Настройка современного Puppet сервера с нуля

от автора

Недавно я переосмыслил процедуру установки нового сервера Puppet с нуля на Ubuntu 12.04, включая все современные свистелки и перделки. В итоге у меня получился этот гайд.

Для начала нам потребуется чистая Ubuntu c работающей сетью и настроенным DNS.

В итоге мы должны получить:

  • Установленый везде Puppet 3-й версии
  • Конфиги в git репозитории с общим доступом
  • Динамические окружения, управляемые r10k
  • Поддержку PuppetDB
  • Поддержку Hiera

Данное руководство довольно длинное, т.к. все настройки делаются вручную, чтобы впоследствии легко можно было пользоваться результатом и подстраивать его под себя. Единственным исключением является PuppetDB, который проще установливать через собственный модуль от Puppet Labs, а не вручную.

Предполагается, что все команды будут выполнены от пользователя root на сервере Puppet, если не указано иное.

Установка Puppet

Добавьте репозиторий Puppet Labs, путем установки их пакета:

source /etc/lsb-release wget https://apt.puppetlabs.com/puppetlabs-release-$DISTRIB_CODENAME.deb dpkg -i puppetlabs-release-$DISTRIB_CODENAME.deb rm puppetlabs-release-$DISTRIB_CODENAME.deb 

Установите Puppet и Puppet Master:

apt-get update apt-get install puppet puppetmaster 

Примечание от переводчика: документация Puppet Labs рекомендует устанавливать puppetmaster-passenger.

Настройка Puppet

Создайте директорию, в которой будут расположены настройки ваших окружений и дайте группе puppet права на запись:

mkdir /etc/puppet/environments chgrp puppet /etc/puppet/environments chmod 2775 /etc/puppet/environment 

Мы никогда не будем редактировать содержимое данной директории напрямую, за нас это будет делать r10k через git hook, который мы настроим чуть позже.

Теперь необходимо сделать некоторые настройки в файле /etc/puppet/puppet.conf. Вот неплохой пример, с которого вы можете начать:

[main]   environment   = production   confdir       = /etc/puppet   logdir        = /var/log/puppet   vardir        = /var/lib/puppet   ssldir        = $vardir/ssl   rundir        = /var/run/puppet   factpath      = $vardir/lib/facter   templatedir   = $confdir/templates   pluginsync    = true  [agent]   environment   = production   report        = true   show_diff     = true  [master]   environment   = production   manifest      = $confdir/environments/$environment/manifests/site.pp   modulepath    = $confdir/environments/$environment/modules:$confdir/environments/$environment/site   # Passenger   ssl_client_header        = SSL_CLIENT_S_DN   ssl_client_verify_header = SSL_CLIENT_VERIFY 

Примечание от переводчика: начиная с версии 3.6, переменные manifest/modulepath/config_version устарели в пользу окружений.

Если у вас еще не настроено определение имени "puppet" в DNS, вы можете добавить server = your.server.com в секцию [main].

Настройка Hiera

Hiera так же требует некоторой конфигурации. Создайте файл /etc/puppet/hiera.yaml:

--- :hierarchy:   - "nodes/%{::fqdn}"   - "manufacturers/%{::manufacturer}"   - "virtual/%{::virtual}"   - common :backends:   - yaml :yaml:   :datadir: "/etc/puppet/environments/%{::environment}/hieradata" 

Для того, что бы сделать отладку Hiera немного проще и избежать путаницы в дальнейшем, я предпочитаю заменить файл /etc/hiera.yaml (о котором Puppet даже не подозревает) символической ссылкой на /etc/puppet/hiera.yaml:

ln -sf /etc/puppet/hiera.yaml /etc/hiera.yaml 

Проверка работоспособности Puppet

Сейчас самое время перезапустить сервис Puppet Master:

/etc/init.d/puppetmaster restart 

Проверьте работоспособность Puppet агента:

puppet agent --test 

В результате вы должны получить нечто похожее:

