🐹 Puppet 3. Часть 2: Манифесты, синтаксис, команды. – Хомячье логово

Введение.

Предположим, что у вас есть парк серверов, выполняющих различные задачи. Пока серверов мало и вы не растёте, вы легко настраиваете каждый сервер вручную. Устанавливаете операционную систему (может быть, автоматизированно), добавляете пользователей, устанавливаете софт, вводя команды в консоль, настраиваете сервисы, правите конфигурации ваших любимых текстовых редакторов, выставляете на них одинаковые настройки DNS-сервера, устанавливаете агент системы мониторинга, настраиваете syslog для централизованного сбора логов… Словом, работы довольно много и она не особенно интересна.

Хороший админ — ленивый админ. Он не любит делать что-то несколько раз.

Первая мысль — написать пару скриптов:

# servers.sh
servers="server00 server01 server02 server03 server04"for server in$servers ; do
   scp /path/to/job/file/job.sh $server:/tmp/job.sh
   ssh $server sh /tmp/job.sh
done

# job.sh
#!/bin/bash
apt-get update
apt-get install nginx
service nginx start

Вроде всё стало легко и хорошо. Нужно что-то сделать — пишем новый скрипт, запускаем. Изменения приходят на все серверы последовательно. Если скрипт хорошо отлажен — всё станет хорошо. До поры…

Теперь представьте, что серверов стало больше. Например, сотня! А изменение долгое — например, сборка чего-нибудь большого и страшного (например, ядра) из исходников. Скрипт будет выполняться сто лет, но это полбеды.

Представьте, что вам нужно сделать это только на определенной группе из этой сотни серверов. А через два дня нужно сделать другую большую задачу на другом срезе серверов. Вам придётся каждый раз переписывать скрипты и много раз проверять, нет ли в них каких-нибудь ошибок, не вызовет ли это какой-нибудь проблемы при запуске.

Самое плохое — это то, что в подобных скриптах вы описываете действия, которые необходимо выполнить для приведения системы в определенное состояние, а не само это состояние. Значит, если система изначально находилась не в том состоянии, что вы предполагали, то всё обязательно пойдет не так.

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

Для сравнения: манифест Puppet, выполняющий ту же работу, что и пара скриптов из начала манифеста:

# nginx.ppclassnginx {
  package { 'nginx':
  ensure => latest
}
 service { 'nginx':
  ensure => running,
  enable => true,
  require => Package['nginx']
 }
}
node /^server(d )$/ {
  include nginx
}

Что такое Puppet?

Puppet — система управления конфигурацией. Архитектура — клиент-серверная, на сервере хранятся конфигурации (в терминах Puppet они называются манифесты), клиенты обращаются к серверу, получают их и применяют.

Почему в инструкции Puppet 3? Потому что из базовых репозиториев CentOS 7 ставится именно Puppet 3 и его вполне хватает для обслуживания серверов на базе CentOS 7. Работает всё исправно — значит не будем менять на другую.

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

Используется pull-модель работы: по умолчанию раз в полчаса клиенты обращаются к серверу за конфигурацией и применяют её. Если вы работали с Ansible, то там используется другая, push-модель: администратор инициирует процесс применения конфигурации, сами по себе клиенты ничего применять не будут.

При сетевом взаимодействии используется двустороннее TLS-шифрование: у сервера и клиента есть свои закрытые ключи и соответствующие им сертификаты. Обычно сервер выпускает сертификаты для клиентов, но в принципе возможно использование и внешнего CA (Certificate Authority Server).

Puppet позволяет просто настроить и впоследствии быстро управлять практически любой сетью на базе любой операционной системы. Система Puppet достаточно популярна в среде IT-компаний.

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

2.1. Архитектура Agent / Master.

В этой архитектуре один или несколько серверов запускают главное приложение Puppet, обычно как приложение Rack, управляемое web-сервером (например, Apache с Passenger), а приложение агента Puppet работает на клиентских серверах, обычно как фоновая служба.

Периодически Puppet agent будет отправлять информацию Puppet master‘у и запрашивать каталог. Puppet master скомпилирует и вернет каталог этого узла, используя несколько источников информации, к которым у него есть доступ.

2.2. Автономная архитектура.

В этой архитектуре клиентские серверы запускают приложение Puppet Apply (автономное сочетание приложений Puppet Master и Puppet Agent), обычно как запланированное задание или задание cron.

Введение

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

Возможные ошибки или если что-то пошло не так.

9.1. Удаление сертификатов.

Бывает, что «что-то идет не так» и подключить Puppet agent к Puppet master не удается:

Иногда на Puppet master забыли пробросить порт 8140 или необходимо удалить битый сертификат.

Будем считать, что порт 8140 проброшен и займёмся сертификатом.

Для этого сначала выполняем команду на сервере:

# puppet cert clean puppet-cl14.hamsterden.loc

Затем, деликатно, на клиенте:

# find /var/lib/puppet/ssl -name puppet-cl14.hamsterden.loc.pem -delete

Или, чтоб наверняка, бахнем всё:

# rm -rf /var/lib/puppet/ssl/*

