Translate

неділю, 3 лютого 2013 р.

Налаштування Puppet

Рано чи пізно мережева інфраструктура розшириться і налаштування кожної системи власноруч забиратиме дуже багато часу. У такому випадку хтось починає писати скрипти, а хтось - задумується про використання систем управління конфігураціями. Про другий варіант надалі і піде мова.

Puppet - кроссплатформове клієнт-серверне програмне забезпечення, котре дозволяє централізовано керувати конфігурацією операційних систем та програм, встановлених на групі серверів. Puppet написаний на мові програмування Ruby.

Puppet має клієнт-серверну архітектуру: puppet master (сервер) та puppet agent (клієнт):


Агент з певною частотою запитує дані в Puppet master. Сервер перевіряє адресу агента і, враховуючи конфіги (наявні маніфести, класи), надсилає необхідні запити на агент. Агент, в свою чергу, виконує перевірку стану ресурсів (права на файли, наявність пацюючого сервісу і т.д.) і змінює їх, якщо це необхідно, тобто слідує за правилами, котрі описано в маніфестах Puppetmaster.

Звісно, що агентів може бути багато, все залежить від потреб. Для прикладу буде проведено налаштування серверів:

Node-1:
Hostname: pcmk-1.clusterlabs.org
IP: 192.168.1.23

Node-2:
Hostname: pcmk-2.clusterlabs.org
IP: 192.168.1.24

Pcmk-1 буде виконувати роль Puppetmaster, а pcmk-2 - агента.  Налаштування буде проведене для Centos 6.3 з ввімкнутими репозиторіями epel. Для початку ставимо необхідне ПО на кожен із серверів, на Puppetmaster:

# yum install puppet-server

Між іншим, пакет в Ubuntu/Debian називається puppetmaster. На майбутньому клієнті робимо наступне:

# yum install puppet

Зрозуміло, що необхідно погодитись з усіма запропонованими залежностями.
Правимо конфіг Puppet-клієнта:

[root@pcmk-2]# vim /etc/sysconfig/puppet

# The puppetmaster server
PUPPET_SERVER=pcmk-1.clusterlabs.org

 # If you wish to specify the port to connect to do so here
#PUPPET_PORT=8140

 # Where to log to. Specify syslog to send log messages to the system log.
PUPPET_LOG=/var/log/puppet/puppet.log

 # You may specify other parameters to the puppet client here
#PUPPET_EXTRA_OPTS=--waitforcert=500

Дуже важливо правильно вказати параметр 'PUPPET_SERVER', адже з’єднання між сервером і клієнтом буде захищеним, тобто за допомогою сертифікату, котрий буде виписаний саме на домен. Зрозуміло, що домени мають правильно перетворюватись в IP - тому задля цього потрібно правити свій локальний DNS, чи просто відредагувати /etc/hosts. У даному випадку /etc/hosts, як сервера так і клієнта, має виглядати наступним чином:

# cat /etc/hosts

 127.0.0.1   localhost localhost.localdomain
192.168.1.23 pcmk-1.clusterlabs.org puppet
192.168.1.24 pcmk-2.clusterlabs.org

Зауважу, що puppet навпроти IP майстра стоїть через багу, що наявна в версії 2.6.17.Запускаємо Puppet master і Puppet agent на відповідних нодах і ставимо їх у автозавантаження:

[root@pcmk-2]# service puppet start && chkconfig puppet on
[root@pcmk-1]# service puppetmaster start && chkconfig puppetmaster on

Якщо запуск пройшов коректно - то клієнт має відіслати запит на сертифікат на Puppet cервер, котрий можна проглянути так:

[root@pcmk-1]# puppetca --list

 pcmk-2.clusterlabs.org

А підписати ключ необхідно таким чином:

[root@pcmk-1]# puppetca --sign pcmk-2.clusterlabs.org

Signed pcmk-2.clusterlabs.org

Тепер варто спробувати тестовий запуск клієнта і чи працює він належним чином, тому виконуємо на pcmk-2.clusterlabs.org:

[root@pcmk-2]# puppet agent --test

info: Caching catalog for pcmk-2.clusterlabs.org
info: Applying configuration version '1359588077'
notice: Finished catalog run in 0.41 seconds

Інакше ж можна отримати проблему щось на зразок:

warning: peer certificate won't be verified in this SSL session
notice: No certificates; exiting

Що власне найбільш ймовірно означає, що ви помилились з іменами доменів. Видалити сертифікат на сервері можна так.

