Juju — краткий обзор

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

    Similar posts

    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 6

      +1

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

        –1
        Да, такое впечатление, что он используется только внутри Canonical, и возможно где-то в мире OpenStack.
          0
          Mir, кстати, еще живой, только ушел в embedded.
            0
            Софт, кстати, у Каноникала писать получается прекрасно, но вот продвигать его они не умеют — это совершенно точно.
              0

              Глядя на апстарт — не соглашусь. Очень не очень.

            0
            Подниму старую статью комментарием. Писал для juju charm-ы на go. В целом довольно прикольно было. Но они там все питонисты и для go много чего не хватало. В конечном итоге утыкаешься в то, что нужно кучу абстракций самому написать для init систем, работы с файлами(раскладывание их в нужные места) и правкой конфигов. В итоге приходишь к мысли, а почему бы внутри не заюзать какой то ansible/salt/chef.
            В итоге от juju остается только контроллер и модель связей. Да, сделано прикольно, но по факту штука сама в себе и никто ее особо не использует. А тянуть весь этот велосипед самому гемор еще тот.
            В свое время в clodo/simplecloud я пытался сделать CMS предустановленные на основе Juju и в целом мне не понравилось.
            Кубер тоже еще то зло, но его более удачно протолкнули.

            Only users with full accounts can post comments. Log in, please.