Ключевые слова:puppet, linux, config, (найти похожие документы)
From: spanasik
Date: Mon, 9 Jan 2010 17:02:14 +0000 (UTC)
Subject: Puppet, система управления конфигурациями
Оригинал: http://habrahabr.ru/blogs/linux/67471/http://habrahabr.ru/blogs/linux/68532/Puppet - это инструмент, который позволяет автоматизировать
настройку и управление большим парком машин. Используя Puppet вы
сможете централизованно управлять конфигурациями одной, десятков, сотен
и тысяч машин.
В этой статье я расскажу об основных особенностях системы.
Puppet написана на Ruby, архитектура - клиент-серверная. На каждом
управляемом узле находится клиент, который периодически обращается по
https к серверу за обновлениями конфигурации.
Puppet, система управления конфигурациями
Язык управления конфигурациями
Конфигурация описывается на специальном языке. Базовыми элементами
конфигурации являются ресурсы. Каждый ресурс имеет тип, атрибуты и
название. Самый простой пример ресурса, файловый:
file { "/etc/passwd":
owner => "root"
}
Этот ресурс включает проверку владельца файла /etc/passwd, и если он
отличен от root, Puppet устанавливает юзера root хозяином этого файла.
Ресурсы можно (и обычно нужно) группировать в классы. Например, класс
для Postfix будет содержать ресурсы и для установки и для настройки
почтового сервера Postfix.
Одним из главных элементов описания конфигурации является узел (node).
Узел позволяет описывать функциональность определённого типа. Скажем,
можно описать узел "офисный десктоп", или "веб-сервер".
Соответственно, для офисного десктопа будет установлено и настроено всё
необходимое для офиса ПО, а для веб-сервера какой-нибудь апач или
nginx.
Вообще, язык описания конфигурации поддерживает практически все фичи
нормального ООП-языка. Так что, по сути получается, что вы как бы
программируете поведение машин. Действительно, в результате получается
довольно наглядное описание, которое легко читать и понимать.
Сообщество пользователей делится своими наработками, в терминах Puppet они
называются "рецептами".
Где и как это работает ?
Следующее, что необходимо отметить, это платформонезависимость. Ваши
сценарии могут разворачиваться одинаково на Linux и FreeBSD, все
особенности конкретной платформы учитываются клиентом Puppet. Вы можете
ознакомиться со списком поддерживаемых платформ, чтобы убедиться,
что ваша любимая ОС поддерживается Puppet. Windows в этом списке нет,
но сообщается, что Puppet в ней работает через cygwin.
Что касается производительности. Она и сейчас довольно неплохая.
Скажем, вы можете управлять 50-100 машинами с помощью довольно
средненького сервера с 2 гигами памяти. Однако, на подходе версия 0.25,
в которой одной из главных фич является переход с XML-RPC на REST, что
означает существенное улучшение производительности.
Кроме того, как практически любой веб-сервис, Puppet масштабируется.
Puppet можно запускать с помощью nginx и Mongrel. Так что вы можете не
опасаться ситуации, когда вдруг ваша организация разрастётся до больших
размеров, Puppet с этой работой справится :-)
Резюме
Завершая эту вводную статью, хочу особенно отметить тот факт, что
Puppet может быть очень полезен для вас, даже если у вас всего один
сервер. Имея хорошо задокументированный конфиг, в случае краха сервера
вы очень быстро сможете развернуть хозяйство на другом сервере, так как
установка и настройка почти всего, что нужно, будет осуществлена в
автоматическом режиме.
Часть II
В первой части я рассказал об основных особенностях системы
управления конфигурациями 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 в комменте описывает возможный вариант разлива
образов по сетке:
Хотелось бы отметить, что при массовых установках может очень помочь
cobbler - небольшой provisioning-сервер. Можно создать заранее
сконфигурированный образ и раскидать на нужное количество машин по
сети (pxe-install). Одно из основных правил администрирования -
start every host in known state.
Собственно, эти два продукта (puppet и cobbler), насколько мне
известно, активно интегрируются в Red Hat Satellite (система
управления и мониторинга инфраструктуры на RHEL'ах) и находящийся в
разработке open-source аналог satellite'а - Spacewalk.
Для debian-like есть еще FAI, которая умеет pxe-установку и создание CD/DVD образов
А вот хрен, если cobbler уже заинтегрировали в spacewalk то Puppet и не собираются, так что опять придется строить огороды, но уже масштабы не сервера а сети >_<
