На днях наткнулся на инструмент Juju от Canonical.
Обрывочные сведения из интернета утверждают, что это инструмент управления конфигурацией наподобие Chef, Ansible или Puppet.
Я прочитал наискосок доки по нему, заглянул в репозитории с charms-модулями (аналог кукбуков или плейбуков) и утверждаю, что это не так.
Juju — это скорее VM-agnostic оркестратор (наподобие Nomad или Kubernetes). На нем можно декларативно описывать инфраструктурную конфигурацию приложения: какие приложения у нас запущены, на каких машинах, в скольки копиях, как они связаны с другими сервисами.
Но в отличие от того же Kubernetes он может работать не только с Docker, но и с любыми видами виртуальных машин.
Говорят, ядро, агент и клиент написаны на Golang — и я в них не заглядывал.
Часть же, относящаяся собственно к конфигурации обычно описывается на комбинации YAML и Python (в доках сказано, что кроме питона можно использовать и другие языки).
Как же это все работает?
Disclaimer: эта статья не претендует на полное и точное описание, я скорее рассматриваю ее как способ снизить порог входа для тех, кто захочет взглянуть на Juju и помочь сориентироваться в документации.
Полная документация находится здесь: https://docs.jujucharms.com/
Как уже написал выше, в Juju есть несколько компонентов:
- Контроллер — серверная часть, которая выделяет виртуалки. Для каждого [облачного] провайдера есть свой контроллер (в т.ч. и для не совсем облачных, таких как локальный LXD или Metal as a Service).
Контроллер — это монолитное приложение из одного компонента. Должна быть запущена минимум одна копия контроллера в каждом провайдере. Есть какое-то HA, но я в это не вникал. - Агент — ставится на каждую виртуалку. Есть два вида агентов — для machine и для unit. Кажется, один из них ставится на хостовую машину, а один в виртуалку — подробно я в это тоже не вникал.
- Клиент — CLI-инструмент для управления всем этим хозяйство.
- GUI
- Декларативное описание всех пользовательских компонентов (приложений, машин и т.д.)
- Пользовательский код для настройки отдельной виртуалки, он называется Charms
(Реально там дерево компонентов больше, но для данного повествования сделаем упрощение, чтобы было проще понять что к чему)
На декларативном описании можно строить примерно такие структуры компонентов (графы отрисовываются автоматом через GUI):
Серверная часть как-то там создает виртуалки, вытягивает зависимости, устанавливает между ними связи, отслеживает возникающие сигналы — там все, мне кажется, довольно стандартно как и у других оркестраторов.
А вот модули настройки виртуалок, называемые charms (ед.ч — charm) давайте рассмотрим подробнее.
Казалось бы, я знаю Chef, Ansible и Puppet, наверное здесь ничего нового нет, однако это не так. Создатели Juju не стали создавать DSL для декларативного описания ресурсов в системе. Вместо этого они создали фреймворк, который позволит вполне обычный код на питоне или баше сделать идемпотентным и связать его с Juju контроллером.
Устройство Charm
Сами чармы устроены не очень просто. По структурной сложности напоминают кукбуки шефа или роли ансибла. И по сути являются скорее аналогом ресурсов, а не кукбуков.
Они состоят из метаданных/декларативной части, императивных хуков (реакции на события) и всяческий файлов данных типа дополнительных скриптов, документации или типовых конфигов.
В декларативной части описываются интерфейсы-зависимости чарма (например, чарм wordpress зависит от mysql, а чарм mysql предоставляет этот интерфейс), совместимости с системами, теги, параметры конфигурации (типа атрибутов кукбука) и программные слои-зависимости (layers) от других чармов (к примеру, большинство чармов включают слой layer:basic).
В императивных хуках же описывается реакция на всякие внешние события. Например, на событие install устанавливаем нужный пакет, на событие configure его настраиваем, а на событие start запускаем сервис.
Это все пишется на обычном питоне с декораторами (где-то читал утверждение, что писать можно на чем угодно, хоть и на баше, но примеров не видел).
Классический легковесный пример — NTP: https://github.com/lampkicking/charm-ntp
Что интересно, судя по всему при компиляции чарма получается полностью standalone приложение, которое можно запускать на сервере без дополнительных зависимостей — в скомпилированном варианте я видел, что в него включено содержимое всех используемых им layers, а также тарболы всех используемых питоновских модулей.
Пример для NTP: https://jaas.ai/ntp/32 (см. список файлов в правой части страницы).
Резюме
У Juju очень интересный и необычный подход к описанию и настройке инфраструктуры.
Скорее всего, у juju порог входа выше чем у шефа, скорее всего чармы медленнее в разработке по сравнению с кукбуками и плейбуками и требуют больших квалификаций в программировании.
С другой стороны, предположу, что модель с событиями-хуками подталкивает писать более правильный код.
Мне показалось, что Juju больше нацелен на инфраструктурных программистов (тех, кто написали множество CLI-инструментов на питоне в линуксах 5-7 летней давности), которым теперь надо настраивать сервера, в то время как Chef/Ansible — на админов, которым вместо одного-двух теперь нужно настраивать сотню-другую серверов.
Стоит ли использовать Juju в 2019г?
Не уверен:
- Новые (cloud native) приложения вы завернете в докер в докер и запустите на кубере или ECS
- Для "старых" приложений у вас уже наверняка написаны скрипты разворачивания на ансибле или шефе
- Для новых проектов со "старой" архитектурой — может быть. НО:
- Про Juju в рунете практически никто не знает, это первая статья на русском языке, которая немного описывает что это такое
Если вы работаете с Juju напишите в комментариях где я ошибся — ведь я всего лишь 2-3 часа почитал к ней доки.
