- PVSM.RU - https://www.pvsm.ru -
От переводчика: в связи с грядущим внедрением одной из подобных описанным в статье систем, приходится изучать доселе неведомые продукты. Захотелось перевести, поскольку подобных обзорных статей на русском языке не нашлось (не исключаю, что плохо искал), и, надеюсь, кому-то и пригодится. За возможные ошибки и неточности перевода просьба ногами не бить.
Быстрое развитие виртуализации вкупе с увеличением мощности серверов, соответствующих промышленным стандартам, а также доступность «облачных» вычислений привели к значительному росту числа нуждающихся в управлении серверов, как внутри, так и вне организации. И если когда-то мы делали это при помощи стоек с физическими серверам в центре обработки данных этажом ниже, то теперь мы должны управлять гораздо большим количеством серверов, которые могут быть распределены по всему земному шару.
В этот момент средства управления конфигурациями и вступают в игру. Во многих случаях, мы управляем группами одинаковых серверов, на которых запущены одинаковые приложения и сервисы. Они размещаются на системах виртуализации внутри организации, или же запускаются как «облачные» и гостевые в удаленных ЦОД. В некоторых случаях, мы можем говорить о большом количестве оборудования, которое существует только для поддержки очень больших приложений или об оборудовании, обслуживающем мириады небольших сервисов. В любом случае, возможность «взмахнуть волшебной палочкой» и заставить их всех выполнить волю системного администратора не может быть обесценена. Это единственный путь управлять огромными и растущими инфраструктурами.
Puppet, Chef, Ansible и Salt были задуманы чтобы упростить настройку и обслуживание десятков, сотен и джае тысяч серверов. Это не значит, что маленькие компании не получат выгоды от этих инструментов, так как автоматизация обычно делает жизнь проще в инфраструктуре любого размера.
Я пристально взглянул на каждый из этих четырех инструментов, исследовал их дизайн и функциональность, и убежден, что несмотря на то, что некоторые оценены выше, чем другие, для каждого есть свое место, в зависимости от целей внедрения. Здесь я подвожу итоги моих находок.
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), размещенных на головных серверах. Вебинтерфейс хорош для управления, но не позволяет проводить «тонкую» настройку модулей. Инструменты для построения отчетов хорошо разработаны, предоставляя глубокую детализацию о поведении агентов и о внесенных изменениях.
Chef похож на Puppet с точки зрения общей концепции, в нем также имеется головной сервер и агенты, установленные на управляемых узлах. В дополнение к головному серверу, установка Chef также требует рабочей станции, для управления им. Агенты могут быть установлены с рабочей станции с помощью утилиты knife, которая использует протокол SSH для развертывания, облегчая бремя установки. После этого, управляемые узлы аутентифицируются с головным при помощи сертификатов.
Конфигурация Chef тесно связана с системой управления версиями Git, поэтому знание того, как работает Git необходимо для работы. Также как и Puppet, Chef основан на ruby, поэтому потребуется и знание этого языка. Как и в случае с Puppet. Модули могут быть загружены или написаны «с нуля», после чего установлены на управялемые узлы, в соответствии с требуемыми настройками.
В отличие от Puppet, у Chef пока нет хорошо реализованной функции push, хотя доступна бета-версия кода. Это означает, что агентов должны быть настроены на периодическую синхронизацию с головным сервером, и немедленное применение изменений невозможно.
Пользовательский веб-интерфейс функционален, но не предоставляет возможности модифицировать конфигурации. Он не так полон, как веб-интерфейс Puppet Enterprise, уступает в построении отчетов и некоторых других функциях, но позволяет вести учет оборудования и организацию узлов.
Как и у Puppet, у Chef большой набор модулей и рецептов настроек, преимущественно на ruby. По этой причине, Chef хорошо подходит для инфраструктур, ориентированных на разработку.
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, но напрямую не связан с интерфейсом командной строки. Это значит, что элементы конфигурации, заданные через командную строку, не появятся в веб-интерфейсе до тех пор, пока не будет запущен цикл синхронизации. Вы можете использовать встроенную утилиту для этого, но необходимо запланировать ее регулярный запуск. Сам по себе веб-интерфейсе достаточно функционален, но не такой полный, как интерфейс командной строки, таким образом вы либо будете переключаться между обоими, либо же просто использовать командную строку.
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 ориентированы на разработчиков, Salt и Ansible больше подходят для нужд системных администраторов. Простой интерфейс и удобство использования Ansible подходят
Salt самый надежный из четырех и тоже подойдет системным администраторам. Хорошо масштабируемый и обладающий достаточным функционалом, лишь веб-интерфейс оставляет желать лучшего.
Puppet наиболее зрелый и, вероятно, самый доступный из четырех продукт, с точки зрения удобства использования, хотя и настоятельно рекомендуются основательные знания ruby. Puppet не настолько оптимизирован как Ansible или Salt, и его конфигурация временами может напоминать «филькину грамоту». Puppet наиболее безопасен для гетерогенного окружения, но вы можете счесть Ansible или Salt более подходящим для больших или более гомогенных инфраструктур.
Chef стабильное и хорошо проработанное решение, но пока не дотягивает до уровня Puppet с точки зрения основных функций, однако его можно расширить. Chef может быть трудным для изучения администраторами с недостаточным опытом в программировании, но может подойти компаниям, занимающимся разработкой ПО.
Если вы зантересованы глубже изучить эти продукты, прочитайте полные обзоры:
Review: Ansible orchestration is a veteran Unix admin's dream [3]
Review: Chef cooks up configuration management [4]
Review: Puppet 3.0 pulls more strings [5]
Review: Salt keeps server automation simple [6]
Puppet 3.0 | Chef 11.4 | Ansible 1.3 | Salt 0.17 | |
За |
|
|
|
|
Против |
|
|
|
|
Цены | Бесплатная версия с открытым исходным текстом; Puppet Enterprise стоит $100 за компьютер в год | Бесплатная версия с открытым исходным кодом; Enterprise Chef бесплатен для 5 компьютеров, $120 в месяц для 20 компьютеров, $300 в месяц для 50 компьютеров, $600 в месяц для 100 и так далее | Бесплатная версия с открытым исходным кодом; AWX бесплатен для 10 компьютеров, далее $100 или $250 за компьютер в год, в зависимости от поддержки | Бесплатная версия с открытым исходным кодом; SaltStack Enterprise стоит $150 за узел в год, с сокидками в зависмости от количества и корпоративными лицензиями |
Автор: Paul Venezia [7]
Оригинал статьи [8]
Автор: horridum
Источник [9]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/it-infrastruktura/54192
Ссылки в тексте:
[1] тестовом датацентре: http://www.infoworld.com/test-center/t/data-center
[2] мышлению: http://www.braintools.ru
[3] Review: Ansible orchestration is a veteran Unix admin's dream: http://www.infoworld.com/d/data-center/review-ansible-orchestration-veteran-unix-admins-dream-228509
[4] Review: Chef cooks up configuration management: http://www.infoworld.com/d/data-center/review-chef-cooks-configuration-management-224178
[5] Review: Puppet 3.0 pulls more strings: http://www.infoworld.com/d/data-center/review-puppet-enterprise-30-pulls-more-strings-222737
[6] Review: Salt keeps server automation simple: http://www.infoworld.com/d/data-center/review-salt-keeps-server-automation-simple-228936
[7] Paul Venezia: http://www.infoworld.com/author-bios/paul-venezia
[8] Оригинал статьи: http://www.infoworld.com/d/data-center/review-puppet-vs-chef-vs-ansible-vs-salt-231308?page=0,0
[9] Источник: http://habrahabr.ru/post/211306/
Нажмите здесь для печати.