🐹 Puppet 3. Часть 1: Установка, настройка, начало эксплуатации.

Содержание:

1. Введение.
2. Что такое Puppet?

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

3. Знакомство с манифестами.
4. Подготовка инфраструктуры.
5. Первые шаги на серверах.

5.1. Как временно или навсегда отключить SELinux.
5.2. Настройка часового пояса и синхронизации времени.
5.3. Первичная настройка брандмауэра.

6. Настройка Puppet master сервера.
7. Настройка Puppet node / Puppet client (агентов).
8. Тестирование работы системы Puppet.

8.1. Тестирование автономной архитектуры — Puppet apply.
8.2. Описание ноды и ресурса на ней.
8.3. Взаимосвязи ресурсов на ноде.

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

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

10. Как узнать версию Puppet.
11. Полезные команды.

11.1. Проверка текущих параметров.
11.2. Проверка состояния сертификатов.

12. Готовые конфигурации из репозиториев.
13. Примеры манифестов.
14. Оригиналы источников информации.


Данная статья — это часть цикла статей по эксплуатации системы управления конфигурацией — Puppet 3:

  1. Часть I: статья «Установка, настройка, начало эксплуатации». <— Вы здесь!
  2. Часть II: статья «Манифесты, синтаксис, команды».

На чем было опробовано:

  1. CentOS Linux release 7.9.2009 (Core).
  2. Puppet 3.8.7 (master+agent).

1. Введение.

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

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

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

# servers.sh
servers="server00 server01 server02 server03 server04"
for server in $servers ; do
   scp /path/to/job/file/job.sh $server:/tmp/job.sh
   ssh $server sh /tmp/job.sh
done
# job.sh
#!/bin/bash
apt-get update
apt-get install nginx
service nginx start

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

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

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

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

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

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

# nginx.pp

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

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

2. Что такое Puppet?

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

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

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

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

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

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

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

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

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

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

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

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

3. Знакомство с манифестами.

В терминологии Puppet к Puppet master подключаются ноды — Puppet nodes. Конфигурация для нод пишется в манифестах на специальном языке программирования — Puppet DSL.

Puppet DSL — декларативный язык. На нём описывается желаемое состояние ноды в виде объявления отдельных ресурсов, например:

  • Файл существует, и у него определённое содержимое.
  • Пакет установлен.
  • Сервис запущен.

Ресурсы могут быть взаимосвязаны:

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

Кроме того, в Puppet DSL есть функции и переменные, а также условные операторы и селекторы.

Puppet поддерживает шаблоны в формате EPP и ERB :

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

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

Каталог — это список ресурсов и их взаимосвязей после вычисления значения функций, переменных и раскрытия условных операторов.

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

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

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

Puppet master

Puppet clients

Operating system: CentOS 7 minimal

IP Address: 192.168.0.17
HostName: puppet-srv.hamsterden.locm

Operating system: CentOS 7 minimal

IP Address: 192.168.0.14
HostName: puppet-cl14.hamsterden.loc

IP Address: 192.168.0.15
HostName: puppet-cl15.hamsterden.loc

IP Address: 192.168.0.16
HostName: puppet-cl16.hamsterden.loc

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

# firewall-cmd --reload

Ответы:

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

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

# yum install -y mc

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

# mcedit /etc/hosts

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

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

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

# mcedit /etc/hostname

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

puppet-srv.hamsterden.loc

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

# rpm -ivh http://yum.puppetlabs.com/puppetlabs-release-el-7.noarch.rpm

Устанавливаем Puppet:

# yum install -y puppet-server

Разрешаем автозапуск puppet-сервера:

# systemctl enable puppetmaster.service

По умолчанию, Puppet настроен для оптимальной работы.

Единственное, что мы сделаем, включим автоматическое подтверждение сертификатов от клиентов:

# mcedit /etc/puppet/puppet.conf

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

[main]
…
autosign = true
…

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

Для этого отредактируем основной манифест-файл:

# mcedit /etc/puppet/manifests/site.pp

Добавим в содержимое файла:

import 'nodes/*.pp'

Данная строчка означает, что мы будем подгружать все файлы с расширением *.pp из каталога /etc/puppet/manifests/nodes.

Создаем каталог nodes:

# mkdir -p /etc/puppet/manifests/nodes

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

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

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

file { "/tmp/hello-file":
   replace => "no",
   owner => "root",
   group => "wheel",
   ensure => "present",
   content => "From Puppet\n",
   mode => 0644,
}

Правило создаст файл hello-file, если его нет, в каталоге /tmp. Задаст ему владельца root и группу-владельца wheel. Добавит в него текст «From Puppet» и задаст права 0644.

Запускаем службу Puppet:

# systemctl start puppetmaster.service

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

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

# sudo su

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

# yum update && yum upgrade

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

# yum install -y mc

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

# mcedit /etc/hosts

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

192.168.0.17 puppet-srv.hamsterden.loc

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

# mcedit /etc/hostname

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

puppet-cl14.hamsterden.loc

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

# systemctl restart systemd-hostnamed

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

# hostnamectl status

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

# rpm -ivh http://yum.puppetlabs.com/puppetlabs-release-el-7.noarch.rpm

Устанавливаем Puppet:

# yum install -y puppet

Редактируем конфигурационный файл Puppet:

# mcedit /etc/puppet/puppet.conf

Просто добавьте эти строки по аналогии в соответствующий раздел файла:

[agent]
...
server=puppet-srv.hamsterden.loc
certname=puppet-cl14.hamsterden.loc
...

Запускаем Puppet:

# systemctl start puppet.service

Проверяем подключение клиента puppet-cl14.hamsterden.loc к серверу puppet-srv.hamsterden.loc:

# puppet agent --server=puppet-srv.hamsterden.loc --test --debug

Если вы все правильно настроили, результатом выполнения данной команды будет создание файла /tmp/hello-file.

Проверяем на клиенте сработало ли правило с мастера?

Должен быть создан файл hello-file, в каталоге /tmp, с владельцем root и группой-владельца wheel. Внутри файла должен быть текст «From Puppet» и заданы права 644.

Всё настроено исправно и программа выполняется!

Или выскочит ошибка:

Ошибку легко исправить. Откройте порт 8140 у Puppet master. Описание исправления ошибки ниже по тексту этой инструкции.

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

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

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

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

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

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

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

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

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

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

Ответ:

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

Вы можете сказать, что можно было сделать echo "Hello, world!" > /tmp/helloworld, это было бы быстрее.

На самом деле, необходимо было бы написать:

# touch /tmp/helloworld
# echo 'Hello, world!' > /tmp/helloworld
# chmod 644 /tmp/helloworld
# chown root /tmp/helloworld
# chgrp root /tmp/helloworld

Давайте по строкам разберём, что именно содержится в нашем манифесте:

file { '/tmp/helloworld':
   ensure => present,          # файл должен существовать
   content => 'Hello, world!', # содержимым файла должна являться строка "Hello, world!"
   mode => 0644,               # права на файл - 0644
   owner => 'root',            # владелец файла - root
   group => 'root'             # группа файла - root
}

В терминах Puppet здесь описан ресурс типа файл с названием (title) — это /tmp/helloworld.

8.2. Описание ноды и ресурса на ней.

Установим Puppet agent на остальные виртуальные машины, по аналогии с текстом инструкции выше.

На ноде puppet-cl14.hamsterden.loc должен быть создан файл /etc/issue.test с содержимым "CentOS 7 Hello". Файл должен принадлежать пользователю и группе root, права доступа должны быть 0644.

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

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

Пишем манифест:

node 'puppet-cl14.hamsterden.loc' { # блок конфигурации, относящийся к ноде puppet-cl14.hamsterden.loc
  file { '/etc/issue.test': # описываем файл /etc/issue
    ensure => present, # этот файл должен существовать
    content => 'CentOS 7 Hello', # у него должно быть такое содержимое
    owner => root, # пользователь-владелец
    group => root, # группа-владелец
    mode => '0644', # права на файл.
  }
}

Права на файл заданы в виде строки (в кавычках), потому что иначе число с 0 в начале будет воспринято как записанное в восьмеричной системе, и всё пойдёт не так, как задумано.

Зайдем на puppet-cl14.hamsterden.loc:

# ssh root@puppet-cl14.hamsterden.loc

И запросим манифесты с Puppet master для puppet-cl14.hamsterden.loc:

# puppet agent -t

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

Ответ:

Заметка! Если в манифесте поменять строку с одной ноды на другую: «node 'puppet-cl15.hamsterden.loc'» (была 14, стала 15), и запустить запрос манифестов снова на puppet-cl14.hamsterden.loc, то будет ругаться, что в одном и манифестов её обделили и ничего делать она не будет. Откатится с ошибкой.

На puppet-cl14.hamsterden.loc что-то пошло не так.

Ответ с puppet-cl14.hamsterden.loc:

Зато puppet-cl15.hamsterden.loc цветет и пахнет.

Ответ с puppet-cl15.hamsterden.loc:

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

8.3. Взаимосвязи ресурсов на ноде.

На ноде puppet-cl14.hamsterden.loc должен быть запущен nginx, работающий с подготовленной заранее конфигурацией.

Декомпозируем задачу:

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

Создадим манифест-правило не для всех нод, а только для puppet-cl16.hamsterden.loc:

# mcedit /etc/puppet/manifests/site.pp

Пишем манифест:

# адресуется ноде puppet-cl14.hamsterden.loc
node 'puppet-cl14.hamsterden.loc' {
# создаем файл репозитория
file { '/etc/yum.repos.d/nginx.repo':
ensure => present,
# наполняем его строчками кода
content => '[nginx-mainline]
name=nginx mainline repo
baseurl=http://nginx.org/packages/mainline/centos/$releasever/$basearch/
gpgcheck=1
enabled=1
gpgkey=https://nginx.org/keys/nginx_signing.key
module_hotfixes=true',
# задаем права на файл
owner => root,
group => root,
mode => '0730',
}
# устанавливаем nginx крайней свежей версии
~> package { 'nginx':
   ensure => latest,
}
# запускаем службу nginx и ставим ее в автозапуск
~> service { 'nginx':
# он должен быть запущен
   ensure => running,
# его нужно запускать автоматически при старте системы
   enable => true,
   }
}

Про стрелочки:

  • -> Прямая стрелка (->) говорит о том, что ресурс ниже должен создаваться после ресурса, описанного выше.
  • ~> Волнистая стрелка (~>) говорит о том, что ресурс ниже должен подписаться на изменения ресурса, описанного выше. Волнистая стрелка включает в себя прямую (->).

Зайдем на puppet-cl14.hamsterden.loc:

# ssh root@puppet-cl14.hamsterden.loc

И запросим манифесты с Puppet master для puppet-cl16.hamsterden.loc:

# puppet agent -t

Ответ:

Проверим стартанул ли сервис после автоустановки nginx без нашего участия?

# systemctl status nginx

Ответ:

Стартанул!

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

Все остальные шаблоны легко можно найти на просторах интернета.

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

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

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

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

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

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

# puppet cert clean puppet-cl14.hamsterden.loc

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

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

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

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

# puppet agent -t

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

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

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

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

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

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

# rpm -qa | grep puppet

Ответ:

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

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

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

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

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

# puppet config print

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

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

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

# puppet cert list --all

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

Ответ:

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

# puppet cert --sign --all

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

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

# puppet cert clean pm

Ответ:

12. Готовые конфигурации из репозиториев.

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

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

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

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

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

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

package { "samba":
   ensure => latest
}

Данная статья — это часть цикла статей по эксплуатации системы управления конфигурацией — Puppet 3:

  1. Часть I: статья «Установка, настройка, начало эксплуатации». <— Вы здесь!
  2. Часть II: статья «Манифесты, синтаксис, команды».

14. Оригиналы источников информации.

  1. ru.wikipedia.org «Puppet».
  2. habr.com «Как стать кукловодом или Puppet для начинающих».
  3. habr.com «Установка и нaстройка Puppet версии 3.8 на примере Centos 6.5».
  4. habr.com «Введение в Puppet».
  5. dmosk.ru «Как установить и настроить Puppet на CentOS».
  6. qastack.ru «Как узнать, какую версию Puppet вы используете на Centos?»
  7. losst.ru «Настройка firewall Centos?»
  8. puppet.com «Puppet language syntax examples».
  9. puppet.com «Resources».
  10. puppet.com «Node definitions».
  11. puppet.com «The Puppet language style guide».
  12. puppet.com «Puppet 3.8 Reference Manual».
  13. puppet.com «Resource Type Reference Puppet 3.8».
  14. puppet.com «Language: Relationships and Ordering».
  15. puppet.com «Language: Classes».
  16. puppet.com «Language: Variables».
  17. puppet.com «Values, data types, and aliases».
  18. puppet.com «Language: Defined Resource Types».
  19. puppet.com «Language: Conditional Statements».
  20. puppet.com «Language: Namespaces and Autoloading».
  21. puppet.com «Creating templates using Embedded Puppet».
  22. puppet.com «Language: Embedded Ruby (ERB) Template Syntax».
  23. puppet.com «Facter: Core Facts».
  24. puppet.com «Writing custom facts».
  25. puppet.com «External facts».
  26. puppet.com «Accessing facts from Puppet code».
  27. puppet.com «Built-in variables».

Читайте также: