WWW.APPSERVGRID.COM

Puppet Configuration.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Puppet на FreeBSD
Эта статься преследует целью придания импульса системного администратору о том, как использовать Puppet (инструмент для настройки управления), для управления конфигурациями серверов, особенно на FreeBSD.
Что вы будете знать…
 Что такое puppet
 Как разворачивать серверы используя Puppet
 Различные сценарии в развертывании серверов используя Puppet
Что вы должны знать…
 Основы сетевой конфигурации в FreeBSD
 Основные знания о системе портов в FreeBSD
Использование Puppet для управления конфигурациями серверов имеет следующие преимущества:
 Автоматическая инсталляция сервера
 Массовое развертывание изменений на серверах
 Обеспечить согласованность состояния сервера
Puppet может быть использован для автоматической инсталляции ПО и конфигурации при развертывании серверов. Это особенно полезно при развертывании нескольких серверов с аналогичными конфигурациями службы (например, sudoers, ssh daemon, web службы и другие).
Puppet также полезен в ситуациях где скрипт или программа должна быть развернута на группе серверов. После первоначального развертывания, изменения могут также быть вытолкнуты из Puppet мастера на эту группу серверов с минимальными усилиями.
Часть работы системного администратора это быть уверенным, что сервер находится в состоянии желаемой формы; например ssh демон должен всегда спрашивать публичные ключи, а аутентификация по паролю должна быть отключена. Системный администратор должен настроить конфигурационные файлы и установить окружение соответственно на всех серверах, а службы (например, ssh, ntp, named…) должны быть всегда запущены или должны перезапускаться при загрузке изменений.
Puppet написан на Ruby и лицензирован Apache (с 2.7.6 предыдущие были под лицензией GPL). Это ответвление cfEngine, другого мощного инструмента управления конфигурацией. Puppet относительно легко поднять и начать использовать из-за его декларативного языка. Вместо чтения типичных длинных руководств по языку или учебнику по изучению Puppet, эта статься проведет нас через основные шаги того, как установить клиент/серверную модель Puppet. Затем мы расскажем о наиболее распространенных сценариях, чтобы получить представление о том, как Puppet работает.
Картина
В этом разделе, FreeBSD сервера, участвующие в клиент/серверной модели Puppet должны выглядеть (быть установлены) так:
 Инсталляция и конфигурация Puppet на мастере и агенте. Это всего лишь о SSL сертификате подписи между puppet мастером и его агентом.
 Инсталляция портов использует систему портов FreeBSD, чтобы развернуть последовательную конфигурацию sudoers и ssh демона puppet агентом. Затем установить и настроить веб-сервер Apache, автоматически.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Листинг 1. Инсталляция Puppet

# cd /usr/ports/sysutils/puppet
# make install clean

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Для достижения того, что описано выше, мы разобьем установку на следующие части:
Часть I: установка Puppet мастера и агента
 Инсталляция puppet и других утилит
 Настройка конфигурационных файлов puppet:

• /usr/local/etc/puppet/puppet.conf
• /usr/local/etc/puppet/fileserver.conf
• /usr/local/etc/puppet/manifests/site.pp
• /usr/local/etc/puppet/manifests/classes/*.pp
• /usr/local/etc/puppet/auth.conf
• /etc/rc.conf

 Подпись сертификата puppet мастера и агента

Часть II:различные сценарии развертывания
 Использование puppet для настройки конфигурации sudoers агента
 Настройка и конфигурирование ssh демона
 Настройка и конфигурирование веб сервера Apache 2.2
Эти серверы будут выполнять следующие роли:
 Puppet-master.example.com – это сервер будет puppet мастером. Он будет ответственным за выталкивание конфигураций в puppet агента.
 Puppet-agent.example.com – puppet агент. Он будет получать инструкции от мастера puppet и соответствующим образом их разворачивать. В данном случае, развертывание sudoers конфигураций, ssh демона и веб сервера Apache.
К этому моменту вы должны были заметить, что сервер требует полного доменного имени. Puppet мастер будет назван как puppet-master.example.com и puppet-agent.example.com.

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Листинг 2. скелет создания файлов

# mkdir -p /usr/local/etc/puppet/manifests/classes
# mkdir -p /usr/local/etc/puppet/files
# touch /usr/local/etc/puppet/files/sudoers
# touch /usr/local/etc/puppet/files/sshd_config
# touch /usr/local/etc/puppet/files/httpd.conf
# touch /usr/local/etc/puppet/manifests/classes/resource_group.pp
# touch /usr/local/etc/puppet/fileserver.conf
# touch /usr/local/etc/puppet/manifests/site.pp
# touch /usr/local/etc/puppet/manifests/classes/resource_group.pp

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Отказ от ответственности: конфигурационные файлы, включенные в этой статье, минимум, для того, чтобы вызвать puppet мастера/агента и это контролируемые службы, они могут быть непригодны для производства. Используйте на свой страх и риск!
Как puppet работает
Puppet использует отношения мастера и агента, чтобы контролировать своих клиентов с сервера. Puppet мастер будет выталкивать инструкции в агента, а агент будет затем исполнять их.
Эти действия называются ресурсами. Ресурсы могут быть группой в классах для формирования более управляемых функций. Эти ресурсы затем выполняются на узле или агенте. Существуют различные типы ресурсов, например, ресурсы файлов, ресурсы пакетов, пользовательские ресурсы и многое другое.
Поведение puppet:
 Puppet использует SSL, чтобы обезопасить соединения между мастером и агентом.
 Разрешение Puppet мастера ресурса определено в файле /usr/local/etc/puppet/auth.conf.
 Puppet мастер конфигурационный файл /usr/local/etc/puppet/puppet.conf.
 Puppet агенту не нужен /usr/local/etc/puppet/puppet.conf для правильной работы.
 Puppet сообщения об ошибках отсортированы в /var/log/messages.

Структура дерева, показанная ниже, какие файлы и каталоги необходимы для puppet мастера для функционирования:

/usr/local/etc/puppet

1. auth.conf
2. files
2.1 httpd.conf
2.2 sshd_config
2.3 sudoers
3. fileserver.conf
4. manifests
4.1 classes
4.1.1 resource_group.pp
4.1.2 something.pp
4.1.3 site.pp
5. puppet.conf
Часть I: настройка puppet мастера и агента
Подготовка puppet-master.example.com: Листинг 1. Настройка и конфигурирование: Листинг 2. настройка puppet мастера: Листинг 3
Измените следующие параметры /usr/local/etc/puppet/puppet.conf:

factsource = puppet://puppet-master.example.com/facts/
pluginsource = puppet://puppet-master.example.com/plugins

Создайте следующие файлы с этим содержимым: Листинг 4 и Листинг 5.
И наконец, запустите puppet мастер для прослушивания запросов на подпись сертификата, чтобы он мог вытолкнуть инструкции puppet агенту. В листинге 5, определены puppet агенты различных хостов и указаны какие ресурсы будут вытолкнуты. В этой начальной настройке, нет ничего. Мы вернемся к этому разделу снова, когда будут выполняться различные сценарии. Подготовка puppet-agent.example.com: листинг 7-9. Начало сессии на подпись сертификата от puppet агента к puppet мастеру:

# puppet agent -v --server puppet-master.example.com --waitforcert 60 --test

Листинг 3. Конфигурация puppet мастера

# puppet master --genconfig /usr/local/etc/puppet/puppet.conf
# cp /usr/local/etc/puppet/auth.conf-dist /usr/local/etc/puppet/auth.conf

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Листинг 4 /usr/local/etc/puppet/fileserver.conf

[files]
path /usr/local/etc/puppet/files
allow *.example.com
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Листинг 5. /usr/local/etc/puppet/manifests/site.pp

import "classes/*.pp"
filebucket { main: server => puppet-master.example.com }
File { backup => main }
Exec { path => /usr/bin:/usr/sbin/:/bin:/sbin }
node puppet-agent.example.com { }
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Листинг 6. запуск puppet мастера

# echo 'puppetmaster_enable="YES"' >> /etc/rc.conf
# /usr/local/etc/rc.d/puppetmaster start
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Пока это происходит, подписывается сертификат в puppet-master.example.com: Листинг 10. Когда сертификат подписан, сессия подписания сертификата puppet агента будет завершена. Подождите, для того, чтобы завершиться. Запустите puppet агент в puppet-agent.example.com добавив следующее в /etc/rc.conf: Листинг 11. Запустите puppet агент для того, чтобы он смог опросить инструкции от puppet мастера:

# /usr/local/etc/rc.d/puppet start

Теперь, когда puppet мастер и агент более или менее установлены, убедитесь, что не произошло никаких ошибок в /var/log/messages.
Часть II: Различные сценарии развертывания
В puppet-master.example.com, создается собственный файл sudoer, который в конечном итоге будет размещен в puppet агенте: Листинг 12.

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Листинг 7. Установка puppet агента и некоторых зависимостей

# cd /usr/ports/sysutils/puppet
# make install clean
# cd /usr/ports/ports-mgmt/portupgrade
# make install clean
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Листинг 8. установка и настройка puppet агента
# hostname puppet-agent.example.com
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Листинг 9. /usr/local/etc/puppet/auth.conf
path /run
method save
allow puppet-master.example.com
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Листинг 10. подписывание сертификата в puppet мастере

# puppet cert --list --all
# puppet cert --sign puppet-agent.example.com
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Листинг 11. /etc/rc.conf

puppet_enable="YES"
puppet_flags="-v --listen --server puppet-master.example.com"
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Создание класса, группирование этих ресурсов: листинг 13.
Включите этот ресурс (в классе) в узле (puppet агент), так что puppet мастер может вытолкнуть это puppet агенту: листинг 14. Активировать эти изменения puppet агенту. Он затем получит каталог и выполнит необходимые действия на агенту:

# puppet kick puppet-agent.example.com

Как только puppet агент обновляет эти конфигурации, настроенный файл sudoers должен быть загружен в /usr/local/etc/sudoers и посмотреть идентичен ли он тому, который мы создаем в puppet-master.example.com. Этот сценарий демонстрирует, что puppet способен вытолкнуть конфигурационные файлы из puppet мастера в его агента.
В листинге 13, файлы типа ресурсов включает в класс с именем sudoers. Всякий раз, когда узлу нужно использовать этот ресурс, мы можем использовать синтаксис включенный в класс sudoers. Этот же ресурс мы используем множество раз на другом узле. Также ключевое слово источник указывает источник файла, который будет в месте в /usr/local/etc/sudoers. Этот URL адрес должен быть абсолютным, параметр [файлы] в листинге 4. Для более подробной информации о типах ресурсов, посмотрите http://docs.puppetlabs.com/references/stable/type.html.

Сценарий 2: установка и конфигурирование ssh демона
Кроме того, сервисы и конфигурационные файлы могут быть управляемыми с puppet мастера. Это как для развертывания настроенного демона ssh с файлом конфигурации, и вытолкнуть его в puppet агент.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Листинг 12 /usr/local/etc/puppet/files/sudoers

root ALL=(ALL) ALL
bob ALL=(ALL) NOPASSWD: ALL
joe ALL=(ALL) NOPASSWD: ALL
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Листинг 13. /usr/local/etc/puppet/manifests/classes/resource_group.pp

class sudoers {
file { "/usr/local/etc/sudoers":
ensure => file,
owner => root,
group => wheel,
mode => 440,
source => "puppet:///files/sudoers",
}
}
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Листинг 14. /usr/local/etc/puppet/manifests/site.pp

node 'puppet-agent.example.com' {
include sudoers
}
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Листинг 15. /usr/local/etc/puppet/files/sshd_config

PermitRootLogin no
StrictModes yes
PubkeyAuthentication yes
PermitEmptyPasswords no
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Листинг 16. /usr/local/etc/puppet/manifests/classes/resource_group.pp

class sshd {
owner => root,
group => wheel,
mode => 0644,
source => "puppet:///files/sshd_config",
}
service { 'sshd_services':
ensure => running,
name => "sshd",
enable => true,
hasrestart => true,
hasstatus => true,
subscribe => File['/etc/ssh/sshd_config'],
}
}
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Листинг 17. /usr/local/etc/puppet/manifests/site.pp

node 'puppet-agent.example.com' {
include sudoers
include sshd
}
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Листинг 18. /usr/local/etc/puppet/files/httpd.conf

ServerRoot "/usr/local"
Listen 80
LoadModule authz_host_module libexec/apache22/mod_authz_host.so
LoadModule include_module libexec/apache22/mod_include.so
LoadModule log_config_module libexec/apache22/mod_log_config.so
LoadModule mime_module libexec/apache22/mod_mime.so
LoadModule dir_module libexec/apache22/mod_dir.so
User www
Group www
ServerAdmin webmaster@example.com
ServerName example.com:80
DocumentRoot "/usr/local/www/apache22/data"
<Directory />
AllowOverride None
Order deny,allow
Deny from all
</Directory>
<Directory "/usr/local/www/apache22/data">
Options Indexes FollowSymLinks
AllowOverride None
Order allow,deny
Allow from all
</Directory>
<IfModule dir_module>
DirectoryIndex index.php index.htm index.html
</IfModule>
ErrorLog "/var/log/httpd-error.log"
LogLevel warn
DefaultType text/plain
<IfModule mime_module>
TypesConfig etc/apache22/mime.types
AddType application/x-compress .Z
AddType application/x-gzip .gz .tgz
AddType application/x-httpd-php .php .aspx
AddType application/x-httpd-php-source .phps
</IfModule>
Include etc/apache22/extra/httpd-default.conf
Include etc/apache22/Includes/*.conf
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Листинг 19. /usr/local/etc/puppet/manifests/classes/resource_

group.pp
class apache22 {
package { www/apache22:
ensure => installed,
provider => ports,
}
file { "/usr/local/etc/apache22/httpd.conf":
owner => root,
group => wheel,
mode => 0640,
source => "puppet:///files/httpd.conf",
require => Package['www/apache22'],
}
service { 'apache22_service':
ensure => running,
name => 'apache22',
enable => true,
hasrestart => true,
hasstatus => true,
subscribe => File['/usr/local/etc/apache22/
httpd.conf'],
}
}
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Листинг 20. /usr/local/etc/puppet/manifests/site.pp

node 'puppet-agent.example.com' {
include apache22
include sudoers
include sshd
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Затем ssh демон в puppet агенте будет перезапущен, чтобы изменения вступили в силу. В puppet-master.example.com создается индивидуальный конфигурационный файл демона ssh:
листинг 15. Обновление файла класса puppet так, что этот ресурс может быть использован позже: листинг 16. Точно также, включен этот ресурс в узел, так, что puppet мастер может вытолкнуть его: листинг 17. Воздействие на puppet агента для того, чтобы обновить свой каталог:

# /usr/local/etc/rc.d/puppet restart

После того как puppet агент обновлен, конфигурационный файл ssh демона должен быть загружены в puppet-agent.example.com и ssh демон перезапущен.
В сервисе тип ресурса в соответствии с классом sshd, параметр гарантирует, убедитесь в этом, что сервис sshd запущен. Также убедитесь, что параметр подписывается всякий раз когда файл /etc/sshd/sshd_config изменяется, он будет перезапускать службу.
Для более полной информации по другим доступным параметра посетите http://docs.puppetlabs.com/references/2 ... meter.html. Для сервисов поддерживаемых в FreeBSD посетите http://docs.puppetlabs.com/references/2 ... ml#service.
Сценарий 3: установка и конфигурирование веб сервера apache 2.2
В этом сценарии, puppet мастер будет инструктировать агента по инсталляции apache 2.2 и скачает желаемый настроенный httpd.conf в puppet агент. Затем apache 2.2 веб сервис будет перезапущен, чтобы новые параметры вступили в силу. В puppet-master.example.com, создастся индивидуальный конфигурационный файл apache (Листинг 18). Еще раз, создается ресурс в файле класса: листинг 19. Точно так же, включает этот ресурс так, что puppet мастер может вытолкнуть его в puppet агента: листинг 20. Отдадим puppet агенту:
# /usr/local/etc/rc.d/puppet restart
После того, как puppet агент обновится, apache 2.2 должен быть установлен, с конфигурационными файлами загруженными в узел puppet-agent.example.com и перезапущенным сервисом apache 2.2. Это, вероятно, займет некоторое время, как только нужно будет скачать необходимые файлы и запустить установку через систему портов FreeBSD. В этом сценарии мы охватываем два новых параметра для типов ресурсов, а именно поставщика и потребителя. Параметр поставщик говорит puppet использовать порты (источник), а не пакеты, чтобы установить ПО. Что же касается потребителя, то он говорит агенту puppet что ПО apache 2.2 должен быть установлен прежде, чем применить /usr/local/etc/apache22/httpd.conf и перезапустить веб-сервис apache 2.2. В приведенном выше примере настройки и сценарии, puppet продемонстрировал, что способен развернуть файлы конфигурации и сервисы. Puppet может быть использован в большинстве случаев, чтобы облегчить работу системного администратора при развертывании новой установки, выталкивая конфигурационные файлы и действия на серверы, а также упорядочения политики между серверами. После прочтения этой статьи, я надеюсь, что вы получите представление о том, как puppet может помочь в управлении конфигурацией также хорошо, как и управлении серверами FreeBSD.
В сети:
• http://docs.puppetlabs.com/ – Документация Puppet Labs,
• http://docs.puppetlabs.com/learning/ – Изучение Puppet.
Эдвард Тан
Изо дня в день администрирует кучу серверов, работающих на FreeBSD. В свободное время он ведет технические блоги на http://psybermonkey.net, изучает Perl и думает о том, как внести свой вклад в сообщество FreeBSD.
01/2012 BSD Magazine