Puppet е систем за управување со конфигурации. Се користи за доведување на домаќините во посакуваната состојба и одржување на оваа состојба.

Работам со Puppet повеќе од пет години. Овој текст во суштина е преведена и преуредена компилација на клучни точки од официјалната документација, што ќе им овозможи на почетниците брзо да ја разберат суштината на Куклата.

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

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

Се користи модел на влечење: стандардно, еднаш на секои половина час, клиентите контактираат со серверот за конфигурација и го применуваат. Ако сте работеле со Ansible, тогаш тие користат различен модел на push: администраторот го иницира процесот на примена на конфигурацијата, самите клиенти нема да применат ништо.

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

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

Во куклена терминологија на куклен сервер поврзете јазли (јазли). Конфигурацијата за јазлите е напишана во манифести во посебен програмски јазик - Puppet DSL.

Puppet DSL е декларативен јазик. Ја опишува посакуваната состојба на јазолот во форма на декларации на поединечни ресурси, на пример:

• Датотеката постои и има специфична содржина.
• Пакетот е инсталиран.
• Услугата започна.

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

• Постојат зависности, тие влијаат на редоследот по кој се користат ресурсите.
  На пример, „прво инсталирајте го пакетот, потоа уредете ја конфигурациската датотека, а потоа стартувајте ја услугата“.
• Има известувања - ако некој ресурс е променет, тој испраќа известувања до ресурсите што се претплатени на него.
  На пример, ако конфигурациската датотека се промени, можете автоматски да ја рестартирате услугата.

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

Куклата е напишана во Руби, па многу од конструкциите и термините се земени од таму. Руби ви овозможува да го проширите 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

За дополнително објаснување, ќе го воведам концептот на „root директориум“. Коренскиот директориум е директориумот што ја содржи конфигурацијата Puppet за одреден јазол.

Коренскиот директориум варира во зависност од верзијата на Puppet и користените средини. Околините се независни групи на конфигурации кои се складирани во посебни директориуми. Обично се користи во комбинација со git, во тој случај околините се создаваат од git гранки. Соодветно на тоа, секој јазол се наоѓа во една или друга средина. Ова може да се конфигурира на самиот јазол или во ENC, за што ќе зборувам во следната статија.

• Во третата верзија („старата кукла“) основниот директориум беше /etc/puppet. Употребата на околини е опционална - на пример, не ги користиме со старата Кукла. Ако се користат околини, тие обично се складираат во /etc/puppet/environments, root директориумот ќе биде директориумот на животната средина. Ако околините не се користат, root директориумот ќе биде основниот директориум.
• Почнувајќи од четвртата верзија („нова кукла“), употребата на околини стана задолжителна, а основниот директориум беше преместен во /etc/puppetlabs/code. Според тоа, околините се складираат во /etc/puppetlabs/code/environments, root директориумот е директориумот на животната средина.

Мора да има поддиректориум во root директориумот manifests, кој содржи еден или повеќе манифестации кои ги опишуваат јазлите. Покрај тоа, треба да има поддиректориум modules, кој ги содржи модулите. Кои се модулите ќе ви кажам малку подоцна. Покрај тоа, старата Кукла може да има и поддиректориум 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 — означете дали услугата initscript поддржува рестартирање. Ако false а параметарот е наведен рестартирајте — се користи вредноста на овој параметар. Ако false и параметар рестартирајте не е одредено - услугата е запрена и почна да се рестартира (но systemd ја користи командата systemctl restart).
• има статус — означете дали услугата initscript ја поддржува командата status. Ако false, тогаш се користи вредноста на параметарот статус. Стандардно true.

exec

Извршува надворешни команди. Ако не наведете параметри создава, само ако, освен ако или освежување, командата ќе се извршува секогаш кога ќе се изврши Puppet. Може да обработува известувања - извршува команда.

Параметри:

• име на ресурс — команда што треба да се изврши (опционално)
• команда — командата што треба да се изврши (ако не е наведено во името)
• пат — патеки во кои се бара извршната датотека
• само ако — ако командата наведена во овој параметар е завршена со нула повратен код, главната команда ќе се изврши
• освен ако — ако командата наведена во овој параметар е завршена со повратен код кој не е нула, главната команда ќе се изврши
• создава — ако датотеката наведена во овој параметар не постои, главната команда ќе се изврши
• освежување - ако true, тогаш командата ќе се изврши само кога оваа exec ќе добие известување од други ресурси
• cwd — директориум од кој се извршува командата
• корисникот — корисникот од кого да се изврши командата
• услуги - како да ја извршите командата:
  • поксик — едноставно се креира дете процес, задолжително наведете пат
  • школка - командата е лансирана во школка /bin/sh, можеби не е наведено пат, можете да користите глобирање, цевки и други карактеристики на школка. Обично се открива автоматски ако има некои специјални знаци (|, ;, &&, || и така натаму).

cron

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

Параметри:

• име на ресурс - само некаков идентификатор
• обезбеди - крунска држава:
  • present - креирај ако не постои
  • absent - избришете ако постои
• команда - која команда да ја извршите
• животната средина — во која средина да се изврши командата (список на променливи на околината и нивните вредности преку =)
• корисникот — од кој корисник да ја изврши командата
• минута, час, делничен ден, месец, месечен ден — кога да се кандидира cron. Ако некој од овие атрибути не е наведен, неговата вредност во кронтабот ќе биде *.

Во кукла 6.0 cron како да отстранети од кутијата во puppetserver, така што нема документација на општиот сајт. Но тој е во кутијата во кукла-агенс, така што нема потреба да се инсталира посебно. Можете да ја видите документацијата за тоа во документацијата за петтата верзија на КуклаИли на GitHub.

За ресурсите воопшто

Барања за уникатност на ресурсите

Најчеста грешка со која се среќаваме е Дупликат декларација. Оваа грешка се појавува кога два или повеќе ресурси од ист тип со исто име се појавуваат во директориумот.

Затоа пак ќе напишам: манифестациите за истиот јазол не треба да содржат ресурси од ист тип со ист наслов!

Понекогаш има потреба да се инсталираат пакети со исто име, но со различни менаџери на пакети. Во овој случај, треба да го користите параметарот nameза да се избегне грешката:

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

Други видови ресурси имаат слични опции за да се избегне дуплирање - name у Сервис, command у exec, и така натаму.

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

Секој тип на ресурси има некои посебни параметри, без оглед на неговата природа.

Целосна листа на мета параметри во куклената документација.

Кратка листа:

• бараат — овој параметар покажува од кои ресурси зависи овој ресурс.
• пред - Овој параметар одредува кои ресурси зависат од овој ресурс.
• се претплатите — овој параметар одредува од кои ресурси овој ресурс добива известувања.
• извести — Овој параметар одредува кои ресурси добиваат известувања од овој ресурс.

Сите наведени метапараметри прифаќаат или една врска со ресурси или низа врски во квадратни загради.

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

Врската со ресурси е едноставно спомнување на ресурсот. Тие главно се користат за укажување на зависности. Референцирањето на непостоечки ресурс ќе предизвика грешка при компилацијата.

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

Пример:

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 {}. Се разбира, можете едноставно да копирате идентични делови од конфигурацијата, но генерално ова е лошо решение - конфигурацијата расте, и ако го промените општиот дел од конфигурацијата, ќе треба да го уредувате истото на многу места. Во исто време, лесно е да се направи грешка, и воопшто, принципот СУВО (не се повторувај) е измислен со причина.

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

Класи

Класа е именуван блок од попет код. Потребни се часови за повторна употреба на кодот.

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

# Описание класса начинается с ключевого слова 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}"

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

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

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

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

# переменная без пространства имён
$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 vs class{'classname':}

Секоја класа е ресурс од типот класа. Како и со кој било друг тип на ресурс, не може да има два примери од иста класа на истиот јазол.

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

Меѓутоа, доколку користите include, тогаш класата може да се додаде онолку пати колку што сакате. Факт е дека include е идемпотентна функција која проверува дали е додадена класа во директориумот. Ако класата не е во директориумот, ја додава, а ако веќе постои, не прави ништо. Но, во случај на употреба include Не можете да поставите параметри на класата за време на декларацијата на класата - сите потребни параметри мора да бидат поставени во надворешен извор на податоци - Hiera или ENC. За нив ќе зборуваме во следната статија.

Дефинира

Како што беше кажано во претходниот блок, истата класа не може да биде присутна на јазол повеќе од еднаш. Меѓутоа, во некои случаи треба да можете да користите ист блок код со различни параметри на истиот јазол. Со други зборови, постои потреба од сопствен тип на ресурси.

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

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

