The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Puppet, система управления конфигурациями (puppet linux config)


<< Предыдущая ИНДЕКС Исправить src / Печать Следующая >>
Ключевые слова: 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 образов

<< Предыдущая ИНДЕКС Исправить src / Печать Следующая >>

Обсуждение [ RSS ]
  • 1, fxp (?), 10:02, 27/02/2010 [ответить]  
  • +/
    А вот хрен, если cobbler уже заинтегрировали в spacewalk то Puppet и не собираются, так что опять придется строить огороды, но уже масштабы не сервера а сети >_<
     
     
  • 2, sHaggY_caT (ok), 12:49, 01/03/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Cobbler дружится с puppet:

    https://fedorahosted.org/cobbler/wiki/UsingCobblerWithConfigManagementSystem

    А вообще, имхо, "котлеты отдельно", "мухи отдельно": пусть Spacewalk управляет пакетами, а Puppet конфигурацией:)

     

  • 3, www2 (??), 11:30, 05/06/2010 [ответить]  
  • +/
    А что-нибудь поинтереснее изменения прав на файл нельзя было описать? Описанное можно и shell-скриптом по ssh сделать.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Заголовок:
    Текст:




    Спонсоры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2022 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру