Куурчак конфигурацияларды башкаруу системасы болуп саналат. Ал хостторду каалаган абалга алып келүү жана бул абалды сактоо үчүн колдонулат.

Мен Куурчак менен беш жылдан ашык убакыттан бери иштешип келем. Бул текст түпкүлүгүндө расмий документациянын негизги пункттарынын которулган жана иреттелген жыйнагы болуп саналат, бул жаңы баштагандарга Куурчактын маңызын тез түшүнүүгө мүмкүндүк берет.

негизги маалыматтар

Куурчактын операциялык системасы кардар-сервер, бирок ал чектелген функция менен серверсиз иштөөнү да колдойт.

Операциянын тартуу модели колдонулат: демейки боюнча, ар бир жарым саатта кардарлар конфигурация үчүн сервер менен байланышып, аны колдонушат. Эгер сиз Ansible менен иштеген болсоңуз, анда алар башка түртүү моделин колдонушат: администратор конфигурацияны колдонуу процессин баштайт, кардарлардын өздөрү эч нерсе колдонбойт.

Тармактык байланыш учурунда эки тараптуу TLS шифрлөө колдонулат: сервер менен кардар өздөрүнүн жеке ачкычтарына жана тиешелүү сертификаттарына ээ. Адатта сервер кардарлар үчүн сертификаттарды чыгарат, бирок негизинен тышкы САны колдонууга болот.

Манифесттерге киришүү

Куурчак терминологиясында куурчак серверге туташтыруу түйүндөр (түйүндөрү). Түйүндөр үчүн конфигурация жазылган манифесттерде атайын программалоо тилинде - Puppet DSL.

Куурчак DSL – декларативдик тил. Ал жеке ресурстардын декларациясы түрүндө түйүндүн каалаган абалын сүрөттөйт, мисалы:

Файл бар жана анын белгилүү бир мазмуну бар.
Пакет орнотулду.
Кызмат башталды.

Ресурстар өз ара байланышта болушу мүмкүн:

Көз карандылык бар, алар ресурстарды колдонуу тартибине таасир этет.
Мисалы, "адегенде пакетти орнотуп, андан кийин конфигурация файлын түзөтүңүз, анан кызматты баштаңыз."
Билдирүүлөр бар - бул ресурс өзгөргөн болсо, ага жазылган ресурстарга эскертмелерди жөнөтөт.
Мисалы, конфигурация файлы өзгөрсө, сиз кызматты автоматтык түрдө өчүрө аласыз.

Кошумчалай кетсек, куурчак DSL функциялары жана өзгөрмөлөрү, ошондой эле шарттуу билдирүүлөр жана селекторлор бар. Ар кандай калыптандыруу механизмдери да колдоого алынат - EPP жана ERB.

Куурчак Ruby тилинде жазылган, ошондуктан көптөгөн конструкциялар жана терминдер ошол жерден алынган. Ruby сизге Куурчакты кеңейтүүгө мүмкүндүк берет - татаал логиканы, ресурстардын жаңы түрлөрүн, функцияларды кошуу.

Куурчак иштеп жатканда, сервердеги ар бир белгилүү түйүн үчүн манифесттер каталогго түзүлөт. справочник функциялардын, өзгөрмөлөрдүн маанисин жана шарттуу билдирүүлөрдү кеңейтүүнү эсептөөдөн кийин ресурстардын жана алардын өз ара мамилелеринин тизмеси.

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

Бул жерде келтирилген мисалдар жетишсиз болсо, синтаксисти түшүнүүгө жардам бере турган расмий документтердин бөлүмдөрү:

Манифесттин мисалы:

# Комментарии пишутся, как и много где, после решётки.
#
# Описание конфигурации ноды начинается с ключевого слова 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 }).
Параметрлердеги жебелер бирдей деңгээлде болушу керек.
Алардын алдында ресурстук байланыш жебелери жазылган.

Паппесервердеги файлдардын жайгашкан жери

Көбүрөөк түшүндүрүү үчүн, мен "тамыр каталогу" түшүнүгүн киргизем. Түп каталогу – бул белгилүү бир түйүн үчүн Куурчак конфигурациясын камтыган каталог.

Түп каталогу куурчак версиясына жана колдонулган чөйрөлөргө жараша өзгөрөт. Айлана-чөйрөлөр өзүнчө каталогдордо сакталган конфигурациялардын өз алдынча топтомдору. Көбүнчө git менен айкалыштырып колдонулат, мында чөйрөлөр гит бутактарынан түзүлөт. Демек, ар бир түйүн тигил же бул чөйрөдө жайгашкан. Муну түйүндүн өзүндө же ENCде конфигурациялоого болот, ал жөнүндө мен кийинки макалада айтам.

Үчүнчү версияда ("эски куурчак") базалык каталог болгон /etc/puppet. Айлана-чөйрөнү колдонуу милдеттүү эмес - мисалы, биз аларды эски Куурчак менен колдонбойбуз. Эгерде чөйрөлөр колдонулса, алар адатта сакталат /etc/puppet/environments, түпкү каталог айлана-чөйрөнүн каталогу болот. Эгерде чөйрөлөр колдонулбаса, түпкү каталог негизги каталог болот.
Төртүнчү версиядан баштап («жаңы куурчак») чөйрөлөрдү колдонуу милдеттүү болуп, базалык каталог көчүрүлгөн. /etc/puppetlabs/code. Демек, чөйрөлөр сакталат /etc/puppetlabs/code/environments, түпкү каталог - бул чөйрө каталогу.

Түп каталогунда подкаталог болушу керек manifestsтүйүндөрдү сүрөттөгөн бир же бир нече манифестти камтыйт. Мындан тышкары, бир подкаталог болушу керек modules, ал модулдарды камтыйт. Кандай модулдар бар экенин бир аздан кийин айтам. Мындан тышкары, эски Куурчактын да подкаталоги болушу мүмкүн files, анда биз түйүндөргө көчүрүүчү ар кандай файлдар камтылган. Жаңы куурчакта бардык файлдар модулдарга жайгаштырылат.

Манифест файлдарынын кеңейтилиши бар .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

Ресурстун түрлөрү

Колдоого алынган ресурс түрлөрүнүн толук тизмесин бул жерден тапса болот документтерде, бул жерде мен беш негизги түрүн сүрөттөп берем, алар менин практикамда көпчүлүк маселелерди чечүү үчүн жетиштүү.

билэ

Файлдарды, каталогдорду, символдук шилтемелерди, алардын мазмунун жана кирүү укуктарын башкарат.

Options:

ресурстун аталышы — файлга жол (милдеттүү эмес)
жол — файлга жол (эгерде ал атында көрсөтүлбөсө)
камсыз кылуу - файл түрү:
- absent - файлды жок кылуу
- present — кандайдыр бир типтеги файл болушу керек (эгер файл жок болсо, кадимки файл түзүлөт)
- file - кадимки файл
- directory - каталог
- link - символдук шилтеме
ыраазы — файлдын мазмуну (кадимки файлдар үчүн гана ылайыктуу, аны менен бирге колдонууга болбойт булак же бута)
булак — файлдын мазмунун көчүрүүнү каалаган жолдун шилтемеси (менен бирге колдонууга болбойт ыраазы же бута). Схемасы бар URI катары көрсөтүлүшү мүмкүн puppet: (анда куурчак серверинин файлдары колдонулат) жана схема менен http: (Мен бул учурда эмне болору түшүнүктүү деп үмүттөнөм), ал тургай, диаграмма менен file: же схемасы жок абсолюттук жол катары (андан кийин түйүндөгү жергиликтүү FS файлы колдонулат)
бута — символдук шилтеме кайсы жерди көрсөтүү керек (менен бирге колдонууга болбойт ыраазы же булак)
ээси — файлга ээлик кылуучу колдонуучу
группа — файл таандык болушу керек болгон топ
режими - файл уруксаттары (сап катары)
кайталоо - рекурсивдүү каталогду иштетүүгө мүмкүндүк берет
тазалоо - Куурчакта сүрөттөлбөгөн файлдарды жок кылууга мүмкүндүк берет
күч - Куурчакта сүрөттөлбөгөн каталогдорду жок кылууга мүмкүндүк берет

таңгак

Пакеттерди орнотот жана жок кылат. Билдирмелерди иштете алат - параметр көрсөтүлгөн болсо, пакетти кайра орнотот reinstall_on_refresh.

Options:

