Puppet

Написание манифеста

Потренироваться писать манифесты, модули и классы Puppet можно на примере установки стека LAMP на сервер Ubuntu (в результате получится ).

Итак, чтобы выполнить оркестровку сервера Ubuntu 14.04 и установить на него стек LAMP, нужны ресурсы для таких действий:

  • установка пакета apache2.
  • запуск сервиса apache2.
  • установка пакета сервера MySQL, mysql-server.
  • запуск сервиса mysql.
  • установка пакета php5
  • создание тестового сценария PHP, info.php.
  • обновление индекса apt перед установкой каждого пакета.

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

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

Примечание
: Для тестирования лучше использовать свежий виртуальный сервер.

Начало работы с Puppet

Данный раздел научит вас выполнять базовые операции Puppet.

Сбор фактов

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

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

Чтобы просмотреть список фактов по умолчанию, введите:

Главный манифест

Для описания конфигурации системы Puppet использует предметно-ориентированный язык, а эти описания сохраняет в так называемых манифестах (файлы с расширением .pp).

Главный манифест по умолчанию находится на мастере Puppet в /etc/puppetlabs/code/environments/production/manifests/site.pp. Замените этот файл:

Обратите внимание: на данный момент главный манифест пуст

Выполнение главного манифеста

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

Немедленная проверка агента

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

Эта команда сверит текущие настройки агента с главным манифестом и вернёт примерно такой вывод:

Разовые манифесты

Команда puppet apply позволяет выполнять манифесты, которые не имеют отношения к главному манифесту. Они применяются только к тому агенту, на котором была запущена команда. Например:

Это позволяет протестировать    новый манифест на одной ноде.

Foreman + Puppet

Открыть в браузере ссылку https://master.astra.lan (подтвердить согласие на подключение)

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

Если узлы отсутствуют, то подождать, пока информация обновится, или на нужных узлах (на клиенте) выполнить команду:

sudo systemctl restart puppet

После чего обновить страницу web-интерфейса.

Убедиться, что в  «Инфраструктура» — «Капсулы» ( в английском варианте «Infrastructure» -> «Smart Proxies») имеется отображение созданного по умолчанию proxy. Если proxy не создан, то:

  • Перейти в «Администратор» — «Местоположения» («Administer» — «Locations»);
    • Выбрать Default location;
    • Нажать кнопку «Устранить несоответствия» («Fix mismatches»);
    • Нажать кнопку «Применить» («Submit»);
  • Аналогично «Администратор» — «Организации» («Administer» — «Organizations»);
    • Выбрать Default organization;
    • Нажать кнопку «Устранить несоответствия» («Fix mismatches»);
  • Нажать кнопку «Применить» («Submit»);

После выполнения этих шагов в  «Инфраструктура» — «Капсулы» ( в английском варианте «Infrastructure» -> «Smart Proxies») появится отображение созданного по умолчанию proxy.

Начало работы с Puppet

Данный раздел научит вас выполнять базовые операции Puppet.

Сбор фактов

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

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

Чтобы просмотреть список фактов по умолчанию, введите:

Главный манифест

Для описания конфигурации системы Puppet использует предметно-ориентированный язык, а эти описания сохраняет в так называемых манифестах (файлы с расширением .pp).

Главный манифест по умолчанию находится на мастере Puppet в /etc/puppetlabs/code/environments/production/manifests/site.pp. Замените этот файл:

Обратите внимание: на данный момент главный манифест пуст

Выполнение главного манифеста

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

Немедленная проверка агента

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

Эта команда сверит текущие настройки агента с главным манифестом и вернёт примерно такой вывод:

Разовые манифесты

Команда puppet apply позволяет выполнять манифесты, которые не имеют отношения к главному манифесту. Они применяются только к тому агенту, на котором была запущена команда. Например:

Это позволяет протестировать    новый манифест на одной ноде.

Пример манифеста

Откройте главный манифест. Перейдите на мастер и запустите:

Добавьте в него описание ресурса file:

Сохраните и закройте файл.

Этот ресурс создаёт на всех нодах файл /tmp/example-ip с правами -rw-r–r– и добавляет в него внешний IP-адрес ноды.

Вы можете подождать, пока ноды проверят конфигурации на мастере, а можете инициировать проверку одной из нод  вручную с помощью команды puppet agent –test.

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

На экране появится:

Объявление ноды

Чтобы определить ресурс для конкретных нод, добавьте в манифест node.

Отредактируйте site.pp на мастере:

Добавьте в файл:

Сохраните и закройте файл.

