Всем привет! В данной статье хочу поделиться с вами впечатлениями от настройки Puppet для конфигурации Windows-серверов.

В целом, задача заключалась в следующем: требовалось организовать процесс автоматической доставки и установки патчей для обновления удаленных серверов. Выбирали из известных менеджеров конфигураций, главное требование к которым — поддержка Windows на высоком уровне. Сразу скажу, что от Puppet решили отказаться из-за высокого порога вхождения, pull подхода и необходимости знания Ruby. Но уж очень хочется поделиться тем, что получилось.

Введение

Puppet обладает коммуникационной моделью (архитектурой) «мастер-агент», причем операционной системой мастера не может быть Windows. Для управления Windows-агентами, на целевых машинах должно быть установлено ПО, которое представляет собой .msi установщик.

Puppet оперирует хостнеймами и взаимодействие между мастером и агентами осуществляется по протоколу HTTPS, из чего следует, что у агентов и мастера есть такие зависимости, как веб-сервер Apache, а также не удастся избежать взаимодействия с сертификатами и их настройки.

Тестовая инфраструктура

• Виртуальная машина с ОС Ubuntu 16.04 LTS для установки Puppet-мастера.
• Целевые машины с ОС Windows, которыми, собственно, и нужно управлять.

Установка

Установка состоит из двух частей, по количеству архитектурных компонент.

Мастер

Установка мастера описана здесь ^[1]. Единственное, что во время установки не завелось – после перегенерации SSL сертификатов Apache перестал запускаться.

После обращения к журналу событий становится понятно, в чем проблема – сертификата с таким именем, как в конфигурационном файле /etc/apache2/sites-enabled/puppetmaster.conf, не существует. Заходим, исправляем имя (в моем случае просто puppet), готово. Кстати, посмотреть на сертификат мастера можно здесь — /var/lib/puppet/ssl/certs.

Агенты

При установке Windows-агентов есть вероятность, что что-то пойдет не так. Самое главное правило – версия Puppet-мастера всегда должна быть сопоставима (или больше) версии Puppet-агента.
В самом начале процесса установки можно увидеть, что включает в себя установщик.

Конкретнее о многих из этих компонентов можно узнать из документации ^[2]. Далее указываем адрес мастера и готово.

Как можно увидеть, завершилось ли все успехом? Заходим в Event Viewer и смотрим на сообщения, где источником является Puppet. Пример ранее упомянутой проблемы несовместимости версий мастера и агента приведен ниже.

Если все прошло нормально, заключительным этапом является подпись сертификата агента на мастере.

puppet cert list --all
cert sign <agent-hostname>

Пример Puppet-манифеста

# манифесты содержат набор инструкций для применения на целевых машинах
# класс определяет блок действий, которые необходимо применить

# создаем класс с описанием того, что файл должен существовать
# и иметь определенное содержимое
class action::windows {
    file { 'c:\Temp\foo.txt':
        ensure   => present,
        content  => 'This is some text in my file'
    }
}

# класс для обработки всех машин, кроме Windows
class action::default {
    notify{ "Operating system $::operatingsystem not supported": }
}

# анализируем факт osfamily
# и в зависимости от этого выполняем нужные действия
case $::osfamily {
    'windows': { include action::windows }
    default: { include action::default }
}

Чтобы применить манифесты на мастере: puppet apply <manifest-name>.
На агентах: puppet agent --test.

Заключение

Как я писал ранее, для поставленной задачи Puppet не был выбран главным образом из-за того, что использует pull подход к управлению, но, мое мнение — стабильность и возраст системы во многих ситуациях важнее. К тому же, для push подхода существует mcollective ^[3].

Полезные источники

1. ssl background ^[4]
2. puppet agent/master communications ^[5]
3. puppet architecture overview ^[6]
4. puppet official modules ^[7]
5. installation ^[1]
6. tutorial presentation ^[8]
7. mcollective ^[3]

Автор: tikhoa

Источник ^[9]