Apache Brooklyn

Материал из Национальной библиотеки им. Н. Э. Баумана
Последнее изменение этой страницы: 20:23, 17 января 2019.
Apache Brooklyn
Brooklyn Logo
Создатели: Apache Software Foundation, Cloudsoft
Выпущена: April 2012 [Источник 1]
Состояние разработки: Active
Написана на: Java, Javascript, Groovy
Операционная система: Linux, macOS, Windows
Лицензия: Apache License 2.0
Веб-сайт Apache Brooklyn

Apache Broklyn является платформой с открытым исходным кодом для развертывания и управления распределенными приложениями, моделируя, контролируя руководящие приложения через автономные проекты[Источник 2].

Идеи, лежащие в Apache Бруклине пришли из Автономных Вычислений в теории Promise. Это также пытается реализовать OASIS CAMP (Управление Облачным Приложением Для Платформ) и TOSCA (Топология и Спецификация Оркестровки для "Облачных" приложений) стандартные спецификации.

Особенности

Проектирование

  • Компонуемое проектирование
    Спецификация службы YAML может иметь отношение к другим проектам, в каталоге или URL, и может предоставлять пользовательскую конфигурацию.
  • Портативные спецификации механизмов - или идентификаторы конкретного местоположения
    Определяет спецификации механизмов, используя переносимые ограничения, или, когда вы должны использовать определенный imageId, аппаратные профили и т.д.

Управление на основе политик

  • Текущие показатели
    Соберите текущих показателей для использования в политике из метрических хранилищ или от непосредственно использования REST, JMX, SSH, и т.д.
  • Политика управления
    Выберите из встроенной политики включая автомасштабирование, отказоустойчивость и следование-солнцу, или создайте новую политику выполняющую пользовательское управление во время работы. Используйте ключи конфигурации, чтобы настроить политику для удовлетворения потребностей вашей системы, прямо в проекте YAML.
  • Динамическое реконфигурирование
    Реконфигурируйте политику, приостановите ей или добавьте новые на лету через остальных API.

Операции

  • Brooklyn консоль
    Brooklyn работает с консолью GUI, предоставляющей легкий доступ к иерархии управления, датчикам и действиям.
  • Высокая доступность
    Выполненные резервные узлы, которые дополнительно могут автоматически заменить ведущее устройство в случае отказа основного. Узлы горячего резервирования могут обеспечить дополнительный доступ только для чтения к информации об объекте.
  • Постоянство состояния
    Проект, каталог, топология и информация о датчике могут быть автоматически сохранены в любой файловой системе или объектно-ориентированной памяти при остановке Brooklyn и перезапуске, все возобновиться с того места где вы закончили.
  • REST API
    Консоль - чистый JS-REST, и все данные, показанные в GUI, доступны через прямой REST/JSON API. Во многих случаях остальное API является просто конечной точкой GUI без продвижения #. Например, данные для #/v1/applications/ доступны в /v1/applications/. И во всех случаях, документ Swagger доступен в продукте.
    Рисунок 1 - REST API example
  • Groovy консоль
    С правильными полномочиями крипты Groovy могут быть отправлены через GUI или через REST, позволив операцию на открытом сердце в Ваших системах. (Используйте с осторожностью!)
  • Управление версиями
    Проекты в каталоге могут быть иметь версию, которая была на время выполнения. Рабочие объекты присоединены к версии, против которой они были запущены, чтобы сохранить целостность, пока ручные обновления версии не выполнены.
  • Подробная информация о задаче
    Консоль показывает потоки задачи в режиме реального времени, включая stdin и stdout для команд оболочки, делая более простым отладку той досадной неудачи.

Java

  • Поддающаяся обнаружению конфигурация
    Ключи конфигурации, датчики и исполнительные элементы могут быть определены на классах, таким образом, что они автоматически поддающиеся обнаружению во времени выполнения. Введите информацию, параметры, документацию, и значения по умолчанию возвращены через остальных API и показаны в GUI.
  • Введите иерархию
    Используйте интерфейсы и соединение-ins, чтобы совместно использовать и наследовать форму поведения со строгим контролем типов.
  • Каналы датчика
    Быстрый API стиля разработчика включен для сбора информации датчика от конечных точек REST, команд SSH, соединителей JMX, и т.д.
  • Библиотеки задачи
    Быстрые библиотеки задач стиля разработчика включены для цепочек строительных работ, которые работают параллельно или последовательно, выполняя SSH, REST или произвольные команды Java. Состояние Task, результат, иерархии и ошибки представлены через остальных API и в GUI.

