Не так давно на страницах журнала мы рассматривали систему удаленного управления конфигурацией 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 - Типы ресурсов

Администрирование виртуальных серверов с использованием Puppet

Часть 1. Установка и настройка Puppet

Серия контента:

В процессе организации серверной среды с использованием средств виртуализации или облачных сервисов быстро растет количество отдельных серверов. Каждый раз при создании нового сервера возникает необходимость установки и конфигурации соответствующего программного обеспечения. Более того, синхронизация серверных конфигураций требует дополнительных усилий, таких, например, как написание cценариев на языке командной оболочки shell .

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

Несмотря на то, что эта программа обычно используется для управления крупными серверными структурами (например, в дата-центрах или на Web-сервисах с большим количеством пользователей), её вполне можно применить и для обслуживания нескольких серверов (скажем, в локальной сети небольшого офиса или в домашней сети).

История Puppet

Проект Puppet является разработкой компании Puppet Labs и распространяется как ПО с открытым исходным кодом (Open Source Software). Программа имеет гибкую модульную структуру: в настоящее время для Puppet написано уже более 200 модулей расширения.

Puppet поддерживается не только компанией-разработчиком, но и весьма активным сообществом пользователей .

Установка и подготовка Puppet к работе

Функционирование Puppet организовано по схеме "клиент-сервер". Каждый клиент периодически устанавливает связь с главным управляющим сервером (или несколькими такими серверами) и выполняет синхронизацию конфигурации. По умолчанию такие сеансы связи происходят каждые полчаса. Поэтому для обеспечения нормальной работы Puppet потребуются как минимум два установленных сервера: один будет выполнять функции главного управляющего сервера (master server), а другой (или другие) выступать в роли подчинённых ему серверов, то есть, в данном контексте можно назвать их серверами-"клиентами".

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

Листинг 1. Установка пакета puppet-server на главный управляющий сервер

# yum -y install puppet-server # chkconfig puppetmaster on # service puppetmaster start

Пакеты для подчинённых серверов устанавливаются на клиентских хостах, как показано в листинге 2 (команды выполняются также от имени суперпользователя root ).

Листинг 2. Установка пакета puppet на хосте-клиенте

# yum -y install puppet # chkconfig puppet on # service puppet start

Если хост главного управляющего сервера защищён сетевым экраном, а хосты-клиенты расположены "снаружи" относительно этого сетевого экрана (например, компьютеры в локальной сети), то на главном сервере необходимо открыть TCP-порт с номером 8140 и, по возможности, сделать его доступным только для клиентских хостов. Если все операции будут выполняться на одном компьютере (localhost), то никаких манипуляций с сетевым экраном не требуется.

Основы использования Puppet

С точки зрения Puppet все конфигурации определяются и описываются как ресурсы (resources ), которые можно назвать основными структурными компонентами управляющей среды. Ресурсами могут быть файлы, сервисы (server services), программные пакеты (software packages) и т.д. Более того, ресурсом может быть даже одиночный вызов команды оболочки shell. Например, описываемый в листинге 3 ресурс типа file представляет известный всем файл /etc/passwd, владельцем которого является root .

Листинг 3. Описание ресурса - файла /etc/passwd

file { "/etc/passwd": owner => root, mode => 644, }

Ресурсы можно группировать по определённым характеристикам: так, например, любой файл имеет владельца и расположен по конкретному адресу (path) в файловой системе, у каждого пользователя есть регистрационное имя (login), личный идентификатор (UID) и идентификатор группы (GID). В соответствии с этими характеристиками формируются типы ресурсов. Кроме того, самые важные характеристики типа ресурса в общем смысле одинаковы для любых операционных систем, независимо от незначительных деталей реализации. То есть описание ресурса вполне можно абстрагировать от его реализации в той или иной операционной системе.

На основе вышеописанных предпосылок сформирован уровень абстракции ресурсов (resource abstraction layer - RAL ) программы Puppet. RAL разделяет ресурсы на типы (types ), являющиеся моделями высокого уровня, и провайдеры (providers ), которые представляют более низкий уровень, то есть реализации ресурсов, зависящие от конкретной платформы. Такая организация RAL позволяет составлять описания ресурсов способом, применимым практически на любой системе.

Цикл синхронизации RAL

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

Структура описания ресурса

Как было сказано выше, в Puppet каждый ресурс является экземпляром некоторого типа (resource type ), с указания которого начинается собственно описание. Ресурс идентифицируется именем (title ), которое записывается в одиночных кавычках после открывающей фигурной скобки и сопровождается символом двоеточия. Далее с новой строки определяются атрибуты типа (attributes ), причём некоторые атрибуты являются общими для всех типов, другие же присущи только данному конкретному типу ресурса. Каждый атрибут имеет значение (value ), таким образом, записи атрибутов с соответствующими значениями имеют общую форму attribute => value .

Общее представление о синтаксисе языка описания ресурсов Puppet можно получить из листинга 4, в котором показан самый простой случай - описание ресурса типа "пользователь" (user ).

Листинг 4. Синтаксис языка описания ресурсов Puppet на примере пользователя

user { "alex": ensure => present, uid => "501", gid => "admin", shell => "/bin/bash", home => "/home/alex", managehome => true, }

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

Следующая конфигурация, демонстрируемая в листинге 5, позволяет установить пакет openssh-server , разрешить использование сервиса sshd по умолчанию и выполнить проверку, чтобы убедиться в том, что этот сервис действительно активизирован и работает.

Листинг 5. Описание ресурса - сервиса sshd (установка, запуск, проверка)

package { "openssh-server": ensure => installed, } service { "sshd": enable => true, ensure => running, require => Package["openssh-server"], }

Теперь необходимо применить описанные выше конфигурации к соответствующим серверам. В пакет Puppet по умолчанию включён специальный файл конфигурирования ресурсов site.pp , который располагается в каталоге /etc/puppet/manifests . Если параметры конфигурации ресурсов не очень сложны, то их можно добавить в этот файл вручную: например, содержимое вышеприведённых листингов 3 и 4.

После того, как все требуемые программы установлены и активированы, а файлы конфигурации сформированы, обязательно нужно зарегистрировать все подчинённые серверы (клиенты) на главном управляющем сервере и подтвердить достоверность регистрации (sign ), то есть пройти своеобразную сертификацию. На подчинённых серверах регистрация выполняется следующей командой (также требуются права суперпользователя root ):

puppetd --test --waitforcert 30 --server MASTER_SERVER_ADDRESS

Вместо MASTER_SERVER_ADDRESS следует указать реальный адрес главного управляющего сервера.

После регистрации всех необходимых клиентов на главном управляющем сервере выполняются команды, показанные в листинге 6.

Листинг 6. Сертификация зарегистрированных клиентов на главном управляющем сервере

puppetca --list # выводится список адресов зарегистрированных клиентов puppetca --sign CLIENT_SERVER_ADDRESS # вместо CLIENT_SERVER_ADDRESS следует указать реальный адрес клиента # команда повторяется для адреса каждого клиента

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

# здесь также записывается реальный адрес сервера server = MASTER_SERVER_ADDRESS

Теперь Puppet полностью настроен и работает. Автоматическая синхронизация конфигураций ресурсов подчинённых серверов будет производиться каждые 30 минут. Пронаблюдать процесс можно выполнив команду:

tail -f /var/log/messages

Заключение

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

Для более эффективного использования Puppet нужно понимать, как строятся модули и манифесты. Данное руководство ознакомит вас с работой этих компонентов Puppet на примере настройки стека LAMP на сервере Ubuntu 14.04.

Требования

• Установка Puppet (мастер и агент). Больше об этом – .
• Возможность создать хотя бы один виртуальный сервер Ubuntu 14.04 для обслуживания агентской ноды Puppet.

Основы кода Puppet

Ресурсы

Код Puppet в основном состоит из ресурсов. Ресурс – это фрагмент кода, который описывает состояние системы и определяет необходимые ей изменения. Например:

user { "mitchell":
ensure => present,
uid => "1000",
gid => "1000",
shell => "/bin/bash",
home => "/home/mitchell"
}

Объявление ресурса имеет такой формат:

resource_type { "resource_name"
attribute => value
...
}

Чтобы просмотреть все типы ресурсов Puppet, введите команду:

puppet resource --types

Больше о типах ресурсов вы узнаете в этом руководстве.

Манифесты

Манифест – это сценарий оркестровки. Программы Puppet с расширением.pp называются манифестами. Манифест Puppet по умолчанию – /etc/puppet/manifests/site.pp.

Классы

Как и в любом обычном языке программирования, классы отвечают за организацию и повторное использование частей оркестровки.

В определении класса находится блок кода, который описывает, как работает класс. Определив класс, вы можете использовать его в манифестах.

Определение класса имеет такой формат:

class example_class {
...
code
...
}

Этот код определяет класс example_class. Код Puppet будет находиться в фигурных скобках.

Объявление класса – это то место в коде, где вызывается тот или иной класс. С помощью объявления класса Puppet обрабатывает его код.

Объявление класса бывает обычным и по типу ресурса.

Обычное объявление класса добавляется в код с помощью ключевого слова include.

include example_class

При объявлении по типу ресурса класс объявляется в формате ресурса:

class { "example_class": }

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

node "host2" {
class { "apache": } # use apache module
apache::vhost { "example.com": # define vhost resource
port => "80",
docroot => "/var/www/html"
}
}

Модули

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

Модули Puppet хранятся в каталоге /etc/puppet/modules.

Написание манифеста

Потренироваться писать манифесты, модули и классы Puppet можно на примере установки стека LAMP на сервер Ubuntu (в результате получится ).

Итак, чтобы выполнить оркестровку сервера Ubuntu 14.04 и установить на него стек LAMP, нужны ресурсы для таких действий:

• установка пакета apache2.
• запуск сервиса apache2.
• установка пакета сервера MySQL, mysql-server.
• запуск сервиса mysql.
• установка пакета php5
• создание тестового сценария PHP, info.php.
• обновление индекса apt перед установкой каждого пакета.

Ниже вы найдете три примера кода Puppet, с помощью которого можно получить такую установку стека LAMP.

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

Примечание : Для тестирования лучше использовать свежий виртуальный сервер.

Пример 1: Установка LAMP с помощью одного манифеста

Манифест Puppet можно написать на агентской ноде, а затем выполнить его с помощью команды puppet apply (для этого не нужно иметь установку из мастера и агента).

В данном разделе вы научитесь писать манифесты, которые будут использовать такие типы объявления ресурсов:

• exec: выполнение команд.
• package: установка пакетов.
• service: управление сервисами.
• file: управление файлами.

Создание манифеста

Создайте новый манифест:

sudo vi /etc/puppet/manifests/lamp.pp

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

# запуск команды "apt-get update"
exec { "apt-update": # ресурс exec "apt-update"
command => "/usr/bin/apt-get update" # команда, которую запустит этот ресурс
}
# установка пакета apache2
package { "apache2":
require => Exec["apt-update"], # запрос "apt-update" перед установкой пакета
ensure => installed,
}
# запуск сервиса apache2
service { "apache2":
ensure => running,
}
# установка mysql-server
package { "mysql-server":
require => Exec["apt-update"], # запрос "apt-update" передустановкой
ensure => installed,
}
# запуск сервиса mysql
service { "mysql":
ensure => running,
}
# установка пакета php5
package { "php5":
require => Exec["apt-update"], # запрос "apt-update" перед установкой
ensure => installed,
}
# запуск сервиса info.php
file { "/var/www/html/info.php":
ensure => file,
content => "", # код phpinfo
require => Package["apache2"], # запрос пакета "apache2"
}

Применение манифеста

Чтобы использовать новый манифест, введите команду:

sudo puppet apply --test

Она выведет объёмный результат, который отображает все изменения состояния среды. Если в выводе нет ошибок, вы сможете открыть свой внешний IP-адрес или доменное имя в браузере. На экране появится тестовая страница PHP с информацией о стеке. Это значит, что Apache и PHP работают.

Теперь стек LAMP установлен на сервер с помощью Puppet.

Это довольно простой манифест, поскольку его можно выполнить на агенте. Если у вас нет мастера Puppet, другие агентские ноды не смогут использовать этот манифест.

Мастер-сервер Puppet проверяет изменения состояния сервера каждые 30 минут.

Пример 2: Установка стека LAMP с помощью модуля

Теперь попробуйте создать простой модуль, основанный на манифесте LAMP, который вы написали в предыдущем разделе.

Чтобы создать модуль, создайте в каталоге modules новый каталог (его имя должно совпадать с именем модуля). В этом каталоге должны находиться каталог manifests и файл init.pp. В файле init.pp указывается класс Puppet (его имятакже должно совпадать с именем модуля).

Создание модуля

Перейдите на мастер-сервер Puppet и создайте структуру каталогов для модуля:

cd /etc/puppet/modules
sudo mkdir -p lamp/manifests

Создайте и откройте в редакторе файл init.pp:

sudo vi lamp/manifests/init.pp

В файл вставьте класс lamp:

class lamp {
}

Скопируйте содержимое манифеста из раздела 1 и вставьте его в блок класса lamp. Теперь у вас есть определение класса lamp. Другие манифесты смогут использовать этот класс в качестве модуля.

Сохраните и закройте файл.

Использование модуля в главном манифесте

Теперь можно настроить главный манифест и с помощью модуля lamp установить на сервер стек LAMP.

На мастер-сервере Puppet отредактируйте такой файл:

sudo vi /etc/puppet/manifests/site.pp

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

node default { }
node "lamp-1" {
}

Примечание : Вместо lamp-1 укажите имя хоста своего агента Puppet, на который нужно установить стек.

Блок node позволяет указать код Puppet, который будет применяться только к некоторым нодам.

Блок default применяется ко всем агентским нодам, у которых нет индивидуального блока (оставьте его пустым). Блок lamp-1 будет применяться к агентской ноде lamp-1.

Добавьте в этот блок следующую строку, которая использует модуль lamp:

Сохраните и закройте файл.

Теперь агентская нода Puppet сможет загрузить настройки с мастер-сервера и установить стек LAMP. Если вы хотите внести изменения прямо сейчас, запустите на агенте команду:

sudo puppet agent --test

Модули – это самый удобный способ повторного использования кода Puppet. Кроме того, модули помогают логически организовать код.

Пример 3: Установка LAMP с помощью общедоступных модулей

Модуль MySQL используется аналогичным образом. Добавьте в блок ноды такие строки:

class { "mysql::server":
root_password => "password",
}

Также можно передать параметры модуля MySQL.

Добавьте ресурс, который скопирует info.php в нужное место. Используйте параметр source. Добавьте в блок node следующие строки:

file { "info.php": # имя файла ресурса
path => "/var/www/html/info.php", # целевой путь
ensure => file,
require => Class["apache"], # класс apache, который нужно использовать
source => "puppet:///modules/apache/info.php", # место, куда нужно скопировать файл
}

В этом объявлении класса используется параметр source вместо content. Этот параметр не только использует содержимое файла, но и копирует его.

Файл puppet:///modules/apache/info.php Puppet скопирует в /etc/puppet/modules/apache/files/info.php.

Сохраните и закройте файл.

Создайте файл info.php.

sudo sh -c "echo "" > /etc/puppet/modules/apache/files/info.php"

Теперь агентская нода Puppet сможет загрузить настройки с мастер-сервера и установить стек LAMP. Если вы хотите внести изменения в среду агента прямо сейчас, запустите на этой ноде команду:

sudo puppet agent --test

Эта команда загрузит все обновления для текущей ноды и установит на неё стек. Чтобы убедиться, что Apache и PHP работают, откройте IP-адрес или домен ноды в браузере:

http://lamp_1_public_IP/info.php

Заключение

Теперь вы имеете базовые навыки работы с модулями и манифестами Puppet. Попробуйте самостоятельно создать простой манифест и модуль.

Puppet отлично подходит для управления конфигурационными файлами приложений.

Tags: ,

Когда число серверов, которыми вы управляете меньше десяти — редко кто задумывается об их централизованном управлении, этого может и не требоваться. Когда серверов десятки — централизованное управление ПО и конфигурациями крайне полезно. Когда серверов сотни и тысячи — это жизненно необходимо. Программ такого рода много, например: Chef, CFEngine, … Вот о последнем и пойдет речь в этой записи.

Puppet по достоинству считается одним из лучших решений в этом роде. Его используют такие компании как Google, Citrix и Red Hat. Это собой клиент-серверное приложение написанное на языке программирования Ruby, которое распространяется в двух вариантах:

• Puppet Open Source — полностью бесплатная версия
• Puppet Enterprise — бесплатная в конфигурации до 10 серверов, далее требуется приобретение лицензий

Рассмотрим установку сервера и агента Puppet Open Source, которые присутствует в пакетах большинства современных дистрибутивов. Далее речь пойдет о Ubuntu 12.04 Precise Pangolin.

Серверная часть Puppet называется puppetmaster , начнем установку с нее:

:~# apt-get install puppetmaster

А теперь клиент:

:~# apt-get install puppet

В конфигурационном файле клиента /etc/puppet/puppet.conf необходимо рассказать о сервере, добавив следующую секцию:

Server=puppet.local report=true pluginsync=false

На первоначальном этапе pluginsync лучше выключить.

Запустим клиент puppet чтобы он создал запрос на получение сертификата:

:~# puppetd --verbose --test info: Creating a new SSL key for linux.local info: Caching certificate for ca info: Creating a new SSL certificate request for linux.local info: Certificate Request fingerprint (md5): E5:EA:AC:5B:22:9A:BA:42:B8:A1:63:9E:1F:1F:23:51 Exiting; no certificate found and waitforcert is disabled

На сервере необходимо проверить что запрос сертификата получен и, если это так, выписываем сертификат:

:~# puppetca --list "linux.local" (E5:EA:AC:5B:22:9A:BA:42:B8:A1:63:9E:1F:1F:23:51) :~# puppetca --sign linux.local notice: Signed certificate request for linux.local notice: Removing file Puppet::SSL::CertificateRequest linux.local at "/var/lib/puppet/ssl/ca/requests/linux.local.pem"

Повторяем предыдущий шаг на клиенте:

:~# puppetd --verbose --test info: Caching certificate for linux.local info: Retrieving plugin info: Caching certificate_revocation_list for ca info: Caching catalog for linux.local info: Applying configuration version "1356278451" info: Creating state file /var/lib/puppet/state/state.yaml notice: Finished catalog run in 0.02 seconds

Отлично, все работает. Переходим к созданию первого манифеста. Манифесты, они же конфигурации описываются на специальном декларативном языке. Будем сразу приучаться к хорошему, использовать модульную структуру и классы. Для примера напишем модуль который будет поддерживать в актуальном виде файл /etc/hosts на всех наших серверах.

Проверим, где puppet ищет модули:

:~# puppet apply --configprint modulepath /etc/puppet/modules:/usr/share/puppet/modules

Создаем каталоги для своего модуля

:~# cd /etc/puppet/modules :~# mkdir hosts; cd hosts; mkdir manifests; cd manifests

Первый манифест, он же основной файл модуля — должен называться init.pp

Class hosts { # puppet.local host { "puppet.local": ensure => "present", target => "/etc/hosts", ip => "192.168.0.1", host_aliases => "puppet", } # linux.local host { "linux.local": ensure => "present", target => "/etc/hosts", ip => "192.168.0.2", host_aliases => "linux", } }

По-умолчанию puppet ищет файл /etc/puppet/manifests/site.pp чтобы загрузить конфигурацию, приведем его к следующему виду:

Node default { include hosts }

Проверяем манифест на сервере:

:~# puppet apply --verbose /etc/puppet/manifests/site.pp info: Applying configuration version "1356281036" notice: /Stage//Host/ensure: created info: FileBucket adding {md5}notice: /Stage//Host/ensure: created notice: Finished catalog run in 0.03 seconds

На клиенте:

:~# ll /etc/hosts rw-r--r-- 1 root root 290 Dec 16 19:10 /etc/hosts :~# puppetd --verbose --test info: Caching catalog for linux.local info: Applying configuration version "1356283380" info: FileBucket adding {md5}notice: /Stage/Hosts/Host/ensure: created notice: /Stage/Hosts/Host/ensure: created notice: Finished catalog run in 0.04 seconds :~# ll /etc/hosts -rw-r--r-- 1 root root 551 Dec 23 20:43 /etc/hosts

После того как мы убедились что все работает, разрешаем запуск службы, в /etc/default/puppet меняем:

# Start puppet on boot? START=yes

Запускаем службу

:~# service puppet start

Puppet будет каждые 30 минут опрашивать сервер puppetmaster на предмет изменения конфигурации и, при необходимости, производить соответствующую настройку системы.