Puppet, система управления конфигурациями. Часть I
Puppet — это инструмент, который позволяет автоматизировать настройку и управление большим парком машин. Используя Puppet вы сможете централизованно управлять конфигурациями одной, десятков, сотен и тысяч машин.
В этой статье я расскажу об основных особенностях системы.
Puppet написана на Ruby, архитектура — клиент-серверная. На каждом управляемом узле находится клиент, который периодически обращается по https к серверу за обновлениями конфигурации.
Язык управления конфигурациями
Конфигурация описывается на специальном языке. Базовыми элементами конфигурации являются ресурсы. Каждый ресурс имеет тип, атрибуты и название. Самый простой пример ресурса, файловый:
Этот ресурс включает проверку владельца файла /etc/passwd, и если он отличен от root, Puppet устанавливает юзера root хозяином этого файла.
Ресурсы можно (и обычно нужно) группировать в классы. Например, класс для Postfix будет содержать ресурсы и для установки и для настройки почтового сервера Postfix.
Одним из главных элементов описания конфигурации является узел (node). Узел позволяет описывать функциональность определённого типа. Скажем, можно описать узел «офисный десктоп», или «веб-сервер». Соответственно, для офисного десктопа будет установлено и настроено всё необходимое для офиса ПО, а для веб-сервера какой-нибудь апач или nginx.
Вообще, язык описания конфигурации поддерживает практически все фичи нормального ООП-языка. Так что, по сути получается, что вы как бы программируете поведение машин. Действительно, в результате получается довольно наглядное описание, которое легко читать и понимать.
Сообщество юзеров делится своими наработками, в терминах Puppet они называются «рецептами».
Следующее, что необходимо отметить, это платформонезависимость. Ваши сценарии могут разворачиваться одинаково на Linux и FreeBSD, все особенности конкретной платформы учитываются клиентом Puppet. Вы можете ознакомиться со списком поддерживаемых платформ, чтобы убедиться, что ваша любимая ОС поддерживается Puppet. Windows в этом списке нет, но сообщается, что Puppet в ней работает через cygwin.
Что касается производительности. Она и сейчас довольно неплохая. Скажем, вы можете управлять 50-100 машинами с помощью довольно средненького сервера с 2 гигами памяти. Однако, на подходе версия 0.25, в которой одной из главных фич является переход с XML-RPC на REST, что означает существенное улучшение производительности.
Кроме того, как практически любой веб-сервис, Puppet масштабируется. Puppet можно запускать с помощью nginx и Mongrel. Так что вы можете не опасаться ситуации, когда вдруг ваша организация разрастётся до больших размеров, Puppet с этой работой справится 
Резюме
Завершая эту вводную статью, хочу особенно отметить тот факт, что Puppet может быть очень полезен для вас, даже если у вас всего один сервер. Имея хорошо задокументированный конфиг, в случае краха сервера вы очень быстро сможете развернуть хозяйство на другом сервере, так как установка и настройка почти всего, что нужно, будет осуществлена в автоматическом режиме.
В следующей части я опишу установку, настройку и базовые возможности Puppet.
Если вам не терпится узнать о Puppet больше прямо сейчас, милости просим в документацию
Puppet: простой инструмент для автоматической конфигурации множества машин
Оригинал: Puppet: Configure many machines the easy way
Автор: Jon Archer
Дата публикации: 30 марта 2016 г.
Перевод: A. Панин
Дата перевода: 4 мая 2016 г.
Для чего это нужно?
Хотя упомянутые манифесты и могут исполняться на локальных системах для выполнения описанных административных задач, в случае их хранения на центральном сервере, метко названным «мастер-сервером Puppet», появляется возможность выполнения автоматической конфигурации множества машин из сети. Делегирование функций хранения описаний особенностей конфигурации машин отдельному серверу значительно упрощает процесс автоматического конфигурирования множества серверов и рабочих станций в рамках отдельных сетей.
Как говорилось ранее, система управления конфигурацией Puppet состоит из двух элементов: мастер-сервера Puppet, на котором хранятся все манифесты и агентов Puppet, которые исполняются на всех клиентских серверах или рабочих станциях. Агенты опрашивают мастер-сервер через заданные промежутки времени (по умолчанию через каждые 30 минут) и проверяют изменения в принятых от него манифестах.
В рамках данного руководства мы рассмотрим процесс установки и настройки мастер-сервера Puppet и соединенных с ним агентов для автоматизации процесса изменения конфигурации машин, на которых будут установлены упомянутые агенты. Мы будем использовать дистрибутив CentOS 7, но стоит иметь в виду, что пакеты программного обеспечения с компонентами Puppet доступны из репозиториев большинства, а может быть и всех существующих на сегодняшний день дистрибутивов.
Перед установкой Puppet следует обратить внимание на системные требования:
Мы запускаем фоновые службы Puppet с помощью systemd. Попытайтесь не увлекаться чтением всех сообщений мастер-сервера Puppet
Добавьте следующие строки в файлы с именами узлов сети на всех трех машинах:
Теперь нам придется установить пакеты программного обеспечения на всех этих серверах. Разработчики PuppetLabs, сопровождающие рассматриваемое программное обеспечение, создали репозитории пакетов программного обеспечения с пакетами новейших версий. Кроме того, они разрабатывают Enterprise-версию Puppet, которую не стоит путать с версией с открытым исходным кодом, рассматриваемой в данной статье.
Давайте подключим репозиторий пакетов программного обеспечения, из которого мы будем устанавливать пакеты с компонентами Puppet:
После подключения репозитория мы можем установить компоненты Puppet:
С помощью данной команды осуществляется установка мастер-сервера Puppet и всех его зависимостей.
После установки рассматриваемого пакета программного обеспечения в первую очередь нужно сгенерировать сертификат SSL. Этот сертификат будет использоваться для шифрования данных в процессе взаимодействия сервера и агентов Puppet, причем мастер-сервер Puppet будет использовать этот сертификат сразу же после поступления первых запросов подписи сертификатов от агентов, поэтому данная генерация сертификата является первым этапом процесса организации безопасного и надежного канала обмена данными. Существует множество вариантов генерации сертификата, которые должны использоваться в зависимости от желаемой конфигурации; например, генерация сертификата должна осуществляться особым образом при настройке нескольких мастер-серверов Puppet в рамках одной сети, но так как мы используем простейшую конфигурацию сети с одним мастер-сервером, процесс генерации сертификата не будет представлять каких-либо сложностей. Нам придется запустить мастер-сервер Puppet без перехода в режим демона (фоновый режим):
После этого вы увидите следующие строки в выводе:
Сразу же после того, как вы увидите сообщение о том, что начатая мастер-сервером Puppet генерация сертификата завершилась, вы можете продолжить работу. Теперь вам придется использовать сочетание клавиш Ctrl+C для завершения работы запущенного процесса мастер-сервера, после чего активировать соответствующий юнит systemd и запустить мастер-сервер в режиме демона с помощью этого юнита:
Необходимо убедиться в том, что на уровне межсетевого экрана открыт порт, используемый агентами для соединения с мастер-сервером:
В данном руководстве мы деактивируем механизм мандатного доступа SELinux для того, чтобы быть уверенными в том, что он не встанет на нашем пути; выполните две следующие команды для его деактивации:
Мастер-сервер Puppet установлен и исполняется на сервере с именем server1, причем на серверах с именами server2 и server3 для установки агентов должна быть выполнена аналогичная последовательность действий.
Во-первых, хорошей идеей является ознакомление с содержимым системного журнала на машине с мастер-сервером с целью отслеживания всех входящих соединений со стороны агентов.
Давайте поищем в системном журнале информацию обо всех входящих запросах подписи сертификатов, отправленных агентами мастер-серверу:
Теперь выполним следующую команду для подключения репозиториев пакетов программного обеспечения PuppetLabs на серверах с именами server2 и server3:
После этого мы можем установить пакет программного обеспечения с компонентами агента Puppet:
На следующем шаге следует запустить и активировать службу агента Puppet:
Мы также можем запустить и активировать службу агента Puppet на сервере с именем server1; в конце концов, это тоже сервер, конфигурацией которого нужно управлять.
Сразу же после запуска агента он отправит запрос подписи сертификата на мастер-сервер Puppet. Как говорилось ранее, это один из этапов процесса организации канала безопасного и надежного взаимодействия между мастер-сервером и агентами. После запуска клиента и отправки запроса подписи сертификата вы должны обнаружить в системном журнале сервера с именем server1 соответствующие записи.
Обратите внимание на то, что нам не пришлось осуществлять какую-либо конфигурацию машин с агентами Puppet. Это объясняется тем, что ранее мы добавили в строку описания сервера с именем server1 файла с именами узлов сети псевдоним puppet, с которым по умолчанию связывается каждый агент Puppet и это значительно упростило процесс внедрения системы управления конфигурацией серверов.
После установки и запуска агентов на серверах с именами server2 и server3, мы можем вернуться к мастер-серверу и изучить запросы подписи сертификатов (скорее всего, вам придется открыть дополнительное окно терминала, если вы не желаете закрывать окно с обновляемым выводом содержимого системного журнала).
Выполните следующую команду:
В результате будет выведен список всех запросов подписи сертификатов, которые могут быть одобрены с помощью следующей команды:
Список всех сертификатов, как подписанных, так и не подписанных, может быть выведен после выполнения следующей команды:
Процесс подписи сертификатов является последним этапом достаточно простого процесса настройки и ввода в эксплуатацию системы Puppet. Теперь мы можем начинать распространение конфигурационных данных между агентами.
Существует два типа описания узлов, которые мы будем рассматривать в данной статье: стандартное описание узла и описание узла с указанием его имени. Стандартное описание узла соответствует всем узлам, для которых не создано отдельных описаний. В то же время, описание узла с указанием его имени позволяет задавать параметры конфигурации для отдельного узла. Давайте рассмотрим простое описание из файла манифеста /etc/manifests/site.pp :
Каждый манифест, ассоциированный с модулем, хранится в поддиректории manifests директории модуля в файле с именем init.pp и содержит описание класса (имя класса должно совпадать с именем модуля). Исходя из этого, файл манифеста нашего модуля test должен быть расположен по следующему пути:
Давайте рассмотрим объявление класса:
После добавления описания данного ресурса notify в объявление нашего класса конфигурации, последнее будет выглядеть следующим образом:
После того, как агент Puppet, работающий на сервере с именем server2, получит список изменений параметров конфигурации с мастер-сервера, в загруженном каталоге будет обнаружено объявление ресурса уведомления, причем для ознакомления с самим уведомлением вам придется прочитать последние сообщения из системного журнала.
Давайте попробуем реализовать описанную схему на практике: отредактируйте файл /etc/puppet/manifests/site.pp на вашем мастер-сервере следующим образом:
Выполните следующую команду на сервере с именем server2 для получения информации об изменениях параметров конфигурации в ручном режиме:
Вы должны увидеть следующий вывод, а также введенный ранее текст уведомления:
Файл /etc/puppet/modules/resolvconf/files/resolv.conf должен содержать следующие строки:
Для того, чтобы убедиться в корректном подключении рассматриваемого модуля, мы можем убрать изменения в файле site.pp и добавить класс конфигурации resolvconf как в стандартное описание узлов, так и в описание узла с именем server2. Теперь следует повторно выполнить следующую команду:
В результате модуль будет использоваться как агентом с узла с заданным именем, так и агентами со всех остальных узлов, так как данный класс конфигурации был добавлен и в стандартное описание узлов.
В данной статье мы всего лишь кратко рассмотрели вопрос использования манифестов конфигурации Puppet. Существуют и другие аспекты использования Puppet, такие, как организация установки пакетов программного обеспечения, распространение конфигурационных файлов и управление системными службами. Рассмотренный программный продукт позволяет выполнять практически все мероприятия, связанные с администрированием системы, организовывать автоматическое выполнение повторяющихся операций, а также осуществлять управление процессом развертывания стеков программного обеспечения для быстрого внедрения программных продуктов, что является ключевой функцией в современном мире облачных сервисов и масштабируемых систем.
Операционные системы Astra Linux
Оперативные обновления и методические указания
Операционные системы Astra Linux предназначены для применения в составе информационных (автоматизированных) систем в целях обработки и защиты 1) информации любой категории доступа 2) : общедоступной информации, а также информации, доступ к которой ограничен федеральными законами (информации ограниченного доступа).
1) от несанкционированного доступа;
2) в соответствии с Федеральным законом от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации» (статья 5, пункт 2).
Операционные системы Astra Linux Common Edition и Astra Linux Special Edition разработаны коллективом открытого акционерного общества «Научно-производственное объединение Русские базовые информационные технологии» и основаны на свободном программном обеспечении. С 17 декабря 2019 года правообладателем, разработчиком и производителем операционной системы специального назначения «Astra Linux Special Edition» является ООО «РусБИТех-Астра».
На web-сайтах https://astralinux.ru/ и https://wiki.astralinux.ru представлена подробная информация о разработанных операционных системах семейства Astra Linux, а также техническая документация для пользователей операционных систем и разработчиков программного обеспечения.
Мы будем признательны Вам за вопросы и предложения, которые позволят совершенствовать наши изделия в Ваших интересах и адаптировать их под решаемые Вами задачи!
Репозитория открытого доступа в сети Интернет для операционной системы Astra Linux Special Edition нет. Операционная система распространяется посредством DVD-дисков.
Информацию о сетевых репозиториях операционной системы Astra Linux Common Edition Вы можете получить в статье Подключение репозиториев с пакетами в ОС Astra Linux и установка пакетов.
В целях обеспечения соответствия сертифицированных операционных систем Astra Linux Special Edition требованиям, предъявляемым к безопасности информации, ООО «РусБИтех-Астра» осуществляет выпуск очередных и оперативных обновлений.
Очередные обновления (версии) предназначены для:
Оперативные обновления предназначены для оперативного устранения уязвимостей в экземплярах, находящихся в эксплуатации, и представляют собой бюллетень безопасности, который доступен в виде:
Ввиду совершенствования нормативно-правовых документов в области защиты информации и в целях обеспечения соответствия информационных актуальным требованиям безопасности информации, а также обеспечения их долговременной эксплуатации, в том числе работоспособности на современных средствах вычислительной техники, рекомендуется на регулярной основе планировать проведение мероприятий по применению очередных и оперативных обновлений операционной системы.
🐹 Puppet 3. Часть 1: Установка, настройка, начало эксплуатации.
Опубликовано 2021-04-07 · Обновлено 2021-04-07
Содержание:
Данная статья — это часть цикла статей по эксплуатации системы управления конфигурацией — Puppet 3:
На чем было опробовано:
1. Введение.
Предположим, что у вас есть парк серверов, выполняющих различные задачи. Пока серверов мало и вы не растёте, вы легко настраиваете каждый сервер вручную. Устанавливаете операционную систему (может быть, автоматизированно), добавляете пользователей, устанавливаете софт, вводя команды в консоль, настраиваете сервисы, правите конфигурации ваших любимых текстовых редакторов, выставляете на них одинаковые настройки DNS-сервера, устанавливаете агент системы мониторинга, настраиваете syslog для централизованного сбора логов… Словом, работы довольно много и она не особенно интересна.
Хороший админ — ленивый админ. Он не любит делать что-то несколько раз.
Первая мысль — написать пару скриптов:
Вроде всё стало легко и хорошо. Нужно что-то сделать — пишем новый скрипт, запускаем. Изменения приходят на все серверы последовательно. Если скрипт хорошо отлажен — всё станет хорошо. До поры…
Теперь представьте, что серверов стало больше. Например, сотня! А изменение долгое — например, сборка чего-нибудь большого и страшного (например, ядра) из исходников. Скрипт будет выполняться сто лет, но это полбеды.
Представьте, что вам нужно сделать это только на определенной группе из этой сотни серверов. А через два дня нужно сделать другую большую задачу на другом срезе серверов. Вам придётся каждый раз переписывать скрипты и много раз проверять, нет ли в них каких-нибудь ошибок, не вызовет ли это какой-нибудь проблемы при запуске.
Самое плохое — это то, что в подобных скриптах вы описываете действия, которые необходимо выполнить для приведения системы в определенное состояние, а не само это состояние. Значит, если система изначально находилась не в том состоянии, что вы предполагали, то всё обязательно пойдет не так.
Манифесты Puppet декларативно описывают необходимое состояние системы, а вычисление, как к нему прийти из текущего состояния — задача самой системы управления конфигурацией.
Для сравнения: манифест Puppet, выполняющий ту же работу, что и пара скриптов из начала манифеста:
Если правильно использовать серверы и потратить некоторое время на первичную настройку системы управления конфигурацией, можно добиться такого состояния парка серверов, что вам не потребуется вводить логин и пароль на них для выполнения работы. Все необходимые изменения будут приходить к ним автоматически.
2. Что такое 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.
3. Знакомство с манифестами.
В терминологии Puppet к Puppet master подключаются ноды — Puppet nodes. Конфигурация для нод пишется в манифестах на специальном языке программирования — Puppet DSL.
Puppet DSL — декларативный язык. На нём описывается желаемое состояние ноды в виде объявления отдельных ресурсов, например:
Ресурсы могут быть взаимосвязаны:
Кроме того, в Puppet DSL есть функции и переменные, а также условные операторы и селекторы.
Puppet поддерживает шаблоны в формате EPP и ERB :
Puppet написан на Ruby, поэтому многие конструкции и термины взяты оттуда. Ruby позволяет расширять Puppet — дописывать сложную логику, новые типы ресурсов, функции.
Во время работы Puppet манифесты для каждой конкретной ноды на сервере компилируются в каталог.
Каталог — это список ресурсов и их взаимосвязей после вычисления значения функций, переменных и раскрытия условных операторов.
4. Подготовка инфраструктуры.
Для настройки архитектуры Agent/Master, потребуется подготовить свое рабочее окружение. Для демонстрации программного обеспечения Puppet создадим 4 виртуальных машины на базе операционной системы CentOS 7.
Можно сделать и одну ноду, но мне было лень откатываться из резервной копии и «очищать» одну и тоже ноду, поэтому я наклонировал сразу три и игрался с ними.
Puppet master
Puppet clients
Operating system: CentOS 7 minimal
IP Address: 192.168.0.17
HostName: puppet-srv.hamsterden.locm
Operating system: CentOS 7 minimal
IP Address: 192.168.0.14
HostName: puppet-cl14.hamsterden.loc
IP Address: 192.168.0.15
HostName: puppet-cl15.hamsterden.loc
IP Address: 192.168.0.16
HostName: puppet-cl16.hamsterden.loc
5. Первые шаги на серверах.
5.1. Как временно или навсегда отключить SELinux.
Когда вы устанавливаете CentOS 7, функция SELinux включена по умолчанию, из-за этого некоторые приложения в вашей системе могут фактически не поддерживать этот механизм безопасности. Чтобы такие приложения функционировали нормально, вам необходимо отключить SELinux на всех серверах.
Конечно в интернете имеется много способов настройки и эксплуатации этой системы, но в данной инструкции я, настраивать SELinux не буду.
5.2. Настройка часового пояса и синхронизации времени.
Внимание! Сервис Puppet крайне чувствителен к синхронизации времени между сервером и агентами. Рассинхронизация даже в несколько минут может приводить к отказу в обслуживании.
Очень важно иметь правильно настроенную систему учета времени на сервере, потому что сервер — существо электромеханическое и все процессы в нём ориентируются на точно время. Например, резервное копирование, мониторинг и синхронизация с другими системами в сети.
Чтобы время на сервере CentOS 7 соответствовало вашему часовому поясу, его можно изменить вручную.
Для корректной работы сервера требуется правильно настроить его синхронизацию времени по Network Time Protocol.
5.3. Первичная настройка брандмауэра.
По умолчанию в системе CentOS 7 нет сервиса Puppet, но мы можем открыть порт 8140 для работы Puppet master вручную.
Для этого просто добавьте нужный порт 8140 к зоне:
Чтобы удалить порт 8140 из зоны, выполните:
Аналогично сервисам, чтобы открыть порт в firewall в CentOS 7 надо перезагрузить брандмауэр:
Ответы:
6. Настройка Puppet master сервера.
Устанавливаем Midnight Commander:
Puppet чувствителен к именам узлов, поэтому задаем имена сервера и тестового клиента в файле hosts:
Модифицируем содержимое файла, добавим в конце файла:
Также зададим имя нашего Puppet master сервера:
Модифицируем содержимое файла:
Сначала установим репозиторий для Puppet 3 версии на Puppet master:
Устанавливаем Puppet:
Разрешаем автозапуск puppet-сервера:
# systemctl enable puppetmaster.service
По умолчанию, Puppet настроен для оптимальной работы.
Единственное, что мы сделаем, включим автоматическое подтверждение сертификатов от клиентов:
Модифицируем содержимое файла:
Конфигурационные файлы правил в Puppet называются манифестами. Удобнее делить правила по различным файлам.
Для этого отредактируем основной манифест-файл:
Добавим в содержимое файла:
Создаем каталог nodes :
В качестве теста, создадим первый манифест-правило:
Модифицируем содержимое файла files.pp :
Запускаем службу Puppet:
# systemctl start puppetmaster.service
7. Настройка Puppet node / Puppet client (агентов).
Заходим в каждую систему по списку клиент-серверов под root:
Обновляем список пакетов:
# yum update && yum upgrade
Устанавливаем Midnight Commander:
Задаем имя сервера Puppet master в файле hosts :
Просто добавьте в конце текста в файле эту строку:
Также зададим имя Puppet клиента, соответствующего порядковому номеру из списка:
Просто добавьте в файл эту строку, взамен старой информации:
Чтобы все изменения вступили в силу желательно перезапустить службу (сервис) systemd-hostnamed:
# systemctl restart systemd-hostnamed
Чтобы увидеть имя хоста сервера в CentOS 7 воспользуйтесь командой hostnamectl:
Устанавливаем Puppet:
Редактируем конфигурационный файл Puppet:
Просто добавьте эти строки по аналогии в соответствующий раздел файла:
Запускаем Puppet:
# systemctl start puppet.service
Проверяем подключение клиента puppet-cl14.hamsterden.loc к серверу puppet-srv.hamsterden.loc :
Проверяем на клиенте сработало ли правило с мастера?
Всё настроено исправно и программа выполняется!
Или выскочит ошибка:
Ошибку легко исправить. Откройте порт 8140 у Puppet master. Описание исправления ошибки ниже по тексту этой инструкции.
8. Тестирование работы системы Puppet.
Теперь у нас в системе установлен Puppet и с ним можно поиграть.
8.1. Тестирование автономной архитектуры — Puppet apply.
Протестируем работу режима Puppet apply, напишем манифест самому себе, то есть для Puppet master сервера.
В качестве теста, создадим манифест-правило:
Модифицируем содержимое файла:
И применим его в режиме автономной архитектуры:
# puppet apply /etc/puppet/manifests/nodes/files2.pp
Ответ:
На самом деле, необходимо было бы написать:
# touch /tmp/helloworld
# echo ‘Hello, world!’ > /tmp/helloworld
# chmod 644 /tmp/helloworld
# chown root /tmp/helloworld
# chgrp root /tmp/helloworld
Давайте по строкам разберём, что именно содержится в нашем манифесте:
8.2. Описание ноды и ресурса на ней.
Установим Puppet agent на остальные виртуальные машины, по аналогии с текстом инструкции выше.
В качестве теста, создадим манифест-правило:
Права на файл заданы в виде строки (в кавычках), потому что иначе число с 0 в начале будет воспринято как записанное в восьмеричной системе, и всё пойдёт не так, как задумано.
Зайдем на puppet-cl14.hamsterden.loc :
И запросим манифесты с Puppet master для puppet-cl14.hamsterden.loc :
Агент запросит манифесты с сервера и выполнит их. В ответе несколько манифестов на выполнении, в том числе и тот, пример которого мы сейчас с вами сделали.
Ответ:
На puppet-cl14.hamsterden.loc что-то пошло не так.
Ответ с puppet-cl14.hamsterden.loc :
Зато puppet-cl15.hamsterden.loc цветет и пахнет.
Ответ с puppet-cl15.hamsterden.loc :
Так что если что-то работать не будет сразу или не на всех Puppet node, то смотрите логику манифестов и их алгоритм работы, возможно вы допустили ошибку.
8.3. Взаимосвязи ресурсов на ноде.
На ноде puppet-cl14.hamsterden.loc должен быть запущен nginx, работающий с подготовленной заранее конфигурацией.
Создадим манифест-правило не для всех нод, а только для puppet-cl16.hamsterden.loc :
Зайдем на puppet-cl14.hamsterden.loc :
И запросим манифесты с Puppet master для puppet-cl16.hamsterden.loc :
Ответ:
Проверим стартанул ли сервис после автоустановки nginx без нашего участия?
# systemctl status nginx
Ответ:
Еще можно с Puppet master подкачивать на ноды, заранее подготовленные файлы конфигураций, создавать каталоги и удалять программное обеспечение. Всё это можно найти в расширенных примерах работы Puppet оркестратора. В рамках этой инструкции будет только первоначальное знакомство и установка Puppet.
Все остальные шаблоны легко можно найти на просторах интернета.
9. Возможные ошибки или если что-то пошло не так.
9.1. Удаление сертификатов.
Бывает, что «что-то идет не так» и подключить Puppet agent к Puppet master не удается:
Иногда на Puppet master забыли пробросить порт 8140 или необходимо удалить битый сертификат.
Будем считать, что порт 8140 проброшен и займёмся сертификатом.
Для этого сначала выполняем команду на сервере:
# puppet cert clean puppet-cl14.hamsterden.loc
Затем, деликатно, на клиенте:
Или, чтоб наверняка, бахнем всё:
Если всё рано выскакивает ошибка, то уже точно на Puppet master не проброшен порт 8140 и его отсекает межсетевой экран. Отключите брандмауэр или настройте проброс порта.
10. Как узнать версию Puppet.
Более новые версии, отличные от версии Puppet 3, используют другую командную строку.
Команда для Puppet 3 будет соответственно:
Для версий до Puppet 4.0, если Puppet был установлен как пакет RPM, вы можете запросить базу данных RPM:
Ответ:
Puppetlabs изменили свою упаковку, и упакованная версия Puppet не указана номером версии пакета puppet-agent.
11. Полезные команды.
11.1. Проверка текущих параметров.
Для проверки всех текущих параметров Puppet сервера есть полезная команда:
# puppet config print
Ответ: большой и длинный список параметров и их значений.
11.2. Проверка состояния сертификатов.
Для проверки списка сертификатов:
Если с плюсом, значит подписан.
Ответ:
Если он без плюса, значит его надо подписать:
Чтобы удалить сертификат host‘а с именем « pm » нужно ввести команду:
# puppet cert clean pm
Ответ:
12. Готовые конфигурации из репозиториев.
В Puppet предусмотрен репозиторий готовых конфигураций от других пользователей.
Данный раздел зарезервирован для инструкции по работе с готовыми конфигурациями из репозиториев, он здесь скоро появится.
13. Примеры манифестов.
Задает права и владельца для файла /etc/passwd :
Устанавливает последнюю версию пакета samba:
Данная статья — это часть цикла статей по эксплуатации системы управления конфигурацией — Puppet 3: