На днях наткнулся на инструмент 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):
image


Серверная часть как-то там создает виртуалки, вытягивает зависимости, устанавливает между ними связи, отслеживает возникающие сигналы — там все, мне кажется, довольно стандартно как и у других оркестраторов.


А вот модули настройки виртуалок, называемые 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 часа почитал к ней доки.

Комментарии (3)


  1. amarao
    28.06.2019 15:38

    Убунту его очень сильно пиариала ещё в 2014-2015, а от внедрения останавливает
    а) сильная завязка на коммерческие сервисы
    б) печальная судьба апстарта, юнити и мира. Ну не получается у Каноникала свой софт писать.


    1. erthad Автор
      28.06.2019 16:35

      Да, такое впечатление, что он используется только внутри Canonical, и возможно где-то в мире OpenStack.


    1. DSolodukhin
      28.06.2019 17:18

      Mir, кстати, еще живой, только ушел в embedded.