Вкратце:

1. cfpuppetserver — модуль автоматической настройки Puppet Server + PuppetDB + PostgreSQL + r10k + librarian-puppet
2. Краткое введение в Puppet
3. Описывается изначальное развёртывание с нуля

Тематический цикл:

• Часть I: сеть и сетевой фильтр (cfnetwork + cffirehol)
• Часть II: доступ и стандартное окружение (cfauth + cfsystem)
• Часть III: установка Puppet Server (cfpuppetserver)

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

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

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)

• В данном случае только один сервер выступает в роли 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.

Установка

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

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

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. В каком-то смысле это напоминает сборку компилятора в несколько этапов.

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

1. Скачиваем скрипт установки: wget https://raw.githubusercontent.com/codingfuture/puppet-cfpuppetserver/master/setup_puppetserver.sh
2. Просматриваем скрипт и хмурим бровки: less setup_puppetserver.sh
3. Запускаем: bash setup_puppetserver.sh <repo_uri> puppet.${MY_DOMAIN}.
   
   • Пример с удалённым репозиторием: bash setup_puppetserver.sh ssh://git@git.example.com/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!

bash <<EOT
#!/bin/bash

http_proxy=

if test "\$(id -un)" != 'root'; then
    echo 'This script must run as root'
    exit 1
fi

if test ! -z ""; then
    echo -n  >/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 <<EOF
[main]
certname = host.example.com
server = puppet.example.com
ca_server = puppet.example.com
environment = production
EOF

apt-get update &&
    apt-get install puppet-agent

while ! /opt/puppetlabs/bin/puppet agent --test --wairforcert 120; do
    echo "Please go to puppetserver and exec the following command when we wait for key"
    echo "> 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> [<certname=hostname> [<cflocation> [<cflocationpool> [<http_proxy>] ] ] ]

• 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 <certname> [<cflocation> [<cflocationpool> [<http_proxy>]]]

класс 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/ в модуле)