Использование Puppet для настройки конфигураций

Сценарий 1 – используем Puppet для настройки конфигурации sudo на агенте

 

На машине puppet-master.example.com создайте требуемый файл sudoers, который будет передан и

развернут на Puppet агенте:

Создайте класс, который объединяет “ресурсы”:

Включите “ресурс” (в классе) в “узел” (нужный Puppet-агент) так, чтобы мастер-узел мог бы отправить его на агент:

Активируем проведенное изменение путем “толкания” агента. Который затем самостоятельно скачает каталог изменений и совершит необходимые действия на машине.

# puppet kick puppet-agent.example.com

 

Как только агент получит извещение об измененных конфигурациях, он загрузит файл sudoers к себе. Проверьте /usr/local/etc/sudoers и убедитесь, совпадает ли он с тем вариантом, что мы редактировали на мастер-узле puppet-master.example.com. Этот сценарий приведен для того,чтобы показать, что Puppet действительно умеет синхронизировать конфигурации со своей главной машины с подчиненными агентами.

 

В Листинге 2.1.2 тип ресурса “файл” включен в класс под названием “sudoers”. Если какому-либо узлу требуется использовать данный ресурс, то мы можем с помощью синтаксической конструкции “include” добавить класс “sudoers” в нужный узел. Этот же ресурс может многократно использоваться и на других узлах.

Так же ключевое слово “source” определяет место нахождения файла в /usr/local/etc/sudoers. Путь к файлу должен совпадать со значением параметра “[files]” из Листинга 1.4

 

Листинг 2.1.1

– /usr/local/etc/puppet/files/sudoers

root ALL=(ALL) ALL

bob ALL=(ALL) NOPASSWD: ALL

joe ALL=(ALL) NOPASSWD: ALL

 

Листинг 2.1.2

– /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”,

}

}

 

Листинг 2.1.3 –

/usr/local/etc/puppet/manifests/site.pp

node ‘puppet-agent.example.com’ {

include sudoers}

 

  

Сценарий 2: Настройка и конфигурирование службы SSH

 

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

Посмотрим, как развернуть SSH-службу с её конфигурационным файлом на машине-агенте. После получения файлов, агент должен будет перезапустить службу, чтобы изменения вошли в силу.

Листинг 2.2.1 –/usr/local/etc/puppet/files/sshd_config

PermitRootLogin no

StrictModes yes

PubkeyAuthentication yes

PermitEmptyPasswords no

 

Листинг 2.2.2 – /usr/local/etc/puppet/manifests/

classes/resource_group.pp

class sshd {

file { “/etc/ssh/sshd_config”:

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’],

}

}

 

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

node ‘puppet-agent.example.com’ {

include sudoers

include sshd}

 

На мастер-узле puppet-master.example.com создайте нужный конфигурационный файл для SSH.

Обновите файл с классами, чтобы мы могли использовать новый ресурс:

Аналогичным образом включаем этот ресурс и в определение узла, чтобы Puppet знал куда именно

передавать конфигурацию:

“Толкаем” агента Puppet, чтобы он синхронизировал информацию:

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

После того, как агент получил изменения,конфигурационный файл для SSH-службы должен быть загружен на puppet-agent.example.com , а сам SSH-демон перезапуститься. Обратите внимание на параметр “ensure” в классе “sshd” ресурсного типа “service”. Он предназначен для проверки, что служба SSH работает. Параметр “subscribe” предназначен для слежения за изменением файла “/etc/ssh/sshd_config”, чтобы в случае такового Puppet на агенте перезапустил службу.

  

Сценарий 3: настройка и конфигурация веб-сервера Apache 2.2

 

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

Создаем нужную конфигурацию для Apache на мастер-узле puppet-master.example.com

Еще разок создадим нужный ресурс в классе:

Как и всегда добавляем ресурс в нужный агент,чтобы мастер-узел знал куда передавать изменения:“Толкаем” агент Puppet:

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

После обновления информации на агенте, на нем должна начаться инсталляция Apache 2.2. вместе с получением конфигурационного файла для веб-сервера на узле puppet-agent.example.com, после чего будет перезапущена служба “apache22”. На эту процедуру уйдет некоторое время, т.к. операционная система FreeBSD на агенте должна будет загрузить нужный исходник через систему портов и пройти через фазу инсталляции.

В этом сценарии мы встретили два новых параметра для ресурсов – “provider” и “require”. Первый информирует Puppet, что он должен использовать для инсталляции программ порты (т.е. компиляцию из исходных текстов) вместо бинарных пакетов  (pkg).

Второй же параметр – “require” – предназначен для указания, что сначала должен быть установлен Apache22, а потом применены действия в отношении файла /usr/local/etc/apache22/httpd.conf. И только после этого, веб-служба “apache22” может быть перезапущена.

 

Листинг 2.3.1 – /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 

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

 

Листинг 2.3.2 –/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’],

}

}

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

node ‘puppet-agent.example.com’ {

include apache22

include sudoers

include sshd}

 

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

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *