Puppet: различия между версиями

Для того, чтобы puppet работал:

* у клиента должна быть возможность соединиться с мастером по IP адресу и имени компьютера (последнее особенно важно, так как SSL сертификаты подписываются с учётом указанного имени). Для этого может потребоваться у клиента в файле /etc/hosts прописать строку с IP адресом и именем host или корректная настройка dns-сервера:

* должны быть открыты исходящие соединения для Puppet на порту 8140 для работы и 8139 для передачи обратных отчётов (или фаервол полностью отключен);

* должны быть синхронизированы часы (из практических соображений, так как часть команд может задаваться с привязкой ко времени и используемое SSL шифрование тоже имеет привязку к времени существования сертификатов).

=== Настройка клиентов ===

Для того чтобы клиенту знать, где собственно искать мастера, необходимо в файле '''puppet.conf''' добавить строку:

[agent]

server = puppet-master.domain

node_name = cert

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

 

 

=== Подписывание сертификатов ===

В первой попытке соединиться с мастером клиенту будет отказано по причине отсутствия подписанного [[w:SSL|SSL]] сертификата, поэтому, получив отказ, клиент оставит запрос на его получение. Посмотреть список запросов можно с помощью команды:

Подписать сертификат и, соответственно, разрешить доступ клиенту можно командой:

где «puppet-client.domain» — имя клиента.

Удалить сертификат с сервера:

В версиях менее третьей надо было использовать эти команды в двух вариантах, заменив '''puppet cert = puppetca'''.

 

=== Гид по языку ===

* '''Условие'''

block of code

}

else {

block of code

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

centos, redhat: { $apache = "httpd" }

debian, ubuntu: { $apache = "apache2" }

default: { fail("Unrecognized operating system for webserver") }

* '''Выбор'''

centos => 'httpd',

redhat => 'httpd',

/(?i)(ubuntu|debian)/ => "apache2",

default => undef,

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

 

==== Классы ====

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

file { '/etc/passwd':

owner => 'root',

class freebsd inherits unix {

File['/etc/passwd', '/etc/shadow'] { group => 'wheel', owner => undef }

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

Значение атрибутов можно не заменять а добавлять:

service { 'apache': require => Package['httpd'] }

}

# host certificate is required for SSL to function

Service['apache'] { require +> File['apache.pem'] }

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

service { 'apache': require => Class['squid'] }

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

service { foo: ensure => running }

}

include myservice

file { '/foo': notify => Service[foo] }

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

# Содержимое класса

}

node webserver {

class { 'apache': version => '1.3.13' }

 

== Основные типы ==

* '''logoutput''' — включать ли вывод команды в лог, равно ''true'', ''false'' и ''on_failure'' (только в случае выхода с ошибкой).

* '''onlyif''' — задаёт проверочную команду. Основная команда (атрибут ''command'') будет выполнена, только если эта команда выполнится без ошибок (код выхода будет 0), например:

path => "/usr/bin:/usr/sbin:/bin",

onlyif => "test `du /var/log/messages | cut -f1` -gt 100000"

При этом onlyif может проверять массив команд и выполнить основную команду только тогда, когда все команды массива выполнятся:

 

=== cron ===

Каждый раз, когда puppet отрабатывает манифесты, она проверяет, попадает ли текущий момент времени в указанное расписание. Если попадает, то ресурс отработает, иначе будет просто пропущен. При этом puppet '''НЕ создаст себе никакого задания отработать ресурс в будущем'''. То есть если создать расписание «Х» скажем ежедневно с 12:20 до 12:30, а по умолчанию puppet применяет конфигурацию раз в 30 минут, а компьютер был включен в 12:10… то следующий раз puppet отработает в 12:40 и все ресурсы, которым было назначено расписание «Х», просто не сработают. Или puppet будет отрабатывать какой-нибудь ресурс продолжительное время (загружать файлы или т. п.) с 12:15 по 12:35, и данное расписание тоже «выпадет» и может вообще никогда не сработает. <br />

Поэтому, лучше использовать широкие расписания… (с интервалом в несколько часов). Например, чтобы запускать задание 1 раз в сутки между 2 и 4 часами утра надо задать следующее расписание:

range => "2 - 4",

period => daily,

repeat => 1,

* '''period''' — Период повторения. Равно hourly, daily, weekly, monthly, never (никогда, то есть параметр ''repeat'' задаст сколько всего раз выполнится данный ресурс).

* '''periodmatch''' — Конкретизирует параметр ''period''. Равно ''number'' (когда учитываются количество срабатываний ''в течение'' определённого период, например, в час) или ''distance'' (когда учитывается срабатывание ''через'' определённый период).

tests/</code>

Обращение в коде puppet к классам будет выглядеть как:

имя_модуля::класс1 { ... }

Для того, чтобы модуль вообще заработал достаточно иметь папку с именем модуля, папку с манифестами и начальным манифестом ''init.pp''.<br />

По аналогии выстраиваем под_под_классы и под_под_…под_классы, пока не надоест. <br />