для чего используется инструмент ansible
Используем Ansible для развертывания системы и программ. Колонка Ильи Русанена
Содержание статьи
Для кого?
Цель этого материала — показать основные приемы работы с Ansible для решения простой и понятной задачи. Рассказать о промышленном использовании Ansible для развертывания инфраструктуры в рамках этой заметки, разумеется, невозможно. Но уверен, после прочтения ты придумаешь, как подстроить этот замечательный инструмент под свой workflow. Или как минимум обратишь на него внимание, если раньше обходил стороной.
Зачем нужна оркестрация локальной машины?
Давай для начала определимся, зачем мы хотим управлять своим компьютером с помощью оркестратора. Под оркестрацией твоего компьютера мы будем понимать:
и так далее. В рамках этой статьи мы научимся автоматизировать действия, которые нужно совершить от установки базовой системы до получения готового к работе компьютера.
Зачем это может потребоваться? Несмотря на то что большинство людей годами не переустанавливают систему, причин дисциплинированно держать свои конфиги в порядке может быть масса. Для себя я выделил следующие.
Воспроизводимость
Мне важно иметь возможность быстро поднять привычную рабочую среду на новой машине. Ситуации бывают разные:
В подобных случаях часто приходится раскатывать ОС с нуля, ставить весь необходимый софт и, что самое неприятное, мучительно вспоминать все пляски с бубном, которые устраивал при предыдущей настройке ОС. Поясню: в моем случае это установка Arch Linux (сама по себе довольно муторная), допиливание оконного менеджера i3, донастройка железа (вплоть до чувствительности BT-мыши), стандартная ерунда вроде локалей, шрифтов, systemd-юнитов и shell-скриптов. И все это без учета установки и настройки непосредственно рабочего софта.
Ничего страшного в этой процедуре нет, но она занимает почти день. При этом все равно что-то забудешь и вспомнишь об этом, только когда выяснится, что оно не работает, не настроено или не установлено.
Предсказуемость
Очень полезно знать, что в системе установлено и как настроено. Когда конфиг перед глазами, быстрее понимаешь, почему ОС так работает (или не работает).
Если не представляешь четко, что, как и когда ты сконфигурировал в системе (а в Linux невозможно запомнить все даже с опорой на ArchWiki), ты вскоре обнаружишь, что также не понимаешь, почему эта программа сейчас работает так, хотя раньше работала иначе. Возможно, ты ставил какой-то плагин или что-то исправлял в конфиге, но забыл?
Имея под рукой полное описание всех настроек в одном месте, ты с меньшей вероятностью столкнешься с этими проблемами.
Декларативность и поддерживаемость
Декларативный подход к конфигурированию (читай: описание, как должно быть, а не что нужно сделать) значительно упрощает понимание настроек. Вносить необходимые изменения в них становится куда проще, а вот свои костыли поддерживать в итоге сложнее, чем стороннее, но проверенное решение.
Пример наивного «инсталлятора» пакетов в одном из моих скриптов. И это только одна функция
Кстати, если ты тоже без ума от декларативного подхода к описанию ОС, обрати внимание на дистрибутив NixOS.
Другие решения?
Разумеется, для быстрого развертывания можно приспособить и другие инструменты, например системы образов вроде эппловской Time Machine или Norton Ghost. Можно подойти и более радикально: запускать софт в контейнерах Docker или даже виртуалках в AppVM. Проблема в том, что сложно их поддерживать, управлять ими и обновлять софт на регулярной основе. Другими словами, они созданы для решения несколько других задач и не так бесшовно встраиваются в повседневную жизнь, если это не твоя работа 24/7.
Как нам поможет Ansible
Ansible — это система оркестрации. Она написана на Python, присутствует в популярных дистрибутивах и не требует клиента на целевых машинах. Инструмент активно развивается, под него существует много плагинов. Он достаточно новый, но уже популярен наряду с Puppet и Chef.
Для работы с Ansible достаточно передать скрипт (сценарий, конфиг) с перечислением действий, который он должен выполнить на целевой машине. Давай посмотрим, как писать эти конфиги.
Конфиг Ansible называется playbook. Он описывается на языке YAML. Ключевой объект конфига — задача. Это массив (список) вложенных блоков-задач, каждая из которых описывает одно действие. Задачи могут быть атомарны, а могут, в свою очередь, содержать блок подзадач. И так далее, выстраивая дерево подзадач. Примеры задач:
Задач может быть сколько угодно, и Ansible пройдется по всем и выполнит каждую по очереди. Посмотри на пример простого конфига — он описан в одном файле (часть блоков свернута для наглядности). Конечно, большие боевые конфиги удобно разделять на несколько файлов и тегировать, но для наших задач хватит и одной простыни. 🙂
Пример простого конфига для развертывания локального рабочего окружения. Обрати внимание на список задач
У каждой задачи есть свои параметры (например, список пакетов, которые нужно поставить, или пути к файлам, которые нужно скопировать). Подробнее о том, как писать задачи различных типов, ниже.
Пробуем Ansible
Что нужно для работы Ansible?
Linux, Python и в некоторых случаях SSH. Сразу оговорим термины:
Строго говоря, в отличие от других систем оркестрации, устанавливать Ansible на целевом хосте не обязательно. Если у тебя есть еще один компьютер (я проделывал это, например, с Raspberry Pi 3), Ansible нужно иметь именно на нем.
Только что установленный Arch Linux с Python и Ansible через pip. Больше ничего не нужно
Перечисляем хосты и запускаем playbook
С этого момента договоримся, что мы не разделяем master- и target-машины, все действия выполняем на одной машине. Для удаленных хостов процедура будет почти такая же.
Здесь необходимо пояснение. Обычно при работе с удаленными хостами Ansible соединяется с ними по SSH и выполняет определенные в скрипте операции. Однако, поскольку мы выполняем действия над «самим собой», было бы излишне поднимать sshd-демон, чтобы законнектиться к самому себе. Для таких случаев Ansible позволяет указать дополнительный параметр ansible_connection, который определит тип соединения. В нашем случае это local.
Попробуем пропинговать хосты на отклик (в нашем случае единственный хост):
Ответ по localhost — работает.
Собираем свой playbook
Мы уже знаем, что по большей части playbook — это набор задач разной степени вложенности. Теперь научимся писать эти задачи.
Главное, что нужно усвоить, — для выполнения каждой задачи требуется использовать модуль. Модуль — это actor, который может совершать действия определенного типа. К примеру:
Для каждой задачи передаем модуль и набор параметров его запуска, например список пакетов для установки. Модулей очень много, с их полным списком ты можешь ознакомиться здесь. А пока пройдемся по тем, которые нам понадобятся.
1. Обновление системы и установка пакетов
Для обновления системы и установки базовых пакетов программ напишем пару тасков с использованием модуля pacman. Вот пример подобной задачи:
Здесь мы определили две задачи: в первой обновляем систему, во второй передаем модулю pacman список пакетов, которые нужно установить, и инструкцией become сообщаем, что надо поднять привилегии до суперпользователя.
Обрати внимание на блочный конфиг задачи install zsh: это удобный (но необязательный) способ записи для группировки нескольких действий, не требующих выноса в отдельные (под)задачи.
Для установки из AUR можно использовать и yaourt (правда, сейчас его уже подвинул новый yay). Поскольку устанавливать из AUR под рутом нельзя, а мы определили повышение привилегий в корневой задаче, создадим отдельного юзера aur_builder и будем переходить под него в задачах установки из AUR:
Теперь при установке пакетов мы можем включить блок установки из AUR:
Продолжение доступно только участникам
Вариант 1. Присоединись к сообществу «Xakep.ru», чтобы читать все материалы на сайте
Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», позволит скачивать выпуски в PDF, отключит рекламу на сайте и увеличит личную накопительную скидку! Подробнее
Вариант 2. Открой один материал
Заинтересовала статья, но нет возможности стать членом клуба «Xakep.ru»? Тогда этот вариант для тебя! Обрати внимание: этот способ подходит только для статей, опубликованных более двух месяцев назад.
Илья Русанен
Главный редактор ][, занимаюсь разработкой и безопасностью
Система управления конфигурацией Ansible
Представьте себе, что вам нужно управлять парком серверов, расположенных к тому же в разных географических точках. Каждый из этих серверов требует настройки, регулярного обновления и мониторинга. Конечно, для решения этих задач можно воспользоваться самым простым способом: подключиться к каждому серверу по ssh и внести необходимые изменения. При всей своей простоте этот способ сопряжен с некоторыми трудностями: он чрезвычайно трудоемок, а на выполнение однообразных операций уходит очень много времени.
Чтобы упростить процессы настройки и конфигурирования серверов, можно также писать shell-скрипты. Но и этот способ вряд ли можно назвать совершенным. Скрипты нужно постоянно изменять, подстраивая их под каждую новую задачу. При их написании необходимо учитывать различие операционных систем и версий. Не будем забывать и о том, что отладка скриптов отнимает много усилий и забирает немало времени.
Оптимальным вариантом решения описанных проблем является внедрение системы удаленного управления конфигурацией. В таких системах достаточно лишь описать нужное состояние управляемого узла. Система должна сама определить, что нужно сделать для достижения этого состояния, и осуществит все необходимые действия.
Со всеми сложностями, о которых идет речь выше, мы хорошо знакомы на собственном опыте: у нас имеется 10 точек присутствия с NS-серверами, расположенные в разных точках планеты. На них необходимо регулярно вносить различные изменения: обновлять операционную систему, устанавливать и обновлять различное ПО, изменять конфигурцию и т.п. Мы решили все эти операции автоматизировать и внедрить систему удаленного управления конфигурациями. Изучив имеющиеся решения, мы остановили свой выбор на Ansible.
В этой статье мы бы хотели подробно рассказать о его возможностях этого инструмента управления конфигурациями и поделиться собственным опытом его использования.
Что такое Ansible?
Ansible — опенсорсное программное решение для удаленного управления конфигурациями, разработанное Майклом Де Хаанном в 2012 году. Название продукта взято из научно-фантастической литературы: в романах американской писательницы Урсулы Ле Гуин ансиблом называется устройство для оперативной космической связи.
Ansible берет на себя всю работу по приведению удаленных серверов в необходимое состояние. Администратору необходимо лишь описать, как достичь этого состояния с помощью так называемых сценариев (playbooks; это аналог рецептов в Chef). Такая технология позволяет очень быстро осуществлять переконфигурирование системы: достаточно всего лишь добавить несколько новых строк в сценарий.
Почему Ansible?
Преимущества Ansible по сравнению с другими аналогичными решениями (здесь в первую очередь следует назвать такие продукты, как Puppet, Chef и Salt) заключаются в следующем:
Push или pull?
“Из коробки” все сценарии и команды выполняются методом push: когда возникает необходимость, мы запускаем сценарий, и он последовательно выполняется на удалённых серверах. Однако разработчики также предусмотрели метод pull и даже написали специальное приложение для установки необходимой для этого части ansible на удалённые хосты.
Установка
Требования для установки Ansible минимальны. На машине с которой производится управление должен быть установлен Python 2.6 или выше. На управляемых узлах должен быть установлен только Python версии не ниже 2.4, но он, как правило, по умолчанию включен в состав большинства дистрибутивов linux-систем. MS Windows не поддерживается.
Вам также могут потребоваться следующие модули Python, устанавливаемые через pip или пакетный менеджер вашей операционной системы:
В Ubuntu установка самого Ansible и зависимостей осуществляется добавлением репозитория и установкой пакета:
Группы серверов
Список групп серверов, которыми нужно управлять, Ansible может получать двумя основными способами:
Файл hosts
Помимо списка управляемых узлов, в файле hosts могут быть указаны и другие сведения, необходимые для работы: номера портов для подключения по SSH, способ подключения, пароль для подключения по SSH, имя пользователя, объединения групп и т.п. В некоторых случаях — в частности, при работе с большими и сложными конфигурациями, — различные параметры можно выносить в отдельные файлы и каталоги (о структуре каталогов см. ниже).
Информация об узлах (Facts)
Перед внесением изменений Ansible подключается к управляемым узлам и собирает информацию о них: о сетевых интерфейсах и их состоянии, об установленной операционной системе и т.п. Он может делать это как с помощью собственного модуля, так и с помощью инструментов ohai и facter, если они установлены (такая возможность специально предусмотрена для пользователей, уже имеющих опыт работы с системами удаленного управления конфигурациями: ohai и facter являются библиотеками фактов для Chef и Puppet).
Переменные
Во время деплоя, как правило, требуется не только установить какое-либо приложение, но и настроить его в соответствии с определенными параметрами на основании принадлежности к группе серверов или индивидуально (например, ip-адрес BGP-соседа и номер его AS или параметры для базы данных). Как уже было сказано, загромождать файл hosts будет не очень красиво, поэтому разработчики Ansible пошли следующим путём:
Помимо пользовательских переменных можно (и даже нужно) использовать факты, собранные ansible перед выполнением сценариев и отдельных задач.
Модули Ansible
В состав Ansible входит огромное количество модулей для развёртывания, контроля и управления различными компонентами, которые можно условно разделить на следующие группы (в скобках приведены названия некоторых продуктов и сервисов):
Примеры простых задач
С помощью Ansible можно одновременно выполнить одну задачу на целой группе серверов. Попробуем, например, отправить запрос ping на серверы выбранной группы:
Следующий пример соберёт информацию о хостах и выведёт её на консоль в формате JSON:
А вот так можно создать логический том (или, в зависимости от текущего состояния, изменить его размер) с именем examplevolume в группе examplegroup:
Ansible позволяет не только выполнять единичные задачи, но и писать сценарии, которые необходимо выполнить на управляемых узлах. Рассмотрим структуру и правила написания таких сценариев более подробно.
Cценарии (playbooks)
Все сценарии в Ansible пишутся на YAML. Это — человекочитаемый формат сериализованных данных, гораздо более простой, чем XML или JSON.
Чтобы выполнить сценарий используется команда ansible-playbook со следующим сиснтаксисом:
В начале сценария обязательно должна присутствовать последовательность символов «–––» (так в YAML обозначается начало документа). Перед каждым новым разделом списка ставится дефис ( – ):
Основными параметрами/группами простого сценария являются:
Также в сценарии перед непосредственным описанием задач могут быть указаны следующие параметры или группы параметров:
Рассмотрим все эти разделы более подробно.
В разделе hosts указывается группа управляемых узлов, к которой будут применены описываемые в сценарии изменения.
Так, строка формата:
означает, что изменения будут применены к узлам из группы webservers.
Сценарии могут выполняться не только от имени пользователя, под именем которого установлено соедиение, но и любого другого. В следующем примере авторизация на хосте будет произведена с именем yourname, но задачи будут выполняться от имени пользователя root (если, конечно, этому пользователю это разрешено):
Если добавить параметр “user: postgres”, то все действия будут выполняться с привилегиями пользователя postgres.
В разделе vars указываются переменные, которые будут использованы в сценарии, и их значения:
Список изменений, которые необходимо произвести на управляемом узле, приводится в разделе tasks. Каждой задаче (task) присваивается имя (name). Далее указываются модули Ansible, которые будут задействованы при ее выполнении:
Для каждой задачи можно указывать пользователя, от имени которого она будет выполнена:
Шаблонизация
В приведённом примере мы подставляем в шаблон следующие значения:
Обработку шаблонов и, в данном случае, генерацию конфигурационного файла выполняет модуль template ; он же может задать необходимые права доступа и изменить владельца/группу:
Обратим внимание на то, что файл шаблона и файл с паролем пользователя базы данных находятся на машине управления, а результатом будет файл на удалённом узле.
Обработчики событий (Handlers)
Ansible не просто выполняет задачи в указанном порядке, но и проверяет их состояние на наличие изменений. Если при выполнении сценария требовалось, например, добавить строку в конфигурационный файл, и в результате выполнения он изменился (необходимой строки действительно не было), то Ansible может выполнить специальную задачу, описанную как обработчик события (handler). Если при выполнении строка уже была в конфигурационном файле, то обработчик выполнен не будет. Обработчики событий описываются в конце сценария; в описании задачи они указываются через параметр notify. Приведём пример:
Контроль выполнения
Допустим, что при выполнении сценария нам нужно проверять определённые переменные или состояния и, в зависимости от них, выполнять или не выполнять какие-либо задачи. Для этого можно использовать оператор “when”:
Делегирование задачи другому хосту
Иногда требуется выполнить задачу на определённом узле, но в контексте другого узла. Например, во время обновления узла может возникнуть необходимость отключить для него мониторинг, находящийся на отдельном сервере. Для этого используется управляющая директива delegate_to. Приведём пример:
Результатом выполнения этой задачи будет отключение сообщений для сервиса dnsserver в Nagios.
Ролью называется типовой набор переменных и задач, назначаемых для одного или нескольких серверов. Если вам нужно применить к серверу или группе серверов типовой набор операций, вам достаточно просто назначить ему роль. Предварительно в проекте каталоге проекта должна быть создана соответствующая структура. В сценариях роли назначаются следующим образом:
Структура проекта
Пример сценария
Чтобы понять, как это все работает, рассмотрим практический пример: простой сценарий развёртывания новой версии PostgreSQL 9.3 на debian-based ОС. Роли в этом примере не используются.
Ansible AWX
Заключение
Ansible — достаточно простой, но при этом эффективный инструмент для удаленного управления конфигурациями. В рамках этой статьи мы сделали лишь беглый обзор его возможностей и рассказали, как пишутся сценарии для решения простых задач. Все возможности и варианты использования Ansible в рамках одной статьи охватить невозможно. О применении этого инструмента для решения более специфических задач мы расскажем в последующих публикациях.
Для желающих узнать больше — несколько ссылок:
Ansible против Puppet
Ansible и Puppet представляют собой системы управления конфигурациями (SCM), необходимые для построения повторяющихся инфраструктур.
Ansible отличается простотой использования, имеет безагентную архитектуру (не требует установки агента/клиента на целевую систему) и YAML-подобный DSL, написана на Python и легко расширяется за счет модулей. Обычно управляет конфигурацией Linux.
Puppet имеет клиент-серверную архитектуру (периодически опрашивает сервер, чтобы внести в конфигурацию изменения, внесенные администратором сети), написана на Ruby и имеет Ruby-подобный DSL. Это приложение позволяет централизованно управлять конфигурацией ПО, установленного на нескольких компьютерах.
В статье проводится сравнение преимуществ и недостатков этих SCM.
По сравнению с 90-ми годами, в наше время системным администраторам и разработчикам приходится управлять значительно большим количеством серверов, на которых размещается намного больше приложений. Причина этого состоит в экспоненциальном росте вычислений для организаций и компаний, связанным с появлением таких новых технологий, как виртуализация и облачные вычисления.
Таким образом, такие инструменты, как Puppet и Ansible, быстро становятся необходимыми компонентами управления большим количеством серверов, например, в дата-центрах. Их называют средствами управления конфигурацией (CM) и удаленного выполнения (RE) и часто используют с инструментами обновления ПО. Эти полезнейшие приложения позволяют, например, сетевому администратору выполнять действия на нескольких серверах одновременно, развертывать несколько приложений одним щелчком мыши, что значительно упрощают настройку и обслуживание десятков, сотен или даже тысяч серверов.
Ansible против Puppet: краткий обзор
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:
Эта конкретная задача 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:
Важным преимуществом 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 Tower доступен в виде пакета услуг и предоставляет вашей компании больше возможностей в области обучения, управления и планирования заданий с помощью панели управления с графическим интерфейсом.
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 не составит для вас никаких проблем.
Выводы
Чтобы облегчить вам выбор, предлагаем ознакомиться с основными преимуществами и недостатками обеих систем.