Теперь файл /tmp/dns будет создан на ns1 и ns2. Вы можете запустить тестирование этих нод с помощью puppet agent –test.

Если вы удалите ресурсы из манифеста, то созданные ранее файлы всё равно останутся. Чтобы Puppet удалял созданные файлы, замените ensure на absent.

Работа с модулями

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

Попробуйте установить модуль puppetlabs-apache:

Важно! Не используйте этот модуль, если Apache уже установлен. Это повредит все настройки Apache, за которые не отвечает Puppet

Отредактируйте  site.pp:

Добавьте в файл следующий код, чтобы установить Apache на host2:

Сохраните и закройте файл. Во время следующей проверки конфигураций host2 Puppet установит пакет Apache, создаст виртуальный хост example.com, прослушивающий порт 80, и добавит корневой каталог /var/www/html.

Запустите команду на host2:

После выполнения команды попробуйте открыть IP-адрес host2 в браузере. На экране должна появиться страница Apache.

Манифесты[править]

Их иногда называют рецептами, представляют собой текстовые файлы с расширением .pp (По умолчанию выполняется $confdir/manifests/site.pp). В манифесте могут и должны содержаться:

  • Классы (class)
  • Узлы (node)
  • Ресурсы (то есть типы file, user и др.)
  • Ссылки на другие манифесты (import)

Встроенные переменныеправить

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

  • $operatingsystem — операционная система.
  • $fqdn — полное доменное имя.
  • $hostname — имя хоста.
  • $ipaddress — IP адрес.
  • $osfamily — семейство операционных систем.
  • $is_virtual — запущена ли ОС в виртуальной машине.

Гид по языкуправить

Условие

if condition {
  block of code
}
elsif condition {
  block of code
}
else {
  block of code
}

Перечисление

case $operatingsystem {
      centos, redhat { $apache = "httpd" }
      debian, ubuntu { $apache = "apache2" }
      default { fail("Unrecognized operating system for webserver") }
}

Выбор

$apache = $operatingsystem ? {
      centos                => 'httpd',
      redhat                => 'httpd',
      /(?i)(ubuntu|debian)/ => "apache2",
      default               => undef,
}

Атрибуты по умолчанию

Exec { path => '/usr/bin:/bin:/usr/sbin:/sbin' }
exec { 'echo this works' }

Классыправить

Наследование классов

class unix {
      file { '/etc/passwd'
            owner => 'root',
            group => 'root',
            mode  => '0644',
      }
      file { '/etc/shadow'
            owner => 'root',
            group => 'root',
            mode  => '0440',
      }
}
class freebsd inherits unix {
      File'/etc/passwd', '/etc/shadow' { group => 'wheel', owner => undef }
}

При вызове класса freebsd для файлов атрибут group изменится на wheel, а вот атрибут owner не будет проверяться вообще.
Значение атрибутов можно не заменять а добавлять:

class apache {
      service { 'apache' require => Package'httpd' }
}
class apache-ssl inherits apache {
      # host certificate is required for SSL to function
      Service'apache' { require +> File'apache.pem' }
}

Зависимости между классами

class apache {
      service { 'apache' require => Class'squid' }
}

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

class myservice {
      service { foo ensure => running }
}
class otherstuff {
      include myservice
      file { '/foo' notify => Servicefoo }
}

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

class apache($version , $home = '/var/www') {
      # Содержимое класса
}
node webserver {
      class { 'apache' version => '1.3.13' }
}

Использование команды в числовом виде

Права записываются одной строкой сразу для трёх типов пользователей:

  • владельца файла (u);
  • других пользователей, входящих в группу владельца (g);
  • всех прочих пользователей (o);

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

Пример: в числовом виде, установить права rwx-rx-rx:

chmod 755 filename

Пример — значение права «755»

Владелец Группа Остальные
восьмеричное значение 7 5 5
символьная запись rwx r-x r-x
обозначение типа пользователя u g o

Таким образом, права «755» записываются в символьном виде как «rwxr-xr-x». При этом для понимания сути задания прав в Unix-системах полезно знать представление чисел в двоичной системе счисления.

Варианты записи прав пользователя

двоичная восьмеричная символьная права на файл права на директорию
000 нет нет
001 1 —x выполнение чтение файлов и их свойств
010 2 -w- запись нет
011 3 -wx запись и выполнение всё, кроме чтения списка файлов
100 4 r— чтение чтение имён файлов
101 5 r-x чтение и выполнение доступ на чтение
110 6 rw- чтение и запись чтение имён файлов
111 7 rwx все права все права

