Немного лирики. Казалось бы с этой статьи следует начинать весь цикл, но всё же целевой аудиторией являются более опытные пользователи Open Source продуктов Puppet Labs, которых не устраивают отдельные малоинтегрированные модули с Puppet Forge. Как и с любым случаем "library vs. framework", расплатой является следование мировоззрению автора интегрированного решения.

Немного о принципе работы Puppet

Puppet - это в первую очередь специфичный язык декларативного задания конечного состояния системы. Для сравнения крайне подойдёт GNU Makefile, где помимо непосредственного описания зависимостей есть возможность начудить на полную катушку.

Абстракция Puppet примерно следующая (срыв шаблонов - забудьте всё, что вы знали о терминах в программировании! ).

• Узел (node) - это совокупность конфигурации для конкретной целевой системы. На деле это частный случай класса.
• Класс (class) - это набор декларативной логики, которая включается в конфигурацию узла или другие классы. У класса нет ни экземпляров, ни методов, зато есть параметры и переменные, определённые внутри логики. На деле, это скорее процедура, которая может наследовать другую процедуру банальным наращиванием кода и не совсем банальной областью видимости переменных.
• Тип (type) - а вот это уже больше смахивает на классический класс - у него предполагаются экземпляры с именем и определённо заданными параметрами, но ничего более. Конкретная реализация типа может быть написана в виде Puppet скрипта через define , который создаёт экземпляры других типов или же в виде расширения на Ruby с полётом фантазии.
• Ресурс (resource) - собственно это и есть именованные экземпляры Типов. Имя каждого ресурса уникально в рамках конкретного типа в пределах конфигурации узла (каталога).
• Переменные (variable) - ну, короче это константы… До версии Puppet 4 с их областью видимости было всё ещё хуже. Теперь она адекватна: для использования извне места определения требуется задавать полностью квалифицированный идентифиактор, за исключением случая наследования классов.

Puppet может использоваться для локального развёртывания без сети и соответствующей инфраструктуры. Это может использоваться для создания образов контейнеров. Есть даже целое направление ратующих за отказ от централизованного сервера.

В идеологически правильном ключе, инфраструктура Puppet состоит из агента - привилегированного сервиса на целевой системе и сервера, раздающего ценные указания в виде декларативных каталогов ресурсов по запросу от агентов. Безопасность реализована на уровне приватной инфраструктуры публичного ключа (X.509). Попросту говоря, тех же механизмов, что и в HTTPS, но с собственным CA и обязательной проверкой клиентского сертификата.

В упрощённом виде процедура развёртывания выглядит примерно так:

1. Обработка по TLS и X.509 (установка соединения, обновление CRL, проверка ограничений сертификата и т.д)
2. Агент получает генераторы фактов с сервера с кэшированием и всеми делами (точнее вытягивается всё из папок lib/ в модулях). Не составляет никакого труда добавить свой Ruby скрипт для сбора интересующей информации.
3. Агент собирает факты о целевой системе и отправляет на сервер. Все факты легко просмотреть вручную через вызов puppet facts . Эти факты доступны в качестве глобальных переменных.
4. Сервер составляет каталог ресурсов и отправляет агенту. Под этим скрывается целый пласт различных концепций.
5. Агент вытягивает всё необходимое с сервера и приводит систему к указанном виду. Сам агент при этом не знает как поступать с ресурсами, он полагается на реализацию provider"ов (смысловой перевод будет "воплотитель", а не поставщик) конкретных типов ресурсов. Часть provider"ов являются стандартными и входят в пакеты Puppet, а остальные вытягиваются из модулей.

Для вкушения всех прелестей, существует дополнительные плюшки в виде:

