Puppet, система управления конфигурациями. Часть II

    R2-D2 и C-3PO
    В первой части я рассказал об основных особенностях системы управления конфигурациями 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.
    Поделиться публикацией
    Ой, у вас баннер убежал!

    Ну. И что?
    Реклама
    Комментарии 11
      0
      Спасибо
        +1
        Всегда пожалуйста! :-)
        +3
        Хотелось бы отметить, что при массовых установках может очень помочь cobbler — небольшой provisioning-сервер. Можно создать заранее сконфигурированный образ и раскидать на нужное количество машин по сети (pxe-install). Одно из основных правил администрирования — start every host in known state.

        Собственно, эти два продукта (puppet и cobbler), насколько мне известно, активно интегрируются в Red Hat Satellite (система управления и мониторинга инфраструктуры на RHEL'ах) и находящийся в разработке open-source аналог satellite'а — Spacewalk.
          0
          Спасибо за полезную информацию! Сейчас в статью добавлю.
            +1
            Только учтите, пожалуйста, относительную кроссплатформенность cobbler'а — пока что его, в основном, на rhel/centos/suse/fedora/debian/ubuntu используют. Но, полагаю, описанные дистрибутивы практически в полной мере описывают «linux server», так что вряд ли тут будет проблема — слакварщики/гентушники/бздшники все равно, в большинстве случаев, любят сами все ручками раскидывать. :)
              0
              Не вопрос, дело мастера боится. В общем-то в статье и используется как раз Ubuntu, так что в тему :-)
            0
            на данный момент puppet в spacewalk нету, оно значится только в future ideas:
            Use puppet project as an alternative solution to replace our current Configuration File/Directory management tools — provide a richer usage than the basic capabilities we have today
              0
              Все правильно: «Examples of free & and open source management products that may be able to integrate with Spacewalk and Satellite in the future include projects like Cobbler (for provisioning management) and Puppet (a configuration management project.) In addition, projects like Cobbler and Puppet have already been adopted by a number of Red Hat customers. We believe that the participation within the community is a critical success factor for any open source initiative.»

              Cobbler уже начали интегрировать, puppet если не начали, то скоро начнут. Штуки-то полезные.
                0
                cobbler уже давно да
              +1
              Для debian-like есть еще FAI, которая умеет pxe-установку и создание CD/DVD образов
                0
                Спасибо, добавил в статью!

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

            Самое читаемое