ресурстун аталышы - пакеттин аталышы (милдеттүү эмес)
ысым - пакеттин аталышы (атында көрсөтүлбөсө)
камсыздоочу — колдонуу үчүн пакет менеджери
камсыз кылуу - пакеттин каалаган абалы:
- present, installed - орнотулган каалаган версия
- latest - акыркы версия орнотулган
- absent - жок кылынды (apt-get remove)
- purged — конфигурация файлдары менен кошо өчүрүлгөн (apt-get purge)
- held - пакет версиясы кулпуланган (apt-mark hold)
- любая другая строка — көрсөтүлгөн версия орнотулду
reinstall_on_refresh - Эгер true, анда эскертмени алгандан кийин пакет кайра орнотулат. Түзүү параметрлерин өзгөртүүдө пакеттерди кайра куруу зарыл болушу мүмкүн болгон булактарга негизделген бөлүштүрүүлөр үчүн пайдалуу. Демейки false.

кызмат

Кызматтарды башкарат. Билдирмелерди иштете алат - кызматты кайра иштетет.

Options:

ресурстун аталышы - башкарылуучу кызмат (милдеттүү эмес)
ысым — башкарууга муктаж болгон кызмат (атында көрсөтүлбөсө)
камсыз кылуу - кызматтын каалаган абалы:
- running - ишке киргизди
- stopped - токтоду
иштетүү — кызматты баштоо мүмкүнчүлүгүн көзөмөлдөйт:
- true — автоматтык иштетүү иштетилген (systemctl enable)
- mask - жашырылган (systemctl mask)
- false — autorun өчүрүлгөн (systemctl disable)
кайра жүргүзүү - кызматты кайра иштетүү буйругу
абал — кызмат абалын текшерүү буйругу
кайра баштоо — кызмат initscript кайра иштетүүнү колдойбу же жокпу көрсөтөт. Эгерде false жана параметр көрсөтүлөт кайра жүргүзүү — бул параметрдин мааниси колдонулат. Эгерде false жана параметр кайра жүргүзүү көрсөтүлгөн эмес - кызмат токтоп, кайра иштей баштады (бирок systemd буйругун колдонот systemctl restart).
hasstatus — кызмат initscript команданы колдой тургандыгын көрсөтөт status. эгер false, анда параметр мааниси колдонулат абал. Демейки true.

Шмидт

Тышкы буйруктарды иштетет. Эгер сиз параметрлерди көрсөтпөсөңүз жараткан, onlyif, башкача каралбаса, же жаңылануу менен, команда Куурчак иштетилген сайын аткарылат. Билдирмелерди иштетүүгө жөндөмдүү - буйрукту иштетет.

Options:

ресурстун аталышы - аткарыла турган буйрук (милдеттүү эмес)
буйрук — аткарыла турган команда (эгерде ал атында көрсөтүлбөсө)
жол — аткарылуучу файлды издей турган жолдор
onlyif — эгерде бул параметрде көрсөтүлгөн команда нөлдүк кайтаруу коду менен толукталса, негизги команда аткарылат
башкача каралбаса, — эгерде бул параметрде көрсөтүлгөн команда нөл эмес кайтаруу коду менен бүтсө, негизги буйрук аткарылат
жараткан — эгерде бул параметрде көрсөтүлгөн файл жок болсо, анда негизги команда аткарылат
жаңылануу менен - Эгер true, анда буйрук бул аткаруучу башка ресурстардан эскертме алганда гана иштетилет
cwd — команданы иштете турган каталог
колдонуучу — буйрукту кимден иштете турган колдонуучу
камсыздоочу - буйрукту кантип иштетүү керек:
- POSIX — бала процесси жөн гана түзүлөт, сөзсүз түрдө тактаңыз жол
- жумуртканын кабыгы - команда кабыкчада ишке киргизилет /bin/sh, белгиленбеши мүмкүн жол, сиз globbing, түтүктөрдү жана башка кабык өзгөчөлүктөрүн колдоно аласыз. Көбүнчө кандайдыр бир өзгөчө белгилер болгондо автоматтык түрдө аныкталат (|, ;, &&, || жана башка).

Мурунку

Cronjobs көзөмөлдөйт.

Options:

ресурстун аталышы - жөн гана идентификатордун кандайдыр бир түрү
камсыз кылуу - таажы абалы:
- present - эгерде жок болсо түзүү
- absent - бар болсо, жок кылуу
буйрук - чуркоо үчүн кандай команда
айлана-чөйрө — команданы кайсы чөйрөдө иштетүү керек (чөйрө өзгөрмөлөрүнүн тизмеси жана алардын маанилери аркылуу =)
колдонуучу — команданы кайсы колдонуучудан аткаруу керек
мүнөт, саат, иш күнү, ай, айдын күнү — качан cron иштетүү керек. Эгерде бул атрибуттардын бири көрсөтүлбөсө, анын crontabдагы мааниси болот *.

Куурчак 6.0 Мурунку сыяктуу кутудан алынып салынды куурчак серверинде, ошондуктан жалпы сайтта эч кандай документация жок. Бирок ал кутуда турат куурчак-агентте, ошондуктан аны өзүнчө орнотуунун кереги жок. Сиз ал үчүн документтерди көрө аласыз куурчак бешинчи версиясынын документтериндеже GitHub боюнча.

Жалпысынан ресурстар жөнүндө

Ресурстун уникалдуулугуна талаптар

Биз кабылган эң көп ката Кайталанма декларация. Бул ката каталогдо бирдей аталыштагы эки же андан көп ресурстар пайда болгондо пайда болот.

Ошондуктан, мен дагы бир жолу жазам: бир түйүн үчүн манифесттер бирдей аталыштагы бир түрдөгү ресурстарды камтыбашы керек!

Кээде бир эле аталыштагы, бирок башка пакет менеджерлери менен пакеттерди орнотуу зарылчылыгы келип чыгат. Бул учурда, сиз параметрди колдонуу керек nameкатаны болтурбоо үчүн:

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

Башка ресурстун түрлөрүн кайталоону болтурбоо үчүн окшош параметрлери бар - name у кызмат, command у Шмидт, жана башка.

Метапараметрлер

Ар бир ресурс түрү, анын мүнөзүнө карабастан, кээ бир өзгөчө параметрлери бар.

Мета параметрлердин толук тизмеси куурчак документтеринде.

Кыска тизме:

талап кылуу — бул параметр бул ресурс кайсы ресурстарга көз каранды экенин көрсөтөт.
мурун - Бул параметр кайсы ресурстар бул ресурска көз каранды экендигин аныктайт.
жазылуу — бул параметр бул ресурс билдирүүлөрдү кайсы ресурстардан алаарын аныктайт.
билдирүү — Бул параметр кайсы ресурстар бул ресурстан эскертмелерди алаарын аныктайт.

Бардык саналып өткөн метапараметрлер бир ресурстук шилтемени же төрт бурчтуу кашаадагы шилтемелердин массивдерин кабыл алат.

Ресурстарга шилтемелер

Ресурстук шилтеме бул булак жөнүндө жөн гана сөз. Алар негизинен көз карандылыкты көрсөтүү үчүн колдонулат. Болбогон булакка шилтеме жасоо компиляция катасын жаратат.

Шилтеменин синтаксиси төмөнкүдөй: баш тамга менен ресурс түрү (эгерде типтин аталышында кош чекиттер бар болсо, анда эки чекиттин ортосундагы аталыштын ар бир бөлүгү баш тамга менен жазылат), андан кийин төрт бурчтуу кашаанын ичинде ресурстун аталышы (аттын иши өзгөрбөйт!). Боштуктар болбошу керек, типтин аталышынан кийин төрт бурчтуу кашаалар жазылат.

мисалы:

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

Көз карандылыктар жана эскертмелер

Документтер бул жерде.

Жогоруда айтылгандай, ресурстардын ортосундагы жөнөкөй көз карандылык өтмө болуп саналат. Баса, көз карандылыкты кошууда этият болуңуз - сиз циклдик көз карандылыктарды түзө аласыз, бул компиляция катасын жаратат.

Көз карандылыктан айырмаланып, эскертмелер өтмө эмес. Төмөнкү эрежелер эскертүүлөр үчүн колдонулат:

Ресурс эскертме алса, ал жаңыланат. Жаңыртуу аракеттери ресурстун түрүнө жараша болот - Шмидт буйругун аткарат, кызмат кызматты кайра иштетет, таңгак пакетти кайра орнотот. Ресурста жаңыртуу аракети аныкталбаса, анда эч нерсе болбойт.
Куурчакты бир иштетүү учурунда ресурс бир жолудан көп эмес жаңыртылып турат. Бул мүмкүн, анткени эскертмелер көз карандылыкты камтыйт жана көз карандылык графиги циклдерди камтыбайт.
Эгерде Куурчак ресурстун абалын өзгөртсө, ресурс ага жазылган бардык ресурстарга эскертмелерди жөнөтөт.
Ресурс жаңыртылган болсо, ага жазылган бардык ресурстарга эскертмелерди жөнөтөт.

Белгисиз параметрлерди иштетүү

Эреже катары, кандайдыр бир ресурс параметринин демейки мааниси жок болсо жана бул параметр манифестте көрсөтүлбөсө, анда Куурчак түйүндөгү тиешелүү ресурс үчүн бул касиетти өзгөртпөйт. Мисалы, эгерде бул ресурс түрү билэ параметр көрсөтүлгөн эмес owner, анда Куурчак тиешелүү файлдын ээсин өзгөртпөйт.

Класстарга, өзгөрмөлөргө жана аныктамаларга киришүү

Бизде конфигурациянын бирдей бөлүгүнө ээ болгон бир нече түйүн бар дейли, бирок айырмачылыктар да бар - антпесе биз муну бир блокто сүрөттөп бере алабыз. 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 орнотуу үчүн колдонсо болот.

Бул үчүн эмне кылуу керек өзгөрмөлөрдү колдонуу.

Көңүл буруңуз: куурчактагы өзгөрмөлөр өзгөрүлгүс!

Мындан тышкары, өзгөрмө жарыялангандан кийин гана жеткиликтүү болот, антпесе өзгөрмөнүн мааниси 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',   # задаём параметры класса точно так же, как параметры для других ресурсов
  }
}

Куурчакта өзгөрмөлөр терилген. же көп маалымат түрлөрү. Маалымат түрлөрү, адатта, класстарга жана аныктамаларга өткөн параметр маанилерин текшерүү үчүн колдонулат. Өткөрүлгөн параметр көрсөтүлгөн түргө дал келбесе, компиляция катасы пайда болот.

Түрү параметр аталышынын алдында дароо жазылат:

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

Класстар: класс атын камтыйт жана класс {'класс аты':}

Ар бир класс бул түрдүн булагы тап. Ресурстун башка түрүндөгүдөй эле, бир түйүндө бир класстын эки нускасы болушу мүмкүн эмес.

Эгерде сиз классты бир эле түйүнгө эки жолу кошууга аракет кылсаңыз class { 'classname':} (эч кандай айырмасы жок, ар кандай же бирдей параметрлер менен), компиляция катасы болот. Бирок, эгер сиз классты ресурс стилинде колдонсоңуз, анын бардык параметрлерин манифестте дароо ачык орното аласыз.

Бирок, колдонсоңуз include, анда класс каалаганча көп жолу кошулушу мүмкүн. Чындыгында ошол include класстын каталогго кошулганын текшерген идемпотент функциясы. Эгерде класс каталогдо жок болсо, аны кошот, ал эми ал мурда бар болсо, эч нерсе кылбайт. Ал эми пайдаланган учурда include класс декларациясы учурунда класс параметрлерин орното албайсыз - бардык талап кылынган параметрлер тышкы маалымат булагында коюлушу керек - Hiera же ENC. Алар тууралуу кийинки макалада сөз кылабыз.

аныктайт

Мурунку блокто айтылгандай, бир эле класс түйүндө бир нече жолу болушу мүмкүн эмес. Бирок, кээ бир учурларда сиз бир эле түйүндө ар кандай параметрлери менен бир эле блокту колдоно билишиңиз керек. Башкача айтканда, өзүнүн ресурс түрүнө муктаждык бар.

Мисалы, PHP модулун орнотуу үчүн, биз Avitoдо төмөнкүлөрдү жасайбыз:

Бул модул менен пакетти орнотуу.
Келгиле, бул модул үчүн конфигурация файлын түзөлү.
Биз php-fpm үчүн конфигурацияга символдук шилтеме түзөбүз.
Биз php cli үчүн конфигурацияга символдук шилтеме түзөбүз.