• Модуль - совокупность декларативных скриптов Puppet, Ruby расширений для Puppet, файлов, шаблонов файлов, Hiera данных и многого другого. Более правильный термин был бы "пакет".
• Среда (Environment) - совокупность скриптов, модулей и Hiera данных. С усложнением инфраструктуры неминуемо потребовалось разделять конфигурацию далее стандартного деления по узлам. В основном, это требуется для пилотных нововведений и банального контроля доступа (когда не все админы имеют доступ ко всем узлам IT инфраструктуры).
• Hiera - иерархическая база данных. Такая формулировка может сильно отпугивать. Вероятно поэтому её и поменяли в документации более поздних версий. На деле это крайне простой и удобный механизм вытягивать конфигурацию из YAML или JSON файлов. Иерархия заключается в возможности задать порядок чтения множества конфигурационных файлов - т.е. иерархию/приоритет этих файлов.
  • Помимо вытягивания данных по вызову функции, Puppet вытягивает параметры классов по умолчанию, что является главной изюминкой.
  • Разумеется, Hiera поддерживает интерполяцию фактов и даже вызов специальных функций.
  • В Puppet 4.3 реализовали этот же функционал ещё раз для поддержки не только глобальной базы данных, но и локальной для Среды и Модуля, правда автор уже нашёл несколько проблем в их реализации (PUP-5983 , PUP-5952 и PUP-5899), которые были моментально исправлены Puppet Labs.
  • Поддерживаются несколько стратегий вытягивания значения из всех файлов по иерархии:
    • first - выдаётся первое попавшиеся по приоритету значение
    • unique - собирает все значения в одномерный массив и убирает дубликаты
    • hash - объединяет все найденные YAML Hash. Дубликаты ключей выбираются по приоритету.
    • deep - по сути рекурсивный вариант hash
  • Прелесть в том, что стратегия выборки может задаваться как при вызове функции lookup() , т.к. и в любом файле иерархии через специальный ключ lookup_options , что активно используется в модуле cfnetwork .
• PuppetDB - по сути слой бизнес логики вокруг реляционной базы данных (PostgreSQL), который позволяет сохранять отчёты о фактах и проделанных развёртываниях и экспортировать ресурсы для последующего импорта в каталоги на других узлах или выборки через специальные функции. Ещё есть и веб-морда в виде Puppet Dashboard.
• X.509 PKI - уже упомянутая инфраструктура сертификатов, которую крайне удобно использовать для других сервисов без необходимости управления отдельной инфраструктурой.
• MCollective - вроде бы полезная вещь для событийного запуска задач на серверной ферме, но у автора есть определённое недоверие к безопасности конкретного решения.
• Puppet Forge - открытая площадка для публикации и скачивания Модулей.
• некоторые другие фичи в виде управления внешними устройствами типа оборудования Cisco и развёртывания на голом железе, но это уже отдельная история

Заметки по безопасности и доступности

Требуется понимать, что Puppet Server становится уязвимым местом всей IT инфраструктуры, т.к. определяет конечную конфигурацию всех систем. В особых случаях имеет смысл делать разделение - отдельный сервер для критичных элементов инфраструктуры с крайне ограниченным доступов и ручным обновлением и второй для всего остального.

Доступность Puppet Server определяет возможность управления всей инфраструктурой. Имеет смысл размещать Puppet Server на виртуалке в более надёжном и быстро восстанавливаемом стороннем облаке, чем собственные возможности. Или же следует устанавливать несколько серверов.

В любом случае, не следует устанавливать иные сервисы на системе, где будет развёрнут Puppet Server с прибамбасами. Виртуализация и контейнеризация вам в помощь.

Мульти-мастер (несколько обособленных Puppet Server)

• В данном случае только один сервер выступает в роли CA (Certificate Authority) - его недоступность означает невозможность добавить новые узлы.
  • Puppet допускает использовать стороннюю инфраструктуру X.509, если встроенная не устраивает.
• Вся конфигурация (Среда) должна храниться в системе контроля версий и развёртываться на каждом сервере одновременно.
• Единственное общее - это база PostgreSQL, организация высокой доступности которой выходит за рамки данной статьи.
• Модуль cfpuppetserver поддерживает установки в качестве основного (с CA) и в качестве второстепенного сервера.

Что значимое изменилось с более старых версий

Полное описание есть у производителя .

• Все сервисы переехали на JVM, JRuby и Jetty. За очевидными плюсами интегрированности есть и минусы по расходу памяти.
• Добавились лямбда-функции для обработки коллекций - теперь нет необходимости пилить костыли на Ruby или извращаться через create_resources()
• Появился инструмент обработки шаблонов EPP - по сути тот же ERB , но с Puppet DSL вместо Ruby,
• Сильно поменялось структура каталогов конфигурационных файлов по умолчанию
• Появилась поддержка Data Providers для Сред и Модулей (больше не требуются хаки).
• Принижение роли глобальной Hiera. Новая связанная с этим команда puppet lookup .

Установка

Данный процесс достаточно примитивен, но требует соблюдения определённой последовательности шагов. Поскольку делать это вручную неблагодарное занятие, автор научит плохому, а именно скачивать непонятные скрипты с интернета и запускать под root"ом на своей системе.

Три основных компонента сервера - это сам Puppet Server, PuppetDB и PostgreSQL. Их всех можно запихнуть на один узел или же разбить на две-три системы. Puppet Server и Puppet DB могут быть запущены множество раз, а вот PostgeSQL является единым узлом отказа. Есть разнообразные подход к репликации и кластеризации PostgeSQL.Удобный подход в случае основного и второстепенного серверов будет Master + Read-Only Slave, что поддерживается в самом PuppetDB как основной и read-only узел базы данных, но автоматизация такой настройки требует времени и поэтому пока не входит в модуль cfpuppetserver .

Непосредственно конфигурацию можно просто хранить хоть на файловой системе вместе с Puppet Server, но это как писать скрипты на боевом веб-сервере. Самое подходящее решение - это git репозиторий. Утилита r10k умеет вытягивать все ветки репозитория и развёртывать их на Puppet Server как отдельные Среды. У r10k достаточно плохо с вытягиванием зависимостей, поэтому поверх используется librarian-puppet . Стоит сразу заметить, что основной канонической Средой Puppet является "production". Поэтому в репозитории конфигурации следует использовать ветку с названием "production", а не "master".

Системные требования

По железу описано самим производителем . Модуль cfpuppetserver пока поддерживает только Debian Jessie+ и Ubuntu Trusty+.

Конфигурация в Git

Для самого r10k размещение репозитория не имеет большого значения - главное его доступность. Например, в целях тестирования репозиторий можно разместить на той же системе с доступом через file:// . Хорошим стартом будет пример конфигурации codingfuture/puppet-exampleenv .

1. Клонируем репозиторий: git clone https://github.com/codingfuture/puppet-exampleenv my-puppet-conf && cd my-puppet-conf
2. Устанавливаем общие настройки админского доступа, используя подсказки в комментариях:
   • $EDITOR data/common.yaml
3. Создадим конфигурацию узлов:
   • $MY_DOMAIN - корневое доменной имя (например, example.org)
   • $HOST_NAME - имя клиентского узла без домена
   • mkdir data/$MY_DOMAIN
   • cp data/example.com/puppet.yaml data/${MY_DOMAIN}/puppet.yaml
   • $EDITOR nano -w data/${MY_DOMAIN}/puppet.yaml - настройка узла с Puppet Server по подсказкам в комментариях
   • cp data/example.com/host.yaml data/${MY_DOMAIN}/${HOST_NAME}.yaml
   • $EDITOR nano -w data/${MY_DOMAIN}/${HOST_NAME}.yaml - настройка произвольного узла по подсказкам в комментариях
4. Пушаем на собственный Git сервер или же делаем доступным локально на узле с Puppet Server через rsync или scp. Локальный репозиторий удобен как промежуточный шаг пока Git сервер не развёрнут с самого же Puppet. В каком-то смысле это напоминает сборку компилятора в несколько этапов.

Ставим с нуля на чистой системе

Модуль cfpuppetserver позволяет установить всё средствами самого же Puppet, но для изначального установки базовые операции продублированы скриптом Bash.

На целевой системе:

1. Скачиваем скрипт установки: wget https://raw.githubusercontent.com/codingfuture/puppet-cfpuppetserver/master/setup_puppetserver.sh
2. Просматриваем скрипт и хмурим бровки: less setup_puppetserver.sh
3. Запускаем: bash setup_puppetserver.sh puppet.${MY_DOMAIN} .
   • Пример с удалённым репозиторием: bash setup_puppetserver.sh ssh://[email protected]/puppet-conf
   • Пример с локальным: bash setup_puppetserver.sh file:///root/puppetconf/
4. Смотрим как пыжится система и не очень быстро всё устанавливает.
5. Если удалённый репозиторий:
   • Создаём SSH ключ у root"а: ssh-keygen -t rsa -b 2048
   • Прописываем публичный ключ /root/.ssh/id_rsa.pub на удалённом сервере Git...
   • … и там же настриваем Git hook с вызовом следующей команды: /usr/bin/ssh -T deploypuppet@puppet.${MY_DOMAIN} ./puppetdeploy.sh
6. Запускаем развёртывание конфигурации вручную: /etc/puppetlabs/deploy.sh
7. Пробуем как работает на самом сервере: /opt/puppetlabs/bin/puppet agent --test
8. Проверьте настройки сети, сетевого фильтра и SSH-доступа

Добавляем управляемые узлы

1. Полное имя Puppet Server должно быть доступно через DNS на управляемом узле или же следует "зашить" в /etc/hosts.
   • Пример: echo "128.1.1.1 puppet.example.com" >> /etc/hosts
2. На узле с Puppet Server запускаем следующий скрипт /root/genclientinit.sh ${HOST_NAME}.${MY_DOMAIN} .
3. Результат копируем целиком и вставляем в командную строку на целевой системе.
4. Ждём окнчания выполнения и запускаем /opt/puppetlabs/bin/puppet agent --test . При первом запуске будет сгенерирован запрос на подпись сертификата.
5. Идём на узел Puppet Server чтобы подписать сертификат.
   • puppet cert list - сверяем сигнатуру сертификата для пущей параноидальности.
   • puppet cert sign ${HOST_NAME}.${MY_DOMAIN} - собственно, подписываем сертификат.
6. Возвращаемся на управляемый узел и запускаем: /opt/puppetlabs/bin/puppet agent --test` ещё раз. Это принудительно запустит процедуру развёртывания.
7. Ждём пока закончится выполнение развёртывания через Puppet Agent.
8. Всё, у вас готова минимальная инфраструктура Puppet!

Пример вывода /root/genclientinit.sh

bash </etc/cflocation fi if test ! -z ""; then echo -n >/etc/cflocationpool fi if test ! -z "\$http_proxy"; then export http_proxy export https_proxy="\$http_proxy" export HTTP_PROXY="\$http_proxy" export HTTPS_PROXY="\$http_proxy" fi echo host.example.com > /etc/hostname hostname host.example.com if ! which lsb-release | read; then apt-get install lsb-release fi codename=\$(lsb_release -cs) if test -z "\$codename"; then echo "Failed to detect correct codename" exit 1 fi wget https://apt.puppetlabs.com/puppetlabs-release-pc1-\${codename}.deb dpkg -i puppetlabs-release-pc1-\${codename}.deb mkdir -p /etc/puppetlabs/puppet cat > /etc/puppetlabs/puppet/puppet.conf < puppet cert sign host.example.com" echo "Use CTRL+C to stop cycle, if fails due to different reasons" sleep 5 done EOT

Описание модуля

Полный список параметров Bash скрипта изначальной установки

~# ./setup_puppetserver.sh Usage: ./setup_puppetserver.sh [ [ [ [] ] ] ]

• r10k_repo_url - URI Git репозитория
• certname - полное доменное имя узла
• cflocation - инициализация факта cf_location
• cflocationpool - инициализация факта cf_location_pool
• http_proxy - прокси сервер для HTTP и HTTPS запросов

Полный список параметров Bash скрипта инициализации клиента Puppet

~# /root/genclientinit.sh Usage: ./genclientinit.sh [ [ []]]
Значение параметров такое же, как у предыдущего скрипта.

класс cfpuppetserver

• deployuser = "deploypuppet" - имя пользователя для автоматического развёртывания обновлений конфигурации
• deployuser_auth_keys = undef - список ключей для $deployuser
• repo_url = undef - URI репозитория (пример: ssh://user@host/repo или file:///some/path)
• puppetserver = true - устанавливать ли компонент Puppet Server на данный узел
• puppetdb = true - устанавливать ли компонент PuppetDB на данный узел
• puppetdb_port = 8081 - порт для PuppetDB
• setup_postgresql = true - устанавливать ли компонент PostgreSQL на данный узел (только если включена установка PuppetDB)
• service_face = "any" - название ресурса cfnetwork::iface для принятия входящих соединений
• puppetserver_mem = auto - оперативная память под Puppet Server в мегайбатах (минимум 192MB)
• puppetdb_mem = auto - оперативная память под PuppetDB в мегайбатах (минимум 192MB)
• postgresql_mem = auto - оперативная память под PostgreSQL в мегайбатах (минимум 128MB)

класс cfpuppetserver::puppetdb

• postgresql_host = "localhost" - адрес базы данных
• postgresql_listen = $postgresql_host - значение идёт прямо в директиву listen_addresses PostgreSQL
• postgresql_port = 5432 - порт базы данных
• postgresql_user = "puppetdb" - пользователь PuppetDB в базе данных
• postgresql_pass = "puppetdb" - пароль пользователя PuppetDB в базе данных
• postgresql_ssl = false - включение шифрования соединения на основе сертификатов Puppet PKI

класс cfpuppetserver::puppetserver

• autosign = false - НЕ СТОИТ использовать в боевой среде, разве что в DMZ. Существует исключительно для автоматизации тестирования.
• global_hiera_config = "cfpuppetserver/hiera.yaml" - путь к файлу конфигурации Hiera по умолчанию по канонам Puppet (первый компонент - название модуля, остальное - путь под папкой files/ в модуле)

Вы можете помочь и перевести немного средств на развитие сайта



Некоторое время назад список серверов у меня в закладках перевалил за отметку в 200. По мере увеличения количества серверов развертывание любой новой конфигурации или установка новых пакетов, приводит к трате огромного количества времени. Так я решил использовать puppet.
Puppet (англ. марионетка) - кроссплатформенное клиент-серверное приложение, которое позволяет централизованно управлять конфигурацией операционных систем и программ, установленных на нескольких компьютерах. Puppet написан на языке программирования Ruby.

Еще говорят, что puppet это система удаленного управления конфигурациями, наиболее известными представителями которых являются открытые системы Cfengine и Puppet.

Ознакомившись с отзывами я решил использовать puppet.

Puppet сервер установка и настройка:
Установка puppet-сервера :
Установим puppet-server на OpenSuSE 11.4:

zypper in puppet-server

Изменим имя сервера на puppet:
/etc/HOSTNAME:

DNS запись должна резолвиться на 127.0.0.2
cat /etc/hosts:

127.0.0.2 puppet.site puppet

Дадим права для пользователя puppet :

Запустим сервис Puppet Master:

rcpuppetmasterd start

Добавим запуск puppet демона в автозагрузку:

chkconfig -a puppetmasterd

Настройка puppet-сервера:
Определим директорию, где будут храниться файлы, которые puppet-server будет передавать на машины-клиенты в манифестах типа file.

vim /etc/puppet/fileserver

path /etc/puppet/files
allow *

mkdir /etc/puppet/files

chown -R puppet:puppet /etc/puppet/files

Создадим файл любого содержания для развертывания и тестирования на клиентах

touch /etc/puppet/files/puppettesting

Перезагрузим puppet сервер:

rcpuppetmasterd restart

Puppet использует собственный язык описания конечного состояния операционной системы, с помощью которого сисадмин указывает то, к какому виду должны быть приведены компоненты ОС, чтобы она достигла желаемого состояния. Под состоянием может подразумеваться наличие определенного файла, папки, запущенных сервисов установленных пакетов, обновлений и другое. Все настройки состояний описываются в файлах или манифестах, которые расположены в каталоге: /etc/puppet/manifests. Эти файлы имею имена типа *.pp.

Создадим простейший манифест :
/etc/puppet/manifests/1.file.pp:

file { "/tmp/puppettesting" :
source => "puppet:///files/puppettesting",
}

Для применения даннного манифеста:
puppet apply 1.file.pp

Установка и настройка клиента puppet:

zypper in puppet

Дадим права puppet пользователю:

chown -R puppet.puppet /var/lib/puppet/

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

На сервере мы можем увидеть какие запросы на подтверждение ожидают:

"puppet-client.localdomain" (B5:12 :69 :63 :DE:19 :E9:75 :32 :2B:AA:74 :06:F6:8E:8A)

Подтверждаем:

puppetca --sign "puppet-client.localdomain"

Самое время рассмотреть простейшие примеры создание манифестов:
создадим файл /etc/puppet/manifests/site.pp:

node default {
file { "/tmp/puppettesting" :
source => "puppet:///files/puppettesting" ,
}
service { "ntp" :
ensure => running,
enable => true ,
}
package { "htop" :
ensure => installed,
}
}

default - применять для всех клиентов
file - эта секция говорит создать или перезаписать файл /tmp/puppettesting который находится на сервере в каталоге /etc/puppet/files
service: проверить запущен ли сервис, если не запущен, то запустить его, а также добавить в автозагрузку
package: проверить установлен ли на клиенте пакет htop и если нет, то установить его.

Для проверки запустим на клиенте:

Как видим на клиенте был добавлен ntp в автозагрузку, запущен ntp демон, установлен пакет htop, а также скопирован файл puppettesting в директорию /tmp/

info: Caching catalog for puppet-client.localdomain
info: Applying configuration version "1370163660"
notice: / Stage[ main] // Node[ default] / Service[ ntp] / ensure: ensure changed "stopped" to "running"
notice: / Stage[ main] // Node[ default] / Package[ htop ] / ensure: created
notice: / Stage[ main] // Node[ default] / File[ / tmp/ puppettesting] / ensure: defined content as "{md5}f2171ac69ba86781bea2b7c95d1c8e67"
notice: Finished catalog run in 3.95 seconds

В следующей статье я опишу более сложные примеры создания манифестов и web-интерфейс puppet-dashboard.

Популярные типы ресурсов Puppet
cron - управление заданиями cron
exec - запуск скриптов и команд
file - управление файлами
filebucket - резервное копирование файлов
group - управление группами
host - управление записями в файле /etc/hosts
interface - конфигурирование сетевых интерфейсов
mount - монтирование файловых систем
notify - посылка сообщения в лог-файл Puppet
package - управление пакетами
service - управление сервисами
sshkey - управление ключами SSH
tidy - удаление файлов в зависимости от условий
user - управление пользователями
zones - управление зонами Solaris

Puppet - это кроссплатформенная структура, позволяющая системным администраторам выполнять общие задачи с использованием кода. Код позволяет выполнять различные задачи от установки новых программ до проверки прав доступа файлов или обновлений пользовательских учетных записей. Puppet превосходна не только в процессе изначальной установки системы, но и на протяжении всего жизненного цикла системы. В большинстве случаев puppet используется в конфигурации клиент/сервер.

Этот раздел показывает установку и настройку Puppet в конфигурации клиент/сервер. Этот простой пример демонстрирует как установить Apache с использованием Puppet .

Установка

Для установки Puppet введите в терминале:

Sudo apt-get install puppetmaster

На клиентской машине (или машинах) введите:

Sudo apt-get install puppet

Настройка

Прежде чем настраивать puppet вам возможно захочется добавить запись DNS CNAME для puppet.example.com , где example.com - это ваш домен. По умолчанию клиенты Puppet проверяют DNS на наличие puppet.example.com в качестве имени puppet сервера (Puppet Master ). Смотрите Служба доменных имен для дополнительных деталей использования DNS .

Если вы не предполагаете использовать DNS , вы можете добавить записи в файл /etc/hosts на сервере и клиенте. Например, в файл /etc/hosts Puppet сервера добавьте:

127.0.0.1 localhost.localdomain localhost puppet 192.168.1.17 meercat02.example.com meercat02

На каждом Puppet клиенте добавьте запись для сервера:

192.168.1.16 meercat.example.com meercat puppet

Замените IP адреса и доменные имена из примера на ваши актуальные адреса и имена сервера и клиентов.

Теперь настроим некоторые ресурсы для apache2 . Создайте файл /etc/puppet/manifests/site.pp , содержащий следующее:

Package { "apache2": ensure => installed } service { "apache2": ensure => true, enable => true, require => Package["apache2"] }

Node "meercat02.example.com" { include apache2 }

Замените meercat02.example.com на актуальное имя вашего Puppet клиента.

Финальным шагом для этого простого Puppet сервера является перезапуск сервиса:

Sudo /etc/init.d/puppetmaster restart

Теперь на Puppet сервере все настроено и время настроить клиента.

Сначала настроим сервис Puppet агента для запуска. Отредактируйте /etc/default/puppet, заменив значение START на yes :

Sudo /etc/init.d/puppet start

Возвращаемся на Puppet сервер для подписи клиентского сертификата с помощью команды:

Sudo puppetca --sign meercat02.example.com

Проверьте /var/log/syslog на любые ошибки конфигурации. Если все прошло хорошо, пакет apache2 и его зависимости будут установлены на Puppet клиенте.

Этот пример очень простой и не показывает многие возможности и преимущества Puppet . Для дополнительной информации смотрите

Когда число серверов, которыми вы управляете меньше десяти — редко кто задумывается об их централизованном управлении, этого может и не требоваться. Когда серверов десятки — централизованное управление ПО и конфигурациями крайне полезно. Когда серверов сотни и тысячи — это жизненно необходимо. Программ такого рода много, например: Chef, CFEngine, Puppet… Вот о последнем и пойдет речь в этой записи.

Puppet по достоинству считается одним из лучших решений в этом роде. Его используют такие компании как Google, Citrix и Red Hat. Это собой клиент-серверное приложение написанное на языке программирования Ruby, которое распространяется в двух вариантах:

• Puppet Open Source — полностью бесплатная версия
• Puppet Enterprise — бесплатная в конфигурации до 10 серверов, далее требуется приобретение лицензий

Рассмотрим установку сервера и агента Puppet Open Source, которые присутствует в пакетах большинства современных дистрибутивов. Далее речь пойдет о Ubuntu 12.04 Precise Pangolin.

Серверная часть Puppet называется puppetmaster , начнем установку с нее:

:~# apt-get install puppetmaster

А теперь клиент:

:~# apt-get install puppet

В конфигурационном файле клиента /etc/puppet/puppet.conf необходимо рассказать о сервере, добавив следующую секцию:

Server=puppet.local report=true pluginsync=false

На первоначальном этапе pluginsync лучше выключить.

Запустим клиент puppet чтобы он создал запрос на получение сертификата:

:~# puppetd --verbose --test info: Creating a new SSL key for linux.local info: Caching certificate for ca info: Creating a new SSL certificate request for linux.local info: Certificate Request fingerprint (md5): E5:EA:AC:5B:22:9A:BA:42:B8:A1:63:9E:1F:1F:23:51 Exiting; no certificate found and waitforcert is disabled

На сервере необходимо проверить что запрос сертификата получен и, если это так, выписываем сертификат:

:~# puppetca --list "linux.local" (E5:EA:AC:5B:22:9A:BA:42:B8:A1:63:9E:1F:1F:23:51) :~# puppetca --sign linux.local notice: Signed certificate request for linux.local notice: Removing file Puppet::SSL::CertificateRequest linux.local at "/var/lib/puppet/ssl/ca/requests/linux.local.pem"

Повторяем предыдущий шаг на клиенте:

:~# puppetd --verbose --test info: Caching certificate for linux.local info: Retrieving plugin info: Caching certificate_revocation_list for ca info: Caching catalog for linux.local info: Applying configuration version "1356278451" info: Creating state file /var/lib/puppet/state/state.yaml notice: Finished catalog run in 0.02 seconds

Отлично, все работает. Переходим к созданию первого манифеста. Манифесты, они же конфигурации описываются на специальном декларативном языке. Будем сразу приучаться к хорошему, использовать модульную структуру и классы. Для примера напишем модуль который будет поддерживать в актуальном виде файл /etc/hosts на всех наших серверах.

Проверим, где puppet ищет модули:

:~# puppet apply --configprint modulepath /etc/puppet/modules:/usr/share/puppet/modules

Создаем каталоги для своего модуля

:~# cd /etc/puppet/modules :~# mkdir hosts; cd hosts; mkdir manifests; cd manifests

Первый манифест, он же основной файл модуля — должен называться init.pp

Class hosts { # puppet.local host { "puppet.local": ensure => "present", target => "/etc/hosts", ip => "192.168.0.1", host_aliases => "puppet", } # linux.local host { "linux.local": ensure => "present", target => "/etc/hosts", ip => "192.168.0.2", host_aliases => "linux", } }

По-умолчанию puppet ищет файл /etc/puppet/manifests/site.pp чтобы загрузить конфигурацию, приведем его к следующему виду:

Node default { include hosts }

Проверяем манифест на сервере:

:~# puppet apply --verbose /etc/puppet/manifests/site.pp info: Applying configuration version "1356281036" notice: /Stage//Host/ensure: created info: FileBucket adding {md5}notice: /Stage//Host/ensure: created notice: Finished catalog run in 0.03 seconds

На клиенте:

:~# ll /etc/hosts rw-r--r-- 1 root root 290 Dec 16 19:10 /etc/hosts :~# puppetd --verbose --test info: Caching catalog for linux.local info: Applying configuration version "1356283380" info: FileBucket adding {md5}notice: /Stage/Hosts/Host/ensure: created notice: /Stage/Hosts/Host/ensure: created notice: Finished catalog run in 0.04 seconds :~# ll /etc/hosts -rw-r--r-- 1 root root 551 Dec 23 20:43 /etc/hosts

После того как мы убедились что все работает, разрешаем запуск службы, в /etc/default/puppet меняем:

# Start puppet on boot? START=yes

Запускаем службу

:~# service puppet start

Puppet будет каждые 30 минут опрашивать сервер puppetmaster на предмет изменения конфигурации и, при необходимости, производить соответствующую настройку системы.