ProHoster > Blog > Ma'muriyat > Qo'g'irchoqqa kirish

Qo'g'irchoqqa kirish

Qo'g'irchoq - bu konfiguratsiyani boshqarish tizimi. U xostlarni kerakli holatga keltirish va shu holatni saqlab qolish uchun ishlatiladi.

Men qo‘g‘irchoq bilan besh yildan ortiq vaqtdan beri ishlayapman. Ushbu matn aslida rasmiy hujjatlarning asosiy fikrlarini tarjima qilingan va qayta tartiblangan kompilyatsiya bo'lib, yangi boshlanuvchilarga Qo'g'irchoqning mohiyatini tezda tushunishga imkon beradi.

Qo'g'irchoqqa kirish

Asosiy ma'lumotlar

Qo'g'irchoqning operatsion tizimi mijoz-serverdir, garchi u cheklangan funksionallik bilan serversiz ishlashni ham qo'llab-quvvatlaydi.

Operatsiyaning tortish modeli qo'llaniladi: sukut bo'yicha, har yarim soatda bir marta, mijozlar konfiguratsiya uchun serverga murojaat qilishadi va uni qo'llashadi. Agar siz Ansible bilan ishlagan bo'lsangiz, ular boshqa surish modelidan foydalanadilar: administrator konfiguratsiyani qo'llash jarayonini boshlaydi, mijozlar o'zlari hech narsa qo'llamaydilar.

Tarmoq aloqasi vaqtida ikki tomonlama TLS shifrlash qo'llaniladi: server va mijoz o'zlarining shaxsiy kalitlari va tegishli sertifikatlariga ega. Odatda server mijozlar uchun sertifikatlar chiqaradi, lekin printsipial jihatdan tashqi CA dan foydalanish mumkin.

Manifestlarga kirish

Qo'g'irchoq terminologiyasida qo'g'irchoq serverga ulanmoq tugunlar (tugunlar). Tugunlar uchun konfiguratsiya yozilgan manifestlarda maxsus dasturlash tilida - Puppet DSL.

Qo'g'irchoq DSL - deklarativ til. U tugunning istalgan holatini individual resurslar deklaratsiyasi shaklida tasvirlaydi, masalan:

  • Fayl mavjud va u o'ziga xos tarkibga ega.
  • Paket o'rnatildi.
  • Xizmat boshlandi.

Resurslar o'zaro bog'lanishi mumkin:

  • Bog'liqliklar mavjud, ular resurslardan foydalanish tartibiga ta'sir qiladi.
    Masalan, "avval paketni o'rnating, keyin konfiguratsiya faylini tahrirlang, so'ngra xizmatni ishga tushiring."
  • Bildirishnomalar mavjud - agar resurs o'zgargan bo'lsa, u obuna bo'lgan resurslarga bildirishnomalarni yuboradi.
    Misol uchun, agar konfiguratsiya fayli o'zgartirilsa, siz xizmatni avtomatik ravishda qayta ishga tushirishingiz mumkin.

Bundan tashqari, Qo'g'irchoq DSL funksiyalari va o'zgaruvchilari, shuningdek, shartli bayonotlar va selektorlarga ega. Har xil shablonlash mexanizmlari ham qo'llab-quvvatlanadi - EPP va ERB.

Qo'g'irchoq Ruby tilida yozilgan, shuning uchun ko'plab konstruktsiyalar va atamalar u erdan olingan. Ruby sizga Qo'g'irchoqni kengaytirish imkonini beradi - murakkab mantiq, resurslarning yangi turlari, funktsiyalarni qo'shing.

Qo'g'irchoq ishlayotganda, serverdagi har bir aniq tugun uchun manifestlar katalogga kompilyatsiya qilinadi. katalog funksiyalar, o'zgaruvchilar qiymatini hisoblash va shartli bayonotlarni kengaytirishdan keyin resurslar va ularning munosabatlari ro'yxati.

Sintaksis va kod uslubi

Agar taqdim etilgan misollar etarli bo'lmasa, sintaksisni tushunishga yordam beradigan rasmiy hujjatlarning bo'limlari:

Manifestning qanday ko'rinishiga misol:

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

Chiziq va qator uzilishlari manifestning majburiy qismi emas, lekin tavsiya etiladi uslubiy qo'llanma. Xulosa:

  • Ikki bo'shliqdan iborat bo'shliqlar, yorliqlar ishlatilmaydi.
  • Jingalak qavslar bo'sh joy bilan ajratiladi, ikki nuqta bo'sh joy bilan ajratilmaydi.
  • Har bir parametrdan keyin vergul, shu jumladan oxirgisi. Har bir parametr alohida satrda joylashgan. Parametrsiz va bitta parametrsiz holat uchun istisno qilingan: siz bitta satrga va vergulsiz yozishingiz mumkin (ya'ni. resource { 'title': } и resource { 'title': param => value }).
  • Parametrlardagi o'qlar bir xil darajada bo'lishi kerak.
  • Resurs munosabatlari o'qlari ularning oldida yozilgan.

Pappetserverda fayllarning joylashuvi

Qo'shimcha tushuntirish uchun men "ildiz katalogi" tushunchasini kiritaman. Ildiz katalogi ma'lum bir tugun uchun Qo'g'irchoq konfiguratsiyasini o'z ichiga olgan katalogdir.

Ildiz katalogi Qoʻgʻirchoq versiyasiga va foydalanilgan muhitga qarab oʻzgaradi. Muhitlar alohida kataloglarda saqlanadigan mustaqil konfiguratsiyalar to'plamidir. Odatda git bilan birgalikda ishlatiladi, bu holda muhitlar git shoxlaridan yaratiladi. Shunga ko'ra, har bir tugun u yoki bu muhitda joylashgan. Bu tugunning o'zida yoki ENCda sozlanishi mumkin, bu haqda men keyingi maqolada gaplashaman.

  • Uchinchi versiyada ("eski qo'g'irchoq") asosiy katalog edi /etc/puppet. Muhitlardan foydalanish ixtiyoriydir - masalan, biz ularni eski Qo'g'irchoq bilan ishlatmaymiz. Agar muhit ishlatilsa, ular odatda saqlanadi /etc/puppet/environments, ildiz katalogi muhit katalogi bo'ladi. Agar muhit ishlatilmasa, asosiy katalog asosiy katalog bo'ladi.
  • To'rtinchi versiyadan boshlab ("yangi qo'g'irchoq") muhitlardan foydalanish majburiy bo'ldi va asosiy katalog ko'chirildi. /etc/puppetlabs/code. Shunga ko'ra, muhitlar saqlanadi /etc/puppetlabs/code/environments, ildiz katalogi atrof-muhit katalogidir.

Ildiz katalogida pastki katalog bo'lishi kerak manifests, unda tugunlarni tavsiflovchi bir yoki bir nechta manifest mavjud. Bundan tashqari, pastki katalog bo'lishi kerak modules, unda modullar mavjud. Qaysi modullar borligini biroz keyinroq aytib beraman. Bundan tashqari, eski Qo'g'irchoq ham pastki katalogga ega bo'lishi mumkin files, unda biz tugunlarga nusxa ko'chiradigan turli xil fayllar mavjud. Yangi Qo'g'irchoqda barcha fayllar modullarga joylashtirilgan.

Manifest fayllari kengaytmaga ega .pp.

Bir nechta jangovar misollar

Tugunning tavsifi va undagi resurs

Tugunda server1.testdomain fayl yaratilishi kerak /etc/issue mazmuni bilan Debian GNU/Linux n l. Fayl foydalanuvchi va guruhga tegishli bo'lishi kerak root, kirish huquqlari bo'lishi kerak 644.

Biz manifest yozamiz:

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 в начале будет воспринято как записанное в восьмеричной системе, и всё пойдёт не так, как задумано
    }
}

Tugundagi resurslar o'rtasidagi munosabatlar

Tugunda server2.testdomain nginx oldindan tayyorlangan konfiguratsiya bilan ishlayotgan bo'lishi kerak.

Keling, muammoni ajratamiz:

  • Paket o'rnatilishi kerak nginx.
  • Konfiguratsiya fayllarini serverdan nusxalash kerak.
  • Xizmat ishga tushishi kerak nginx.
  • Agar konfiguratsiya yangilangan bo'lsa, xizmatni qayta ishga tushirish kerak.

Biz manifest yozamiz:

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 получает уведомление,
  # соответствующий сервис перезапускается.
}

Buning ishlashi uchun sizga qo'g'irchoq serverida taxminan quyidagi fayl joylashuvi kerak bo'ladi:

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

Resurs turlari

Qo'llab-quvvatlanadigan manba turlarining to'liq ro'yxatini bu yerda topishingiz mumkin hujjatlarda, bu erda men beshta asosiy turni tasvirlab beraman, ular mening amaliyotimda ko'pchilik muammolarni hal qilish uchun etarli.

Fayl

Fayllar, kataloglar, symlinks, ularning mazmuni va kirish huquqlarini boshqaradi.

Parametrlar:

  • resurs nomi - faylga yo'l (ixtiyoriy)
  • Yo'l - faylga yo'l (agar u nomda ko'rsatilmagan bo'lsa)
  • ta'minlash - fayl turi:
    • absent - faylni o'chirish
    • present — har qanday turdagi fayl bo'lishi kerak (agar fayl bo'lmasa, oddiy fayl yaratiladi)
    • file - oddiy fayl
    • directory - katalog
    • link - ramziy bog'lanish
  • kontent — fayl mazmuni (faqat oddiy fayllar uchun mos, bilan birga foydalanilmaydi manba yoki maqsad)
  • manba — fayl mazmunini koʻchirmoqchi boʻlgan yoʻlga havola (bilan birga ishlatib boʻlmaydi kontent yoki maqsad). Sxema bilan URI sifatida belgilanishi mumkin puppet: (keyin qo'g'irchoq serveridagi fayllar ishlatiladi) va sxema bilan http: (Umid qilamanki, bu holatda nima bo'lishi aniq) va hatto diagramma bilan file: yoki sxemasiz mutlaq yo'l sifatida (keyin tugundagi mahalliy FS faylidan foydalaniladi)
  • maqsad — symlink qayerga ishora qilishi kerak (bilan birga ishlatib boʻlmaydi kontent yoki manba)
  • egasi — faylga egalik qilishi kerak bo‘lgan foydalanuvchi
  • guruh — fayl tegishli bo'lishi kerak bo'lgan guruh
  • usul - fayl ruxsatnomalari (satr sifatida)
  • takrorlash - kataloglarni rekursiv qayta ishlash imkonini beradi
  • tozalash - Qo'g'irchoqda tasvirlanmagan fayllarni o'chirish imkonini beradi
  • kuch - Qo'g'irchoqda tasvirlanmagan kataloglarni o'chirish imkonini beradi

To'plami

Paketlarni o'rnatadi va o'chiradi. Bildirishnomalarni boshqarish imkoniyati - agar parametr ko'rsatilgan bo'lsa, paketni qayta o'rnatadi reinstall_on_refresh.

Parametrlar:

  • resurs nomi - paket nomi (ixtiyoriy)
  • ism - paket nomi (agar nomda ko'rsatilmagan bo'lsa)
  • Provayderi — foydalanish uchun paket menejeri
  • ta'minlash - paketning istalgan holati:
    • present, installed - har qanday versiya o'rnatilgan
    • latest - so'nggi versiya o'rnatilgan
    • absent - o'chirildi (apt-get remove)
    • purged — konfiguratsiya fayllari bilan birga oʻchirildi (apt-get purge)
    • held - paket versiyasi qulflangan (apt-mark hold)
    • любая другая строка — belgilangan versiya oʻrnatilgan
  • reinstall_on_refresh - agar true, keyin bildirishnoma olingandan so'ng paket qayta o'rnatiladi. Qurilish parametrlarini o'zgartirganda paketlarni qayta tiklash zarur bo'lishi mumkin bo'lgan manbaga asoslangan tarqatish uchun foydalidir. Standart false.

xizmat

Xizmatlarni boshqaradi. Bildirishnomalarni qayta ishlashga qodir - xizmatni qayta ishga tushiradi.

Parametrlar:

  • resurs nomi — boshqariladigan xizmat (ixtiyoriy)
  • ism — boshqarilishi kerak boʻlgan xizmat (agar nomda koʻrsatilmagan boʻlsa)
  • ta'minlash - xizmatning istalgan holati:
    • running - ishga tushirildi
    • stopped - to'xtadi
  • imkon — xizmatni ishga tushirish imkoniyatini nazorat qiladi:
    • true — avtomatik ishga tushirish yoqilgan (systemctl enable)
    • mask - niqoblangan (systemctl mask)
    • false - autorun o'chirilgan (systemctl disable)
  • qayta ishga tushirish - xizmatni qayta ishga tushirish buyrug'i
  • holat — xizmat holatini tekshirish buyrug'i
  • qayta ishga tushirish — xizmat initscript qayta ishga tushirishni qo'llab-quvvatlashini ko'rsating. Agar false va parametr belgilanadi qayta ishga tushirish — ushbu parametrning qiymati ishlatiladi. Agar false va parametr qayta ishga tushirish ko'rsatilmagan - xizmat to'xtatildi va qayta ishga tusha boshladi (lekin systemd buyrug'idan foydalanadi systemctl restart).
  • egalik holati — xizmat initscripti buyruqni qo'llab-quvvatlashini ko'rsating status. agar false, keyin parametr qiymati ishlatiladi holat. Standart true.

exec

Tashqi buyruqlarni bajaradi. Agar siz parametrlarni ko'rsatmasangiz yaratadi, faqat agar, Agar bo'lmasa yoki yangilangan holda, buyruq har safar Qo'g'irchoq ishga tushirilganda bajariladi. Bildirishnomalarni qayta ishlashga qodir - buyruqni bajaradi.

Parametrlar:

  • resurs nomi — bajariladigan buyruq (ixtiyoriy)
  • buyruq — bajariladigan buyruq (agar u nomda ko‘rsatilmagan bo‘lsa)
  • Yo'l — bajariladigan faylni izlash yoʻllari
  • faqat agar — agar ushbu parametrda ko‘rsatilgan buyruq nol qaytaruvchi kod bilan to‘ldirilgan bo‘lsa, asosiy buyruq bajariladi
  • Agar bo'lmasa - agar ushbu parametrda ko'rsatilgan buyruq nolga teng bo'lmagan qaytarish kodi bilan to'ldirilgan bo'lsa, asosiy buyruq bajariladi.
  • yaratadi — agar ushbu parametrda ko'rsatilgan fayl mavjud bo'lmasa, asosiy buyruq bajariladi
  • yangilangan holda - agar true, keyin buyruq faqat ushbu ijrochi boshqa manbalardan bildirishnoma olganida ishga tushadi
  • cwd — buyruqni ishga tushirish uchun katalog
  • foydalanuvchi — buyruqni ishga tushirish uchun foydalanuvchi
  • Provayderi - buyruqni qanday bajarish kerak:
    • posix — bola jarayoni oddiygina yaratilgan, aniq belgilashni unutmang Yo'l
    • chig'anoq - buyruq qobiqda ishga tushiriladi /bin/sh, belgilanmasligi mumkin Yo'l, siz globbing, quvurlar va boshqa qobiq xususiyatlaridan foydalanishingiz mumkin. Agar maxsus belgilar mavjud bo'lsa, odatda avtomatik ravishda aniqlanadi (|, ;, &&, || va boshqalar).

cron

Cronjoblarni boshqaradi.

Parametrlar:

  • resurs nomi - shunchaki qandaydir identifikator
  • ta'minlash - toj holati:
    • present - agar mavjud bo'lmasa yaratish
    • absent - agar mavjud bo'lsa, o'chirish
  • buyruq - qanday buyruqni bajarish kerak
  • atrof-muhit — buyruqni qaysi muhitda ishga tushirish kerak (muhit o'zgaruvchilari ro'yxati va ularning qiymatlari orqali =)
  • foydalanuvchi — buyruqni qaysi foydalanuvchidan bajarishi
  • daqiqa, soat, ish kuni, oy, oy kuni — cronni qachon ishga tushirish kerak. Agar ushbu atributlardan birortasi ko'rsatilmagan bo'lsa, uning crontabdagi qiymati bo'ladi *.

Qo'g'irchoq 6.0 da cron go'yo qutidan olib tashlangan qo'g'irchoq serverida, shuning uchun umumiy saytda hech qanday hujjat yo'q. Lekin u qutida joylashgan qo'g'irchoq-agentda, shuning uchun uni alohida o'rnatishga hojat yo'q. Buning uchun hujjatlarni ko'rishingiz mumkin Qo'g'irchoqning beshinchi versiyasi uchun hujjatlarda, yoki GitHub-da.

Umuman olganda, resurslar haqida

Resursning o'ziga xosligiga qo'yiladigan talablar

Biz duch keladigan eng keng tarqalgan xato Ikki nusxadagi deklaratsiya. Bu xatolik katalogda bir xil nomdagi ikki yoki undan ortiq bir xil turdagi resurslar paydo bo'lganda yuzaga keladi.

Shuning uchun men yana yozaman: bir xil tugun uchun manifestlar bir xil nomdagi bir xil turdagi resurslarni o'z ichiga olmaydi!

Ba'zan bir xil nomdagi paketlarni o'rnatish zarurati tug'iladi, lekin turli paket menejerlari bilan. Bunday holda siz parametrdan foydalanishingiz kerak namexatolikka yo'l qo'ymaslik uchun:

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

Boshqa resurs turlari takrorlanishning oldini olishga yordam beradigan shunga o'xshash variantlarga ega - name у xizmat, command у exec, va hokazo.

Metaparametrlar

Har bir resurs turi, tabiatidan qat'i nazar, ba'zi maxsus parametrlarga ega.

Meta parametrlarning to'liq ro'yxati Qo'g'irchoq hujjatlarida.

Qisqa ro'yxat:

  • talab qiladi — bu parametr ushbu resurs qaysi resurslarga bog‘liqligini ko‘rsatadi.
  • oldin - Ushbu parametr qaysi resurslar ushbu resursga bog'liqligini belgilaydi.
  • obuna — bu parametr ushbu resurs xabarnomalarni qaysi manbalardan olishini belgilaydi.
  • xabar berish — Bu parametr qaysi manbalar ushbu resursdan bildirishnomalarni olishini belgilaydi.

Ro'yxatdagi barcha metaparametrlar bitta manba havolasini yoki kvadrat qavs ichidagi havolalar qatorini qabul qiladi.

Resurslarga havolalar

Resurs havolasi shunchaki resurs haqida eslatma. Ular asosan bog'liqliklarni ko'rsatish uchun ishlatiladi. Mavjud bo'lmagan resursga havola qilish kompilyatsiya xatosiga olib keladi.

Bog'lanish sintaksisi quyidagicha: bosh harf bilan resurs turi (agar tur nomi qo'sh nuqtadan iborat bo'lsa, u holda ikki nuqta orasidagi nomning har bir qismi bosh harf bilan yoziladi), so'ngra kvadrat qavs ichida manba nomi (nomning ishi) o'zgarmaydi!). Bo'sh joy bo'lmasligi kerak, kvadrat qavslar tur nomidan keyin darhol yoziladi.

Misol:

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

Bog'liqlar va bildirishnomalar

Hujjatlar bu yerda.

Yuqorida aytib o'tilganidek, resurslar o'rtasidagi oddiy bog'liqliklar o'tish xususiyatiga ega. Aytgancha, bog'liqliklarni qo'shishda ehtiyot bo'ling - siz tsiklik bog'liqliklar yaratishingiz mumkin, bu esa kompilyatsiya xatosini keltirib chiqaradi.

Bog'liqlardan farqli o'laroq, bildirishnomalar o'tishli emas. Bildirishnomalar uchun quyidagi qoidalar qo'llaniladi:

  • Agar resurs bildirishnoma olsa, u yangilanadi. Yangilash harakatlari resurs turiga bog'liq - exec buyruqni bajaradi, xizmat xizmatni qayta ishga tushiradi, To'plami paketni qayta o'rnatadi. Agar resursda yangilanish harakati aniqlanmagan bo'lsa, unda hech narsa bo'lmaydi.
  • Qo'g'irchoqning bir marta ishlashi davomida resurs ko'pi bilan bir marta yangilanadi. Bu mumkin, chunki bildirishnomalar bog'liqlikni o'z ichiga oladi va bog'liqlik grafigida tsikllar mavjud emas.
  • Agar Qo'g'irchoq resurs holatini o'zgartirsa, resurs unga obuna bo'lgan barcha resurslarga bildirishnomalarni yuboradi.
  • Agar resurs yangilangan bo'lsa, u obuna bo'lgan barcha manbalarga bildirishnomalarni yuboradi.

Aniqlanmagan parametrlarga ishlov berish

Qoidaga ko'ra, agar biron bir resurs parametri standart qiymatga ega bo'lmasa va bu parametr manifestda ko'rsatilmagan bo'lsa, u holda Qo'g'irchoq tugundagi mos manba uchun bu xususiyatni o'zgartirmaydi. Misol uchun, agar turdagi resurs bo'lsa Fayl parametr belgilanmagan owner, keyin Qo'g'irchoq mos keladigan faylning egasini o'zgartirmaydi.

Sinflar, o'zgaruvchilar va ta'riflar bilan tanishish

Aytaylik, bizda konfiguratsiyaning bir xil qismiga ega bo'lgan bir nechta tugunlar mavjud, ammo farqlar ham bor - aks holda biz barchasini bitta blokda tasvirlashimiz mumkin. node {}. Albatta, siz shunchaki konfiguratsiyaning bir xil qismlarini nusxalashingiz mumkin, lekin umuman olganda, bu yomon yechim - konfiguratsiya o'sib boradi va agar siz konfiguratsiyaning umumiy qismini o'zgartirsangiz, ko'p joylarda bir xil narsani tahrirlashingiz kerak bo'ladi. Shu bilan birga, xato qilish oson va umuman olganda, DRY (o'zingizni takrorlamang) printsipi biron bir sababga ko'ra ixtiro qilingan.

Ushbu muammoni hal qilish uchun bunday dizayn mavjud класс.

Sinflar

sinf poppet kodining nomlangan blokidir. Kodni qayta ishlatish uchun sinflar kerak.

Avval sinfni tavsiflash kerak. Tavsifning o'zi hech qanday manbani qo'shmaydi. Sinf manifestlarda tasvirlangan:

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

Shundan so'ng sinfdan foydalanish mumkin:

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

Oldingi topshiriqdan misol - keling, nginx-ning o'rnatilishi va konfiguratsiyasini sinfga o'tkazamiz:

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
}

O'zgaruvchilar

Oldingi misoldagi sinf umuman moslashuvchan emas, chunki u har doim bir xil nginx konfiguratsiyasini olib keladi. Keling, konfiguratsiya o'zgaruvchisiga yo'lni yarataylik, keyin bu sinf har qanday konfiguratsiya bilan nginxni o'rnatish uchun ishlatilishi mumkin.

Buni amalga oshirish mumkin o'zgaruvchilar yordamida.

Diqqat: Qo'g'irchoqdagi o'zgaruvchilar o'zgarmasdir!

Bundan tashqari, o'zgaruvchiga faqat e'lon qilinganidan keyin kirish mumkin, aks holda o'zgaruvchining qiymati undef.

O'zgaruvchilar bilan ishlashga misol:

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

Qo'g'irchoq bor nom maydonlari, va o'zgaruvchilar, mos ravishda, ega ko'rish maydoni: Xuddi shu nomdagi o'zgaruvchini turli nomlar maydonlarida aniqlash mumkin. O'zgaruvchining qiymatini echishda o'zgaruvchi joriy nomlar maydonida, so'ngra qo'shuvchi nomlar maydonida va hokazolarda qidiriladi.

Nom maydoniga misollar:

  • global - sinf yoki tugun tavsifidan tashqaridagi o'zgaruvchilar u erga boradi;
  • tugun tavsifidagi tugun nom maydoni;
  • sinf tavsifidagi sinf nomlari maydoni.

O'zgaruvchiga kirishda noaniqlikni oldini olish uchun o'zgaruvchi nomida nom maydonini belgilashingiz mumkin:

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

Keling, nginx konfiguratsiyasiga yo'l o'zgaruvchida ekanligiga rozi bo'laylik $nginx_conf_source. Keyin sinf quyidagicha ko'rinadi:

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
}

Biroq, keltirilgan misol yomon, chunki sinf ichida falon nomli o'zgaruvchidan foydalaniladigan "maxfiy bilimlar" mavjud. Ushbu bilimlarni umumiy qilish ancha to'g'ri - sinflar parametrlarga ega bo'lishi mumkin.

Sinf parametrlari sinf nomlari maydonidagi o'zgaruvchilar bo'lib, ular sinf sarlavhasida ko'rsatilgan va sinf tanasidagi oddiy o'zgaruvchilar kabi ishlatilishi mumkin. Parametr qiymatlari manifestda sinfdan foydalanganda belgilanadi.

Parametr standart qiymatga o'rnatilishi mumkin. Agar parametr standart qiymatga ega bo'lmasa va foydalanilganda qiymat o'rnatilmagan bo'lsa, u kompilyatsiya xatosini keltirib chiqaradi.

Keling, yuqoridagi misoldan sinfni parametrlashtiramiz va ikkita parametr qo'shamiz: birinchisi, talab qilinadigan, konfiguratsiyaga yo'l, ikkinchisi, ixtiyoriy, nginx bilan paketning nomi (masalan, Debian'da paketlar mavjud). 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',   # задаём параметры класса точно так же, как параметры для других ресурсов
  }
}