Пересвідчуємось, що все працює правильно і пишемо перший маніфест:

[root@pcmk-1]# vim /etc/puppet/manifests/site.pp

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

class nginx {
  package { "nginx":
      ensure => installed,
  }

  service { "nginx":
      ensure => running,
      enable => true,
      subscribe => File['default.conf'],
  }

  file { 'default.conf':
      path    => '/etc/nginx/conf.d/default.conf',
      ensure  => file,
      require => Package['nginx'],
      source  => "puppet:///modules/nginx/default.conf",
    }
  }

node 'pcmk-2.clusterlabs.org' {
  include passwd
  include nginx
  }

Розглянемо перший клас passwd. Клас - це сукупність ресурсів (file, service, package). Перший клас описує стан /etc/passwd: у файла має бути власник і група root і встановлені права 644. Із певною частотою Puppet agent буде підключатись до Puppet master, підтягувати конфіг, що його стосується і застосовувати в разі не відповідності зазначеним критеріям.

Клас nginx описує установку, запуск і перевірку сервіса та налаштування конфігу /etc/nginx/conf.d/default.conf. Копія конфігу /etc/nginx/conf.d/ лежить в /etc/puppet/modules/nginx на Puppet master і в ресурсі file описується як source  => "puppet:///modules/nginx/default.conf". Тобто,якщо на Puppet клієнті зміниться конфіг default.conf /видалиться nginx/зупиниться nginx то Puppet все самостійно поверне до заданого стану.

Дуже важливими є параметри require та subscribe. Вони описують залежності між ресурсами в класі. Тобто ресурс Service['nginx'] буде виконуватись після виконання ресурсу File['default.conf'] і виконуватись повторно після його зміни (тобто на практиці при зміни конфігураційного файлу nginx, останній буде перезапускатись задля прийняття конфігу). У свою чергу ресурс File['default.conf'] залежить від Package['nginx'] і виконуватиметься лише після виконання ресурсу Service['nginx']. Тобто різниця між subscribe та require в тому, що subscribe перечитуватиме кожен раз конфіг пов’язаного з ним ресурсу у разі його зміни.

Параметр node описує клієнти, для яких власне і необхідно виконати класи.
Перевіряємо як працюють правила, на Puppet агенті виконаємо:

[root@pcmk-2 ~]# puppet agent --test

info: Caching catalog for pcmk-2.clusterlabs.org
info: Applying configuration version '1359626673'
--- /etc/nginx/conf.d/default.conf      2013-01-31 13:33:12.529795128 -0500
+++ /tmp/puppet-file20130131-1883-1i8e9y5-0     2013-01-31 13:33:37.678731354 -0500
@@ -3,7 +3,7 @@
 #
server {
     listen 80 default_server;
-    server_name testetetetetet;
+    server_name test;
     #charset koi8-r;
     @@ -21,12 +21,12 @@
     # redirect server error pages to the static page /50x.html
     #
-    error_page 501 502 503 504 /50x.html;
+    error_page 500 502 503 504 /50x.html;
     location = /50x.html {
     root /usr/share/nginx/html;
}
-    # proxy the PH iscripts to Apache listening on 127.0.0.1:80
+    # proxy the PHP scripts to Apache listening on 127.0.0.1:80
     #
     #location ~ \.php$ {
     #    proxy_pass   http://127.0.0.1;
info: FileBucket adding {md5}f947d3dbe7bb6e6c74055848b3aefaaf
info: /File[default.conf]: Filebucketed /etc/nginx/conf.d/default.conf to puppet with sum f947d3dbe7bb6e6c74055848b3aefaaf
notice: /File[default.conf]/content: content changed '{md5}f947d3dbe7bb6e6c74055848b3aefaaf' to '{md5}7da7cb10610010cf50945d67a0c5680e'
info: /File[default.conf]: Scheduling refresh of Service[nginx]
notice: /Stage[main]/Nginx/Service[nginx]/ensure: ensure changed 'stopped' to 'running'
notice: /Stage[main]/Nginx/Service[nginx]: Triggered 'refresh' from 1 events
notice: Finished catalog run in 1.29 seconds
[root@pcmk-2 ~]# 

Як бачимо, конфіги підтягнулись і було змінено default.conf, запущено і встановлено nginx. Отаким от нехитрим способом можна автоматично налаштовувати сервера і більш того слідкувати за незмінністю їх конфігурацій.


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

Немає коментарів:

Дописати коментар

Підписатися на: Дописати коментарі (Atom)