Библиотека сайта rus-linux.net
Puppet: простой инструмент для автоматической конфигурации множества машин
Оригинал: Puppet: Configure many machines the easy way
Автор: Jon Archer
Дата публикации: 30 марта 2016 г.
Перевод: A. Панин
Дата перевода: 4 мая 2016 г.
Выполнение повторяющихся последовательностей действий отравляет жизнь всех системных администраторов. Именно поэтому у нас есть Puppet - мощный инструмент для одновременной автоматической конфигурации множества машин.
Для чего это нужно?
- Вы сможете автоматизировать выполнение повторяющихся последовательностей действий.
- Вы сможете осуществлять достаточно быстрое развертывание масштабируемых вычислительных окружений.
- Вы узнаете о важном инструменте из нового мира облачных вычислений.
Puppet является утилитой для управления конфигурацией систем, которая была спроектирована с целью автоматизации выполнения различных административных задач на различных системах. Файлы манифестов, описывающие особенности конфигурации компонентов системы, создаются с использованием языка Puppet с собственным синтаксисом и используются для конфигурации систем Linux (или Unix, Mac, Windows). Данный подход позволяет автоматизировать выполнение административных задач, сократив затраты времени на выполнение повторяющихся последовательностей действий - что по сути и является основной целью системного администратора.
Хотя упомянутые манифесты и могут исполняться на локальных системах для выполнения описанных административных задач, в случае их хранения на центральном сервере, метко названным "мастер-сервером Puppet", появляется возможность выполнения автоматической конфигурации множества машин из сети. Делегирование функций хранения описаний особенностей конфигурации машин отдельному серверу значительно упрощает процесс автоматического конфигурирования множества серверов и рабочих станций в рамках отдельных сетей.
Давайте рассмотрим пример компании, в которой используется 50 серверов с статическими IP-адресами. После ввода в строй нового сервера доменных имен на каждом из этих 50 серверов придется внести изменения в файл конфигурации /etc/resolv.conf. Без инструментов управления конфигурацией систем эти изменения могут вноситься либо путем установки соединений по протоколу SSH с каждым из серверов и ручного редактирования упомянутого файла конфигурации, либо путем копирования на каждый из серверов обновленного файла конфигурации с помощью утилиты scp, на что уйдет слишком много времени. В случае задействования Puppet для этой цели будет использоваться небольшой файл манифеста, который будет передаваться всем клиентам Puppet (или агентам) при следующем обмене данными и содержать директивы для копирования файла конфигурации и выполнения необходимых мероприятий.
Как говорилось ранее, система управления конфигурацией Puppet состоит из двух элементов: мастер-сервера Puppet, на котором хранятся все манифесты и агентов Puppet, которые исполняются на всех клиентских серверах или рабочих станциях. Агенты опрашивают мастер-сервер через заданные промежутки времени (по умолчанию через каждые 30 минут) и проверяют изменения в принятых от него манифестах.
Пакеты RPM доступны из репозитория по адресу yum.puppetlabs.com, пакеты DEB - из репозитория по адресу apt.puppetlabs.com
В рамках данного руководства мы рассмотрим процесс установки и настройки мастер-сервера Puppet и соединенных с ним агентов для автоматизации процесса изменения конфигурации машин, на которых будут установлены упомянутые агенты. Мы будем использовать дистрибутив CentOS 7, но стоит иметь в виду, что пакеты программного обеспечения с компонентами Puppet доступны из репозиториев большинства, а может быть и всех существующих на сегодняшний день дистрибутивов.
Перед установкой Puppet следует обратить внимание на системные требования:
- Необходимо установить имена узлов - это позволит осуществлять гарантированную передачу корректной информацию в процессе их конфигурации.
- Необходимо настроить сервер DNS - как и в большинстве проектов, записи сервера доменных имен или файла с именами узлов сети (/etc/hosts) являются важным элементом процесса сетевого взаимодействия, позволяющим использовать имена машин, а их не IP-адреса.
- Агенты Puppet по умолчанию используют имя узла 'puppet' для доступа к мастер-серверу Puppet - и хотя на уровне каждого из клиентов может быть установлено отличное имя мастер-сервера, гораздо проще соответствующим образом настроить сервер доменных имен или создать соотвествующий файл с именами узлов сети.
- Необходимо настроить сервер NTP - очень важно организовать автоматический процесс установки точного времени на всех машинах для того, чтобы все компоненты Puppet функционировали корректно, главным образом ввиду того, что мастер-сервер также выполняет функции центра выдачи сертификатов. В том случае, если на машинах с мастер-сервером и агентами будет установлено отличающееся время, в некоторых случаях сертификат может быть признан просроченным, а изменения в конфигурации машины - не применены.
Мы запускаем фоновые службы Puppet с помощью systemd. Попытайтесь не увлекаться чтением всех сообщений мастер-сервера Puppet
В данном руководстве мы будем считать, что у нас есть три сервера, работающих под управлением минимального варианта операционной системы CentOS 7, на одном из которых установлен мастер-сервер Puppet, а на всех других - агенты Puppet (эти серверы имеют имена server1, server2 и server3 и IP-адреса 192.168.1.10, 192.168.1.11 и 192.168.1.12 соответственно).
Добавьте следующие строки в файлы с именами узлов сети на всех трех машинах:
192.168.1.210 server1.localdomain server1 puppet 192.168.1.211 server2.localdomain server2 192.168.1.212 server3.localdomain server3
Теперь нам придется установить пакеты программного обеспечения на всех этих серверах. Разработчики PuppetLabs, сопровождающие рассматриваемое программное обеспечение, создали репозитории пакетов программного обеспечения с пакетами новейших версий. Кроме того, они разрабатывают Enterprise-версию Puppet, которую не стоит путать с версией с открытым исходным кодом, рассматриваемой в данной статье.
Давайте подключим репозиторий пакетов программного обеспечения, из которого мы будем устанавливать пакеты с компонентами Puppet:
yum localinstall http://yum.puppetlabs.com/puppetlabs-release-el-7.noarch.rpm
После подключения репозитория мы можем установить компоненты Puppet:
yum install puppet-server
С помощью данной команды осуществляется установка мастер-сервера Puppet и всех его зависимостей.
После установки рассматриваемого пакета программного обеспечения в первую очередь нужно сгенерировать сертификат SSL. Этот сертификат будет использоваться для шифрования данных в процессе взаимодействия сервера и агентов Puppet, причем мастер-сервер Puppet будет использовать этот сертификат сразу же после поступления первых запросов подписи сертификатов от агентов, поэтому данная генерация сертификата является первым этапом процесса организации безопасного и надежного канала обмена данными. Существует множество вариантов генерации сертификата, которые должны использоваться в зависимости от желаемой конфигурации; например, генерация сертификата должна осуществляться особым образом при настройке нескольких мастер-серверов Puppet в рамках одной сети, но так как мы используем простейшую конфигурацию сети с одним мастер-сервером, процесс генерации сертификата не будет представлять каких-либо сложностей. Нам придется запустить мастер-сервер Puppet без перехода в режим демона (фоновый режим):
puppet master --verbose --no-daemonize
После этого вы увидите следующие строки в выводе:
Сразу же после того, как вы увидите сообщение о том, что начатая мастер-сервером Puppet генерация сертификата завершилась, вы можете продолжить работу. Теперь вам придется использовать сочетание клавиш Ctrl+C для завершения работы запущенного процесса мастер-сервера, после чего активировать соответствующий юнит systemd и запустить мастер-сервер в режиме демона с помощью этого юнита:
systemctl start puppetmaster systemctl enable puppetmaster
Необходимо убедиться в том, что на уровне межсетевого экрана открыт порт, используемый агентами для соединения с мастер-сервером:
firewall-cmd --add-port=8140/tcp --permanent firewall-cmd --reload
В данном руководстве мы деактивируем механизм мандатного доступа SELinux для того, чтобы быть уверенными в том, что он не встанет на нашем пути; выполните две следующие команды для его деактивации:
sed -i s/SELINUX=enforcing/SELINUX=disabled/g /etc/selinux/config setenforce 0
Мастер-сервер Puppet установлен и исполняется на сервере с именем server1, причем на серверах с именами server2 и server3 для установки агентов должна быть выполнена аналогичная последовательность действий.
Во-первых, хорошей идеей является ознакомление с содержимым системного журнала на машине с мастер-сервером с целью отслеживания всех входящих соединений со стороны агентов.
Давайте поищем в системном журнале информацию обо всех входящих запросах подписи сертификатов, отправленных агентами мастер-серверу:
tailf /var/log/messages
Теперь выполним следующую команду для подключения репозиториев пакетов программного обеспечения PuppetLabs на серверах с именами server2 и server3:
yum -y localinstall http://yum.puppetlabs.com/puppetlabs-release-el-7.noarch.rpm
После этого мы можем установить пакет программного обеспечения с компонентами агента Puppet:
yum -y install puppet
На следующем шаге следует запустить и активировать службу агента Puppet:
systemctl start puppet systemctl enable puppet
Мы также можем запустить и активировать службу агента Puppet на сервере с именем server1; в конце концов, это тоже сервер, конфигурацией которого нужно управлять.
Сразу же после запуска агента он отправит запрос подписи сертификата на мастер-сервер Puppet. Как говорилось ранее, это один из этапов процесса организации канала безопасного и надежного взаимодействия между мастер-сервером и агентами. После запуска клиента и отправки запроса подписи сертификата вы должны обнаружить в системном журнале сервера с именем server1 соответствующие записи.
Feb 2 14:11:07 puppet puppet-master[20580]: server2.localdomain has a waiting certificate request
Обратите внимание на то, что нам не пришлось осуществлять какую-либо конфигурацию машин с агентами Puppet. Это объясняется тем, что ранее мы добавили в строку описания сервера с именем server1 файла с именами узлов сети псевдоним puppet, с которым по умолчанию связывается каждый агент Puppet и это значительно упростило процесс внедрения системы управления конфигурацией серверов.
После установки и запуска агентов на серверах с именами server2 и server3, мы можем вернуться к мастер-серверу и изучить запросы подписи сертификатов (скорее всего, вам придется открыть дополнительное окно терминала, если вы не желаете закрывать окно с обновляемым выводом содержимого системного журнала).
Выполните следующую команду:
puppet cert list
В результате будет выведен список всех запросов подписи сертификатов, которые могут быть одобрены с помощью следующей команды:
puppet cert sign fqdn
Вместо строки fqdn следует использовать полностью определенное доменное имя сервера, отправившего запрос подписи сертификата - оно выводится после выполнения приведенной выше команды list. Мы должны увидеть два ожидающих одобрения запроса подписи сервтификата от серверов с именами server2 и server3, поэтому давайте одобрим их:
puppet cert sign server2.localdomain puppet cert sign server3.localdomain
Список всех сертификатов, как подписанных, так и не подписанных, может быть выведен после выполнения следующей команды:
puppet cert list --all
Процесс подписи сертификатов является последним этапом достаточно простого процесса настройки и ввода в эксплуатацию системы Puppet. Теперь мы можем начинать распространение конфигурационных данных между агентами.
В системе CentOS файлы конфигурации мастер-сервера Puppet хранятся в директории /etc/puppet. В рамках данной директории существует несколько поддиректорий: в данном руководстве нас будут интересовать лишь директории с файлами манифестов (manifests) и файлами модулей (modules). Каталог конфигурации Puppet, загружаемый каждым из агентов, всегда начинается с файла с именем site.pp из директории манифестов. В рамках данного файла могут описываться агенты, которым разрешается устанавливать соединение с мастер-сервером, в формате узлов (node). Параметры конфигурации, изменения которых должны отслеживаться этими узлами, описываются в формате классов (class).
Существует два типа описания узлов, которые мы будем рассматривать в данной статье: стандартное описание узла и описание узла с указанием его имени. Стандартное описание узла соответствует всем узлам, для которых не создано отдельных описаний. В то же время, описание узла с указанием его имени позволяет задавать параметры конфигурации для отдельного узла. Давайте рассмотрим простое описание из файла манифеста /etc/manifests/site.pp:
node default {
include resolvconf
}
node 'server2.localdomain'
include resolvconf
include test
}
Данный файл манифеста с именем site.pp на самом деле содержит целых два описания узлов, а именно, стандартное описание узла и описание узла с именем server2. В рамках данных описаний приведены классы конфигурации, которые будут применены к соответствующим узлам. Таким образом, в нашем окружении для серверов с именами server1 и server3 будет использоваться стандартный класс конфигурации resolvconf, так как для них не создано отдельных описаний. В то же время, для сервера с именем server2 создано отдельное описание с этим же классом конфигурации resolvconf, а также с дополнительным классом конфигурации test.
Давайте рассмотрим классы конфигурации, установленные для наших узлов. Эти классы описывают списки изменений конфигурационных данных, которые могут приниматься агентом и могут размещаться в рамках модуля. Модуль Puppet является отличным механизмом для объединения манифестов конфигурации Puppet и ассоциированных с ними данных. В случае нашего класса test, мы можем создать соответствующий модуль конфигурации и поместить в него наш манифест. В руководстве Puppet говорится, что практически все манифесты должны быть связаны с какими-либо модулями конфигурации, за исключением манифеста site.pp, с которым мы сталкивались ранее. Данные модулей размещаются в директории /etc/puppet/modules, причем в этой директории могут создаваться различные поддиректории для хранения различных элементов модуля.
Каждый манифест, ассоциированный с модулем, хранится в поддиректории manifests директории модуля в файле с именем init.pp и содержит описание класса (имя класса должно совпадать с именем модуля). Исходя из этого, файл манифеста нашего модуля test должен быть расположен по следующему пути:
/etc/puppet/modules/test/manifests/init.pp
Давайте рассмотрим объявление класса:
class test{
}
В данном случае мы объявили класс конфигурации test. Это объявление не позволяет выполнить какие-либо функции; для выполнения функций нам придется разобраться с ресурсами. Каждый ресурс описывает какой-либо аспект конфигурируемой системы, например, устанавливаемый пакет программного обеспечения, контролируемую системную службу или модифицируемый файл. Для того, чтобы осуществлять управление тем или иным ресурсом на заданном узле нам придется описать его в рамках нашего класса. Класс test будет использоваться для отправки простого уведомления, поэтому нам придется использовать тип ресурса notify (уведомление). Само уведомление может быть описано следующим образом:
notify {"I'm notifying you.":}
После добавления описания данного ресурса notify в объявление нашего класса конфигурации, последнее будет выглядеть следующим образом:
class test{
notify {"I'm notifying you.":}
}
После того, как агент Puppet, работающий на сервере с именем server2, получит список изменений параметров конфигурации с мастер-сервера, в загруженном каталоге будет обнаружено объявление ресурса уведомления, причем для ознакомления с самим уведомлением вам придется прочитать последние сообщения из системного журнала.
Давайте попробуем реализовать описанную схему на практике: отредактируйте файл /etc/puppet/manifests/site.pp на вашем мастер-сервере следующим образом:
node 'server2.localdomain' {
include test
}
mkdir /etc/puppet/modules/test/manifests -p
edit
/etc/puppet/modules/test/manifests/init.pp
class test{
notify {" test notification ":}
}
Выполните следующую команду на сервере с именем server2 для получения информации об изменениях параметров конфигурации в ручном режиме:
puppet agent -t
Вы должны увидеть следующий вывод, а также введенный ранее текст уведомления:
[root@server2 ~]# puppet agent -t Info: Retrieving pluginfacts Info: Retrieving plugin Info: Caching catalog for server2.localdomain Info: Applying configuration version 1426284530 Notice: test notification Notice: /Stage[main]/Test/Notify[ test notification ]/message: defined message as test notification Notice: Finished catalog run in 0.05 seconds
Теперь, когда мы рассмотрели основные аспекты создания манифестов, пришло время заняться полезной работой. Одним из классов, упомянутых в файле манифеста site.pp, был класс resolvconf (include resolvconf). Давайте автоматизируем создание/модификацию файла /etc/resolv.conf на наших серверах. Для этого нам понадобится тип ресурса file (файл), который сообщит нашим агентам о необходимости загрузки файла из так называемого файлового хранилища. Файловое хранилище является директорией, которая находится в директории модуля рядом с директорией для хранения файлов манифестов. В нашем случае файл resolv.conf должен быть сохранен без каких-либо изменений в файловом хранилище модуля resolvconf. Структура директорий модуля должна выглядеть следующим образом:
/etc/puppet/modules/resolvconf - manifests/init.pp - files/resolv.conf
Файл манифеста для данного модуля должен содержать объявление класса resolvconf и путь к файлу resolv.conf, который должен загружаться агентами.
class resolvconf {
file { "/etc/resolv.conf":
ensure => file,
source => 'puppet:///modules/resolvconf/resolv.conf',
path => "/etc/resolv.conf",
owner => root,
group => root,
mode => 644,
}
}
Данный манифест сообщает нашим агентам о необходимости загрузки файла resolv.conf из нашего файлового хранилища, сохранения загруженного файла под именем /etc/resolv.conf, установки прав доступа к этому файлу (точнее идентификаторов владельца файла, группы владельцев файла и прав доступа к файлу), а также проверки корректности создания файла. Манифест позволяет гарантированно распространить файл resolv.conf между всеми нашими серверами для их корректной конфигурации, причем любые локальные изменения этого файла будут автоматически перезаписаны в ходе последующей операции получения списка изменений параметров конфигурации от мастер-сервера.
Файл /etc/puppet/modules/resolvconf/files/resolv.conf должен содержать следующие строки:
search localdomain nameserver 192.168.1.1
Для того, чтобы убедиться в корректном подключении рассматриваемого модуля, мы можем убрать изменения в файле site.pp и добавить класс конфигурации resolvconf как в стандартное описание узлов, так и в описание узла с именем server2. Теперь следует повторно выполнить следующую команду:
puppet agent -t
В результате модуль будет использоваться как агентом с узла с заданным именем, так и агентами со всех остальных узлов, так как данный класс конфигурации был добавлен и в стандартное описание узлов.
В данной статье мы всего лишь кратко рассмотрели вопрос использования манифестов конфигурации Puppet. Существуют и другие аспекты использования Puppet, такие, как организация установки пакетов программного обеспечения, распространение конфигурационных файлов и управление системными службами. Рассмотренный программный продукт позволяет выполнять практически все мероприятия, связанные с администрированием системы, организовывать автоматическое выполнение повторяющихся операций, а также осуществлять управление процессом развертывания стеков программного обеспечения для быстрого внедрения программных продуктов, что является ключевой функцией в современном мире облачных сервисов и масштабируемых систем.