На днях наткнулся на инструмент 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 часа почитал к ней доки.