Мындай учурларда, мисалы, дизайн аныктоо (аныктоо, аныкталган тип, аныкталган ресурс түрү). A 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 {
  ...
}

башкача каралбаса,

if тескери болбосо: эгер туюнтма жалган болсо, код блогу аткарылат.

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

окуя

Бул жерде да татаал эч нерсе жок. Маани катары кадимки маанилерди (саптар, сандар ж.б.), кадимки туюнтмаларды жана маалымат түрлөрүн колдоно аласыз.

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

Селекторлор

Селектор - бул окшош тил конструкциясы case, бирок код блогун аткаруунун ордуна, ал маанини кайтарат.

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

модулдар

Конфигурация кичинекей болгондо, аны оңой эле бир манифестте сактоого болот. Бирок биз канчалык көп конфигурацияларды сүрөттөсөк, манифестте ошончолук көп класстар жана түйүндөр бар, ал өсөт жана аны менен иштөө ыңгайсыз болуп калат.

Мындан тышкары, кодду кайра колдонуу көйгөйү бар - бардык код бир манифестте болгондо, бул кодду башкалар менен бөлүшүү кыйын. Бул эки маселени чечүү үчүн, куурчак модулдар деп аталган объектке ээ.

модулдар - бул өзүнчө каталогго жайгаштырылган класстардын, аныктамалардын жана башка Куурчак объектилердин топтому. Башка сөз менен айтканда, модуль куурчак логикасынын көз карандысыз бөлүгү болуп саналат. Мисалы, nginx менен иштөө үчүн модуль болушу мүмкүн жана анда nginx менен иштөө үчүн эмне жана эмне керек болсо, же РНР менен иштөө үчүн модуль болушу мүмкүн ж.б.у.с.

Модулдар версияланган жана модулдардын бири-бирине көз карандылыгы да колдоого алынат. модулдардын ачык репозиторий бар - Куурчак сарайы.

Куурчак серверде модулдар түпкү каталогдун модулдар подкаталогунда жайгашкан. Ар бир модулдун ичинде стандарттык каталог схемасы бар - манифесттер, файлдар, шаблондор, lib жана башкалар.

Модулдагы файл структурасы

Модулдун тамыры сүрөттөмө аталыштары бар төмөнкү каталогдорду камтышы мүмкүн:

manifests - манифесттерди камтыйт
files - ал файлдарды камтыйт
templates - бул шаблондорду камтыйт
lib — ал Ruby кодун камтыйт

Бул каталогдордун жана файлдардын толук тизмеси эмес, бирок азырынча бул макала үчүн жетиштүү.

Модулдагы ресурстардын аттары жана файлдардын аттары

Документтер бул жерде.

Модулдагы ресурстарды (класстар, аныктамалар) сиз каалагандай атай албайт. Кошумчалай кетсек, бул ресурстун аталышы менен Куурчак ал ресурстун сүрөттөлүшүн издей турган файлдын аталышынын ортосунда түз кат алышуу бар. Эгер сиз ат коюу эрежелерин бузсаңыз, анда Куурчак ресурстун сүрөттөмөсүн таппай калат жана сиз компиляция катасын аласыз.

Эрежелер жөнөкөй:

Модулдагы бардык ресурстар модулдун аталыш мейкиндигинде болушу керек. Эгерде модуль чакырылса 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 — ал файлдын атын эмес, калыптын текстин киргизүү катары кабыл алат.

Калыптардын ичинде сиз учурдагы масштабдагы бардык куурчак өзгөрмөлөрүн колдоно аласыз.

Куурчак 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 релизинин кандай экенине жараша, пакеттин тигил же бул версиясын орнотуу керек. Мунун баарын кол менен көзөмөлдөй аласыз, эгер түйүндөр өзгөрсө манифесттерди кайра жаза аласыз. Бирок бул олуттуу мамиле эмес, автоматташтыруу алда канча жакшы;

Түйүндөр жөнүндө маалымат алуу үчүн, Куурчакта фактылар деп аталган механизм бар. маалымат - бул глобалдык аттар мейкиндигинде кадимки өзгөрмөлөр түрүндөгү манифесттерде жеткиликтүү түйүн жөнүндө маалымат. Мисалы, хосттун аталышы, операциялык системанын версиясы, процессордун архитектурасы, колдонуучулардын тизмеси, тармак интерфейстеринин тизмеси жана алардын даректери жана башка көптөгөн нерселер. Фактылар манифесттерде жана шаблондордо кадимки өзгөрмөлөр катары жеткиликтүү.

Фактылар менен иштөөнүн мисалы:

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

Формалдуу түрдө айтканда, фактынын аты (сап) жана мааниси бар (ар кандай түрлөрү бар: саптар, массивдер, сөздүктөр). же орнотулган фактылардын жыйындысы. Сиз да өзүңүздүн жазсаңыз болот. Факты жыйноочулар баяндалган Ruby'деги функциялар сыяктуу, же кантип аткарылуучу файлдар. Фактыларды формада да келтирсе болот маалыматтар менен текст файлдары түйүндөрүндө.

Иштөө учурунда куурчак агент адегенде паппесерверден түйүнгө бардык колдо болгон фактыларды чогултуучуларды көчүрөт, андан кийин аларды ишке киргизет жана чогултулган фактыларды серверге жөнөтөт; Андан кийин сервер каталогду түзө баштайт.

Аткарылуучу файлдар түрүндөгү фактылар

Мындай фактылар каталогдо модулдарга жайгаштырылат facts.d. Албетте, файлдар аткарылуучу болушу керек. Иштеп жатканда, алар маалыматты YAML же ачкыч=маани форматында стандарттык чыгарууга чыгарышы керек.

Фактылар сиздин модулуңуз орнотулган poppet сервери башкарган бардык түйүндөргө тиешелүү экенин унутпаңыз. Ошондуктан, скриптте, системада сиздин ишиңиз үчүн зарыл болгон бардык программалар жана файлдар бар экендигин текшериңиз.

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

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

Ruby фактылары

Мындай фактылар каталогдо модулдарга жайгаштырылат 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).

Бул жерде документтердин тиешелүү бөлүмү.

Камтылган өзгөрмөлөр

Фактылардан тышкары дагы бар кээ бир өзгөрмөлөр, глобалдык аттар мейкиндигинде жеткиликтүү.

ишеничтүү фактылар — кардардын сертификатынан алынган өзгөрмөлөр (сертификат адатта poppet серверинде берилгендиктен, агент анын сертификатын жөн эле алып, өзгөртө албайт, ошондуктан өзгөрмөлөр "ишенимдүү" болуп саналат): сертификаттын аталышы, сертификаттын аталышы хост жана домен, сертификаттан кеңейтүүлөр.
сервердик фактылар — сервер тууралуу маалыматка байланыштуу өзгөрмөлөр — версия, аты, сервердин IP дареги, чөйрө.
агент фактылары — фактор боюнча эмес, түздөн-түз куурчак-агент тарабынан кошулган өзгөрмөлөр — сертификаттын аталышы, агент версиясы, куурчак версиясы.
негизги өзгөрмөлөр - Pappetmaster өзгөрмөлөрү (sic!). Бул болжол менен ошол эле сервердик фактылар, плюс конфигурация параметринин маанилери бар.
компилятор өзгөрмөлөр — ар бир чөйрөдө айырмаланган компилятордук өзгөрмөлөр: учурдагы модулдун аталышы жана учурдагы объектке кирген модулдун аталышы. Алар, мисалы, жеке класстарыңыздын башка модулдардан түздөн-түз колдонулбагандыгын текшерүү үчүн колдонулушу мүмкүн.

1-тиркеме: мунун баарын кантип иштетүү жана оңдоо керек?

Макалада куурчак кодунун көптөгөн мисалдары камтылган, бирок бул кодду кантип иштетүү керектиги такыр айтылган эмес. Мейли, мен өзүмдү оңдоп жатам.

Куурчакты иштетүү үчүн агент жетиштүү, бирок көпчүлүк учурда сизге сервер керек болот.

агент

Жок дегенде 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.

Server

Мен бул макалада паппетсерверди толук орнотууну жана ага кодду киргизүүнү карабайм, мен аз сандагы серверлер менен иштөө үчүн кошумча конфигурацияны талап кылбаган сервердин толук функционалдык версиясы бар экенин гана айтам; түйүндөр (айталы, жүзгө чейин). Түйүндөрдүн көбүрөөк саны жөндөөнү талап кылат - демейки боюнча, куурчак сервери төрт жумушчудан ашык эмес ишке киргизет, көбүрөөк иштөө үчүн алардын санын көбөйтүү керек жана эстутум чектөөлөрүн көбөйтүүнү унутпаңыз, антпесе сервер көпчүлүк учурда таштандыларды чогултат.

