Puppet е система за управление на конфигурацията. Използва се за привеждане на хостове в желаното състояние и поддържане на това състояние.

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

Основна информация

Операционната система на Puppet е клиент-сървър, въпреки че поддържа и работа без сървър с ограничена функционалност.

Използва се модел на работа с изтегляне: по подразбиране, веднъж на всеки половин час, клиентите се свързват със сървъра за конфигурация и я прилагат. Ако сте работили с Ansible, тогава те използват различен push модел: администраторът инициира процеса на прилагане на конфигурацията, самите клиенти няма да прилагат нищо.

По време на мрежова комуникация се използва двупосочно TLS криптиране: сървърът и клиентът имат свои собствени частни ключове и съответните сертификати. Обикновено сървърът издава сертификати за клиенти, но по принцип е възможно да се използва външен CA.

Въведение в манифестите

В кукленската терминология към марионетния сървър свържете се възли (възли). Конфигурацията за възлите е написана в манифести на специален език за програмиране – Puppet DSL.

Puppet DSL е декларативен език. Той описва желаното състояние на възела под формата на декларации на отделни ресурси, например:

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

Ресурсите могат да бъдат свързани помежду си:

• Има зависимости, те влияят на реда, в който се използват ресурсите.
  Например, „първо инсталирайте пакета, след това редактирайте конфигурационния файл, след това стартирайте услугата.“
• Има известия - ако даден ресурс е променен, той изпраща известия до ресурсите, които са абонирани за него.
  Например, ако конфигурационният файл се промени, можете автоматично да рестартирате услугата.

Освен това Puppet DSL има функции и променливи, както и условни оператори и селектори. Поддържат се и различни шаблонни механизми – EPP и ERB.

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

Докато Puppet работи, манифестите за всеки конкретен възел на сървъра се компилират в директория. указател е списък с ресурси и техните връзки след изчисляване на стойността на функции, променливи и разширяване на условни изрази.

Синтаксис и кодов стил

Ето раздели от официалната документация, които ще ви помогнат да разберете синтаксиса, ако предоставените примери не са достатъчни:

• Синтаксис на различни езикови конструкции.
• Синтаксис на ресурса.
• Синтаксис за описание на възли.

Ето пример за това как изглежда манифестът:

# Комментарии пишутся, как и много где, после решётки.
#
# Описание конфигурации ноды начинается с ключевого слова node,
# за которым следует селектор ноды — хостнейм (с доменом или без)
# или регулярное выражение для хостнеймов, или ключевое слово default.
#
# После этого в фигурных скобках описывается собственно конфигурация ноды.
#
# Одна и та же нода может попасть под несколько селекторов. Про приоритет
# селекторов написано в статье про синтаксис описания нод.
node 'hostname', 'f.q.d.n', /regexp/ {
  # Конфигурация по сути является перечислением ресурсов и их параметров.
  #
  # У каждого ресурса есть тип и название.
  #
  # Внимание: не может быть двух ресурсов одного типа с одинаковыми названиями!
  #
  # Описание ресурса начинается с его типа. Тип пишется в нижнем регистре.
  # Про разные типы ресурсов написано ниже.
  #
  # После типа в фигурных скобках пишется название ресурса, потом двоеточие,
  # дальше идёт опциональное перечисление параметров ресурса и их значений.
  # Значения параметров указываются через т.н. hash rocket (=>).
  resource { 'title':
    param1 => value1,
    param2 => value2,
    param3 => value3,
  }
}

Отстъпът и новият ред не са задължителна част от манифеста, но има препоръчителна ръководство за стил. Резюме:

• Отстъпи с два интервала, табулатори не се използват.
• Къдравите скоби са разделени с интервал; двоеточията не са разделени с интервал.
• Запетая след всеки параметър, включително последния. Всеки параметър е на отделен ред. Изключение се прави за случая без параметри и един параметър: можете да пишете на един ред и без запетая (т.е. resource { 'title': } и resource { 'title': param => value }).
• Стрелките на параметрите трябва да са на същото ниво.
• Пред тях са изписани стрелки за взаимоотношения с ресурси.

Местоположение на файловете на pappetserver

За по-нататъшно обяснение ще представя понятието „основна директория“. Основната директория е директорията, която съдържа конфигурацията на Puppet за конкретен възел.

Основната директория варира в зависимост от версията на Puppet и използваните среди. Средите са независими набори от конфигурация, които се съхраняват в отделни директории. Обикновено се използва в комбинация с git, като в този случай среди се създават от git клонове. Съответно всеки възел се намира в една или друга среда. Това може да бъде конфигурирано в самия възел или в ENC, за което ще говоря в следващата статия.

• В третата версия („старата Puppet“) основната директория беше /etc/puppet. Използването на среди не е задължително - например не ги използваме със стария Puppet. Ако се използват среди, те обикновено се съхраняват в /etc/puppet/environments, основната директория ще бъде директорията на средата. Ако среди не се използват, основната директория ще бъде основната директория.
• Започвайки от четвъртата версия („нова марионетка“), използването на среди става задължително и базовата директория е преместена в /etc/puppetlabs/code. Съответно средите се съхраняват в /etc/puppetlabs/code/environments, основната директория е директорията на средата.