Часть разрешений имеет смысл только в сочетании с другими. Из первых четырёх пунктов (не дающих права на чтение файла) для файлов обычно используется только «—», то есть полный запрет доступа к файлу данному типу пользователей. Для директорий из всего списка обычно применяются только 0, 5 и 7 — запрет, чтение и выполнение, и полный доступ.

Суммировав эти коды для трёх типов пользователей, можно получить числовую или символьную запись. Например, chmod 444 {имяфайла}: 400+40+4=444 — все имеют право только на чтение (идентично «r—r—r—»).

Помимо стандартных разрешений ‘rwx’, команда chmod осуществляет также управление битами SGID, SUID и T. Установленные атрибуты SUID или SGID позволяют запускать файл на выполнение с правами владельца файла или группы соответственно.

Для SUID вес — 4000, а для SGID — 2000. Данные атрибуты имеют смысл при установленном соответствующем бите исполнения и обозначаются при символьной записи буквой «s»: и соответственно.

Пример: chmod 4555 {имяфайла} — все имеют право на чтение и выполнение, но запускаться файл на исполнение будет с правами владельца.

Установка SGID для директории приведёт к установке принадлежности каждого нового создаваемого файла к той же группе, к которой принадлежит сама директория, а не к основной группе владельца, как это происходит по умолчанию. SUID для директории не имеет смысла.
sticky bit или restricted deletion flag (t-бит) используется только с директориями. Когда t-бит для директории не установлен, файл в данной директории может удалить (переименовать) любой пользователь, имеющий доступ на запись к данному файлу. Устанавливая t-бит на директорию, мы меняем это правило таким образом, что удалить (переименовать) файл может только владелец этого файла. Следуя приведённой выше кодировке, t-бит имеет вес 1000.

Примечание: Право на запись (w) даёт пользователю возможность записывать или изменять файл, а право на запись для каталога — возможность создавать новые файлы или удалять файлы из этого каталога. Если на каталоге стоит возможность записи (w), то файл внутри этого каталога можно будет удалить, даже если право на запись для него не установлено. (В соответствии с концепцией файловой системы POSIX).

Популярные значения

— Владелец имеет право чтения; никто другой не имеет права выполнять никакие действия — Все пользователи имеют право чтения; владелец может редактировать — Владелец и группа могут читать и редактировать; остальные не имеют права выполнять никаких действий — Все пользователи имеют право чтения; владелец и группа могут редактировать — Все пользователи могут читать и редактировать — Владелец может читать, записывать и запускать на выполнение; никто другой не имеет права выполнять никакие действия — Каждый пользователь может читать, владелец имеет право редактировать и запускать на выполнение — Каждый пользователь имеет право читать и запускать на выполнение; владелец может редактировать — Каждый пользователь может читать, редактировать и запускать на выполнение — Каждый пользователь имеет право читать и запускать на выполнение; удалить файл может только владелец этого файла — Каждый пользователь имеет право читать и запускать на выполнение с правами группы(user group) владельца файла — Владелец и группа имеет право чтения никто другой не имеет права выполнять никакие действия — Каждый пользователь имеет право читать и запускать на выполнение с правами владельца файла

Step 1 — Configuring /etc/hosts

Puppet master servers and the nodes they manage need to be able to communicate with each other. In most situations, this will be accomplished using DNS, either configured on an externally hosted service or on self-hosted DNS servers maintained as part of the infrastructure.

DNS is its own domain of expertise, however, even on hosted services, so in order to focus on the fundamentals of Puppet itself and eliminate potential complexity in troubleshooting while we’re learning, in this tutorial we’ll use the file instead.

On every machine

On each machine, edit the file. At the end of the file, specify the Puppet master server as follows, substituting the IP address for your Puppet master:

/etc/hosts

When you’re done, save and exit.

Note: By default, Puppet agents will look for the Puppet master at to make it easier to get Puppet set up. This means we must use the name in . If does not resolve to the Puppet master, the agents will not be able to make contact without .

Пример 1: Установка LAMP с помощью одного манифеста

Манифест Puppet можно написать на агентской ноде, а затем выполнить его с помощью команды puppet apply (для этого не нужно иметь установку из мастера и агента).

В данном разделе вы научитесь писать манифесты, которые будут использовать такие типы объявления ресурсов:

  • exec: выполнение команд.
  • package: установка пакетов.
  • service: управление сервисами.
  • file: управление файлами.

Создание манифеста

Создайте новый манифест:

sudo vi /etc/puppet/manifests/lamp.pp

Добавьте в него следующий код, чтобы объявить необходимые ресурсы.

