Puppet: установка и настройка puppet-сервера и puppet-агента на CentOS

Автор: | 04/08/2014
Нет комментариев
 

puppet-logo

Установка Puppet-master

Puppet в репозиториях состоит из двух пакетов – puppet-server и puppet (puppet-клиент).

Находим пакеты:

# yum list puppet*
...
puppet.noarch 2.7.25-2.el6                                                                       epel
puppet-gluster.noarch 0.0.3-1.el6                                                          epel
puppet-gluster-doc.noarch 0.0.3-1.el6                                                 epel
puppet-server.noarch 2.7.25-2.el6                                                         epel
puppetlabs-stdlib.noarch 4.2.1-1.20140510git08b00d9.el6      epel

Доступны оказались только в репозитории Epel.

Мы же добавим родной репозиторий Puppet и будем устанавливать из него.

Выбираем архитектуру:
http://yum.puppetlabs.com/el/6/products/

И последний пакет на момент написания статьи – puppetlabs-release-6-10.noarch.rpm.

Устанавливаем его:

# rpm -ivh http://yum.puppetlabs.com/el/6/products/i386/puppetlabs-release-6-10.noarch.rpm
Retrieving http://yum.puppetlabs.com/el/6/products/i386/puppetlabs-release-6-10.noarch.rpm
warning: /var/tmp/rpm-tmp.9A3aN7: Header V4 RSA/SHA1 Signature, key ID 4bd6ec30: NOKEY
Preparing... ########################################### [100%]
1:puppetlabs-release ########################################### [100%]

Проверяем:

# yum repolist | grep puppet
puppetlabs-deps Puppet Labs Dependencies El 6 - i386 64
puppetlabs-products Puppet Labs Products El 6 - i386 403

Устанавливаем сам puppet-server:

# yum -y install puppet-server

Среди зависимостей у него так же Ruby, на котором написан Puppet. Всё должно установится вместе, при чём обратите внимание на puppet-пакеты, что бы они шли из репозитория Puppetlabs:

Installing:
puppet-server noarch 3.6.2-1.el6                             puppetlabs-products                          24 k

В файле /etc/hosts добавляем запись (это важно – имя хоста должно быть доступно и назначено и серверу, и клиенту):

# head -n 2 /etc/hosts
127.0.0.1 localhost puppet
192.168.1.109 centos_3

Проверяем имя машины:

# hostname
centos_3

Стартуем:

# service puppetmaster start
Starting puppetmaster: [ OK ]

Сервер работает на порту 8140:

# netstat -anp | grep 8140
tcp 0 0 0.0.0.0:8140 0.0.0.0:* LISTEN 2665/ruby

Добавляем правило в IPTABLES:

# iptables -I INPUT 2 -p tcp --dport 8140 -j ACCEPT

И, если нету, то:

# iptables -I -INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

Сохраняем:

# service iptables save
iptables: Saving firewall rules to /etc/sysconfig/iptables:[ OK ]

Добавляем в автозапуск:

# chkconfig puppetmaster on

Проверяем:

# chkconfig --list | grep puppetmaster
puppetmaster 0:off 1:off 2:on 3:on 4:on 5:on 6:off

Файлы и клиента и сервера хранятся в каталоге /etc/puppet:

# ls -l /etc/puppet
total 28
-rw-r--r--. 1 root root 4178 Jun 10 00:09 auth.conf
drwxr-xr-x. 3 root root 4096 Jul 2 12:18 environments
-rw-r--r--. 1 root root 1462 Jun 10 00:08 fileserver.conf
drwxr-xr-x. 2 root root 4096 Jun 10 00:09 manifests
drwxr-xr-x. 2 root root 4096 Jun 10 00:09 modules
-rw-r--r--. 1 root root 853 Jun 10 00:08 puppet.conf

Файлы fileserver.conf и auth.conf используются для настройки файлового сервера и аутентификации – мы их пока трогать не будем.

Каталог manifests содержит в себе “манифесты”, которые являются файлами настройки для клиентов. Основной из них – файл site.pp, который будет считываться мастером всегда, и его настройки будут применяться ко всем клиентам (если другое не указано в самом манифесте).

Посмотреть все текущие настройки можно командой:

# puppet apply --configprint all

Отдельные – так:

# puppet master --configprint ssldir
/var/lib/puppet/ssl

Теперь создадим файл site.pp, который будет нашим управляющим манифестом, в него добавим строки:

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

Установка и настройка Puppet-клиента

Устанавливаем Puppet-репозиторий и puppet-клиент:

# yum -y install puppet

Проверяем имя хоста в /etc/hosts (или на DNS-сервере, если имеется):

# cat /etc/hosts
127.0.0.1 localhost
192.168.1.110 centos_4
192.168.1.109 centos_3

Тут centos_4 – это машина-клиент, а centos_3 – машина-сервер.

Проверяем на клиенте имя хоста:

# hostname
centos_4

На клиенте редактируем файл /etc/puppet/puppet.conf и в блок [agent] добавляем :

server = centos_3

Тут важно замечание – во многих мануалах говорится про puppetcca, puppetd и т.п. – но в версии 3.0 они отсутствуют (первая колонка – старая команда, во второй – новая):

puppetmasterd puppet master
puppetd puppet agent
puppet puppet apply
puppetca puppet cert
ralsh puppet resource
puppetrun puppet kick
puppetqd puppet queue
filebucket puppet filebucket
puppetdoc puppet doc
pi puppet describe

Следующий шаг – создание сертификата клиента, выполняем:

# puppet agent --server centos_3 --waitforcert 60 --test
Info: Creating a new SSL key for centos_4
Info: Caching certificate for ca
Info: csr_attributes file loading from /etc/puppet/csr_attributes.yaml
Info: Creating a new SSL certificate request for centos_4
Info: Certificate Request fingerprint (SHA256): 51:08:F6:EA:88:5F:4D:74:0D:2A:A6:D4:F1:6C:D0:3A:90:81:9B:A0:9F:9F:88:18:9C:CA:A9:B7:E7:E4:3B:8C
Info: Caching certificate for ca
Notice: Did not receive certificat

На сервере проверяем пришёл ли запрос от клиента (нода, или node в терминологии Puppet):

# puppet cert list
"centos_4" (SHA256) 51:08:F6:EA:88:5F:4D:74:0D:2A:A6:D4:F1:6C:D0:3A:90:81:9B:A0:9F:9F:88:18:9C:CA:A9:B7:E7:E4:3B:8C

Обратите внимание на имя хоста во время генерации сертифката – вот почему важно их везде установить верно.

Подписываем клиента:

# puppet cert --sign centos_4
Notice: Signed certificate request for centos_4
Notice: Removing file Puppet::SSL::CertificateRequest centos_4 at '/var/lib/puppet/ssl/ca/requests/centos_4.pem'

И на стороне клиента в течении 60-ти секунд должно появится сообщение:

Info: Caching certificate for centos_4
Info: Caching certificate_revocation_list for ca
Info: Retrieving pluginfacts
Error: Could not retrieve pluginfacts: Parameter source failed on File[/var/lib/puppet/facts.d]: Could not understand source puppet://centos_3/pluginfacts: the scheme puppet does not accept registry part: centos_3 (or bad hostname?)
Wrapped exception:
Could not understand source puppet://centos_3/pluginfacts: the scheme puppet does not accept registry part: centos_3 (or bad hostname?)
Wrapped exception:
the scheme puppet does not accept registry part: centos_3 (or bad hostname?)
Info: Retrieving plugin
Error: Could not retrieve plugin: Parameter source failed on File[/var/lib/puppet/lib]: Could not understand source puppet://centos_3/plugins: the scheme puppet does not accept registry part: centos_3 (or bad hostname?)
Wrapped exception:
Could not understand source puppet://centos_3/plugins: the scheme puppet does not accept registry part: centos_3 (or bad hostname?)
Wrapped exception:
the scheme puppet does not accept registry part: centos_3 (or bad hostname?)
Info: Caching catalog for centos_4
Info: Applying configuration version '1404297834'
Notice: /Stage[main]/Main/File[/etc/passwd]/group: group changed 'root' to 'bin'
Info: Creating state file /var/lib/puppet/state/state.yaml
Notice: Finished catalog run in 0.05 seconds

Ошибка Error: Could not retrieve pluginfacts вызвана тем, что по-умолчанию включена опция синхронизации плагинов, которых у нас нет.

Можно либо установить плагины (в следующий раз), либо отключить эту синхронизацию.

Для этого на клиенте в puppet.conf, в блоке [main]  устанавливаем:

pluginsync = false

Запускаем:

# puppet agent

Добавляем в автозапуск:

# chkconfig puppet on

Проверяем:

# service puppet status
puppet (pid 3069) is running...
# ps aux | grep puppet
root 3069 1.5 3.5 43420 36580 ? Ss 14:11 0:00 /usr/bin/ruby /usr/bin/puppet agent

Теперь проверим как всё работает.

Редактируем файл site.pp на сервере и изменим права:

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

на:

file { "/etc/passwd":
owner => "root",
group => "bin",
mode => 777,
}

Сначала посмотрим на файл на клиенте сейчас:

# ls -l /etc/passwd
-rw-r--r--. 1 root bin 1390 Jul 2 13:10 /etc/passwd

Теперь – можно либо подождать 30 минут, пока агент сам запросит изменения, либо перезапустить его, либо настроить не меньший интервал запросов изменений от мастера.

Выберем последний вариант – редактируем файл puppet.conf на клиенте, и устанавливаем в блоке [agent] опцию:

runinterval = 10

Где 10 – количество секунд меду запросами.

Сохраняем, выходим, и видим на сервере в логе каждые 10 секунд сообщение:

[2014-07-02 14:32:37] 192.168.1.110 - - [02/Jul/2014:14:32:37 EEST] "GET /production/node/centos_4?fail_on_404=true&transaction_uuid=cb1ea3c9-abcf-4da1-a00c-3b8292b30abf HTTP/1.1" 200 4100
[2014-07-02 14:32:37] - -> /production/node/centos_4?fail_on_404=true&transaction_uuid=cb1ea3c9-abcf-4da1-a00c-3b8292b30abf

Проверяем файл на клиенте:

# ls -l /etc/passwd
-rwxrwxrwx. 1 root bin 1390 Jul 2 13:10 /etc/passwd

Всё работает.

Не забываем вернуть значение 644.

Ссылки по теме

http://www.ibm.com
http://kolbosa.kz
http://www.xakep.ru
http://ru.wikibooks.org

Официальная документация

Главный HowTo
http://docs.puppetlabs.com

Что такое “ресурсы”
http://docs.puppetlabs.com

Что такое “манифесты”
http://docs.puppetlabs.com

Описание схемы мастер-клиент
http://docs.puppetlabs.com

Краткий гайд по установке
http://docs.puppetlabs.com