# puppet agent -t

Если всё рано выскакивает ошибка, то уже точно на Puppet master не проброшен порт 8140 и его отсекает межсетевой экран. Отключите брандмауэр или настройте проброс порта.

Установка Foreman Puppet на puppet-мастера

Добавим репозиторий установщика Foreman/Puppet и установим его в систему:

. Как узнать версию Puppet.

Более новые версии, отличные от версии Puppet 3, используют другую командную строку.

Команда для Puppet 3 будет соответственно:

• # puppet --version
• # puppet master --version
• # puppet agent --version

Для версий до Puppet 4.0, если Puppet был установлен как пакет RPM, вы можете запросить базу данных RPM:

# rpm -qa | grep puppet

Ответ:

Для любителей Debian / Ubuntu / Mint, пакет запроса будет: dpkg -l | grep puppet.

Puppetlabs изменили свою упаковку, и упакованная версия Puppet не указана номером версии пакета puppet-agent.

. Немного о кроссдистрибутивности.

В Puppet есть возможность использовать кроссдистрибутивные манифесты, это одна из целей, для которых он создавался. Не рекомендуется этим пользоваться. Парк серверов должен быть максимально однотипным в плане системного программного обеспечения, это позволяет не думать в критические моменты «ай, блин, тут rc.d, а не init.d» (реверанс в сторону ArchLinux) и вообще позволяет меньше думать на рутинных задачах.

Многие ресурсы зависят от других ресурсов.

Например, для ресурса «сервис sshd» необходим ресурс «пакет sshd» и опционально «конфигурация sshd».

Посмотрим, как это реализуется:

file { 'sshd_config':
   path => '/etc/ssh/sshd_config',
   ensure => file,
   content => "Port 22               Protocol 2               HostKey /etc/ssh/ssh_host_rsa_key               HostKey /etc/ssh/ssh_host_dsa_key               HostKey /etc/ssh/ssh_host_ecdsa_key               UsePrivilegeSeparation yes               KeyRegenerationInterval 3600               ServerKeyBits 768               SyslogFacility AUTH               LogLevel INFO               LoginGraceTime 120               PermitRootLogin yes               StrictModes yes               RSAAuthentication yes               PubkeyAuthentication yes               IgnoreRhosts yes               RhostsRSAAuthentication no               HostbasedAuthentication no               PermitEmptyPasswords no               ChallengeResponseAuthentication no               X11Forwarding yes               X11DisplayOffset 10               PrintMotd no               PrintLastLog yes               TCPKeepAlive yes               AcceptEnv LANG LC_*               Subsystem sftp /usr/lib/openssh/sftp-server               UsePAM yes",
   mode => 0644,
   owner => root,
   group => root,
   require => Package['sshd']
}

   package { 'sshd':
   ensure => latest,
   name => 'openssh-server'
}

   service { 'sshd':
   ensure => running,
   enable => true,
   name => 'ssh'
   subscribe => File['sshd_config'],
   require => Package['sshd']
}

Здесь используется инлайн-конфигурация, которая делает манифест некрасивым. На самом деле так почти никогда не делается, существует механизм шаблонов, основанный на ERB, и возможность просто использовать внешние файлы. Но нас не это интересует.

Самые интересные строчки здесь — это строчки зависимостей — require и subscribe.

Puppet поддерживает много вариантов описания зависимостей. Подробно, как всегда, можно прочитать в документации.

Require означает ровно то, что ожидается. Если ресурс А зависит (require) от ресурса Б, то Puppet сначала обработает ресурс Б, а потом вернётся к ресурсу А.

Subscribe даёт чуть более хитрое поведение. Если ресурс А подписан (subscribe) на ресурс Б, то Puppet сначала обработает ресурс Б, а потом вернётся к ресурсу А (поведение как у require), и далее при изменениях Б, будет заново обрабатываться А. Это очень удобно для создания сервисов, зависящих от их конфигов (как в примере выше).

Если конфигурация изменяется, сервер перезапускается, не нужно самому об этом беспокоиться.

Существуют также notify, before, но мы их здесь касаться не будем.

. Полезные команды.

11.1. Проверка текущих параметров.

Для проверки всех текущих параметров Puppet сервера есть полезная команда:

# puppet config print

Ответ: большой и длинный список параметров и их значений.

11.2. Проверка состояния сертификатов.

Для проверки списка сертификатов:

# puppet cert list –all

Если с плюсом, значит подписан.

Ответ:

Если он без плюса, значит его надо подписать:

# puppet cert –sign –all

Итог должен появиться в /var/lib/puppet/ssl. Если что то пошло не так всё там стираем и повторяем заново.

Чтобы удалить сертификат host‘а с именем «pm» нужно ввести команду:

# puppet cert clean pm

Ответ:

. Примеры манифестов.

Задает права и владельца для файла /etc/passwd:

file { "/etc/passwd":
   owner => "root",
   group => "wheel",
   mode => "0664",
}

Устанавливает последнюю версию пакета samba:

package { "samba":
   ensure => latest
}

Настройка Foreman

