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

Для имён хостов я решил использовать имена роботов из эпопеи Джорджа Лукаса «Звёздные войны»: R2D2 и C-3PO. Так как R2 умнее, то он будет управлять C-3PO :-)

В качестве ОС для экспериментов решил ипользовать Ubuntu Server 8.04.01-LTS. Можно было и Debian, и Cent OS, и FreeBSD — не принципиально. Ubuntu Server использую по причине простоты её настройки, дружелюбности лично для меня. Кому нравится что-то другое — не вопрос.

Управляющий сервер

Итак, начнём с R2D2, т.е. с управляющей машины. На неё мы ставим пакет puppetmaster:

sudo apt-get install puppetmaster

после выполнения этой команды управляющий сервер будет установлен и запущен под учётной записью puppet.

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

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

Здесь следует сразу отметить, что так как мы не задали никакие узлы, то все параметры, указанные в манифесте будут применены ко всем клиентским хостам. Таким образом, все машины, обратившиеся за конфигурацией к R2D2 проверят права и владельца файла /etc/passwd.

Сервер работает на порту 8140, так что в случае проблем, проверьте настройки сети, клиентские машины должны иметь доступ к порту 8140 на управляющем сервере.

Клиент

На клиент мы ставим пакет puppet:

sudo apt-get install puppet

Клиент в отличие от сервера работает под учёткой root, чтобы иметь возможность внести любые изменения в систему. Для начала клиент генерит сертификат, который при первом соединении с сервером просит подписать. Если сертификат подписывается, клиент получает актуальный конфиг, после чего применяет его к машине. В дальнейшем каждые полчаса клиент проверяет не изменилась ли конфигурация.

Добавим в конце конфига /etc/puppet/puppet.conf строчки:

[puppetd]
server=r2d2.localdomain

это говорит клиенту, с каким сервером работать. Можно указать ip, у меня ip r2d2 прописан в /etc/hosts.
ОЧЕНЬ ВАЖНО, чтобы имя сервера было в точности таким, каким подписывает сертификаты управляющий сервер. Проверить имя сервера в сертификатах можно с помощью openssl:

openssl s_client -showcerts -connect r2d2.localdomain:8140

Также закомментируем строчку:

#pluginsync=true

Эта опция задаёт синхронизацию плагинов с сервером — пока это не нужно, лучше закомментить.

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

spanasik@c3po:~$ sudo puppetd --verbose --test
info: Creating a new certificate request for c3po.localdomain
info: Creating a new SSL key at /var/lib/puppet/ssl/private_keys/c3po.localdomain.pem
warning: peer certificate won't be verified in this SSL session
notice: No certificates; exiting

Так, теперь сертификат c3po должен быть на r2d2, проверим его наличие на r2d2, и если он там, подпишем:

spanasik@r2d2:~$ sudo puppetca --list
c3po.localdomain
spanasik@r2d2:~$ sudo puppetca --sign c3po.localdomain
Signed c3po.localdomain

Сертификат подписан. Повторяем тестовый запуск клиента:

spanasik@c3po:~$ sudo puppetd --verbose --test
warning: peer certificate won't be verified in this SSL session
notice: Got signed certificate
info: No classes to store
info: Caching catalog at /var/lib/puppet/state/localconfig.yaml
notice: Starting catalog run
info: Creating state file /var/lib/puppet/state/state.yaml
notice: Finished catalog run in 0.04 seconds

Всё работает ОК. Теперь проверим, что будет, если поменять владельца файла /etc/passwd :-)
Моя учётка — spanasik, так что я назначу себя его владельцем и установлю маску 777:

spanasik@c3po:~$ sudo chown spanasik:users /etc/passwd
spanasik@c3po:~$ sudo chmod 777 /etc/passwd
spanasik@c3po:~$ ls -la /etc/passwd
-rwxrwxrwx 1 spanasik users 1084 2009-09-01 12:01 /etc/passwd

:-)

Теперь запускаем клиента puppet:

spanasik@c3po:~$ sudo puppetd --verbose --test
notice: Ignoring cache
info: No classes to store
info: Caching catalog at /var/lib/puppet/state/localconfig.yaml
notice: Starting catalog run
notice: //File[/etc/passwd]/owner: owner changed 'spanasik' to 'root'
notice: //File[/etc/passwd]/group: group changed 'users' to 'root'
notice: //File[/etc/passwd]/mode: mode changed '777' to '644'
notice: Finished catalog run in 0.03 seconds

Вуаля!

spanasik@c3po:~$ ls -la /etc/passwd
-rw-r--r-- 1 root root 1084 2009-09-01 12:01 /etc/passwd

Владелец опять root, и права как положено — 644. Ну и собственно, запускаем теперь демон клиента:

spanasik@c3po:~$ sudo /etc/init.d/puppet start
* Starting puppet configuration management tool [ OK ]
spanasik@c3po:~$ ps auxw | grep puppet | grep -v grep
root 6959 1.3 7.3 29584 18856 ? Ssl 13:46 0:00 ruby /usr/sbin/puppetd -w 0

Всё работает ОК, теперь каждые полчаса c3po будет проверять обновление конфига на r2d2 и вносить изменения в систему.

Одна машина, автоматическое развёртывание ?

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

Вы видите, что в этой статье я всё проделал вручную. Конечно, это не вариант, когда у вас сотни машин. В случае, когда у вас много машин, можно применить автоматическое развёртывание системы. Вы делаете образ для установки, и разливаете его на винчестеры. При первой же загрузке клиентская система подключится к управляющему серверу, а дальше уже можно применять дефолтный конфиг, или работать с каждой по отдельности. Отмечу, что сам я такое не делал, т.к. не админю парк машин :-)
Вот pingeee в комменте описывает возможный вариант разлива образов по сетке, за что ему большое спасибо. А уважаемый stasikos подсказывает об инструменте FAI для debian-like дистрибов, за что мы ему тоже не менее благодарны.

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