Сравнение систем автоматизации

На этой странице сравниваются системы автоматизации, охватываемые данной частью базы знаний MariaDB. Более подробная информация о системах представлена на соответствующих страницах, и в будущем могут быть добавлены и другие системы.

Отличия в структуре кода

Разные системы автоматизации предоставляют различные способы описания нашей инфраструктуры. Понимание их работы является первым шагом для оценки и выбора одной из них для нашей организации.

Структура кода Ansible

Код Ansible состоит из следующих компонентов:

• Инвентарь определяет, к каким хостам Ansible должен иметь доступ для развертывания. Каждый хост может принадлежать одному или нескольким группам. Группы могут иметь подгруппы, образуя иерархию. Это полезно, так как позволяет развертывать на группе или назначать переменные группе.
• Роль описывает состояние, которого хост или группа хостов должны достичь после развертывания.
• Игра (play) связывает хосты или группы с их ролями. Каждая роль/группа может иметь более одной роли.
• Роль состоит из списка задач (tasks). Несмотря на название, задача не обязательно что-то делать, но что-то, что должно существовать в определённом состоянии.
• Задачи могут использовать переменные. Они могут влиять на выполнение задачи (например, имя файла), или даже на то, выполняется ли задача вообще. Переменные существуют на уровне роли, группы или хоста. Переменные также могут быть переданы пользователем при применении игры.
• Плейбуки — это код, используемый для определения задач и переменных.
• Факты — данные, которые Ansible извлекает с удалённых хостов перед развертыванием. Это очень важный шаг, потому что факты могут определять, какие задачи выполняются или как они выполняются. Факты включают, например, семейство операционной системы или её версию. Плейбук воспринимает факты как предопределённые переменные.
• Модули реализуют действия, которые могут использовать задачи. Примеры действий — file (для объявления того, что файлы и каталоги должны существовать) или mysql_variables (для объявления переменных MySQL/MariaDB, которые необходимо установить).

Для получения более подробной информации и примера см. Обзор Ansible — концепции.

Структура кода Puppet

Код Puppet состоит из следующих компонентов:

• Файл инвентаризации определяет набор групп и их целей (членов группы). Плагины могут использоваться для динамического получения групп и целей, поэтому они эквивалентны динамическим инвентарям Ansible.
• Манифест — файл, описывающий конфигурацию.
• Ресурс — компонент, который должен работать на сервере. Например, «file» и «service» — это существующие типы поддержки.
• Атрибут относится к ресурсу и влияет на способ его применения. Например, ресурс типа «file» может иметь атрибуты, такие как «владелец» и «режим».
• Класс группирует ресурсы и переменные, описывая логическую часть конфигурации сервера. Один класс может быть связан с несколькими серверами. Класс является частью манифеста.
• Модуль — набор манифестов и описывает инфраструктуру или её часть.
• Классы могут иметь типизированные параметры, которые влияют на способ их применения.
• Свойства — переменные, которые считываются с удалённого сервера и не могут быть произвольно назначены.
• Факты — предопределённые переменные, собранные Puppet перед применением или компиляцией манифеста.

Архитектурные различия

Архитектура различных систем отличается. Их архитектура определяет, как физически происходит развертывание и что для этого требуется.

Архитектура Ansible

Архитектура Ansible простая. Ansible может запускаться с любого хоста и применять свои плейбуки на удалённых хостах. Для этого он выполняет команды через SSH. На практике в большинстве случаев команды будут выполняться от имени суперпользователя через sudo, хотя это не всегда необходимо.

Инвентаризация может быть динамической. В этом случае при применении плейбука Ansible подключается к удалённым службам для обнаружения хостов.

Плейбуки Ansible применяются с помощью двоичного файла ansible-playbook. Изменения в плейбуках применяются только при выполнении этой операции.

Подводя итог, Ansible не нужно устанавливать на управляемый сервер. Ему нужен доступ по SSH, и обычно его пользователю нужно иметь возможность запуска sudo. Также возможно настроить динамический инвентарь и использовать удалённую службу для этой цели.

Архитектура Puppet

Puppet поддерживает два типа архитектуры: агент-мастер или автономный. Архитектура агент-мастер рекомендуется Puppet Labs и является наиболее популярной среди пользователей Puppet. По этой причине те, кто предпочитает автономную архитектуру, склонны предпочесть Ansible.

Архитектура агент-мастер

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

Необязательным компонентом является PuppetDB. Это централизованное хранилище некоторых данных, включая манифесты, извлечённые факты и журналы. PuppetDB основана на PostgreSQL, и нет планов по поддержке MariaDB или других СУБД.

Если внесены ручные изменения на удалённый сервер, они, скорее всего, будут перезаписаны при следующем запуске агента Puppet. Чтобы этого избежать, можно остановить службу агента Puppet.

Автономная архитектура

Как уже упоминалось, эта архитектура не рекомендуется Puppet Labs и не является популярной среди пользователей Puppet. Она похожа на архитектуру Ansible.

Пользователи могут применять манифесты с любого хоста с установленным Puppet. Это может быть их ноутбук, но, чтобы эмулировать поведение архитектуры агент-мастер, обычно Puppet запускается на выделенном узле как задача cron. Приложение Puppet apply потребует фактов с удалённых хостов, оно скомпилирует каталог для каждого хоста, проверит, какие его части нужно применить, и применит их удалённо.

Если внесены ручные изменения на удалённый сервер, они будут перезаписаны при следующем запуске Puppet apply. Чтобы этого избежать, можно закомментировать задачу cron, выполняющую Puppet apply, или закомментировать целевой сервер в инвентаре.

Инвентарь

Как уже упоминалось, Puppet поддерживает плагины для динамического получения инвентаризации с удалённых служб. В архитектуре агент-мастер нужно убедиться, что каждый целевой хост имеет доступ к этим службам. В автономной архитектуре нужно убедиться, что хосты, на которых запускается Puppet apply, имеют доступ к этим службам.

Хранение секретов

Часто в наших репозиториях автоматизации необходимо хранить секреты, такие как пароли пользователей MariaDB или приватные ключи для SSH-аутентификации.

Ansible и Puppet поддерживают интеграцию с хранилищами секретов, такими как Hashicorp Vault. Для интеграции с Puppet см. Интеграция с хранилищами секретов.

В простейшем случае Ansible позволяет шифровать секреты в плейбуках и расшифровывать их во время выполнения с помощью ansible-vault. Это предполагает минимальные усилия по обработке секретов. Однако это не самый безопасный способ хранения секретов. Пароли для раскрытия определённых секретов должны быть доступны пользователям, имеющим право их использовать. Также возможны атаки с применением силы.

Экосистемы и сообщества

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

Экосистема Ansible

Ansible — это открытый исходный код, выпущенный под лицензией GNU GPL. Он производится компанией RedHat. RedHat имеет страницу о партнёрах Red Hat Ansible Automation Platform, которые могут предоставить поддержку и консультации.

Ansible Galaxy — большой репозиторий ролей Ansible, созданных как поставщиком, так и сообществом. Ansible поставляется с ansible-galaxy, инструментом, который можно использовать для создания ролей и загрузки их в Ansible Galaxy.

На момент написания этой статьи Ansible не имеет официальных модулей MariaDB. Модули MySQL могут быть использованы. Однако будьте осторожны, чтобы не пытаться использовать функции, которые применимы только к MySQL. Есть несколько поддерживаемых сообществом ролей MariaDB.

Экосистема Puppet

Puppet — это открытый исходный код, выпущенный под лицензией GNU GPL. Он производится одноимённой компанией. На странице партнёров Puppet перечислены партнёры, которые могут предоставить поддержку и консультации по Puppet.

Puppet Forge — это большой репозиторий модулей, созданных поставщиком и сообществом, а также руководств по использованию.

В настоящее время Puppet имеет множество модулей MariaDB.

См. также

Для получения дополнительной информации о системах, упомянутых на этой странице, с точки зрения пользователей MariaDB:

• Ansible и MariaDB.
• Puppet и MariaDB.

Контент первоначально предоставлен компанией Vettabase Ltd.