Кодду жайылтуу - эгер сизге тез жана оңой керек болсо, анда караңыз (r10k)[https://github.com/puppetlabs/r10k], кичинекей орнотуулар үчүн бул жетиштүү болушу керек.

2-тиркеме: Коддоо боюнча көрсөтмөлөр

Бардык логиканы класстарга жана аныктамаларга жайгаштырыңыз.
Класстарды жана аныктамаларды түйүндөрдү сүрөттөгөн манифесттерде эмес, модулдарда сактаңыз.
Фактыларды колдонуңуз.
Хост аттарынын негизинде ifs жасабаңыз.
Класстар жана аныктамалар үчүн параметрлерди кошуудан тартынбаңыз - бул класстын/аныктоолордун денесинде жашырылган жашыруун логикага караганда жакшыраак.

Эмне үчүн мен муну кийинки макалада сунуш кылам.

жыйынтыктоо

Келгиле, кириш сөз менен бүтүрөлү. Кийинки макалада мен Hiera, ENC жана PuppetDB жөнүндө айтып берем.

Сурамжылоого катталган колдонуучулар гана катыша алышат. Кирүү, өтүнөмүн.

Чынында, дагы көп материалдар бар - мен төмөнкү темалар боюнча макалаларды жаза алам, сизди эмнени окугуңуз келсе, добуш бере алам:

59,1%Өркүндөтүлгөн куурчак конструкциялары - кийинки деңгээлдеги кээ бир нерселер: циклдер, карта түзүү жана башка ламбда туюнтмалары, ресурс чогултуучулар, экспорттолгон ресурстар жана Куурчак аркылуу хосттор аралык байланыш, тэгдер, провайдерлер, абстракттуу маалымат түрлөрү.13
31,8%"Мен апамдын администраторумун" же биз Авитодо ар кандай версиядагы бир нече poppet серверлери менен кантип достошконубуз жана, негизинен, poppet серверин башкаруу бөлүгү.7
81,8%Биз куурчак кодун кантип жазабыз: приборлор, документтер, тестирлөө, CI/CD.18

22 колдонуучу добуш берди. 9 колдонуучу добуш берүүдөн баш тартты.

Source: www.habr.com

Куурчакка киришүү

негизги маалыматтар

Манифесттерге киришүү

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

Паппесервердеги файлдардын жайгашкан жери

Бир нече согуштук мисалдар

Түйүндүн сүрөттөлүшү жана андагы ресурс

Түйүндөгү ресурстардын ортосундагы байланыштар

Ресурстун түрлөрү

билэ

таңгак

кызмат

Шмидт

Мурунку

Жалпысынан ресурстар жөнүндө

Ресурстун уникалдуулугуна талаптар

Метапараметрлер

Ресурстарга шилтемелер

Көз карандылыктар жана эскертмелер

Белгисиз параметрлерди иштетүү

Класстарга, өзгөрмөлөргө жана аныктамаларга киришүү

класстар

өзгөрмөлөр

Класстар: класс атын камтыйт жана класс {'класс аты':}

аныктайт

Класстар жана аныктамалар үчүн көз карандылыктар жана эскертмелер

Шарттуу операторлор жана селекторлор

if

башкача каралбаса,

окуя

Селекторлор

модулдар

Модулдагы файл структурасы

Модулдагы ресурстардын аттары жана файлдардын аттары

Калып:

ERB жөнүндө кыскача

Шаблонду колдонуунун мисалы

Фактылар жана орнотулган өзгөрмөлөр

Аткарылуучу файлдар түрүндөгү фактылар

Ruby фактылары

Тексттик фактылар

Фактыларга баруу

Камтылган өзгөрмөлөр

1-тиркеме: мунун баарын кантип иштетүү жана оңдоо керек?

агент

Server

2-тиркеме: Коддоо боюнча көрсөтмөлөр

жыйынтыктоо

Чынында, дагы көп материалдар бар - мен төмөнкү темалар боюнча макалаларды жаза алам, сизди эмнени окугуңуз келсе, добуш бере алам: