Puppet что это такое
Puppet, система управления конфигурациями. Часть I
Puppet — это инструмент, который позволяет автоматизировать настройку и управление большим парком машин. Используя Puppet вы сможете централизованно управлять конфигурациями одной, десятков, сотен и тысяч машин.
В этой статье я расскажу об основных особенностях системы.
Puppet написана на Ruby, архитектура — клиент-серверная. На каждом управляемом узле находится клиент, который периодически обращается по https к серверу за обновлениями конфигурации.
Язык управления конфигурациями
Конфигурация описывается на специальном языке. Базовыми элементами конфигурации являются ресурсы. Каждый ресурс имеет тип, атрибуты и название. Самый простой пример ресурса, файловый:
Этот ресурс включает проверку владельца файла /etc/passwd, и если он отличен от root, Puppet устанавливает юзера root хозяином этого файла.
Ресурсы можно (и обычно нужно) группировать в классы. Например, класс для Postfix будет содержать ресурсы и для установки и для настройки почтового сервера Postfix.
Одним из главных элементов описания конфигурации является узел (node). Узел позволяет описывать функциональность определённого типа. Скажем, можно описать узел «офисный десктоп», или «веб-сервер». Соответственно, для офисного десктопа будет установлено и настроено всё необходимое для офиса ПО, а для веб-сервера какой-нибудь апач или nginx.
Вообще, язык описания конфигурации поддерживает практически все фичи нормального ООП-языка. Так что, по сути получается, что вы как бы программируете поведение машин. Действительно, в результате получается довольно наглядное описание, которое легко читать и понимать.
Сообщество юзеров делится своими наработками, в терминах Puppet они называются «рецептами».
Следующее, что необходимо отметить, это платформонезависимость. Ваши сценарии могут разворачиваться одинаково на Linux и FreeBSD, все особенности конкретной платформы учитываются клиентом Puppet. Вы можете ознакомиться со списком поддерживаемых платформ, чтобы убедиться, что ваша любимая ОС поддерживается Puppet. Windows в этом списке нет, но сообщается, что Puppet в ней работает через cygwin.
Что касается производительности. Она и сейчас довольно неплохая. Скажем, вы можете управлять 50-100 машинами с помощью довольно средненького сервера с 2 гигами памяти. Однако, на подходе версия 0.25, в которой одной из главных фич является переход с XML-RPC на REST, что означает существенное улучшение производительности.
Кроме того, как практически любой веб-сервис, Puppet масштабируется. Puppet можно запускать с помощью nginx и Mongrel. Так что вы можете не опасаться ситуации, когда вдруг ваша организация разрастётся до больших размеров, Puppet с этой работой справится 🙂
Резюме
Завершая эту вводную статью, хочу особенно отметить тот факт, что Puppet может быть очень полезен для вас, даже если у вас всего один сервер. Имея хорошо задокументированный конфиг, в случае краха сервера вы очень быстро сможете развернуть хозяйство на другом сервере, так как установка и настройка почти всего, что нужно, будет осуществлена в автоматическом режиме.
В следующей части я опишу установку, настройку и базовые возможности Puppet.
Если вам не терпится узнать о Puppet больше прямо сейчас, милости просим в документацию 🙂
Как стать кукловодом или Puppet для начинающих
Здравствуйте. 
Этот топик открывает цикл статей по использованию системы управления конфигурацией Puppet.
Что такое система управления конфигурацией?
Предположим, что у вас есть парк серверов, выполняющих различные задачи. Пока серверов мало и вы не растёте, вы легко настраиваете каждый сервер вручную. Устанавливаете ОС (может быть, автоматизированно), добавляете пользователей, устанавливаете софт, вводя команды в консоль, настраиваете сервисы, правите конфиги ваших любимых текстовых редакторов (nanorc, vimrc), выставляете на них одинаковые настройки DNS-сервера, устанавливаете агент системы мониторинга, настраиваете syslog для централизованного сбора логов… Словом, работы довольно много и она не особенно интересна.
Я искренне верю, что хороший админ — ленивый админ. Он не любит делать что-то несколько раз. Первая мысль — написать пару скриптов, в котором будет что-то наподобие:
Вроде всё стало легко и хорошо. Нужно что-то сделать — пишем новый скрипт, запускаем. Изменения приходят на все серверы последовательно. Если скрипт хорошо отлажен — всё станет хорошо. До поры.
Теперь представьте, что серверов стало больше. Например, сотня. А изменение долгое — например, сборка чего-нибудь большого и страшного (например, ядра) из исходников. Скрипт будет выполняться сто лет, но это полбеды.
Представьте, что вам нужно сделать это только на определенной группе из этой сотни серверов. А через два дня нужно сделать другую большую задачу на другом срезе серверов. Вам придётся каждый раз переписывать скрипты и много раз проверять, нет ли в них каких-нибудь ошибок, не вызовет ли это какой-нибудь проблемы при запуске.
Самое плохое — это то, что в подобных скриптах вы описываете действия, которые необходимо выполнить для приведения системы в определенное состояние, а не само это состояние. Значит, если система изначально находилась не в том состоянии, что вы предполагали, то всё обязательно пойдет не так. Манифесты Puppet декларативно описывают необходимое состояние системы, а вычисление, как к нему прийти из текущего состояния — задача самой системы управления конфигурацией.
Для сравнения: манифест puppet, выполняющий ту же работу, что и пара скриптов из начала топика:
Если правильно использовать серверы и потратить некоторое время на первичную настройку системы управления конфигурацией, можно добиться такого состояния парка серверов, что вам не потребуется логиниться на них для выполнения работы. Все необходимые изменения будут приходить к ним автоматически.
Что такое Puppet?
Puppet — система управления конфигурацией. Архитектура — клиент-серверная, на сервере хранятся конфиги (в терминах puppet они называются манифесты), клиенты обращаются к серверу, получают их и применяют. Puppet написан на языке Ruby, сами манифесты пишутся на особом DSL, очень похожем на сам Ruby.
Первые шаги
Давайте забудем о клиентах, серверах, их взаимодействии и т.п. Пусть у нас есть только один сервер, на котором установлена голая ОС (здесь и далее я работаю в Ubuntu 12.04, для других систем действия будут несколько отличаться).
Сначала установим puppet последней версии.
Замечательно. Теперь у нас в системе установлен puppet и с ним можно играть.
Hello, world!
Создадим первый манифест:
Теперь посмотрите на содержимое файла /tmp/helloworld. В нём окажется (удивительно!) строка «Hello, world!», которую мы задали в манифесте.
Давайте по строкам разберём, что именно содержится в нашем манифесте:
В терминах Puppet здесь описан ресурс типа файл с названием (title) /tmp/helloworld.
Ресурсы
В Puppet есть возможность добавлять свои ресурсы. Поэтому если хорошенько заморочиться, можно докатиться до манифестов наподобие:
Puppet при этом будет создавать logical volume размером в 1 ГиБ на сервере, монтировать его куда положено (например в /var/www/example.com), добавлять нужные записи в fstab, создавать нужные виртуальные хосты в nginx и apache, рестартовать оба демона, добавлять в ftp и sftp пользователя example.com с паролем mySuperSecretPassWord с доступом на запись в этот виртуальный хост.
Вкусно? Не то слово!
Причем, самое вкусное, на мой взгляд — это не автоматизация рутины. Если вы например, идиот, и постоянно пересетапливаете ваши серверы в продакшне, Puppet позволит подхватить старый любовно созданный набор пакетов и конфигов с нуля в полностью автоматическом режиме. Вы просто устанавливаете Puppet-агент, подключаете его к вашему Puppet-мастеру и ждёте. Всё придёт само. На сервере волшебным (нет, правда волшебным!) образом появятся пакеты, разложатся ваши ssh-ключи, установится фаервол, придут индивидуальные настройки bash, сети, установится и настроится весь софт, который вы предусмотрительно ставили с помощью Puppet.
Кроме того, Puppet при старании позволяет получить самодокументируемую систему, ибо конфигурация (манифесты) сами же являются костяком документации. Они всегда актуальны (они же работают уже), в них нет ошибок (вы же проверяете свои настройки перед запуском), они минимально подробны (работает же).
Ещё немного магии
Многие ресурсы зависят от других ресурсов. Например, для ресурса «сервис sshd» необходим ресурс «пакет sshd» и опционально «конфиг sshd»
Посмотрим, как это реализуется:
Здесь используется инлайн-конфиг, который делает манифест некрасивым. На самом деле так почти никогда не делается, существует механизм шаблонов, основанный на ERB, и возможность просто использовать внешние файлы. Но нас не это интересует.
Самые вкусные строчки здесь — это строчки зависимостей — require и subscribe.
Puppet поддерживает много вариантов описания зависимостей. Подробно, как всегда, можно прочитать в документации.
Существуют также notify, before, но мы их здесь касаться не будем. Интересующимся — в уже упопомянутую документацию.
На текущий момент мы уже научились писать простые манифесты с указанием зависимостей между ресурсами. Очень многие простые демоны ложатся в модель «пакет-конфиг-сервис», поэтому даже в таком виде puppet уже годится для использования.
В последующих топиках будет описано, как использовать более мощные возможности puppet при создании сферического LAMP-хостинга в вакууме (если есть другие идеи сферического проекта для обучения — добро пожаловать в личку или в комментарии).
Введение в Puppet
Puppet — это система управления конфигурацией. Он используется для приведения хостов к нужному состоянию и поддержания этого состояния.
Я работаю с Puppet уже больше пяти лет. На мой взгляд, его официальная документация хороша для тех, кто уже знаком с Puppet, а для новичка она сложна — сразу даётся много новых терминов; непонятно, в каком порядке читать. Эта статья — по сути переведённая компиляция ключевых моментов из официальной документации, которая позволит новичкам быстро вникнуть в суть Puppet. Я переупорядочил информацию, чтобы постепенно рассказать про все сущности и термины.
Базовая информация
Схема работы Puppet — клиент-серверная, хотя поддерживается и вариант работы без сервера с ограниченной функциональностью.
Используется pull-модель работы: по умолчанию раз в полчаса клиенты обращаются к серверу за конфигурацией и применяют её. Если вы работали с Ansible, то там используется другая, push-модель: администратор инициирует процесс применения конфигурации, сами по себе клиенты ничего применять не будут.
При сетевом взаимодействии используется двустороннее TLS-шифрование: у сервера и клиента есть свои закрытые ключи и соответствующие им сертификаты. Обычно сервер выпускает сертификаты для клиентов, но в принципе возможно использование и внешнего CA.
Знакомство с манифестами
В терминологии Puppet к паппет-серверу подключаются ноды (nodes). Конфигурация для нод пишется в манифестах на специальном языке программирования — Puppet DSL.
Puppet DSL — декларативный язык. На нём описывается желаемое состояние ноды в виде объявления отдельных ресурсов, например:
Ресурсы могут быть взаимосвязаны:
Кроме того, в Puppet DSL есть функции и переменные, а также условные операторы и селекторы. Также поддерживаются различные механизмы шаблонизации — EPP и ERB.
Puppet написан на Ruby, поэтому многие конструкции и термины взяты оттуда. Ruby позволяет расширять Puppet — дописывать сложную логику, новые типы ресурсов, функции.
Во время работы Puppet манифесты для каждой конкретной ноды на сервере компилируются в каталог. Каталог — это список ресурсов и их взаимосвязей после вычисления значения функций, переменных и раскрытия условных операторов.
Синтаксис и кодстайл
Вот разделы официальной документации, которые помогут разобраться с синтаксисом, если приведённых примеров будет недостаточно:
Вот пример того, как выглядит манифест:
Отступы и переводы строк не являются обязательной частью манифеста, однако есть рекомендованный style guide. Краткое изложение:
Расположение файлов на паппетсервере
Для дальнейших объяснений я введу понятие «корневая директория». Корневая директория — это директория, в которой находится Puppet-конфигурация для конкретной ноды.
Корневая директория различается в зависимости от версии Puppet и использования окружений. Окружения — это независимые наборы конфигурации, которые хранятся в отдельных директориях. Обычно используются в сочетании с гитом, в таком случае окружения создаются из веток гита. Соответственно, каждая нода находится в том или ином окружении. Это настраивается на самой ноде, либо в ENC, про что я расскажу в следующей статье.
Пара боевых примеров
Описание ноды и ресурса на ней
Взаимосвязи ресурсов на ноде
На ноде server2.testdomain должен быть запущен nginx, работающий с подготовленной заранее конфигурацией.
Чтобы это работало, нужно примерно такое расположение файлов на паппет-сервере:
Типы ресурсов
Полный список поддерживаемых типов ресурсов находится в документации, здесь же я опишу пять базовых типов, которых в моей практике хватает для решения большинства задач.
Управляет файлами, директориями, симлинками, их содержимым, правами доступа.
package
Устанавливает и удаляет пакеты. Умеет обрабатывать уведомления — переустанавливает пакет, если задан параметр reinstall_on_refresh.
service
Управляет сервисами. Умеет обрабатывать уведомления — перезапускает сервис.
Запускает внешние команды. Если не указывать параметры creates, onlyif, unless или refreshonly, команда будет запускаться при каждом прогоне Паппета. Умеет обрабатывать уведомления — запускает команду.
В Puppet 6.0 cron как бы удалили из коробки в puppetserver, поэтому нет документации на общем сайте. Но он есть в коробке в puppet-agent, поэтому ставить его отдельно не надо. Документацию по нему можно посмотреть в документации к пятой версии Паппета, либо на Гитхабе.
Про ресурсы в общем
Требования к уникальности ресурсов
Самая частая ошибка, с которой мы встречаемся — Duplicate declaration. Эта ошибка возникает, когда в каталог попадают два и более ресурса одинакового типа с одинаковым названием.
Поэтому ещё раз напишу: в манифестах для одной ноды не должно быть ресурсов одинакового типа с одинаковым названием (title)!
В других типах ресурсов есть аналогичные параметры, помогающие избежать дубликации, — name у service, command у exec, и так далее.
Метапараметры
Некоторые специальные параметры есть у каждого типа ресурса, независимо от его сущности.
Полный список метапараметров в документации Puppet.
Все перечисленные метапараметры принимают либо одну ссылку на ресурс, либо массив ссылок в квадратных скобках.
Ссылки на ресурсы
Ссылка на ресурс — это просто упоминание ресурса. Используются они в основном для указания зависимостей. Ссылка на несуществующий ресурс вызовет ошибку компиляции.
Синтаксис у ссылки следующий: тип ресурса с большой буквы (если в названии типа содержатся двойные двоеточия, то с большой буквы пишется каждая часть названия между двоеточиями), дальше в квадратных скобках название ресурса (регистр названия не меняется!). Пробелов быть не должно, квадратные скобки пишутся сразу после названия типа.
Зависимости и уведомления
Как уже было сказано ранее, простые зависимости между ресурсами транзитивны. Кстати, будьте внимательны при проставлении зависимостей — можно сделать циклические зависимости, что вызовет ошибку компиляции.
В отличие от зависимостей, уведомления не транзитивны. Для уведомлений действуют следующие правила:
Обработка неуказанных параметров
Знакомство с классами, переменными и дефайнами
Для решения такой проблемы есть такая конструкция, как класс.
Классы
Класс — это именованный блок паппет-кода. Классы нужны для переиспользования кода.
Сначала класс нужно описать. Само по себе описание не добавляет никуда никакие ресурсы. Класс описывается в манифестах:
После этого класс можно использовать:
Пример из предыдущей задачи — вынесем установку и настройку nginx в класс:
Переменные
Класс из предыдущего примера совсем не гибок, потому что он всегда приносит одну и ту же конфигурацию nginx. Давайте сделаем так, чтобы путь к конфигурации стал переменным, тогда этот класс можно будет использовать для установки nginx с любой конфигурацией.
Внимание: переменные в Puppet неизменяемые!
Пример работы с переменными:
В Puppet есть пространства имён, а у переменных, соответственно, есть область видимости: переменная с одним и тем же именем может быть определена в разных пространствах имён. При разрешении значения переменной переменная ищется в текущем неймспейсе, потом в объемлющем, и так далее.
Примеры пространства имён:
Чтобы избежать неоднозначности при обращении к переменной, можно указывать пространство имён в имени переменной:
Однако приведённый пример плох тем, что есть некое «тайное знание» о том, что где-то внутри класса использует переменная с таким-то именем. Гораздо более правильно сделать это знание общим — у классов могут быть параметры.
Параметры класса — это переменные в пространстве имён класса, они задаются в заголовке класса и могут быть использованы как обычные переменные в теле класса. Значения параметров указывается при использовании класса в манифесте.
Параметру можно задать значение по умолчанию. Если у параметра нет значения по умолчанию и значение не задано при использовании, это вызовет ошибку компиляции.
В Puppet переменные типизированы. Есть много типов данных. Типы данных обычно используются для валидации значений параметров, передаваемых в классы и дефайны. Если переданный параметр не соответствует указанному типу, произойдёт ошибка компиляции.
Тип пишется непосредственно перед именем параметра:
Классы: include classname vs class
Каждый класс является ресурсом типа class. Как и в случае с любыми другими типами ресурсов, на одной ноде не может присутствовать два экземпляра одного и того же класса.
Если попробовать добавить класс на одну и ту же ноду два раза с помощью class < 'classname':>(без разницы, с разными или с одинаковыми параметрами), будет ошибка компиляции. Зато в случае использования класса в стиле ресурса можно тут же в манифесте явно задать все его параметры.
Дефайны
Как было сказано в предыдущем блоке, один и тот же класс не может присутствовать на ноде более одного раза. Однако в некоторых случаях нужно иметь возможность применять один и тот же блок кода с разными параметрами на одной ноде. Иными словами, есть потребность в собственном типе ресурса.
Например, для того, чтобы установить модуль PHP, мы в Авито делаем следующее:
Упрощённый пример с модулем для PHP:
В дефайне проще всего поймать ошибку Duplicate declaration. Это происходит, если в дефайне есть ресурс с константным именем, и на какой-то ноде два и более экземпляра этого дефайна.
Зависимости и уведомления для классов и дефайнов
Классы и дефайны добавляют следующие правила к обработке зависимостей и уведомлений:
Условные операторы и селекторы
unless
unless — это if наоборот: блок кода будет выполнен, если выражение ложно.
Тут тоже ничего сложного. В качестве значений можно использовать обычные значения (строки, числа и так далее), регулярные выражения, а также типы данных.
Селекторы
Модули
Когда конфигурация маленькая, её легко можно держать в одном манифесте. Но чем больше конфигурации мы описываем, тем больше классов и нод становится в манифесте, он разрастается, с ним становится неудобно работать.
Кроме того, есть проблема переиспользования кода — когда весь код в одном манифесте, сложно этим кодом делиться с другими. Для решения этих двух проблем в Puppet есть такая сущность, как модули.
Модули — это наборы классов, дефайнов и прочих Puppet-сущностей, вынесенных в отдельную директорию. Иными словами, модуль — это независимый кусок Puppet-логики. Например, может быть модуль для работы с nginx, и в нём будет то и только то, что нужно для работы с nginx, а может быть модуль для работы с PHP, и так далее.
Модули версионируются, также поддерживаются зависимости модулей друг от друга. Есть открытый репозиторий модулей — Puppet Forge.
На паппет-сервере модули лежат в поддиректории modules корневой директории. Внутри каждого модуля стандартная схема директорий — manifests, files, templates, lib и так далее.
Структура файлов в модуле
В корне модуля могут быть следующие директории с говорящими названиями:
Это не полный список директорий и файлов, но для этой статьи пока достаточно.
Названия ресурсов и имена файлов в модуле
Ресурсы (классы, дефайны) в модуле нельзя называть как угодно. Кроме того, есть прямое соответствие между названием ресурса и именем файла, в котором Puppet будет искать описание этого ресурса. Если нарушать правила именования, то Puppet просто не найдёт описание ресурсов, и получится ошибка компиляции.
Шаблоны
Наверняка вы и сами знаете, что такое шаблоны, не буду расписывать здесь подробно. Но на всякий случай оставлю ссылку на Википедию.
Кроме того, есть функция inline_template — ей на вход передаётся текст шаблона, а не имя файла.
Внутри шаблонов можно использовать все переменные Puppet в текущей области видимости.
Puppet поддерживает шаблоны в формате ERB и EPP:
Вкратце про ERB
Выражения в ERB пишутся на Ruby (собственно, ERB — это Embedded Ruby).
Пример использования шаблона
Предположим, я пишу модуль для управления ZooKeeper. Класс, отвечающий за создание конфига, выглядит примерно так:
А соответствующий ему шаблон zoo.cfg.erb — так:
Факты и встроенные переменные
Зачастую конкретная часть конфигурации зависит от того, что в данный момент происходит на ноде. Например, в зависимости от того, какой релиз Debian стоит, нужно установить ту или иную версию пакета. Можно следить за этим всем вручную, переписывая манифесты в случае изменения нод. Но это несерьёзный подход, автоматизация гораздо лучше.
Для получения информации о нодах в Puppet есть такой механизм, как факты. Факты — это информация о ноде, доступная в манифестах в виде обычных переменных в глобальном пространстве имён. Например, имя хоста, версия операционной системы, архитектура процессора, список пользователей, список сетевых интерфейсов и их адресов, и многое, многое другое. Факты доступны в манифестах и шаблонах как обычные переменные.
Пример работы с фактами:
Если говорить формально, то у факта есть имя (строка) и значение (доступны различные типы: строки, массивы, словари). Есть набор встроенных фактов. Также можно писать собственные. Сборщики фактов описываются как функции на Ruby, либо как исполняемые файлы. Также факты могут быть представлены в виде текстовых файлов с данными на нодах.
Во время работы паппет-агент сначала копирует с паппетсервера на ноду все доступные сборщики фактов, после чего запускает их и отправляет на сервер собранные факты; уже после этого сервер начинает компиляцию каталога.
Факты в виде исполняемых файлов
Не забывайте, что факты распространяются на все ноды, которые находятся под управлением паппет-сервера, на который выкатывается ваш модуль. Поэтому в скрипте озаботьтесь проверкой того, что в системе есть все необходимые для работы вашего факта программы и файлы.
Факты на Ruby
Текстовые факты
Такие факты кладутся на ноды в директорию /etc/facter/facts.d в старом Паппете или /etc/puppetlabs/facts.d в новом Паппете.
Обращение к фактам
Обратиться к фактам можно двумя способами:
Встроенные переменные
Кроме фактов, есть ещё некоторые переменные, доступные в глобальном пространстве имён.
Дополнение 1: как это всё запускать и дебажить?
В статье было много примеров puppet-кода, но совсем не было рассказано, как же этот код запускать. Что ж, исправляюсь.
Для работы Puppet достаточно агента, но для большинства случаев нужен будет и сервер.
Агент
Как минимум с пятой версии пакеты puppet-agent из официального репозитория Puppetlabs содержат в себе все зависимости (ruby и соответствующие gem’ы), поэтому сложностей с установкой никаких нет (говорю про Debian-based дистрибутивы — RPM-based дистрибутивами мы не пользуемся).
В простейшем случае для применения puppet-конфигурации достаточно запустить агент в беcсерверном режиме: при условии, что puppet-код скопирован на ноду, запускаете puppet apply :
Лучше, конечно, поднять сервер и запустить агенты на нодах в режиме демона — тогда раз в полчаса они будут применять конфигурацию, скачанную с сервера.
Сервер
Полноценную настройку паппетсервера и деплой на него кода в этой статье я не буду рассматривать, скажу лишь, что из коробки ставится вполне работоспособная версия сервера, не требующая дополнительной настройки для работы в условиях небольшого количества нод (скажем, до ста). Большее количество нод уже потребует тюнинга — по умолчанию puppetserver запускает не больше четырёх воркеров, для большей производительности нужно увеличить их число и не забыть увеличить лимиты памяти, иначе большую часть времени сервер будет garbage collect’ить.
Деплой кода — если нужно быстро и просто, то смотрите (на r10k)[https://github.com/puppetlabs/r10k], для небольших инсталляций его вполне должно хватить.
Дополнение 2: рекомендации по написанию кода
А почему я рекомендую так делать — объясню в следующей статье.
Заключение
На этом закончим со введением. В следующей статье расскажу про Hiera, ENC и PuppetDB.