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

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

Введение

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

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

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

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

Установка

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

Мастер

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

image![image](https://imagebin.ca/v/3NbWzYZ942C3)

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

Агенты

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

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

Как можно увидеть, завершилось ли все успехом? Заходим в 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.

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

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

Первоначальная настройка Puppet — не все так просто, как кажется