Обзор: Puppet, Chef, Ansible, Salt

Ведущие инструменты для управления конфигурацией по разному подходят к автоматизации серверов


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

Быстрое развитие виртуализации вкупе с увеличением мощности серверов, соответствующих промышленным стандартам, а также доступность «облачных» вычислений привели к значительному росту числа нуждающихся в управлении серверов, как внутри, так и вне организации. И если когда-то мы делали это при помощи стоек с физическими серверам в центре обработки данных этажом ниже, то теперь мы должны управлять гораздо большим количеством серверов, которые могут быть распределены по всему земному шару.

В этот момент средства управления конфигурациями и вступают в игру. Во многих случаях, мы управляем группами одинаковых серверов, на которых запущены одинаковые приложения и сервисы. Они размещаются на системах виртуализации внутри организации, или же запускаются как «облачные» и гостевые в удаленных ЦОД. В некоторых случаях, мы можем говорить о большом количестве оборудования, которое существует только для поддержки очень больших приложений или об оборудовании, обслуживающем мириады небольших сервисов. В любом случае, возможность «взмахнуть волшебной палочкой» и заставить их всех выполнить волю системного администратора не может быть обесценена. Это единственный путь управлять огромными и растущими инфраструктурами.

Puppet, Chef, Ansible и Salt были задуманы чтобы упростить настройку и обслуживание десятков, сотен и джае тысяч серверов. Это не значит, что маленькие компании не получат выгоды от этих инструментов, так как автоматизация обычно делает жизнь проще в инфраструктуре любого размера.
Я пристально взглянул на каждый из этих четырех инструментов, исследовал их дизайн и функциональность, и убежден, что несмотря на то, что некоторые оценены выше, чем другие, для каждого есть свое место, в зависимости от целей внедрения. Здесь я подвожу итоги моих находок.


Puppet Enterprise

Puppet считается наиболее используемым из четырех. Он наиболее полон с точки зрения возможных действий, модулей и пользовательских интерфейсов, представляя полную картину ЦОД, охватывая почти каждую операционную систему и предоставляя утилиты для всех основных ОС. Начальная установка относиельно проста, требует развертывания головного сервера и клиентских агентов на каждой управляемой системе.
Интерфейс командной строки позволяет загружать и устанавливать модули с помощью команды puppet. Затем требуются изменения в конфигурационных файлах, необходимые для настройки модуля под требуемую задачу, а клиенты, которые должны получить инструкции, получат их при следующем обращении к головному серверу, или через запрос от сервера, инициирующий процесс изменения немедленно.
Также имеются модули, с помощью которых выполняется настройка виртуальных и размещенных в «облаках» серверов. Все модули и конфигурации строятся с помощью встроеного, основанного на ruby, языка, или же на самом ruby. Это потребует некоторых знаний программирования, в дополнение к навыкам системного администрирования.

Результаты тестирования в тестовом датацентре

Доступность
Совместимость
Управление
Масштабируемость
Производительность
Стоимость
Общий итог
20%
20%
20%
20%
10%
10%
AnsibleWorks Ansible 1.3
9
7
8
8
9
9
8,2
Очень хорошо
20%
20%
20%
20%
10%
10%
Enterprise Chef 11.4
9
8
7
9
8
9
8,3
Очень хорошо
20%
20%
20%
20%
10%
10%
Puppet Enterprise 3.0
9
9
9
9
9
9
9
Отлично
20%
20%
20%
20%
10%
10%
SaltStack Enterprise 0.17.0
9
8
9
9
9
9
8,8
Очень хорошо


В Puppet Enterprise наиболее полный веб-интерфейс из всех, позволяющий контролировать управляемые узлы в реальном времени с помощью предварительно созданных модулей и «поваренных книг» (cookbooks), размещенных на головных серверах. Вебинтерфейс хорош для управления, но не позволяет проводить «тонкую» настройку модулей. Инструменты для построения отчетов хорошо разработаны, предоставляя глубокую детализацию о поведении агентов и о внесенных изменениях.

Enterprise Chef

Chef похож на Puppet с точки зрения общей концепции, в нем также имеется головной сервер и агенты, установленные на управляемых узлах. В дополнение к головному серверу, установка Chef также требует рабочей станции, для управления им. Агенты могут быть установлены с рабочей станции с помощью утилиты knife, которая использует протокол SSH для развертывания, облегчая бремя установки. После этого, управляемые узлы аутентифицируются с головным при помощи сертификатов.

Конфигурация Chef тесно связана с системой управления версиями Git, поэтому знание того, как работает Git необходимо для работы. Также как и Puppet, Chef основан на ruby, поэтому потребуется и знание этого языка. Как и в случае с Puppet. Модули могут быть загружены или написаны «с нуля», после чего установлены на управялемые узлы, в соответствии с требуемыми настройками.

В отличие от Puppet, у Chef пока нет хорошо реализованной функции push, хотя доступна бета-версия кода. Это означает, что агентов должны быть настроены на периодическую синхронизацию с головным сервером, и немедленное применение изменений невозможно.

Пользовательский веб-интерфейс функционален, но не предоставляет возможности модифицировать конфигурации. Он не так полон, как веб-интерфейс Puppet Enterprise, уступает в построении отчетов и некоторых других функциях, но позволяет вести учет оборудования и организацию узлов.
Как и у Puppet, у Chef большой набор модулей и рецептов настроек, преимущественно на ruby. По этой причине, Chef хорошо подходит для инфраструктур, ориентированных на разработку.

AnsibleWorks Ansible


Ansible больше похож на Salt, чем на Puppet или Chef. Ansible фокусируется на оптимизации и скорости, и не требует установки агентов на управляемые узлы — все функции производятся по SSH. Ansible написан на python, в отличие от Puppet и Chef, основанных на ruby.

Установка Ansible может быть выполнена путем клонирования Git-репозитория на головной сервер. Вслед за этим, узлы, над которыми требуется управление добавляются в конфигурацию Ansible, и авторизованные ключи SSH «привязываются» к каждому узлу, относясь к пользователю от имени которого будет запускаться Ansible. Как только это сделано, головной сервер может соединяться с узлами по протоколу SSH и выполнять все необходимые задачи. Для работы с системами, не позволящими доступ с правами суперпользователя (root) по SSH, Ansible использует учетные данные, позволяющие выполнять действия от имени суперпользователя с помощью команды sudo.

Ansible может использовать Paramiko — реализацию протокола SSH2 на языке python, или стандартную реализацию SSH, но есть также ускоренный режим, для более быстрой и широкомасштабной коммуникации.

Ansible может быть запущен из командной строки без использования конфигурационных файлов для простых задач, таких как проверка, что некий сервис запущен, или для обновления триггеров и перезагрузки. Для более комплексных задач, конфигурационные файлы создаются с помощью YAML и называются «сценарии» (playbook). В них могут быть использованы шаблоны для расширения функциональности.

В Ansible есть набор модулей, которые могут использоваться для управления различными системами, равно как и «облачными» инфраструктурами, такими как Amazon EC2 и OpenStack. Дополнительные модули могут быть написаны на практически любом языке программирования, при условии, что вывод будет в формате JSON.

Веб-интерфейс доступен в виде AnsibleWorks AWX, но напрямую не связан с интерфейсом командной строки. Это значит, что элементы конфигурации, заданные через командную строку, не появятся в веб-интерфейсе до тех пор, пока не будет запущен цикл синхронизации. Вы можете использовать встроенную утилиту для этого, но необходимо запланировать ее регулярный запуск. Сам по себе веб-интерфейсе достаточно функционален, но не такой полный, как интерфейс командной строки, таким образом вы либо будете переключаться между обоими, либо же просто использовать командную строку.

SaltStack Enterprise


Salt схож с Ansible в том, что основан на командной строке. Он использует метод push для связи с клиентами. Он может быть установлен через Git или через систему управления пакетами на головном сервере и клиентах. Клиент делает запрос к головному серверу, и если тот дает разрешение, позволяет управлять данным узлом с помощью агента (в терминах Salt — minion).

Salt может связываться с клиентами по протоколу SSH, но масштабируемость значительно расширяется за счет клиентских агентов. Также, Salt включает асинхронный файловый сервер для ускорения обслуживания агентов, позволяя создавать хорошо масштабируемые системы.

Как и в случае Ansible, вы можете отдавать команды, такие как как запуск сервисов или установка пакетов агентам напрямую из командной строки, или можете использовать конфигурационные файлы в формате YAML (state), для обработки комплексных задач. Также есть централизовано размещенные наборы данных (pillar) к которым имеют доступ конфигурационные файлы во время работы.

Вы можете запросить информацию о конфигурации — такую как версия ядра или детальную информацию о сетевом интерфейсе — напрямую от агентов через командную строку. Агенты могут также задаваться через использование элементов инвентаря, называемых «зернами» (grain), позволяющими легко передавать команды на определенные сервера, безотносительно к настроенным группам. Например, одной командой можно отправить запрос к агентам, расположенным на серверах с определенной версией ядра.

Как и предыдущие продукты, Salt предоставляет большое количество модулей для разнообразного программного обеспечения, операционных систем и «облачных» сервисов. Вспомогательные модули могут быть написаны на языках python или PyDSL. Salt предоставляет возможность управлять и Windows-узлами, равно как и Unix, но больше расчитан на системы Unix и Linux.

Веб-интерфейс Salt — Halite — слишком новый и не полный, как пользоветельские интерфейсы других систем. С его помощью можно просматривать системные журнал сообщений и статус управляемых узлов, а также имеется возможность выполнять на них команды. Этот иснтурмент активно разрабатывается, и обещает значительные улучшения, но пока это голый «скелет» и содержит много ошибок.

Самое большое преимущество Salt — масштабируемость и гибкость. У вас может быть несколько уровней головных серверов, организующих связанную струкутру, для обеспечения распределения нагрузки и увеличения отказоустойчивости. Головные сервера верхнего уровня могут управлять нижестоящеми в иерархии и их подчиненными узлами. Другое преимущество — одноранговая система обмена сообщениями, позволяющая подчиненным узлам задавать вопросы головным, а те могут получать ответы от других серверов для завершения картины. Это может быть полезным, если даные для завершения настройки узла находятся в базе данных реального времени.

Puppet или Chef? Ansible или Salt?


Тогда как Puppet и Chef ориентированы на разработчиков, Salt и Ansible больше подходят для нужд системных администраторов. Простой интерфейс и удобство использования Ansible подходят мышлению сисадминов в компаниях с большим числом Unix и Linux систем. Ansible быстри и легко запускается «из коробки».

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

Puppet наиболее зрелый и, вероятно, самый доступный из четырех продукт, с точки зрения удобства использования, хотя и настоятельно рекомендуются основательные знания ruby. Puppet не настолько оптимизирован как Ansible или Salt, и его конфигурация временами может напоминать «филькину грамоту». Puppet наиболее безопасен для гетерогенного окружения, но вы можете счесть Ansible или Salt более подходящим для больших или более гомогенных инфраструктур.

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

Если вы зантересованы глубже изучить эти продукты, прочитайте полные обзоры:
Review: Ansible orchestration is a veteran Unix admin's dream
Review: Chef cooks up configuration management
Review: Puppet 3.0 pulls more strings
Review: Salt keeps server automation simple

Общий взгляд

Puppet 3.0
Chef 11.4
Ansible 1.3
Salt 0.17
За
  • Модули могут быть написаны на ruby, или на более простом, производном от ruby языке
  • Команды Push позволяют применять изменения немедленно
  • Веб-интерфейс поддерживает отчеты, инвентаризацию и управление узлами в реальном времени
  • Детализированные отчеты о работе агентов и конфигурации узлов

  • «Поваренные книги» и рецепты используют всю мощь ruby
  • Централизованные, основанные на JSON массивы данных позволяют скриптам заполнять переменные во время работы
  • Веб-интерфейс позволяет вести поиск и учет узлов, просматривать их активность, применять «поваренные книги» и роли

  • Модули могут быть написаны почти на любом языке
  • Не требуются агенты на управляемых узлах
  • Веб-интерфейс позволяет настраивать пользователей, команды и оборудование, применять сценарии
  • Очень просто настраивается и запускается

  • Конфигурационные файлы могут быть простыми YAML-шаблонами или скриптами на pyhton и PyDSL
  • Может связываться с клиентами через SSH или с помощью локально установленных агентов
  • Веб-интерфейс позволяет просматривать запущенные задачи, статус подчиненных узлов и позволяет выполнять комнады на клиентах
  • Крайне хорошо масштабируется

Против
  • Требуется изучение встроенного языка или ruby
  • Процессу установки недостает отчетов об ошибках


  • Требуется знание ruby
  • В данный момент недостает функциональных команд push
  • Документация местами неясная

  • Недостает поддержки клиентов для Windows
  • Веб-интерфейс автоматически не связывается с существующей установкой Ansible; данные должны быть импортированы

  • Веб-интерфейс не такой зрелый и полный как у конкурентов
  • Не хватает инструментов для детальных отчетов

Цены
Бесплатная версия с открытым исходным текстом; Puppet Enterprise стоит $100 за компьютер в год
Бесплатная версия с открытым исходным кодом; Enterprise Chef бесплатен для 5 компьютеров, $120 в месяц для 20 компьютеров, $300 в месяц для 50 компьютеров, $600 в месяц для 100 и так далее
Бесплатная версия с открытым исходным кодом; AWX бесплатен для 10 компьютеров, далее $100 или $250 за компьютер в год, в зависимости от поддержки
Бесплатная версия с открытым исходным кодом; SaltStack Enterprise стоит $150 за узел в год, со скидками в зависмости от количества и корпоративными лицензиями


Автор: Paul Venezia
Оригинал статьи
Поделиться публикацией
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама
Комментарии 17
  • 0
    Меня вот интересует один вопрос. Проекты Salt и Ansible существенно моложе, чем Puppet и Chef. Всвязи с чем вызвано их появление на свет? Можно ли говорить о том, что это следующее поколение систем управления конфигурациями?
    • –4
      Yes
      • +5
        Да. Могу говорить за Ansible. После попыток быстро что-то сделать с Chef, Puppet, CFEngine. Ansible это глоток свежего воздуха. Базовые вещи можно начинать делать после прочтения одной А4 страницы. Автоматический репорт после выполнения команды максимально упрощает дебаг. У меня только одни вопрос: «Почему раньше нельзя было так просто сделать» :)
      • 0
        Да, можно и так сказать про Ansible. Рефакторил как-то Puppet для крупного хостинга — было стойкое желание написать свой puppet из-за не очевидных часто конфигов на ruby, агента на сервере, из-за мелочей, которые могли бы быть реализованы проще. Автору ansible удалось избавиться от недостатков puppet: работа через ssh, простой конфиг в yaml, низкий порог вхождения, мои админы оценили.
      • +3
        В Puppet Enterprise наиболее полный веб-интерфейс из всех, позволяющий контролировать управляемые узлы в реальном времени с помощью предварительно созданных модулей и «поваренных книг» (cookbooks)

        После этого абзаца невольно засомневался, что автор хоть немного повникал в реальную архитектуру Puppet.
        • 0
          Я думаю, автор не вникал, а просто перевёл.
          • НЛО прилетело и опубликовало эту надпись здесь
            • 0
              Спасибо, поправил. А в архитектуру puppet я как раз сейчас вникаю, оф.документация очень даже ничего — правда на ее перевод я замахиваться боюсь. :-)
          • 0
            На сколько я помню, cookbooks это концепция Chef, а не Puppet. Очевидно ошибка перевода.
            Так же нет важных архитектурных отличий и табличка очень субъективная.
            Одно наличие в Salt MQ подсистемы для получения статусов и логов с хостов, а в Chef реляционного Postgress для хранения данных говорит очень много о применимости и масштабируемости этих систем.
            В общем, оригинальная статья не очень ок и может привести человека к ложному выбору.
            Реально масштабно использовал только chef на 1000+ хостах. Летело:)
            • 0
              В оригинале — «Puppet Enterprise has the most complete Web UI of the bunch, allowing for real-time control of managed nodes using prebuilt modules and cookbooks present on the master servers.», но с Вами согласен — о «поваренных книгах» в доках по Puppet упоминается в объяснении классов — «Classes: The Puppet classes (or Chef cookbooks, etc.) applied to this node». То ес ть по-русски — «Классы: Классы Puppet (или „поваренные книги“ Chef» и т.д.) применяемые к этому узлу". Каюсь, не очень удачный выбор статьи, однако опыта работы ни с одной из этих систем не было, о чем я честно предупредил в начале. :-)
          • +1
            Мы как раз переводим сейчас наши Rails проекты с Chef на Ansible. Базовые вещи в Ansible делаются действительно проще и понятнее нежели в случаи с Chef.
            • 0
              После мучительных попыток освоить Chef, пробовал Puppet, теперь попробую Ansible, он действительно кажется проще и понятнее, спасибо.
              • 0
                AnsibleWorks AWX теперь называется Ansible Tower.
                • 0
                  Про Ansible незнал, думал буду учить chef/ruby. Спасибо
                  • 0
                    не сосвем понял про push для chef

                    можно делать
                    knife ssh «role:webserver AND chef_environment:production» «sudo chef-client» -С 4
                    и деплоить изменения сразу и с указанной конкуренцией ( что может быть удобно, когда сервера стоят за балансировщиком и нужно чтото рестартить).

                    По моему скромному мнению, chef идеалогически правильно заточен под devops workflow.

                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.