Трябва да има поддиректория в основната директория manifests, който съдържа един или повече манифести, описващи възлите. Освен това трябва да има поддиректория modules, който съдържа модулите. Ще ви кажа какви са модулите малко по-късно. В допълнение, старата Puppet може също да има поддиректория files, който съдържа различни файлове, които копираме в възлите. В новия Puppet всички файлове са поставени в модули.

Файловете на манифеста имат разширение .pp.

Няколко бойни примера

Описание на възела и ресурса в него

На възела server1.testdomain трябва да се създаде файл /etc/issue със съдържание Debian GNU/Linux n l. Файлът трябва да е собственост на потребител и група root, трябва да има права за достъп 644.

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

node 'server1.testdomain' {   # блок конфигурации, относящийся к ноде server1.testdomain
    file { '/etc/issue':   # описываем файл /etc/issue
        ensure  => present,   # этот файл должен существовать
        content => 'Debian GNU/Linux n l',   # у него должно быть такое содержимое
        owner   => root,   # пользователь-владелец
        group   => root,   # группа-владелец
        mode    => '0644',   # права на файл. Они заданы в виде строки (в кавычках), потому что иначе число с 0 в начале будет воспринято как записанное в восьмеричной системе, и всё пойдёт не так, как задумано
    }
}

Връзки между ресурсите на възел

На възела server2.testdomain nginx трябва да работи с предварително подготвена конфигурация.

Нека разложим проблема:

• Пакетът трябва да бъде инсталиран nginx.
• Необходимо е конфигурационните файлове да бъдат копирани от сървъра.
• Услугата трябва да работи nginx.
• Ако конфигурацията се актуализира, услугата трябва да се рестартира.

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

node 'server2.testdomain' {   # блок конфигурации, относящийся к ноде server2.testdomain
    package { 'nginx':   # описываем пакет nginx
        ensure => installed,   # он должен быть установлен
    }
  # Прямая стрелка (->) говорит о том, что ресурс ниже должен
  # создаваться после ресурса, описанного выше.
  # Такие зависимости транзитивны.
    -> file { '/etc/nginx':   # описываем файл /etc/nginx
        ensure  => directory,   # это должна быть директория
        source  => 'puppet:///modules/example/nginx-conf',   # её содержимое нужно брать с паппет-сервера по указанному адресу
        recurse => true,   # копировать файлы рекурсивно
        purge   => true,   # нужно удалять лишние файлы (те, которых нет в источнике)
        force   => true,   # удалять лишние директории
    }
  # Волнистая стрелка (~>) говорит о том, что ресурс ниже должен
  # подписаться на изменения ресурса, описанного выше.
  # Волнистая стрелка включает в себя прямую (->).
    ~> service { 'nginx':   # описываем сервис nginx
        ensure => running,   # он должен быть запущен
        enable => true,   # его нужно запускать автоматически при старте системы
    }
  # Когда ресурс типа service получает уведомление,
  # соответствующий сервис перезапускается.
}

За да работи това, имате нужда от приблизително следното файлово местоположение на марионетния сървър:

/etc/puppetlabs/code/environments/production/ # (это для нового Паппета, для старого корневой директорией будет /etc/puppet)
├── manifests/
│   └── site.pp
└── modules/
    └── example/
        └── files/
            └── nginx-conf/
                ├── nginx.conf
                ├── mime.types
                └── conf.d/
                    └── some.conf

Видове ресурси

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

досие

Управлява файлове, директории, символни връзки, тяхното съдържание и права за достъп.

Опции:

• име на ресурс — път до файла (по избор)
• път — път до файла (ако не е посочен в името)
• гарантира, - тип файл:
  • absent - изтриване на файл
  • present — трябва да има файл от произволен тип (ако няма файл, ще бъде създаден обикновен файл)
  • file - обикновен файл
  • directory - указател
  • link - символна връзка
• съдържание — съдържание на файла (подходящо само за обикновени файлове, не може да се използва заедно с източник или цел)
• източник — връзка към пътя, от който искате да копирате съдържанието на файла (не може да се използва заедно с съдържание или цел). Може да се посочи или като URI със схема puppet: (тогава ще се използват файлове от марионетния сървър), и със схемата http: (Надявам се, че е ясно какво ще се случи в този случай) и дори с диаграмата file: или като абсолютен път без схема (тогава ще се използва файлът от локалния FS на възела)
• цел — където трябва да сочи символната връзка (не може да се използва заедно с съдържание или източник)
• собственик — потребителят, който трябва да притежава файла
• група — групата, към която трябва да принадлежи файлът
• вид — разрешения за файлове (като низ)
• рецидив - позволява рекурсивна обработка на директория
• чистка - позволява изтриване на файлове, които не са описани в Puppet
• принуди - позволява изтриване на директории, които не са описани в Puppet

пакет

Инсталира и премахва пакети. Може да обработва известия - преинсталира пакета, ако параметърът е зададен reinstall_on_refresh.

Опции:

• име на ресурс — име на пакет (по избор)
• име — име на пакета (ако не е посочено в името)
• доставчик — мениджър на пакети за използване
• гарантира, — желано състояние на опаковката:
  • present, installed - всяка инсталирана версия
  • latest - инсталирана е най-новата версия
  • absent - изтрит (apt-get remove)
  • purged — изтрит заедно с конфигурационните файлове (apt-get purge)
  • held - версията на пакета е заключена (apt-mark hold)
  • любая другая строка — определената версия е инсталирана
• reinstall_on_refresh - ако true, след получаване на известието пакетът ще бъде преинсталиран. Полезно за дистрибуции, базирани на изходен код, където може да е необходимо повторно изграждане на пакети при промяна на параметрите на компилация. По подразбиране false.

обслужване

Управлява услугите. Може да обработва известия - рестартира услугата.

Опции:

• име на ресурс — услуга, която трябва да се управлява (по избор)
• име — услугата, която трябва да се управлява (ако не е посочена в името)
• гарантира, — желано състояние на услугата:
  • running - стартиран
  • stopped - спряна
• позволи — контролира възможността за стартиране на услугата:
  • true — автоматично стартиране е активирано (systemctl enable)
  • mask - маскиран (systemctl mask)
  • false — автоматичното стартиране е деактивирано (systemctl disable)
• рестартиране - команда за рестартиране на услугата
• статус — команда за проверка на състоянието на услугата
• hasrestart — посочва дали началният скрипт на услугата поддържа рестартиране. Ако false и параметърът е посочен рестартиране — използва се стойността на този параметър. Ако false и параметър рестартиране не е посочено - услугата е спряна и стартирана за рестартиране (но systemd използва командата systemctl restart).
• hasstatus — посочва дали initscript на услугата поддържа командата status, ако false, тогава се използва стойността на параметъра статус. По подразбиране true.

EXEC

Изпълнява външни команди. Ако не посочите параметри създава, само ако, освен ако или освежено, командата ще се изпълнява всеки път, когато се стартира Puppet. Може да обработва известия - изпълнява команда.

Опции:

• име на ресурс — команда за изпълнение (по избор)
• команда — командата, която трябва да бъде изпълнена (ако не е посочена в името)
• път — пътища, в които да търсите изпълнимия файл
• само ако — ако командата, посочена в този параметър, завърши с нулев код за връщане, основната команда ще бъде изпълнена
• освен ако — ако командата, посочена в този параметър, завърши с ненулев код за връщане, основната команда ще бъде изпълнена
• създава — ако посоченият в този параметър файл не съществува, основната команда ще бъде изпълнена
• освежено - ако true, тогава командата ще бъде изпълнена само когато този exec получи известие от други ресурси
• cwd — директория, от която да се изпълни командата
• потребител — потребителят, от когото да се изпълни командата
• доставчик - как да стартирате командата:
  • POSIX — просто се създава дъщерен процес, не забравяйте да посочите път
  • черупка - командата се стартира в shell-а /bin/sh, може да не е посочено път, можете да използвате globbing, тръби и други функции на обвивката. Обикновено се открива автоматично, ако има специални знаци (|, ;, &&, || и т.н.).

Cron

Контролира cronjobs.

Опции:

• име на ресурс - просто някакъв вид идентификатор
• гарантира, — състояние на crownjob:
  • present - създайте, ако не съществува
  • absent - изтриване, ако съществува
• команда - каква команда да стартирате
• заобикаляща среда — в коя среда да се изпълни командата (списък с променливи на средата и техните стойности чрез =)
• потребител — от кой потребител да се изпълни командата
• минута, час, делничен, месец, месечен ден — кога да стартирате cron. Ако някой от тези атрибути не е посочен, стойността му в crontab ще бъде *.

В Puppet 6.0 Cron все едно изваден от кутията в puppetserver, така че няма документация на общия сайт. Но той е в кутията в puppet-agent, така че няма нужда да го инсталирате отделно. Можете да видите документацията за него в документацията за петата версия на PuppetИли на GitHub.

За ресурсите като цяло

Изисквания за уникалност на ресурса

Най-честата грешка, която срещаме е Дублирана декларация. Тази грешка възниква, когато два или повече ресурса от един и същи тип с едно и също име се появяват в директорията.

Затова ще напиша отново: манифестите за един и същи възел не трябва да съдържат ресурси от същия тип с едно и също заглавие!

Понякога има нужда да се инсталират пакети със същото име, но с различни мениджъри на пакети. В този случай трябва да използвате параметъра nameза да избегнете грешката:

package { 'ruby-mysql':
  ensure   => installed,
  name     => 'mysql',
  provider => 'gem',
}
package { 'python-mysql':
  ensure   => installed,
  name     => 'mysql',
  provider => 'pip',
}

Други типове ресурси имат подобни опции за избягване на дублиране - name у обслужване, command у EXEC, и така нататък.

Метапараметри

Всеки тип ресурс има някои специални параметри, независимо от естеството си.

Пълен списък с мета параметри в документацията на Puppet.

Кратък списък:

• изисква — този параметър показва от кои ресурси зависи този ресурс.
• преди - Този параметър указва кои ресурси зависят от този ресурс.
• Абонирай се — този параметър указва от кои ресурси този ресурс получава известия.
• уведомява — Този параметър указва кои ресурси получават известия от този ресурс.

Всички изброени метапараметри приемат или една връзка към ресурс, или масив от връзки в квадратни скоби.

Връзки към ресурси

Връзката към ресурс е просто споменаване на ресурса. Те се използват главно за обозначаване на зависимости. Позоваването на несъществуващ ресурс ще доведе до грешка при компилиране.

