Василий Михаленя, Minsk, Belarus

LVEE Winter 2012

The review of Puppet – open source tool for managing configurations. This presentation will describe its features, advantages, scalability, common and best practices. “SSH in a for loop is not a solution” © Luke Kanies, Puppet developer

Что такое puppet.

Puppet – клиент-серверное приложение для удобного распространения конфигураций – состоит из puppetmaster’а, сервера хранящего конфигурации, и puppet agent’а, работающего на конфигурируемом сервере. Puppet написан на ruby, распространяется под лицензией Apache и содержит возможности расширения функциональности с использованием ruby. Проект имеет ruby в качестве единственной зависимости, работает на Linux, Solaris, BSD, Mac OS X, поддерживает Microsoft Windows. Puppet можно использовать как для документирования конфигурации на одном сервере, так и для легкого управления конфигурацией парка серверов в гетерогенной среде. Puppet используют такие проекты как wikimedia, twitter, digg, sugarcrm и многие другие.

Основные примитивы языка. Puppet vs bash.

Описание конфигураций происходит на своем собственном декларативном языке. Декларативный язык позволяет описать желаемое состояние системы в зависимости от набора фактов – описание “как именно делать”, как правило, не требуется. Если применять некоторую конфигурацию на серверах с разными ОС (или, например, разными дистрибутивами Linux), используя bash скриптинг, получаем трудноподдерживаемый код. Puppet же позволяет быть уверенным не только в том, что изменения были применены единоразово ( случай shell-сценариев), но и что текущее состояние соответствует описанному. Простота языка позволяет использовать манифесты puppet как понятную документацию конфигурации систем.

К числу основных понятий языка относятся следующие:

• ресурсы – file, package, user, exec, cron и т.д.
• классы – объединения ресурсов и зависимости между ними
• модули – самостоятельные наборы классов, например, для конфигурации определенного сервиса. Модули независимы и могут распространяться отдельно.
• факты – facts – пары “ключ-значение”, которыми оперирует puppet для выбора конфигурации ( например, hostname => mars, is_virtual => false, operatingsystem => Ubuntu, processorcount => 8 ).
• ноды – nodes – соответствие имени сервера ( ноды ) и набора классов, которые будут к ней применены. Возможно хранение нод в LDAP или использование внешнего классификатора нод – произвольного скрипта.
• манифест – конфигурационный файл puppet, в котором описаны ресурсы, классы, модули или ноды

Управление парком машин от 2 до бесконечности.

Очевидно, что преимуществ от автоматизации применения конфигурации тем больше, чем больше систем и сервисов на них настраиваются с помощью puppet. Но некоторые вещи полезно автоматизировать, если имеются хотя бы 2 ноды:

• синхронизация authorized_keys
• синхронизация пользователей и/или их настроек (bashrc, vimrc …)
• синхронизация правил брандмауэра
• и т.д.

В гетерогенной среде приходится учитывать “факты” в своих конфигурациях. Деплоймент новой или вышедшей из строя ноды происходит в течение нескольких минут при достаточной степени полноты описания конфигурации. Существует огромное количество написанных модулей для практически любых сервисов (их список можно получить поиском, например, на github). Деплоймент или применение каких-либо изменений для 2 или 2000 нод практически не отличаются по трудоемкости при грамотном подходе.

Как работает puppet.

Puppet agent раз в 30 минут запрашивает конфигурацию у puppetmaster:

1. Компиляция манифеста происходит на сервере, результатом являются “базовые хеши” и никакой валидации данных.
2. Инстанциирование – конвертация “базовых хешей” и массивов, полученных при компиляции, в объекты puppet-библиотеки. Валидация входных данных происходит на данном этапе.
3. Конфигурирование – сравнение каждого описанного ресурса с реальным положением дел, и внесение соответствующих изменений при необходимости.

Также существует подход nodeless (masterless). При данном подходе, манифеста с описанием нод не существет – мастер не нужен, вся конфигурация копируется на ноду, а настройка опирается исключительно на “факты”.

Как масштабировать puppet.

До 100 нод со стандартным периодом в 30 минут могут успешно работать с единственным puppetmaster-сервером (WEBRick Ruby-based HTTP). Дальше начинаются проблемы. Выход – связка mod_passenger + apache + rack. При данной схеме возможно распределение нагрузки на несколько серверов. Часто используют подход со splay time – размазывание по времени нагрузки на мастер – при котором все ноды не должны обращаться к мастеру одновременно. Можно также использовать подход 1 мастер на площадку (сайт), с синхронизацией между площадками, например, через тот же git.

Опыт работы в команде

Опыт работы над “рецептами” puppet подсказывает использовать следующие практики:

• Использование environments – различных наборов манифестов для разработки и продакшна, когда выбор environment’a происходит на стороне клиента.
• Использование системы контроля версий – например, git. Очень удобным оказывается использование двух различных веток или репозиториев, для разработки и продакшна соответсвенно.

Текст тезисов доступен под лицензией Creative Commons Attribution-ShareAlike 3.0.

Presentation