Как запускал Puppet

Мой опыт работы с Puppet

За время работы с Puppet (начиная с версии ~3.x и вплоть до современных 6.x/7.x) я использовал несколько подходов к запуску, которые эволюционировали вместе с инфраструктурой и DevOps-практиками. Вот ключевые модели, которые я применял.

Модель развертывания: Master-Agent (Server-Client)

Это классическая и наиболее распространенная модель, которую я настраивал с нуля в нескольких компаниях.

Архитектура:

• Puppet Master (Server): Центральный сервер, хранящий всю конфигурацию (манифесты, модули, данные Hiera). На нем же запущен сертификационный центр.
• Puppet Agent (Client): Демон, установленный на управляемых нодах (узлах). Периодически связывается с мастером, получает скомпилированный каталог конфигурации (catalog) и применяет его.

Типичный рабочий процесс запуска:

1. Первоначальная настройка (puppet agent --test или --waitforcert): После установки агента на новом сервере я всегда запускал его вручную с флагом --test для первого подключения. Это инициировало процесс подписания сертификата.

   # На агенте (новой ноде)
   puppet agent --test --server puppetmaster.example.com --waitforcert 60
   

2. Подписание сертификата на мастере: Затем, в зависимости от политики безопасности (автоподписание или ручной контроль), я подписывал сертификат на мастер-сервере.

   # На мастере (просмотр запросов)
   puppetserver ca list
   
   # Подписание конкретного сертификата
   puppetserver ca sign --certname web-server-01.example.com
   

3. Регулярный запуск по расписанию (puppet agent --daemonize): После успешного рукопожатия агент переводился в фоновый режим (daemon). Он автоматически запускался как служба и опрашивал мастер по расписанию (по умолчанию каждые 30 минут).

   # Запуск/управление службой (система инициализации зависит от ОС)
   systemctl start puppet  # На systemd-системах
   service puppet start    # На sysvinit-системах
   
   # Просмотр логов для отладки
   tail -f /var/log/puppetlabs/puppet/puppet.log
   

Masterless (Standalone) Модель

Я применял эту модель для специфических случаев:

• Высоконагруженные или изолированные среды, где нельзя допускать зависимости от центрального сервера.
• Развертывание immutable-инфраструктуры (например, создание образов AMI/Packer).
• Быстрое прототипирование конфигураций.

В этом подходе Puppet запускается локально на каждой машине, применяя конфигурацию напрямую из локального репозитория (часто синхронизированного через Git):

# Клонируем репозиторий с манифестами и модулями
git clone https://git.internal.company.com/puppet-repo.git /etc/puppetlabs/code

# Запускаем Puppet локально
/opt/puppetlabs/bin/puppet apply /etc/puppetlabs/code/environments/production/manifests/site.pp \
  --modulepath=/etc/puppetlabs/code/modules \
  --hiera_config=/etc/puppetlabs/code/hiera.yaml

Для автоматизации в CI/CD пайплайнах я часто оборачивал это в Ansible playbook или простой bash-скрипт.

Интеграция с CI/CD и Оркестрацией

В современных стеках запуск Puppet редко был изолированным действием. Мои практики включали:

• Тестирование изменений в ветках Git с помощью puppet parser validate, puppet-lint и rspec-puppet в пайплайнах Jenkins/GitLab CI перед мержем в production.
• Ступенчатый деплой: После подписания кода изменения сначала применялись на канареечных нодах (puppet agent --test --environment=canary), и только после проверки — на остальных.
• Оркестрация запуска: Для немедленного применения изменений на группе серверов (вместо ожидания 30 минут) использовались:

    *   `mcollective` (в более ранних версиях стека)
    *   Интеграция через **Bolt** или **Ansible** для выполнения `puppet agent -t` удаленно.
    *   `ssh`-циклы или **Fabric** для простых случаев.

Пример задания в Jenkins для принудительного запуска Puppet на группе серверов:

pipeline {
    agent any
    stages {
        stage('Run Puppet on Web Servers') {
            steps {
                script {
                    def servers = ['web01', 'web02', 'web03']
                    servers.each { server ->
                        sh "ssh ${server} 'sudo /opt/puppetlabs/bin/puppet agent -t --no-noop'"
                    }
                }
            }
        }
    }
}

Ключевые принципы и инструменты сопровождения

• Управление средами (Environments): Всегда разделял production, staging, development. Запуск агента в конкретной среде осуществлялся через puppet agent --test --environment=staging.
• Отладка и нотификации: Использование флагов:

    *   `--verbose` (`-v`) / `--debug` (`-d`) для детального вывода.
    *   `--noop` («no-operation») для **предварительного просмотра изменений** без реального применения — обязательный шаг перед любым серьезным обновлением.
    *   Интеграция отчетов (`puppet agent --test --report`) с системами мониторинга (**Prometheus**) и уведомлений (**Slack**, **Email**).

• Управление зависимостями: Тщательное проектирование порядка запуска классов через метапараметры (require, before, notify, subscribe) и использование run stages для критичных зависимостей.

Итог: Мой подход к запуску Puppet всегда балансировал между автоматизацией регулярных применений (через демон) и контролируемыми, проверяемыми запусками (через CI/CD и оркестрацию) для критичных изменений. Эволюция от ручных команд к полной интеграции в Infrastructure as Code-пайплайны была естественным путем повышения надежности и скорости доставки конфигураций.