# запуск команды «apt-get update»
exec { «apt-update»: # ресурс exec «apt-update»
command => «/usr/bin/apt-get update» # команда, которую запустит этот ресурс
}
# установка пакета apache2
package { «apache2»:
require => Exec, # запрос «apt-update» перед установкой пакета
ensure => installed,
}
# запуск сервиса apache2
service { «apache2»:
ensure => running,
}
# установка mysql-server
package { «mysql-server»:
require => Exec, # запрос «apt-update» передустановкой
ensure => installed,
}
# запуск сервиса mysql
service { «mysql»:
ensure => running,
}
# установка пакета php5
package { «php5»:
require => Exec, # запрос «apt-update» перед установкой
ensure => installed,
}
# запуск сервиса info.php
file { «/var/www/html/info.php»:
ensure => file,
content => «<?php phpinfo(); ?>», # код phpinfo
require => Package, # запрос пакета «apache2»
}

Применение манифеста

Чтобы использовать новый манифест, введите команду:

sudo puppet apply —test

Она выведет объёмный результат, который отображает все изменения состояния среды. Если в выводе нет ошибок, вы сможете открыть свой внешний IP-адрес или доменное имя в браузере. На экране появится тестовая страница PHP с информацией о стеке. Это значит, что Apache и PHP работают.

Теперь стек LAMP установлен на сервер с помощью Puppet.

Это довольно простой манифест, поскольку его можно выполнить на агенте. Если у вас нет мастера Puppet, другие агентские ноды не смогут использовать этот манифест.

Мастер-сервер Puppet проверяет изменения состояния сервера каждые 30 минут.

класс cfpuppetserver

  • — имя пользователя для автоматического развёртывания обновлений конфигурации
  • — список ключей для $deployuser
  • — URI репозитория (пример: ssh://user@host/repo или file:///some/path)
  • — устанавливать ли компонент Puppet Server на данный узел
  • — устанавливать ли компонент PuppetDB на данный узел
  • — порт для PuppetDB
  • — устанавливать ли компонент PostgreSQL на данный узел (только если включена установка PuppetDB)
  • — название ресурса для принятия входящих соединений
  • — оперативная память под Puppet Server в мегайбатах (минимум 192MB)
  • — оперативная память под PuppetDB в мегайбатах (минимум 192MB)
  • — оперативная память под PostgreSQL в мегайбатах (минимум 128MB)

Step 4 — Signing Certificates on Puppet Master

The first time Puppet runs on an agent node, it sends a certificate signing request to the Puppet master. Before Puppet Server will be able to communicate with and control the agent node, it must sign that particular agent node’s certificate.

List current certificate requests

To list all unsigned certificate requests, run the following command on the Puppet master:

There should be one request for each host you set up, that looks something like the following:

A in front of a certificate indicates it has been signed. The absence of a plus sign indicates our new certificate has not been signed yet.

Sign requests

To sign a single certificate request, use the command, with the hostname of the certificate as it is displayed in the certificate request.

For example, to sign db1’s certificate, you would use the following command:

Output similar to the example below indicates that the certificate request has been signed:

The Puppet master can now communicate and control the node that the signed certificate belongs to. You can also sign all current requests at once.

We’ll use the option to sign the remaining certificate:

Now that all of the certificates are signed, Puppet can manage the infrastructure. You can learn more about managing certificates in the How to Manage Puppet 4 Certificates cheat sheet.

Step 5 — Verifying the Installation

Puppet uses a domain-specific language to describe system configurations, and these descriptions are saved to files called “manifests”, which have a file extension. You can learn more about these in the Getting Started with Puppet Code: Manifests and Modules guide, but for now we’ll create a brief directive to verify that the Puppet Server can manage the Agents as expected.

We’ll begin by creating the default manifest, , in the default location:

We’ll use Puppet’s domain-specific language to create a file called on agent nodes located in the directory which contains the public IP address of the agent server and sets the permissions to:

site.pp example

By default Puppet Server runs the commands in its manifests by default every 30 minutes. If the file is removed, the directive will cause it to be recreated. The directive will set the file permissions, and the directive add content to the directive.

We can also test the manifest on a single node using . Note that is not a flag for a dry run; if it’s successful, it will change the agent’s configuration.

Rather than waiting for the Puppet master to apply the changes, we’ll apply the manifest now on :

The output should look something like:

When it’s done, we’ll check the file contents:

Repeat this for or, if you prefer, check back in half an hour or so to verify that the Puppet master is running automatically.

Note: You can check the log file on the Puppet master to see when Puppet last compiled the catalog for an agent, which indicates that any changes required should have been applied.

Congratulations! You’ve successfully installed Puppet in Master/Agent mode.

Installing a package from a specific source

We can install packages from different repositories in Debian or Redhat based machines. We can specify from what source we can install the software.

class testmodule {
package {'apache2':
ensure => 'present',
provider => 'apt',
install_options => ,
}

}

In our next tutorial, we will see how to deal with files and folders in Puppet.

Post Views: 27,973

The following two tabs change content below.

Mr Surendra Anne is from Vijayawada, Andhra Pradesh, India. He is a Linux/Open source supporter who believes in Hard work, A down to earth person, Likes to share knowledge with others, Loves dogs, Likes photography. He works as Devops Engineer with Taggle systems, an IOT automatic water metering company, Sydney . You can contact him at surendra (@) linuxnix dot com.

Latest posts by Surendra Anne

  • Docker: How to copy files to/from docker container — June 30, 2020
  • Anisble: ERROR! unexpected parameter type in action: Fix — June 29, 2020
  • FREE: JOIN OUR DEVOPS TELEGRAM GROUPS — August 2, 2019
  • Review: Whizlabs Practice Tests for AWS Certified Solutions Architect Professional (CSAP) — August 27, 2018
  • How to use ohai/chef-shell to get node attributes — July 19, 2018

Мастер-сервер Puppet

Настройка NTP

Мастер-сервер Puppet должен показывать правильное время, потому что он является ведущим сервером инфраструктуры, и во многом правильность настройки нод зависит от него. Для этого используйте NTP (Network Time Protocol).

Просмотрите доступные часовые пояса:

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

Примечание: Не забудьте заменить условные данные своими.

Установите NTP:

Синхронизируйте время с помощью команды ntpdate:

Конфигурации NTP часто обновляют для поддержки пулов, которые географически ближе к NTP- серверу данного VPS. Откройте браузер и перейдите на NTP Pool Project. Выберите ближайший к вашему датацентру пул. В руководстве используется пул United States.

Откройте ntp.conf:

Добавьте серверы со страницы сайта NTP в начало файла, например:

Сохраните и закройте файл.

Перезапустите NTP:

Включите демон NTP:

Установка Puppet Server

Puppet Server – это программное обеспечение мастер-сервера Puppet.

Именно этот компонент передаёт настройки на ноды.

Включите официальный репозиторий Puppet Labs:

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

Настройка распределения памяти (опционально)

По умолчанию мастер Puppet использует 2 GB RAM. Этот параметр нужно настроить, учитывая объём свободной памяти мастер-сервера и количество нод в инфраструктуре.

Откройте /etc/sysconfig/puppetserver:

Найдите строку JAVA_ARGS. Чтобы установить распределение памяти, используйте параметры -Xms и –Xmx. К примеру, чтобы установить 3 GB памяти, нужно изменить строку так:

Сохраните и закройте файл.

Запуск Puppet Server

Запустите Puppet Server:

Включите сервис Puppet Server, чтобы программа автоматически загружалась вместе с сервером.

Puppet Server работает, но пока не управляет нодами.

Environments[править]

Окружения (environments) нужны для полного разделения конфигураций. У каждого окружения свои модули и манифесты. Это можно сравнить с использованием разных серверов puppet master.

Историяправить

  • До версии 3.5 для указания окружений использовались только переменные manifest и modulepath («config file environments», в противоположность «directory environments», которые появились в версии 3.5)
  • С версии 3.6 «config file environments» устарели .
  • В версии 3.7 «directory environments» включены по умолчанию в Puppet Enterprise, но не в Open Source.
  • С версии 4.0 в случае неиспользования окружений будет выдаваться предупреждение.

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

Именованиеправить

Имя окружения должно состоять из строчных букв, цифр и подчёркивания, начинаться с буквы. Нельзя использовать main, master, agent, user . Пример имён окружений: production и testing.

Подключениеправить

В версиях 3.5, 3.6, 3.7 Open Source, 3.8 для использования «directory environments» прописываем в секцию или файла /etc/puppet/puppet.conf:

environmentpath = $confdir/environments

В более новых версиях указывать ничего не нужно.

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

environment = testing

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

После подключения, используются манифесты из каталога окружения, например, /etc/puppet/environments/production/manifests/.

В манифестах можно использовать переменную $environment с именем текущего окружения.

Рейтинг
( Пока оценок нет )
Понравилась статья? Поделиться с друзьями:
Мой редактор ОС
Добавить комментарий

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: