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

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

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

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

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

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

Puppet Enterprise

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

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

В 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

Общий взгляд

Автор: Paul Venezia
Оригинал статьи

Автор: horridum

Источник