Qo'g'irchoqda o'zgaruvchilar yoziladi. Yemoq ko'p ma'lumotlar turlari. Ma'lumotlar turlari odatda sinflar va ta'riflarga o'tkazilgan parametr qiymatlarini tekshirish uchun ishlatiladi. O'tkazilgan parametr belgilangan turga mos kelmasa, kompilyatsiya xatosi paydo bo'ladi.

Tur parametr nomidan oldin darhol yoziladi:

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

Sinflar: sinf nomi va sinf nomini o'z ichiga oladi{'classname':}

Har bir sinf bir turdagi resursdir sinf. Resursning boshqa turlarida bo'lgani kabi, bitta tugunda bir xil sinfning ikkita nusxasi bo'lishi mumkin emas.

Agar siz ikki marta bir xil tugunga sinf qo'shishga harakat qilsangiz class { 'classname':} (farq yo'q, turli yoki bir xil parametrlar bilan), kompilyatsiya xatosi bo'ladi. Ammo agar siz resurs uslubida sinfdan foydalansangiz, darhol uning barcha parametrlarini manifestda aniq belgilashingiz mumkin.

Biroq, agar foydalansangiz include, keyin sinfni xohlagancha ko'p marta qo'shish mumkin. Gap shundaki include idempotent funksiya bo'lib, katalogga sinf qo'shilganligini tekshiradi. Agar sinf katalogda bo'lmasa, uni qo'shadi va agar u allaqachon mavjud bo'lsa, u hech narsa qilmaydi. Ammo foydalanish holatida include Sinf deklaratsiyasida siz sinf parametrlarini o'rnatolmaysiz - barcha kerakli parametrlar tashqi ma'lumotlar manbasida o'rnatilishi kerak - Hiera yoki ENC. Ular haqida keyingi maqolada gaplashamiz.

Aniqlaydi

Oldingi blokda aytilganidek, bir xil sinf tugunda bir necha marta bo'lishi mumkin emas. Biroq, ba'zi hollarda siz bir xil tugundagi turli parametrlarga ega bir xil kod blokidan foydalanish imkoniyatiga ega bo'lishingiz kerak. Boshqacha aytganda, o'ziga xos resurs turiga ehtiyoj bor.

Masalan, PHP modulini o'rnatish uchun Avito'da quyidagilarni bajaramiz:

  1. Paketni ushbu modul bilan o'rnating.
  2. Keling, ushbu modul uchun konfiguratsiya faylini yaratamiz.
  3. Biz php-fpm uchun konfiguratsiyaga simli havola yaratamiz.
  4. Biz PHP cli uchun konfiguratsiyaga simli havola yaratamiz.

Bunday hollarda dizayn kabi aniqlash (aniqlash, belgilangan tur, belgilangan resurs turi). Define sinfga o'xshaydi, lekin farqlari bor: birinchidan, har bir Define resurs emas, resurs turidir; ikkinchidan, har bir ta'rif yashirin parametrga ega $title, resurs nomi e'lon qilinganda qayerga ketadi. Xuddi sinflarda bo'lgani kabi, birinchi navbatda ta'rifni tasvirlash kerak, shundan so'ng undan foydalanish mumkin.

PHP moduli bilan soddalashtirilgan misol:

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' }
}

Takroriy deklaratsiya xatosini aniqlashning eng oson yo'li Ta'rifda. Bu, agar ta'rif doimiy nomga ega bo'lgan manbaga ega bo'lsa va ba'zi tugunlarda bu ta'rifning ikki yoki undan ortiq nusxalari mavjud bo'lsa sodir bo'ladi.

O'zingizni bundan himoya qilish juda oson: ta'rif ichidagi barcha manbalar shunga qarab nomga ega bo'lishi kerak $title. Shu bilan bir qatorda resurslarning idempotent qo'shilishi; eng oddiy holatda, ta'rifning barcha misollari uchun umumiy bo'lgan resurslarni alohida sinfga ko'chirish va bu sinfni ta'rif - funktsiyaga kiritish kifoya. include idempotent.

Resurslarni qo'shishda identifikatsiyaga erishishning boshqa usullari mavjud, xususan, funktsiyalardan foydalanish defined и ensure_resources, lekin bu haqda keyingi qismda aytib beraman.

Sinflar va ta'riflar uchun bog'liqliklar va bildirishnomalar

Sinflar va ta'riflar bog'liqliklar va bildirishnomalarni boshqarish uchun quyidagi qoidalarni qo'shadi:

  • sinfga bog'liqlik/aniqlash sinfning barcha resurslariga bog'liqliklarni qo'shadi/aniqlash;
  • sinf/aniqlash bog'liqligi barcha sinflarga bog'liqliklarni qo'shadi/resurslarni aniqlaydi;
  • class/define bildirishnomasi sinf/aniqlashning barcha resurslarini xabardor qiladi;
  • class/define obunasi sinf/define ning barcha resurslariga obuna bo'ladi.

Shartli gaplar va selektorlar

Hujjatlar bu yerda.

if

Bu erda hamma narsa oddiy:

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

Agar bo'lmasa

if teskari bo'lmasa: ifoda noto'g'ri bo'lsa, kod bloki bajariladi.

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

hodisa

Bu erda ham murakkab narsa yo'q. Qiymat sifatida siz oddiy qiymatlardan (satrlar, raqamlar va boshqalar), oddiy iboralar va ma'lumotlar turlaridan foydalanishingiz mumkin.

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

Selektorlar

Selektor - shunga o'xshash til konstruktsiyasi case, lekin kod blokini bajarish o'rniga u qiymatni qaytaradi.

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

Moduli

Agar konfiguratsiya kichik bo'lsa, uni bitta manifestda osongina saqlash mumkin. Ammo biz qanchalik ko'p konfiguratsiyalarni tasvirlasak, manifestda qanchalik ko'p sinflar va tugunlar mavjud bo'lsa, u o'sib boradi va u bilan ishlash noqulay bo'ladi.

Bundan tashqari, kodni qayta ishlatish muammosi mavjud - agar barcha kodlar bitta manifestda bo'lsa, bu kodni boshqalar bilan bo'lishish qiyin. Ushbu ikkita muammoni hal qilish uchun Puppet modul deb nomlangan ob'ektga ega.

Moduli - bu alohida katalogga joylashtirilgan sinflar, ta'riflar va boshqa qo'g'irchoq ob'ektlar to'plami. Boshqacha qilib aytganda, modul qo'g'irchoq mantig'ining mustaqil qismidir. Misol uchun, nginx bilan ishlash uchun modul bo'lishi mumkin va u nginx bilan ishlash uchun nima va faqat nima kerakligini o'z ichiga oladi yoki PHP bilan ishlash uchun modul bo'lishi mumkin va hokazo.

Modullar versiyalashtirilgan va modullarning bir-biriga bog'liqligi ham qo'llab-quvvatlanadi. Modullarning ochiq ombori mavjud - Qo'g'irchoq uyi.

Qo'g'irchoq serverida modullar ildiz katalogining modullar pastki katalogida joylashgan. Har bir modul ichida standart katalog sxemasi mavjud - manifestlar, fayllar, shablonlar, lib va ​​boshqalar.

Moduldagi fayl tuzilishi

Modulning ildizida tavsiflovchi nomli quyidagi kataloglar bo'lishi mumkin:

  • manifests - unda manifestlar mavjud
  • files - unda fayllar mavjud
  • templates - unda shablonlar mavjud
  • lib - u Ruby kodini o'z ichiga oladi

Bu kataloglar va fayllarning to'liq ro'yxati emas, lekin hozircha ushbu maqola uchun etarli.

Moduldagi resurslarning nomlari va fayllar nomlari

Hujjatlar bu yerda.

Moduldagi manbalarni (sinflar, ta'riflar) siz xohlagan tarzda nomlash mumkin emas. Bundan tashqari, Resurs nomi va Qo'g'irchoq ushbu resurs tavsifini qidiradigan fayl nomi o'rtasida to'g'ridan-to'g'ri yozishmalar mavjud. Agar siz nomlash qoidalarini buzsangiz, Qo'g'irchoq shunchaki manba tavsifini topa olmaydi va siz kompilyatsiya xatosini olasiz.

Qoidalar oddiy:

  • Moduldagi barcha resurslar modul nomlari maydonida bo'lishi kerak. Agar modul chaqirilsa foo, keyin undagi barcha resurslar nomlanishi kerak foo::<anything>, yoki shunchaki foo.
  • Modul nomi bilan resurs faylda bo'lishi kerak init.pp.
  • Boshqa manbalar uchun fayl nomlash sxemasi quyidagicha:
    • modul nomi bilan prefiks o'chiriladi
    • barcha qoʻsh nuqtalar, agar mavjud boʻlsa, qiyshiq chiziq bilan almashtiriladi
    • kengaytma qo'shiladi .pp

Men misol bilan ko'rsataman. Aytaylik, men modul yozyapman nginx. U quyidagi manbalarni o'z ichiga oladi:

  • класс nginx manifestda tasvirlangan init.pp;
  • класс nginx::service manifestda tasvirlangan service.pp;
  • aniqlash nginx::server manifestda tasvirlangan server.pp;
  • aniqlash nginx::server::location manifestda tasvirlangan server/location.pp.

Shablonlar

Shablonlar nima ekanligini o'zingiz bilasiz, men ularni bu erda batafsil tasvirlamayman. Lekin har ehtimolga qarshi uni qoldiraman Vikipediyaga havola.

Shablonlardan qanday foydalanish: Shablonning ma'nosi funksiya yordamida kengaytirilishi mumkin template, shablonga yo'l uzatiladi. Turdagi resurslar uchun Fayl parametr bilan birga ishlatiladi content. Masalan, bu kabi:

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

Yo'lni ko'rish <modulename>/<filename> faylni nazarda tutadi <rootdir>/modules/<modulename>/templates/<filename>.

Bundan tashqari, funktsiya mavjud inline_template — u fayl nomini emas, shablon matnini kiritish sifatida qabul qiladi.

Shablonlar ichida siz joriy doiradagi barcha Qo'g'irchoq o'zgaruvchilardan foydalanishingiz mumkin.

Qo'g'irchoq ERB va EPP formatidagi shablonlarni qo'llab-quvvatlaydi:

ERB haqida qisqacha

Nazorat tuzilmalari:

  • <%= ВЫРАЖЕНИЕ %> — ifoda qiymatini kiriting
  • <% ВЫРАЖЕНИЕ %> — ifoda qiymatini hisoblash (qo‘shmasdan). Shartli iboralar (if) va tsikllar (har biri) odatda bu erga boradi.
  • <%# КОММЕНТАРИЙ %>

ERB-dagi ifodalar Ruby-da yozilgan (ERB aslida Embedded Ruby).

Manifestdagi o'zgaruvchilarga kirish uchun siz qo'shishingiz kerak @ o'zgaruvchi nomiga. Tekshirish konstruktsiyasidan keyin paydo bo'ladigan qatorni olib tashlash uchun siz yopish tegidan foydalanishingiz kerak -%>.

Shablondan foydalanishga misol

Aytaylik, men ZooKeeperni boshqarish uchun modul yozyapman. Konfiguratsiyani yaratish uchun mas'ul bo'lgan sinf quyidagicha ko'rinadi:

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'),
  }
}

Va tegishli shablon zoo.cfg.erb - Shunday qilib:

<% 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 -%>

Faktlar va o'rnatilgan o'zgaruvchilar

Ko'pincha konfiguratsiyaning o'ziga xos qismi tugunda nima sodir bo'layotganiga bog'liq. Masalan, Debian versiyasi nima ekanligiga qarab, paketning u yoki bu versiyasini o'rnatishingiz kerak. Bularning barchasini qo'lda kuzatishingiz mumkin, agar tugunlar o'zgarsa, manifestlarni qayta yozishingiz mumkin. Ammo bu jiddiy yondashuv emas, avtomatlashtirish ancha yaxshi.

Tugunlar haqida ma'lumot olish uchun qo'g'irchoq faktlar deb ataladigan mexanizmga ega. Faktlar - bu global nomlar maydonida oddiy o'zgaruvchilar ko'rinishidagi manifestlarda mavjud bo'lgan tugun haqida ma'lumot. Masalan, xost nomi, operatsion tizim versiyasi, protsessor arxitekturasi, foydalanuvchilar ro'yxati, tarmoq interfeyslari ro'yxati va ularning manzillari va boshqalar. Faktlar manifest va shablonlarda oddiy o'zgaruvchilar sifatida mavjud.

Faktlar bilan ishlashga misol:

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

Rasmiy ravishda, faktning nomi (string) va qiymati bor (har xil turlari mavjud: satrlar, massivlar, lug'atlar). Yemoq o'rnatilgan faktlar to'plami. O'zingiz ham yozishingiz mumkin. Fakt yig'uvchilar tasvirlangan Ruby'dagi funktsiyalar kabiyoki qanday qilib bajariladigan fayllar. Faktlar shaklda ham taqdim etilishi mumkin ma'lumotlarga ega matnli fayllar tugunlarda.

Ish paytida qo'g'irchoq agenti avvalo pappetserverdan tugunga barcha mavjud fakt yig'uvchilarni ko'chiradi, shundan so'ng u ularni ishga tushiradi va to'plangan faktlarni serverga yuboradi; Shundan so'ng, server katalogni tuzishni boshlaydi.

Bajariladigan fayllar ko'rinishidagi faktlar

Bunday faktlar katalogdagi modullarga joylashtirilgan facts.d. Albatta, fayllar bajariladigan bo'lishi kerak. Ishga tushirilganda, ular ma'lumotni YAML yoki kalit = qiymat formatida standart chiqishga chiqarishlari kerak.

Shuni unutmangki, faktlar sizning modulingiz joylashtirilgan poppet server tomonidan boshqariladigan barcha tugunlarga tegishli. Shuning uchun, skriptda tizimda sizning haqiqatingiz ishlashi uchun zarur bo'lgan barcha dasturlar va fayllar mavjudligini tekshirishga e'tibor bering.

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

Ruby faktlar

Bunday faktlar katalogdagi modullarga joylashtirilgan 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

Matnli faktlar

Bunday faktlar katalogdagi tugunlarga joylashtiriladi /etc/facter/facts.d eski qo'g'irchoqda yoki /etc/puppetlabs/facts.d yangi qo'g'irchoqda.

examplefact=examplevalue
---
examplefact2: examplevalue2
anotherfact: anothervalue

Faktlarga kirish

Faktlarga yondashishning ikki yo'li mavjud:

  • lug'at orqali $facts: $facts['fqdn'];
  • fakt nomini o'zgaruvchi nomi sifatida ishlatish: $fqdn.

Lug'atdan foydalanish yaxshidir $facts, yoki undan ham yaxshiroq, global nom maydonini ko'rsating ($::facts).

Bu erda hujjatlarning tegishli bo'limi.

O'rnatilgan o'zgaruvchilar

Faktlardan tashqari, yana bir bor ba'zi o'zgaruvchilar, global nomlar maydonida mavjud.

  • ishonchli faktlar — mijoz sertifikatidan olinadigan oʻzgaruvchilar (sertifikat odatda poppet serverda chiqarilganligi sababli, agent shunchaki sertifikatni olib oʻzgartira olmaydi, shuning uchun oʻzgaruvchilar “ishonchli” boʻladi): sertifikat nomi, sertifikat nomi xost va domen, sertifikatdan kengaytmalar.
  • server faktlari —server haqidagi maʼlumotlarga tegishli oʻzgaruvchilar—versiya, nomi, server IP manzili, muhit.
  • agent faktlari — fakter boʻyicha emas, balki toʻgʻridan-toʻgʻri qoʻgʻirchoq-agent tomonidan qoʻshilgan oʻzgaruvchilar — sertifikat nomi, agent versiyasi, qoʻgʻirchoq versiyasi.
  • asosiy o'zgaruvchilar - Pappetmaster o'zgaruvchilari (sic!). Bu taxminan bir xil server faktlari, plyus konfiguratsiya parametrlari qiymatlari mavjud.
  • kompilyator o'zgaruvchilari — har bir sohada farq qiluvchi kompilyator oʻzgaruvchilari: joriy modul nomi va joriy obʼyektga murojaat qilingan modul nomi. Ular, masalan, sizning shaxsiy sinflaringiz to'g'ridan-to'g'ri boshqa modullardan foydalanilmasligini tekshirish uchun ishlatilishi mumkin.

1-qo'shimcha: bularning barchasini qanday ishga tushirish va disk raskadrovka qilish kerak?

Maqolada qo'g'irchoq kodining ko'plab misollari mavjud edi, ammo bu kodni qanday ishlatish haqida bizga umuman aytilmagan. Xo'sh, men o'zimni tuzataman.

Qo'g'irchoqni ishga tushirish uchun agent yetarli, lekin ko'p hollarda sizga server ham kerak bo'ladi.

Agent

Hech bo'lmaganda XNUMX-versiyadan boshlab, qo'g'irchoq-agent paketlari rasmiy Puppetlabs ombori barcha bog'liqliklarni o'z ichiga oladi (ruby va tegishli qimmatbaho toshlar), shuning uchun o'rnatishda hech qanday qiyinchiliklar yo'q (men Debian-ga asoslangan tarqatishlar haqida gapiryapman - biz RPM-ga asoslangan taqsimotlardan foydalanmaymiz).

Eng oddiy holatda, qo'g'irchoq konfiguratsiyasidan foydalanish uchun agentni serversiz rejimda ishga tushirish kifoya: agar qo'g'irchoq kod tugunga ko'chirilgan bo'lsa, ishga tushiring. 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

Albatta, serverni o'rnatish va agentlarni demon rejimida tugunlarda ishga tushirish yaxshiroq - keyin har yarim soatda ular serverdan yuklab olingan konfiguratsiyani qo'llaydilar.

Ishning surish modeliga taqlid qilishingiz mumkin - sizni qiziqtirgan tugunga o'ting va boshlang sudo puppet agent -t. Kalit -t (--test) aslida alohida-alohida yoqish mumkin bo'lgan bir nechta variantni o'z ichiga oladi. Ushbu variantlarga quyidagilar kiradi:

  • demon rejimida ishlamang (sukut bo'yicha agent demon rejimida ishga tushadi);
  • katalogni qo'llaganingizdan so'ng o'chiring (sukut bo'yicha agent ishlashni davom ettiradi va har yarim soatda bir marta konfiguratsiyani qo'llaydi);
  • batafsil ish jurnalini yozing;
  • fayllardagi o'zgarishlarni ko'rsatish.

Agentda o'zgarishsiz ishlash rejimi mavjud - siz to'g'ri konfiguratsiyani yozganingizga ishonchingiz komil bo'lmaganda va ish paytida agent nimani o'zgartirishini tekshirishni xohlasangiz, undan foydalanishingiz mumkin. Ushbu rejim parametr tomonidan yoqilgan --noop buyruq satrida: sudo puppet agent -t --noop.

Bundan tashqari, siz ishning disk raskadrovka jurnalini yoqishingiz mumkin - unda qo'g'irchoq o'zi bajaradigan barcha harakatlar haqida yozadi: hozirda ishlov berilayotgan resurs haqida, ushbu resursning parametrlari, qaysi dasturlarni ishga tushirishi haqida. Albatta, bu parametr --debug.

Server

Men ushbu maqolada pappetserverni to'liq sozlashni va unga kodni joylashtirishni ko'rib chiqmayman; faqat shuni aytamanki, serverning to'liq funktsional versiyasi mavjud bo'lib, u oz sonli serverlar bilan ishlash uchun qo'shimcha konfiguratsiyani talab qilmaydi. tugunlar (aytaylik, yuztagacha). Ko'proq sonli tugunlar sozlashni talab qiladi - sukut bo'yicha, qo'g'irchoq serveri to'rt nafardan ko'p bo'lmagan ishchilarni ishga tushiradi, ko'proq ishlash uchun siz ularning sonini ko'paytirishingiz kerak va xotira chegaralarini oshirishni unutmang, aks holda server ko'pincha axlat yig'adi.

Kodni joylashtirish - agar sizga tez va oson kerak bo'lsa, qarang (r10k da)[https://github.com/puppetlabs/r10k], kichik o'rnatishlar uchun bu etarli bo'lishi kerak.

2-ilova: Kodlash bo'yicha ko'rsatmalar

  1. Barcha mantiqni sinflar va ta'riflarga joylashtiring.
  2. Sinflar va ta'riflarni tugunlarni tavsiflovchi manifestlarda emas, balki modullarda saqlang.
  3. Faktlardan foydalaning.
  4. Xost nomlari asosida ifs yaratmang.
  5. Sinflar va ta'riflar uchun parametrlarni qo'shishingiz mumkin - bu sinf / ta'rifning tanasida yashirin mantiqdan yaxshiroqdir.

Keyingi maqolada nima uchun buni qilishni maslahat beraman.

xulosa

Keling, kirish so‘zi bilan yakunlaylik. Keyingi maqolada men sizga Hiera, ENC va PuppetDB haqida gapirib beraman.

So'rovda faqat ro'yxatdan o'tgan foydalanuvchilar ishtirok etishlari mumkin. tizimga kirishiltimos.

Darhaqiqat, ko'proq materiallar mavjud - men quyidagi mavzularda maqolalar yozishim mumkin, siz o'qishni qiziqtirgan narsalarga ovoz berishim mumkin:

  • 59,1%Murakkab qo'g'irchoq konstruktsiyalari - keyingi darajadagi ba'zi bir axlat: halqalar, xaritalash va boshqa lambda ifodalari, resurs yig'uvchilar, eksport qilinadigan resurslar va Qo'g'irchoq orqali xostlar o'rtasidagi aloqa, teglar, provayderlar, mavhum ma'lumotlar turlari.13
  • 31,8%“Men onamning administratoriman” yoki biz Avitoda qanday qilib turli versiyadagi bir nechta poppet serverlar bilan do‘stlashdik va, qoida tariqasida, poppet serverini boshqarish bo‘limi.7
  • 81,8%Qo'g'irchoq kodini qanday yozamiz: asboblar, hujjatlar, testlar, CI/CD.18

22 foydalanuvchi ovoz berdi. 9 nafar foydalanuvchi betaraf qoldi.

Manba: www.habr.com