По умолчанию Foreman использует свой SSL-сертификат, сгенерированный Puppet и ваш браузер не будет принимать его. Вы можете добавить корневой сертификат (

/var/lib/puppet/ssl/certs/ca.pem

) в свой браузер, чтобы исчезли предупреждения небезопасного соединения (для Chromium добавлять сюда: Настройки/SSL/Центры сертификации).

При первом входе вы увидите страницу Dashboard, где будет показана общая статистика по всем узлам сети. При добавления узлов сети, здесь будет полезная статистическая информация.

При последующих входах вы будете перенаправляться на страницу списка узлов сети.

Расположение файлов на Puppet master.

Для дальнейших объяснений введем понятие «корневая директория».

Корневая директория — это директория, в которой находится Puppet-конфигурация для конкретной ноды.

Корневая директория различается в зависимости от версии Puppet и использования окружений.

Окружения — это независимые наборы конфигурации, которые хранятся в отдельных директориях. Обычно используются в сочетании с гитом, в таком случае окружения создаются из веток гита. Соответственно, каждая нода находится в том или ином окружении. Это настраивается на самой ноде, либо в Puppet – External Node Classifiers (ENC).

В третьей версии («старый Puppet») базовой директорией была /etc/puppet. Использование окружений опциональное — мы, например, их не используем со старым Puppet. Если окружения используются, то они обычно хранятся в /etc/puppet/environments, корневой директорией будет директория окружения. Если окружения не используются, корневой директорией будет базовая.

Начиная с четвёртой версии («новый Puppet») использование окружений стало обязательным, а базовую директорию перенесли в /etc/puppetlabs/code. Соответственно, окружения хранятся в /etc/puppetlabs/code/environments, корневая директория — директория окружения.

В корневой директории должна быть поддиректория manifests, в которой лежит один или несколько манифестов с описанием нод. Кроме того, там должна быть поддиректория modules, в которой лежат модули.

Кроме того, в старом Puppet также может быть поддиректория files, в которой лежат различные файлы, которые мы копируем на ноды. В новом Puppet же все файлы вынесены в модули.

Файлы манифестов имеют расширение *.pp.

1. Смена пароля

Первым делом необходимо изменить пароль пользователя:

Пароль по умолчанию и так сложный, но лучше сделать свой.

2. Добавление модуля на примере NTP

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

3. Добавление модуля accounts и ssh

На примере предыдущего модуля установим модуль

accounts

master ~ $ puppet module install camptocamp-accounts

Если установка прошла успешно, то вы увидите следующее:

Установим модуль

ssh

master ~ $ puppet module install saz/ssh

После этого идём в

Foreman

и импортируем новые классы. Позже, после создания групп узлов сети, мы настроим классы

accountsssh

4. Добавление модуля mysql и apache

Для объяснения последующих названий групп

databaseweb

добавим модули

apachemysql

. Добавляем модули по примеру предыдущих. Загрузить их можно командами:

master ~ $ puppet module install puppetlabs-apache
master ~ $ puppet module install puppetlabs-mysql

Добавление узлов сети

Чтобы добавить узел сети в Puppet, необходимо установить puppet-агент на этот узел. Для установки puppet-агента скачаем и установим репозиторий

puppet-labs

Ресурсы.

Ресурс — это самая мелкая единица абстракции в Puppet.

Ресурсами могут быть:

• файлы;
• пакеты (Puppet поддерживает пакетные системы многих дистрибутивов);
• сервисы;
• пользователи;
• группы;
• задачи cron;
• и так далее по аналогии.

Добавление групп узлов сети

Перейдём в пункт меню

Configure → Host Groups

. Нажмём

New Host Group

. Вкладка

Host Group

должна получится следующей:

Группа

root

будет корневой. Она будет родителем всех остальных групп. У ней будет полный доступ ко всему. И в неё будут включены основные классы.

Далее перейдем во вкладку Puppet Classes и добавим необходимые классы нажав на :

Нажимаем

Submit

Добавим по этому же принципу ещё две группы. Только теперь мы выберем в качестве Parent группу root, потому классы accounts, ntp и ssh наследуются и добавлять их повторно не нужно. Добавим только для группы database класс mysql::server, а для группы web класс apache.

Подготовка инфраструктуры.

Для настройки архитектуры Agent/Master, потребуется подготовить свое рабочее окружение. Для демонстрации программного обеспечения Puppet создадим 4 виртуальных машины на базе операционной системы CentOS 7.

Можно сделать и одну ноду, но мне было лень откатываться из резервной копии и «очищать» одну и тоже ноду, поэтому я наклонировал сразу три и игрался с ними.

Про ресурсы в общем.

4.1. Требования к уникальности ресурсов.

Самая частая ошибка, с которой мы встречаемся — Duplicate declaration. Эта ошибка возникает, когда в каталог попадают два и более ресурса одинакового типа с одинаковым названием.

Внимание! В манифестах для одной ноды не должно быть ресурсов одинакового типа с одинаковым названием (title).

Иногда есть необходимость поставить пакеты с одинаковым названием, но разными пакетными менеджерами.

В таком случае нужно пользоваться параметром name, чтобы избежать ошибки:

package { 'ruby-mysql':
  ensure => installed,
  name => 'mysql',
  provider => 'gem',
}
  package { 'python-mysql':
  ensure => installed,
  name => 'mysql',
  provider => 'pip',
}

В других типах ресурсов есть аналогичные параметры, помогающие избежать дубликации, — name у service, command у exec, и так далее.

4.2. Метапараметры.

Некоторые специальные параметры есть у каждого типа ресурса, независимо от его сущности.

Полный список метапараметров в документации Puppet.

Краткий список:

• require — в этом параметре указывается, от каких ресурсов зависит данный ресурс.
• before — в этом параметре указывается, какие ресурсы зависят от данного ресурса.
• subscribe — в этом параметре указывается, от каких ресурсов получает уведомления данный ресурс.
• notify — в этом параметре указывается, какие ресурсы получают уведомления от данного ресурса.

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

4.3. Ссылки на ресурсы.

Ссылка на ресурс — это просто упоминание ресурса. Используются они в основном для указания зависимостей. Ссылка на несуществующий ресурс вызовет ошибку компиляции.

Синтаксис у ссылки следующий: тип ресурса с большой буквы (если в названии типа содержатся двойные двоеточия, то с большой буквы пишется каждая часть названия между двоеточиями), дальше в квадратных скобках название ресурса (регистр названия не меняется). Пробелов быть не должно, квадратные скобки пишутся сразу после названия типа.

Пример:

file { '/file1':
  ensure => present }
file { '/file2':
  ensure => directory,
  before => File['/file1'],
}
file { '/file3':
  ensure => absent }
File['/file1'] -> File['/file3']

4.4. Зависимости и уведомления.

Добавление узла в группу

Чтобы включить узел в группу, необходимо перейти в его настройки.

После этого в первой вкладке добавляем группу, как на скриншоте ниже:

После этого нажимаем

Submit

и в течение нескольких минут на узле сети появится

mysql

. Таким же образом можно присвоить остальным двум серверам группу

web

Вся конфигурация распространяется на puppet-агенты автоматически в течение нетокоротого времени.

Если не хочется ждать, то можно на клиентах выполнить команду puppet agent –test и увидеть своими глазами, как создаётся конфигурация.

Знакомство с классами, переменными и дефайнами.

Предположим, у нас несколько нод, на которых есть одинаковая часть конфигурации, но есть и различия — иначе мы могли бы описать это всё в одном блоке node {}. Конечно, можно просто скопировать одинаковые части конфигурации, но в общем случае это плохое решение — конфигурация разрастается, при изменении общей части конфигурации придётся править одно и то же во множестве мест.

Для решения такой проблемы есть такая конструкция, как класс.

5.1. Классы.

Первые шаги на серверах.

5.1. Как временно или навсегда отключить SELinux.

Когда вы устанавливаете CentOS 7, функция SELinux включена по умолчанию, из-за этого некоторые приложения в вашей системе могут фактически не поддерживать этот механизм безопасности. Чтобы такие приложения функционировали нормально, вам необходимо отключить SELinux на всех серверах.

Ссылка:«CentOS 7: Как временно или навсегда отключить SELinux».

Конечно в интернете имеется много способов настройки и эксплуатации этой системы, но в данной инструкции я, настраивать SELinux не буду.

5.2. Настройка часового пояса и синхронизации времени.

Внимание!Сервис Puppet крайне чувствителен к синхронизации времени между сервером и агентами. Рассинхронизация даже в несколько минут может приводить к отказу в обслуживании.

Очень важно иметь правильно настроенную систему учета времени на сервере, потому что сервер — существо электромеханическое и все процессы в нём ориентируются на точно время. Например, резервное копирование, мониторинг и синхронизация с другими системами в сети.

Чтобы время на сервере CentOS 7 соответствовало вашему часовому поясу, его можно изменить вручную.

Ссылка:«CentOS 7: Настройка часового пояса. Утилита tzdata».

Ссылка:«CentOS 7: Настройка синхронизация времени по Network Time Protocol. Утилита chrony».

Для корректной работы сервера требуется правильно настроить его синхронизацию времени по Network Time Protocol.

5.3. Первичная настройка брандмауэра.

По умолчанию в системе CentOS 7 нет сервиса Puppet, но мы можем открыть порт 8140 для работы Puppetmaster вручную.

Для этого просто добавьте нужный порт 8140 к зоне:

# firewall-cmd –zone=public –add-port=8140/tcp –permanent

Чтобы удалить порт 8140 из зоны, выполните:

# firewall-cmd –zone=public –remove-port=8140/tcp –permanent

Аналогично сервисам, чтобы открыть порт в firewall в CentOS 7 надо перезагрузить брандмауэр:

# firewall-cmd –reload

Ответы:

Настройка Puppet master сервера.

Устанавливаем Midnight Commander:

# yum install -y mc

Puppet чувствителен к именам узлов, поэтому задаем имена сервера и тестового клиента в файле hosts:

# mcedit /etc/hosts

Модифицируем содержимое файла, добавим в конце файла:

