Централизованная настройка с помощью Puppet. Централизованная настройка UNIX-систем с помощью Puppet Полный список параметров Bash скрипта инициализации клиента Puppet

Сергей Яремчук

Централизованная настройка UNIX-систем с помощью Puppet

Управление большим количеством UNIX-систем нельзя назвать удобным. Для изменения одного параметра администратору приходится обращаться к каждой машине, скрипты лишь частично могут помочь, да и не во всех ситуациях.

Следует признать, что администраторы Windows-сетей находятся все-таки в более выгодном положении. Достаточно изменить настройки групповых политик, и через некоторое время все компьютеры сети, в том числе и с недавно установленной операционной системой, «узнают» о нововведении, если они их, конечно, касаются. Оглянувшись на долгий период развития UNIX, можно заметить, что ничего подобного так и не прижилось. Есть решения вроде kickstart, которые помогают при первичной установке операционной системы, но дальнейшая доводка потребует значительных усилий. Коммерческие решения, вроде BladeLogic и OpsWare , проблему автоматизации настроек решают лишь отчасти, основное их достоинство – наличие графического интерфейса, да и позволить их приобрести могут только крупные организации. Есть, конечно, и проекты, предлагающие свободные решения, но за все время своего существования они так и не смогли создать большого сообщества. Например, Cfengine не очень пользуется популярностью уадминистраторов, хотя, кроме Linux, может использоваться в *BSD, Windows и Mac OS X. Возможно, это связано с относительной сложностью в создании конфигураций. Приописании заданий приходится учитывать особенности каждой конкретной системы и вручную контролировать последовательность действий при выполнении команд. То есть администратор должен помнить, что для одних систем следует писать adduser для других – useradd, учитывать расположение файлов в разных системах и так далее. Это на порядок усложняет процесс написания команд, с ходу создать правильную конфигурацию очень сложно, а созданные конфигурации прочитать через некоторое время практически нереально. Несмотря на GPL-лицензию Cfengine, фактически проект одного человека, который контролирует все изменения и не очень заинтересован в построении открытого общества. В результате возможности Cfengine вполне удовлетворяют разработчика, а для остальных администраторов это скорее лишняя головная боль. Чтобы улучшить Cfengine, сторонними разработчиками были созданы различные дополнения, что часто только ухудшало ситуацию. Автор нескольких таких модулей к Cfengine Люке Каниес (Luke Kanies) витоге решил разработать подобный инструмент, но лишенный многих недостатков Cfengine.

Возможности Puppet

Puppet , как и Cfengine, является клиент-серверной системой, использующей декларативный, то есть обязательный для выполнения язык для описания задач и библиотеки дляихреализации. Клиенты периодически (по умолчанию каждые 30 минут) соединяются с центральным сервером и получают последнюю конфигурацию. Если полученные настройки не совпадают с системным состоянием, они будут выполнены, при необходимости серверу отсылается отчет о произведенных операциях. Сервер сообщения может сохранить вsyslog или файл, создать RRD-график, отослать на указанный e-mail. Дополнительные уровни абстракции Transactional и Resource обеспечивают максимальную совместимость ссуществующими настройками и приложениями, позволяя сфокусироваться на системных объектах, не заботясь о различиях в реализации и описании подробных команд иформатах файлов. Администратор оперирует лишь с типом объекта, остальное Puppet берет на себя. Так, тип packages знает о 17 пакетных системах, нужная автоматически будет распознана на основании информации о версии дистрибутива или системы, хотя при необходимости пакетный менеджер можно задать принудительно.

В отличие от скриптов, которые часто невозможно использовать в других системах, конфигурации Puppet, написанные сторонними администраторами, будут в большинстве безпроблем работать в любой другой сети. В Puppet CookBook уже имеется три десятка готовых рецептов. В настоящее время Puppet официально поддерживает следующие операционные системы и сервисы: Debian, RedHat/Fedora, Solaris, SUSE, CentOS, Mac OS X, OpenBSD, Gentoo и MySQL, LDAP.

Язык Puppet

Чтобы идти дальше, вначале следует разобраться с основными элементами и возможностями языка. Язык – это одна из сильных сторон Puppet. С его помощью описываются ресурсы, которыми администратор планирует управлять, и действия. В отличие от большинства подобных решений, в Puppet язык позволяет упростить обращение ко всем схожим ресурсам на любой системе в гетерогенной среде. Описание ресурса, как правило, состоит из названия, типа и атрибутов. Например, укажем на файл /etc/passwd и установим его атрибуты:

file { "/etc/passwd":

Owner => root,

Group => root,

Mode => 644,

Теперь клиенты, подключившись к серверу, скопируют файл /etc/passwd и установят указанные атрибуты. В одном правиле можно определять сразу несколько ресурсов, разделяя их с помощью точки с запятой. А что делать, если конфигурационный файл, используемый на сервере, отличается от клиентских или вообще не используется? Например, такая ситуация может возникнуть при настройках VPN-соединений. В этом случае следует указать на файл директивой source. Здесь два варианта, можно, как обычно указать путь кдругому файлу, а также с помощью поддерживающихся двух URI протоколов: file и puppet. В первом случае используется ссылка на внешний NFS-сервер, во втором варианте насервере Puppet запускается NFS-подобный сервис, который и экспортирует ресурсы. В последнем случае по умолчанию путь указывается относительно корневого каталога puppet– /etc/puppet. То есть ссылка puppet://server.domain.com/config/sshd_config будет соответствовать файлу /etc/puppet/config/sshd_config. Переопределить этот каталог можно спомощью директивы filebucket, хотя более правильно использовать одноименную секцию в файле /etc/puppet/fileserver.conf. В этом случае можно ограничить доступ к сервису только сопределенных адресов. Например, опишем секцию config:

Path /var/puppet/config

Allow *.domain.com

Allow 127.0.0.1

Allow 192.168.0.*

Allow 192.168.1.0/24

Deny *.wireless.domain.com

А затем обращаемся к этой секции при описании ресурса:

source => "puppet://server.domain.com/config/sshd_config"

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

file { "/etc/passwd":

Alias => passwd

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

file { sshdconfig:

Name => $operatingsystem ? {

Solaris => "/usr/local/etc/ssh/sshd_config",

Default => "/etc/ssh/sshd_config"

В этом примере мы столкнулись с возможностью выбора. Отдельно указан файл для Solaris, для всех остальных будет выбран файл /etc/ssh/sshd_config. Теперь к этому ресурсу можно обращаться как к sshdconfig, в зависимости от операционной системы будет выбран нужный путь. Например, укажем, что в случае, если демон sshd запущен и получен новый файл, следует перезапустить сервис:

service { sshd:

Ensure => true,

Subscribe => File

Переменные часто используются при работе с пользовательскими данными. Например описываем месторасположение домашних каталогов пользователей:

$homeroot = "/home"

Теперь к файлам конкретного пользователя можно обратиться как:

${homeroot}/$name

В параметр $name будет подставлено учетное имя пользователя. В некоторых случаях удобно определить значение по умолчанию для некоторого типа. Например, для типа exec очень часто указывают каталоги, в которых он должен искать исполняемый файл:

Exec { path => "/usr/bin:/bin:/usr/sbin:/sbin" }

В том случае, если нужно указать на несколько вложенных файлов и каталогов, можно использовать параметр recurse:

file { "/etc/apache2/conf.d":

Source => "puppet:// puppet://server.domain.com/config/apache/conf.d",

Recurse => "true"

Несколько ресурсов могут быть объединены в классы или определения. Классы являются законченным описанием системы или сервиса и используются обособленно:

class linux {

File {

"/etc/passwd": owner => root, group => root, mode => 644;

"/etc/shadow": owner => root, group => root, mode => 440

Как и в объектно-ориентированных языках, классы могут переопределяться. Например, в FreeBSD группой-владельцем этих файлов является wheel. Поэтому, чтобы не переписывать ресурс полностью, создадим новый класс freebsd, который будет наследовать класс linux:

class freebsd inherits linux {

File["/etc/passwd"] { group => wheel };

File["/etc/shadow"] { group => wheel }

Для удобства все классы можно вынести в отдельный файл, который нужно подключать директивой include. Определения могут принимать многочисленные параметры в качестве аргументов, но не поддерживают наследования и используются в том случае, если нужно описать многократно используемые объекты. Например, определим домашний каталог пользователей и команды, необходимые для создания новой учетной записи:

define user_homedir ($group, $fullname, $ingroups) {

User { "$name":

Ensure => present,

Comment => "$fullname",

Gid => "$group",

Groups => $ingroups,

Membership => minimum,

Shell => "/bin/bash",

Home => "/home/$name",

Require => Group[$group],

Exec { "$name homedir":

Command => "/bin/cp -R /etc/skel /home/$name; /bin/chown -R $name:$group /home/$name",

Creates => "/home/$name",

Require => User[$name],

Теперь, чтобы создать новую учетную запись, достаточно обратиться к user_homedir:

user_homedir { "sergej":

Group => "sergej",

Fullname => "Sergej Jaremchuk",

Ingroups => ["media", " admin]

Отдельно стоят описания узлов (node), которые поддерживают наследование, как и классы. При подключении клиента к серверу Puppet будет произведен поиск соответствующей секции node и выданы специфические только для этого компьютера настройки. Для описания всех остальных систем можно использовать node default. Описание всех типов приведено в документе «Type Reference», с которым необходимо ознакомиться в любом случае, хотя бы для того, чтобы понять все возможности языка Puppet. Различные типы позволяют выполнять указанные команды, в том числе и при выполнении определенных условий (например, изменение конфигурационного файла), работать с cron, учетными данными и группами пользователей, компьютерами, монтированием ресурсов, запуском и остановкой сервисов, установкой, обновлением и удалением пакетов, работой с SSH-ключами, зонами Solaris и так далее. Вот так просто можно заставить обновлять список пакетов в дистрибутивах, использующих apt, ежедневно между 2 и 4 часами:

schedule { daily:

Period => daily,

Range =>

exec { "/usr/bin/apt-get update":

Schedule => daily

Обновление за тот период каждой системой будет выполнено только один раз, после чего задание считается выполненным и будет удалено с клиентского компьютера. Язык Puppet поддерживает другие привычные структуры: условия, функции, массивы, комментарии и подобные.

Установка Puppet

Для работы Puppet потребуются Ruby (начиная с версии 1.8.1 и выше) с поддержкой OpenSSL и библиотеками XMLRPC, а также библиотека Faster . В репозитарии Ubuntu 7.04, который использовался при тестовой установке, уже включен пакет puppy:

$ sudo apt-cache search puppet

~$ ruby -rxmlrpc/client -e "puts:yep"

yep

Если не получено ошибок, значит, все необходимое уже включено. Файлы, в которых описывается желательная конфигурация систем, в терминологии Puppet называются манифестами (manifests). При запуске демон пытается прочитать файл /etc/puppet/manifests/site.pp, при его отсутствии выдает предупреждающее сообщение. При тестировании можно указать демону на работу в автономном режиме, при котором манифест не требуется:

$ sudo /usr/bin/puppetmasterd --nonodes

При необходимости к site.pp можно подключать другие файлы, например, с описаниями классов. Для тестового запуска в этот файл можно занести самую простую инструкцию.

class sudo {

File { "/etc/sudoers":

Owner => root,

Group => root,

Mode => 440,

node default {

Include sudo

Все конфигурационные файлы, как сервера так и клиентов, расположены в /etc/puppet. Файл fileserver.conf, о котором мы уже говорили, не обязателен и используется только в том случае, когда Puppet будет работать еще и как файл-сервер. В Ubuntu в этом файле экспортируется подкаталог /etc/puppet/files. В подкаталоге ssl расположены сертификаты и ключи, которые будут использоваться для шифрования при подключениях клиентов. Ключи создаются автоматически при первом запуске puppetmasterd, вручную их можно создать командой:

$ sudo /usr/bin/puppetmasterd --mkusers

Файлы puppetd.conf и puppetmasterd.conf похожи. В них указываются некоторые параметры работы демонов на клиентской системе и сервере. Клиентский файл отличается только наличием параметра server, указывающего на компьютер, на котором запущен puppetmasterd:

server = grinder.com

logdir = /var/log/puppet

vardir = /var/lib/puppet

rundir = /var/run

# отсылаем отчет серверу

report = true

Чтобы не печатать все вручную, можно создать шаблон с помощью самого puppetd:

$ puppetd --genconfig > /etc/puppet/puppetd.conf

Аналогично можно создать и site.pp на сервере:

$ puppetd --genmanifest > /etc/puppet/manifests/site.pp

Еще один файл tagmail.conf, позволяет указать почтовые адреса, на которые будут отсылаться отчеты. В простейшем случае можно использовать одну строку:

all: [email protected]

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

Сначала, чтобы сервер узнал о новом компьютере, на клиентской системе вводим команду:

$ sudo puppetd --server grinder.com --waitforcert 60 –test

Межсетевой экран должен разрешать соединения на порт 8140.

На сервере получаем список сертификатов, нуждающихся в подписи:

$ sudo puppetca –list

nomad.grinder.com

И подписываем сертификат клиента:

$ sudo puppetca –sign nomad.grinder.com

Теперь клиент может свободно подключаться к серверу и получать настройки.

К сожалению, все возможности Puppet в пределах статьи показать невозможно. Но, как видите, это функциональный и гибкий инструмент, позволяющий решить большую часть задач по одновременному администрированию большого числа систем. И самое главное, проекту удалось собрать пока небольшое, но постоянно растущее сообщество. Поэтому будем надеяться, что хорошей идее не дадут умереть или уйти в сторону.

Удачи!

  1. Сайт проекта BladeLogic – http://www.bladelogic.com .
  2. Сайт проекта OpsWare – http://www.opsware.com .
  3. Сайт проекта Cfengine – http://www.cfengine.org .
  4. Сайт проекта Puppet – http://reductivelabs.com/projects/puppet .
  5. Puppet CookBook – http://www.reductivelabs.com/trac/puppet/tagspuppet%2Crecipe .
  6. Библиотека Faster –

Не так давно на страницах журнала мы рассматривали систему удаленного управления конфигурацией UNIX-машин Cfengine, которая существенно облегчает жизнь системного администратора за счет автоматизации действий по настройке множества сетевых узлов. Но, как бы ни был удобен Cfengine, у него есть множество недостатков, которых лишена система под названием Puppet.

Представь себя в роли системного администратора, ответственного за поддержание работоспособности сотни-другой машин, работающих под управлением операционных систем типа UNIX. Каждая из них требует настройки, периодического обновления и мониторинга, при этом предполагается, что многие из них выполняют сходные функции.

Две трети - это рабочие станции, еще несколько - маршрутизаторы, остальные - несколько веб-серверов и хранилищ данных. Вопрос: как всем этим хозяйством управлять? Самый простой ответ - это просто подключаться к каждой из них с помощью SSH и вносить необходимые изменения. Однако такой способ имеет две проблемы. Во-первых, он очень трудоемкий. Во-вторых, админу постоянно придется выполнять множество однообразных действий (например, чтобы обновить OpenOffice.org на всех рабочих станциях, придется выполнить одни и те же команды несколько десятков раз). Можно попытаться избежать этой проблемы, написав несколько скриптов, которые будут сами подключаться к каждой машине и выполнять заранее прописанные команды. Но и здесь тебя ожидают проблемы.

Скрипты постоянно придется видоизменять, чтобы подстроить их под каждую задачу; в скриптах придется учитывать различие в операционных системах и версиях, их придется долго отлаживать, перед тем как применить к работающим машинам. В общем, не комильфо. Правильный ответ заключается в использовании так называемых систем удаленного управления конфигурациями, наиболее известными представителями которых являются открытые системы Cfengine и Puppet. Такие системы берут на себя все обязанности по приведению конфигурации машин к нужному виду, требуя от администратора лишь описание конечного состояния системы на специальном языке (например, описание того, какие пакеты должны быть установлены в ОС, какие строки должны быть добавлены в конфигурационные файлы, какие команды должны быть выполнены и т.д.). После этого все узлы сами получат информацию о требуемом состоянии от сервера и проведут автоконфигурирование системы. Благодаря такому механизму новые машины могут быть полностью настроены без вмешательства человека, а существующие - перенастроены с помощью добавления всего нескольких строк в описание состояний.

Puppet?

Мы уже посвятили целую статью системе Cfengine, поэтому сегодня мы остановимся на системе Puppet, которую вполне можно назвать ее идеологическим последователем. Puppet была разработана Люком Каниесом (Luke Kanies), который устал от ограничений Cfengine и решил создать ее более совершенный аналог с нуля. Если ты уже использовал Cfenfine, то наверняка найдешь Puppet более удобной и мощной системой. Язык описания состояний Puppet более высокоуровневый и гибкий, благодаря чему администратору не нужно заботиться о таких вещах, как написание отдельных правил для каждого типа ОС или подробное описание выполнения тривиальных действий. Puppet позволяет своему господину сосредоточится на том, что он хочет сделать, вместо того, как это делать (например, чтобы установить определенный пакет в любую из поддерживаемых системой ОС, достаточно написать буквально несколько строк, говорящих «Установи эту программу», вместо описания команд, необходимых для ее установки). Puppet написан на простом языке Ruby, благодаря чему его достаточно просто подогнать под конкретную задачу и расширить функционал (предусмотрена гибкая система плагинов).

Кроме того, в отличие от модели развития Cfengine, которая фактически вращается вокруг одного человека, вокруг Puppet сформировалось большое сообщество энтузиастов, которые вносят доработки в код, делятся примерами конфигурации и пишут документацию.

В целом Puppet производит впечатление более современной и продуманной системы с хорошим дизайном. Как и Cfengine, она поддерживает почти все современные UNIX-подобные ОС (в том числе MacOS X), а также может работать в среде Cygwin поверх Windows. Список ее зависимостей включает только интерпретатор Ruby и инструмент Factor, так что проблем с установкой возникнуть не должно (справедливости ради стоит сказать, что список зависимостей Cfengine и того короче).

Установка

Как и Cfengne, Puppet - клиент-серверная система, которая состоит из управляющего сервера и подчиненных узлов. Сервер хранит описание конечных состояний узлов (который в терминах Puppet называется манифестом) и ждет их подключения. Каждые полчаса (по умолчанию) клиент подключается к серверу, получает от него описание конечного состояния, сверяет его с текущим и, если оно и/или описанное состояние изменилось, производит переконфигурирование системы, после чего уходит в сон. Коммуникация производится через зашифрованный канал, поэтому атаки, основанные на подмене описания состояния, исключены (но если взломщик захватит сервер, то все узлы будут под его контролем).

Puppet включен в репозитории всех популярных дистрибутивов, поэтому его установка не должна вызвать затруднений. Например, в Debian/Ubuntu клиент Puppet можно установить так:

$ sudo apt-get install puppet

А сервер - так:

$ sudo apt-get install puppet puppetmaster

Конфигурационные файлы клиента и сервера хранятся в каталоге /etc/puppet. Наиболее важный из них - файл /etc/puppet/manifests/site.pp, содержащий манифест.

Он хранит описание состояний и должен существовать только на сервере. Для удобства отладки добавим в него простейшую конфигурацию:


class passwd {
file { "/etc/passwd":
owner => root,
group => root,
mode => 644,
}
}
node default {
include passwd
}

Эти строки описывают состояние, при котором владельцем файла /etc/passwd должен быть root, а права доступа к нему установлены в значение 644. В следующем разделе мы подробнее рассмотрим формат файла манифеста. Второй по важности файл носит имя /etc/puppet/puppet.conf. Он задает конфигурацию сервера и клиентов, поэтому должен присутствовать на всех машинах, организованных в сеть Puppet. В Ubuntu этот файл содержит минимально необходимые и в большинстве случаев достаточные настройки. Ниже они приведены с комментариями:

# vi /etc/puppet/puppet.conf
# Стандартные пути к каталогам
logdir=/var/log/puppet
vardir=/var/lib/puppet
ssldir=/var/lib/puppet/ssl
rundir=/var/run/puppet
# Расположение инструмента Facter,
# используемого для получения информации об ОС
factpath=$vardir/lib/facter
# Синхронизировать плагины
# (установил плагины на сервер - они копируются на клиентов)
pluginsync=true
# Каталог с шаблонами (о них читай ниже)
templatedir=$confdir/templates
# Синхронизация с etckeeper
# (кто знает - поймет, остальным не нужно)
prerun_command=/etc/puppet/etckeeper-commitpre
postrun_command=/etc/puppet/etckeeper-commitpost

Конфигурационный файл может включать в себя большое количество различных опций, информацию о которых можно получить, сгенерировав дефолтовый конфиг:

$ sudo puppetmasterd -genconfig > /etc/puppet/
puppetd.conf.default

Дефолтовый клиентский конфиг генерируется с помощью другой команды:

$ sudo puppet -genconfig > /etc/puppet/puppetd.conf.default

Файлы fileserver.conf и auth.conf используются для настройки файлового сервера (об этом читай в разделе «Файловый сервер») и аутентификации. Пока их трогать нет смысла. По окончании конфигурирования сервер Puppet необходимо перезапустить:

$ sudo /etc/init.d/puppetmaster restart

После чего он будет готов принимать запросы клиентов. Однако без подписанного сертификата ни один клиент не сможет получить манифест от сервера и выполнить конфигурирование машины.

Поэтому мы должны запустить клиенты Puppet в тестовом режиме, чтобы они смогли передать свои сертификаты серверу на подпись (кстати, одновременно на всех машинах это можно сделать с помощью инструмента shmux):

$ sudo puppetd -server puppet-сервер.com -verbose -test

Возвращаемся на сервер и получаем список сертификатов, готовых к подписи:

$ sudo puppetca --list

Выбираем хост из списка и подписываем его сертификат:

$ sudo puppetca --sign nomad.grinder.com

Или же подписываем сразу все:

$ sudo puppetca --sign --all

Теперь можно запустить клиенты в боевом режиме. Но сначала необходимо прописать имя Puppet-сервера в конфигурационном файле (по умолчанию его имя - просто puppet):

$ sudo su
# echo "" >> /etc/puppet/puppet.conf
# echo "server=puppet-сервер.com" >> /etc/puppet/puppet.conf
# exit

Запускаем клиенты:

$ sudo /etc/init.d/puppet start

Язык описания состояния

Как уже было сказано выше, Puppet использует собственный язык описания конечного состояния операционной системы, с помощью которого сисадмин указывает то, к какому виду должны быть приведены компоненты ОС, чтобы она достигла желаемого состояния. Это достаточно сложный язык, который, тем не менее, гораздо проще любого языка программирования. Если ты хотя бы поверхностно знаком с языком сценариев bash, то легко разберешься в языке Puppet. Ключевым элементом языка являются ресурсы, с помощью которых происходит описание того, к какому виду должен быть приведен один из компонентов ОС. Например, следующий простейший ресурс описывает желаемое состояние файла /etc/passwd:

# vi /etc/puppet/manifests/site.pp
file { "/etc/passwd":
owner => "root"
}

Здесь file - это тип ресурса. Всего их существует несколько десятков, начиная от ресурсов, управляющих файлами, как в этом примере, и заканчивая пакетами и сервисами. Строка /etc/passwd - имя ресурса.

В случае с типом file имя совпадает с путем до файла, однако в некоторых других типах имя может быть произвольным. Строка owner => "root" описывает установку атрибута owner в значение root, то есть говорит, что владельцем (owner) указанного файла должен быть администратор.

Каждый тип ресурсов обладает собственным набором доступных для модификации атрибутов, плюс есть специальные мета-атрибуты, которые можно использовать в любом ресурсе. Одним из важных качеств ресурсов является возможность ссылки на них. Это можно использовать для формирования цепочек зависимостей. Следующая запись создает ресурс /etc/group, который зависит от ресурса /etc/passwd (зависимости указываются с помощью мета-атрибута require):

# vi /etc/puppet/manifests/site.pp
file { "/etc/group":
require => File["/etc/passwd"],
owner => "root",
}

Это значит, что ресурс /etc/group может быть сконфигурирован (приведен к описанному виду) только тогда, когда будет сконфигурирован ресурс /etc/passwd. Ресурсы могут быть сгруппированы в коллекции ресурсов, называемые классами. Это нужно для того, чтобы объединить похожие по смыслу и типу выполняемой задачи ресурсы в один абстрактный ресурс. Например, для удобства мы могли бы объединить установку и запуск веб-сервера nginx в один абстрактный одноименный ресурс:

# vi /etc/puppet/manifests/site.pp
class nginx {
package { "nginx":
ensure => installed
}
service { "nginx":
ensure => running,
require => Package["nginx"],
}
}

Здесь тип ресурса package используется для установки пакета nginx в систему, а service - для запуска одноименного сервиса. С помощью require мы заставляем систему запускать сервис только в том случае, если пакет был успешно установлен. Удобство классов в том, что их тоже можно включать в зависимости:

# vi /etc/puppet/manifests/site.pp
service { "squid":
ensure => running,
require => Class["nginx"],
}

Как и в настоящих ООП-языках, классы могут наследовать друг друга и переопределять атрибуты:

# vi /etc/puppet/manifests/site.pp
class passwd {
file { "/etc/passwd":
owner => "root",
group => "root",
}
}
class passwd-bsd inherits passwd {
File["/etc/passwd"] { group => "wheel" }
}

Здесь класс passwd-bsd наследуется от passwd для того, чтобы переопределить атрибут group ресурса /etc/passwd (в BSD-системах /etc/passwd принадлежит группе wheel, поэтому мы создали отдельный класс для таких систем). Позже мы рассмотрим более правильный и очевидный способ выбора альтернативных значений атрибутов с помощью условий.

Переменные - один из неотъемлемых компонентов любого языка программирования, и в языке Puppet они тоже есть. Переменные начинаются со знака $ и могут содержать любое число, строку или булево значение (true, false):

$want_apache = true
$apache_version = "2.2.14"

Одним из мощнейших свойств языка Puppet, связанным с переменными, является интеграция с инструментом получения информации о машине facter. Эта утилита возвращает всю информацию, специфичную для машины, в виде пар «ключ-значение», которые в Puppet превращаются в одноименные переменные. Вкупе с условными инструкциями языка Puppet они могут быть использованы для альтерации атрибутов ресурса в зависимости от свойств машины.

Например, описанный выше класс passwd может быть легко переписан для автоматического выбор атрибута в зависимости от типа ОС (при этом сам класс больше не нужен):

# vi /etc/puppet/manifests/site.pp
file { "/etc/passwd":
owner => "root",
group => $kernel ? {
Linux => "root",
FreeBSD => "wheel",
},
}

В зависимости от того, на какой ОС будет проанализирован данный фрагмент манифеста, значением атрибута group станет либо root, либо wheel. Кроме условного оператора, язык Puppet поддерживает и оператор выбора case, который можно использовать для создания того или иного ресурса в зависимости от значения переменной:

# vi /etc/puppet/manifests/site.pp
case $operatingsystem {
redhat: { service { "httpd": ensure => running }}
debian: { service { "apache": ensure => running }}
default: { service { "apache2": ensure =>
running }}
}

Этот код определяет различные варианты ресурса типа service в зависимости от операционной системы (имена сервисов в различных дистрибутивах Linux могут отличаться, поэтому то, какой сервис должен запустить Puppet, необходимо указывать индивидуально для каждого из них).

Вариант default используется в том случае, если значение переменной не соответствует ни одному из предыдущих вариантов. Помимо уже рассмотренных ранее типов ресурсов file, package и service, Puppet поддерживает большое количество других, в том числе созданных сторонними разработчиками типов ресурсов. Их подробное описание, включая примеры, поддерживаемые атрибуты и особенности, ты можешь найти в официальной документации - http://docs.puppetlabs.com/references/stable/type.html . Ниже приведен список и краткое описание наиболее используемых из них:

Популярные типы ресурсов Puppet

  • cron - управление заданиями cron
  • exec - запуск скриптов и команд
  • file - управление файлами
  • filebucket - резервное копирование файлов
  • group - управление группами
  • host - управление записями в файле /etc/hosts
  • interface - конфигурирование сетевых интерфейсов
  • mount - монтирование файловых систем
  • notify - посылка сообщения в лог-файл Puppet
  • package - управление пакетами
  • service - управление сервисами
  • sshkey - управление ключами SSH
  • tidy - удаление файлов в зависимости от условий
  • user - управление пользователями
  • zones - управление зонами Solaris

Второй после ресурсов по важности элемент языка Puppet - это узлы (nodes). С их помощью администратор может описать то, к каким машинам должны быть применены те или иные ресурсы и классы. Другими словами, это способ указать индивидуальную конфигурацию для каждой из машин, участвующих в сети Puppet. Наиболее простой пример узла приведен в начале статьи в разделе «Установка»:

# vi /etc/puppet/manifests/site.pp
node default {
include passwd
}

Это определение узла default, включающего в себя ресурс/класс passwd. Имя default значит «все остальные узлы», поэтому ресурс/ класс passwd, определенный где-то выше, будет сконфигурирован на каждом из них. Ключевое слово include здесь использовано для удобства, на самом деле все классы и ресурсы можно описать прямо в описании узла, но делать это не рекомендуется. Помимо default в имени узла можно указывать сетевое имя машины (тогда все описанные в узле ресурсы будут сконфигурированы только на этой машине), либо произвольное имя (тогда этот узел может быть унаследован другим узлом). Чтобы понять, как все это работает совместно с классами и ресурсами, рассмотрим пример готового манифеста Puppet, используемого для конфигурирования двух сетевых машин (веб-сервера и NTP-сервера):

# vi /etc/puppet/manifests/site.pp
# Установка и запуск SSH-сервера
class sshd {
package { openssh-server: ensure => installed }
service { sshd:
name => $operatingsystem ? {
fedora => "sshd",
debian => "ssh",
default => "sshd",
},
enable => true,
ensure => running,
}
}
# Установка и запуск Apache
class httpd {
package { httpd: ensure => installed }
service { httpd:
enable => true,
ensure => running,
}
}
# Установка и запуск NTP-сервера
class ntpd {
package { ntp-server: ensure => installed }
service {
ntp-server:
enable => true,
ensure => running,
}
}
# Базовый узел, используется только как родитель всех остальных
node base {
include sshd
}
# Узел, на котором будет расположен веб-сервер
node web.server.com inherits base {
inlude httpd
}
# Узел NTP-сервера
node ntp.server.com inherits base {
include ntpd
}

Эта простая с виду конфигурация делает достаточно много: она приводит к установке и запуску Apache на машине с адресом web.server.com и к установке и запуску NTP-сервера на машине ntp.server.com . Дополнительно обе машины устанавливают SSH-сервер. Такая конфигурация едва ли устроит хоть одного администратора; ее придется серьезно доработать, чтобы научить правильно настраивать серверы, получать свежие конфиги и другие файлы с головного сервера Puppet.

Однако она наглядно показывает мощь Puppet. С помощью простого конфига мы сделали так, чтобы машины сами установили и запустили необходимое ПО и поддерживали его в рабочем состоянии (если сервер упадет, Puppet сам произведет переконфигурирование, чтобы привести системы к требуемому состоянию).

Файл-сервер

Многие задачи удаленного администрирования не могут быть решены без копирования на машины дополнительных файлов. Это могут быть заранее подготовленные конфиги, веб-страницы для Apache, пакеты, отсутствующие в официальном репозитории, и многое другое. Чтобы облегчить процесс переноса этих файлов на удаленные узлы, Puppet включает в себя файловый сервер.

Настройки файлового сервера хранятся в файле /etc/puppet/fileserver.conf. Чтобы заставить Puppet отдавать клиентам содержимое определенного каталога, необходимо поместить в него несколько строк:

# vi /etc/puppet/fileserver.conf
path = /var/puppet/files
allow *.server.com

Эти две строки указывают на то, что каталог /var/puppet/files должен быть доступен всем хостам домена server.com. Кроме того, мы можем указать полное доменное имя разрешенной машины или ее IP-адрес, а также отрезать неугодных с помощью директивы deny. После этого любой файл этого каталога можно переместить на клиент с помощью ресурса file. Например:

# vi /etc/puppet/manifests/site.pp
file { "/etc/httpd/conf/httpd.conf":
source => "puppet://httpd/httpd.conf",
mode => 644,
}

Файл httpd.conf, расположенный на сервере в каталоге /var/puppet/ files/httpd, будет скопирован на целевую машину по пути, указанном в имени ресурса.

Выводы

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

Info

  • Puppet использует протокол HTTP, поэтому для увеличения производительности может быть запущен под управлением веб-сервера.
  • Puppet можно использовать для автоконфигурирования и сопровождения одной локальной машины.
  • Объединив Puppet, сетевую установку ОС (pxe-install) и самосборные установочные образы, можно создать полностью самоконфигурируемую сеть машин, для развертывания которой достаточно выполнить одну команду.
  • Puppet используют в своей работе многие крупные компании, такие как Google, Fedora Project, Stanford University, Red Hat, Siemens IT Solution и SugarCRM.

Links

  • http://docs.puppetlabs.com - Документация Puppet
  • http://docs.puppetlabs.com/guides/language_tutorial.html - Полное описание языка Puppet
  • http://docs.puppetlabs.com/references/stable/type.html - Типы ресурсов

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

Следует признать, что администраторы Windows сетей находятся все-таки в более выгодном положении. Достаточно изменить настройки групповых политик и через некоторое время все компьютеры сети, в том числе и с недавно установленной операционной системой “узнают” о нововведении, если они их конечно касаются. Оглянувшись на долгий период развития Unix, можно заметить, что ничего подобного так и не прижилось. Есть решения вроде kickstart, которые помогают при первичной установке операционной системы, но дальнейшая доводка потребует значительных усилий. Коммерческие решения вроде BladeLogic и OpsWare , проблему автоматизации настроек решают лишь отчасти, основное их достоинство наличие графического интерфейса, да и позволить их приобрести могут только в крупных организациях. Есть конечно и проекты предлагающие свободные решения, но за все время своего существования они так и не смогли создать большого сообщества. Например Cfengine не очень пользуется популярностью у администраторов, хотя кроме Linux, может использоваться в *BSD, Windows и Mac OS X. Возможно это связано с относительной сложностью в создании конфигураций. При описании заданий приходится учитывать особенности каждой конкретной системы, и вручную контролировать последовательность действий при выполнении команд. То есть администратор должен помнить, что для одних систем следует писать adduser для других useradd, учитывать расположение файлов в разных системах, и так далее. Это на порядок усложняет процесс написания команд, с ходу создать правильную конфигурацию очень сложно, а созданные конфигурации прочитать через некоторое время практически не реально. Не смотря на GPL лицензию Cfengine фактически проект одного человека, который контролирует все изменения и не очень заинтересован в построении открытого общества. В результате возможности cfengine вполне удовлетворяют разработчика, а для остальных администраторов это скорее лишняя головная боль. Чтобы улучшить cfengine сторонними разработчиками были созданы различные дополнения, что часто только ухудшало ситуацию. Автор нескольких таких модулей к cfengine Люке Каниес (Luke Kanies) в итоге решил разработать подобный инструмент, но лишенный многих недостатков cfengine.

Возможности Puppet

Puppet как и cfengine является клиент-серверной системой использующей декларативный, то есть обязательный для выполнения язык для описания задач и библиотеки для их реализации. Клиенты периодически (по умолчанию 30 минут) соединяются с центральным сервером и получают последнюю конфигурацию. Если полученные настройки не совпадают с системным состоянием, они будут выполнены, при необходимости серверу отсылается отчет о произведенных операциях. Сервер сообщения может сохранить в syslog или файл, создать RRD график, отослать на указанный e-mail. Дополнительные уровни абстракции Transactional и Resource обепечивают максимальную совместимость с существующими настройками и приложениями, позволяя сфокусироваться на системных объектах, не заботясь о различиях в реализации и описании подробных команд и форматах файлов. Администратор оперирует лишь с типом объекта, остальное Puppet берет на себя. Так тип packages знает о 17 пакетных системах, нужная автоматически будет распознана на основании информации о версии дистрибутива или системы, хотя при необходимости пакетный менеджер можно задать принудительно.

В отличие от скриптов, которые часто не возможно использовать в других системах, конфигурации Puppet написанные сторонними администраторами будут в большинстве без проблем работать в любой другой сети. В Puppet CookBook [http://www.reductivelabs.com/trac/puppet/tags/puppet%2Crecipe ] уже имеется три десятка готовых рецептов. В настоящее время Puppet официально поддерживает следующие операционные системы и сервисы: Debian, RedHat/Fedora, Solaris, SUSE, CentOS, Mac OS X, OpenBSD, Gentoo и MySQL, LDAP.

Язык Puppet

Чтобы идти дальше, вначале следует разобраться с основными элементами и возможностями языка. Язык это одна из сильных сторон Puppet. С его помощью описываются ресурсы которыми администратор планирует управлять и действия. В отличие от большинства подобных решений, в Puppet язык позволяет упростить обращение ко всем схожим ресурсам на любой системе в гетерогенной среде. Описание ресурса, как правило, состоит из названия, типа и атрибутов. Например укажем на файл /etc/passwd и установим его атрибуты:

file { «/etc/passwd»:

owner => root,

group => root,

Теперь клиенты, подключившись к серверу скопируют файл /etc/passwd и установят указанные аттрибуты. В одном правиле можно определять сразу несколько ресурсов, разделяя их с помощью точки с запятой. А что делать если конфигурационный файл используемый на сервере отличается от клиентских или вообще не используется? Например такая ситуация может возникнуть при настройках VPN соединений. В этом случае следует на файл можно указать директивой source. Здесь два варианта, как обычно указать путь к другому файлу, также поддерживается два URI протокола: file и puppet. В первом случае используется ссылка на внешний NFS сервер, во втором варианте на сервере Puppet, запускается NFS подобный сервис, который и экспортирует ресурсы. В последнем случае по умолчанию путь указывается относительно корневого каталога puppet — /etc/puppet. То есть ссылка puppet://server.domain.com/config/sshd_config будет соответствовать файлу /etc/puppet/config/sshd_config. Переопределить этот каталог, можно с помощью директивы filebucket, хотя более правильно использовать одноименную секцию в файле /etc/puppet/fileserver.conf. В этом случае можно ограничить доступ к сервису только с определенных адресов. Например опишем секцию config.

path /var/puppet/config

allow *.domain.com

allow 192.168.0.*

allow 192.168.1.0/24

deny *.wireless.domain.com

А затем обращаемся к этой секции при описании ресурса.

source => «puppet://server.domain.com/config/sshd_config»

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

file { «/etc/passwd»:

alias => passwd

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

file { sshdconfig:

name => $operatingsystem ? {

solaris => «/usr/local/etc/ssh/sshd_config»,

default => «/etc/ssh/sshd_config»

В этом примере мы столкнулись с возможностью выбора. Отдельно указан файл для Solaris, для всех остальных будет выбран файл /etc/ssh/sshd_config. Теперь к этому ресурсу можно обращаться как к sshdconfig, в зависимости от операционной системы будет выбран нужный путь. Например укажем, что в случае если демон sshd запущен и получен новый файл, следует перезапустить сервис.

ensure => true,

subscribe => File

Переменные часто используются при работе с пользовательскими данными. Например описываем месторасположение домашнних каталогов пользователей:

$homeroot = «/home»

Теперь к файлам конкретного пользователя можно обратиться как

${homeroot}/$name

В параметр $name будет подставлено учетное имя пользователя. В некоторых случаях удобно определить значение по умолчанию для некоторого типа. Например для типа exec очень часто указывают каталоги в которых он должен искать исполняемый файл:

Exec { path => «/usr/bin:/bin:/usr/sbin:/sbin» }

В том случе если нужно указать на несколько вложенных файлов и каталогов, можно использовать параметр recurse.

file { «/etc/apache2/conf.d»:

source => «puppet:// puppet://server.domain.com/config/apache/conf.d»,

recurse => «true»

Несколько ресурсов могут быть объеденены в классы или определения. Классы являются законченным описанием системы или сервиса и используются обособленно.

«/etc/passwd»: owner => root, group => root, mode => 644;

«/etc/shadow»: owner => root, group => root, mode => 440

Как и в объектно-ориентированных языках классы могут переопределяться. Например в FreeBSD группой-владельцем этих файлов является wheel. Поэтому чтобы не переписывать ресурс полностью, создадим новый класс freebsd, который будет наследовать класс linux:

class freebsd inherits linux {

File[«/etc/passwd»] { group => wheel };

File[«/etc/shadow»] { group => wheel }

Для удобства все классы можно вынести в отдельный файл, который подключать директивой include. Определения могут принимать многочисленные параметры в качестве аргументов, но не поддерживают наследования и используются в том случае если нужно описать многократно используемые объекты. Например определим домашний каталог пользователей и команды необходимые для создания новой учетной записи.

define user_homedir ($group, $fullname, $ingroups) {

user { «$name»:

ensure => present,

comment => «$fullname»,

gid => «$group»,

groups => $ingroups,

membership => minimum,

shell => «/bin/bash»,

home => «/home/$name»,

require => Group[$group],

exec { «$name homedir»:

command => «/bin/cp -R /etc/skel /home/$name; /bin/chown -R $name:$group /home/$name»,

creates => «/home/$name»,

require => User[$name],

Теперь чтобы создать новую учетную запись достаточно обратиться к user_homedir.

user_homedir { «sergej»:

group => «sergej»,

fullname => «Sergej Jaremchuk»,

ingroups => [«media», » admin]

Отдельно стоят описания узлов (node), которые поддерживают наследование как и классы. При подключении клиента к серверу Puppet будет произведен поиск соотетсвующей секции node и выданы специфические только для этого компьютера настройки. Для описания всех остальных систем можно использовать node default. Описание всех типов приведено в документе “Type Reference” с которым необходимо ознакомиться в любой случае, хотя бы, для того чтобы понять все возможности языка Puppet. Различные типы позволяют выполнять указанные команды, в том числе и при выполнении определенных условий (например изменение конфигурационного файла), работать с cron, учетными данными и группами пользователей, компьютерами, монтированием ресурсов, запуском и остановкой сервисов, установкой, обновлением и удалением пакетов, работой с SSH ключами, зонами Solaris и так далее. Вот так просто можно заставить обновлять список пакетов в дистрибутивах использующих apt, ежедневно между 2 и 4 часами.

schedule { daily:

period => daily,

range =>

exec { «/usr/bin/apt-get update»:

schedule => daily

Обновление за тот период каждой системой будет выполнено только один раз, после чего задание считается выполненным и будет удалено с клиентского компьютера. Язык Puppet поддерживает другие привычные структуры: условия, функции, массивы, комментарии и подобные.

Установка Puppet

Для работы Puppet потребуются Ruby (>= 1.8.1) с поддержкой OpenSSL и библиотеками XMLRPC, а также библиотека Faster [http://reductivelabs.com/projects/facter ]. В репозитарии Ubuntu 7.04, который использовался при тестовой установке, уже включен пакет puppy.

$ sudo apt-cache search puppet

puppet — centralised configuration management for networks

puppetmaster — centralised configuration manangement control daemon

При инсталляции будут установлены все необходимые зависимости пакеты: facter libopenssl-ruby libxmlrpc-ruby.

$ sudo apt-get install puppet puppetmaster

Проверить наличие библиотек Ruby можно командой.

$ ruby -ropenssl -e «puts:yep»

~$ ruby -rxmlrpc/client -e «puts:yep»

Если не получено ошибок, значит все необходимое уже включено. Файлы в которых описывается желательная конфигурация систем в терминологии Puppet называются манифестами (manifests). При запуске демон пытается прочитать файл /etc/puppet/manifests/site.pp, при его отсутствии выдает предупреждающее сообщение. При тестировании можно указать демону на работу в автоновном режиме при котором манифест не требуется

$ sudo /usr/bin/puppetmasterd —nonodes

При необходимости к site.pp можно подключать другие файлы, например с описаниями классов. Для тестового запуска в этот файл можно занести самую простую инструкцию.

file { «/etc/sudoers»:

owner => root,

group => root,

Все конфигурационный файлы как сервера так и клиентов расположены в /etc/puppet. Файл fileserver.conf о котором мы говорили выше, не обязателен и используется только в том случае когда Puppet будет работать еще и как файл-сервер. В Ubuntu в этом файле экспортируется подкаталог /etc/puppet/files. В подкаталоге ssl расположены сертификаты и ключи, которые будут использоваться для шифрования при подключениях клиентов. Ключи создаются автоматически при первом запуске puppetmasterd, вручную их создать можно командой.

$ sudo /usr/bin/ puppetmasterd —mkusers.

Файлы puppetd.conf и puppetmasterd.conf похожи. В них указываются некоторые параметры работы демонов на клиенской системе и сервере. Клиенский файл отличается только наличием параметра server, указывающего на компьютер на котором запущен puppetmasterd.

server = grinder.com

logdir = /var/log/puppet

vardir = /var/lib/puppet

rundir = /var/run

# отсылаем отчет серверу

Чтобы не печатать все вручную, можно создать шаблон с помощью самого puppetd.

$ puppetd —genconfig > /etc/puppet/puppetd.conf

Аналогично можно создать и site.pp на сервере.

$ puppetd —genmanifest > /etc/puppet/manifests/site.pp

Еще один файл tagmail.conf, позволяет указать почтовые адреса на которые будут отсылаться отчеты. В простейшем случае можно использовать одну строку.

all: [email protected]

Конфигурационных файлов недостаточно, чтобы клиент мог подключаться к серверу. Для этого необходимо еще подписать сертификаты. Сначала чтобы сервер узнал о новом компьютере на клиентской системе вводим команду:

$ sudo puppetd —server grinder.com —waitforcert 60 —test

info: Requesting certificate

warning: peer certificate won’t be verified in this SSL session

notice: Did not receive certificate

Если будет выдана другая строка, следует проверить работу сервера.

$ ps aux | grep puppet

puppet 5779 0.0 1.4 27764 15404 ? Ssl 21:49 0:00 ruby /usr/sbin/puppetmasterd

Межсетевой экран должен разрешать соединения на порт 8140.

На сервере получаем список сертификатов нуждающихся в подписи.

$ sudo puppetca —list

nomad.grinder.com

И подписываем сертификат клиента.

$ sudo puppetca –sign nomad.grinder.com

Теперь клиент может свободно подключаться к серверу и получать настройки.

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


Немного лирики. Казалось бы с этой статьи следует начинать весь цикл, но всё же целевой аудиторией являются более опытные пользователи Open Source продуктов Puppet Labs, которых не устраивают отдельные малоинтегрированные модули с Puppet Forge. Как и с любым случаем "library vs. framework", расплатой является следование мировоззрению автора интегрированного решения.

Немного о принципе работы Puppet

Puppet - это в первую очередь специфичный язык декларативного задания конечного состояния системы. Для сравнения крайне подойдёт GNU Makefile, где помимо непосредственного описания зависимостей есть возможность начудить на полную катушку.

Абстракция Puppet примерно следующая (срыв шаблонов - забудьте всё, что вы знали о терминах в программировании! ).

  • Узел (node) - это совокупность конфигурации для конкретной целевой системы. На деле это частный случай класса.
  • Класс (class) - это набор декларативной логики, которая включается в конфигурацию узла или другие классы. У класса нет ни экземпляров, ни методов, зато есть параметры и переменные, определённые внутри логики. На деле, это скорее процедура, которая может наследовать другую процедуру банальным наращиванием кода и не совсем банальной областью видимости переменных.
  • Тип (type) - а вот это уже больше смахивает на классический класс - у него предполагаются экземпляры с именем и определённо заданными параметрами, но ничего более. Конкретная реализация типа может быть написана в виде Puppet скрипта через define , который создаёт экземпляры других типов или же в виде расширения на Ruby с полётом фантазии.
  • Ресурс (resource) - собственно это и есть именованные экземпляры Типов. Имя каждого ресурса уникально в рамках конкретного типа в пределах конфигурации узла (каталога).
  • Переменные (variable) - ну, короче это константы… До версии Puppet 4 с их областью видимости было всё ещё хуже. Теперь она адекватна: для использования извне места определения требуется задавать полностью квалифицированный идентифиактор, за исключением случая наследования классов.
Puppet может использоваться для локального развёртывания без сети и соответствующей инфраструктуры. Это может использоваться для создания образов контейнеров. Есть даже целое направление ратующих за отказ от централизованного сервера.

В идеологически правильном ключе, инфраструктура Puppet состоит из агента - привилегированного сервиса на целевой системе и сервера, раздающего ценные указания в виде декларативных каталогов ресурсов по запросу от агентов. Безопасность реализована на уровне приватной инфраструктуры публичного ключа (X.509). Попросту говоря, тех же механизмов, что и в HTTPS, но с собственным CA и обязательной проверкой клиентского сертификата.

В упрощённом виде процедура развёртывания выглядит примерно так:

  1. Обработка по TLS и X.509 (установка соединения, обновление CRL, проверка ограничений сертификата и т.д)
  2. Агент получает генераторы фактов с сервера с кэшированием и всеми делами (точнее вытягивается всё из папок lib/ в модулях). Не составляет никакого труда добавить свой Ruby скрипт для сбора интересующей информации.
  3. Агент собирает факты о целевой системе и отправляет на сервер. Все факты легко просмотреть вручную через вызов puppet facts . Эти факты доступны в качестве глобальных переменных.
  4. Сервер составляет каталог ресурсов и отправляет агенту. Под этим скрывается целый пласт различных концепций.
  5. Агент вытягивает всё необходимое с сервера и приводит систему к указанном виду. Сам агент при этом не знает как поступать с ресурсами, он полагается на реализацию provider"ов (смысловой перевод будет "воплотитель", а не поставщик) конкретных типов ресурсов. Часть provider"ов являются стандартными и входят в пакеты Puppet, а остальные вытягиваются из модулей.
Для вкушения всех прелестей, существует дополнительные плюшки в виде:
  • Модуль - совокупность декларативных скриптов Puppet, Ruby расширений для Puppet, файлов, шаблонов файлов, Hiera данных и многого другого. Более правильный термин был бы "пакет".
  • Среда (Environment) - совокупность скриптов, модулей и Hiera данных. С усложнением инфраструктуры неминуемо потребовалось разделять конфигурацию далее стандартного деления по узлам. В основном, это требуется для пилотных нововведений и банального контроля доступа (когда не все админы имеют доступ ко всем узлам IT инфраструктуры).
  • Hiera - иерархическая база данных. Такая формулировка может сильно отпугивать. Вероятно поэтому её и поменяли в документации более поздних версий. На деле это крайне простой и удобный механизм вытягивать конфигурацию из YAML или JSON файлов. Иерархия заключается в возможности задать порядок чтения множества конфигурационных файлов - т.е. иерархию/приоритет этих файлов.
    • Помимо вытягивания данных по вызову функции, Puppet вытягивает параметры классов по умолчанию, что является главной изюминкой.
    • Разумеется, Hiera поддерживает интерполяцию фактов и даже вызов специальных функций.
    • В Puppet 4.3 реализовали этот же функционал ещё раз для поддержки не только глобальной базы данных, но и локальной для Среды и Модуля, правда автор уже нашёл несколько проблем в их реализации (PUP-5983 , PUP-5952 и PUP-5899), которые были моментально исправлены Puppet Labs.
    • Поддерживаются несколько стратегий вытягивания значения из всех файлов по иерархии:
      • first - выдаётся первое попавшиеся по приоритету значение
      • unique - собирает все значения в одномерный массив и убирает дубликаты
      • hash - объединяет все найденные YAML Hash. Дубликаты ключей выбираются по приоритету.
      • deep - по сути рекурсивный вариант hash
    • Прелесть в том, что стратегия выборки может задаваться как при вызове функции lookup() , т.к. и в любом файле иерархии через специальный ключ lookup_options , что активно используется в модуле cfnetwork .
  • PuppetDB - по сути слой бизнес логики вокруг реляционной базы данных (PostgreSQL), который позволяет сохранять отчёты о фактах и проделанных развёртываниях и экспортировать ресурсы для последующего импорта в каталоги на других узлах или выборки через специальные функции. Ещё есть и веб-морда в виде Puppet Dashboard.
  • X.509 PKI - уже упомянутая инфраструктура сертификатов, которую крайне удобно использовать для других сервисов без необходимости управления отдельной инфраструктурой.
  • MCollective - вроде бы полезная вещь для событийного запуска задач на серверной ферме, но у автора есть определённое недоверие к безопасности конкретного решения.
  • Puppet Forge - открытая площадка для публикации и скачивания Модулей.
  • некоторые другие фичи в виде управления внешними устройствами типа оборудования Cisco и развёртывания на голом железе, но это уже отдельная история

Заметки по безопасности и доступности

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

Доступность Puppet Server определяет возможность управления всей инфраструктурой. Имеет смысл размещать Puppet Server на виртуалке в более надёжном и быстро восстанавливаемом стороннем облаке, чем собственные возможности. Или же следует устанавливать несколько серверов.

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

Мульти-мастер (несколько обособленных Puppet Server)

  • В данном случае только один сервер выступает в роли CA (Certificate Authority) - его недоступность означает невозможность добавить новые узлы.
    • Puppet допускает использовать стороннюю инфраструктуру X.509, если встроенная не устраивает.
  • Вся конфигурация (Среда) должна храниться в системе контроля версий и развёртываться на каждом сервере одновременно.
  • Единственное общее - это база PostgreSQL, организация высокой доступности которой выходит за рамки данной статьи.
  • Модуль cfpuppetserver поддерживает установки в качестве основного (с CA) и в качестве второстепенного сервера.

Что значимое изменилось с более старых версий

Полное описание есть у производителя .
  • Все сервисы переехали на JVM, JRuby и Jetty. За очевидными плюсами интегрированности есть и минусы по расходу памяти.
  • Добавились лямбда-функции для обработки коллекций - теперь нет необходимости пилить костыли на Ruby или извращаться через create_resources()
  • Появился инструмент обработки шаблонов EPP - по сути тот же ERB , но с Puppet DSL вместо Ruby,
  • Сильно поменялось структура каталогов конфигурационных файлов по умолчанию
  • Появилась поддержка Data Providers для Сред и Модулей (больше не требуются хаки).
  • Принижение роли глобальной Hiera. Новая связанная с этим команда puppet lookup .

Установка

Данный процесс достаточно примитивен, но требует соблюдения определённой последовательности шагов. Поскольку делать это вручную неблагодарное занятие, автор научит плохому, а именно скачивать непонятные скрипты с интернета и запускать под root"ом на своей системе.

Три основных компонента сервера - это сам Puppet Server, PuppetDB и PostgreSQL. Их всех можно запихнуть на один узел или же разбить на две-три системы. Puppet Server и Puppet DB могут быть запущены множество раз, а вот PostgeSQL является единым узлом отказа. Есть разнообразные подход к репликации и кластеризации PostgeSQL.Удобный подход в случае основного и второстепенного серверов будет Master + Read-Only Slave, что поддерживается в самом PuppetDB как основной и read-only узел базы данных, но автоматизация такой настройки требует времени и поэтому пока не входит в модуль cfpuppetserver .

Непосредственно конфигурацию можно просто хранить хоть на файловой системе вместе с Puppet Server, но это как писать скрипты на боевом веб-сервере. Самое подходящее решение - это git репозиторий. Утилита r10k умеет вытягивать все ветки репозитория и развёртывать их на Puppet Server как отдельные Среды. У r10k достаточно плохо с вытягиванием зависимостей, поэтому поверх используется librarian-puppet . Стоит сразу заметить, что основной канонической Средой Puppet является "production". Поэтому в репозитории конфигурации следует использовать ветку с названием "production", а не "master".

Системные требования

По железу описано самим производителем . Модуль cfpuppetserver пока поддерживает только Debian Jessie+ и Ubuntu Trusty+.

Конфигурация в Git

Для самого r10k размещение репозитория не имеет большого значения - главное его доступность. Например, в целях тестирования репозиторий можно разместить на той же системе с доступом через file:// . Хорошим стартом будет пример конфигурации codingfuture/puppet-exampleenv .
  1. Клонируем репозиторий: git clone https://github.com/codingfuture/puppet-exampleenv my-puppet-conf && cd my-puppet-conf
  2. Устанавливаем общие настройки админского доступа, используя подсказки в комментариях:
    • $EDITOR data/common.yaml
  3. Создадим конфигурацию узлов:
    • $MY_DOMAIN - корневое доменной имя (например, example.org)
    • $HOST_NAME - имя клиентского узла без домена
    • mkdir data/$MY_DOMAIN
    • cp data/example.com/puppet.yaml data/${MY_DOMAIN}/puppet.yaml
    • $EDITOR nano -w data/${MY_DOMAIN}/puppet.yaml - настройка узла с Puppet Server по подсказкам в комментариях
    • cp data/example.com/host.yaml data/${MY_DOMAIN}/${HOST_NAME}.yaml
    • $EDITOR nano -w data/${MY_DOMAIN}/${HOST_NAME}.yaml - настройка произвольного узла по подсказкам в комментариях
  4. Пушаем на собственный Git сервер или же делаем доступным локально на узле с Puppet Server через rsync или scp. Локальный репозиторий удобен как промежуточный шаг пока Git сервер не развёрнут с самого же Puppet. В каком-то смысле это напоминает сборку компилятора в несколько этапов.

Ставим с нуля на чистой системе

Модуль cfpuppetserver позволяет установить всё средствами самого же Puppet, но для изначального установки базовые операции продублированы скриптом Bash.

На целевой системе:

  1. Скачиваем скрипт установки: wget https://raw.githubusercontent.com/codingfuture/puppet-cfpuppetserver/master/setup_puppetserver.sh
  2. Просматриваем скрипт и хмурим бровки: less setup_puppetserver.sh
  3. Запускаем: bash setup_puppetserver.sh puppet.${MY_DOMAIN} .
    • Пример с удалённым репозиторием: bash setup_puppetserver.sh ssh://[email protected]/puppet-conf
    • Пример с локальным: bash setup_puppetserver.sh file:///root/puppetconf/
  4. Смотрим как пыжится система и не очень быстро всё устанавливает.
  5. Если удалённый репозиторий:
    • Создаём SSH ключ у root"а: ssh-keygen -t rsa -b 2048
    • Прописываем публичный ключ /root/.ssh/id_rsa.pub на удалённом сервере Git...
    • … и там же настриваем Git hook с вызовом следующей команды: /usr/bin/ssh -T deploypuppet@puppet.${MY_DOMAIN} ./puppetdeploy.sh
  6. Запускаем развёртывание конфигурации вручную: /etc/puppetlabs/deploy.sh
  7. Пробуем как работает на самом сервере: /opt/puppetlabs/bin/puppet agent --test
  8. Проверьте настройки сети, сетевого фильтра и SSH-доступа

Добавляем управляемые узлы

  1. Полное имя Puppet Server должно быть доступно через DNS на управляемом узле или же следует "зашить" в /etc/hosts.
    • Пример: echo "128.1.1.1 puppet.example.com" >> /etc/hosts
  2. На узле с Puppet Server запускаем следующий скрипт /root/genclientinit.sh ${HOST_NAME}.${MY_DOMAIN} .
  3. Результат копируем целиком и вставляем в командную строку на целевой системе.
  4. Ждём окнчания выполнения и запускаем /opt/puppetlabs/bin/puppet agent --test . При первом запуске будет сгенерирован запрос на подпись сертификата.
  5. Идём на узел Puppet Server чтобы подписать сертификат.
    • puppet cert list - сверяем сигнатуру сертификата для пущей параноидальности.
    • puppet cert sign ${HOST_NAME}.${MY_DOMAIN} - собственно, подписываем сертификат.
  6. Возвращаемся на управляемый узел и запускаем: /opt/puppetlabs/bin/puppet agent --test` ещё раз. Это принудительно запустит процедуру развёртывания.
  7. Ждём пока закончится выполнение развёртывания через Puppet Agent.
  8. Всё, у вас готова минимальная инфраструктура Puppet!

Пример вывода /root/genclientinit.sh

bash </etc/cflocation fi if test ! -z ""; then echo -n >/etc/cflocationpool fi if test ! -z "\$http_proxy"; then export http_proxy export https_proxy="\$http_proxy" export HTTP_PROXY="\$http_proxy" export HTTPS_PROXY="\$http_proxy" fi echo host.example.com > /etc/hostname hostname host.example.com if ! which lsb-release | read; then apt-get install lsb-release fi codename=\$(lsb_release -cs) if test -z "\$codename"; then echo "Failed to detect correct codename" exit 1 fi wget https://apt.puppetlabs.com/puppetlabs-release-pc1-\${codename}.deb dpkg -i puppetlabs-release-pc1-\${codename}.deb mkdir -p /etc/puppetlabs/puppet cat > /etc/puppetlabs/puppet/puppet.conf < puppet cert sign host.example.com" echo "Use CTRL+C to stop cycle, if fails due to different reasons" sleep 5 done EOT

Описание модуля

Полный список параметров Bash скрипта изначальной установки

~# ./setup_puppetserver.sh Usage: ./setup_puppetserver.sh [ [ [ [] ] ] ]
  • r10k_repo_url - URI Git репозитория
  • certname - полное доменное имя узла
  • cflocation - инициализация факта cf_location
  • cflocationpool - инициализация факта cf_location_pool
  • http_proxy - прокси сервер для HTTP и HTTPS запросов

Полный список параметров Bash скрипта инициализации клиента Puppet

~# /root/genclientinit.sh Usage: ./genclientinit.sh [ [ []]]
Значение параметров такое же, как у предыдущего скрипта.

класс cfpuppetserver

  • deployuser = "deploypuppet" - имя пользователя для автоматического развёртывания обновлений конфигурации
  • deployuser_auth_keys = undef - список ключей для $deployuser
  • repo_url = undef - URI репозитория (пример: ssh://user@host/repo или file:///some/path)
  • puppetserver = true - устанавливать ли компонент Puppet Server на данный узел
  • puppetdb = true - устанавливать ли компонент PuppetDB на данный узел
  • puppetdb_port = 8081 - порт для PuppetDB
  • setup_postgresql = true - устанавливать ли компонент PostgreSQL на данный узел (только если включена установка PuppetDB)
  • service_face = "any" - название ресурса cfnetwork::iface для принятия входящих соединений
  • puppetserver_mem = auto - оперативная память под Puppet Server в мегайбатах (минимум 192MB)
  • puppetdb_mem = auto - оперативная память под PuppetDB в мегайбатах (минимум 192MB)
  • postgresql_mem = auto - оперативная память под PostgreSQL в мегайбатах (минимум 128MB)

класс cfpuppetserver::puppetdb

  • postgresql_host = "localhost" - адрес базы данных
  • postgresql_listen = $postgresql_host - значение идёт прямо в директиву listen_addresses PostgreSQL
  • postgresql_port = 5432 - порт базы данных
  • postgresql_user = "puppetdb" - пользователь PuppetDB в базе данных
  • postgresql_pass = "puppetdb" - пароль пользователя PuppetDB в базе данных
  • postgresql_ssl = false - включение шифрования соединения на основе сертификатов Puppet PKI

класс cfpuppetserver::puppetserver

  • autosign = false - НЕ СТОИТ использовать в боевой среде, разве что в DMZ. Существует исключительно для автоматизации тестирования.
  • global_hiera_config = "cfpuppetserver/hiera.yaml" - путь к файлу конфигурации Hiera по умолчанию по канонам Puppet (первый компонент - название модуля, остальное - путь под папкой files/ в модуле)

Вы можете помочь и перевести немного средств на развитие сайта