Теория

Brooklyn - платформа для моделирования, контроля и руководящих приложений через автономные проекты.

Почему Brooklyn?

Создание и развертывание приложений в эру "облачных" вычислений изменили многие вещи. Настройте пустой на текущее время сервер, и используйте автоматизированные инструменты, чтобы установить приложение. Используйте API, чтобы добавить сервер к балансировщику загрузки. Когда загрузка идет вверх, используйте другой сервер; когда загрузка спадает, уничтожьте сервер, чтобы экономить деньги.

Появились много новых инструментов, которые используют в своих интересах эту новую эру. Однако, каждый из них только решает часть проблемы и не рассматривает картину целиком. Например, инструменты управления конфигурацией, такие как Chef могут единственной командой настраивать новый облачный сервер и тогда же способны устанавливливать и конфигурировать приложение – но они требуют, чтобы дополнительный код программы реконфигурировал балансировщик загрузки каждый раз, когда пул веб-серверов изменяется. Автомасштабирование Amazon может настроить новые серверы и обновить балансировщики загрузки, но это зависит от CloudWatch – что означает использование метрики по доверенности, такие как среднее время отклика или писать больше кода, представляющий реальные метрики приложения. Выделенный контрольный инструмент может быть в состоянии легко контролировать ключевые метрики с небольшим усилием, но его сигналы тревоги должны будут быть интегрированы в процесс настройки сервера.

Таким образом, все инструменты создают и управляют приложением облачного масштаба, которое может адаптироваться к потребностям для оправдания надежд пользователя, не тратя впустую деньги на лишние службы, но вам будут нужны несколько таких инструментов и вам решать интегрировать их в ваш план развертывания. Некоторые из этих инструментов – таких как сеть Веб-сервисов Amazon EC2, CloudWatch, AutoScaling и CloudFormation – означают, что вы можете пострадать от привязки. Связанные проекты в OpenStack (Heat, Ceilometer, Murano, Solum и т.д.) обеспечивают подобную функциональность, но снова для ограниченной цели.Наиболее распространенная политика (такая как уменьшение задержки запроса) может быть простой, но меньше использование общей политики, такой как следование-солнцу и следование-луне может завершить ваше дело. Ваша политика масштабирования может понять, что “высокое требование = добавляет другой сервера”, но может не понять требования, такие как некоторые сгруппированные службы, требующие нечетного числа экземпляров для предотвращения голосовых блокировок.

Как Brooklyn может помочь

В этом контексте преимущество Brooklyn становится очевидным: единственный инструмент, который в состоянии управлять настройкой и развертыванием приложения, контролировать состояние и метрики приложения, понять зависимости между компонентами (такими как знание, что при добавлении нового веб-сервера означает, что балансировщику загрузки нужно реконфигурирование), и возможность применения сложной политики управления приложением.Инструмент обеспечивает API REST и GUI, и позволяет автономным проектам рассматриваться как неотъемлемую часть приложения. С Brooklyn вводиться политика, где они становится модульными компонентами, которые могут быть снова использованы и легко добавлены к проектам.

Brooklyn о развертывании приложений и управления ими: создание полного стека для приложения; развертывание, чтобы объединиться в облако и не объединиться в облако; использование контролирующих инструментов, чтобы собрать ключевые метрики состояния/производительности; ответ на ситуации, такие как узел сбоя; и добавление или удаление возможности соответствовать требованиям.

Проектирование

Проект Brooklyn определяет приложение, используя декларативный синтаксис YAML, поддерживающий плагины JVM. Основной проект может содержать один процесс, например, сервер веб-приложений под управлением файла WAR или базы данных SQL и связанные сценарии DDL. Более сложные проекты охватывают комбинации процессов через многочисленные механизмы и службы, такие как выравнивание нагрузки сервером HTTP или контроллером SDN, выходящий на кластер серверов приложений J2EE, поочередно соединенных с эластичным кластером серверов базы данных SQL. Еще более сгруппированное приложение, работающее в многочисленных областях, может быть описано, с функциями, такими как шины сообщения с эластичными брокерами, кэширование уровней серверов хранилища значения ключа NoSQL, высоконадежного кластера баз данных и многократных компонентов приложения, соединенных через эти уровни.

Одно основное преимущество этих проектов - то, что они компануемы: проекты наиболее успешной практики одного процесса или образца (например, кластер Cassandra) могут быть включены в другие проекты (например, приложение с кластером Cassandra как один компонент).Другое главное преимущество - то, что проекты можно рассматривать как исходный код как часть кодовой базы приложений: протестированный, прослеженный, имеющий версию и укрепленный как неотъемлемая часть процесса devops[Источник 3] . До некоторой степени Brooklyn по времени выполнения, что Maven ко времени изготовления.

Проекты Превращаются в Развертывание

Brooklyn знает о Chef, Salt и подобных инструментах, APT, Yum и простых сценариях оболочки, для развертывания компонентов приложения. Проекты созданы из смеси и стандартных пакетов, таких как Tomcat, MySQL, Cassandra, и еще многого из нашей библиотеки; и компоненты, которые сделаны на заказ к отдельным приложениям; вместе с политикой, которая позволяет приложению заниматься самоуправлением.

Brooklyn создан для облака, в котором открывается проект и разворачивается на одном из многих поддерживаемых облаков или даже на нескольких различных облаках, или в частной инфраструктуре (принесите свой собственный узел), или на других платформах. Это позволяет динамично сконфигурировать и соединить все различные компоненты приложения, например, таким образом, балансировщики загрузки будут знать, где веб-серверы, а веб-приложения, где база данных.

Brooklyn собирает ключевые метрики, чтобы контролировать состояние приложения; например, при отправке запроса и при измерении задержки, или устанавливаются контролирующие инструменты и, используя их считываться интерфейс управления сервера, чтобы определить длину очереди запроса. Эти метрики могут быть внедрены в политику, которая автоматически принимает меры, такие как перезапуск неудавшегося узла или масштабирование ярусов веб-узлов, если требование превышает возможности пользователя. Это позволяет приложению быть самоуправляемым: восстанавливать себя при простых отказах, масштабироваться, когда требования увеличиваются и соответствовать мощности; затем масштабировать падении спроса и прекратить платить за резервные мощности.

Проще говоря, проекты Brooklyn позволяют примерам наиболее успешной практики развертываться и управлять сложным программным обеспечением, шифроваться как часть процесса разработки программного обеспечения.

Быстрый и гибкий

Brooklyn - продукт, созданный с нуля для быстроты приложения. Оно включает мобильность через не облако, облако и цели PaaS; поскольку применяется инфраструктура кода devops-стиля к приложениям; и автономное управление в реальном времени на основе теории promise. Некоторые введения в эти понятия, связанные инструменты и открытые спецификации могут быть полезными.

Облачные вычисления в своей основе составляют резервы ресурсов по требованию. Наиболее широко известный аспект - IaaS (инфраструктура как сервис), такая как Amazon EC2, Softlayer, Google Cloud Platform, Apache CloudStack или OpenStack. Усиливая проект Apache jclouds (и способствуя в большой степени ему), проект Brooklyn в состоянии работать с большим количеством таких провайдеров. Однако, выше стека есть все более и более разнообразный набор целей платформы, от PaaS (платформа как сервис), таких как Cloud Foundry и Apache Stratos, через них к бесчисленным контейнерам и структурам во время выполнения, таким как LXC/Докер, Apache Mesos, Apache Karaf, Apache Hadoop и Apache Usergrid и другой бэкэнд как сервис среды. Brooklyn основывается на предпосылке, что приложения, возможно, должны работать в любых из них, и модель должна быть гибка и достаточно открыта, чтобы поддерживать это.

Совместимые между собой devops и модная тенденция, именуемая быстро-гибкие, закрепили много важных уроков:

  • Истина находится в коде (не любые вспомогательные документы)
  • Если это не протестировано, тогда предполагают, что это не работает
  • Интеграция Toolchain и API есть ключ к успеху проекта
  • Еще более важным является расширение прав и возможностей всех заинтересованных сторон в проекте
  • Внимание Brooklyn на проектирование и моделирования в коде и API, соответствует этим принципам.

Автономные Вычисления

Другое главное влияние на проект Brooklyn оказали идеи автономной теории вычислений и теории promise. Нет необходимости иметь их полное понимание, чтобы использовать Brooklyn, но участникам довольно быстро становятся понятны большинство этих аспектов. По существу наука и техника самоуправляющихся систем основывается на понятии компонентов, заботящихся о себе, где есть возможность самовосстановления, самооптимизации и т.д. и представление датчика (выводы данных) и исполнительный элемент (операции) API, где им, возможно, понадобится контроль другого элемента. Теория Promise расширяет этот подход, представляя идею, что передача намерения (посредством обещаний) является более надежным основанием для сложных сотрудничающих систем, чем основанные на обязательстве исполнительные элементы. Инструменты, такие как CF Engine, Chef, Puppet, Ansible и Salt применяют теорию Promise к файлам и процессам на механизмах; Brooklyn может усилить все эти инструменты, дополнив их прикладной моделью.

Стандарты

Наконец мы отмечаем некоторые появляющиеся стандарты в этой области. OASIS CAMP (Cloud Application Management for Platforms) и TOSCA (Topology and Orchestration Specification for Cloud Applications) определяют прикладные модели YAML, типа Brooklyn. CAMP фокусирует на остальных API для взаимодействия с таким уровнем управления и фокусы TOSCA на декларативной поддержке более сложной оркестровки. В настоящее время Бруклин использует YAML, который соответствует синтаксису CAMP и представляет многие конечные точки CAMP API REST. Мы хотели бы поддерживать только что отпечатанный TOSCA YAML и расширить охват CAMP API REST.

Установка Apache Brooklyn

По умолчанию аутентификация не требуется, и веб-консоль будет прослушивать все сетевые интерфейсы. Для производственной системы или если Apache Brooklyn общедоступен, настоятельно рекомендуется настроить безопасность.

Ubuntu / Debian

Для пользователей Ubuntu и Debian рекомендуемый способ установки Apache Brooklyn - использовать файл deb.

Файл deb является стандартом для упаковки программного обеспечения в этих дистрибутивах Linux и предоставляет механизм для установки, обновления и удаления таких пакетов, как Apache Brooklyn. Пакет deb содержит все необходимые для работы файлы. Загрузите дистрибутив Apache Brooklyn.

После загрузки выполните следующую команду:

sudo dpkg -i apache-brooklyn_0.12.0_noarch.deb

OSX / Linux

Для Linux или OSX, пожалуйста, загрузите Apache Brooklyn tar.gz из раздела загрузок.

Распакуйте архив tar.gz и перейдите в папку apache-brooklyn-0.12.0.

tar -zxf apache-brooklyn-0.12.0-dist.tar.gz
cd apache-brooklyn-0.12.0

Windows

Для всех версий Microsoft Windows загрузите zip-файл Apache Brooklyn с этой страницы.

Извлеките этот zip-файл в каталог на вашем компьютере, например, c:\Program Files\brooklyn, где c - это буква диска вашей операционной системы.

Запуск Apache Brooklyn

Ubuntu / Debian

Apache Brooklyn должен быть установлен и работать как системная служба. Его можно остановить и запустить стандартными консольными командами:

sudo service brooklyn start|stop|restart|status

Затем приложение должно вывести свои логи в brooklyn.debug.log и brooklyn.info.log. Подробная информация о расположении файлов указана здесь.

OSX / Linux

Запустите Apache Brooklyn с помощью следующей команды:

bin/start

Затем приложение должно вывести свои логи в brooklyn.debug.log и brooklyn.info.log. Подробная информация о расположении файлов указана здесь.

Windows

Теперь вы можете запустить Apache Brooklyn, запустив
c:\Program Files\brooklyn\bin\start.bat
Затем приложение должно вывести свой журнал в консоль, а также
c:\Program Files\brooklyn\data\log\brooklyn.debug.log
и
c:\Program Files\brooklyn\data\log\brooklyn.info.log

Управление Apache Brooklyn

Управление Apache Brooklyn может производиться через веб-консоль. Логи будут содержать адрес интерфейса управления:

INFO  Started Brooklyn console at http://127.0.0.1:8081/, running classpath://brooklyn.war

По умолчанию к нему можно получить доступ, открыв 127.0.0.1:8081 в вашем веб-браузере.

Apache Brooklyn использует инструмент интерфейса командной строки (CLI), br. Этот инструмент распространяется вместе с Apache Brooklyn или может быть загружен по наиболее подходящей ссылке для вашей ОС:

  1. Windows
  2. Linux
  3. OSX

Ссылки

  1. Presentation of Apache Brooklyn at ApacheCon (organized by Linux Foundation) // Сайт Linuxfoundation. Дата обновления: 10.05.2018 [2018-2018]. URL: http://events.linuxfoundation.org/sites/events/files/slides/Apache%20Brooklyn%20-%20what%20it%20is.pdf (дата обращения: 22.12.2018)
  2. Apache Foundation // Официальный сайт Apache. Дата обновления: 10.07.2018 [2018-2018]. URL: https://brooklyn.incubator.apache.org/learnmore/theory.html (дата обращения: 20.11.2018)
  3. DevOps // Википедия. Дата обновления: 14.02.2018 [2018-2018]. URL: https://ru.wikipedia.org/wiki/DevOps ru.wikipedia.org/wiki/DevOps (дата обращения: 22.12.2018)