Info: Retrieving plugin Error: /File[/var/lib/puppet/lib]: Could not evaluate: Could not retrieve information from environment production source(s) puppet://testpm.qix.no/plugins Info: Caching catalog for testpm.qix.no Info: Applying configuration version '1384949455' Info: Creating state file /var/lib/puppet/state/state.yaml Notice: Finished catalog run in 0.03 seconds 

Единственная ошибка может быть проигнорирована, т.к. у нас еще нет ни конфигов, ни плагинов.
Перед тем как продолжать, удостоверьтесь, что данная команда работает. Проблемы на данном этапе скорее всего связаны с DNS.

Установка r10k

Бесподобный Adrien Thebo создал такую же бесподобную утилиту для управления динамическими окружениями Puppet и эффективного использования внешних модулей — неважно, нашли ли вы их на Puppet Forge или храните их в своем собственном репозитории.
Дополнительную информацию вы можете найти на страничке GitHub. Для установки выполните команды:

apt-get install rubygems gem install r10k 

Настройка r10k

Необходимо создать директорию с кешами, в которой r10k будет хранить копии модулей:

mkdir /var/cache/r10k chgrp puppet /var/cache/r10k chmod 2775 /var/cache/r10k 

И конечно же, r10k имеет свой файл с настройками. Создайте /etc/r10k.yaml со следующим содержимым:

# location for cached repos :cachedir: '/var/cache/r10k'  # git repositories containing environments :sources:   :base:     remote: '/srv/puppet.git'     basedir: '/etc/puppet/environments'  # purge non-existing environments found here :purgedirs:   - '/etc/puppet/environments' 

Установка git

К сожалению, версия git, которая идет в поставке Ubuntu 12.04, подвержена этому багу, который устанавливает неверные права (0755) на все новые окружения Puppet. Это не позволяет расшаривать репозитории между несколькими пользователями.

Добавьте PPA от команды поддержки git:

apt-get install python-software-properties add-apt-repository ppa:git-core/ppa 

Установите последнюю стабильную версию git:

apt-get update apt-get install git 

Создание git репозитория

Теперь создайте новый git репозиторий, который станет главным источником Puppet конфигурации для вашего сервера.
Все ваши администраторы будут работать с этим репозиторием, а r10k будет обновляться из него, чтобы автоматически создавать (или удалять) окружения Puppet.
Создайте новый репозиторий в /srv/puppet.git:

git init --bare --shared=group /srv/puppet.git chgrp -R puppet /srv/puppet.git cd /srv/puppet.git git symbolic-ref HEAD refs/heads/production 

Обратите внимание, что у этого репозитория есть три отличительных особенности:

  1. он bare;
  2. он shared;
  3. ветка master переименована в production.

Настройка прав доступа

Пришло время начать настраивать Puppet в git репозитории.
Вы не должны работать с git репозиторием из под пользователя root, поэтому добавьте своего пользователя в группу puppet, которая будет использована для ограничения доступа к репозиторию:

adduser <myuser> puppet 

Перелогиньтесь, что бы изменения вступили в силу.
Еще раз проверьте членство в группе, выполнив данную команду от обычного пользователя:

id | grep puppet 

Создание git хука

Продолжайте работать под своим обычным пользователем.
Создайте файл /srv/puppet.git/hooks/post-receive, который будет запускать r10k при каждом push’е в репозиторий:

#!/bin/bash  umask 0002  while read oldrev newrev ref do     branch=$(echo $ref | cut -d/ -f3)     echo     echo "--> Deploying ${branch}..."     echo     r10k deploy environment $branch -p     # sometimes r10k gets permissions wrong too     find /etc/puppet/environments/$branch/modules -type d -exec chmod 2775 {} \; 2> /dev/null     find /etc/puppet/environments/$branch/modules -type f -exec chmod 664 {} \; 2> /dev/null done 

Не забудьте сделать скрипт исполняемым:

chmod 0775 /srv/puppet.git/hooks/post-receive 

Создание первого окружения

Перейдите в домашнюю директорию под своим обычным пользователем и склонируйте пустой репозиторий:

cd git clone /srv/puppet.git cd puppet 

Создайте несколько необходимых директорий:

mkdir -p hieradata/nodes manifests site 

Папку modules мы не создаем, т.к. она будет управляться через r10k. Локальные модули (т.е. модули исключительно для данного puppet master сервера) будут располагаться в директории site.
Теперь давайте приступим к настройке r10k. Создайте файл Puppetfile в корне репозитория со следующим содержимым:

# Puppet Forge mod 'puppetlabs/ntp', '3.0.0-rc1' mod 'puppetlabs/puppetdb', '3.0.0' mod 'puppetlabs/stdlib', '4.1.0' mod 'puppetlabs/concat', '1.0.0' mod 'puppetlabs/inifile', '1.0.0' mod 'puppetlabs/postgresql', '3.2.0' mod 'puppetlabs/firewall', '0.4.2'  # A module from your own git server #mod 'custom', #  :git => 'git://git.mydomain.com/custom.git', #  :ref => '1.0' 

Формат файла Puppetfile был впервые предложен Тимом Шарпом (Tim Sharpe) для использования в librarian-puppet, поэтому используйте его как источник документации.
Два важных момента о Puppetfile:

  • В отличии от команды puppet module, r10k не поддерживает автоматическую обработку зависимостей (для версии 1.1.0). Вы должны включить все зависимости вручную.
  • Вы можете ссылаться на git коммиты заменяя теги на git хеши. Для тестирования вы даже можете переключить ветку, установив ref на что-нибудь типа master, но это возможно не очень хорошая идея в боевом окружении.

Теперь мы настроим два модуля, подключив их через Hiera.
Все хосты должны иметь ntp модуль, поэтому создайте файл hieradata/common.yaml со следующим содержимым:

--- classes:   - ntp  ntp::servers:   - 0.pool.ntp.org   - 1.pool.ntp.org   - 2.pool.ntp.org   - 3.pool.ntp.org 

Нашему puppet master серверу требуется модуль puppetdb, поэтому создайте файл hieradata/nodes/$(hostname -f).yaml и добавьте в него необходимый класс с дефолтными настройками:

--- classes:   - puppetdb   - puppetdb::master::config 

Наконец, создайте очень простой манифест manifests/site.pp, который будет включать все классы, которые мы определили в Hiera:

hiera_include('classes') 

Commit и push

Оставайтесь в git репозитории — пришло время выполнить commit и push первой версии окружения production.
Из-за того, что git не позволяет сохранять пустые директории, а у нас пока что нет локальных модулей, добавьте фиктивный файл директорию site:

touch site/.keep 

Удостоверьтесь, что у вас правильная ветка, добавьте все файлы и выполните commit и push:

git checkout -b production git add * git commit -a -m "initital commit" git push -u origin production 

В результате вы должны получить примерно такой ответ:

Counting objects: 11, done. Compressing objects: 100% (5/5), done. Writing objects: 100% (11/11), 867 bytes | 0 bytes/s, done. Total 11 (delta 0), reused 0 (delta 0) remote:  remote: --> Deploying production... remote:  To /srv/puppet.git  * [new branch]      production -> production Branch production set up to track remote branch production from origin. 

Обратите внимание на сообщение --> Deploying production..., которое означает, что наш git хук сработал.
Вы может так же проверить, что директория /etc/puppet/environments/production была создана и содержимое ее папки modules содержит модули Puppet Forge, которые мы перечислили в Puppetfile.

Запуск Puppet

Переключитесь обратно на пользователя root и запустите puppet агента:

puppet agent --test 

Вы должны получить несколько экранов вывода черного и зеленого текста, описывающих прогресс инсталляции и конфигурации NTP и PuppetDB сервисов, включая базу данных PostgreSQL, необходимую для PuppetDB.
Проверьте, что сервисы запущены:

/etc/init.d/ntp status /etc/init.d/puppetdb status 

Проверка PuppetDB

Запустите puppet еще раз, чтобы наполнить данными postgresql:

puppet agent --test 

После этого запустите такую команду:

puppet node status $(hostname -f) 

Вы должны получить примерно такой ответ:

testpm.qix.no Currently active Last catalog: 2013-11-20T13:22:05.036Z Last facts: 2013-11-20T13:22:00.437Z 

Полезный совет: попробуйте следующую команду, чтобы увидеть всю информацию о вашем хосте, которую хранит puppetdb в отформатированном json:

puppet node find $(hostname -f) | python -mjson.tool 

Теперь puppetdb полностью настроен и вы можете использовать экспорт ресурсов для таких вещей как распределение ssh ключей по всем хостам.

Проверка Hiera

Если вы дошли до этого шага, значит Hiera уже работает, но вам может быть неоходимо во время разработки потестировать Hiera из командной строки.
Надеюсь, вы последовали моему совету и сделали файл /etc/hiera.yaml символической ссылкой на /etc/puppet/hiera.yaml. Тогда следующая команда перечислит все классы, которые будут применены к текущему хосту в production окружении:

hiera -a classes ::environment=production ::fqdn=$(hostname -f) 

В результате вы должны получить:

["puppetdb", "puppetdb::master::config", "ntp"] 

Процесс работы с Puppet Master

Создание веток в git не требует особых усилий, поэтому процесс разработки будет выглядеть так:

# создайте новую ветку и сделайте требуемые изменения git checkout -b new_feature vim somefile git add somefile git commit -m "best feature ever"  # новая ветка == новое окружение git push --set-upstream origin new_feature  # проведите тесты (ведь вы это будете делать на тестовом сервере, не так ли?) puppet agent --test --noop --environment new_feature puppet agent --test --environment new_feature  # diff and merge git checkout production git diff ..new_feature git diff --name-only new_feature git merge new_feature  # выложите новую фичу в production git push  # удалите локальную ветку git branch -d new_feature  # удалите ветку с сервера == удалить окружение git push origin :new_feature 

Процесс работы с модулями

Если вы работаете над модулем, который вы хотите использовать на нескольких серверах Puppet Master (но не отдавать наружу), один из способов это сделать — выложить на внутренний git сервер и настроить ветку, над которой вы работаете в Puppetfile:

mod 'my_app',   :git => 'git://git.mydomain.com/my_app.git',   :ref => 'master' 

Данный модуль будет обновляться под последний коммит в ветке master каждый раз когда вы делаете push репозитория /srv/puppet.git. А что, если вы не делали никаких изменений в этот репозиторий? В таком случае просто выполните r10k явно. Даннная команда обновит все модули во всех окружениях:

r10k deploy environment -p 

Для обновления только окружения testing:

r10k deploy environment testing -p 

Единственная проблема при запуске r10k таким образом это то, что при этом могут поехать права в /etc/puppet/environments, что приведет к проблемам в расшаренном репозитории. Что бы этого избежать создайте скрипт /usr/local/bin/deploy и дайте ему права на исполнение:

#!/bin/sh  umask 0002  r10k deploy environment $1 -p  find /etc/puppet/environments -mindepth 1 -type d -exec chmod 2775 {} \; find /etc/puppet/environments -type f -exec chmod 0664 {} \; 

Теперь при обновлении модулей, которые настроены на определенную ветку, вы можете запустить команды:

# обновить все модули во всех окружениях deploy  # обновить все модули в тестовом окружении deploy testing 

После окончания работы над своем модулем, не забудьте создать для него тег:

git tag -a 1.0 -m "finally no error messages" git push --tags 

… и обновите ваш Puppetfile, что бы ссылаться по имени тега, а не по имени ветки. Чуть позже вы будете благодарны себе за это.

Заключение

Теперь вы должны иметь прочную и современную (ну, на какое-то время) базовую конфигурацию Puppet. Удачи!

Рекомендую почитать

Дополнения от переводчика

У себя на Puppet Master я настроил связку gitolite+gitlist. Все репозитории лежат в gitolite, изменения можно удобно просматривать в браузере (gitlab мне показался слишком монструозным с большим количеством зависимостей и ненужным в моем случае функционалом). Директория /etc/puppet тоже лежит в отдельном git репозитории (environments добавлены в .gitignore)
Для мониторинга отчетов я использую puppetexplorer — очень удобный интерфейс для PuppetDB, работающий на стороне клиента (написан на AngularJS и CoffeeScript).

Ссылки:

ссылка на оригинал статьи http://habrahabr.ru/post/229867/


Комментарии

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *