[Перевод] Ansible против Puppet
Ansible и Puppet представляют собой системы управления конфигурациями (SCM), необходимые для построения повторяющихся инфраструктур.
Ansible отличается простотой использования, имеет безагентную архитектуру (не требует установки агента/клиента на целевую систему) и YAML-подобный DSL, написана на Python и легко расширяется за счет модулей. Обычно управляет конфигурацией Linux.
Puppet имеет клиент-серверную архитектуру (периодически опрашивает сервер, чтобы внести в конфигурацию изменения, внесенные администратором сети), написана на Ruby и имеет Ruby-подобный DSL. Это приложение позволяет централизованно управлять конфигурацией ПО, установленного на нескольких компьютерах.
В статье проводится сравнение преимуществ и недостатков этих SCM.
По сравнению с 90-ми годами, в наше время системным администраторам и разработчикам приходится управлять значительно большим количеством серверов, на которых размещается намного больше приложений. Причина этого состоит в экспоненциальном росте вычислений для организаций и компаний, связанным с появлением таких новых технологий, как виртуализация и облачные вычисления.
Таким образом, такие инструменты, как Puppet и Ansible, быстро становятся необходимыми компонентами управления большим количеством серверов, например, в дата-центрах. Их называют средствами управления конфигурацией (CM) и удаленного выполнения (RE) и часто используют с инструментами обновления ПО. Эти полезнейшие приложения позволяют, например, сетевому администратору выполнять действия на нескольких серверах одновременно, развертывать несколько приложений одним щелчком мыши, что значительно упрощают настройку и обслуживание десятков, сотен или даже тысяч серверов.
Ansible против Puppet: краткий обзор
Puppet — один из известнейших брендов на рынке CM. Он существует с 2005 года, что для инструментов CM равносильно существованию со времен зарождения человечества. Множество именитых клиентов, таких как Google, Reddit, Dell, PayPal, Oracle, лаборатории Los Alamos Labs и Стэндфордский университет, управляют своими дата-центрами с помощью Puppet. Наличие таких клиентов на борту всегда придает продукту определенный уровень доверия. Puppet также может похвастаться самым зрелым интерфейсом и работой на всех основных операционных системах -Linux, Windows, Unix и даже Mac OS X. Следуя модели, созданной различными версиями Linux, это приложение с открытым исходным кодом разработано на Ruby. Однако существует солидная, хорошо зарекомендовавшая себя компания поддержки и спонсорства PuppetLabs, предлагающая профессиональную поддержку и коммерческую корпоративную версию программного обеспечения.
Puppet также предлагает простую процедуру установки и несколько инструментов для таких задач, как быстрое развертывание на клиентских серверах. В дополнение к GUI есть CLI на основе Ruby. На самом деле для большинства продвинутых задач вам, скорее всего, придется зависеть от CLI, причем GUI является интерфейсом просмотра, управления и мониторинга. Это означает, что в дополнение к работе системного администратора вам потребуется изучить Ruby.
Вы можете подумать: «Все это звучит здорово! Есть ли какие-то минусы, или стоит пойти и купить Puppet прямо сейчас»?… Спор вокруг использования этой SCM на специализированных форумах CM заключается в том, что Puppet, как и многие другие гиганты программного обеспечения, стала жертвой собственного успеха и размера. «Ловкий» и «проворный» — это не те слова, которые можно использовать для описания работы Puppet. Пользователи сообщают об ошибках, которые слишком долго исправляются, и игнорировании новых запросов. Существует также некоторое недовольство тем, что PuppetLabs настойчиво подталкивает своих клиентов к принятию коммерческой версии. Наконец, хотя Puppet поддерживает как чистый Ruby, так и его настроенный DSL на CLI, поддержка одного лишь Ruby является устаревшей. Это плохая новость для тех, кто изучал только Ruby, а не DSL.
Ansible обошел Puppet, захватив самую большую долю рынка в индустрии систем управления конфигурациями — 26,5%. За ним следует Microsoft System Center CM (21,8%) и Puppet (12%).
Это также продукт с открытым исходным кодом, который был выпущен в 2012 году и с тех пор поддерживается компанией-разработчиком AnsibleWorks. Он был разработан на Python, а не на Ruby, что делает его духовно ближе к Salt (еще один новый инструмент CM), чем Puppet. Другим преимуществом Python является то, что он встроен в большинство Unix и Linux — приложений, так что SCM, написанные на этом языке, устанавливаются и работают быстрее.
Уникальный маркетинговый ход Ansible состоит именно в легком и быстром развертывании. Фактически эта система даже не использует развертываемые агенты для связи с мастер-клиеном, вместо этого все функции выполняются через SSH. Для тех конфигураций, которые не поддерживают корневой SSH, Ansible может выполнять «sudo» как root. Ansible можно запускать из CLI без использования файлов конфигурации для простых задач, таких как проверка работы службы или запуск обновлений и перезагрузок. Для более сложных задач конфигурация Ansible обрабатывается с помощью синтаксиса YAML в конфигурационных файлах, называемых «playbooks». Команды Ansible могут быть написаны практически на любом языке программирования и распространены в виде универсальных модулей JSON, что явно является преимуществом по сравнению с выбором одного конкретного языка.
Ansible стал более популярным благодаря новому подходу к традиционным задачам конфигурирования, и многие компании используют его для развертывания крупных дата-центров. Сообщество энтузиастов Ansible напряженно работают на тем, чтобы развить свой успех, увеличивая количество поддерживаемых устройств, интегрируя лучшую поддержку Windows, улучшая экосистему и так далее.
Ansible против Puppet: различие в установке
Различия между Ansible или Puppet становятся очевидными с момента установки систем. Поскольку они следуют различным архитектурным парадигмам, их настройка существенно отличается. Так, Ansible преследует явную цель сделать процесс настройки как можно проще, что проявляется в пользовательском опыте.
Чтобы настроить Ansible, вначале необходимо назначить один узел в качестве узла управления control node. В действительности любой из ваших узлов может быть узлом управления. Вы можете установить Ansible на этом узле с помощью последнего пакета Ansible из репозиториев пакетов вашего дистрибутива, при этом нет никакой необходимости настраивать клиентское программное обеспечение на других узлах. Просто создайте пару ключей SSH на своем узле управления, а затем скопируйте их на остальные узлы. Далее создайте файл инвентаризации для узлов Ansible — как правило, в таких ОС Linux, как Red Hat Linux, Ubuntu и Debian это происходит в /etc/ansible/hosts. Теперь вы готовы использовать Ansible для запуска PlayBook как на вашем узле управления, так и на остальной части сетевой инфраструктуры. Ansible будет использовать SSH-соединения с вашими control node для запуска управления конфигурацией на основе PlayBook.
Настройка Puppet выглядит немного сложнее, но зато в интернете есть много документации, которая поможет в трудном случае. Во-первых, вам нужно будет настроить узлы master и agent так, чтобы они имели одинаковое время и часовой пояс. Затем вам потребуется зайти на мастер-сервер с root-правами и установить серверное программное обеспечение Puppet. Далее необходимо настроить файл Puppet-мастера /etc/hosts для подключения всех управляемых клиентов, запустить службу PuppetServer и перевести ее в режим «enable» для получения клиентских подключений на порту 8140. Поскольку Puppet опирается на программное обеспечение клиентов, вам потребуется установить программные агенты Puppet на каждом из них.
Кроме того, потребуется добавить IP-адрес мастер-сервера в /etc/hosts, чтобы клиент мог к нему подключиться. Для этого вы должны запустить и включить службу Puppet agent на каждом клиенте, после чего сгенерировать SSL-сертификаты, так как эта система CM использует HTTPS для связи мастер-клиент.
В обоих случаях будет необходимо усилить безопасность сервера, чтобы исключить возможность несанкционированных подключений.
Ansible против Puppet: масштабируемость и механизм транспортировки конфигураций
Обе SCM хорошо масштабируются, но для достижения этого используют разные механизмы транспортировки конфигураций. В действительности, независимо от того, нужно ли вам управлять несколькими сотнями или десятками тысяч узлов, существуют хитрости и стратегии, которые можно использовать на каждой платформе для удобного масштабирования до нужного уровня.
Ansible по умолчанию использует транспортный механизм «smart», который основан на доверенных сертификатах SSH. Ansible сначала проанализирует PlayBooks и определит затрагиваемые элементы инфраструктуры. Затем она откроет SSH-соединение и создаст временный каталог. После закрытия этого соединения Ansible открывает второе соединение для выполнения копирования поверх кода модуля Ansible и шаблонного кода Ansible. Ansible закроет это соединение перед открытием третьего, окончательного соединения для выполнения кода. Эта настройка будет служить большинству целей, но ее можно изменять по мере масштабирования инфраструктуры.
Первая функция, которую может использовать Ansible, называется ControlPersist, и она полагается на постоянные, сохраняемые сокеты, чтобы сократить время на обмен рукопожатиями, которые необходимы для нескольких соединений. Ansible также поддерживает «конвейеризацию» — конфигурацию, которая сокращает количество требуемых соединений с трех до одного. Наконец, Ansible можно настроить для одновременной обработки большего числа узлов инвентаризации, настроив переменную forks в конфигурации этой системы. По умолчанию это значение равно 5, но для ускорения обработки можно установить более высокое значение.
Транспортный механизм Puppet — это HTTPS, который управляется с помощью SSL-сертификатов. Один сервер Puppet обрабатывает запросы конфигурации целого списка клиентов Puppet. Каждый клиент отправляет Puppet-факты мастер-серверу вместе с запросом на каталог Puppet, после чего мастер-сервер отправляет в ответ этот каталог. Затем клиент обрабатывает каталог, сверяя каждый программный ресурс с требуемым состоянием конфигурации, указанным в каталоге. Если ресурс не находится в нужном состоянии, клиент Puppet обновит ресурс на данном компьютере и после завершения обновления отправит отчет о выполненном изменении конфигурации Puppet-серверу.
Примечательно, что модель обработки Puppet выделяет поток JRuby из пула потоков для обработки каждого входящего клиентского соединения. По мере увеличения числа узлов можно оптимизировать масштабирование Puppet, увеличив количество доступных в пуле потоков JRuby. Это можно проделать, установив значение параметра конфигурации Puppet «max-active-instances» выше, чем значение по умолчанию, которое равно 1. Как правило, это значение принимается равным количеству ядер процессора вашего компьютера, однако имейте в виду, что это потребует большего объема задействованной процессорной памяти CPU RAM. Как правило, вам также будет необходимо установить более высокий «максимальный размер кучи» для JVM вашего Puppet-сервера, чтобы гарантировать, что ваши дополнительные потоки JRuby могут быть выделены без возникновения ошибки виртуальной машины Java «out of memory». При выполнении этой настройки следует соблюдать осторожность, так как можно столкнуться с потерей производительности.
Пример кода CM Ansible
Для повседневной работы с конфигурацией написание кода Ansible удивительно просто благодаря сочетанию двух факторов: использованию формата YAML для PlayBooks и декларативному стилю управления конфигурацией, который отсекает «острые углы». Это важно для быстрого повышения производительности команд DevOps и обеспечения управляемости вашего кода даже для сложных задач конфигурации.
Код Ansible является идемпотентным. Это означает, что вы можете безопасно запускать PlayBook для компонентов системы снова и снова, не портя свои серверы. Ansible будет изменять конфигурацию программных ресурсов только на тех серверах, где она находится за пределами желаемого состояния. Например, если для вашего PlayBook требуется установить пакет и создать на диске определенный файл конфигурации, Ansible установит только этот пакет и создаст файл конфигурации, указанный при первом запуске PlayBook на узле. Последующие запуски PlayBook автоматически оставляют пакет нетронутым до тех пор, пока не произойдет какое-либо изменение, которое удалит или изменит указанную конфигурацию файла или пакета. Это содержит ваши узлы в предсказуемом, детерминированном состоянии с очень небольшим или нулевым шансом дрейфа конфигурации.
Ниже приведен пример кода Ansible PlayBook, который устанавливает на ваши узлы веб-сервер Tomcat. Этот пример взят с официального репозитория Ansible examples, который вам стоит просмотреть, чтобы лучше ознакомиться с идиоматическим стилем Ansible:
---
- name: Install Java 1.7
yum: name=java-1.7.0-openjdk state=present
- name: add group "tomcat"
group: name=tomcat
- name: add user "tomcat"
user: name=tomcat group=tomcat home=/usr/share/tomcat createhome=no
become: True
become_method: sudo
- name: Download Tomcat
get_url: url=http://archive.apache.org/dist/tomcat/tomcat-7/v7.0.61/bin/apache-tomcat-7.0.61.tar.gz dest=/opt/apache-tomcat-7.0.61.tar.gz
- name: Extract archive
command: chdir=/usr/share /bin/tar xvf /opt/apache-tomcat-7.0.61.tar.gz -C /opt/ creates=/opt/apache-tomcat-7.0.61
- name: Symlink install directory
file: src=/opt/apache-tomcat-7.0.61 path=/usr/share/tomcat state=link
- name: Change ownership of Tomcat installation
file: path=/usr/share/tomcat/ owner=tomcat group=tomcat state=directory recurse=yes
- name: Configure Tomcat server
template: src=server.xml dest=/usr/share/tomcat/conf/
notify: restart tomcat
- name: Configure Tomcat users
template: src=tomcat-users.xml dest=/usr/share/tomcat/conf/
notify: restart tomcat
- name: Install Tomcat init script
copy: src=tomcat-initscript.sh dest=/etc/init.d/tomcat mode=0755
- name: Start Tomcat
service: name=tomcat state=started enabled=yes
- name: deploy iptables rules
template: src=iptables-save dest=/etc/sysconfig/iptables
when: "ansible_os_family == 'RedHat' and ansible_distribution_major_version == '6'"
notify: restart iptables
- name: insert firewalld rule for tomcat http port
firewalld: port=/tcp permanent=true state=enabled immediate=yes
when: "ansible_os_family == 'RedHat' and ansible_distribution_major_version == '7'"
- name: insert firewalld rule for tomcat https port
firewalld: port=/tcp permanent=true state=enabled immediate=yes
when: "ansible_os_family == 'RedHat' and ansible_distribution_major_version == '7'"
- name: wait for tomcat to start
wait_for: port=
Эта конкретная задача Ansible загружает и устанавливает Apache Tomcat вместе с зависимым Java JDK 1.7, а затем настраивает, запускает и обеспечивает установку Tomcat. Как видно из данного примера, файлы, управляемые Ansible, могут содержать шаблоны Jinja, что упрощает вычисление значений и делает вашу конфигурацию более гибкой. Код YAML легко читать и писать как системным администраторам, так и разработчикам. Это приводит к тому, что Ansible становится доступной системой управления конфигурацией как для продвинутых, так и для начинающих пользователей.
Пример кода CM Puppet
Предметно-ориентированный язык Puppet основан на Ruby, но его синтаксис гораздо ближе к императивным языкам в стиле C, таким как Perl, Java и C++. Этот подход является промежуточным звеном между разработчиками, знакомыми с Ruby, и теми, кто может быть незнаком с данным языком. В результате вам может вообще не понадобится знать Ruby, чтобы изучить и продуктивно использовать Puppet DSL.
Это пример манифеста Puppet из репозитория PuppetLabs MySQL Puppet Module, который устанавливает и настраивает клиентский пакет MySQL:
# @summary
# Installs and configures the MySQL client.
#
# @example Install the MySQL client
# class {'::mysql::client':
# package_name => 'mysql-client',
# package_ensure => 'present',
# bindings_enable => true,
# }
#
# @param bindings_enable
# Whether to automatically install all bindings. Valid values are `true`, `false`. Default to `false`.
# @param install_options
# Array of install options for managed package resources. You must pass the appropriate options for the package manager.
# @param package_ensure
# Whether the MySQL package should be present, absent, or a specific version. Valid values are 'present', 'absent', or 'x.y.z'.
# @param package_manage
# Whether to manage the MySQL client package. Defaults to `true`.
# @param package_name
# The name of the MySQL client package to install.
#
class mysql::client (
$bindings_enable = $mysql::params::bindings_enable,
$install_options = undef,
$package_ensure = $mysql::params::client_package_ensure,
$package_manage = $mysql::params::client_package_manage,
$package_name = $mysql::params::client_package_name,
) inherits mysql::params {
include '::mysql::client::install'
if $bindings_enable {
class { 'mysql::bindings':
java_enable => true,
perl_enable => true,
php_enable => true,
python_enable => true,
ruby_enable => true,
}
}
# Anchor pattern workaround to avoid resources of mysql::client::install to
# "float off" outside mysql::client
anchor { 'mysql::client::start': }
-> Class['mysql::client::install']
-> anchor { 'mysql::client::end': }
}
Важным преимуществом Puppet является то, что, в отличие от перечисленных выше императивных языков программирования, Puppet DSL является декларативным, в некотором смысле похожим на XML, а также на код YAML из приведенного выше примера кода Ansible. Декларативный подход как Puppet, так и Ansible действительно прослеживается в обоих примерах кода. С точки зрения кодирования, они похожи и ближе друг другу, чем такие инструменты, как Chef. Тем не менее, декларативный язык Puppet также предоставляет Ruby-подобные конструкции, такие как условные выражения и итерации, что опять же является компромиссным решением для пользователей Ruby и тех, кто не владеет данным языком.
Ansible против Puppet: простота использования
Для команды разработчиков простота использования должна быть важной частью оценки SCM. Учитывая, что разработчики Ansible сосредотачивают массу усилий на простоте использования системы, в этом она не имеет конкурентов. Настройка, программирование и управление узлами предоставляют очень простой интерфейс как инженерам-разработчикам, так и системным администраторам.
Это не означает, что Puppet трудно пользоваться, просто эта система ведет себя уверенно, пока вы следуете предлагаемому ей способу автоматизации своей инфраструктуры. В этой области Puppet довольно сильна, явно моделируя каждый ресурс и предоставляя пользователям модули со стандартным поведением, которые эффективно использовать в ваших манифестах.
С точки зрения обучаемости пользователей обе платформы просты в использовании, но Ansible имеет небольшое преимущество. Легко добиться декларативного стиля YAML, так что код Ansible никогда не бывает слишком сложным. Тем временем Puppet пришла к осознанию некоторых проблем, связанных с объединением данных и кода в одних и тех же исходных файлах. Это привело к появлению Puppet Hiera, решения для хранения данных, которое использует формат YAML для хранения пар «ключ-значение» конфигурационных данных. Hiera проходит долгий путь к упрощению и оптимизации опыта Puppet DevOps. Формат YAML оказался довольно популярным для управления конфигурациями, причем Salt от SaltStack также использует этот формат.
Обе SCM имеют возможности для проверки и тестирования вашего СM, от проверки синтаксиса до интеграции кода «infrastructure-as-code».
Ansible против Puppet: расходы на приобретение лицензий и внедрение
Как инструменты с открытым исходным кодом, Ansible и Puppet имеют много общего в своей лицензионной политике.
Релиз Ansible с открытым исходным кодом доступен совершенно бесплатно. Компаниям, которым требуется больше гарантий безопасности, стабильности и надежности, предлагается перейти на Ansible Engine, продукт корпоративного класса, который предоставляется в Red Hat Linux. Стоимость лицензии Ansible Engine обычно составляет от $ 47,50 до $ 70 в год на узел и зависит от предпочтительной настройки.
Если вам нужна техническая поддержка с возможностью быстрого устранения неполадок, стоит использовать корпоративную версию. Инструмент управления крупным предприятием Ansible Tower доступен в виде пакета услуг и предоставляет вашей компании больше возможностей в области обучения, управления и планирования заданий с помощью панели управления с графическим интерфейсом.
Как и Ansible, релиз Puppet с открытым исходным кодом доступен бесплатно. Для получения дополнительных корпоративных функций и технической поддержки, организации могут перейти на Puppet Enterprise, стоимость которого составляет от $112 до $199 в год на 1 узел. Puppet Enterprise предлагает пакет из нескольких инструментов, включая отчетность и мониторинга состояния инфраструктуры предприятия.
Ansible против Puppet: сообщество
Puppet, выпущенный в 2005 году, является более старым инструментом DevOps, поэтому у него было больше времени для создания собственного сообщества и базы пользователей. Тем не менее, Ansible, запущенный в 2012 году, благодаря своему новому подходу, смог привлечь еще большую аудиторию и создать очень динамичное сообщество разработчиков-энтузиастов и пользователей. В число пользователей Puppet входят такие компании, как Uber, Salesforce и Paypal, а сообщество Ansible включает в себя такие компании, как Digital Ocean, 9GAG и TypeForm.
Если сравнить такой важный показатель развития продуктов open source, как число вкладчиков — участников разработки на GitHub, то Ansible с более чем 4800 вкладчиками намного превосходит Puppet с его 527 участниками разработки продукта. Развитие развития Ansible за последние годы происходило настолько стремительными темпами, что породило создание отдельного «галактического» репозитория Ansible Galaxy. Это означает, что сообщество Ansible стремиться делиться своим кодом, тем самым внося свой вклад в дальнейшее развитие продукта.
Тем временем сообщество Puppet, развивающее более медленно и стабильно, создало инфраструктуру, чтобы облегчить поиск решений для удовлетворения ваших потребностей в этой SCM. Puppet Forge предоставляет модули для выполнения общих задач управления конфигурацией для сообщества Puppet.
Обе системы имеют первоклассные инструменты для контроля жизненного цикла проекта управления конфигурацией через командную строку. И Puppet, и Ansible хорошо интегрируются с другими широко используемыми системами DevOps, такими как Docker, Kubernetes и Jenkins и облачными вычислительными платформами AWS и Azure.
Ansible против Puppet: что лучше?
В этом вопросе выбор остается только за вами. Декларативный стиль как Ansible, так и Puppet означает, что эти инструменты имеют намного больше общего, чем остальные системы управления конфигурацией. Однако, чтобы сделать оптимальный выбор, нужно обратить особое внимание на то, как потребности вашей команды сочетаются с дизайном и преимуществами конкретной SCM.
Ansible лучше подходит тем, кто интересуется конфигурацией в стиле YAML и разделяет философию Ansible — быть максимально простой, при этом достаточно быстро и параллельно управлять большим пулом машин. Кроме того, эта философия направлена на использование существующих функций SSH вместо создания пользовательских агентов.
Puppet больше подходит командам, предпочитающим DSL, который моделирует системные ресурсы последовательным, повторяющимся образом. Это именно то, что выполняет Puppet DSL вместе с целой экосистемой инструментов для того, чтобы сделать работу крупных команд предсказуемой и легкой.
Если вы точно знаете, какие принципы системы управления конфигурацией лучше всего отвечают вашим потребностям, выбор между Puppet и Ansible не составит для вас никаких проблем.
Выводы
Чтобы облегчить вам выбор, предлагаем ознакомиться с основными преимуществами и недостатками обеих систем.
Немного рекламы :)
Спасибо, что остаётесь с нами. Вам нравятся наши статьи? Хотите видеть больше интересных материалов? Поддержите нас, оформив заказ или порекомендовав знакомым, облачные VPS для разработчиков от $4.99, уникальный аналог entry-level серверов, который был придуман нами для Вас: Вся правда о VPS (KVM) E5–2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps от $19 или как правильно делить сервер? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40GB DDR4).
Dell R730xd в 2 раза дешевле в дата-центре Equinix Tier IV в Амстердаме? Только у нас 2 х Intel TetraDeca-Core Xeon 2x E5–2697v3 2.6GHz 14C 64GB DDR4 4×960GB SSD 1Gbps 100 ТВ от $199 в Нидерландах! Dell R420 — 2x E5–2430 2.2Ghz 6C 128GB DDR3 2×960GB SSD 1Gbps 100TB — от $99! Читайте о том Как построить инфраструктуру корп. класса c применением серверов Dell R730xd Е5–2650 v4 стоимостью 9000 евро за копейки?
