Кукольный — Обзор

Puppet — это инструмент управления конфигурацией, разработанный Puppet Labs для автоматизации управления инфраструктурой и ее конфигурации. Puppet — очень мощный инструмент, который помогает понять концепцию инфраструктуры как кода. Этот инструмент написан на языке Ruby DSL, который помогает конвертировать полную инфраструктуру в формат кода, которым легко управлять и настраивать.

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

Особенности кукольной системы

Ниже приведены наиболее важные функции Puppet.

идемпотентность

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

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

Кросс-платформенная

В Puppet с помощью Resource Abstraction Layer (RAL), который использует ресурсы Puppet, можно ориентироваться на указанную конфигурацию системы, не беспокоясь о деталях реализации и о том, как команда конфигурации будет работать внутри системы, которые определены в базовой конфигурации. файл.

Кукольный — Рабочий процесс

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

• В Puppet первое, что делает мастер Puppet, это собирает информацию о целевой машине. Используя коэффициент, который присутствует на всех узлах Puppet (аналогично Ohai в Chef), он получает все детали конфигурации уровня машины. Эти данные собираются и отправляются обратно Хозяину Марионеток.

• Затем мастер марионеток сравнивает извлеченную конфигурацию с определенными деталями конфигурации и с определенной конфигурацией создает каталог и отправляет его целевым агентам Puppet.

• Затем агент Puppet применяет эти конфигурации, чтобы привести систему в нужное состояние.

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

В Puppet первое, что делает мастер Puppet, это собирает информацию о целевой машине. Используя коэффициент, который присутствует на всех узлах Puppet (аналогично Ohai в Chef), он получает все детали конфигурации уровня машины. Эти данные собираются и отправляются обратно Хозяину Марионеток.

Затем мастер марионеток сравнивает извлеченную конфигурацию с определенными деталями конфигурации и с определенной конфигурацией создает каталог и отправляет его целевым агентам Puppet.

Затем агент Puppet применяет эти конфигурации, чтобы привести систему в нужное состояние.

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

Кукольный — Ключевые компоненты

Ниже приведены ключевые компоненты Puppet.

Кукольные Ресурсы

Кукольные ресурсы являются ключевыми компонентами для моделирования любой конкретной машины. Эти ресурсы имеют свою собственную модель реализации. Puppet использует ту же модель, чтобы получить любой конкретный ресурс в желаемом состоянии.

Провайдеры

Поставщики в основном являются исполнителями любого конкретного ресурса, используемого в Puppet. Например, типы пакетов ‘apt-get’ и ‘yum’ допустимы для управления пакетами. Иногда на конкретной платформе может быть доступно более одного поставщика. Хотя у каждой платформы всегда есть поставщик по умолчанию.

манифест

Манифест — это набор ресурсов, которые связаны внутри функции или классов для настройки любой целевой системы. Они содержат набор кода Ruby для настройки системы.

Модули

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

Шаблоны

Шаблоны используют выражения Ruby для определения настраиваемого содержимого и ввода переменных. Они используются для разработки пользовательского контента. Шаблоны определяются в манифестах и ​​копируются в место в системе. Например, если кто-то хочет определить httpd с настраиваемым портом, то это можно сделать с помощью следующего выражения.

Listen <% = @httpd_port %>

Переменная httpd_port в этом случае определяется в манифесте, который ссылается на этот шаблон.

Статические файлы

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

Кукольный — Архитектура

Ниже приводится схематическое представление архитектуры Puppet.

Хозяин Марионеток

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

Кукольный агент

Агенты Puppet — это фактические рабочие машины, которыми управляет мастер Puppet. В них работает служба демона Puppet Agent.

Репозиторий Конфиг

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

факты

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

Каталог

Все файлы манифеста или конфигурации, записанные в Puppet, сначала преобразуются в скомпилированный формат, называемый каталогом, а затем эти каталоги применяются на целевом компьютере.

Кукольный — Установка

Puppet работает на архитектуре клиент-сервер, в которой мы называем сервер хозяином Puppet, а клиент — узлом Puppet. Эта настройка достигается путем установки Puppet как на клиенте, так и на всех серверах.

Для большинства платформ Puppet может быть установлен с помощью выбранного менеджера пакетов. Однако для некоторых платформ это можно сделать, установив tarball или RubyGems .

Предпосылки

Фактор является единственным предварительным условием, которое не сопровождает Ohai, который присутствует в Chef.

Стандартная библиотека ОС

Нам нужно иметь стандартный набор библиотек любой базовой ОС. Оставшаяся вся система поставляется вместе с версиями Ruby 1.8.2 +. Ниже приведен список элементов библиотеки, из которых должна состоять ОС.

• base64
• CGI
• дайджест / md5
• так далее
• FileUtils
• IPADDR
• OpenSSL
• strscan
• системный журнал
• URI
• WEBrick
• WEBrick / HTTPS
• XMLRPC

Установка Facter

Как уже говорилось, в комплект поставки не входит стандартная версия Ruby. Таким образом, для того, чтобы получить facter в целевой системе, необходимо установить его вручную из источника, поскольку библиотека facter является предпосылкой Puppet.

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

Сначала скачайте тарбол с официального сайта Puppet с помощью утилиты wget .

$ wget http://puppetlabs.com/downloads/facter/facter-latest.tgz  ------: 1 

Затем распакуйте файл tar. Зайдите в каталог Untarred с помощью команды CD. Наконец, установите facter с помощью файла install.rb, который находится внутри каталога facter .

$ gzip -d -c facter-latest.tgz | tar xf - -----: 2 
$ cd facter-* ------: 3 
$ sudo ruby install.rb # or become root and run install.rb -----:4 

Установка Puppet из источника

Сначала установите архив Puppet с сайта Puppet с помощью wget . Затем извлеките тарбол в нужное место. Переместитесь в созданный каталог с помощью команды CD . Используя файл install.rb , установите Puppet на базовый сервер.

# get the latest tarball 
$ wget http://puppetlabs.com/downloads/puppet/puppet-latest.tgz -----: 1

# untar and install it 
$ gzip -d -c puppet-latest.tgz | tar xf - ----: 2 
$ cd puppet-* ------: 3 
$ sudo ruby install.rb # or become root and run install.rb -------: 4 

Установка Puppet и Facter с использованием Ruby Gem

# Installing Facter 
$ wget http://puppetlabs.com/downloads/gems/facter-1.5.7.gem 
$ sudo gem install facter-1.5.7.gem

# Installing Puppet 
$ wget http://puppetlabs.com/downloads/gems/puppet-0.25.1.gem 
$ sudo gem install puppet-0.25.1.gem 

Кукольный — Конфигурация

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

Открытые порты брандмауэра на машинах

Чтобы сервер Puppet централизованно управлял сервером клиента, необходимо открыть указанный порт на всех машинах, т. Е. Можно использовать 8140 , если он не используется ни на одной из машин, которые мы пытаемся настроить. Нам нужно включить как TCP, так и UDP связь на всех машинах.

Конфигурационный файл

Основной файл конфигурации для Puppet это etc / puppet / puppet.conf . Все файлы конфигурации создаются в пакетной конфигурации Puppet. Большая часть конфигурации, необходимой для настройки Puppet, хранится в этих файлах, и после запуска Puppet эти конфигурации автоматически выбираются. Однако для некоторых конкретных задач, таких как настройка веб-сервера или внешнего центра сертификации (CA), Puppet имеет отдельную конфигурацию для файлов и настроек.

Файлы конфигурации сервера находятся в каталоге conf.d, который также называется мастером Puppet. Эти файлы по умолчанию расположены в /etc/puppetlabs/puppetserver/conf.d path. Эти файлы конфигурации имеют формат HOCON, который сохраняет базовую структуру JSON, но он более читабелен. Когда происходит запуск Puppet, он берет все файлы .cong из каталога conf.d и использует их для внесения любых изменений в конфигурацию. Любые изменения в этих файлах имеют место только при перезапуске сервера.

Файл списка и файл настроек

• global.conf
• webserver.conf
• веб-routes.conf
• puppetserver.conf
• auth.conf
• master.conf (устарело)
• ca.conf (устарело)

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

Puppet.conf

Файл Puppet.conf является основным файлом конфигурации Puppet. Puppet использует один и тот же файл конфигурации для настройки всех необходимых команд и служб Puppet. В этом файле определены все параметры, связанные с Puppet, такие как определение мастера Puppet, агента Puppet, применение Puppet и сертификаты. Марионетка может отослать их согласно требованию.

Конфигурационный файл напоминает стандартный INI-файл, в котором настройки можно перейти в конкретный раздел приложения основного раздела.

Главный раздел конфигурации

[main] 
certname = Test1.vipin.com 
server = TestingSrv 
environment = production 
runinterval = 1h 

Файл конфигурации Puppet Master

[main] 
certname = puppetmaster.vipin.com 
server = MasterSrv 
environment = production 
runinterval = 1h 
strict_variables = true  
[master] 

dns_alt_names = MasterSrv,brcleprod01.vipin.com,puppet,puppet.test.com 
reports = puppetdb 
storeconfigs_backend = puppetdb 
storeconfigs = true 
environment_timeout = unlimited 

Подробный обзор

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

Раздел конфигурации

Файл конфигурации Puppet в основном состоит из следующих разделов конфигурации.

• Main — Это называется глобальным разделом, который используется всеми командами и службами в Puppet. Один определяет значения по умолчанию в главном разделе, которые могут быть переопределены любым разделом, присутствующим в файле puppet.conf.

• Мастер — этот раздел передается мастером Puppet и командой Puppet cert.

• Агент — этот раздел упоминается службой Puppet.

• Пользователь — в основном используется командой Puppet apply, а также многими менее распространенными командами.

Main — Это называется глобальным разделом, который используется всеми командами и службами в Puppet. Один определяет значения по умолчанию в главном разделе, которые могут быть переопределены любым разделом, присутствующим в файле puppet.conf.

Мастер — этот раздел передается мастером Puppet и командой Puppet cert.

Агент — этот раздел упоминается службой Puppet.

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

[main] 
certname = PuppetTestmaster1.example.com 

Ключевые компоненты файла конфигурации

Ниже приведены ключевые компоненты файла конфигурации.

Строки комментариев

В Puppet любая строка комментария начинается со знака ( # ). Это может быть связано с любым количеством места. Мы можем иметь частичный комментарий в той же строке.

# This is a comment. 
Testing = true #this is also a comment in same line 

Линии настроек

Строка настроек должна состоять из —

• Любое количество пробелов (необязательно)
• Наименование настроек
• Знак равенства =, который может быть окружен любым количеством пробелов
• Значение для настройки

Установка переменных

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

пути

В настройках файла конфигурации возьмите список каталогов. При определении этих каталогов следует иметь в виду, что они должны быть разделены символом системного пути, который является символом (:) в * nix платформах и точкой с запятой (;) в Windows.

# *nix version: 
environmentpath = $codedir/special_environments:$codedir/environments 
# Windows version: 
environmentpath = $codedir/environments;C:\ProgramData\PuppetLabs\code\environment 

В определении каталог файлов, который указан первым, сканируется, а затем перемещается в другой каталог в списке, если он не найден.

Файлы и каталоги

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

ssldir = $vardir/ssl {owner = service, mode = 0771} 

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

Кукольный — Окружающая среда Conf

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

Место нахождения

В Puppet для всех определенных сред среда file.conf находится на верхнем уровне домашней среды, рядом с директорами манифеста и модулей. Рассматривая пример, если ваша среда находится в каталогах по умолчанию (Vipin / testing / environment) , то файл конфигурации тестовой среды находится в Vipin / testing / environment / test / environment.conf .

пример

 # /etc/testingdir/code/environments/test/environment.conf  
 # Puppet Enterprise требует $ basemodulepath;  см. примечание ниже под modulepath ". 
 modulepath = site: dist: modules: $ basemodulepath  
 # Используйте наш пользовательский скрипт, чтобы получить git commit для текущего состояния кода: 
 config_version = get_environment_commit.sh 

Формат

Все файлы конфигурации в Puppet одинаково используют один и тот же INI-подобный формат. Файл environment.conf имеет тот же INI-подобный формат, что и другие, например, файл puppet.conf. Единственная разница между environment.conf и puppet.conf в том, что файл environment.conf не может содержать раздел [main]. Все настройки в файле environment.conf должны быть вне любого раздела конфигурации.

Относительный путь в ценностях

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

Интерполяция в ценностях

Файл настроек Environment.conf может использовать значения других настроек в качестве переменных. Существует несколько полезных переменных, которые можно вставить в файл environment.conf. Вот список нескольких важных переменных —

• $ basemodulepath — полезно для включения каталогов в настройки пути модуля. Пользователь Puppet Enterprise обычно должен включать это значение modulepath, поскольку ядро Puppet использует модуль в базовом модуле path .

• $ environment — Используется в качестве аргумента командной строки для вашего скрипта config_version. Вы можете интерполировать эту переменную только в настройке config_version.

• $ codedir — Полезно для поиска файлов.

$ basemodulepath — полезно для включения каталогов в настройки пути модуля. Пользователь Puppet Enterprise обычно должен включать это значение modulepath, поскольку ядро Puppet использует модуль в базовом модуле path .

$ environment — Используется в качестве аргумента командной строки для вашего скрипта config_version. Вы можете интерполировать эту переменную только в настройке config_version.

$ codedir — Полезно для поиска файлов.

Разрешенные настройки

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

• ModulePath
• манифест
• Config_version
• Environment_timeout

ModulePath

Это один из ключевых параметров в файле environment.conf. Все директора, определенные в modulepath, по умолчанию загружаются Puppet. Это путь, откуда Puppet загружает свои модули. Нужно явно настроить это. Если этот параметр не установлен, путь модуля по умолчанию для любой среды в Puppet будет —

 <СПРАВОЧНИК МОДУЛЕЙ ИЗ ОКРУЖАЮЩЕЙ СРЕДЫ>: $ basemodulepath 

манифест

Это используется для определения основного файла манифеста, который мастер Puppet будет использовать при загрузке и компиляции каталога из определенного манифеста, который будет использоваться для настройки среды. В этом мы можем определить один файл, список файлов или даже каталог, состоящий из нескольких файлов манифеста, который должен быть оценен и скомпилирован в определенной алфавитной последовательности.

Необходимо явно определить этот параметр в файле environment.conf. Если нет, то Puppet будет использовать каталог манифеста по умолчанию в качестве основного манифеста.

Config_version

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

Тайм-аут среды

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

Образец файла environment.conf

 [мастер] 
    manifest = $ confdir / environment / $ environment / manifts / site.pp 
    modulepath = $ confdir / environment / $ environment / modules

В приведенном выше коде $ confdir — это путь к каталогу, в котором находятся файлы конфигурации среды. $ environment — это имя среды, для которой выполняется конфигурация.

Файл конфигурации рабочей среды

 # Файл конфигурации среды  
 # Главный каталог или файл манифеста, где Puppet начинает оценивать код  
 # Это значение по умолчанию.  Работает только с файлом site.pp или любым другим  
 манифест = манифест /  
 # Каталоги, добавленные в путь к модулю, выглядят в порядке первого совпадения:  
 # modules - Каталог для внешних модулей, заполняемый r10k на основе Puppetfile  
 # $ basemodulepath - Начиная с: конфигурация puppet print basemodulepath  
 modulepath = site: modules: $ basemodulepath  
 # Установите тайм-аут кэша для этой среды.  
 # Это переопределяет то, что установлено прямо в puppet.conf для всего сервера Puppet  
 # environment_timeout = неограничено  
 # При кешировании вам нужно очищать кеш при каждом развертывании нового кода Puppet  
 # Это также можно сделать вручную: bin / puppet_flush_environment_cache.sh  
 # Чтобы отключить кэширование каталога:  
 environment_timeout = 0  
 # Здесь мы переходим к одному в контрольном репозитории Puppet environment (и git branch)  
 # чтобы получить заголовок и необходимую информацию о последнем коммите git
 config_version = 'bin / config_script.sh $ environment' 

Кукольный — Мастер

В Puppet архитектура клиент-сервер мастера Puppet рассматривается как контролирующий орган всей установки. Хозяин Puppet действует как сервер в настройке и контролирует все действия на всех узлах.

Для любого сервера, который должен выступать в качестве мастера Puppet, на нем должно быть запущено программное обеспечение сервера Puppet. Это серверное программное обеспечение является ключевым компонентом контроля всех действий на узлах. В этой настройке следует помнить один ключевой момент — иметь доступ суперпользователя ко всем машинам, которые планируется использовать в настройке. Ниже приведены шаги по настройке Puppet master.

Предпосылки

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

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

Создание Puppet Master Server

Мастер Puppet, который мы создаем, будет на компьютере CentOS 7 × 64 с именем Puppet в качестве имени хоста. Минимальная конфигурация системы для создания Puppet master — это два ядра процессора и 1 ГБ памяти. Конфигурация также может иметь больший размер в зависимости от количества узлов, которыми мы будем управлять с помощью этого мастера. В инфраструктуре больше, чем настроено с использованием 2 ГБ оперативной памяти.

Имя хоста	Роль	Частное полное доменное имя
Brcleprod001	Кукольный мастер	bnrcleprod001.brcl.com

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

Установка NTP

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

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

Список доступных часовых поясов

$ timedatectl list-timezones

Приведенная выше команда предоставит полный список доступных часовых поясов. Это обеспечит регионы доступностью часового пояса.

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

$ sudo timedatectl set-timezone India/Delhi 

Установите NTP на компьютере сервера Puppet, используя утилиту yum компьютера CentOS.

$ sudo yum -y install ntp 

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

$ sudo ntpdate pool.ntp.org 

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

$ sudo vi /etc/ntp.conf 

Добавьте сервер времени из доступных часовых поясов пула NTP. Вот как выглядит файл ntp.conf.

brcleprod001.brcl.pool.ntp.org 
brcleprod002.brcl.pool.ntp.org 
brcleprod003.brcl.pool.ntp.org
brcleprod004.brcl.pool.ntp.org 

Сохраните конфигурацию. Запустите сервер и включите демон.

$ sudo systemctl restart ntpd 
$ sudo systemctl enable ntpd 

Настройка программного обеспечения Puppet Server

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

Включите официальный репозиторий Puppet labs collection с помощью следующей команды.

$ sudo rpm -ivh https://yum.puppetlabs.com/puppetlabs-release-pc1-el7.noarch.rpm

Установите пакет puppetserver.

$ sudo yum -y install puppetserver 

Настройте распределение памяти на сервере Puppet

Как мы уже говорили, по умолчанию сервер Puppet настраивается на 2 ГБ ОЗУ. Можно настроить настройку в соответствии со свободной памятью, доступной на машине, и количеством узлов, которыми будет управлять сервер.

Отредактируйте конфигурацию сервера марионеток в режиме vi

$ sudo vi /etc/sysconfig/puppetserver  
Find the JAVA_ARGS and use the –Xms and –Xms options to set the memory allocation. 
We will allocate 3GB of space  
JAVA_ARGS="-Xms3g -Xmx3g" 

После этого сохраните и выйдите из режима редактирования.

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

$ sudo systemctl start puppetserver 

Далее мы выполним настройку так, чтобы марионеточный сервер запускался при загрузке главного сервера.

$ sudo systemctl enable puppetserver 

Puppet.conf Мастер Раздел

[master] 
autosign = $confdir/autosign.conf { mode = 664 } 
reports = foreman 
external_nodes = /etc/puppet/node.rb 
node_terminus = exec 
ca = true 
ssldir = /var/lib/puppet/ssl 
certname = sat6.example.com 
strict_variables = false 
manifest = 
/etc/puppet/environments/$environment/manifests/site.pp 
modulepath = /etc/puppet/environments/$environment/modules 
config_version = 

Puppet — установка агента

Puppet agent — это программное приложение, предоставленное лабораториями Puppet, которое работает на любом узле в кластере Puppet. Если кто-то хочет управлять каким-либо сервером с помощью мастера Puppet, на этом конкретном сервере должно быть установлено программное обеспечение агента Puppet. В общем случае агент Puppet будет установлен на всех машинах, за исключением главного компьютера Puppet в любой данной инфраструктуре. Программное обеспечение агента Puppet может работать на большинстве компьютеров с Linux, UNIX и Windows. В следующих примерах мы используем программное обеспечение Puppet для установки на компьютере CentOS.

Шаг 1. Включите официальный репозиторий Puppet labs collection с помощью следующей команды.

$ sudo rpm -ivh https://yum.puppetlabs.com/puppetlabs-release-pc1-el7.noarch.rpm

Шаг 2 — Установите пакет агента Puppet.

$ sudo yum -y install puppet-agent

Шаг 3. После установки агента Puppet включите его с помощью следующей команды.

$ sudo /opt/puppetlabs/bin/puppet resource service puppet ensure=running enable = true

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

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

Puppet — Настройка SSL-сертификата

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

Список текущих запросов сертификатов

На хозяине Puppet выполните следующую команду, чтобы увидеть все неподписанные запросы сертификатов.

$ sudo /opt/puppetlabs/bin/puppet cert list

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

"Brcleprod004.brcl.com" (SHA259) 
15:90:C2:FB:ED:69:A4:F7:B1:87:0B:BF:F7:ll:
B5:1C:33:F7:76:67:F3:F6:45:AE:07:4B:F 6:E3:ss:04:11:8d 

Он не содержит + (знак) в начале, который указывает, что сертификат все еще не подписан.

Подпишите запрос

Чтобы подписать новый запрос сертификата, который был сгенерирован при запуске агента Puppet на новом узле, будет использоваться команда знака Puppet cert с именем хоста сертификата, который был создан вновь сконфигурированным узлом, которому требуется должен быть подписан. Поскольку у нас есть сертификат Brcleprod004.brcl.com, мы будем использовать следующую команду.

$ sudo /opt/puppetlabs/bin/puppet cert sign Brcleprod004.brcl.com 

Ниже будет вывод .

Notice: Signed certificate request for Brcle004.brcl.com 
Notice: Removing file Puppet::SSL::CertificateRequest Brcle004.brcl.com at 
'/etc/puppetlabs/puppet/ssl/ca/requests/Brcle004.brcl.com.pem' 

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

$ sudo /opt/puppetlabs/bin/puppet cert sign --all 

Отмена хоста из настроек Puppet

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

$ sudo /opt/puppetlabs/bin/puppet cert clean hostname 

Просмотр всех подписанных запросов

Следующая команда создаст список подписанных сертификатов со знаком + (знак), который указывает, что запрос утвержден.

$ sudo /opt/puppetlabs/bin/puppet cert list --all

Следующим будет его вывод .

+ "puppet" (SHA256) 5A:71:E6:06:D8:0F:44:4D:70:F0:
BE:51:72:15:97:68:D9:67:16:41:B0:38:9A:F2:B2:6C:B 
B:33:7E:0F:D4:53 (alt names: "DNS:puppet", "DNS:Brcle004.nyc3.example.com")  

+ "Brcle004.brcl.com" (SHA259) F5:DC:68:24:63:E6:F1:9E:C5:FE:F5:
1A:90:93:DF:19:F2:28:8B:D7:BD:D2:6A:83:07:BA:F E:24:11:24:54:6A 

+ " Brcle004.brcl.com" (SHA259) CB:CB:CA:48:E0:DF:06:6A:7D:75:E6:CB:22:BE:35:5A:9A:B3 

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

Puppet — Установка и настройка r10K

В Puppet у нас есть инструмент управления кодом, известный как r10k, который помогает в управлении конфигурациями среды, связанной с различными типами сред, которые мы можем настроить в Puppet, такими как разработка, тестирование и производство. Это помогает хранить конфигурацию, связанную со средой, в хранилище исходного кода. Используя ветви репозитория управления исходным кодом, r10k создает среды на главной машине Puppet для установки и обновления среды, используя модули, присутствующие в репо.

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

$ urlgrabber -o /etc/yum.repos.d/timhughes-r10k-epel-6.repo
https://copr.fedoraproject.org/coprs/timhughes/yum -y install rubygem-r10k 

Настройте среду в /etc/puppet/puppet.conf

[main] 
environmentpath = $confdir/environments 

Создайте файл конфигурации для конфигурации r10k

cat <<EOF >/etc/r10k.yaml 
# The location to use for storing cached Git repos 
:cachedir: '/var/cache/r10k' 
# A list of git repositories to create 
:sources: 
# This will clone the git repository and instantiate an environment per 
# branch in /etc/puppet/environments 
:opstree: 
#remote: 'https://github.com/fullstack-puppet/fullstackpuppet-environment.git' 
remote: '/var/lib/git/fullstackpuppet-environment.git' 
basedir: '/etc/puppet/environments' 
EOF

Установка Puppet Manifest и модуля

r10k deploy environment -pv 

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

cat << EOF > /etc/cron.d/r10k.conf 
SHELL = /bin/bash 
PATH = /sbin:/bin:/usr/sbin:/usr/bin 
H/15 * * * * root r10k deploy environment -p 
EOF

Тестирование Установка

Чтобы проверить, все ли работает как принято, нужно скомпилировать манифест Puppet для модуля Puppet. Выполните следующую команду и получите результат YAML в качестве результата.

curl --cert /etc/puppet/ssl/certs/puppet.corp.guest.pem \ 
--key /etc/puppet/ssl/private_keys/puppet.corp.guest.pem \ 
--cacert /etc/puppet/ssl/ca/ca_crt.pem \ 
-H 'Accept: yaml' \ 
https://puppet.corp.guest:8140/production/catalog/puppet.corp.guest 

Puppet — Проверка настроек кукол

В Puppet, установка может быть проверена локально. Следовательно, как только мы настроили мастер и узел Puppet, пришло время проверить настройки локально. Нам нужно, чтобы Vagrant и Vagrant box были установлены локально, что помогает в локальном тестировании установки.

Настройка виртуальной машины

Поскольку мы тестируем настройки локально, нам фактически не требуется работающий мастер Puppet. Это означает, что без фактического запуска мастера Puppet на сервере мы можем просто использовать Puppet, чтобы применить команду для проверки правильности настройки Puppet. Команда Puppet apply применяет изменения из локального / etc / puppet в зависимости от имени хоста виртуальной машины в файле конфигурации.

Первый шаг, который нам нужно выполнить, чтобы протестировать установку, — это создать следующий Vagrantfile, запустить машину и смонтировать папку / etc / puppet на место. Все необходимые файлы будут помещены в систему контроля версий со следующей структурой.

Структура каталогов

- manifests 
   \- site.pp 
- modules 
   \- your modules  
- test 
   \- update-puppet.sh 
   \- Vagrantfile 
- puppet.conf 

Бродячий файл

# -*- mode: ruby -*- 
# vi: set ft = ruby : 
Vagrant.configure("2") do |config| 
   config.vm.box = "precise32" 
   config.vm.box_url = "http://files.vagrantup.com/precise64.box" 
   config.vm.provider :virtualbox do |vb| 
      vb.customize ["modifyvm", :id, "--memory", 1028, "--cpus", 2] 
   end 
  
   # Mount our repo onto /etc/puppet 
   config.vm.synced_folder "../", "/etc/puppet"  
   
   # Run our Puppet shell script   
   config.vm.provision "shell" do |s| 
      s.path = "update-puppet.sh" 
   end  
 
   config.vm.hostname = "localdev.example.com" 
end 

В приведенном выше коде мы использовали поставщика оболочки, в котором мы пытаемся запустить сценарий оболочки с именем update-puppet.sh . Сценарий находится в том же каталоге, где находится файл Vagrant, а содержимое сценария указано ниже.

!/bin/bash 
echo "Puppet version is $(puppet --version)" 
if [ $( puppet --version) != "3.4.1" ]; then  
   echo "Updating puppet" 
   apt-get install --yes lsb-release 
   DISTRIB_CODENAME = $(lsb_release --codename --short) 
   DEB = "puppetlabs-release-${DISTRIB_CODENAME}.deb" 
   DEB_PROVIDES="/etc/apt/sources.list.d/puppetlabs.list"  
   
   if [ ! -e $DEB_PROVIDES ] 
   then 
      wget -q http://apt.puppetlabs.com/$DEB 
      sudo dpkg -i $DEB 
   fi  
sudo apt-get update 
   sudo apt-get install -o Dpkg::Options:: = "--force-confold" 
   --force-yes -y puppet 
else 
   echo "Puppet is up to date!" 
fi 

Для дальнейшей обработки пользователю необходимо создать файл манифеста в каталоге Manifests с именем site.pp, который установит некоторое программное обеспечение на ВМ.

node 'brclelocal03.brcl.com' { 
   package { ['vim','git'] : 
      ensure => latest 
   } 
} 
echo "Running puppet" 
sudo puppet apply /etc/puppet/manifests/site.pp 

Как только пользователь подготовит вышеуказанный сценарий с необходимой конфигурацией файла Vagrant, он сможет перейти в тестовый каталог и выполнить команду vagrant up . Это загрузит новую виртуальную машину, позже установит Puppet, а затем запустит ее, используя скрипт Shell.

Ниже будет вывод.

Notice: Compiled catalog for localdev.example.com in environment production in 0.09 seconds 
Notice: /Stage[main]/Main/Node[brclelocal03.brcl.com]/Package[git]/ensure: created 
Notice: /Stage[main]/Main/Node[brcllocal03.brcl.com]/Package[vim]/ensure: ensure changed 'purged' to 'latest'

Проверка конфигурации нескольких машин

Если нам нужно проверить конфигурацию нескольких машин локально, это можно сделать, внеся изменения в файл конфигурации Vagrant.

Новый настроенный бродячий файл

config.vm.define "brclelocal003" do |brclelocal003| 
   brclelocal03.vm.hostname = "brclelocal003.brcl.com" 
end  

config.vm.define "production" do |production| 
   production.vm.hostname = "brcleprod004.brcl.com" 
end

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

node 'brcleprod004.brcl.com' inherits 'brcleloacl003.brcl.com' { 
   package { ['SSL'] : 
      ensure => latest 
   } 
} 

После внесения изменений в конфигурационный файл манифеста нам просто нужно перейти в тестовый каталог и запустить базовую команду vagrant up, которая вызовет как машины brclelocal003.brcl.com, так и машину brcleprod004.brcl.com . В нашем случае мы пытаемся запустить производственную машину, что можно сделать, выполнив команду vagrant up production . Будет создан новый компьютер с именем производства, как определено в файле Vagrant, и на нем будет установлен пакет SSL.

Кукольный стиль кодирования

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

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

Основные единицы

Puppet использует несколько основных стилей кодирования, которые просты для понимания и управления. Ниже приведен список немногих.

Ресурсы

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

В Puppet все ресурсы объединяются либо с помощью «define», либо «классы» . Эти функции агрегирования помогают в организации модуля. Ниже приведен пример ресурса, который состоит из нескольких типов, заголовка и списка атрибутов, с которыми Puppet может поддерживать несколько атрибутов. Каждый ресурс в Puppet имеет свое собственное значение по умолчанию, которое может быть переопределено при необходимости.

Образец кукольного ресурса для файла

В следующей команде мы пытаемся указать разрешение для определенного файла.

file {  
   '/etc/passwd': 
   owner => superuser, 
   group => superuser, 
   mode => 644, 
}

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

Указание локального имени в дополнение к заголовку

file { 'sshdconfig': 
   name => $operaSystem ? { 
      solaris => '/usr/local/etc/ssh/sshd_config', 
      default => '/etc/ssh/sshd_config', 
   }, 
   owner => superuser, 
   group => superuser, 
   mode => 644, 
}

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

Другим примером может быть использование службы, которая зависит от файла.

service { 'sshd': 
   subscribe => File[sshdconfig], 
} 

С этой зависимостью служба sshd всегда перезапускается после изменения файла sshdconfig . Следует помнить, что File [sshdconfig] является объявлением File, как в нижнем регистре, но если мы изменим его на FILE [sshdconfig], то это будет ссылка.

При объявлении ресурса следует помнить один фундаментальный момент: он может быть объявлен только один раз для каждого файла конфигурации. Повторное объявление одного и того же ресурса более одного раза вызовет ошибку. Благодаря этой фундаментальной концепции Puppet гарантирует, что конфигурация хорошо смоделирована.

У нас даже есть возможность управлять зависимостью от ресурсов, которая помогает управлять несколькими отношениями.

service { 'sshd': 
   require => File['sshdconfig', 'sshconfig', 'authorized_keys']
}   

Metaparameters

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

Ресурс по умолчанию

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

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

Exec { path => '/usr/bin:/bin:/usr/sbin:/sbin' } 
exec { 'echo Testing mataparamaters.': } 

В приведенной выше команде первый оператор Exec установит значение по умолчанию для ресурса exec. Ресурсу Exec требуется полный путь или путь, который выглядит как исполняемый файл. При этом можно определить один путь по умолчанию для всей конфигурации. По умолчанию работает с любым типом ресурса в Puppet.

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

Коллекции Ресурсов

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

Классы и определения

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

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

Разница между классом и определением

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

Классы

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

class unix { 
   file { 
      '/etc/passwd': 
      owner => 'superuser', 
      group => 'superuser', 
      mode => 644; 
      '/etc/shadow': 
      owner => 'vipin', 
      group => 'vipin', 
      mode => 440; 
   } 
}

В следующем примере мы использовали некоторую короткую руку, которая похожа на вышеприведенную.

class unix { 
   file { 
      '/etc/passwd': 
      owner => 'superuser', 
      group => 'superuser', 
      mode => 644; 
   }  
   
   file {'/etc/shadow': 
      owner => 'vipin', 
      group => 'vipin', 
      mode => 440; 
   } 
} 

Наследование в кукольных классах

В Puppet концепция ООП наследования поддерживается по умолчанию, в которой классы могут расширять функциональность предыдущего, не копируя и не вставляя бит полного кода снова во вновь созданный класс. Наследование позволяет подклассу переопределять настройки ресурса, определенные в родительском классе. При использовании наследования следует помнить о том, что класс может наследовать функции только от одного родительского класса, но не от одного.

class superclass inherits testsubclass { 
   File['/etc/passwd'] { group => wheel } 
   File['/etc/shadow'] { group => wheel } 
}

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

class superclass inherits testsubcalss { 
   File['/etc/passwd'] { group => undef } 
} 

Альтернативный способ использования наследования

class tomcat { 
   service { 'tomcat': require => Package['httpd'] } 
} 
class open-ssl inherits tomcat { 
   Service[tomcat] { require +> File['tomcat.pem'] } 
}

Вложенный класс в кукольный

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

class testclass { 
   class nested { 
      file {  
         '/etc/passwd': 
         owner => 'superuser', 
         group => 'superuser', 
         mode => 644; 
      } 
   } 
} 
class anotherclass { 
   include myclass::nested 
} 

Параметризованные классы

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

Чтобы передать параметр в классе, можно использовать следующую конструкцию —

class tomcat($version) { 
   ... class contents ... 
} 

В Puppet следует помнить один ключевой момент: классы с параметрами не добавляются с помощью функции include, скорее результирующий класс можно добавить в качестве определения.

node webserver { 
   class { tomcat: version => "1.2.12" } 
}

Значения по умолчанию как параметры в классе

class tomcat($version = "1.2.12",$home = "/var/www") { 
   ... class contents ... 
} 

Run Stages

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

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

Чтобы использовать это, нужно объявить дополнительные этапы помимо уже существующих этапов, и тогда Puppet может быть настроен для управления каждым этапом в указанном порядке, используя тот же синтаксис отношения ресурсов, прежде чем требовать «->» и «+>» . Отношения затем гарантируют порядок классов, связанных с каждым этапом.

Объявление дополнительных этапов с кукольным декларативным синтаксисом

stage { "first": before => Stage[main] } 
stage { "last": require => Stage[main] } 

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

class { 
   "apt-keys": stage => first; 
   "sendmail": stage => main; 
   "apache": stage => last; 
}

Все ресурсы, связанные с классом apt-key, будут запущены первыми. Все ресурсы в Sendmail будут основным классом, а ресурсы, связанные с Apache, будут последним этапом.

Определения

В Puppet сбор ресурсов в любом файле манифеста осуществляется с помощью классов или определений. Определения очень похожи на класс в Puppet, однако они вводятся с ключевым словом define (не class) и поддерживают аргумент, а не наследование. Они могут работать в одной системе несколько раз с разными параметрами.

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

define perforce_repo($path) { 
   exec {  
      "/usr/bin/svnadmin create $path/$title": 
      unless => "/bin/test -d $path", 
   } 
} 
svn_repo { puppet_repo: path => '/var/svn_puppet' } 
svn_repo { other_repo: path => '/var/svn_other' }

Ключевой момент, который следует здесь отметить, заключается в том, как можно использовать переменную с определением. Мы используем ( $ ) переменную знака доллара. Выше мы использовали $ title. Определения могут иметь как $ title, так и $ name, которыми могут быть представлены имя и заголовок. По умолчанию $ title и $ name установлены на одно и то же значение, но можно установить атрибут title и передать другое имя в качестве параметра. $ title и $ name работают только в определении, а не в классе или другом ресурсе.

Модули

Модуль может быть определен как совокупность всех конфигураций, которые будут использоваться мастером Puppet для применения изменений конфигурации к любому конкретному узлу Puppet (агенту). Они также известны как переносимые коллекции различных видов конфигураций, которые необходимы для выполнения конкретной задачи. Например, модуль может содержать все ресурсы, необходимые для настройки Postfix и Apache.

Вершины

Узлы — это очень простой оставшийся шаг, который позволяет нам сопоставить то, что мы определили («так выглядит веб-сервер») с тем, какие машины выбраны для выполнения этих инструкций.

Определение узла в точности похоже на классы, включая вспомогательное наследование, однако они являются особыми, так что когда узел (управляемый компьютер, на котором работает клиент puppet) подключается к главному демону Puppet, его имя будет отображаться в определенном списке узлов. Определенная информация будет оценена для узла, а затем узел отправит эту конфигурацию.

Имя узла может быть коротким именем хоста или полным доменным именем (FQDN).

node 'www.vipin.com' { 
   include common 
   include apache, squid 
}

Приведенное выше определение создает узел с именем www.vipin.com и включает в себя общий, Apache и Squid.

Мы можем отправить одну и ту же конфигурацию разным узлам, разделяя их запятыми.

node 'www.testing.com', 'www.testing2.com', 'www3.testing.com' { 
   include testing 
   include tomcat, squid 
}

Регулярное выражение для совпадающих узлов

node /^www\d+$/ { 
   include testing 
}

Наследование узлов

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

node 'www.testing2.com' inherits 'www.testing.com' { 
   include loadbalancer 
}

В приведенном выше коде www.testing2.com наследует все функциональные возможности от www.testing.com в дополнение к дополнительному классу loadbalancer.

Расширенные поддерживаемые функции

Цитирование — В большинстве случаев нам не нужно цитировать строку в Puppet. Любая буквенно-цифровая строка, начинающаяся с буквы, должна быть оставлена ​​без кавычек. Однако всегда лучше заключать в кавычки строку для любых неотрицательных значений.

Переменная интерполяция с кавычками

До сих пор мы упоминали переменную с точки зрения определения. Если нужно использовать эти переменные со строкой, используйте двойные кавычки, а не одинарные. Строка одинарных кавычек не будет выполнять никакой переменной интерполяции, строка двойных кавычек будет делать. Переменная может заключаться в квадратные скобки в {}, что упрощает их совместное использование и облегчает понимание.

$value = "${one}${two}" 

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

капитализация

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

• Ссылки — это способ ссылки на уже созданный ресурс. Он в основном используется для целей зависимости, нужно использовать заглавную букву имени ресурса. Пример, require => file [sshdconfig]

• Наследование — при переопределении параметра родительского класса из подкласса используйте версию имени ресурса в верхнем регистре. Использование строчной версии приведет к ошибке.

• Установка значения атрибута по умолчанию — Использование заглавного ресурса без заголовка работает для установки ресурса по умолчанию.

Ссылки — это способ ссылки на уже созданный ресурс. Он в основном используется для целей зависимости, нужно использовать заглавную букву имени ресурса. Пример, require => file [sshdconfig]

Наследование — при переопределении параметра родительского класса из подкласса используйте версию имени ресурса в верхнем регистре. Использование строчной версии приведет к ошибке.

Установка значения атрибута по умолчанию — Использование заглавного ресурса без заголовка работает для установки ресурса по умолчанию.

Массивы

Puppet позволяет использовать массивы в нескольких областях [Один, два, три].

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

host { 'one.vipin.com': 
   alias => [ 'satu', 'dua', 'tiga' ], 
   ip => '192.168.100.1', 
   ensure => present, 
}

Приведенный выше код добавит хост ‘one.brcletest.com’ в список хостов с тремя псевдонимами ‘satu’ ‘dua’ ‘tiga’ . Если кто-то хочет добавить несколько ресурсов к одному ресурсу, это можно сделать, как показано в следующем примере.

resource { 'baz': 
   require => [ Package['rpm'], File['testfile'] ], 
}

переменные

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

$content = 'some content\n' 
file { '/tmp/testing': content => $content } 

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

$user = root 
file {  
   '/etc/passwd': 
   owner => $user, 
} 

$user = bin 
   file {  
      '/bin': 
      owner => $user, 
      recurse => true, 
   }

Переменная сфера

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

$test = 'top' 
class Testclass { 
   exec { "/bin/echo $test": logoutput => true } 
} 

class Secondtestclass { 
   $test = 'other' 
   include myclass 
} 

include Secondtestclass 

Квалифицированная переменная

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

class testclass { 
   $test = 'content' 
} 

class secondtestclass { 
   $other = $myclass::test 
} 

В приведенном выше коде значение переменной $ other оценивает содержимое.

Conditionals

Условия — это ситуации, когда пользователь желает выполнить набор операторов или кода, когда определенное условие или требуемое условие выполнены. Puppet поддерживает два типа условий.

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

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

Селекторы

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

$owner = $Sysoperenv ? { 
   sunos => 'adm', 
   redhat => 'bin', 
   default => undef, 
}

В более поздних версиях Puppet 0.25.0 селекторы могут использоваться как регулярные выражения.

$owner = $Sysoperenv ? { 
   /(Linux|Ubuntu)/ => 'bin', 
   default => undef, 
}

В приведенном выше примере значение селектора $ Sysoperenv соответствует либо Linux, либо Ubuntu, тогда выбранным будет результат bin, в противном случае для пользователя будет задано значение undefined.

Состояние заявления

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

Оператор case, который соответствует данному входному условию, выполняется. Это условие оператора case не имеет никакого возвращаемого значения. В Puppet очень распространенным случаем использования оператора условия является запуск набора битов кода, основанных на базовой операционной системе.

case $ Sysoperenv { 
   sunos: { include solaris }  
   redhat: { include redhat }  
   default: { include generic}  
}

Оператор Case также может указывать несколько условий, разделяя их запятой.

case $Sysoperenv { 
   development,testing: { include development } testing,production: { include production }
   default: { include generic }  
} 

If-Else Заявление

Puppet поддерживает концепцию условной операции. Для этого оператор If / else предоставляет параметры ветвления, основанные на возвращаемом значении условия. Как показано в следующем примере —

if $Filename { 
   file { '/some/file': ensure => present } 
} else { 
   file { '/some/other/file': ensure => present } 
} 

Последняя версия Puppet поддерживает переменное выражение, в котором оператор if также может переходить в зависимости от значения выражения.

if $machine == 'production' { 
   include ssl 
} else { 
   include nginx 
}

Чтобы добиться большего разнообразия в коде и выполнять сложные условные операции, Puppet поддерживает вложенный оператор if / else, как показано в следующем коде.

if $ machine == 'production' { 
   include ssl 
} elsif $ machine == 'testing' { 
   include nginx
} else { 
   include openssl 
} 

Виртуальный ресурс

Виртуальные ресурсы — это те, которые не отправляются клиенту, если не реализованы.

Ниже приводится синтаксис использования виртуального ресурса в Puppet.

@user { vipin: ensure => present } 

В приведенном выше примере пользователь vipin определен виртуально, чтобы реализовать определение, которое можно использовать в коллекции.

User <| title == vipin |>

Комментарии

Комментарии используются в любом бите кода для создания дополнительного узла о наборе строк кода и его функциональности. В Puppet в настоящее время поддерживаются два типа комментариев.

• Комментарии в стиле оболочки Unix. Они могут быть на своей или следующей строке.
• Многострочные комментарии в стиле c.

Ниже приведен пример комментария в стиле оболочки.

# this is a comment

Ниже приведен пример многострочного комментария.

/* 
This is a comment 
*/ 

Приоритет оператора

Приоритет оператора Puppet соответствует стандартному приоритету в большинстве систем, от самого высокого до самого низкого.

Ниже приведен список выражений

• ! = нет
• / = раз и разделить
• — + = минус, плюс
• << >> = сдвиг влево и вправо
• ==! = = не равно, равно
• > = <=> <= больше равно, меньше или равно, больше чем, меньше чем

Выражение сравнения

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

if $environment == 'development' { 
   include openssl 
} else { 
   include ssl 
} 

Не равный пример

if $environment != 'development' { 
   $otherenvironment = 'testing' 
} else { 
   $otherenvironment = 'production' 
} 

Арифметическое выражение

$one = 1 
$one_thirty = 1.30 
$two = 2.034e-2 $result = ((( $two + 2) / $one_thirty) + 4 * 5.45) - 
   (6 << ($two + 4)) + (0×800 + -9)

Логическое выражение

Логические выражения возможны с использованием или, и, & not.

$one = 1 
$two = 2 
$var = ( $one < $two ) and ( $one + 1 == $two ) 

Регулярное выражение

Puppet поддерживает сопоставление регулярных выражений, используя = ~ (совпадение) и! ~ (Не совпадение).

if $website =~ /^www(\d+)\./ { 
   notice('Welcome web server #$1') 
}

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

exec { "Test": 
   command => "/bin/echo now we don’t have openssl installed on machine > /tmp/test.txt", 
   unless => "/bin/which php" 
}

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

exec { "Test": 
   command => "/bin/echo now we don’t have openssl installed on machine > /tmp/test.txt", 
   unless => "/bin/which php" 
}

Работа с шаблонами

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

file { "/etc/tomcat/sites-available/default.conf": 
   ensure => "present", 
   content => template("tomcat/vhost.erb")  
}

Puppet делает несколько предположений при работе с локальными файлами, чтобы обеспечить организацию и модульность. Puppet ищет шаблон vhost.erb внутри папки apache / templates, внутри каталога модулей.

Определение и запуск сервисов

В Puppet у него есть ресурс под названием service, который способен управлять жизненным циклом всех сервисов, работающих на любой конкретной машине или среде. Сервисные ресурсы используются, чтобы убедиться, что сервисы инициализированы и включены. Они также используются для перезапуска службы.

Например, в предыдущем шаблоне tomcat, который у нас есть, где мы устанавливаем виртуальный хост apache. Если кто-то хочет убедиться, что apache перезапускается после смены виртуального хоста, нам нужно создать ресурс службы для службы apache, используя следующую команду.

service { 'tomcat': 
   ensure => running, 
   enable => true 
}

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

file { "/etc/tomcat/sites-available/default.conf": 
   ensure => "present", 
   content => template("vhost.erb"), 
   notify => Service['tomcat']  
}

Кукольный — Манифест

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

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

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

Рабочий процесс файла манифеста

Кукольный манифест состоит из следующих компонентов —

• Файлы (это обычные файлы, в которых Puppet не имеет ничего общего с ними, просто чтобы взять их и поместить в нужное место)

• Ресурсы

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

• Узлы (все определения, относящиеся к клиентскому узлу, определены здесь)

• Классы

Файлы (это обычные файлы, в которых Puppet не имеет ничего общего с ними, просто чтобы взять их и поместить в нужное место)

Ресурсы

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

Узлы (все определения, относящиеся к клиентскому узлу, определены здесь)

Классы

Указывает на заметку

• В Puppet все файлы манифеста используют Ruby в качестве языка кодирования и сохраняются с расширением .pp .

• Оператор «import» во многих манифестах используется для загрузки файлов при запуске Puppet.

• Для того чтобы импортировать все файлы, содержащиеся в каталоге, вы можете использовать оператор импорта другим способом, например, import «clients / *». Это позволит импортировать все файлы .pp внутри этого каталога.

В Puppet все файлы манифеста используют Ruby в качестве языка кодирования и сохраняются с расширением .pp .

Оператор «import» во многих манифестах используется для загрузки файлов при запуске Puppet.

Для того чтобы импортировать все файлы, содержащиеся в каталоге, вы можете использовать оператор импорта другим способом, например, import «clients / *». Это позволит импортировать все файлы .pp внутри этого каталога.

Письменные манифесты

Работа с переменными

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

Пример строковой переменной

$package = "vim"  

package {  $package: 
   ensure => "installed" 
}

Использование циклов

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

Чаще всего массив используется для повторения теста с разными значениями.

$packages = ['vim', 'git', 'curl']  

package { $packages: 
   ensure => "installed" 
}

Использование условных выражений

Puppet поддерживает большую часть условной структуры, которую можно найти в традиционных языках программирования. Условие может использоваться для динамического определения, выполнять ли конкретную задачу или набор кода должен выполняться. Например if / else и case. Кроме того, такие условия, как execute, также поддерживают атрибуты, которые работают как условие, но принимают только вывод команды в качестве условия.

if $OperatingSystem != 'Linux' { 
   warning('This manifest is not supported on this other OS apart from linux.') 
} else { 
   notify { 'the OS is Linux. We are good to go!': }
} 

Кукольный — Модуль

В Puppet модуль может быть определен как набор ресурсов, классов, файлов, определений и шаблонов. Puppet поддерживает простое перераспределение модулей, что очень полезно при модульности кода, поскольку можно написать указанный универсальный модуль и использовать его несколько раз с минимальными изменениями кода. Например, это включит конфигурацию сайта по умолчанию в / etc / puppet, а модули, поставляемые собственно Puppet, находятся в / etc / share / puppet.

Конфигурация модуля

В любом модуле Puppet у нас есть два раздела, которые помогают определить структуру кода и управлять деноминациями.

• Путь поиска модулей настраивается с использованием разделенного двоеточиями списка каталогов в puppetmasterd или masterd , последнем разделе главного файла конфигурации Puppet с параметром modulepath .

Путь поиска модулей настраивается с использованием разделенного двоеточиями списка каталогов в puppetmasterd или masterd , последнем разделе главного файла конфигурации Puppet с параметром modulepath .

[puppetmasterd] 
... 
modulepath = /var/lib/puppet/modules:/data/puppet/modules 

Путь поиска можно добавить во время выполнения, установив переменную среды PUPPETLAB, которая также должна быть разделенным двоеточиями списком переменных.

• Настройки контроля доступа для модулей файлового сервера в fileserver.conf, конфигурация пути для этого модуля всегда игнорируется, и при указании пути будет выдано предупреждение.

Путь поиска можно добавить во время выполнения, установив переменную среды PUPPETLAB, которая также должна быть разделенным двоеточиями списком переменных.

Настройки контроля доступа для модулей файлового сервера в fileserver.conf, конфигурация пути для этого модуля всегда игнорируется, и при указании пути будет выдано предупреждение.

Модули Источник

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

Разумный путь по умолчанию может быть настроен как —

/etc/puppet/modules:/usr/share/puppet:/var/lib/modules. 

В качестве альтернативы каталог / etc / puppet может быть установлен как специальный анонимный модуль, который всегда ищется первым.

Наименование модуля

Puppet следует тем же стандартам именования конкретного модуля, где имя модуля должно быть обычными словами, соответствующими [- \\ w +] (буква, слово, число, подчеркивание и тире) и не содержащими разделитель пространства имен:: или /. Хотя это может быть разрешено в отношении иерархий модулей, для новых модулей оно не может быть вложенным.

Модуль Внутренняя Организация

Когда пользователь создает новый модуль в Puppet, он следует той же структуре и содержит манифест, распределенный файл, плагины и шаблоны, расположенные в определенной структуре каталогов, как показано в следующем коде.

MODULE_PATH/ 
   downcased_module_name/ 
      files/ 
      manifests/ 
         init.pp 
      lib/ 
         puppet/ 
            parser/ 
               functions 
            provider/ 
            type/ 
         facter/ 
      templates/ 
      README 

Всякий раз, когда модуль создается, он содержит файл манифеста init.pp в указанном месте исправления в каталоге манифестов. Этот файл манифеста является файлом по умолчанию, который выполняется первым в любом конкретном модуле и содержит коллекцию всех классов, связанных с этим конкретным модулем. Дополнительный файл .pp можно добавить прямо в папку манифестов. Если мы добавляем дополнительные файлы .pp, они должны быть названы в честь класса.

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

пример

Рассмотрим модуль autofs, который устанавливает фиксированную карту auto.homes и генерирует auto.master из шаблонов.

class autofs { 
   package { autofs: ensure => latest } 
   service { autofs: ensure => running } 
   
   file { "/etc/auto.homes": 
      source => "puppet://$servername/modules/autofs/auto.homes" 
   } 
   file { "/etc/auto.master": 
      content => template("autofs/auto.master.erb") 
   } 
}

Файловая система будет иметь следующие файлы.

MODULE_PATH/ 
autofs/ 
manifests/ 
init.pp 
files/ 
auto.homes 
templates/ 
auto.master.erb 

Модуль Поиск

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

Для ссылок на файл на файловом сервере используется аналогичная ссылка, так что ссылка на puppet: //$servername/modules/autofs/auto.homes преобразуется в файл autofs / files / auto.homes в пути модуля.

Чтобы сделать модуль пригодным для использования как с клиентом командной строки, так и с мастером марионеток, можно использовать URL-адрес пути from puppet: ///. т.е. URL без явного имени сервера. Такие URL немного различаются в Puppet и puppetd . Puppet ищет бессерверный URL в локальной файловой системе.

Поиск в файлах шаблонов осуществляется аналогично манифесту и файлам: упоминание шаблона («autofs / auto.master.erb») заставит puppetmaster сначала найти файл в $ templatedir / autofs / auto.master.erb, а затем autofs / templates / auto.master.erb в пути к модулю. С Puppet-версиями всего под Puppet он доступен для использования. Это называется автоматической загрузкой модуля. Puppet попытается автоматически загрузить классы и определения из модуля.

Кукольный — Файловый сервер

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

class { 'java':  
   package               => 'jdk-8u25-linux-x64',  
   java_alternative      => 'jdk1.8.0_25',  
   java_alternative_path => '/usr/java/jdk1.8.0_25/jre/bin/java'  
}

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

“puppet://server/modules/module_name/sudoers”

Формат файла

В структуре каталогов Puppet по умолчанию конфигурация файлового сервера находится в каталоге /etc/puppet/fileserver.config. Если пользователь желает изменить этот путь к файлу конфигурации по умолчанию, это можно сделать с помощью нового флага конфигурации для puppetmasterd . Файл конфигурации напоминает INI-файлы, но не точно такой же.

[module] 
path /path/to/files 
allow *.domain.com 
deny *.wireless.domain.com 

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

Путь может содержать любой или все% d,% h и% H, которые динамически заменяются его доменным именем, именем хоста и полным именем хоста. Все они взяты из SSL-сертификата клиента (поэтому будьте осторожны, если есть несоответствие имени хоста и имени сертификата). Это полезно при создании модулей, в которых файлы каждого клиента хранятся совершенно отдельно. Пример для приватных ключей хоста.

[private] 
path /data/private/%h 
allow * 

В приведенном выше фрагменте кода код пытается найти файл /private/file.txt с клиента client1.vipin.com . Он будет искать его в /data/private/client1/file.txt, а тот же запрос для client2.vipin.com попытается получить файл /data/private/client2/file.txt на файловом сервере.

Безопасность

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

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

При определении структуры файла следует отметить один ключевой момент: все операторы deny анализируются перед оператором allow. Следовательно, если какой-либо оператор deny совпадает с хостом, то этому хосту будет отказано, и если в следующих файлах не будет записан оператор allow, то хост будет отклонен. Эта функция помогает установить приоритет любого конкретного сайта.

Имя хоста

В любой конфигурации файлового сервера имя хоста файла можно указать двумя способами: либо с использованием полного имени хоста, либо путем указания полного имени домена с использованием подстановочного знака *, как показано в следующем примере.

[export] 
path /usr 
allow brcleprod001.brcl.com 
allow *.brcl.com 
deny brcleprod002.brcl.com

Айпи адрес

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

[export] 
path /usr 
allow 127.0.0.1 
allow 172.223.30.* 
allow 172.223.30.0/24 

Глобальный Разрешить

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

[export] 
path /export 
allow * 

Кукольный — Facter & Facts

Puppet поддерживает хранение нескольких значений в качестве переменной среды. Эта функция поддерживается в Puppet с помощью Facter . В Puppet facter — это автономный инструмент, который содержит переменную уровня среды. In можно рассматривать как переменную env в Bash или Linux. Иногда может происходить дублирование информации, хранящейся в фактах, и переменной среды машины. В Puppet пара ключ-значение называется «факт». Каждый ресурс имеет свои собственные факты, и в Puppet у пользователя есть возможности для создания своих собственных пользовательских фактов.

# facter 

Команда Facter может использоваться для вывода списка всех переменных среды и связанных с ними значений. Эта коллекция фактов поставляется с готовой информацией и упоминается как основные факты. Можно добавить пользовательские факты в коллекцию.

Если кто-то хочет просмотреть только одну переменную. Это можно сделать с помощью следующей команды.

# facter {Variable Name}  

Example 
[root@puppetmaster ~]# facter virtual 
virtualbox 

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

Пример для тестирования

[root@puppetmaster modules]# tree brcle_account 
brcle_account 
└── manifests  └── init.pp [root@puppetmaster modules]# cat brcle_account/manifests/init.pp  
class brcle_account {  
   user { 'G01063908': 
      ensure => 'present', 
      uid => '121', 
      shell => '/bin/bash', 
      home => '/home/G01063908', 
   }  
   
   file {'/tmp/userfile.txt': 
      ensure => file, 
      content => "the value for the 'OperatingSystem' fact is: $OperatingSystem \n", 
   } 
} 

Тестирование Это

[root@puppetmaster modules]# puppet agent --test 
Notice: /Stage[main]/Activemq::Service/Service[activemq]/ensure: 
ensure changed 'stopped' to 'running' 
Info: /Stage[main]/Activemq::Service/Service[activemq]: 
Unscheduling refresh on Service[activemq] 

Notice: Finished catalog run in 4.09 seconds  
[root@puppetmaster modules]# cat /tmp/testfile.txt  
the value for the 'OperatingSystem' fact is: Linux   

[root@puppetmaster modules]# facter OperatingSystem 
Linux

Как мы можем заметить в приведенном выше фрагменте кода, мы не определили OperatingSystem . Мы только что заменили значение мягким кодированным значением $ OperatingSystem в качестве обычной переменной.

В Puppet есть три типа фактов, которые можно использовать и определить:

• Основные факты
• Пользовательские факты
• Внешние факты

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

Кукольные Факты

Непосредственно перед тем, как агент запрашивает каталог у мастера, он сначала составляет полный список информации, доступной сам по себе, в форме пары ключ-значение. Информация об агенте собирается инструментом под названием facter, и каждая пара ключ-значение называется фактом. Ниже приводится общий вывод фактов об агенте.

[root@puppetagent1 ~]# facter
architecture => x86_64 
augeasversion => 1.0.0 
bios_release_date => 13/09/2012 
bios_vendor => innotek GmbH 
bios_version => VirtualBox 
blockdevice_sda_model => VBOX HARDDISK 
blockdevice_sda_size => 22020587520 
blockdevice_sda_vendor => ATA 
blockdevice_sr0_model => CD-ROM 
blockdevice_sr0_size => 1073741312 
blockdevice_sr0_vendor => VBOX 
blockdevices => sda,sr0 
boardmanufacturer => Oracle Corporation 
boardproductname => VirtualBox 
boardserialnumber => 0 

domain => codingbee.dyndns.org  
facterversion => 2.1.0 
filesystems => ext4,iso9660 
fqdn => puppetagent1.codingbee.dyndns.org 
hardwareisa => x86_64 
hardwaremodel => x86_64 
hostname => puppetagent1 
id => root 
interfaces => eth0,lo 
ipaddress => 172.228.24.01 
ipaddress_eth0 => 172.228.24.01 
ipaddress_lo => 127.0.0.1 
is_virtual => true 
kernel => Linux 
kernelmajversion => 2.6 
kernelrelease => 2.6.32-431.23.3.el6.x86_64 
kernelversion => 2.6.32 
lsbdistcodename => Final 
lsbdistdescription => CentOS release 6.5 (Final) 
lsbdistid => CentOS 
lsbdistrelease => 6.5 
lsbmajdistrelease => 6 
lsbrelease => :base-4.0-amd64:base-4.0-noarch:core-4.0-amd64:core-4.0noarch:graphics-4.0-amd64:
graphics-4.0-noarch:printing-4.0-amd64:printing-4.0noarch 
macaddress => 05:00:22:47:H9:77 
macaddress_eth0 => 05:00:22:47:H9:77 
manufacturer => innotek GmbH 
memoryfree => 125.86 GB 
memoryfree_mb => 805.86 
memorysize => 500 GB 
memorysize_mb => 996.14 
mtu_eth0 => 1500 
mtu_lo => 16436 
netmask => 255.255.255.0 
netmask_eth0 => 255.255.255.0  

network_lo => 127.0.0.0 
operatingsystem => CentOS 
operatingsystemmajrelease => 6 
operatingsystemrelease => 6.5 
osfamily => RedHat 
partitions => {"sda1"=>{
"uuid"=>"d74a4fa8-0883-4873-8db0-b09d91e2ee8d", "size" =>"1024000", 
"mount" => "/boot", "filesystem" => "ext4"}, "sda2"=>{"size" => "41981952", 
"filesystem" => "LVM2_member"}
} 
path => /usr/lib64/qt3.3/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin 
physicalprocessorcount => 1 
processor0 => Intel(R) Core(TM) i7 CPU         920  @ 2.67GHz 
processor1 => Intel(R) Core(TM) i7 CPU         920  @ 2.67GHz 
processor2 => Intel(R) Core(TM) i7 CPU         920  @ 2.67GHz 
processorcount => 3 
productname => VirtualBox 
ps => ps -ef 
puppetversion => 3.6.2 
rubysitedir => /usr/lib/ruby/site_ruby/1.8 
rubyversion => 1.8.7
selinux => true 
selinux_config_mode => enforcing 
selinux_config_policy => targeted 
selinux_current_mode => enforcing 
selinux_enforced => true 
selinux_policyversion => 24 
serialnumber => 0 
sshdsakey => AAAAB3NzaC1kc3MAAACBAK5fYwRM3UtOs8zBCtRTjuHLw56p94X/E0UZBZwFR3q7
WH0x5+MNsjfmdCxKvpY/WlIIUcFJzvlfjXm4qDaTYalbzSZJMT266njNbw5WwLJcJ74KdW92ds76pjgm
CsjAh+R9YnyKCEE35GsYjGH7whw0gl/rZVrjvWYKQDOmJA2dAAAAFQCoYABgjpv3EkTWgjLIMnxA0Gfud
QAAAIBM4U6/nerfn6Qvt43FC2iybvwVo8ufixJl5YSEhs92uzsW6jiw68aaZ32q095/gEqYzeF7a2knr
OpASgO9xXqStYKg8ExWQVaVGFTR1NwqhZvz0oRSbrN3h3tHgknoKETRAg/imZQ2P6tppAoQZ8wpuLrXU
CyhgJGZ04Phv8hinAAAAIBN4xaycuK0mdH/YdcgcLiSn8cjgtiETVzDYa+jF 
swapfree => 3.55 GB 
swapfree_mb => 2015.99 
swapsize => 3.55 GB 
swapsize_mb => 2015.99 
timezone => GMT 
type => Other 
uniqueid => a8c0af01 
uptime => 45:012 hours 
uptime_days => 0 
uptime_hours => 6 
uptime_seconds => 21865 
uuid => BD8B9D85-1BFD-4015-A633-BF71D9A6A741 
virtual => virtualbox 

В приведенном выше коде мы видим, что некоторые данные перекрываются с небольшим количеством информации, доступной в переменной bash «env». Puppet напрямую не использует данные, вместо этого он использует данные Facter, данные Facter обрабатываются как глобальная переменная.

Затем факты доступны как переменные верхнего уровня, и мастер Puppet может использовать их для составления каталога Puppet для запрашивающего агента. Фасеты вызываются в манифесте как обычная переменная с префиксом $.

пример

if ($OperatingSystem == "Linux") { 
   $message = "This machine OS is of the type $OperatingSystem \n" 
} else { 
   $message = "This machine is unknown \n" 
} 

file { "/tmp/machineOperatingSystem.txt": 
   ensure => file, 
   content => "$message" 
}

Приведенный выше файл манифеста беспокоит только об одном файле с именем machineOperatingSystem.txt , где содержимое этого файла вычитается фактом, называемым OperatingSystem .

[root@puppetagent1 /]# facter OperatingSystem 
Linux  

[root@puppetagent1 /]# puppet apply /tmp/ostype.pp 
Notice: Compiled catalog for puppetagent1.codingbee.dyndns.org 
in environment production in 0.07 seconds 
Notice: /Stage[main]/Main/File[/tmp/machineOperatingSystem.txt]/ensure: 
defined content as '{md5}f59dc5797d5402b1122c28c6da54d073' 
Notice: Finished catalog run in 0.04 seconds  

[root@puppetagent1 /]# cat /tmp/machinetype.txt 
This machine OS is of the type Linux

Пользовательские факты

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

• Использование «экспорта FACTER… Синтаксис»
• Использование настроек $ LOAD_PATH
• FACTERLIB
• Pluginsync

Использование синтаксиса «export FACTER»

Можно вручную добавить факты, используя синтаксис экспорта FACTER_ {имя факта}.

пример

[root@puppetagent1 facter]# export FACTER_tallest_mountain="Everest" 
[root@puppetagent1 facter]# facter tallest_mountain Everest

Использование настроек $ LOAD_PATH

В Ruby $ LOAD_PATH эквивалентно специальному параметру Bash. Хотя она похожа на переменную bash $ PATH, в действительности $ LOAD_PATH не является переменной окружения, а предопределенной переменной.

$ LOAD_PATH имеет синоним «$:». Эта переменная является массивом для поиска и загрузки значений.

[root@puppetagent1 ~]# ruby -e 'puts $LOAD_PATH'            
# note you have to use single quotes.  
/usr/lib/ruby/site_ruby/1.6 
/usr/lib64/ruby/site_ruby/1.6 
/usr/lib64/ruby/site_ruby/1.6/x86_64-linux 
/usr/lib/ruby/site_ruby 
/usr/lib64/ruby/site_ruby 
/usr/lib64/site_ruby/1.6 
/usr/lib64/site_ruby/1.6/x86_64-linux 
/usr/lib64/site_ruby 
/usr/lib/ruby/1.6 
/usr/lib64/ruby/1.6 
/usr/lib64/ruby/1.6/x86_64-linux 

Давайте рассмотрим пример создания директории каталогов, добавления файла .pp и добавления к нему содержимого.

[root@puppetagent1 ~]# cd /usr/lib/ruby/site_ruby/ 
[root@puppetagent1 site_ruby]# mkdir facter 
[root@puppetagent1 site_ruby]# cd facter/ 
[root@puppetagent1 facter]# ls 
[root@puppetagent1 facter]# touch newadded_facts.rb 

Добавьте следующее содержимое в файл custom_facts.rb.

[root@puppetagent1 facter]# cat newadded_facts.rb 
Facter.add('tallest_mountain') do 
   setcode "echo Everest" 
end 

Facter работает методом сканирования всех папок, перечисленных в $ LOAD_PATH, и ищет директора с именем facter. Как только он найдет эту конкретную папку, он загрузит их в любом месте структуры папки. Если он находит эту папку, он ищет любой Ruby-файл в этой папке Facter и загружает все определенные факты о любой конкретной конфигурации в память.

Использование FACTERLIB

В Puppet FACTERLIB работает очень похоже на $ LOAD_PATH, но с одним ключевым отличием — это параметр среды уровня ОС, а не специальная переменная Ruby. По умолчанию переменная среды может быть не установлена.

[root@puppetagent1 facter]# env | grep "FACTERLIB" 
[root@puppetagent1 facter]# 

Чтобы протестировать FACTERLIB, нам нужно выполнить следующие шаги.

Создайте папку с именем test_facts в следующей структуре.

[root@puppetagent1 tmp]# tree /tmp/test_facts/ 
/tmp/some_facts/ 
├── vipin 
│   └── longest_river.rb 
└── testing 
   └── longest_wall.rb 

Добавьте следующее содержимое в файлы .rb.

[root@puppetagent1 vipin]# cat longest_river.rb 
Facter.add('longest_river') do 
   setcode "echo Nile" 
end 

[root@puppetagent1 testing]# cat longest_wall.rb 
Facter.add('longest_wall') do 
   setcode "echo 'China Wall'" 
end 

Используйте оператор экспорта.

[root@puppetagent1 /]# export 
FACTERLIB = "/tmp/some_facts/river:/tmp/some_facts/wall" 
[root@puppetagent1 /]# env | grep "FACTERLIB" 
FACTERLIB = /tmp/some_facts/river:/tmp/some_facts/wall 

Протестируйте новый фактер.

[root@puppetagent1 /]# facter longest_river 
Nile 
[root@puppetagent1 /]# facter longest_wall 
China Wall 

Внешние факты

Внешние факты очень полезны, когда пользователь желает применить некоторые новые факты, созданные во время предоставления. Внешние факты являются одним из ключевых способов применения метаданных к ВМ на этапе ее подготовки (например, с использованием vSphere, OpenStack, AWS и т. Д.)

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

Создание внешнего факта

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

$ mkdir -p /etc/facter/facts.d

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

$ ls -l /etc/facter/facts.d 
total 4 
-rwxrwxrwx. 1 root root 65 Sep 18 13:11 external-factstest.sh 
$ cat /etc/facter/facts.d/external-factstest.sh 
#!/bin/bash 
echo "hostgroup = dev" 
echo "environment = development"

Измените разрешение файла сценария.

$ chmod u+x /etc/facter/facts.d/external-facts.sh

После этого мы можем видеть переменную, присутствующую в паре ключ / значение.

$ facter hostgroup 
dev 
$ facter environment 
development 

Можно написать пользовательские факты в Puppet. В качестве ссылки используйте следующую ссылку с сайта Puppet.

https://docs.puppet.com/facter/latest/fact_overview.html#writing-structured-facts

Кукольный — Ресурс

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

Блок кода Puppet в файле манифеста или любом другом файле называется объявлением ресурса. Блок кода написан на языке декларативного языка моделирования (DML). Ниже приведен пример того, как это выглядит.

user { 'vipin': 
   ensure => present, 
   uid    => '552', 
   shell  => '/bin/bash', 
   home   => '/home/vipin', 
}

В Puppet объявление ресурса для любого конкретного типа ресурса выполняется в блоке кода. В следующем примере пользователь состоит в основном из четырех предварительно определенных параметров.

• Тип ресурса — в приведенном фрагменте кода это пользователь.

• Параметр ресурса — в приведенном фрагменте кода это Vipin.

• Атрибуты — в приведенном фрагменте кода это обеспечивает, uid, shell, home.

• Значения — это значения, которые соответствуют каждому свойству.

Тип ресурса — в приведенном фрагменте кода это пользователь.

Параметр ресурса — в приведенном фрагменте кода это Vipin.

Атрибуты — в приведенном фрагменте кода это обеспечивает, uid, shell, home.

Значения — это значения, которые соответствуют каждому свойству.

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

Тип ресурса

В Puppet доступны различные типы ресурсов, которые имеют свой собственный способ работы. Эти типы ресурсов можно просмотреть с помощью команды «description» и опции «-list».

[root@puppetmaster ~]# puppet describe --list 
These are the types known to puppet: 
augeas          - Apply a change or an array of changes to the  ... 
computer        - Computer object management using DirectorySer ... 
cron            - Installs and manages cron jobs 
exec            - Executes external commands 
file            - Manages files, including their content, owner ... 
filebucket      - A repository for storing and retrieving file  ... 
group           - Manage groups 
host            - Installs and manages host entries 
interface       - This represents a router or switch interface 
k5login         - Manage the ‘.k5login’ file for a user 
macauthorization - Manage the Mac OS X authorization database 
mailalias       - .. no documentation .. 
maillist        - Manage email lists 
mcx             - MCX object management using DirectoryService  ... 
mount           - Manages mounted filesystems, including puttin ... 
nagios_command  - The Nagios type command 
nagios_contact  - The Nagios type contact 
nagios_contactgroup - The Nagios type contactgroup 
nagios_host     - The Nagios type host 
nagios_hostdependency - The Nagios type hostdependency 
nagios_hostescalation - The Nagios type hostescalation 
nagios_hostextinfo - The Nagios type hostextinfo 
nagios_hostgroup - The Nagios type hostgroup 

nagios_service  - The Nagios type service 
nagios_servicedependency - The Nagios type servicedependency 
nagios_serviceescalation - The Nagios type serviceescalation 
nagios_serviceextinfo - The Nagios type serviceextinfo  
nagios_servicegroup - The Nagios type servicegroup 
nagios_timeperiod - The Nagios type timeperiod 
notify          - .. no documentation .. 
package         - Manage packages 
resources       - This is a metatype that can manage other reso ... 
router          - .. no documentation .. 
schedule        - Define schedules for Puppet 
scheduled_task  - Installs and manages Windows Scheduled Tasks 
selboolean      - Manages SELinux booleans on systems with SELi ... 
service         - Manage running services 
ssh_authorized_key - Manages SSH authorized keys 
sshkey          - Installs and manages ssh host keys 
stage           - A resource type for creating new run stages 
tidy            - Remove unwanted files based on specific crite ... 
user            - Manage users 
vlan            - .. no documentation .. 
whit            - Whits are internal artifacts of Puppet's curr ... 
yumrepo         - The client-side description of a yum reposito ... 
zfs             - Manage zfs 
zone            - Manages Solaris zones 
zpool           - Manage zpools 

Название ресурса

В приведенном выше фрагменте кода у нас есть заголовок ресурса как vipin, который уникален для каждого ресурса, используемого в одном и том же файле кода. Это уникальный заголовок для этого типа ресурса пользователя. У нас не может быть ресурса с тем же именем, потому что это вызовет конфликты.

Команда Resource может использоваться для просмотра списка всех ресурсов, используя тип user.

[root@puppetmaster ~]# puppet resource user 
user { 'abrt': 
   ensure           => 'present', 
   gid              => '173', 
   home             => '/etc/abrt', 
   password         => '!!', 
   password_max_age => '-1', 
   password_min_age => '-1', 
   shell            => '/sbin/nologin', 
   uid              => '173', 
} 

user { 'admin': 
   ensure           => 'present', 
   comment          => 'admin', 
   gid              => '444', 
   groups           => ['sys', 'admin'], 
   home             => '/var/admin', 
   password         => '*', 
   password_max_age => '99999', 
   password_min_age => '0', 
   shell            => '/sbin/nologin', 
   uid              => '55', 
} 

user { 'tomcat': 
   ensure           => 'present', 
   comment          => 'tomcat', 
   gid              => '100', 
   home             => '/var/www', 
   password         => '!!', 
   password_max_age => '-1', 
   password_min_age => '-1', 
   shell            => '/sbin/nologin', 
   uid              => '100', 
} 

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

[root@puppetmaster ~]# puppet resource user tomcat 
user { 'apache': 
   ensure           => 'present', 
   comment          => 'tomcat', 
   gid              => '100', 
   home             => '/var/www', 
   password         => '!!', 
   password_max_age => '-1', 
   password_min_age => '-1', 
   shell            => '/sbin/nologin', 
   uid              => '100’, 
}

Атрибуты и ценности

Основная часть любого ресурса состоит из набора пар атрибут-значение. Здесь можно указать значения для свойства данного ресурса. Каждый тип ресурса имеет свой собственный набор атрибутов, которые можно настроить с помощью пар ключ-значение.

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

[root@puppetmaster ~]# puppet describe user 
user 
==== 
Manage users.  This type is mostly built to manage system users, 
so it is lacking some features useful for managing normal users. 

This resource type uses the prescribed native tools for creating groups 
and generally uses POSIX APIs for retrieving information about them.
It does not directly modify ‘/etc/passwd’ or anything. 

**Autorequires:** If Puppet is managing the user's primary group 
(as provided in the ‘gid’ attribute), 
the user resource will autorequire that group. 
If Puppet is managing any role accounts corresponding to the user's roles, 
the user resource will autorequire those role accounts.  

Parameters 
---------- 
- **allowdupe** 
   Whether to allow duplicate UIDs. Defaults to ‘false’. 
   Valid values are ‘true’, ‘false’, ‘yes’, ‘no’.  

- **attribute_membership** 
   Whether specified attribute value pairs should be treated as the 
   **complete list** (‘inclusive’) or the **minimum list** (‘minimum’) of 
   attribute/value pairs for the user. Defaults to ‘minimum’. 
   Valid values are ‘inclusive’, ‘minimum’.  

- **auths** 
   The auths the user has.  Multiple auths should be 
   specified as an array. 
   Requires features manages_solaris_rbac.  

- **comment** 
   A description of the user.  Generally the user's full name.  

- **ensure** 
   The basic state that the object should be in. 
   Valid values are ‘present’, ‘absent’, ‘role’.  

- **expiry**
   The expiry date for this user. Must be provided in 
   a zero-padded YYYY-MM-DD format --- e.g. 2010-02-19. 
   If you want to make sure the user account does never 
   expire, you can pass the special value ‘absent’. 
   Valid values are ‘absent’. Values can match ‘/^\d{4}-\d{2}-\d{2}$/’. 
   Requires features manages_expiry.  

- **forcelocal** 
   Forces the mangement of local accounts when accounts are also 
   being managed by some other NSS  

- **gid** 
   The user's primary group. Can be specified numerically or by name. 
   This attribute is not supported on Windows systems; use the ‘groups’ 
   attribute instead. (On Windows, designating a primary group is only 
   meaningful for domain accounts, which Puppet does not currently manage.)  

- **groups** 
   The groups to which the user belongs. The primary group should 
   not be listed, and groups should be identified by name rather than by 
   GID.  Multiple groups should be specified as an array.  

- **home** 
   The home directory of the user.  The directory must be created 
   separately and is not currently checked for existence.  

- **ia_load_module** 
   The name of the I&A module to use to manage this user. 
   Requires features manages_aix_lam.  

- **iterations** 
   This is the number of iterations of a chained computation of the 
   password hash (http://en.wikipedia.org/wiki/PBKDF2).  This parameter 
   is used in OS X. This field is required for managing passwords on OS X 
   >= 10.8. 
   Requires features manages_password_salt. 

- **key_membership**  

- **managehome** 
   Whether to manage the home directory when managing the user. 
   This will create the home directory when ‘ensure => present’, and 
   delete the home directory when ‘ensure => absent’. Defaults to ‘false’. 
   Valid values are ‘true’, ‘false’, ‘yes’, ‘no’.  

- **membership** 
   Whether specified groups should be considered the **complete list** 
   (‘inclusive’) or the **minimum list** (‘minimum’) of groups to which 
   the user belongs. Defaults to ‘minimum’. 
   Valid values are ‘inclusive’, ‘minimum’.  

- **name** 
   The user name. While naming limitations vary by operating system, 
   it is advisable to restrict names to the lowest common denominator, 
   which is a maximum of 8 characters beginning with a letter. 
   Note that Puppet considers user names to be case-sensitive, regardless 
   of the platform's own rules; be sure to always use the same case when 
   referring to a given user.  

- **password** 
   The user's password, in whatever encrypted format the local 
   system requires. 
   * Most modern Unix-like systems use salted SHA1 password hashes. You can use 
      Puppet's built-in ‘sha1’ function to generate a hash from a password. 
   * Mac OS X 10.5 and 10.6 also use salted SHA1 hashes.  

Windows API 
   for setting the password hash. 
   [stdlib]: https://github.com/puppetlabs/puppetlabs-stdlib/ 
   Be sure to enclose any value that includes a dollar sign ($) in single 
   quotes (') to avoid accidental variable interpolation. 
   Requires features manages_passwords.  

- **password_max_age** 
   The maximum number of days a password may be used before it must be changed. 
   Requires features manages_password_age.  

- **password_min_age** 
   The minimum number of days a password must be used before it may be changed. 
   Requires features manages_password_age.  

- **profile_membership** 
   Whether specified roles should be treated as the **complete list** 
   (‘inclusive’) or the **minimum list** (‘minimum’) of roles 
   of which the user is a member. Defaults to ‘minimum’. 
   Valid values are ‘inclusive’, ‘minimum’.  

- **profiles** 
   The profiles the user has.  Multiple profiles should be 
   specified as an array. 
   Requires features manages_solaris_rbac.  

- **project** 
   The name of the project associated with a user. 
   Requires features manages_solaris_rbac.  

- **uid** 
   The user ID; must be specified numerically. If no user ID is 
   specified when creating a new user, then one will be chosen 
   automatically. This will likely result in the same user having 
   different UIDs on different systems, which is not recommended. This is 
   especially noteworthy when managing the same user on both Darwin and 
   other platforms, since Puppet does UID generation on Darwin, but 
   the underlying tools do so on other platforms. 
   On Windows, this property is read-only and will return the user's 
   security identifier (SID). 

Puppet — слой абстракции ресурсов

В Puppet Resource Abstraction Layer (RAL) можно рассматривать как основную концептуализированную модель, на которой работает вся инфраструктура и настройка Puppet. В RAL каждый алфавит имеет свое значимое значение, которое определяется следующим образом.

Ресурс [R]

Ресурс может рассматриваться как все ресурсы, которые используются для моделирования любой конфигурации в Puppet. Это в основном встроенные ресурсы, которые по умолчанию присутствуют в Puppet. Их можно рассматривать как набор ресурсов, принадлежащих к предопределенному типу ресурса. Они похожи на концепцию ООП в любом другом языке программирования, где объект является экземпляром класса. В Puppet его ресурс является экземпляром типа ресурса.

Абстракция [A]

Абстракция может рассматриваться как ключевая особенность, где ресурсы определяются независимо от целевой ОС. Другими словами, при написании любого файла манифеста пользователю не нужно беспокоиться о целевой машине или ОС, которая присутствует на этой конкретной машине. В абстракции ресурсы дают достаточно информации о том, что должно существовать в агенте Puppet.

Puppet позаботится обо всех функциях или магии, происходящих за сценой. Независимо от ресурсов и ОС, Puppet позаботится о реализации конфигурации на целевой машине, при этом пользователю не нужно беспокоиться о том, как Puppet делает это за кулисами.

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

Слой [L]

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

Пример для типа ресурса пользователя

[root@puppetmaster ~]# puppet describe user --providers 
user 
==== 
Manage users.
This type is mostly built to manage systemusers, 
so it is lacking some features useful for managing normalusers. 
This resource type uses the prescribed native tools for 
creating groups and generally uses POSIX APIs for retrieving informationabout them.
It does not directly modify '/etc/passwd' or anything. 

- **comment** 
   A description of the user.  Generally the user's full name.  

- **ensure** 
   The basic state that the object should be in. 
   Valid values are 'present', 'absent', 'role'.  

- **expiry** 
   The expiry date for this user. 
   Must be provided in a zero-padded YYYY-MM-DD format --- e.g. 2010-02-19. 
   If you want to make sure the user account does never expire, 
   you can pass the special value 'absent'. 
   Valid values are 'absent'. 
   Values can match '/^\d{4}-\d{2}-\d{2}$/'. 
   Requires features manages_expiry.  

- **forcelocal** 
   Forces the management of local accounts when accounts are also 
   being managed by some other NSS 
   Valid values are 'true', 'false', 'yes', 'no'. 
   Requires features libuser.  

- **gid** 
   The user's primary group.  Can be specified numerically or by name. 
   This attribute is not supported on Windows systems; use the ‘groups’ 
   attribute instead. (On Windows, designating a primary group is only 
   meaningful for domain accounts, which Puppet does not currently manage.)  

- **groups** 
   The groups to which the user belongs. The primary group should 
   not be listed, and groups should be identified by name rather than by 
   GID. Multiple groups should be specified as an array.  

- **home** 
   The home directory of the user.  The directory must be created 
   separately and is not currently checked for existence.  

- **ia_load_module**
   The name of the I&A module to use to manage this user. 
   Requires features manages_aix_lam.  

- **iterations** 
   This is the number of iterations of a chained computation of the 
   password hash (http://en.wikipedia.org/wiki/PBKDF2).  
   This parameter is used in OS X. 
   This field is required for managing passwords on OS X >= 10.8.  

- **key_membership** 
   Whether specified key/value pairs should be considered the 
   **complete list** ('inclusive') or the **minimum list** ('minimum') of 
   the user's attributes. Defaults to 'minimum'. 
   Valid values are 'inclusive', 'minimum'.  

- **keys** 
   Specify user attributes in an array of key = value pairs. 
   Requires features manages_solaris_rbac.  

- **managehome** 
   Whether to manage the home directory when managing the user. 
   This will create the home directory when 'ensure => present', and 
   delete the home directory when ‘ensure => absent’. Defaults to ‘false’. 
   Valid values are ‘true’, ‘false’, ‘yes’, ‘no’.  

- **membership** 
   Whether specified groups should be considered the **complete list** 
   (‘inclusive’) or the **minimum list** (‘minimum’) of groups to which 
   the user belongs. Defaults to ‘minimum’. 
   Valid values are ‘inclusive’, ‘minimum’. 

- **name** 
   The user name. While naming limitations vary by operating system, 
   it is advisable to restrict names to the lowest common denominator.  

- **password** 
   The user's password, in whatever encrypted format the local system requires. 
   * Most modern Unix-like systems use salted SHA1 password hashes. You can use 
      Puppet's built-in ‘sha1’ function to generate a hash from a password. 
   * Mac OS X 10.5 and 10.6 also use salted SHA1 hashes. 
   * Mac OS X 10.7 (Lion) uses salted SHA512 hashes. 
   The Puppet Labs [stdlib][] module contains a ‘str2saltedsha512’ 
   function which can generate password hashes for Lion. 
   * Mac OS X 10.8 and higher use salted SHA512 PBKDF2 hashes. 
   When managing passwords on these systems the salt and iterations properties 
   need to be specified as well as the password. 
   [stdlib]: https://github.com/puppetlabs/puppetlabs-stdlib/ 
   Be sure to enclose any value that includes a dollar sign ($) in single 
   quotes (') to avoid accidental variable interpolation. 
   Requires features manages_passwords.  

- **password_max_age** 
   The maximum number of days a password may be used before it must be changed. 
Requires features manages_password_age.  

- **password_min_age** 
   The minimum number of days a password must be used before it may be changed. 
Requires features manages_password_age.  

- **profile_membership** 
   Whether specified roles should be treated as the **complete list** 
   (‘inclusive’) or the **minimum list** (‘minimum’) of roles 
   of which the user is a member. Defaults to ‘minimum’. 
   Valid values are ‘inclusive’, ‘minimum’. 

- **profiles** 
   The profiles the user has.  Multiple profiles should be 
   specified as an array. 
Requires features manages_solaris_rbac.  

- **project** 
   The name of the project associated with a user. 
   Requires features manages_solaris_rbac.  

- **purge_ssh_keys** 
   Purge ssh keys authorized for the user 
   if they are not managed via ssh_authorized_keys. 
   When true, looks for keys in .ssh/authorized_keys in the user's home directory. 
   Possible values are true, false, or an array of 
   paths to file to search for authorized keys. 
   If a path starts with ~ or %h, this token is replaced with the user's home directory. 
   Valid values are ‘true’, ‘false’.  

- **role_membership** 
   Whether specified roles should be considered the **complete list** 
   (‘inclusive’) or the **minimum list** (‘minimum’) of roles the user has. 
   Defaults to ‘minimum’. 
Valid values are ‘inclusive’, ‘minimum’.  

- **roles** 
   The roles the user has.  Multiple roles should be 
   specified as an array. 
Requires features manages_solaris_rbac.  

- **salt** 
   This is the 32 byte salt used to generate the PBKDF2 password used in 
   OS X. This field is required for managing passwords on OS X >= 10.8. 
   Requires features manages_password_salt. 

- **shell** 
   The user's login shell.  The shell must exist and be 
   executable. 
   This attribute cannot be managed on Windows systems. 
   Requires features manages_shell. 

- **system** 
   Whether the user is a system user, according to the OS's criteria; 
   on most platforms, a UID less than or equal to 500 indicates a system 
   user. Defaults to ‘false’. 
   Valid values are ‘true’, ‘false’, ‘yes’, ‘no’.  

- **uid** 
   The user ID; must be specified numerically. If no user ID is 
   specified when creating a new user, then one will be chosen 
   automatically. This will likely result in the same user having 
   different UIDs on different systems, which is not recommended. 
   This is especially noteworthy when managing the same user on both Darwin and 
   other platforms, since Puppet does UID generation on Darwin, but 
   the underlying tools do so on other platforms. 
   On Windows, this property is read-only and will return the user's 
   security identifier (SID).  

Providers 
--------- 

- **aix** 
   User management for AIX. 
   * Required binaries: '/bin/chpasswd', '/usr/bin/chuser', 
   '/usr/bin/mkuser', '/usr/sbin/lsgroup', '/usr/sbin/lsuser', 
   '/usr/sbin/rmuser'. 
   * Default for ‘operatingsystem’ == ‘aix’. 
   * Supported features: ‘manages_aix_lam’, ‘manages_expiry’, 
   ‘manages_homedir’, ‘manages_password_age’, ‘manages_passwords’, 
   ‘manages_shell’. 

- **directoryservice** 
   User management on OS X. 
   * Required binaries: ‘/usr/bin/dscacheutil’, ‘/usr/bin/dscl’, 
   ‘/usr/bin/dsimport’, ‘/usr/bin/plutil’, ‘/usr/bin/uuidgen’. 
   * Default for ‘operatingsystem’ == ‘darwin’. 
   * Supported features: ‘manages_password_salt’, ‘manages_passwords’, 
   ‘manages_shell’.

- **hpuxuseradd** 
   User management for HP-UX. This provider uses the undocumented ‘-F’ 
   switch to HP-UX's special ‘usermod’ binary to work around the fact that 
   its standard ‘usermod’ cannot make changes while the user is logged in. 
   * Required binaries: ‘/usr/sam/lbin/useradd.sam’, 
   ‘/usr/sam/lbin/userdel.sam’, ‘/usr/sam/lbin/usermod.sam’. 
   * Default for ‘operatingsystem’ == ‘hp-ux’. 
   * Supported features: ‘allows_duplicates’, ‘manages_homedir’, 
   ‘manages_passwords’.  

- **ldap** 
   User management via LDAP. 
   This provider requires that you have valid values for all of the 
   LDAP-related settings in ‘puppet.conf’, including ‘ldapbase’.
   You will almost definitely need settings for ‘ldapuser’ and ‘ldappassword’ in order 
   for your clients to write to LDAP. 
* Supported features: ‘manages_passwords’, ‘manages_shell’.  

- **pw** 
   User management via ‘pw’ on FreeBSD and DragonFly BSD. 
   * Required binaries: ‘pw’. 
   * Default for ‘operatingsystem’ == ‘freebsd, dragonfly’. 
   * Supported features: ‘allows_duplicates’, ‘manages_expiry’, 
   ‘manages_homedir’, ‘manages_passwords’, ‘manages_shell’. 

- **user_role_add** 
   User and role management on Solaris, via ‘useradd’ and ‘roleadd’. 
   * Required binaries: ‘passwd’, ‘roleadd’, ‘roledel’, ‘rolemod’, 
   ‘useradd’, ‘userdel’, ‘usermod’. 
   * Default for ‘osfamily’ == ‘solaris’. 
   * Supported features: ‘allows_duplicates’, ‘manages_homedir’, 
   ‘manages_password_age’, ‘manages_passwords’, ‘manages_solaris_rbac’.  

- **useradd** 
   User management via ‘useradd’ and its ilk.  Note that you will need to 
   install Ruby's shadow password library (often known as ‘ruby-libshadow’) 
   if you wish to manage user passwords. 
   * Required binaries: ‘chage’, ‘luseradd’, ‘useradd’, ‘userdel’, ‘usermod’. 
   * Supported features: ‘allows_duplicates’, ‘libuser’, ‘manages_expiry’, 
   ‘manages_homedir’, ‘manages_password_age’, ‘manages_passwords’, 
   ‘manages_shell’, ‘system_users’.  

- **windows_adsi** 
   Local user management for Windows. 
   * Default for 'operatingsystem' == 'windows'. 
   * Supported features: 'manages_homedir', 'manages_passwords'. 

Ресурс тестирования

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

Для тестирования мы будем применять ресурс локально. Поскольку у нас есть ресурс, предопределенный выше с user = vipin . Одним из способов применения ресурса является CLI. Это можно сделать, переписав весь ресурс в одну команду, а затем передав его в подкоманду ресурса.

puppet resource user vipin ensure = present uid = '505' 
shell = '/bin/bash' home = '/home/vipin'

Протестируйте прикладной ресурс.

[root@puppetmaster ~]# cat /etc/passwd | grep "vipin" 
vipin:x:505:501::/home/vipin:/bin/bash 

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

Кукольный — Шаблон

Шаблонирование — это метод получения вещей в стандартном формате, который можно использовать в нескольких местах. В Puppet шаблоны и шаблоны поддерживаются с помощью erb, который входит в состав стандартной библиотеки Ruby, которая может использоваться в других проектах, кроме Ruby, как в проектах Ruby on Rails. Как стандартная практика, нужно иметь базовое понимание Ruby. Шаблонирование очень полезно, когда пользователь пытается управлять содержимым файла шаблона. Шаблоны играют ключевую роль, когда конфигурации не могут управляться встроенным типом Puppet.

Оценка шаблонов

Шаблоны оцениваются с использованием простых функций.

$value = template ("testtemplate.erb")

Можно указать полный путь к шаблону или можно извлечь все шаблоны в шаблонном шаблоне Puppet, который обычно находится в / var / puppet / templates. Найти местоположение каталога можно, запустив puppet –-configprint templatedir.

Шаблоны всегда оцениваются синтаксическим анализатором, а не клиентом, что означает, что если кто-то использует puppetmasterd, то шаблон должен быть только на сервере и никогда не нужно загружать их на клиент. Там нет разницы в том, как клиент видит между использованием шаблона и указанием всего содержимого файла в виде строки. Это ясно указывает на то, что специфичные для клиента переменные сначала изучаются puppetmasterd во время фазы запуска puppet.

Использование шаблонов

Ниже приведен пример создания конфигурации Tomcat для сайтов тестирования.

define testingsite($cgidir, $tracdir) { 
   file { "testing-$name": 
   path => "/etc/tomcat/testing/$name.conf", 
   owner => superuser, 
   group => superuser, 
   mode => 644, 
   require => File[tomcatconf], 
   content => template("testsite.erb"), 
   notify => Service[tomcat] 
}  
   symlink { "testsym-$name": 
      path => "$cgidir/$name.cgi", 
      ensure => "/usr/share/test/cgi-bin/test.cgi" 
   } 
} 

Ниже приведено определение шаблона.

<Location "/cgi-bin/ <%= name %>.cgi"> 
   SetEnv TEST_ENV "/export/svn/test/<%= name %>" 
</Location>  

# You need something like this to authenticate users 
<Location "/cgi-bin/<%= name %>.cgi/login"> 
   AuthType Basic 
   AuthName "Test" 
   AuthUserFile /etc/tomcat/auth/svn 
   Require valid-user 
</Location>

Это помещает каждый файл шаблона в отдельный файл, а затем нужно просто сказать Apache, чтобы загрузить эти файлы конфигурации.

Include /etc/apache2/trac/[^.#]*

Объединение шаблонов

Два шаблона могут быть легко объединены с помощью следующей команды.

template('/path/to/template1','/path/to/template2')

Итерация в шаблонах

Шаблон Puppet также поддерживает итерацию массива. Если переменная, к которой вы обращаетесь, является массивом, то ее можно перебрать.

$values = [val1, val2, otherval]

У нас могут быть шаблоны, подобные следующим.

<% values.each do |val| -%> 
Some stuff with <%= val %> 
<% end -%>

Приведенная выше команда даст следующий результат.

Some stuff with val1 
Some stuff with val2 
Some stuff with otherval 

Условия в шаблонах

Шаблон erb поддерживает условные выражения . Следующая конструкция — это быстрый и простой способ условного размещения содержимого в файле.

<% if broadcast != "NONE" %> broadcast <%= broadcast %> <% end %>

Шаблоны и Переменные

Можно использовать шаблоны для заполнения переменных в дополнение к заполнению содержимого файла.

testvariable = template('/var/puppet/template/testvar')

Неопределенная переменная

Если нужно проверить, определена ли переменная перед ее использованием, сработает следующая команда.

<% if has_variable?("myvar") then %> 
myvar has <%= myvar %> value 
<% end %>

Переменная вне области видимости

Можно явно искать переменную вне области видимости с помощью функции lookupvar.

<%= scope.lookupvar('apache::user') %>

Образец шаблона проекта

<#Autogenerated by puppet. Do not edit. 
[default] 
#Default priority (lower value means higher priority) 
priority = <%= @priority %> 
#Different types of backup. Will be done in the same order as specified here. 
#Valid options: rdiff-backup, mysql, command 
backups = <% if @backup_rdiff %>rdiff-backup, 
<% end %><% if @backup_mysql %>mysql, 
<% end %><% if @backup_command %>command<% end %> 
<% if @backup_rdiff -%>  

[rdiff-backup]  

<% if @rdiff_global_exclude_file -%> 
   global-exclude-file = <%= @rdiff_global_exclude_file %> 
<% end -%> 
   <% if @rdiff_user -%> 
      user = <%= @rdiff_user %> 
<% end -%> 
<% if @rdiff_path -%> 
   path = <%= @rdiff_path %> 
<% end -%>  

#Optional extra parameters for rdiff-backup  

extra-parameters = <%= @rdiff_extra_parameters %>  

#How long backups are going to be kept 
keep = <%= @rdiff_keep %> 
<% end -%> 
<% if @backup_mysql -%>%= scope.lookupvar('apache::user') %>  

[mysql]  

#ssh user to connect for running the backup 
sshuser =  <%= @mysql_sshuser %>

#ssh private key to be used 
   sshkey = <%= @backup_home %>/<%= @mysql_sshkey %> 
   <% end -%> 
<% if @backup_command -%>  
[command] 

#Run a specific command on the backup server after the backup has finished  

command = <%= @command_to_execute %> 
<% end -%>

Кукольный — Классы

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

Ниже приведен пример класса Puppet.

[root@puppetmaster manifests]# cat site.pp  
class f3backup ( 
   $backup_home   = '/backup', 
   $backup_server = 'default', 
   $myname        = $::fqdn, 
   $ensure        = 'directory', 
) { 
   include '::f3backup::common' 
   if ( $myname == '' or $myname == undef ) { 
      fail('myname must not be empty') 
   }  
   @@file { "${backup_home}/f3backup/${myname}": 
      # To support 'absent', though force will be needed 
      ensure => $ensure, 
      owner  => 'backup', 
      group  => 'backup', 
      mode   => '0644', 
      tag    => "f3backup-${backup_server}", 
   }
}   

В приведенном выше примере у нас есть два клиента, где пользователь должен существовать. Как можно заметить, мы повторили один и тот же ресурс дважды. Один из способов не выполнять одну и ту же задачу при объединении двух узлов.

[root@puppetmaster manifests]# cat site.pp 
node 'Brcleprod001','Brcleprod002' { 
   user { 'vipin': 
      ensure => present, 
      uid    => '101', 
      shell  => '/bin/bash', 
      home   => '/home/homer', 
   } 
}

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

class vipin_g01063908 { 
   user { 'g01063908': 
      ensure => present, 
      uid    => '101', 
      shell  => '/bin/bash', 
      home   => '/home/g01063908', 
   } 
}  
node 'Brcleprod001' { 
   class {vipin_g01063908:} 
}  
node 'Brcleprod002' { 
   class {vipin_g01063908:} 
}

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

Параметризованный класс

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

[root@puppetmaster ~]# cat /etc/puppet/manifests/site.pp 
class user_account ($username){ 
   user { $username: 
      ensure => present, 
      uid    => '101', 
      shell  => '/bin/bash', 
      home   => "/home/$username", 
   } 
}  
node 'Brcleprod002' { 
   class { user_account: 
      username => "G01063908", 
   } 
} 
node 'Brcleprod002' { 
   class {user_account: 
      username => "G01063909", 
   } 
} 

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

Brcleprod001

[root@puppetagent1 ~]# puppet agent --test 
Info: Retrieving pluginfacts 
Info: Retrieving plugin 
Info: Caching catalog for puppetagent1.testing.dyndns.org 
Info: Applying configuration version '1419452655' 

Notice: /Stage[main]/User_account/User[homer]/ensure: created 
Notice: Finished catalog run in 0.15 seconds 
[root@brcleprod001 ~]# cat /etc/passwd | grep "vipin" 
G01063908:x:101:501::/home/G01063909:/bin/bash 

Brcleprod002

[root@Brcleprod002 ~]# puppet agent --test 
Info: Retrieving pluginfacts 
Info: Retrieving plugin 
Info: Caching catalog for puppetagent2.testing.dyndns.org 
Info: Applying configuration version '1419452725' 

Notice: /Stage[main]/User_account/User[bart]/ensure: created 
Notice: Finished catalog run in 0.19 seconds 
[root@puppetagent2 ~]# cat /etc/passwd | grep "varsha" 
G01063909:x:101:501::/home/G01063909:/bin/bash

Можно также установить значение по умолчанию для параметра класса, как показано в следующем коде.

[root@puppetmaster ~]# cat /etc/puppet/manifests/site.pp 
class user_account ($username = ‘g01063908'){ 
   user { $username: 
      ensure => present, 
      uid    => '101', 
      shell  => '/bin/bash', 
      home   => "/home/$username", 
   } 
}  
node 'Brcleprod001' { 
   class {user_account:} 
}  
node 'Brcleprod002' { 
   class {user_account: 
      username => "g01063909", 
   } 
} 

Кукольный — функция

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

• Заявления стоят сами по себе, и у них нет никакого типа возврата. Они используются для выполнения отдельных задач, таких как импорт других модулей Puppet в новый файл манифеста.

• Rvalue возвращает значения и может использоваться только тогда, когда для оператора требуется значение, например, для присваивания или оператора case.

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

Rvalue возвращает значения и может использоваться только тогда, когда для оператора требуется значение, например, для присваивания или оператора case.

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

Функция файла

Файловая функция файлового ресурса состоит в том, чтобы загрузить модуль в Puppet и вернуть желаемый результат в виде строки. Аргументы, которые он ищет, это ссылка <module name> / <file>, которая помогает в загрузке модуля из каталога файлов модуля Puppet.

Как скрипт / tesingscript.sh будет загружать файлы из <имя модуля> /script/files/testingscript.sh. Функция имеет возможность считывать и принимать абсолютный путь, который помогает в загрузке файла из любой точки диска.

Включить функцию

В Puppet функция включения очень похожа на функцию включения в любом другом языке программирования. Он используется для объявления одного или нескольких классов, что приводит к оценке всех ресурсов, присутствующих внутри этих классов, и, наконец, их добавлению в каталог. Это работает так: функция include принимает имя класса, список классов или список имен классов через запятую.

При использовании оператора include следует иметь в виду, что в классе его можно использовать несколько раз, но есть ограничение на включение одного класса только один раз. Если включаемый класс принимает параметр, функция включения автоматически ищет значения для них, используя <имя класса> :: <имя параметра> в качестве ключа поиска.

Функция include не приводит к тому, что класс будет содержаться в классе при их объявлении, для этого нам нужно использовать содержащуюся функцию. Он даже не создает зависимости в объявленном классе и окружающих его классах.

В функции include допускается только полное имя класса, относительные имена не допускаются.

Определенная функция

В Puppet определенная функция помогает определить, где задан данный класс или тип ресурса, и возвращает логическое значение или нет. Можно также использовать определение, чтобы определить, определен ли определенный ресурс или определенная переменная имеет значение. При использовании определенной функции следует помнить, что эта функция принимает как минимум один строковый аргумент, который может быть именем класса, именем типа, ссылкой на ресурс или ссылкой на переменную в форме «$ name».

Определите проверки функций как для собственного, так и для определенного типа функции, включая типы, предоставляемые модулями. Тип и класс соответствуют их именам. Функция соответствует замедлению ресурса, используя ссылку на ресурс.

Определить совпадения функций

# Matching resource types 
defined("file") 
defined("customtype")  

# Matching defines and classes 
defined("testing") 
defined("testing::java")  

# Matching variables 
defined('$name')  

# Matching declared resources 
defined(File['/tmp/file']) 

Кукольный — Пользовательские функции

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

Написание пользовательских функций

Есть несколько вещей, которые нужно иметь в виду, прежде чем писать функцию.

• В Puppet функции выполняются компиляторами, что означает, что все функции выполняются на Puppet master, и им не нужно иметь дело с любым из клиентов Puppet для одного и того же. Функции могут взаимодействовать только с агентами, если информация представлена ​​в форме фактов.

• Мастер Puppet улавливает пользовательские функции, что означает, что необходимо перезапустить мастер Puppet, если кто-то вносит изменения в функцию Puppet.

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

• Доступны два совершенно разных типа функций: функция Rvalue, которая возвращает значение, и функция оператора, которая ничего не возвращает.

• Имя файла, содержащего функцию, должно совпадать с именем функции в файле. В противном случае он не будет загружен автоматически.

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

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

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

Доступны два совершенно разных типа функций: функция Rvalue, которая возвращает значение, и функция оператора, которая ничего не возвращает.

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

Расположение для размещения пользовательской функции

Все пользовательские функции реализованы в виде отдельных файлов .rb и распределены между модулями. Нужно поместить пользовательские функции в lib / puppet / parser / function. Функции могут быть загружены из файла .rb из следующих мест.

• $ LIBDIR / кукольный / СА / функции
• подкаталоги puppet / parser / functions в вашем Ruby $ LOAD_PATH

Создание новой функции

Новые функции создаются или определяются с использованием метода newfunction внутри модуля puppet :: parser :: Functions . Нужно передать имя функции в качестве символа методу newfunction и код для запуска в виде блока. В следующем примере показана функция, которая используется для записи строки в файл в каталоге / user.

module Puppet::Parser::Functions 
   newfunction(:write_line_to_file) do |args| 
      filename = args[0] 
      str = args[1] 
      File.open(filename, 'a') {|fd| fd.puts str } 
   end 
end

Когда пользователь объявил функцию, ее можно использовать в файле манифеста, как показано ниже.

write_line_to_file('/user/vipin.txt, "Hello vipin!")

Кукольный — Окружающая среда

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

Puppet поддерживает управление несколькими средами на одной линии с Ruby on Rails. Ключевым фактором, стоящим за созданием этих сред, является обеспечение простого механизма управления на разных уровнях соглашения об уровне обслуживания. В некоторых случаях аппарат всегда должен быть включен без какой-либо терпимости и использования старого программного обеспечения. В то время как другие среды являются современными и используются для целей тестирования. Они используются для обновлений для более важных машин.

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

Цель окружающей среды

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

Использование среды на Puppet Master

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

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

[main] 
manifest = /usr/testing/puppet/site.pp 
modulepath = /usr/testing/puppet/modules 
[development] 
manifest = /usr/testing/puppet/development/site.pp 
modulepath = /usr/testing/puppet/development/modules

В приведенном выше коде любой клиент в среде разработки будет использовать файл манифеста site.pp, расположенный в каталоге / usr / share / puppet / development, и Puppet будет искать любой модуль в каталоге / usr / share / puppet / development / modules ,

При запуске Puppet с или без какой-либо среды по умолчанию используется файл site.pp и каталог, указанный в значениях manifest и modulepath в главном разделе конфигурации.

Существует всего несколько конфигураций, которые на самом деле имеет смысл настраивать в предварительном окружении, и все эти параметры вращаются вокруг указания, какие файлы использовать для компиляции конфигурации клиента.

Ниже приведены параметры.

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

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

• Manifest — определяет, какую конфигурацию использовать в качестве сценария точки входа.

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

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

Manifest — определяет, какую конфигурацию использовать в качестве сценария точки входа.

С несколькими модулями Puppets помогают получить модульность для конфигураций. В Puppet можно использовать несколько сред, которые работают намного лучше, если в основном полагаться на модули. Легче переносить изменения в среды, инкапсулируя изменения в модуле. Файловый сервер использует специфический для среды путь к модулю; если вы выполняете обслуживание файлов из модулей, а не из отдельных подключенных каталогов, эта среда сможет получать файлы, относящиеся к среде, и, наконец, текущая среда также будет доступна в переменной $ environment в файле манифеста.

Настройка клиентской среды

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

[puppetd] 
environment = Testing 

Приведенное выше определение в файле конфигурации определяет, какую среду файл конфигурации в нашем случае он тестирует.

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

#puppetd -–environment = testing

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

Путь поиска кукол

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

• Значение, указанное в командной строке
• Значения, указанные в разделе, относящемся к среде
• Значения, указанные в специфичном для исполняемого файла разделе
• Значения, указанные в основном разделе

Кукольный — Тип и поставщик

Типы кукол используются для индивидуального управления конфигурацией. Puppet имеет разные типы, такие как тип сервиса, тип пакета, тип провайдера и т. Д. В каждом типе есть провайдеры. Поставщик обрабатывает конфигурацию на разных платформах или инструментах. Например, тип пакета имеет провайдеров aptitude, yum, rpm и DGM. Существует много типов, и Puppet предлагает хороший элемент управления конфигурацией спектра, которым необходимо управлять.

Puppet использует Ruby в качестве базового языка. Все присутствующие типы Puppet и провайдеры написаны на языке Ruby. Поскольку он соответствует стандартному формату кодирования, их можно просто создать, как показано в примере для репо, который управляет репозиториями. Здесь мы создадим репо типа и провайдеры svn и git. Первая часть типа репо — это сам тип. Типы обычно хранятся в lib / puppet / type. Для этого мы создадим файл с именем repo.rb.

$ touch repo.rb

Добавьте следующее содержимое в файл.

Puppet::Type.newtype(:repo) do  
@doc = "Manage repos"  
   Ensurable   
   newparam(:source) do 
      desc "The repo source"  
      
      validate do |value| 
         if value =~ /^git/ 
            resource[:provider] = :git 
         else 
            resource[:provider] = :svn 
         end 
      end 
      isnamevar 
   end  

   newparam(:path) do 
      desc "Destination path"  
      validate do |value| 
         unless value =~ /^\/[a-z0-9]+/ 
            raise ArgumentError , "%s is not a valid file path" % value 
         end 
      end 
   end 
end 

В приведенном выше сценарии мы создали блок « Puppet :: Type.newtype (: repo) do », который создает новый тип с именем repo. Затем у нас есть @doc, который помогает добавлять любой уровень детализации, который вы хотите добавить. Следующее утверждение является Ensurable; это создает базовое свойство обеспечения. Тип Puppet использует свойство sure для определения состояния элемента конфигурации.

пример

service { "sshd": 
   ensure => present, 
} 

Оператор обеспечивает сообщает Puppet, кроме трех методов: создавать, уничтожать и существовать в поставщике. Эти методы предоставляют следующие функции —

• Команда для создания ресурса
• Команда для удаления ресурса
• Команда для проверки существования ресурса

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

Далее мы определяем новый параметр с именем source.

newparam(:source) do 
   desc "The repo source" 
   validate do |value| 
      if value =~ /^git/ 
         resource[:provider] = :git 
      else 
         resource[:provider] = :svn 
      end 
   end 
   isnamevar 
end

Источник сообщит типу репозитория, где получить / клонировать / оформить исходный репозиторий. В этом мы также используем хук под названием validate. В разделе провайдера мы определили git и svn, которые проверяют правильность определенного нами репозитория.

Наконец, в коде мы определили еще один параметр, называемый path.

newparam(:path) do 
   desc "Destination path" 
   validate do |value| 
      unless value =~ /^\/[a-z0-9]+/ 
         raise ArgumentError , "%s is not a valid file path" % value 
      end 

Это тип значения, который указывает, куда поместить новый код, который будет получен. Здесь снова используйте ловушку validate для создания блока, который проверяет значение соответствия.

Вариант использования Subversion Provider

Давайте начнем с провайдера Subversion, используя созданный выше тип.

require 'fileutils' 
Puppet::Type.type(:repo).provide(:svn) do 
   desc "SVN Support"  
   
   commands :svncmd => "svn" 
   commands :svnadmin => "svnadmin"  
   
   def create 
      svncmd "checkout", resource[:name], resource[:path] 
   end  
   
   def destroy 
      FileUtils.rm_rf resource[:path] 
   end  
    
   def exists? 
      File.directory? resource[:path] 
   end 
end

В приведенном выше коде мы заранее определили, что нам нужна библиотека fileutils , для которой требуется ‘fileutils’, с которой мы собираемся использовать метод.

Далее мы определили провайдера как блок Puppet :: Type.type (: repo) .provide (: svn) do, который сообщает Puppet, что это провайдер для типа с именем repo.

Затем мы добавили desc, который позволяет добавить некоторую документацию к провайдеру. Мы также определили команду, которую будет использовать этот поставщик. В следующей строке мы проверяем функции ресурса, такие как создание, удаление и существование.

Создание ресурса

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

repo { "wp": 
   source => "http://g01063908.git.brcl.org/trunk/", 
   path => "/var/www/wp", 
   ensure => present, 
}

Puppet — RESTful API

Puppet использует RESTful API в качестве канала связи между мастером Puppet и агентами Puppet. Ниже приведен основной URL для доступа к этому RESTful API.

https://brcleprod001:8140/{environment}/{resource}/{key} 
https://brcleprod001:8139/{environment}/{resource}/{key}

REST API Security

Puppet обычно заботится о безопасности и управлении сертификатами SSL. Однако, если кто-то хочет использовать RESTful API вне кластера, необходимо самостоятельно управлять сертификатом при попытке подключения к машине. Политику безопасности для Puppet можно настроить с помощью файла rest authconfig.

Тестирование REST API

Утилита Curl может использоваться как базовая утилита для подключения к RESTful API. Ниже приведен пример того, как мы можем получить каталог узла с помощью команды curl REST API.

curl --cert /etc/puppet/ssl/certs/brcleprod001.pem --key 
   /etc/puppet/ssl/private_keys/brcleprod001.pem

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

curl --insecure -H 'Accept: yaml' 
https://brcleprod002:8140/production/catalog/brcleprod001 

В приведенной выше команде мы просто отправляем заголовок, указывающий формат или форматы, которые мы хотим вернуть, и URL-адрес RESTful для создания каталога brcleprod001 в производственной среде сгенерирует следующий вывод.

--- &id001 !ruby/object:Puppet::Resource::Catalog 
aliases: {} 
applying: false 
classes: [] 
...

Давайте рассмотрим другой пример, где мы хотим получить сертификат CA от мастера Puppet. Он не требует аутентификации с собственным подписанным SSL-сертификатом, так как это то, что требуется перед аутентификацией.

curl --insecure -H 'Accept: s' https://brcleprod001:8140/production/certificate/ca  

-----BEGIN CERTIFICATE----- 
MIICHTCCAYagAwIBAgIBATANBgkqhkiG9w0BAQUFADAXMRUwEwYDVQQDDAxwdXBw

Справка по Puppet Master и Agent Shared API

GET /certificate/{ca, other}  

curl -k -H "Accept: s" https://brcelprod001:8140/production/certificate/ca 
curl -k -H "Accept: s" https://brcleprod002:8139/production/certificate/brcleprod002 

Справочник по Puppet Master API

Аутентифицированные ресурсы (действительный, требуется подписанный сертификат).

Каталоги

GET /{environment}/catalog/{node certificate name} 

curl -k -H "Accept: pson" https://brcelprod001:8140/production/catalog/myclient

Список отзыва сертификатов

GET /certificate_revocation_list/ca 

curl -k -H "Accept: s" https://brcleprod001:8140/production/certificate/ca 

Запрос сертификата

GET /{environment}/certificate_requests/{anything} GET 
/{environment}/certificate_request/{node certificate name}  

curl -k -H "Accept: yaml" https://brcelprod001:8140/production/certificate_requests/all 
curl -k -H "Accept: yaml" https://brcleprod001:8140/production/certificate_request/puppetclient 

Отчеты Отправить отчет

PUT /{environment}/report/{node certificate name}  
curl -k -X PUT -H "Content-Type: text/yaml" -d "{key:value}" https://brcleprod002:8139/production

Узел — Факты, касающиеся конкретного узла

GET /{environment}/node/{node certificate name}  

curl -k -H "Accept: yaml" https://brcleprod002:8140/production/node/puppetclient 

Статус — используется для тестирования

GET /{environment}/status/{anything}  

curl -k -H "Accept: pson" https://brcleprod002:8140/production/certificate_request/puppetclient

Справочник по API агента Puppet

Когда новый агент настроен на любом компьютере, по умолчанию агент Puppet не прослушивает HTTP-запрос. Его нужно включить в Puppet, добавив «listen = true» в файл puppet.conf. Это позволит агентам Puppet прослушивать HTTP-запрос при запуске агента Puppet.

факты

GET /{environment}/facts/{anything}  

curl -k -H "Accept: yaml" https://brcelprod002:8139/production/facts/{anything}

Выполнить — заставляет клиента обновляться как puppetturn или puppet kick.

PUT  /{environment}/run/{node certificate name}  

curl -k -X PUT -H "Content-Type: text/pson" -d "{}" 
https://brcleprod002:8139/production/run/{anything}

Кукольный — живой проект

Чтобы выполнить живое тестирование применения конфигурации и манифестов на узле Puppet, мы будем использовать живую рабочую демонстрацию. Это можно напрямую скопировать и вставить, чтобы проверить, как работает конфигурация. Если пользователь желает использовать тот же набор кода, он должен иметь такое же соглашение об именах, как показано в фрагментах кода следующим образом.

Начнем с создания нового модуля.

Создание нового модуля

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

# cd /etc/puppet/modules 
# puppet module generate Live-module

Примечание. Команда создания модуля Puppet требует, чтобы имя модуля принимало формат [имя пользователя] — [модуль] для соответствия спецификациям Puppet Forge.

Новый модуль содержит несколько основных файлов, включая каталог манифеста. Каталог уже содержит манифест с именем init.pp, который является основным файлом манифеста модулей. Это пустое объявление класса для модуля.

class live-module { 
} 

Модуль также содержит тестовый каталог, содержащий манифест с именем init.pp. Этот тестовый манифест содержит ссылку на класс live-module в manifest / init.pp:

include live-module

Puppet будет использовать этот тестовый модуль для проверки манифеста. Теперь мы готовы добавить конфигурацию в модуль.

Установка HTTP-сервера

Модуль Puppet установит необходимые пакеты для запуска http-сервера. Это требует определения ресурса, который определяет конфигурацию пакетов httpd.

В каталоге манифеста модуля создайте новый файл манифеста с именем httpd.pp

# touch test-module/manifests/httpd.pp

Этот манифест будет содержать всю конфигурацию HTTP для нашего модуля. В целях разделения мы будем хранить файл httpd.pp отдельно от файла манифеста init.pp

Нам нужно поместить следующий код в файл манифеста httpd.pp.

class test-module::httpd { 
   package { 'httpd': 
      ensure => installed, 
   } 
}

Этот код определяет подкласс тест-модуля с именем httpd, а затем определяет объявление ресурса пакета для пакета httpd. Атрибут sure => selected проверяет, установлен ли требуемый пакет. Если он не установлен, Puppet использует утилиту yum для его установки. Далее следует включить этот подкласс в наш основной файл манифеста. Нам нужно отредактировать манифест init.pp.

class test-module { 
   include test-module::httpd 
}

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

# puppet apply test-module/tests/init.pp --noop

Команда puppet apply применяет конфигурацию, представленную в файле манифеста в целевой системе. Здесь мы используем тест init.pp, который ссылается на основной init.pp. –Noop выполняет пробный запуск конфигурации, которая показывает только выходные данные, но фактически ничего не делает.

Ниже приводится вывод.

Notice: Compiled catalog for puppet.example.com in environment 
production in 0.59 seconds 

Notice: /Stage[main]/test-module::Httpd/Package[httpd]/ensure: 
current_value absent, should be present (noop) 

Notice: Class[test-module::Httpd]: Would have triggered 'refresh' from 1 
events 

Notice: Stage[main]: Would have triggered 'refresh' from 1 events 
Notice: Finished catalog run in 0.67 seconds 

Выделенная строка является результатом установленного атрибута обеспечивает => установленный. Отсутствует current_value означает, что Puppet обнаружил, что пакет httpd установлен. Без опции –noop Puppet установит пакет httpd.

Запуск сервера httpd

После установки серверов httpd нам нужно запустить службу, используя замедление другого ресурса: Сервис

Нам нужно отредактировать файл манифеста httpd.pp и отредактировать следующее содержимое.

class test-module::httpd { 
   package { 'httpd': 
      ensure => installed, 
   } 
   service { 'httpd': 
      ensure => running, 
      enable => true, 
      require => Package["httpd"], 
   } 
}

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

• Состояние sure => проверяет, запущена ли служба, а если нет, то включает ее.

• Атрибут enable => true устанавливает службу для запуска при загрузке системы.

• Атрибут require => Package [«httpd»] определяет порядок упорядочения между одним замедлением ресурса и другим. В приведенном выше случае он гарантирует, что служба httpd запускается после установки пакета http. Это создает зависимость между службой и соответствующим пакетом.

Состояние sure => проверяет, запущена ли служба, а если нет, то включает ее.

Атрибут enable => true устанавливает службу для запуска при загрузке системы.

Атрибут require => Package [«httpd»] определяет порядок упорядочения между одним замедлением ресурса и другим. В приведенном выше случае он гарантирует, что служба httpd запускается после установки пакета http. Это создает зависимость между службой и соответствующим пакетом.

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

# puppet apply test-module/tests/init.pp --noop 
Notice: Compiled catalog for puppet.example.com in environment 
production in 0.56 seconds 

Notice: /Stage[main]/test-module::Httpd/Package[httpd]/ensure: 
current_value absent, should be present (noop) 

Notice: /Stage[main]/test-module::Httpd/Service[httpd]/ensure: 
current_value stopped, should be running (noop) 

Notice: Class[test-module::Httpd]: Would have triggered 'refresh' from 2 
events 

Notice: Stage[main]: Would have triggered 'refresh' from 1 events 
Notice: Finished catalog run in 0.41 seconds 

Настройка httpd сервера

После выполнения вышеуказанных шагов у нас будет установлен и включен HTTP-сервер. Следующий шаг — предоставить некоторую конфигурацию серверу. По умолчанию httpd предоставляет некоторые конфигурации по умолчанию в /etc/httpd/conf/httpd.conf, который предоставляет порт 80 веб-хоста. Мы добавим несколько дополнительных хостов, чтобы обеспечить некоторые пользовательские возможности для веб-хоста.

Шаблон будет использоваться для предоставления дополнительного порта, так как он требует ввода переменной. Мы создадим каталог с именем template и добавим файл с именем test-server.config.erb в нового директора и добавим следующий контент.

Listen <%= @httpd_port %> 
NameVirtualHost *:<% = @httpd_port %> 

<VirtualHost *:<% = @httpd_port %>> 
   DocumentRoot /var/www/testserver/ 
   ServerName <% = @fqdn %> 
   
   <Directory "/var/www/testserver/"> 
      Options All Indexes FollowSymLinks 
      Order allow,deny 
      Allow from all 
   </Directory> 
</VirtualHost>

Приведенный выше шаблон соответствует стандартному формату конфигурации сервера apache-tomcat. Единственное отличие — использование escape-символа Ruby для вставки переменных из модуля. У нас есть полное доменное имя, в котором хранится полное доменное имя системы. Это известно как системный факт .

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

class test-module::httpd { 
   package { 'httpd': 
      ensure => installed, 
   } 
   service { 'httpd': 
      ensure => running, 
      enable => true, 
      require => Package["httpd"], 
   } 
   file {'/etc/httpd/conf.d/testserver.conf': 
      notify => Service["httpd"], 
      ensure => file, 
      require => Package["httpd"], 
      content => template("test-module/testserver.conf.erb"), 
   } 
   file { "/var/www/myserver": 
      ensure => "directory", 
   } 
}

Это помогает в достижении следующих вещей —

• Это добавляет объявление файлового ресурса для файла конфигурации сервера (/etc/httpd/conf.d/test-server.conf). Содержимое этого файла представляет собой шаблон test-serverconf.erb, который был создан ранее. Мы также проверяем пакет httpd, установленный перед добавлением этого файла.

• Это добавляет второе объявление файлового ресурса, которое создает каталог (/ var / www / test-server) для веб-сервера.

• Затем мы добавляем связь между файлом конфигурации и службой https с помощью атрибута notify => Service [«httpd»] . Это проверяет, есть ли какие-либо изменения файла конфигурации. Если есть, то Puppet перезапускает сервис.

Это добавляет объявление файлового ресурса для файла конфигурации сервера (/etc/httpd/conf.d/test-server.conf). Содержимое этого файла представляет собой шаблон test-serverconf.erb, который был создан ранее. Мы также проверяем пакет httpd, установленный перед добавлением этого файла.

Это добавляет второе объявление файлового ресурса, которое создает каталог (/ var / www / test-server) для веб-сервера.

Затем мы добавляем связь между файлом конфигурации и службой https с помощью атрибута notify => Service [«httpd»] . Это проверяет, есть ли какие-либо изменения файла конфигурации. Если есть, то Puppet перезапускает сервис.

Далее следует включить httpd_port в основной файл манифеста. Для этого нам нужно завершить основной файл манифеста init.pp и включить следующий контент.

class test-module ( 
   $http_port = 80 
) { 
   include test-module::httpd 
}

Это устанавливает для порта httpd значение по умолчанию, равное 80. Далее необходимо выполнить команду Puppet apply.

Ниже будет вывод.

# puppet apply test-module/tests/init.pp --noop 
Warning: Config file /etc/puppet/hiera.yaml not found, using Hiera 
defaults 

Notice: Compiled catalog for puppet.example.com in environment 
production in 0.84 seconds 

Notice: /Stage[main]/test-module::Httpd/File[/var/www/myserver]/ensure: 
current_value absent, should be directory (noop) 

Notice: /Stage[main]/test-module::Httpd/Package[httpd]/ensure: 
current_value absent, should be present (noop) 

Notice: 
/Stage[main]/test-module::Httpd/File[/etc/httpd/conf.d/myserver.conf]/ensure: 
current_value absent, should be file (noop) 

Notice: /Stage[main]/test-module::Httpd/Service[httpd]/ensure: 
current_value stopped, should be running (noop) 

Notice: Class[test-module::Httpd]: Would have triggered 'refresh' from 4 
events 

Notice: Stage[main]: Would have triggered 'refresh' from 1 events 
Notice: Finished catalog run in 0.51 seconds 

Настройка брандмауэра

Для связи с сервером требуется открытый порт. Проблема в том, что в разных операционных системах используются разные методы управления брандмауэром. В случае Linux версии ниже 6 используют iptables, а версия 7 использует firewalld.

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

Для этого нам нужно добавить следующий фрагмент кода внутри класса testmodule :: http.

if $operatingsystemmajrelease <= 6 { 
   exec { 'iptables': 
      command => "iptables -I INPUT 1 -p tcp -m multiport --ports 
      ${httpd_port} -m comment --comment 'Custom HTTP Web Host' -j ACCEPT && 
      iptables-save > /etc/sysconfig/iptables", 
      path => "/sbin", 
      refreshonly => true, 
      subscribe => Package['httpd'], 
   } 
   service { 'iptables': 
      ensure => running, 
      enable => true, 
      hasrestart => true, 
      subscribe => Exec['iptables'], 
   } 
}  elsif $operatingsystemmajrelease == 7 { 
   exec { 'firewall-cmd': 
      command => "firewall-cmd --zone=public --addport = $ { 
      httpd_port}/tcp --permanent", 
      path => "/usr/bin/", 
      refreshonly => true, 
      subscribe => Package['httpd'], 
   } 
   service { 'firewalld': 
      ensure => running, 
      enable => true, 
      hasrestart => true, 
      subscribe => Exec['firewall-cmd'], 
   } 
} 

Приведенный выше код выполняет следующее:

• Используя операционную систему, можно определить, является ли используемая ОС версии 6 или 7.

• Если версия 6, то он запускает все необходимые команды конфигурации для настройки версии Linux 6.

• Если версия ОС 7, тогда она запускает все необходимые команды, необходимые для настройки брандмауэра.

• Фрагмент кода для обеих ОС содержит логику, которая обеспечивает запуск конфигурации только после установки пакета http.

Используя операционную систему, можно определить, является ли используемая ОС версии 6 или 7.

Если версия 6, то он запускает все необходимые команды конфигурации для настройки версии Linux 6.

Если версия ОС 7, тогда она запускает все необходимые команды, необходимые для настройки брандмауэра.

Фрагмент кода для обеих ОС содержит логику, которая обеспечивает запуск конфигурации только после установки пакета http.

Наконец, запустите команду Puppet apply.

# puppet apply test-module/tests/init.pp --noop 
Warning: Config file /etc/puppet/hiera.yaml not found, using Hiera 
defaults 

Notice: Compiled catalog for puppet.example.com in environment 
production in 0.82 seconds 

Notice: /Stage[main]/test-module::Httpd/Exec[iptables]/returns: 
current_value notrun, should be 0 (noop) 

Notice: /Stage[main]/test-module::Httpd/Service[iptables]: Would have 
triggered 'refresh' from 1 events 

Конфигурирование SELinux

Поскольку мы работаем на машине с Linux версии 7 и выше, следовательно, нам необходимо настроить ее для установления http-связи. По умолчанию SELinux ограничивает нестандартный доступ к HTTP-серверу. Если мы определяем пользовательский порт, то нам нужно настроить SELinux для предоставления доступа к этому порту.

Puppet содержит некоторый тип ресурса для управления функциями SELinux, например, логические значения и модули. Здесь нам нужно выполнить команду semanage для управления настройками порта. Этот инструмент является частью пакета policycoreutils-python, который по умолчанию не установлен на серверах Red Hat. Для достижения вышесказанного нам нужно добавить следующий код внутри класса test-module :: http.

exec { 'semanage-port': 
   command => "semanage port -a -t http_port_t -p tcp ${httpd_port}", 
   path => "/usr/sbin", 
   require => Package['policycoreutils-python'], 
   before => Service ['httpd'], 
   subscribe => Package['httpd'], 
   refreshonly => true, 
} 

package { 'policycoreutils-python': 
   ensure => installed, 
} 

Приведенный выше код выполняет следующее:

• Пакет require => Package [‘policycoreutils-python’] гарантирует, что у нас установлен необходимый модуль python.

• Puppet использует semanage, чтобы открыть порт, используя httpd_port в качестве проверяемого.

• Служба before => гарантирует выполнение этой команды до запуска службы httpd. Если HTTPD запускается до команды SELinux, то SELinux запрос на обслуживание и запрос на обслуживание завершаются неудачно.

Пакет require => Package [‘policycoreutils-python’] гарантирует, что у нас установлен необходимый модуль python.

Puppet использует semanage, чтобы открыть порт, используя httpd_port в качестве проверяемого.

Служба before => гарантирует выполнение этой команды до запуска службы httpd. Если HTTPD запускается до команды SELinux, то SELinux запрос на обслуживание и запрос на обслуживание завершаются неудачно.

Наконец, запустите команду Puppet apply

# puppet apply test-module/tests/init.pp --noop 
... 
Notice: /Stage[main]/test-module::Httpd/Package[policycoreutilspython]/ 
ensure: current_value absent, should be present (noop) 
...
Notice: /Stage[main]/test-module::Httpd/Exec[semanage-port]/returns: 
current_value notrun, should be 0 (noop) 
... 
Notice: /Stage[main]/test-module::Httpd/Service[httpd]/ensure: 
current_value stopped, should be running (noop) 

Puppet сначала устанавливает модуль python, затем настраивает доступ к порту и, наконец, запускает службу httpd.

Копирование файлов HTML на веб-хосте

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

Создайте файл index.html внутри каталога файлов.

<html> 
   <head> 
      <title>Congratulations</title> 
   <head> 
   
   <body> 
      <h1>Congratulations</h1> 
      <p>Your puppet module has correctly applied your configuration.</p> 
   </body> 
</html> 

Создайте манифест app.pp внутри директории манифеста и добавьте следующее содержимое.

class test-module::app { 
   file { "/var/www/test-server/index.html": 
      ensure => file, 
      mode => 755, 
      owner => root, 
      group => root, 
      source => "puppet:///modules/test-module/index.html", 
      require => Class["test-module::httpd"], 
   } 
}

Этот новый класс содержит одно замедление ресурса. Это копирует файл из файлового каталога модуля на веб-сервер и устанавливает его разрешения. Обязательный атрибут гарантирует, что класс test-module :: http успешно завершит настройку, прежде чем кто-либо применяет test-module :: app.

Наконец, нам нужно включить новый манифест в наш основной init.pp манифест.

class test-module ( 
   $http_port = 80 
) { 
   include test-module::httpd 
   include test-module::app 
} 

Теперь запустите команду apply, чтобы фактически проверить, что происходит. Ниже будет вывод.

# puppet apply test-module/tests/init.pp --noop
Warning: Config file /etc/puppet/hiera.yaml not found, using Hiera 
defaults 

Notice: Compiled catalog for brcelprod001.brcle.com in environment 
production in 0.66 seconds 

Notice: /Stage[main]/Test-module::Httpd/Exec[iptables]/returns: 
current_value notrun, should be 0 (noop) 

Notice: /Stage[main]/Test-module::Httpd/Package[policycoreutilspython]/ 
ensure: current_value absent, should be present (noop) 

Notice: /Stage[main]/Test-module::Httpd/Service[iptables]: Would have 
triggered 'refresh' from 1 events 

Notice: /Stage[main]/Test-module::Httpd/File[/var/www/myserver]/ensure: 
current_value absent, should be directory (noop) 

Notice: /Stage[main]/Test-module::Httpd/Package[httpd]/ensure: 
current_value absent, should be present (noop) 

Notice: 
/Stage[main]/Test-module::Httpd/File[/etc/httpd/conf.d/myserver.conf]/ensur 
e: current_value absent, should be file (noop) 

Notice: /Stage[main]/Test-module::Httpd/Exec[semanage-port]/returns: 
current_value notrun, should be 0 (noop) 

Notice: /Stage[main]/Test-module::Httpd/Service[httpd]/ensure: 
current_value stopped, should be running (noop) 

Notice: Class[test-module::Httpd]: Would have triggered 'refresh' from 8 
Notice: 
/Stage[main]/test-module::App/File[/var/www/myserver/index.html]/ensur: 
current_value absent, should be file (noop) 

Notice: Class[test-module::App]: Would have triggered 'refresh' from 1 
Notice: Stage[main]: Would have triggered 'refresh' from 2 events Notice: 
Finished catalog run in 0.74 seconds

Выделенная строка показывает результат копирования файла index.html на веб-хост.

Завершение модуля

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