192.168.0.17 puppet-srv.hamsterden.loc
192.168.0.14 puppet-cl14.hamsterden.loc
192.168.0.15 puppet-cl15.hamsterden.loc
192.168.0.16 puppet-cl16.hamsterden.loc

Также зададим имя нашего Puppet master сервера:

# mcedit /etc/hostname

Модифицируем содержимое файла:

puppet-srv.hamsterden.loc

Сначала установим репозиторий для Puppet 3 версии на Puppet master:

Настройка прав доступа с помощью модуля accounts

Собственно сейчас можно ещё раз посмотреть на схему, которую мы привели в начале и на основе её создать логику.

1 Настройка класса ssh

В классе

accounts

мы настроили ssh-доступ по ключам. Потому для более полной безопасности необходимо запретить доступ по паролю. Делается это с помощью класса

ssh

. Переходим в его настройки и открываем вкладку

Smart Class Parameter

. Далее

client options

приводим к следующему виду:

Вкладку

server options

приводим к следующему виду:

И вкладку

storeconfigs enabled

заполняем так:

storeconfigs

хранятся все факты о клиентах, поэтому вы можете запросить базу данных и получить списки узлов сети, соответствующие определенным критериям. Для большей безопасности мы это отключили.

Модули.

Когда конфигурация маленькая, её легко можно держать в одном манифесте. Но чем больше конфигурации мы описываем, тем больше классов и нод становится в манифесте, он разрастается, с ним становится неудобно работать.

Кроме того, есть проблема переиспользования кода — когда весь код в одном манифесте, сложно этим кодом делиться с другими. Для решения этих двух проблем в Puppet есть такая сущность, как модули.

Модули — это наборы классов, дефайнов и прочих Puppet-сущностей, вынесенных в отдельную директорию. Иными словами, модуль — это независимый кусок Puppet-логики. Например, может быть модуль для работы с nginx, и в нём будет то и только то, что нужно для работы с nginx, а может быть модуль для работы с PHP, и так далее.

Модули версионируются, также поддерживаются зависимости модулей друг от друга. Есть открытый репозиторий модулей — Puppet Forge.

Настройка Puppet node / Puppet client (агентов).

Заходим в каждую систему по списку клиент-серверов под root:

# sudo su

Обновляем список пакетов:

# yum update && yum upgrade

Устанавливаем Midnight Commander:

# yum install -y mc

Задаем имя сервера Puppet master в файле hosts:

# mcedit /etc/hosts

Просто добавьте в конце текста в файле эту строку:

192.168.0.17 puppet-srv.hamsterden.loc

Также зададим имя Puppet клиента, соответствующего порядковому номеру из списка:

# mcedit /etc/hostname

Просто добавьте в файл эту строку, взамен старой информации:

puppet-cl14.hamsterden.loc

Чтобы все изменения вступили в силу желательно перезапустить службу (сервис) systemd-hostnamed:

# systemctl restart systemd-hostnamed

Чтобы увидеть имя хоста сервера в CentOS 7 воспользуйтесь командой hostnamectl:

# hostnamectl status

Подключаем репозиторий:

Результаты

В процессе выполнения данного руководства ваша инфраструктура добавленная под управление Puppet станет быстро-конфигурируемой и масштабируемой. А главная цель — управления публичными ssh ключами будет максимально удобной.

Тестирование работы системы Puppet.

Теперь у нас в системе установлен Puppet и с ним можно поиграть.

8.1. Тестирование автономной архитектуры — Puppet apply.

Протестируем работу режима Puppet apply, напишем манифест самому себе, то есть для Puppet master сервера.

В качестве теста, создадим манифест-правило:

# mcedit /etc/puppet/manifests/nodes/files2.pp

Модифицируем содержимое файла:

file { '/tmp/helloworld':
  ensure => present,
  content => 'Hello, world!',
  mode => 0644,
  owner => 'root',
  group => 'root'
}

И применим его в режиме автономной архитектуры:

# puppet apply /etc/puppet/manifests/nodes/files2.pp

Ответ:

Теперь посмотрите на содержимое файла /tmp/helloworld. В нём окажется строка «Hello, world!», которую мы задали в манифесте.

Факты и встроенные переменные.

Зачастую конкретная часть конфигурации зависит от того, что в данный момент происходит на ноде. Например, в зависимости от того, какой релиз Debian стоит, нужно установить ту или иную версию пакета. Можно следить за этим всем вручную, переписывая манифесты в случае изменения нод. Это несерьёзный подход, автоматизация гораздо лучше.

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

Факты — это информация о ноде, доступная в манифестах в виде обычных переменных в глобальном пространстве имён. Например, имя хоста, версия операционной системы, архитектура процессора, список пользователей, список сетевых интерфейсов и их адресов, и многое, многое другое. Факты доступны в манифестах и шаблонах как обычные переменные.

Пример работы с фактами:

notify { "Running OS ${facts['os']['name']} version ${facts['os']['release']['full']}": }
# ресурс типа notify просто выводит сообщение в лог

Если говорить формально, то у факта есть имя (строка) и значение (доступны различные типы: строки, массивы, словари). Есть набор встроенных фактов. Также можно писать собственные. Сборщики фактов описываются как функции на Ruby, либо как исполняемые файлы. Также факты могут быть представлены в виде текстовых файлов с данными на нодах.

Оригинальная документация прилагается:

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

9.1. Факты в виде исполняемых файлов.

Такие факты кладутся в модули в директорию facts.d. Разумеется, файлы должны быть исполняемыми. При запуске они должны выводить на стандартный вывод информацию либо в формате YAML, либо в формате «ключ=значение«.

Не забывайте, что факты распространяются на все ноды, которые находятся под управлением паппет-сервера, на который выкатывается ваш модуль. Поэтому в скрипте озаботьтесь проверкой того, что в системе есть все необходимые для работы вашего факта программы и файлы.

Commit и push

Оставайтесь в git репозитории — пришло время выполнить commit и push первой версии окружения

production

Из-за того, что git не позволяет сохранять пустые директории, а у нас пока что нет локальных модулей, добавьте фиктивный файл директорию

site

touch site/.keep

Удостоверьтесь, что у вас правильная ветка, добавьте все файлы и выполните commit и push:

git checkout -b production
git add *
git commit -a -m "initital commit"
git push -u origin production

В результате вы должны получить примерно такой ответ:

Counting objects: 11, done.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (11/11), 867 bytes | 0 bytes/s, done.
Total 11 (delta 0), reused 0 (delta 0)
remote: 
remote: --> Deploying production...
remote: 
To /srv/puppet.git
 * [new branch]      production -> production
Branch production set up to track remote branch production from origin.

Обратите внимание на сообщение

--> Deploying production...

, которое означает, что наш git хук сработал.

Вы может так же проверить, что директория

/etc/puppet/environments/production

была создана и содержимое ее папки

modules

содержит модули Puppet Forge, которые мы перечислили в

Puppetfile

Shellgit-провайдер

Этот провайдер доступен по умолчанию, и подойдет в тех случаях, если вы собираетесь использовать git-репозиторий в локальном каталоге без git-сервера; или простейший git-сервер с доступом по ssh.

Содержимое конфиуграционного файла /etc/puppetlabs/r10k/r10k.yaml:

Агенты

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

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

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

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

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

Дополнения от переводчика

У себя на Puppet Master я настроил связку

. Все репозитории лежат в gitolite, изменения можно удобно просматривать в браузере (

мне показался слишком монструозным с большим количеством зависимостей и ненужным в моем случае функционалом). Директория /etc/puppet тоже лежит в отдельном git репозитории (

environments

добавлены в

.gitignore

Для мониторинга отчетов я использую

— очень удобный интерфейс для PuppetDB, работающий на стороне клиента (написан на

AngularJSCoffeeScript

Ссылки:

Запуск puppet

Переключитесь обратно на пользователя

root

и запустите puppet агента:

puppet agent --test

Вы должны получить несколько экранов вывода черного и зеленого текста, описывающих прогресс инсталляции и конфигурации NTP и PuppetDB сервисов, включая базу данных PostgreSQL, необходимую для PuppetDB.

Проверьте, что сервисы запущены:

/etc/init.d/ntp status
/etc/init.d/puppetdb status

Конфигурирование репозитория puppet-environments.git

Первоначальная настройка репозитория. Склонируем репозиторий puppet-environments на свой рабочий компьютер:

Листинг сертификатов запросов

Когда серверы агентов Puppet подключаются к сети, если все настроено правильно, они отправляют запрос на подпись сертификата мастеру Puppet. Эти запросы можно просмотреть с помощью команды puppet cert list.

Мастер

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

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

Настройка hiera

Hiera так же требует некоторой конфигурации. Создайте файл

/etc/puppet/hiera.yaml

---
:hierarchy:
  - "nodes/%{::fqdn}"
  - "manufacturers/%{::manufacturer}"
  - "virtual/%{::virtual}"
  - common
:backends:
  - yaml
:yaml:
  :datadir: "/etc/puppet/environments/%{::environment}/hieradata"

Для того, что бы сделать отладку Hiera немного проще и избежать путаницы в дальнейшем, я предпочитаю заменить файл

/etc/hiera.yaml

(о котором Puppet даже не подозревает) символической ссылкой на

/etc/puppet/hiera.yaml

ln -sf /etc/puppet/hiera.yaml /etc/hiera.yaml

Настройка puppet

Создайте директорию, в которой будут расположены настройки ваших окружений и дайте группе

puppet

права на запись:

mkdir /etc/puppet/environments
chgrp puppet /etc/puppet/environments
chmod 2775 /etc/puppet/environment

Мы никогда не будем редактировать содержимое данной директории напрямую, за нас это будет делать

r10k

через git hook, который мы настроим чуть позже.

Теперь необходимо сделать некоторые настройки в файле /etc/puppet/puppet.conf. Вот неплохой пример, с которого вы можете начать:

[main]
  environment   = production
  confdir       = /etc/puppet
  logdir        = /var/log/puppet
  vardir        = /var/lib/puppet
  ssldir        = $vardir/ssl
  rundir        = /var/run/puppet
  factpath      = $vardir/lib/facter
  templatedir   = $confdir/templates
  pluginsync    = true

[agent]
  environment   = production
  report        = true
  show_diff     = true

[master]
  environment   = production
  manifest      = $confdir/environments/$environment/manifests/site.pp
  modulepath    = $confdir/environments/$environment/modules:$confdir/environments/$environment/site
  # Passenger
  ssl_client_header        = SSL_CLIENT_S_DN
  ssl_client_verify_header = SSL_CLIENT_VERIFY

Примечание от переводчика: начиная с версии 3.6, переменные manifest/modulepath/config_versionустарели в пользу окружений.

Настройка r10k

Необходимо создать директорию с кешами, в которой

r10k

будет хранить копии модулей:

mkdir /var/cache/r10k
chgrp puppet /var/cache/r10k
chmod 2775 /var/cache/r10k

И конечно же,

r10k

имеет свой файл с настройками. Создайте

/etc/r10k.yaml

со следующим содержимым:

# location for cached repos
:cachedir: '/var/cache/r10k'

# git repositories containing environments
:sources:
  :base:
    remote: '/srv/puppet.git'
    basedir: '/etc/puppet/environments'

# purge non-existing environments found here
:purgedirs:
  - '/etc/puppet/environments'

Настройка ноды puppet-master01

Сервер сертификации

. Убедимся, что в файле /etc/puppetlabs/puppetserver/services.d/ca.cfg включен запуск сервиса сертификации:

puppetlabs.services.ca.certificate-authority-service/certificate-authority-service

Строка

НЕ

должна быть закомментирована.

Настроим список DNS имен сервераВ файле /etc/puppetlabs/puppet/puppet.conf нужно прописать альтернативные имена DNS для puppet-master01, для этого в секцию [main] добавим:

Настройка ноды puppet-master02

На остальных серверах puppet-master, кроме первого, нужно отключить запуск сервиса сертификации в файле /etc/puppetlabs/puppetserver/services.d/ca.cfg. Нужно закомментировать строку с certificate-authority-service, и раскомментировать sertificate-authority-disabled-service:

# To enable the CA service, leave the following line uncommented
#puppetlabs.services.ca.certificate-authority-service/certificate-authority-service
# To disable the CA service, comment out the above line and uncomment the line below
puppetlabs.services.ca.certificate-authority-disabled-service/certificate-authority-disabled-service

Настроим список DNS имен сервера в файле /etc/puppetlabs/puppet/puppet.conf, для этого в секцию [main] добавим:

Настройка прав доступа

Пришло время начать настраивать Puppet в git репозитории.

Вы не должны работать с git репозиторием из под пользователя root, поэтому добавьте своего пользователя в группу

puppet

, которая будет использована для ограничения доступа к репозиторию:

Общие настройки puppet-агентов

В файл /etc/puppetlabs/puppet/puppet.conf добавить настройки сервера сертификации и имя сервера puppet, к которому они будут обращаться (имя кластера):

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

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

Пример 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.

Проверка hiera

Если вы дошли до этого шага, значит Hiera уже работает, но вам может быть неоходимо во время разработки потестировать Hiera из командной строки.

Надеюсь, вы последовали моему совету и сделали файл /etc/hiera.yaml символической ссылкой на /etc/puppet/hiera.yaml. Тогда следующая команда перечислит все классы, которые будут применены к текущему хосту в production окружении:

hiera -a classes ::environment=production ::fqdn=$(hostname -f)

В результате вы должны получить:

["puppetdb", "puppetdb::master::config", "ntp"]

Проверка post-recive хука

Создадим директорию manifets и файл .keep, чтобы git не игнорировал пустую директорию:

aspetrenko@aspetrenko-pc:~/sgl-git/puppet-environments$ touch manifests/.keep
aspetrenko@aspetrenko-pc:~/sgl-git/puppet-environments$ git add  manifests/.keep
aspetrenko@aspetrenko-pc:~/sgl-git/puppet-environments$ git commit manifests/.keep -m "Test commit"
[production 72bd288] Test commit
 1 file changed, 0 insertions( ), 0 deletions(-)
 create mode 100644 manifests/.keep

Отправим изменения в репозиторий:

aspetrenko@aspetrenko-pc:~/sgl-git/puppet-environments$ git push -u origin production

Дальше git-хук с помощью r10k внесет соответствующие изменения в /etc/puppetlabs/code/environments на каждом сервере. Проверим наличие изменений на puppet-master01 и puppet-master02.

Проверка puppetdb

Запустите puppet еще раз, чтобы наполнить данными postgresql:

puppet agent --test

После этого запустите такую команду:

puppet node status $(hostname -f)

Вы должны получить примерно такой ответ:

testpm.qix.no
Currently active
Last catalog: 2021-11-20T13:22:05.036Z
Last facts: 2021-11-20T13:22:00.437Z

Полезный совет: попробуйте следующую команду, чтобы увидеть всю информацию о вашем хосте, которую хранит puppetdb в отформатированном json:

puppet node find $(hostname -f) | python -mjson.tool

Теперь puppetdb полностью настроен и вы можете использовать

для таких вещей как распределение ssh ключей по всем хостам.

Проверка работоспособности puppet

Сейчас самое время перезапустить сервис Puppet Master:

/etc/init.d/puppetmaster restart

Проверьте работоспособность Puppet агента:

puppet agent --test

В результате вы должны получить нечто похожее:

Info: Retrieving plugin
Error: /File[/var/lib/puppet/lib]: Could not evaluate: Could not retrieve information from environment production source(s) puppet://testpm.qix.no/plugins
Info: Caching catalog for testpm.qix.no
Info: Applying configuration version '1384949455'
Info: Creating state file /var/lib/puppet/state/state.yaml
Notice: Finished catalog run in 0.03 seconds

Единственная ошибка может быть проигнорирована, т.к. у нас еще нет ни конфигов, ни плагинов.

Перед тем как продолжать, удостоверьтесь, что данная команда работает. Проблемы на данном этапе скорее всего связаны с DNS.

Процесс работы с puppet master

Создание веток в git не требует особых усилий, поэтому процесс разработки будет выглядеть так:

# создайте новую ветку и сделайте требуемые изменения
git checkout -b new_feature
vim somefile
git add somefile
git commit -m "best feature ever"

# новая ветка == новое окружение
git push --set-upstream origin new_feature

# проведите тесты (ведь вы это будете делать на тестовом сервере, не так ли?)
puppet agent --test --noop --environment new_feature
puppet agent --test --environment new_feature

# diff and merge
git checkout production
git diff ..new_feature
git diff --name-only new_feature
git merge new_feature

# выложите новую фичу в production
git push

# удалите локальную ветку
git branch -d new_feature

# удалите ветку с сервера == удалить окружение
git push origin :new_feature

Процесс работы с модулями

Если вы работаете над модулем, который вы хотите использовать на нескольких серверах Puppet Master (но не отдавать наружу), один из способов это сделать — выложить на внутренний git сервер и настроить ветку, над которой вы работаете в

Puppetfile

Создание git репозитория

Теперь создайте новый git репозиторий, который станет главным источником Puppet конфигурации для вашего сервера.

Все ваши администраторы будут работать с этим репозиторием, а

r10k

будет обновляться из него, чтобы автоматически создавать (или удалять) окружения Puppet.

Создайте новый репозиторий в

/srv/puppet.git

git init --bare --shared=group /srv/puppet.git
chgrp -R puppet /srv/puppet.git
cd /srv/puppet.git
git symbolic-ref HEAD refs/heads/production

Обратите внимание, что у этого репозитория есть три отличительных особенности:

1. он bare;
2. он shared;
3. ветка master переименована в production.

Создание git хука

Продолжайте работать под своим обычным пользователем.

Создайте файл

/srv/puppet.git/hooks/post-receive

, который будет запускать

r10k

при каждом push’е в репозиторий:

Создание первого окружения

Перейдите в домашнюю директорию под своим обычным пользователем и склонируйте пустой репозиторий:

cd
git clone /srv/puppet.git
cd puppet

Создайте несколько необходимых директорий:

mkdir -p hieradata/nodes manifests site

Папку

modules

мы не создаем, т.к. она будет управляться через

r10k

. Локальные модули (т.е. модули исключительно для данного puppet master сервера) будут располагаться в директории

site

Теперь давайте приступим к настройке

r10k

. Создайте файл

Puppetfile

в корне репозитория со следующим содержимым:

Установка git

К сожалению, версия git, которая идет в поставке Ubuntu 12.04, подвержена

, который устанавливает неверные права (0755) на все новые окружения Puppet. Это не позволяет расшаривать репозитории между несколькими пользователями.

Добавьте PPA от команды поддержки git:

apt-get install python-software-properties
add-apt-repository ppa:git-core/ppa

Установите последнюю стабильную версию git:

apt-get update
apt-get install git

Установка librarian-puppet

На компьютере, где мы работаем с репозиторием, с помощью gem установим librarian-puppet:

aspetrenko@aspetrenko-pc:~/sgl-git/puppet-environments$ sudo gem install librarian-puppet

Удалим директорию modules со всеми вложенными файлами, которые были скопированы из первоначального репозитория Puppet:

aspetrenko@aspetrenko-pc:~/sgl-git/puppet-environments$ git rm -rf modules

Проинициализируем librarian-puppet в репозитории:

aspetrenko@aspetrenko-pc:~/sgl-git/puppet-environments$ librarian-puppet init

Закомментируем строку с metadata в Puppetfile. Приведем Puppetfile к следующему виду:

Установка r10k

Бесподобный

создал такую же бесподобную утилиту для управления динамическими окружениями Puppet и эффективного использования внешних модулей — неважно, нашли ли вы их на

или храните их в своем собственном репозитории.

Дополнительную информацию вы можете найти на страничке

. Для установки выполните команды:

apt-get install rubygems
gem install r10k

Централизованное управление конфигурациями: puppet foreman. часть і

Заключение

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