Синтаксисът на връзката е следният: тип ресурс с главна буква (ако името на типа съдържа двойни двоеточия, тогава всяка част от името между двоеточията е главна), след това името на ресурса в квадратни скоби (случаят на името не се променя!). Не трябва да има интервали, квадратните скоби се изписват непосредствено след името на типа.

Пример:

file { '/file1': ensure => present }
file { '/file2':
  ensure => directory,
  before => File['/file1'],
}
file { '/file3': ensure => absent }
File['/file1'] -> File['/file3']

Зависимости и известия

Документация тук.

Както беше посочено по-рано, простите зависимости между ресурсите са преходни. Между другото, внимавайте, когато добавяте зависимости - можете да създадете циклични зависимости, което ще доведе до грешка при компилация.

За разлика от зависимостите, уведомленията не са преходни. За уведомленията се прилагат следните правила:

• Ако ресурсът получи известие, той се актуализира. Действията за актуализиране зависят от типа ресурс − EXEC изпълнява командата, обслужване рестартира услугата, пакет преинсталира пакета. Ако ресурсът няма дефинирано действие за актуализиране, нищо не се случва.
• По време на едно изпълнение на Puppet, ресурсът се актуализира не повече от веднъж. Това е възможно, защото известията включват зависимости, а графиката на зависимостите не съдържа цикли.
• Ако Puppet промени състоянието на ресурс, ресурсът изпраща известия до всички ресурси, абонирани за него.
• Ако даден ресурс се актуализира, той изпраща известия до всички ресурси, абонирани за него.

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

Като правило, ако някой параметър на ресурс няма стойност по подразбиране и този параметър не е посочен в манифеста, тогава Puppet няма да промени това свойство за съответния ресурс на възела. Например, ако ресурс от тип досие параметърът не е посочен owner, тогава Puppet няма да промени собственика на съответния файл.

Въведение в класове, променливи и дефиниции

Да предположим, че имаме няколко възела, които имат една и съща част от конфигурацията, но има и разлики - в противен случай бихме могли да опишем всичко в един блок node {}. Разбира се, можете просто да копирате идентични части от конфигурацията, но като цяло това е лошо решение - конфигурацията расте и ако промените общата част от конфигурацията, ще трябва да редактирате едно и също нещо на много места. В същото време е лесно да се направи грешка и като цяло принципът DRY (не се повтаряйте) е измислен с причина.

За решаването на този проблем има такъв дизайн като клас.

класове

Клас е наименуван блок от код на poppet. Необходими са класове за повторно използване на код.

Първо трябва да се опише класът. Самото описание никъде не добавя ресурси. Класът е описан в манифести:

# Описание класса начинается с ключевого слова class и его названия.
# Дальше идёт тело класса в фигурных скобках.
class example_class {
    ...
}

След това класът може да се използва:

# первый вариант использования — в стиле ресурса с типом class
class { 'example_class': }
# второй вариант использования — с помощью функции include
include example_class
# про отличие этих двух вариантов будет рассказано дальше

Пример от предишната задача - нека преместим инсталацията и конфигурацията на nginx в клас:

class nginx_example {
    package { 'nginx':
        ensure => installed,
    }
    -> file { '/etc/nginx':
        ensure => directory,
        source => 'puppet:///modules/example/nginx-conf',
        recure => true,
        purge  => true,
        force  => true,
    }
    ~> service { 'nginx':
        ensure => running,
        enable => true,
    }
}

node 'server2.testdomain' {
    include nginx_example
}

променливи

Класът от предишния пример изобщо не е гъвкав, защото винаги носи една и съща конфигурация на nginx. Нека направим пътя до конфигурационната променлива, след което този клас може да се използва за инсталиране на nginx с всяка конфигурация.

Може да се направи използване на променливи.

Внимание: променливите в Puppet са неизменни!

Освен това променливата може да бъде достъпна само след като е декларирана, в противен случай стойността на променливата ще бъде undef.

Пример за работа с променливи:

# создание переменных
$variable = 'value'
$var2 = 1
$var3 = true
$var4 = undef
# использование переменных
$var5 = $var6
file { '/tmp/text': content => $variable }
# интерполяция переменных — раскрытие значения переменных в строках. Работает только в двойных кавычках!
$var6 = "Variable with name variable has value ${variable}"

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

Примери за пространство на имена:

• глобални - променливи извън описанието на класа или възела отиват там;
• пространство от имена на възли в описанието на възли;
• пространство от имена на клас в описанието на класа.

За да избегнете неяснота при достъп до променлива, можете да посочите пространството от имена в името на променливата:

# переменная без пространства имён
$var
# переменная в глобальном пространстве имён
$::var
# переменная в пространстве имён класса
$classname::var
$::classname::var

Нека се съгласим, че пътят до конфигурацията на nginx се крие в променливата $nginx_conf_source. Тогава класът ще изглежда така:

class nginx_example {
    package { 'nginx':
        ensure => installed,
    }
    -> file { '/etc/nginx':
        ensure => directory,
        source => $nginx_conf_source,   # здесь используем переменную вместо фиксированной строки
        recure => true,
        purge  => true,
        force  => true,
    }
    ~> service { 'nginx':
        ensure => running,
        enable => true,
    }
}

node 'server2.testdomain' {
    $nginx_conf_source = 'puppet:///modules/example/nginx-conf'
    include nginx_example
}

Даденият пример обаче е лош, защото има някакво „тайно знание“, че някъде в класа се използва променлива с такова и такова име. Много по-правилно е тези знания да бъдат обобщени - класовете могат да имат параметри.

Параметри на класа са променливи в пространството от имена на класа, те са посочени в заглавката на класа и могат да се използват като обикновени променливи в тялото на класа. Стойностите на параметрите се посочват при използване на класа в манифеста.

Параметърът може да бъде зададен на стойност по подразбиране. Ако даден параметър няма стойност по подразбиране и стойността не е зададена, когато се използва, това ще доведе до грешка при компилиране.

Нека да параметризираме класа от примера по-горе и да добавим два параметъра: първият, задължителен, е пътят към конфигурацията, а вторият, незадължителен, е името на пакета с nginx (в Debian, например, има пакети nginx, nginx-light, nginx-full).

# переменные описываются сразу после имени класса в круглых скобках
class nginx_example (
  $conf_source,
  $package_name = 'nginx-light', # параметр со значением по умолчанию
) {
  package { $package_name:
    ensure => installed,
  }
  -> file { '/etc/nginx':
    ensure  => directory,
    source  => $conf_source,
    recurse => true,
    purge   => true,
    force   => true,
  }
  ~> service { 'nginx':
    ensure => running,
    enable => true,
  }
}

node 'server2.testdomain' {
  # если мы хотим задать параметры класса, функция include не подойдёт* — нужно использовать resource-style declaration
  # *на самом деле подойдёт, но про это расскажу в следующей серии. Ключевое слово "Hiera".
  class { 'nginx_example':
    conf_source => 'puppet:///modules/example/nginx-conf',   # задаём параметры класса точно так же, как параметры для других ресурсов
  }
}

В Puppet променливите се въвеждат. Яжте много типове данни. Типовете данни обикновено се използват за валидиране на стойности на параметри, предадени на класове и дефиниции. Ако предаденият параметър не съответства на указания тип, ще възникне грешка при компилиране.

Типът се записва непосредствено преди името на параметъра:

class example (
  String $param1,
  Integer $param2,
  Array $param3,
  Hash $param4,
  Hash[String, String] $param5,
) {
  ...
}

Класове: включва име на клас срещу клас {'classname':}

Всеки клас е ресурс от тип клас. Както при всеки друг тип ресурс, не може да има два екземпляра от един и същи клас на един и същи възел.

Ако се опитате да добавите клас към един и същ възел два пъти, като използвате class { 'classname':} (без разлика, с различни или идентични параметри), ще има грешка при компилиране. Но ако използвате клас в ресурсния стил, можете веднага изрично да зададете всички негови параметри в манифеста.

Въпреки това, ако използвате include, тогава класът може да се добавя толкова пъти, колкото желаете. Факт е, че include е идемпотентна функция, която проверява дали даден клас е добавен към директорията. Ако класът не е в директорията, той го добавя, а ако вече съществува, не прави нищо. Но в случай на използване include Не можете да задавате параметри на класа по време на декларацията на клас - всички необходими параметри трябва да бъдат зададени във външен източник на данни - Hiera или ENC. Ще говорим за тях в следващата статия.

Определя

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

Например, за да инсталираме PHP модула, правим следното в Avito:

1. Инсталирайте пакета с този модул.
2. Нека създадем конфигурационен файл за този модул.
3. Създаваме символна връзка към конфигурацията за php-fpm.
4. Създаваме символна връзка към конфигурацията за php cli.

В такива случаи дизайн като напр дефинирам (дефиниране, дефиниран тип, дефиниран тип ресурс). Define е подобен на клас, но има разлики: първо, всеки Define е тип ресурс, а не ресурс; второ, всяка дефиниция има неявен параметър $title, където отива името на ресурса, когато е деклариран. Точно както в случая с класовете, дефиницията трябва първо да бъде описана, след което тя може да бъде използвана.

Опростен пример с модул за PHP:

define php74::module (
  $php_module_name = $title,
  $php_package_name = "php7.4-${title}",
  $version = 'installed',
  $priority = '20',
  $data = "extension=${title}.son",
  $php_module_path = '/etc/php/7.4/mods-available',
) {
  package { $php_package_name:
    ensure          => $version,
    install_options => ['-o', 'DPkg::NoTriggers=true'],  # триггеры дебиановских php-пакетов сами создают симлинки и перезапускают сервис php-fpm - нам это не нужно, так как и симлинками, и сервисом мы управляем с помощью Puppet
  }
  -> file { "${php_module_path}/${php_module_name}.ini":
    ensure  => $ensure,
    content => $data,
  }
  file { "/etc/php/7.4/cli/conf.d/${priority}-${php_module_name}.ini":
    ensure  => link,
    target  => "${php_module_path}/${php_module_name}.ini",
  }
  file { "/etc/php/7.4/fpm/conf.d/${priority}-${php_module_name}.ini":
    ensure  => link,
    target  => "${php_module_path}/${php_module_name}.ini",
  }
}

node server3.testdomain {
  php74::module { 'sqlite3': }
  php74::module { 'amqp': php_package_name => 'php-amqp' }
  php74::module { 'msgpack': priority => '10' }
}

Най-лесният начин да хванете грешката при деклариране на дубликат е в Define. Това се случва, ако дефиниция има ресурс с постоянно име и има два или повече екземпляра на тази дефиниция на даден възел.

Лесно е да се предпазите от това: всички ресурси в дефиницията трябва да имат име в зависимост от $title. Алтернатива е идемпотентно добавяне на ресурси; в най-простия случай е достатъчно да преместите ресурсите, общи за всички екземпляри на дефиницията, в отделен клас и да включите този клас в дефиницията - функция include идемпотентен.

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

Зависимости и известия за класове и дефиниции

Класовете и дефинициите добавят следните правила за обработка на зависимости и известия:

• зависимост от клас/дефиниране добавя зависимости към всички ресурси на класа/дефиниране;
• зависимост клас/дефиниране добавя зависимости към всички ресурси клас/дефиниране;
• уведомяването за клас/дефиниране уведомява всички ресурси на класа/дефинирането;
• class/define subscription се абонира за всички ресурси на class/define.

Условни оператори и селектори

Документация тук.

if

Тук е просто:

if ВЫРАЖЕНИЕ1 {
  ...
} elsif ВЫРАЖЕНИЕ2 {
  ...
} else {
  ...
}

освен ако

освен ако не е if в обратна посока: блокът от код ще бъде изпълнен, ако изразът е false.

unless ВЫРАЖЕНИЕ {
  ...
}

случай

Тук също няма нищо сложно. Можете да използвате регулярни стойности (низове, числа и т.н.), регулярни изрази и типове данни като стойности.

case ВЫРАЖЕНИЕ {
  ЗНАЧЕНИЕ1: { ... }
  ЗНАЧЕНИЕ2, ЗНАЧЕНИЕ3: { ... }
  default: { ... }
}

Селектори

Селекторът е езикова конструкция, подобна на case, но вместо да изпълни блок от код, той връща стойност.

$var = $othervar ? { 'val1' => 1, 'val2' => 2, default => 3 }

Модули

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

Освен това съществува проблемът с повторното използване на кода - когато целият код е в един манифест, е трудно този код да се сподели с други. За да разреши тези два проблема, Puppet има обект, наречен модули.

Модули - това са набори от класове, дефиниции и други Puppet обекти, поставени в отделна директория. С други думи, модулът е независима част от логиката на Puppet. Например може да има модул за работа с nginx и той да съдържа това и само това, което е необходимо за работа с nginx или може да има модул за работа с PHP и т.н.

Модулите са с версии и се поддържат зависимости на модулите един от друг. Има отворено хранилище на модули - Ковачница за кукли.

На марионетния сървър модулите се намират в поддиректорията modules на главната директория. Във всеки модул има стандартна схема на директория - манифести, файлове, шаблони, библиотеки и т.н.

Файлова структура в модул

Коренът на модула може да съдържа следните директории с описателни имена:

• manifests - съдържа манифести
• files - съдържа файлове
• templates - съдържа шаблони
• lib — съдържа Ruby код

Това не е пълен списък с директории и файлове, но засега е достатъчен за тази статия.

Имена на ресурси и имена на файлове в модула

Документация тук.

Ресурсите (класове, дефиниции) в модул не могат да бъдат наименувани както искате. Освен това има пряко съответствие между името на ресурс и името на файла, в който Puppet ще търси описание на този ресурс. Ако нарушите правилата за именуване, тогава Puppet просто няма да намери описанието на ресурса и ще получите грешка при компилация.

Правилата са прости:

• Всички ресурси в модул трябва да са в пространството на имената на модула. Ако модулът е извикан foo, тогава всички ресурси в него трябва да бъдат именувани foo::<anything>, или просто foo.
• Ресурсът с името на модула трябва да е във файла init.pp.
• За други ресурси схемата за именуване на файлове е както следва:
  • префиксът с името на модула се изхвърля
  • всички двойни двоеточия, ако има такива, се заменят с наклонени черти
  • се добавя разширение .pp

Ще демонстрирам с пример. Да кажем, че пиша модул nginx. Той съдържа следните ресурси:

• клас nginx описани в манифеста init.pp;
• клас nginx::service описани в манифеста service.pp;
• дефинирам nginx::server описани в манифеста server.pp;
• дефинирам nginx::server::location описани в манифеста server/location.pp.

Templates

Със сигурност вие сами знаете какво представляват шаблоните, няма да ги описвам подробно тук. Но ще го оставя за всеки случай връзка към Wikipedia.

Как да използвате шаблони: Значението на шаблон може да бъде разширено с помощта на функция template, на който се предава пътя към шаблона. За ресурси от тип досие използва се заедно с параметъра content. Например така:

file { '/tmp/example': content => template('modulename/templatename.erb')

Преглед на пътя <modulename>/<filename> предполага файл <rootdir>/modules/<modulename>/templates/<filename>.

Освен това има функция inline_template — получава текста на шаблона като вход, а не името на файла.

В рамките на шаблоните можете да използвате всички променливи на Puppet в текущия обхват.

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

• EPP документация.
• ERB документация.

Накратко за ERB

Контролни структури:

• <%= ВЫРАЖЕНИЕ %> — въведете стойността на израза
• <% ВЫРАЖЕНИЕ %> — изчислете стойността на израз (без да го вмъквате). Условните изрази (if) и циклите (each) обикновено отиват тук.
• <%# КОММЕНТАРИЙ %>

Изразите в ERB са написани на Ruby (ERB всъщност е Embedded Ruby).

За достъп до променливи от манифеста трябва да добавите @ към името на променливата. За да премахнете нов ред, който се появява след контролна конструкция, трябва да използвате затварящ таг -%>.

Пример за използване на шаблона

Да кажем, че пиша модул за управление на ZooKeeper. Класът, отговорен за създаването на конфигурацията, изглежда по следния начин:

class zookeeper::configure (
  Array[String] $nodes,
  Integer $port_client,
  Integer $port_quorum,
  Integer $port_leader,
  Hash[String, Any] $properties,
  String $datadir,
) {
  file { '/etc/zookeeper/conf/zoo.cfg':
    ensure  => present,
    content => template('zookeeper/zoo.cfg.erb'),
  }
}

И съответния шаблон zoo.cfg.erb - Така:

<% if @nodes.length > 0 -%>
<% @nodes.each do |node, id| -%>
server.<%= id %>=<%= node %>:<%= @port_leader %>:<%= @port_quorum %>;<%= @port_client %>
<% end -%>
<% end -%>

dataDir=<%= @datadir %>

<% @properties.each do |k, v| -%>
<%= k %>=<%= v %>
<% end -%>

Факти и вградени променливи

Често конкретната част от конфигурацията зависи от това какво се случва в момента на възела. Например, в зависимост от версията на Debian, трябва да инсталирате една или друга версия на пакета. Можете да наблюдавате всичко това ръчно, като пренаписвате манифестите, ако възлите се променят. Но това не е сериозен подход, автоматизацията е много по-добра.

За да получи информация за възлите, Puppet има механизъм, наречен факти. факти - това е информация за възела, налична в манифестите под формата на обикновени променливи в глобалното пространство на имената. Например име на хост, версия на операционната система, архитектура на процесора, списък с потребители, списък с мрежови интерфейси и техните адреси и много, много повече. Фактите са налични в манифести и шаблони като редовни променливи.

Пример за работа с факти:

notify { "Running OS ${facts['os']['name']} version ${facts['os']['release']['full']}": }
# ресурс типа notify просто выводит сообщение в лог

Формално казано, фактът има име (низ) и стойност (налични са различни типове: низове, масиви, речници). Яжте набор от вградени факти. Можете също да напишете своя собствена. Описани са събирачи на факти като функции в Rubyили като изпълними файлове. Във формата могат да се представят и факти текстови файлове с данни на възлите.

По време на работа марионетният агент първо копира всички налични колектори на факти от pappetserver в възела, след което ги стартира и изпраща събраните факти на сървъра; След това сървърът започва да компилира каталога.

Факти под формата на изпълними файлове

Такива факти се поставят в модули в директорията facts.d. Разбира се, файловете трябва да са изпълними. Когато се изпълняват, те трябва да извеждат информация в стандартен изход във формат YAML или ключ=стойност.

Не забравяйте, че фактите се отнасят за всички възли, които се контролират от poppet сървъра, към който е разположен вашият модул. Затова в скрипта внимавайте да проверите дали системата разполага с всички програми и файлове, необходими за работата на вашия факт.

#!/bin/sh
echo "testfact=success"

#!/bin/sh
echo '{"testyamlfact":"success"}'

Рубинени факти

Такива факти се поставят в модули в директорията lib/facter.

# всё начинается с вызова функции Facter.add с именем факта и блоком кода
Facter.add('ladvd') do
# в блоках confine описываются условия применимости факта — код внутри блока должен вернуть true, иначе значение факта не вычисляется и не возвращается
  confine do
    Facter::Core::Execution.which('ladvdc') # проверим, что в PATH есть такой исполняемый файл
  end
  confine do
    File.socket?('/var/run/ladvd.sock') # проверим, что есть такой UNIX-domain socket
  end
# в блоке setcode происходит собственно вычисление значения факта
  setcode do
    hash = {}
    if (out = Facter::Core::Execution.execute('ladvdc -b'))
      out.split.each do |l|
        line = l.split('=')
        next if line.length != 2
        name, value = line
        hash[name.strip.downcase.tr(' ', '_')] = value.strip.chomp(''').reverse.chomp(''').reverse
      end
    end
    hash  # значение последнего выражения в блоке setcode является значением факта
  end
end

Текстови факти

Такива факти се поставят на възли в директорията /etc/facter/facts.d в стария Puppet или /etc/puppetlabs/facts.d в новия Puppet.

examplefact=examplevalue

---
examplefact2: examplevalue2
anotherfact: anothervalue

Стигане до фактите

Има два начина за подход към фактите:

• чрез речника $facts: $facts['fqdn'];
• използвайки името на факта като име на променлива: $fqdn.

Най-добре е да използвате речник $facts, или дори по-добре, посочете глобалното пространство от имена ($::facts).

Ето съответния раздел от документацията.

Вградени променливи

Освен фактите, има и някои променливи, наличен в глобалното пространство от имена.

• достоверни факти — променливи, които са взети от сертификата на клиента (тъй като сертификатът обикновено се издава на poppet сървър, агентът не може просто да вземе и промени своя сертификат, така че променливите са „доверени“): името на сертификата, името на хост и домейн, разширения от сертификата.
• факти за сървъра — променливи, свързани с информация за сървъра — версия, име, IP адрес на сървъра, среда.
• агентски факти — променливи, добавени директно от марионетен агент, а не от фактор — име на сертификат, версия на агент, версия на марионетка.
• главни променливи - Променливи на Pappetmaster (sic!). Това е горе-долу същото като в факти за сървъра, плюс стойностите на конфигурационните параметри са налични.
• променливи на компилатора — променливи на компилатора, които се различават във всеки обхват: името на текущия модул и името на модула, в който е осъществен достъп до текущия обект. Те могат да се използват, например, за да се провери дали вашите частни класове не се използват директно от други модули.

Допълнение 1: как да стартирате и дебъгвате всичко това?

Статията съдържаше много примери за марионетен код, но изобщо не ни каза как да стартираме този код. Е, поправям се.

Агент е достатъчен, за да стартирате Puppet, но в повечето случаи ще ви трябва и сървър.

агент

Поне от версия XNUMX, пакети за куклен агент от официално хранилище на Puppetlabs съдържат всички зависимости (ruby и съответните скъпоценни камъни), така че няма затруднения при инсталирането (говоря за базирани на Debian дистрибуции - ние не използваме базирани на RPM дистрибуции).

В най-простия случай, за да използвате марионетната конфигурация, е достатъчно да стартирате агента в режим без сървър: при условие, че кодът на марионетката е копиран в възела, стартирайте puppet apply <путь к манифесту>:

atikhonov@atikhonov ~/puppet-test $ cat helloworld.pp 
node default {
    notify { 'Hello world!': }
}
atikhonov@atikhonov ~/puppet-test $ puppet apply helloworld.pp 
Notice: Compiled catalog for atikhonov.localdomain in environment production in 0.01 seconds
Notice: Hello world!
Notice: /Stage[main]/Main/Node[default]/Notify[Hello world!]/message: defined 'message' as 'Hello world!'
Notice: Applied catalog in 0.01 seconds

По-добре е, разбира се, да настроите сървъра и да стартирате агенти на възлите в режим на демон - тогава веднъж на всеки половин час те ще прилагат конфигурацията, изтеглена от сървъра.

Можете да имитирате push модела на работа - отидете до възела, който ви интересува и започнете sudo puppet agent -t. Ключ -t (--test) всъщност включва няколко опции, които могат да бъдат активирани индивидуално. Тези опции включват следното:

• не стартирайте в режим на демон (по подразбиране агентът стартира в режим на демон);
• изключване след прилагане на каталога (по подразбиране агентът ще продължи да работи и ще прилага конфигурацията веднъж на всеки половин час);
• напишете подробен работен дневник;
• показва промените във файловете.

Агентът има режим на работа без промени - можете да го използвате, когато не сте сигурни, че сте написали правилната конфигурация и искате да проверите какво точно ще промени агентът по време на работа. Този режим се разрешава от параметъра --noop на командния ред: sudo puppet agent -t --noop.

Освен това можете да активирате дневника за отстраняване на грешки на работата - в него марионетката пише за всички действия, които извършва: за ресурса, който обработва в момента, за параметрите на този ресурс, за това какви програми стартира. Разбира се, това е параметър --debug.

сървър

Няма да разглеждам пълната настройка на pappetserver и внедряването на код към него в тази статия; ще кажа само, че има напълно функционална версия на сървъра, която не изисква допълнителна конфигурация за работа с малък брой възли (да речем, до сто). По-голям брой възли ще изискват настройка - по подразбиране puppetserver стартира не повече от четири работници, за по-голяма производителност трябва да увеличите броя им и не забравяйте да увеличите ограниченията на паметта, в противен случай сървърът ще събира боклука през повечето време.

Внедряване на код - ако имате нужда от него бързо и лесно, тогава погледнете (в r10k)[https://github.com/puppetlabs/r10k], за малки инсталации би трябвало да е напълно достатъчно.

Допълнение 2: Насоки за кодиране

1. Поставете цялата логика в класове и дефиниции.
2. Съхранявайте класове и дефиниции в модули, а не в манифести, описващи възли.
3. Използвайте фактите.
4. Не правете ifs въз основа на имена на хостове.
5. Чувствайте се свободни да добавяте параметри за класове и дефиниции - това е по-добре от имплицитната логика, скрита в тялото на класа/дефинирането.

Ще обясня защо препоръчвам да направите това в следващата статия.

Заключение

Да приключим с въведението. В следващата статия ще ви разкажа за Hiera, ENC и PuppetDB.

В анкетата могат да участват само регистрирани потребители. Впиши се, Моля те.

Всъщност има много повече материали - мога да пиша статии по следните теми, да гласувате за това, което би ви било интересно да прочетете:

• 59,1%Усъвършенствани марионетни конструкции - някои глупости от следващо ниво: цикли, картографиране и други ламбда изрази, колектори на ресурси, експортирани ресурси и комуникация между хостове чрез Puppet, тагове, доставчици, абстрактни типове данни.13
• 31,8%„Аз съм администраторът на майка ми“ или как ние в Avito се сприятелихме с няколко poppet сървъра с различни версии и по принцип частта за администрирането на poppet сървъра.7
• 81,8%Как пишем марионетен код: инструменти, документация, тестване, CI/CD.18

22 потребители гласуваха. 9 потребители се въздържаха.

Източник: www.habr.com