Во такви случаи, дизајн како што е Дефинирај (дефинира, дефиниран тип, дефиниран тип на ресурси). Дефиниција е слична на класа, но има разлики: прво, секое 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' }
}

Најлесен начин да се фати грешката за декларација на дупликат е во Дефинирање. Ова се случува ако дефиницијата има ресурс со константно име и има два или повеќе случаи на оваа дефиниција на некој јазол.

Лесно е да се заштитите од ова: сите ресурси во дефиницијата мора да имаат име во зависност од $title. Алтернатива е идемпотентно додавање ресурси во наједноставен случај, доволно е да се преместат ресурсите заеднички за сите инстанци на дефиницијата во посебна класа и да се вклучи оваа класа во дефиницијата - функција; include идемпотентен.

Постојат и други начини да се постигне идемотенција при додавање ресурси, имено користење на функции defined и ensure_resources, но ќе ви кажам за тоа во следната епизода.

Зависности и известувања за класи и дефиниции

Класите и дефинициите ги додаваат следниве правила за справување со зависности и известувања:

• зависноста од класа/дефинира додава зависност од сите ресурси на класата/дефинира;
• класа/дефинирај зависност додава зависности на сите класи/дефинирани ресурси;
• известувањето за класа/дефинира ги известува сите ресурси на класата/дефинира;
• класа/дефинира претплата се претплати на сите ресурси на класата/дефинира.

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

Документација овде.

if

Овде е едноставно:

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

освен ако

освен ако е ако е обратно: блокот код ќе се изврши ако изразот е неточен.

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

случај

И тука нема ништо комплицирано. Можете да користите редовни вредности (низи, броеви, итн.), регуларни изрази и типови на податоци како вредности.

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

Селектори

Селекторот е јазична конструкција слична на case, но наместо да изврши блок код, тој враќа вредност.

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

Модули

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

Покрај тоа, постои проблем со повторна употреба на кодот - кога целиот код е во еден манифест, тешко е да се сподели овој код со други. За да ги реши овие два проблеми, Puppet има ентитет наречен модули.

Модули - ова се множества од класи, дефиниции и други куклени ентитети сместени во посебен директориум. Со други зборови, модулот е независно парче од куклената логика. На пример, може да има модул за работа со nginx и тој ќе содржи што и само она што е потребно за работа со nginx, или може да има модул за работа со PHP итн.

Модулите се верзии, а исто така се поддржани зависностите на модулите еден од друг. Постои отворено складиште на модули - Кукла кованица.

На куклен сервер, модулите се наоѓаат во поддиректориумот на модули на root директориумот. Внатре во секој модул има стандардна шема на директориуми - манифестации, датотеки, шаблони, lib итн.

Структура на датотека во модул

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

• manifests - содржи манифести
• files - содржи датотеки
• templates - содржи шаблони
• lib - содржи Руби код

Ова не е комплетна листа на директориуми и датотеки, но за овој напис засега е доволно.

Имиња на ресурси и имиња на датотеки во модулот

Документација овде.

Ресурсите (класи, дефиниции) во модулот не можат да бидат именувани како што сакате. Дополнително, постои директна кореспонденција помеѓу името на ресурсот и името на датотеката во која 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.

шаблони

Сигурно и самите знаете што се шаблони, нема да ги опишам детално овде. Но, ќе го оставам за секој случај линк до Википедија.

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

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

Погледнете ја патеката <modulename>/<filename> имплицира датотека <rootdir>/modules/<modulename>/templates/<filename>.

Покрај тоа, постои функција inline_template — го прима текстот на шаблонот како влез, а не името на датотеката.

Во рамките на шаблоните, можете да ги користите сите променливи на Puppet во тековниот опсег.

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

• Документација на ЕПП.
• ERB документација.

Накратко за ЕРБ

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

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

Изразите во 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 просто выводит сообщение в лог

Формално кажано, факт има име (низа) и вредност (достапни се различни видови: низи, низи, речници). Јадете збир на вградени факти. Можете исто така да напишете своја. Опишани се собирачите на факти како функции во Руби, или како извршни датотеки. Фактите може да се претстават и во форма текстуални датотеки со податоци на јазлите.

За време на работата, куклениот агент прво ги копира сите достапни собирачи на факти од папетсерверот до јазолот, по што ги лансира и ги испраќа собраните факти до серверот; По ова, серверот започнува со составување на каталогот.

Факти во форма на извршни датотеки

Таквите факти се сместени во модули во директориумот facts.d. Се разбира, датотеките мора да бидат извршни. Кога се извршуваат, тие мора да излезат информации на стандарден излез или во формат YAML или key=value.

Не заборавајте дека фактите се однесуваат на сите јазли кои се контролирани од серверот 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 во стара кукла или /etc/puppetlabs/facts.d во новата кукла.

examplefact=examplevalue

---
examplefact2: examplevalue2
anotherfact: anothervalue

Доаѓање до фактите

Постојат два начини да се пристапи кон фактите:

• преку речникот $facts: $facts['fqdn'];
• користејќи го името на фактот како име на променливата: $fqdn.

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

Еве го соодветниот дел од документацијата.

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

Покрај фактите, постои и некои променливи, достапно во глобалниот именски простор.

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

Додаток 1: како да се изврши и дебагира сето ова?

Написот имаше многу примери на куклен код, но воопшто не ни кажа како да го извршиме овој код. Па, се поправам.

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

Агент

Барем од верзијата 5, пакети со кукли-агенти од официјално складиште на Puppetlabs ги содржи сите зависности (рубин и соодветните скапоцени камења), така што нема тешкотии при инсталацијата (зборувам за дистрибуции базирани на 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

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

Можете да го имитирате моделот на работа со туркање - одете до јазолот за кој сте заинтересирани и започнете sudo puppet agent -t. Клуч -t (--test) всушност вклучува неколку опции кои можат да се овозможат поединечно. Овие опции го вклучуваат следново:

• не работи во режим на демон (стандардно агентот започнува во режим на демон);
• исклучете го по примената на каталогот (стандардно, агентот ќе продолжи да работи и ќе ја применува конфигурацијата еднаш на секои половина час);
• напишете детален дневник за работа;
• покажуваат промени во датотеките.

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

Покрај тоа, можете да го овозможите дневникот за дебагирање на делото - во него куклата пишува за сите дејства што ги извршува: за ресурсот што моментално го обработува, за параметрите на овој ресурс, за тоа кои програми ги стартува. Се разбира, ова е параметар --debug.

Сервер

Во овој напис нема да го разгледам целосното поставување на серверот и распоредувањето код на него, ќе кажам само дека надвор од кутијата има целосно функционална верзија на серверот што не бара дополнителна конфигурација за работа со мал број на; јазли (да речеме, до сто). Поголем број јазли ќе бараат подесување - стандардно, куклениот сервер стартува не повеќе од четири работници, за поголеми перформанси треба да го зголемите нивниот број и не заборавајте да ги зголемите границите на меморијата, инаку серверот ќе го собира ѓубрето поголемиот дел од времето.

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

Додаток 2: Упатства за кодирање

1. Ставете ја целата логика во класи и дефиниции.
2. Чувајте ги класите и дефинициите во модули, а не во манифестации кои ги опишуваат јазлите.
3. Користете ги фактите.
4. Не правете ако се базираат на имиња на домаќини.
5. Слободно додавајте параметри за класи и дефиниции - ова е подобро од имплицитната логика скриена во телото на класата/дефинира.

Ќе објаснам зошто препорачувам да го направите ова во следната статија.

Заклучок

Да завршиме со воведот. Во следната статија ќе ви кажам за Hiera, ENC и PuppetDB.

Само регистрирани корисници можат да учествуваат во анкетата. Најави се, вие сте добредојдени.

Всушност, има многу повеќе материјали - можам да пишувам статии на следниве теми, да гласам за што би ве интересирало да прочитате:

• 59,1%Напредни куклени конструкции - некои срања од следното ниво: јамки, мапирање и други ламбда изрази, собирачи на ресурси, извезени ресурси и комуникација меѓу домаќините преку Puppet, ознаки, добавувачи, апстрактни типови податоци.13
• 31,8%„Јас сум админ на мајка ми“ или како ние во Авито се дружевме со неколку попет сервери од различни верзии и, во принцип, делот за администрирање на попет серверот.7
• 81,8%Како пишуваме куклен код: инструментација, документација, тестирање, CI/CD.18

Гласале 22 корисници. 9 корисници беа воздржани.

Извор: www.habr.com