Puppet, Chef, Ansible — это так называемые системы управления конфигурациями, которые можно часто встретить в зарубежных IT вакансиях типа Server/DevOps Admin. Фактически же это мощные инструменты которые могут полностью настроить нулёвый сервер или же достаточно быстро массово перенастроить набор из 1-100+ серверов. Работа с пакетами, с командной строкой, файлами настроек, доступно всё.
Общий обзор можно прочитать в посте Как стать кукловодом
Собственно к написанию этой начальной статьи для Puppet меня сподвигло крайне скудное описание во встречающихся в интернете результатах. И даже при использовании официальной документации умудряешься наткнуться на кучу грабель и подводных камней и получить не то, что ожидал.
Причина использования ветки 3.8, вместо 4.3 заключается в использовании именно этой версии на «моих» серверах из-за наличия именно этих пакетов в репо. Платный вариант Enterprise также не рассматривается, т. к. я с ним не работал. Причина использования Centos – он достаточно широко распространён, включая доработанные версии от Amazon.
Для локальных тестов можно использовать две виртуалки на VirtualBox под CentOS-6.5-x86_64.
Для начала настраиваются два интерфейса: для выхода во внешний инет и для создания локальной сети для puppet. Hostname условно будет pmaster.test.net, а узел для клиента (можно и больше узлов) stage.test.net. Пропишем их на всех узлах в hosts (конечно если только у вас нет под них своего ДНС сервера).
10.1.1.10 pmaster.test.net 10.1.1.11 stage.test.net Доп рекомендация с офф сайта – открыть порт 8140. Также рекомендуется поставить в /etc/sysconfig/selinux параметр SELINUX=disabled.
Установка/настройка пары клиент/сервер
Начинаем установку сервера. Импортируем в систему два репо для пакетов:
rpm -ivh http://yum.puppetlabs.com/puppetlabs-release-el-6.noarch.rpm rpm -ivh http://mirror.logol.ru/epel/6/i386/epel-release-6-8.noarch.rpm Ставим пакет сервера:
yum –y install puppet-server В нагрузку поставится экзотика типа:
hiera 1.3.4-1.el6 ruby 1.8.7.374-4.el6_ rubygems 1.3.7 Т. ч. кому критично, аккуратнее с апдейтами. Как итог получаем:
/etc/init.d/puppetmaster — первый вариант работы через сервис для тестов и регистрации узлов. Далее будем переходить на вариант работы через гем под Апачем.
/etc/sysconfig/puppet — микроконфиг. Рекомендуется раскомментировать для получения отдельных логов строчку
PUPPET_LOG=/var/log/puppet/puppet.log /etc/puppet/environments — может использоваться для деления клиентов на группы, весьма неоднозначная технология, нужна, если узлов не меньше 30 и зачастую заменяется экзотической надстройкой R10K.
/etc/puppet/hieradata — используется для хранения, довольно интересная технология, требует отдельной статьи.
/etc/puppet/manifests/site.pp — основной конфиг запуска классов из модулей настройки клиентов.
/etc/puppet/modules — собственно сюда скачиваются/пишутся_свои модули для настройки клиентов, которые по сути представляют из себя набор классов (манифестов), написаных на DSL, похожем на Ruby. При желании можно даже делать вставки на чистом Ruby.
/var/lib/puppet — пока сюда не лезем, будет нужно для сертификатов.
/etc/puppet/puppet.conf — основной конфиг настройки сервера.
Добавляем в секцию [main]:
confdir = /etc/puppet server = pmaster.test.net certname = pmaster.test.net environmentpath = $confdir/environments basemodulepath = $confdir/modules default_manifest = $confdir/manifests hiera_config = $confdir/hiera.yaml environment_timeout = unlimited dns_alt_names = pmaster.test.net,stage.test.net vardir=/var/lib/puppet dns_alt_names — здесь прописываются узлы, которые могут работать с сервером через сертификаты. Тем у кого сервера сидят за проксёй и они хотят тянуть модули с forgeapi.puppetlabs.com, ползено будет знать, что puppet пофиг на ваши системные http_proxy=proxy01.int:8080 и https_proxy=proxy02.int:8080 и придётся забить в конфиг доп секцию.
[user] http_proxy_host = proxy01.int http_proxy_port = 8080 Для проверки всех текущих параметров сервера есть полезная команда:
puppet config print Причём даже демон перезагружать не надо, он всё время перечитывает свои конфиги.
На этом временно всё.
Начинаем установку клиента
Импортируем в систему два репо для пакетов:
rpm -ivh http://yum.puppetlabs.com/puppetlabs-release-el-6.noarch.rpm rpm -ivh http://mirror.logol.ru/epel/6/i386/epel-release-6-8.noarch.rpm Ставим пакет клиента:
yum –y install puppet Нам нужны:
/etc/init.d/puppet — демон клиента для автопроверок, не изменилось ли что на сервере. Мы будем пользоваться ком строкой.
/etc/sysconfig/puppet — микроконфиг. Приводим его к виду вроде:
PUPPET_SERVER=pmaster.test.net PUPPET_PORT=8140 PUPPET_LOG=/var/log/puppet/puppet.log PUPPET_EXTRA_OPTS=--waitforcert=500 /etc/puppet/puppet.conf — основной конфиг.
Добавляем в секцию [main]:
server = pmaster.test.net
Теперь нам надо сгенерировать и подписать сертификаты. На сервере будет самоподписной и сгенерируется при запуске сервера. На клиенте делаем запрос на верификацию:
puppet agent --test --ca_server=pmaster.test.net Здесь нас может поджидать первый камень типа «забыли про порт или сервис на сервере». Неявно вы увидите ошибку:
Error: Could not request certificate: No route to host - connect(2) Использовав ключ –debug, получите более подробное:
Debug: Creating new connection for https://pmaster.test.net:8140 Error: Could not request certificate: No route to host - connect(2) Ну а если всё нормально то нечто вроде:
Info: Caching certificate for ca Info: csr_attributes file loading from /etc/puppet/csr_attributes.yaml Info: Creating a new SSL certificate request for stage.test.net Info: Certificate Request fingerprint (SHA256): 89:19:56:C4:76:0F:7F:C3:14:F3:D7:91:81:8C:A3:07:C5:55:AC:32:35:F5:93:6A:1B:17:DE:AC:EB:5D:DD:44 Info: Caching certificate for ca Exiting; no certificate found and waitforcert is disabled Идём назад на сервер и проверяем список сертов:
puppet cert list --all "stage.test.net" (SHA256) 89:19:56:C4:76:0F:7F:C3:14:F3:D7:91:81:8C:A3:07:C5:55:AC:32:35:F5:93:6A:1B:17:DE:AC:EB:5D:DD:44 + "pmaster.test.net" (SHA256) 67:F8:6A:01:58:9B:1F:24:46:12:4E:5D:FB:39:60:12:79:4C:2C:6C:BE:EF:D2:27:52:95:6C:AE:B3:6C:05:1E (alt names: "DNS:pmaster.test.net", "DNS:stage.test.net") Если он без плюса, значит его надо подписать:
puppet cert --sign –all Notice: Signed certificate request for stage.test.net Notice: Removing file Puppet::SSL::CertificateRequest stage.test.net at '/var/lib/puppet/ssl/ca/requests/stage.test.net.pem' Итог должен появиться в /var/lib/puppet/ssl. Если что то пошло не так всё там стираем и повторяем заново. Собственно теперь у нас готовая конфигурация и можно посмотреть доступное народное творчество, или напрямую из командной строки:
puppet module search passwd Notice: Searching https://forgeapi.puppetlabs.com ... NAME DESCRIPTION AUTHOR KEYWORDS fraenki-vpasswd Manage virtual users @fraenki dovecot proftpd virtual user passwd wcooley-name_service Type & provider to manage system name service configuration @wcooley dns files ldap passwd lookup group reidmv-local_user Example local user pattern @reidmv user local passwd Видите имена через дефис? Это формат вида имя_автора-имя_модуля. Мы же напишем первый тестовый модуль чтобы понять схему их использования, а не забивать весь код в site.pp.
Заходим в /etc/puppet/modules и генерируем скелет:
puppet module generate myname-mytest Жмём раз 8 ввод, ибо это всё потом можно переделать.
Получаем каталог myname-mytest, который переименуем в mytest. Полное имя нужно, если вы хотите сбилдить и загрузить свой модуль на общественный forge. Нас интересует файл /etc/puppet/modules/ mytest/manifests/init.pp. В class mytest забиваем тот самый псевдоруби типа:
class mytest { file { '/tmp/puppettestfile': path => '/tmp/puppettestfile', ensure => file, content => 'test text' } file { '/tmp/puppettestdir': path => "/tmp/puppettestdir", ensure => directory } } Из особенностей:
— кавычки и апострофы взаимозаменяемы, но иногда кавычки лучше;
— запятые в конце ставьте до предпоследней строчки.
Теперь в /etc/puppet/manifests добавляем код типа:
node default { } node 'stage.test.net' { include mytest } Для теста на клиенте запускаем:
<cut />puppet agent –test И получаем что то вроде:
puppet agent --test Info: Retrieving pluginfacts Info: Retrieving plugin Info: Caching catalog for stage.test.net Info: Applying configuration version '1448981968' Notice: /Stage[main]/Mytest/File[/tmp/puppettestdir]/ensure: created Notice: /Stage[main]/Mytest/File[/tmp/puppettestfile]/ensure: defined content as '{md5}1e2db57dd6527ad4f8f281ab028d2c70' Notice: Finished catalog run in 0.15 seconds Проверим:
ls -l /tmp/puppet* -rw-r--r-- 1 root root 9 Dec 1 09:54 /tmp/puppetenv -rw-r--r-- 1 root root 9 Dec 1 09:59 /tmp/puppettestfile Теперь для чего нужен вариант с апачем. Подозреваю дело в производительности и кэшировании. Я не буду говорить сколько пламенных слов было сказано в сторону офф доков в процессе установки и настройки, но в итоге правильный вариант выглядел так:
Стопим сервис:
/etc/init.d/puppetmaster stop Ставим кучу добра:
yum install httpd yum install mod_passenger yum install mod_ssl yum install gcc-c++ yum install libcurl-devel openssl-devel zlib-devel httpd-devel ruby-devel gem install rack gem install passenger Запускаем экзотическую хрень, которая сбилдит модуль. Он может ругнуться в конце, т. ч. проверим билд и перенастроим апач потом.
passenger-install-apache2-module ls -l /usr/lib/ruby/gems/1.8/gems/passenger-5.0.21/buildout/apache2/mod_passenger.so Теперь надо создать загрузчик под puppet:
mkdir -p /usr/share/puppet/rack/puppetmasterd mkdir /usr/share/puppet/rack/puppetmasterd/public /usr/share/puppet/rack/puppetmasterd/tmp cp /usr/share/puppet/ext/rack/config.ru /usr/share/puppet/rack/puppetmasterd/ chown puppet:puppet /usr/share/puppet/rack/puppetmasterd/config.ru И снова привет /etc/puppet/puppet.conf Добавляем секцию.
[master] always_cache_features = true ssl_client_header = SSL_CLIENT_S_DN ssl_client_verify_header = SSL_CLIENT_VERIFY Настраиваем модуль и хост в Апаче. Мой вариант /etc/httpd/conf.d/passenger.conf.
LoadModule passenger_module /usr/lib/ruby/gems/1.8/gems/passenger-5.0.21/buildout/apache2/mod_passenger.so <IfModule mod_passenger.c> PassengerRoot /usr/lib/ruby/gems/1.8/gems/passenger-5.0.21 PassengerDefaultRuby /usr/bin/ruby </IfModule> PassengerHighPerformance on PassengerMaxPoolSize 12 PassengerPoolIdleTime 600 PassengerMaxRequests 1000 PassengerStatThrottleRate 120 Listen 8140 <VirtualHost *:8140> SSLEngine on SSLProtocol ALL -SSLv2 -SSLv3 SSLCipherSuite EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:+SS SSLHonorCipherOrder on SSLCertificateFile /var/lib/puppet/ssl/certs/pmaster.test.net.pem SSLCertificateKeyFile /var/lib/puppet/ssl/private_keys/pmaster.test.net.pem SSLCertificateChainFile /var/lib/puppet/ssl/ca/ca_crt.pem SSLCACertificateFile /var/lib/puppet/ssl/ca/ca_crt.pem SSLCARevocationFile /var/lib/puppet/ssl/ca/ca_crl.pem SSLVerifyClient optional SSLVerifyDepth 1 SSLOptions +StdEnvVars +ExportCertData RequestHeader unset X-Forwarded-For RequestHeader set X-SSL-Subject %{SSL_CLIENT_S_DN}e RequestHeader set X-Client-DN %{SSL_CLIENT_S_DN}e RequestHeader set X-Client-Verify %{SSL_CLIENT_VERIFY}e DocumentRoot /usr/share/puppet/rack/puppetmasterd/public RackBaseURI / <Directory /usr/share/puppet/rack/puppetmasterd/> Options None AllowOverride None Order allow,deny allow from all </Directory> ErrorLog /var/log/httpd/puppet-server_error.log CustomLog /var/log/httpd/puppet-server_access.log combined </VirtualHost> Собственно остался запуск сервиса:
/etc/init.d/httpd start И протестить это на клиенте:
puppet agent --test Ещё я заметил, что в ветке 3.8.4 теперь изменив код модуля, приходится перезапустить сервис puppetmaster или httpd, чтобы изменения применились сразу, раньше он это не игнорировал.
Создания более сложного модуля, использование Hiera и R10K и заодно описание работы с chef, который по сути наследник puppet но со своими заморочками — это тема отдельной статьи, если дойдут руки.
ссылка на оригинал статьи http://habrahabr.ru/post/272199/
Добавить комментарий