Puppet сервер установка и настройка. Устанавливаем puppet и создаем свой первый манифест Использование модуля в главном манифесте

Советы

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

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 на предмет изменения конфигурации и, при необходимости, производить соответствующую настройку системы.

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

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

Ознакомившись с отзывами я решил использовать puppet.

Puppet сервер установка и настройка:
Установка puppet-сервера :
Установим puppet-server на OpenSuSE 11.4:

zypper in puppet-server

Изменим имя сервера на puppet:
/etc/HOSTNAME:

DNS запись должна резолвиться на 127.0.0.2
cat /etc/hosts:

127.0.0.2 puppet.site puppet

Дадим права для пользователя puppet :

Запустим сервис Puppet Master:

rcpuppetmasterd start

Добавим запуск puppet демона в автозагрузку:

chkconfig -a puppetmasterd

Настройка puppet-сервера:
Определим директорию, где будут храниться файлы, которые puppet-server будет передавать на машины-клиенты в манифестах типа file.

vim /etc/puppet/fileserver

path /etc/puppet/files
allow *

mkdir /etc/puppet/files

chown -R puppet:puppet /etc/puppet/files

Создадим файл любого содержания для развертывания и тестирования на клиентах

touch /etc/puppet/files/puppettesting

Перезагрузим puppet сервер:

rcpuppetmasterd restart

Puppet использует собственный язык описания конечного состояния операционной системы, с помощью которого сисадмин указывает то, к какому виду должны быть приведены компоненты ОС, чтобы она достигла желаемого состояния. Под состоянием может подразумеваться наличие определенного файла, папки, запущенных сервисов установленных пакетов, обновлений и другое. Все настройки состояний описываются в файлах или манифестах, которые расположены в каталоге: /etc/puppet/manifests. Эти файлы имею имена типа *.pp.

Создадим простейший манифест :
/etc/puppet/manifests/1.file.pp:

file { "/tmp/puppettesting" :
source => "puppet:///files/puppettesting",
}

Для применения даннного манифеста:
puppet apply 1.file.pp

Установка и настройка клиента puppet:

zypper in puppet

Дадим права puppet пользователю:

chown -R puppet.puppet /var/lib/puppet/

Для установки связи с puppet-сервером puppet-клиент посылает запрос на подтверждение сертификата, после того, как на сервере будет подтвержден этот запрос, puppet клиент начнет использовать манифесты предназначенные для него. Пошлем запрос на подтверждение сертификата:

На сервере мы можем увидеть какие запросы на подтверждение ожидают:

"puppet-client.localdomain" (B5:12 :69 :63 :DE:19 :E9:75 :32 :2B:AA:74 :06:F6:8E:8A)

Подтверждаем:

puppetca --sign "puppet-client.localdomain"

Самое время рассмотреть простейшие примеры создание манифестов:
создадим файл /etc/puppet/manifests/site.pp:

node default {
file { "/tmp/puppettesting" :
source => "puppet:///files/puppettesting" ,
}
service { "ntp" :
ensure => running,
enable => true ,
}
package { "htop" :
ensure => installed,
}
}

default - применять для всех клиентов
file - эта секция говорит создать или перезаписать файл /tmp/puppettesting который находится на сервере в каталоге /etc/puppet/files
service: проверить запущен ли сервис, если не запущен, то запустить его, а также добавить в автозагрузку
package: проверить установлен ли на клиенте пакет htop и если нет, то установить его.

Для проверки запустим на клиенте:

Как видим на клиенте был добавлен ntp в автозагрузку, запущен ntp демон, установлен пакет htop, а также скопирован файл puppettesting в директорию /tmp/

info: Caching catalog for puppet-client.localdomain
info: Applying configuration version "1370163660"
notice: / Stage[ main] // Node[ default] / Service[ ntp] / ensure: ensure changed "stopped" to "running"
notice: / Stage[ main] // Node[ default] / Package[ htop ] / ensure: created
notice: / Stage[ main] // Node[ default] / File[ / tmp/ puppettesting] / ensure: defined content as "{md5}f2171ac69ba86781bea2b7c95d1c8e67"
notice: Finished catalog run in 3.95 seconds

В следующей статье я опишу более сложные примеры создания манифестов и web-интерфейс puppet-dashboard.

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

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

Этот раздел показывает установку и настройку Puppet в конфигурации клиент/сервер. Этот простой пример демонстрирует как установить Apache с использованием Puppet .

Установка

Для установки Puppet введите в терминале:

Sudo apt-get install puppetmaster

На клиентской машине (или машинах) введите:

Sudo apt-get install puppet

Настройка

Прежде чем настраивать puppet вам возможно захочется добавить запись DNS CNAME для puppet.example.com , где example.com - это ваш домен. По умолчанию клиенты Puppet проверяют DNS на наличие puppet.example.com в качестве имени puppet сервера (Puppet Master ). Смотрите Служба доменных имен для дополнительных деталей использования DNS .

Если вы не предполагаете использовать DNS , вы можете добавить записи в файл /etc/hosts на сервере и клиенте. Например, в файл /etc/hosts Puppet сервера добавьте:

127.0.0.1 localhost.localdomain localhost puppet 192.168.1.17 meercat02.example.com meercat02

На каждом Puppet клиенте добавьте запись для сервера:

192.168.1.16 meercat.example.com meercat puppet

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

Теперь настроим некоторые ресурсы для apache2 . Создайте файл /etc/puppet/manifests/site.pp , содержащий следующее:

Package { "apache2": ensure => installed } service { "apache2": ensure => true, enable => true, require => Package["apache2"] }

Node "meercat02.example.com" { include apache2 }

Замените meercat02.example.com на актуальное имя вашего Puppet клиента.

Финальным шагом для этого простого Puppet сервера является перезапуск сервиса:

Sudo /etc/init.d/puppetmaster restart

Теперь на Puppet сервере все настроено и время настроить клиента.

Сначала настроим сервис Puppet агента для запуска. Отредактируйте /etc/default/puppet, заменив значение START на yes :

Sudo /etc/init.d/puppet start

Возвращаемся на Puppet сервер для подписи клиентского сертификата с помощью команды:

Sudo puppetca --sign meercat02.example.com

Проверьте /var/log/syslog на любые ошибки конфигурации. Если все прошло хорошо, пакет apache2 и его зависимости будут установлены на Puppet клиенте.

Этот пример очень простой и не показывает многие возможности и преимущества Puppet . Для дополнительной информации смотрите

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

Файл-сервер

Многие задачи удаленного администрирования не могут быть решены без копирования на машины дополнительных файлов. Это могут быть заранее подготовленные конфиги, веб-страницы для 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 - Типы ресурсов

Немного лирики. Казалось бы с этой статьи следует начинать весь цикл, но всё же целевой аудиторией являются более опытные пользователи 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 и обязательной проверкой клиентского сертификата.

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

Обработка по TLS и X.509 (установка соединения, обновление CRL, проверка ограничений сертификата и т.д)
Агент получает генераторы фактов с сервера с кэшированием и всеми делами (точнее вытягивается всё из папок lib/ в модулях). Не составляет никакого труда добавить свой Ruby скрипт для сбора интересующей информации.
Агент собирает факты о целевой системе и отправляет на сервер. Все факты легко просмотреть вручную через вызов puppet facts . Эти факты доступны в качестве глобальных переменных.
Сервер составляет каталог ресурсов и отправляет агенту. Под этим скрывается целый пласт различных концепций.
Агент вытягивает всё необходимое с сервера и приводит систему к указанном виду. Сам агент при этом не знает как поступать с ресурсами, он полагается на реализацию 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 .

Клонируем репозиторий: git clone https://github.com/codingfuture/puppet-exampleenv my-puppet-conf && cd my-puppet-conf
Устанавливаем общие настройки админского доступа, используя подсказки в комментариях:
- $EDITOR data/common.yaml
Создадим конфигурацию узлов:
- $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 - настройка произвольного узла по подсказкам в комментариях
Пушаем на собственный Git сервер или же делаем доступным локально на узле с Puppet Server через rsync или scp. Локальный репозиторий удобен как промежуточный шаг пока Git сервер не развёрнут с самого же Puppet. В каком-то смысле это напоминает сборку компилятора в несколько этапов.

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

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

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

Скачиваем скрипт установки: wget https://raw.githubusercontent.com/codingfuture/puppet-cfpuppetserver/master/setup_puppetserver.sh
Просматриваем скрипт и хмурим бровки: less setup_puppetserver.sh
Запускаем: bash setup_puppetserver.sh
puppet.${MY_DOMAIN} .
- Пример с удалённым репозиторием: bash setup_puppetserver.sh ssh://[email protected]/puppet-conf
- Пример с локальным: bash setup_puppetserver.sh file:///root/puppetconf/
Смотрим как пыжится система и не очень быстро всё устанавливает.
Если удалённый репозиторий:
- Создаём 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
Запускаем развёртывание конфигурации вручную: /etc/puppetlabs/deploy.sh
Пробуем как работает на самом сервере: /opt/puppetlabs/bin/puppet agent --test
Проверьте настройки сети, сетевого фильтра и SSH-доступа

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

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

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

Puppet сервер установка и настройка. Устанавливаем puppet и создаем свой первый манифест Использование модуля в главном манифесте

Установка

Настройка

Puppet?

Установка

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

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

Файл-сервер

Выводы

Info

Links

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

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

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

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

Установка

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

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

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

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

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

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

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

класс cfpuppetserver

класс cfpuppetserver::puppetdb

класс cfpuppetserver::puppetserver

Популярные статьи

Последние статьи

Разделы

Страницы

Спецпроекты

Контакты