Kukla konfiqurasiya idarəetmə sistemidir. Hostları istənilən vəziyyətə gətirmək və bu vəziyyəti saxlamaq üçün istifadə olunur.

Artıq beş ildən çoxdur ki, Kukla ilə işləyirəm. Bu mətn mahiyyətcə rəsmi sənədlərin əsas məqamlarının tərcümə edilmiş və yenidən sıralanmış məcmuəsidir ki, bu da yeni başlayanlara Kuklanın mahiyyətini tez başa düşməyə imkan verəcəkdir.

Əsas məlumat

Kuklanın əməliyyat sistemi klient-serverdir, baxmayaraq ki, o, məhdud funksionallıqla serversiz əməliyyatı da dəstəkləyir.

Əməliyyatın çəkmə modeli istifadə olunur: standart olaraq, hər yarım saatda bir dəfə müştərilər konfiqurasiya üçün serverlə əlaqə saxlayır və onu tətbiq edirlər. Əgər siz Ansible ilə işləmisinizsə, onda onlar fərqli təkan modelindən istifadə edirlər: administrator konfiqurasiyanın tətbiqi prosesinə başlayır, müştərilərin özləri heç nə tətbiq etməyəcəklər.

Şəbəkə əlaqəsi zamanı ikitərəfli TLS şifrələməsi istifadə olunur: server və müştərinin öz şəxsi açarları və müvafiq sertifikatları var. Adətən server müştərilər üçün sertifikatlar verir, lakin prinsipcə xarici CA-dan istifadə etmək mümkündür.

Manifestlərə giriş

Kukla terminologiyasında kukla serverinə qoşulmaq qovşaqlar (qovşaqlar). Düyünlər üçün konfiqurasiya yazılmışdır manifestlərdə xüsusi proqramlaşdırma dilində - Puppet DSL.

Kukla DSL deklarativ dildir. O, fərdi resursların bəyannamələri şəklində qovşağın istənilən vəziyyətini təsvir edir, məsələn:

Fayl mövcuddur və onun xüsusi məzmunu var.
Paket quraşdırılıb.
Xidmət başladı.

Resurslar bir-birinə bağlana bilər:

Asılılıqlar var, onlar resursların istifadə qaydasına təsir göstərir.
Məsələn, "əvvəlcə paketi quraşdırın, sonra konfiqurasiya faylını redaktə edin, sonra xidməti işə salın."
Bildirişlər var - əgər resurs dəyişibsə, ona abunə olan resurslara bildirişlər göndərir.
Məsələn, konfiqurasiya faylı dəyişərsə, siz xidməti avtomatik olaraq yenidən başlada bilərsiniz.

Bundan əlavə, Kukla DSL-də funksiyalar və dəyişənlər, həmçinin şərti ifadələr və seçicilər var. Müxtəlif şablon mexanizmləri də dəstəklənir - EPP və ERB.

Kukla Ruby dilində yazılmışdır, ona görə də bir çox konstruksiyalar və terminlər oradan götürülüb. Ruby, Puppet-i genişləndirməyə imkan verir - mürəkkəb məntiq, yeni növ resurslar, funksiyalar əlavə edin.

Kukla işləyərkən, serverdəki hər bir xüsusi qovşaq üçün manifestlər kataloqa yığılır. Directory funksiyaların, dəyişənlərin dəyərinin hesablanması və şərti ifadələrin genişləndirilməsindən sonra resursların və onların əlaqələrinin siyahısıdır.

Sintaksis və kod üslubu

Təqdim olunan nümunələr kifayət etmədikdə sintaksisi başa düşməyə kömək edəcək rəsmi sənədlərin bölmələri:

Manifestin necə göründüyünə dair bir nümunə:

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

Abzas və sətir fasilələri manifestin tələb olunan hissəsi deyil, lakin tövsiyə olunur stil guide. Xülasə:

İki boşluqlu girintilər, nişanlar istifadə edilmir.
Buruq mötərizələr boşluqla ayrılır; kolonlar boşluqla ayrılmır.
Sonuncu daxil olmaqla hər bir parametrdən sonra vergül. Hər bir parametr ayrıca sətirdədir. Parametrsiz və bir parametrsiz hal üçün istisna edilir: bir sətirdə və vergül olmadan yaza bilərsiniz (yəni. resource { 'title': } и resource { 'title': param => value }).
Parametrlərdəki oxlar eyni səviyyədə olmalıdır.
Onların qarşısında resurs əlaqəsi oxları yazılmışdır.

Pappetserverdə faylların yeri

Əlavə izahat üçün mən “kök kataloq” anlayışını təqdim edəcəyəm. Kök kataloq müəyyən bir node üçün Kukla konfiqurasiyasını ehtiva edən qovluqdur.

Kök kataloq Kukla versiyasından və istifadə olunan mühitlərdən asılı olaraq dəyişir. Mühitlər ayrı-ayrı kataloqlarda saxlanılan müstəqil konfiqurasiya dəstləridir. Adətən git ilə kombinasiyada istifadə olunur, bu halda mühitlər git filiallarından yaradılır. Müvafiq olaraq, hər bir qovşaq bu və ya digər mühitdə yerləşir. Bu, qovşağın özündə və ya növbəti məqalədə danışacağım ENC-də konfiqurasiya edilə bilər.

Üçüncü versiyada ("köhnə Kukla") əsas kataloq idi /etc/puppet. Mühitlərin istifadəsi isteğe bağlıdır - məsələn, biz onları köhnə Kukla ilə istifadə etmirik. Əgər mühitlər istifadə olunursa, onlar adətən saxlanılır /etc/puppet/environments, kök kataloq mühit qovluğu olacaq. Mühitlərdən istifadə edilmirsə, kök kataloq əsas kataloq olacaq.
Dördüncü versiyadan (“yeni Kukla”) başlayaraq mühitlərin istifadəsi məcburi oldu və əsas kataloq köçürüldü. /etc/puppetlabs/code. Buna uyğun olaraq mühitlər saxlanılır /etc/puppetlabs/code/environments, kök kataloq mühit qovluğudur.

Kök qovluğunda alt kataloq olmalıdır manifestsqovşaqları təsvir edən bir və ya bir neçə manifest ehtiva edən . Bundan əlavə, bir alt kataloq olmalıdır modulesmodulları ehtiva edən . Hansı modulların olduğunu bir az sonra deyəcəyəm. Bundan əlavə, köhnə Kuklanın da alt kataloqu ola bilər filesqovşaqlara kopyaladığımız müxtəlif faylları ehtiva edən . Yeni Kuklada bütün fayllar modullara yerləşdirilib.

Manifest fayllarının uzantısı var .pp.

Bir neçə döyüş nümunəsi

Düyün və üzərindəki resursun təsviri

Düyün üzərində server1.testdomain fayl yaradılmalıdır /etc/issue məzmunu ilə Debian GNU/Linux n l. Fayl istifadəçi və qrupa məxsus olmalıdır root, giriş hüquqları olmalıdır 644.

Bir manifest yazırıq:

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

Bir qovşaqdakı resurslar arasında əlaqələr

Düyün üzərində server2.testdomain nginx işləməlidir, əvvəlcədən hazırlanmış konfiqurasiya ilə işləməlidir.

Problemi həll edək:

Paketi quraşdırmaq lazımdır nginx.
Konfiqurasiya fayllarının serverdən kopyalanması lazımdır.
Xidmət işləməlidir nginx.
Konfiqurasiya yenilənərsə, xidmət yenidən işə salınmalıdır.

Bir manifest yazırıq:

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

Bunun işləməsi üçün sizə kukla serverində təxminən aşağıdakı fayl yeri lazımdır:

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

Resurs növləri

Dəstəklənən resurs növlərinin tam siyahısını burada tapa bilərsiniz sənədlərdə, burada mən praktikamda əksər problemləri həll etmək üçün kifayət edən beş əsas növü təsvir edəcəyəm.

fayl

Faylları, kataloqları, simvolik əlaqələri, onların məzmununu və giriş hüquqlarını idarə edir.

Variantları:

resurs adı — fayla gedən yol (istəyə görə)
yol — faylın yolu (adda göstərilməyibsə)
təmin etmək - fayl növü:
- absent - faylı silin
- present — istənilən növ fayl olmalıdır (fayl yoxdursa, adi fayl yaradılacaq)
- file - adi fayl
- directory - kataloq
- link - simvolik əlaqə
məzmun — fayl məzmunu (yalnız adi fayllar üçün uyğundur, ilə birlikdə istifadə edilə bilməz mənbə və ya hədəf)
mənbə — faylın məzmununu köçürmək istədiyiniz yola keçid (. ilə birlikdə istifadə edilə bilməz məzmun və ya hədəf). Sxemli URI kimi göstərilə bilər puppet: (sonra kukla serverindən olan fayllar istifadə olunacaq) və sxemlə http: (Ümid edirəm ki, bu vəziyyətdə nə olacağı aydındır) və hətta diaqramla file: və ya sxemsiz mütləq yol kimi (sonra qovşaqdakı yerli FS-dən olan fayl istifadə olunacaq)
hədəf — simvolik keçidin göstərməli olduğu yer ( ilə birlikdə istifadə edilə bilməz məzmun və ya mənbə)
sahib — faylın sahibi olmalı olan istifadəçi
qrup — faylın aid olduğu qrup
rejimində — fayl icazələri (sətir kimi)
resurse - rekursiv qovluqların işlənməsini təmin edir
təmizləmək - Kuklada təsvir olunmayan faylları silməyə imkan verir
məcbur - Kuklada təsvir olunmayan qovluqları silməyə imkan verir

paketi

Paketləri quraşdırır və silir. Bildirişləri idarə edə bilir - parametr göstərildiyi təqdirdə paketi yenidən quraşdırır reinstall_on_refresh.

Variantları:

resurs adı - paket adı (istəyə görə)
ad — paketin adı (adda göstərilməyibsə)
Provider — istifadə etmək üçün paket meneceri
təmin etmək - paketin istədiyiniz vəziyyəti:
- present, installed - quraşdırılmış istənilən versiya
- latest - son versiya quraşdırılıb
- absent - silindi (apt-get remove)
- purged — konfiqurasiya faylları ilə birlikdə silindi (apt-get purge)
- held - paket versiyası kilidlidir (apt-mark hold)
- любая другая строка — göstərilən versiya quraşdırılıb
reinstall_on_refresh - əgər true, sonra bildiriş alındıqdan sonra paket yenidən quraşdırılacaq. Quraşdırma parametrlərini dəyişdirərkən paketlərin yenidən qurulması lazım ola biləcəyi mənbə əsaslı paylamalar üçün faydalıdır. Defolt false.

xidmət

Xidmətləri idarə edir. Bildirişləri emal edə bilir - xidməti yenidən işə salır.

Variantları:

resurs adı — idarə olunacaq xidmət (isteğe bağlı)
ad — idarə edilməli olan xidmət (adda göstərilməyibsə)
təmin etmək - xidmətin arzu olunan vəziyyəti:
- running - işə salındı
- stopped - dayandı
imkan — xidmətə başlamaq imkanına nəzarət edir:
- true — autorun aktivdir (systemctl enable)
- mask - maskalı (systemctl mask)
- false — autorun qeyri-aktivdir (systemctl disable)
yenidən başladın - xidməti yenidən başlatmaq üçün əmr
vəziyyət — xidmət vəziyyətini yoxlamaq üçün əmr
yenidən başladın — xidmət initscriptinin yenidən başlamağı dəstəklədiyini göstərin. Əgər false və parametr müəyyən edilir yenidən başladın — bu parametrin dəyəri istifadə olunur. Əgər false və parametr yenidən başladın göstərilməyib - xidmət dayandırılıb və yenidən başlamağa başlayıb (lakin systemd əmrindən istifadə edir systemctl restart).
vəziyyəti — xidmət initscriptinin əmri dəstəklədiyini göstərin status. Əgər false, sonra parametr dəyəri istifadə olunur vəziyyət. Defolt true.

exec

Xarici əmrləri yerinə yetirir. Parametrləri qeyd etməsəniz yaradır, yalnız əgər, əgər və ya təzədən, komanda hər dəfə Kukla işə salındıqda yerinə yetiriləcək. Bildirişləri emal edə bilir - əmri yerinə yetirir.

Variantları:

resurs adı — icra ediləcək əmr (isteğe bağlı)
komanda — icra ediləcək komanda (adda göstərilməyibsə)
yol — icra olunan faylı axtarmaq üçün yollar
yalnız əgər — bu parametrdə göstərilən əmr sıfır qaytarma kodu ilə tamamlanarsa, əsas əmr yerinə yetiriləcəkdir
əgər — bu parametrdə göstərilən əmr sıfırdan fərqli qaytarma kodu ilə tamamlanarsa, əsas əmr yerinə yetiriləcəkdir.
yaradır — bu parametrdə göstərilən fayl mövcud deyilsə, əsas əmr yerinə yetiriləcək
təzədən - əgər true, onda əmr yalnız bu icraçı digər resurslardan bildiriş aldıqda işlədiləcək
cwd — əmrin icra olunacağı qovluq
istifadəçi — əmri icra edəcək istifadəçi
Provider - əmri necə yerinə yetirmək olar:
- müsbət — uşaq prosesi sadəcə yaradılmışdır, dəqiqləşdirməyi unutmayın yol
- shell - əmr qabıqda işə salınır /bin/sh, müəyyən edilə bilməz yol, siz globbing, borular və digər qabıq xüsusiyyətlərindən istifadə edə bilərsiniz. Xüsusi simvollar olduqda adətən avtomatik aşkarlanır (|, ;, &&, || və s.).

cron

Cronjobs nəzarət edir.

Variantları:

resurs adı - sadəcə bir növ identifikator
təmin etmək - tac vəziyyəti:
- present - mövcud deyilsə yaratmaq
- absent - varsa silin
komanda - hansı əmri işlətmək
ətraf mühit — əmrin hansı mühitdə işlədilməsi (mühit dəyişənlərinin siyahısı və onların qiymətləri vasitəsilə =)
istifadəçi — əmri hansı istifadəçidən icra etmək
dəqiqə, saat, iş günü, ay, ay günü — cronu nə vaxt işə salmaq lazımdır. Bu atributlardan hər hansı biri göstərilməyibsə, onun crontab-dakı dəyəri olacaq *.

Kukla 6.0-da cron kimi idi qutudan çıxarılıb kukla serverində, buna görə də ümumi saytda heç bir sənəd yoxdur. Amma o qutuda var kukla-agentdə, ona görə də ayrıca quraşdırmaya ehtiyac yoxdur. Bunun üçün sənədlərə baxa bilərsiniz Kuklanın beşinci versiyası üçün sənədlərdəVə ya GitHub-da.

Ümumiyyətlə resurslar haqqında

Resursun unikallığına dair tələblər

Qarşılaşdığımız ən çox yayılmış səhvdir Dublikat bəyannamə. Bu xəta kataloqda eyni adlı iki və ya daha çox eyni tipli resurs göründükdə baş verir.

Ona görə də yenə yazacam: eyni node üçün manifestlər eyni başlıqlı eyni tipli resursları ehtiva etməməlidir!

Bəzən eyni adlı, lakin fərqli paket menecerləri olan paketlərin quraşdırılmasına ehtiyac yaranır. Bu vəziyyətdə parametrdən istifadə etməlisiniz namexətanın qarşısını almaq üçün:

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

Digər resurs növlərində təkrarlamanın qarşısını almaq üçün oxşar seçimlər var - name у xidmət, command у exec, və s.

Metaparametrlər

Hər bir resurs növü təbiətindən asılı olmayaraq bəzi xüsusi parametrlərə malikdir.

Meta parametrlərin tam siyahısı Kukla sənədlərində.

Qısa siyahı:

tələb — bu parametr bu resursun hansı resurslardan asılı olduğunu göstərir.
əvvəl - Bu parametr hansı resursların bu resursdan asılı olduğunu müəyyənləşdirir.
yazılmaq — bu parametr bu resursun hansı mənbələrdən bildirişlər aldığını müəyyən edir.
bildirin — Bu parametr hansı resursların bu resursdan bildirişlər aldığını müəyyən edir.

Bütün sadalanan metaparametrlər ya tək resurs keçidini, ya da kvadrat mötərizədə keçidlər massivini qəbul edir.

Resurslara bağlantılar

Resurs bağlantısı sadəcə resursun qeydidir. Onlar əsasən asılılıqları göstərmək üçün istifadə olunur. Mövcud olmayan mənbəyə istinad etmək kompilyasiya xətasına səbəb olacaq.

Bağlantının sintaksisi belədir: böyük hərflə resurs növü (əgər növün adında qoşa nöqtələr varsa, o zaman iki nöqtə arasındakı adın hər bir hissəsi böyük hərflə yazılır), sonra kvadrat mötərizədə resurs adı (adın işi dəyişmir!). Boşluq olmamalıdır, kvadrat mötərizə növün adından dərhal sonra yazılır.

Misal:

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

Asılılıqlar və bildirişlər

Sənədlər burada.

Daha əvvəl qeyd edildiyi kimi, resurslar arasında sadə asılılıqlar keçid xarakterlidir. Yeri gəlmişkən, asılılıqlar əlavə edərkən diqqətli olun - siz tsiklik asılılıqlar yarada bilərsiniz, bu da kompilyasiya xətasına səbəb olacaq.

Asılılıqlardan fərqli olaraq bildirişlər keçidli deyil. Bildirişlər üçün aşağıdakı qaydalar tətbiq olunur:

Resurs bildiriş alırsa, o, yenilənir. Yeniləmə tədbirləri resurs növündən asılıdır - exec əmrini yerinə yetirir, xidmət xidməti yenidən işə salır, paketi paketi yenidən quraşdırır. Resursda müəyyən edilmiş yeniləmə əməliyyatı yoxdursa, heç nə baş vermir.
Kuklanın bir buraxılışı zamanı resurs bir dəfədən çox yenilənmir. Bu mümkündür, çünki bildirişlərə asılılıqlar daxildir və asılılıq qrafikində dövrlər yoxdur.
Kukla resursun vəziyyətini dəyişirsə, resurs ona abunə olan bütün resurslara bildirişlər göndərir.
Resurs yenilənirsə, ona abunə olan bütün resurslara bildirişlər göndərir.

Müəyyən edilməmiş parametrlərin idarə edilməsi

Bir qayda olaraq, əgər hansısa resurs parametrinin defolt dəyəri yoxdursa və bu parametr manifestdə göstərilməyibsə, onda Kukla qovşaqdakı müvafiq resurs üçün bu xassəni dəyişməyəcək. Məsələn, bir növ resurs varsa fayl parametr göstərilməyib owner, onda Kukla müvafiq faylın sahibini dəyişməyəcək.

Siniflərə, dəyişənlərə və təriflərə giriş

Tutaq ki, konfiqurasiyanın eyni hissəsinə malik bir neçə qovşaqımız var, lakin fərqlər də var - əks halda biz hamısını bir blokda təsvir edə bilərik. node {}. Əlbəttə ki, siz sadəcə olaraq konfiqurasiyanın eyni hissələrini kopyalaya bilərsiniz, lakin ümumiyyətlə bu, pis bir həlldir - konfiqurasiya böyüyür və konfiqurasiyanın ümumi hissəsini dəyişdirsəniz, bir çox yerdə eyni şeyi redaktə etməli olacaqsınız. Eyni zamanda, səhv etmək asandır və ümumiyyətlə, DRY (özünüzü təkrarlama) prinsipi bir səbəbdən icad edilmişdir.

Bu problemi həll etmək üçün belə bir dizayn var sinif.

Dərslər

Sinif poppet kodunun adlandırılmış blokudur. Kodu təkrar istifadə etmək üçün siniflər lazımdır.

Əvvəlcə sinfi təsvir etmək lazımdır. Təsvirin özü heç bir yerə heç bir resurs əlavə etmir. Sinif manifestlərdə təsvir edilmişdir:

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

Bundan sonra sinifdən istifadə edilə bilər:

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

Əvvəlki tapşırıqdan bir nümunə - nginx-in quraşdırılmasını və konfiqurasiyasını bir sinfə köçürək:

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
}

Dəyişənlər

Əvvəlki nümunədəki sinif heç də çevik deyil, çünki həmişə eyni nginx konfiqurasiyasını gətirir. Gəlin konfiqurasiya dəyişəninə gedən yolu düzəldək, onda bu sinif istənilən konfiqurasiya ilə nginx quraşdırmaq üçün istifadə edilə bilər.

Bunu etmək olar dəyişənlərdən istifadə etməklə.

Diqqət: Kukladakı dəyişənlər dəyişməzdir!

Bundan əlavə, dəyişənə yalnız elan edildikdən sonra daxil olmaq olar, əks halda dəyişənin dəyəri undef.

Dəyişənlərlə işləmək nümunəsi:

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

Kukla var ad boşluqları, və dəyişənlər, müvafiq olaraq, var görmə sahəsi: Eyni ada malik dəyişən müxtəlif ad boşluqlarında müəyyən edilə bilər. Dəyişənin qiymətini həll edərkən, dəyişən cari ad məkanında, sonra onu əhatə edən ad məkanında və s.

Ad sahəsi nümunələri:

qlobal - sinifdən və ya node təsvirindən kənar dəyişənlər ora gedir;
node təsvirində node ad sahəsi;
sinif təsvirində sinif ad sahəsi.

Dəyişənə daxil olarkən qeyri-müəyyənliyin qarşısını almaq üçün dəyişənin adında ad sahəsini təyin edə bilərsiniz:

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

Gəlin razılaşaq ki, nginx konfiqurasiyasına gedən yol dəyişəndədir $nginx_conf_source. Sonra sinif belə görünəcək:

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
}

Bununla belə, verilən nümunə pisdir, çünki bəzi “gizli biliklər” var ki, sinif daxilində filan və belə adda dəyişən istifadə olunur. Bu biliyi ümumiləşdirmək daha düzgündür - siniflərin parametrləri ola bilər.

Sinif parametrləri sinif ad məkanındakı dəyişənlərdir, onlar sinif başlığında göstərilib və sinif orqanında müntəzəm dəyişənlər kimi istifadə edilə bilər. Parametr dəyərləri manifestdə sinifdən istifadə edərkən müəyyən edilir.

Parametr standart dəyərə təyin edilə bilər. Parametrin defolt dəyəri yoxdursa və istifadə edildikdə dəyər təyin olunmursa, bu, kompilyasiya xətasına səbəb olacaq.

Yuxarıdakı nümunədən klassı parametrləşdirək və iki parametr əlavə edək: birincisi, tələb olunan, konfiqurasiyaya gedən yoldur, ikincisi, isteğe bağlı olaraq, nginx ilə paketin adıdır (məsələn, Debian-da paketlər var. 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',   # задаём параметры класса точно так же, как параметры для других ресурсов
  }
}

Kuklada dəyişənlər yazılır. Yemək çoxlu məlumat növləri. Məlumat növləri adətən siniflərə və təriflərə ötürülən parametr dəyərlərini təsdiqləmək üçün istifadə olunur. Keçirilmiş parametr göstərilən tipə uyğun gəlmirsə, kompilyasiya xətası baş verəcəkdir.

Növ parametr adından dərhal əvvəl yazılır:

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

Siniflər: sinif adı və sinfi daxildir{'sinif adı':}

Hər bir sinif bir növ resursdur sinif. Hər hansı digər resurs növündə olduğu kimi, eyni qovşaqda eyni sinifin iki nümunəsi ola bilməz.

Eyni node istifadə edərək bir sinif əlavə etməyə cəhd etsəniz class { 'classname':} (fərq yoxdur, fərqli və ya eyni parametrlərlə), kompilyasiya xətası olacaq. Ancaq resurs üslubunda bir sinifdən istifadə etsəniz, dərhal manifestdə onun bütün parametrlərini açıq şəkildə təyin edə bilərsiniz.

Ancaq istifadə etsəniz include, sonra sinif istədiyiniz qədər əlavə edilə bilər. Fakt budur ki include bir sinfin kataloqa əlavə edilib-edilmədiyini yoxlayan idempotent funksiyadır. Sinif kataloqda deyilsə, onu əlavə edir və artıq mövcuddursa, heç bir şey etmir. Ancaq istifadə edildiyi təqdirdə include Siz sinif elanı zamanı sinif parametrlərini təyin edə bilməzsiniz - bütün tələb olunan parametrlər xarici məlumat mənbəyində - Hiera və ya ENC-də təyin edilməlidir. Növbəti məqalədə onlar haqqında danışacağıq.

Müəyyən edir

Əvvəlki blokda deyildiyi kimi, eyni sinif bir qovşaqda bir dəfədən çox ola bilməz. Bununla belə, bəzi hallarda eyni qovşaqda müxtəlif parametrlərlə eyni kod blokundan istifadə edə bilməlisiniz. Başqa sözlə, özünəməxsus resurs növünə ehtiyac var.

Məsələn, PHP modulunu quraşdırmaq üçün Avito-da aşağıdakıları edirik:

Paketi bu modulla quraşdırın.
Bu modul üçün konfiqurasiya faylı yaradaq.
Biz php-fpm üçün konfiqurasiyaya simvolik əlaqə yaradırıq.
Biz php cli üçün konfiqurasiyaya simvolik əlaqə yaradırıq.

Belə hallarda, kimi bir dizayn müəyyənləşdirmək (müəyyən etmək, müəyyən edilmiş növ, müəyyən edilmiş resurs növü). Define sinfə bənzəyir, lakin fərqlər var: birincisi, hər bir Define resurs deyil, resurs növüdür; ikincisi, hər bir tərifin gizli parametri var $title, resurs adı elan edildikdə hara gedir. Siniflərdə olduğu kimi, əvvəlcə tərif təsvir edilməlidir, bundan sonra istifadə edilə bilər.

PHP üçün modul ilə sadələşdirilmiş nümunə:

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

Dublikat bəyannaməsi xətasını tutmağın ən asan yolu Müəyyən etməkdir. Bu, tərifin daimi adı olan resursu varsa və bəzi qovşaqda bu tərifin iki və ya daha çox nümunəsi olduqda baş verir.

Özünüzü bundan qorumaq asandır: tərifdəki bütün resursların adı olmalıdır $title. Alternativ resursların idempotent əlavə edilməsidir; ən sadə halda tərifin bütün nümunələri üçün ümumi olan resursları ayrıca bir sinifə köçürmək və bu sinfi tərifə - funksiyaya daxil etmək kifayətdir. include idempotent.

Resurs əlavə edərkən, yəni funksiyalardan istifadə edərkən qeyri-müəyyənliyə nail olmağın başqa yolları da var defined и ensure_resources, amma bu barədə sizə növbəti bölümdə məlumat verəcəyəm.

Siniflər və təriflər üçün asılılıqlar və bildirişlər

Siniflər və təriflər asılılıqları və bildirişləri idarə etmək üçün aşağıdakı qaydaları əlavə edir:

bir sinifdən asılılıq/müəyyən etmək sinfin/müəyyənliyin bütün resurslarından asılılıqlar əlavə edir;
sinif/müəyyənləşdirmə asılılığı bütün siniflərə asılılıqlar əlavə edir/resursları müəyyənləşdirir;
class/define bildirişi sinif/müəyyənləşdirmənin bütün resurslarını xəbərdar edir;
class/define abunəliyi sinif/define-in bütün resurslarına abunə olur.

Şərti ifadələr və seçicilər

Sənədlər burada.

if

Burada çox sadədir:

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

əgər

if tərs deyilsə: ifadə yalan olarsa kod bloku icra olunacaq.

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

hal

Burada da mürəkkəb bir şey yoxdur. Siz normal dəyərlərdən (sətirlər, rəqəmlər və s.), müntəzəm ifadələrdən və məlumat növlərindən dəyərlər kimi istifadə edə bilərsiniz.

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

Seçicilər

Selektor oxşar dil konstruksiyasıdır case, lakin kod blokunu yerinə yetirmək əvəzinə bir dəyər qaytarır.

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

Module

Konfiqurasiya kiçik olduqda, bir manifestdə asanlıqla saxlanıla bilər. Ancaq nə qədər çox konfiqurasiya təsvir etsək, manifestdə bir o qədər çox sinif və qovşaq var, o, böyüyür və onunla işləmək əlverişsiz olur.

Bundan əlavə, kodun təkrar istifadəsi problemi var - bütün kodlar bir manifestdə olduqda, bu kodu başqaları ilə bölüşmək çətindir. Bu iki problemi həll etmək üçün Kukla modul adlı bir varlığa malikdir.

Module - bunlar ayrıca kataloqda yerləşdirilən siniflər, təriflər və digər Kukla obyektləri dəstləridir. Başqa sözlə, modul Kukla məntiqinin müstəqil bir parçasıdır. Məsələn, nginx ilə işləmək üçün modul ola bilər və o, nginx ilə işləmək üçün lazım olanları və yalnız nələri ehtiva edəcək və ya PHP ilə işləmək üçün modul ola bilər və s.

Modullar versiyalanır və modulların bir-birindən asılılığı da dəstəklənir. Modulların açıq deposu var - Kukla Döşəməsi.

Kukla serverində modullar kök kataloqunun modullar alt kataloqunda yerləşir. Hər bir modulun içərisində standart kataloq sxemi var - manifestlər, fayllar, şablonlar, lib və s.

Modulda fayl strukturu

Modulun kökündə təsviri adları olan aşağıdakı kataloqlar ola bilər:

manifests - manifestləri ehtiva edir
files - faylları ehtiva edir
templates - şablonları ehtiva edir
lib - Ruby kodunu ehtiva edir

Bu kataloqların və faylların tam siyahısı deyil, lakin bu məqalə üçün hələlik kifayətdir.

Moduldakı resursların adları və faylların adları

Sənədlər burada.

Moduldakı resursları (siniflər, təriflər) istədiyiniz kimi adlandırmaq olmaz. Bundan əlavə, resursun adı ilə Kuklanın həmin resursun təsvirini axtaracağı faylın adı arasında birbaşa uyğunluq var. Adlandırma qaydalarını pozarsanız, Kukla sadəcə resursun təsvirini tapa bilməyəcək və siz tərtib etmə xətası alacaqsınız.

Qaydalar sadədir:

Moduldakı bütün resurslar modul ad məkanında olmalıdır. Modul çağırılırsa foo, onda içindəki bütün resurslar adlandırılmalıdır foo::<anything>, ya da sadəcə foo.
Modulun adı olan resurs faylda olmalıdır init.pp.
Digər resurslar üçün fayl adlandırma sxemi aşağıdakı kimidir:
- modul adı olan prefiks ləğv edilir
- bütün qoşa nöqtələr, əgər varsa, əyri işarələrlə əvəz olunur
- uzadılması əlavə olunur .pp

Mən bir nümunə ilə nümayiş etdirəcəyəm. Tutaq ki, mən modul yazıram nginx. O, aşağıdakı resursları ehtiva edir:

sinif nginx manifestdə təsvir edilmişdir init.pp;
sinif nginx::service manifestdə təsvir edilmişdir service.pp;
müəyyənləşdirmək nginx::server manifestdə təsvir edilmişdir server.pp;
müəyyənləşdirmək nginx::server::location manifestdə təsvir edilmişdir server/location.pp.

Templates

Şübhəsiz ki, özünüz şablonların nə olduğunu bilirsiniz, mən onları burada ətraflı təsvir etməyəcəyəm. Amma hər ehtimala qarşı buraxacağam Vikipediyaya keçid.

Şablonlardan necə istifadə etməli: Şablonun mənası funksiyadan istifadə etməklə genişləndirilə bilər template, şablona gedən yol ötürülür. Növ mənbələri üçün fayl parametri ilə birlikdə istifadə olunur content. Məsələn, bu kimi:

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

Yola baxın <modulename>/<filename> faylı nəzərdə tutur <rootdir>/modules/<modulename>/templates/<filename>.

Bundan əlavə, bir funksiya var inline_template — o, fayl adını deyil, şablon mətnini giriş kimi qəbul edir.

Şablonlarda siz cari əhatə dairəsində bütün Kukla dəyişənlərindən istifadə edə bilərsiniz.

Kukla ERB və EPP formatında şablonları dəstəkləyir:

ERB haqqında qısaca

Nəzarət strukturları:

<%= ВЫРАЖЕНИЕ %> — ifadənin qiymətini daxil edin
<% ВЫРАЖЕНИЕ %> — ifadənin qiymətini hesablayın (onu daxil etmədən). Şərti ifadələr (əgər) və döngələr (hər biri) adətən burada olur.
<%# КОММЕНТАРИЙ %>

ERB-dəki ifadələr Ruby-də yazılmışdır (ERB əslində Embedded Ruby-dir).

Manifestdən dəyişənlərə daxil olmaq üçün əlavə etməlisiniz @ dəyişən adına. Nəzarət konstruksiyasından sonra görünən sətir kəsilməsini aradan qaldırmaq üçün bağlama teqindən istifadə etməlisiniz -%>.

Şablondan istifadə nümunəsi

Tutaq ki, mən ZooKeeper-i idarə etmək üçün modul yazıram. Konfiqurasiyanın yaradılmasına cavabdeh olan sinif belə görünür:

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

Və müvafiq şablon zoo.cfg.erb - Belə ki:

<% 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 və Daxili Dəyişənlər

Çox vaxt konfiqurasiyanın xüsusi hissəsi hazırda node üzərində baş verənlərdən asılıdır. Məsələn, Debian buraxılışının nə olduğundan asılı olaraq, paketin bu və ya digər versiyasını quraşdırmalısınız. Bütün bunları əl ilə izləyə bilərsiniz, qovşaqlar dəyişdikdə manifestləri yenidən yaza bilərsiniz. Amma bu ciddi yanaşma deyil, avtomatlaşdırma daha yaxşıdır.

Düyünlər haqqında məlumat əldə etmək üçün Kuklada faktlar adlı bir mexanizm var. faktlar - bu, qlobal ad məkanında adi dəyişənlər şəklində manifestlərdə mövcud olan node haqqında məlumatdır. Məsələn, host adı, əməliyyat sisteminin versiyası, prosessor arxitekturası, istifadəçilərin siyahısı, şəbəkə interfeyslərinin siyahısı və onların ünvanları və daha çox şey. Faktlar manifestlərdə və şablonlarda müntəzəm dəyişənlər kimi mövcuddur.

Faktlarla işləmək nümunəsi:

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

Formal desək, faktın adı (sətiri) və dəyəri var (müxtəlif növlər mövcuddur: sətirlər, massivlər, lüğətlər). Yemək daxili faktlar toplusu. Özünüz də yaza bilərsiniz. Fakt kollektorları təsvir edilmişdir Ruby-dəki funksiyalar kimivə ya necə icra edilə bilən fayllar. Faktlar formada da təqdim edilə bilər məlumatları olan mətn faylları qovşaqlarda.

Əməliyyat zamanı kukla agenti əvvəlcə bütün mövcud fakt toplayıcılarını pappetserverdən qovşağına köçürür, bundan sonra onları işə salır və toplanmış faktları serverə göndərir; Bundan sonra server kataloqu tərtib etməyə başlayır.

İcra olunan fayllar şəklində faktlar

Bu cür faktlar kataloqda modullarda yerləşdirilir facts.d. Əlbəttə ki, fayllar icra edilə bilən olmalıdır. İşlədikdə, onlar ya YAML, ya da açar=dəyər formatında standart çıxışa məlumat verməlidirlər.

Unutmayın ki, faktlar modulunuzun yerləşdirildiyi poppet server tərəfindən idarə olunan bütün qovşaqlara aiddir. Buna görə də, skriptdə, sistemdə faktınızın işləməsi üçün lazım olan bütün proqramların və faylların olduğunu yoxlamağa diqqət yetirin.

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

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

Ruby faktları

Bu cür faktlar kataloqda modullarda yerləşdirilir 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

Mətn faktları

Bu cür faktlar kataloqda qovşaqlarda yerləşdirilir /etc/facter/facts.d köhnə Kuklada və ya /etc/puppetlabs/facts.d yeni Kuklada.

examplefact=examplevalue

---
examplefact2: examplevalue2
anotherfact: anothervalue

Faktlara çatmaq

Faktlara yanaşmağın iki yolu var:

lüğət vasitəsilə $facts: $facts['fqdn'];
fakt adından dəyişən adı kimi istifadə etməklə: $fqdn.

Ən yaxşısı lüğətdən istifadə etməkdir $facts, və ya daha yaxşısı, qlobal ad sahəsini göstərin ($::facts).

Budur sənədlərin müvafiq bölməsi.

Daxili Dəyişənlər

Faktlarla yanaşı, faktlar da var bəzi dəyişənlər, qlobal ad məkanında mövcuddur.

etibarlı faktlar — müştəri sertifikatından götürülən dəyişənlər (sertifikat adətən poppet serverdə verildiyi üçün agent sadəcə onun sertifikatını götürüb dəyişdirə bilməz, ona görə də dəyişənlər “etibarlıdır”): sertifikatın adı, sertifikatın adı host və domen, sertifikatdan uzantılar.
server faktları —server haqqında məlumatla bağlı dəyişənlər—versiya, adı, server IP ünvanı, mühit.
agent faktları — fakter tərəfindən deyil, birbaşa kukla agent tərəfindən əlavə edilən dəyişənlər — sertifikat adı, agent versiyası, kukla versiyası.
master dəyişənlər - Pappetmaster dəyişənləri (sic!). Təxminən ilə eynidir server faktları, üstəgəl konfiqurasiya parametri dəyərləri mövcuddur.
kompilyator dəyişənləri — hər bir əhatə dairəsinə görə fərqlənən kompilyator dəyişənləri: cari modulun adı və cari obyektin daxil olduğu modulun adı. Onlardan, məsələn, şəxsi siniflərinizin birbaşa digər modullardan istifadə edilmədiyini yoxlamaq üçün istifadə edilə bilər.

Əlavə 1: bütün bunları necə işlətmək və debug etmək olar?

Məqalədə kukla kodun bir çox nümunəsi var idi, lakin bu kodu necə işlətmək lazım olduğunu bizə ümumiyyətlə izah etmədi. Yaxşı, özümü düzəldirəm.

Puppet-i işə salmaq üçün agent kifayətdir, lakin əksər hallarda sizə server də lazımdır.

Agent

Ən azı versiya XNUMX-dən kukla agent paketləri rəsmi Puppetlabs deposu bütün asılılıqları (ruby və müvafiq daşlar) ehtiva edir, buna görə quraşdırma çətinliyi yoxdur (Mən Debian əsaslı paylamalardan danışıram - biz RPM əsaslı paylamalardan istifadə etmirik).

Ən sadə halda, kukla konfiqurasiyasından istifadə etmək üçün agenti serversiz rejimdə işə salmaq kifayətdir: kukla kodu qovşağına kopyalanmaq şərtilə, işə salın 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

Əlbəttə ki, serveri qurmaq və agentləri demon rejimində qovşaqlarda işə salmaq daha yaxşıdır - sonra hər yarım saatda bir dəfə serverdən yüklənmiş konfiqurasiyanı tətbiq edəcəklər.

İşin təkan modelini təqlid edə bilərsiniz - maraqlandığınız node gedin və başlayın sudo puppet agent -t... Açar -t (--test) əslində fərdi olaraq aktivləşdirilə bilən bir neçə variantı ehtiva edir. Bu seçimlərə aşağıdakılar daxildir:

daemon rejimində işləməyin (standart olaraq agent daemon rejimində başlayır);
kataloqu tətbiq etdikdən sonra bağlanın (standart olaraq, agent işləməyə davam edəcək və hər yarım saatda bir dəfə konfiqurasiya tətbiq edəcək);
ətraflı iş jurnalını yazın;
fayllardakı dəyişiklikləri göstərin.

Agentin dəyişdirilmədən işləmə rejimi var - düzgün konfiqurasiyanı yazdığınızdan əmin olmadıqda və əməliyyat zamanı agentin dəqiq nəyi dəyişəcəyini yoxlamaq istədiyiniz zaman istifadə edə bilərsiniz. Bu rejim parametr tərəfindən aktivləşdirilir --noop komanda xəttində: sudo puppet agent -t --noop.

Bundan əlavə, işin sazlama jurnalını aktivləşdirə bilərsiniz - orada kukla etdiyi bütün hərəkətlər haqqında yazır: hazırda emal etdiyi resurs haqqında, bu resursun parametrləri haqqında, hansı proqramları işə salması haqqında. Təbii ki, bu bir parametrdir --debug.

Server

Bu məqalədə pappetserverin tam qurulmasını və ona kodun yerləşdirilməsini nəzərdən keçirməyəcəyəm; yalnız onu deyim ki, qutudan kənarda az sayda server ilə işləmək üçün əlavə konfiqurasiya tələb etməyən serverin tam funksional versiyası var. qovşaqlar (məsələn, yüzə qədər). Daha çox sayda qovşaq tənzimləmə tələb edəcək - standart olaraq, kukla serveri dörddən çox işçini işə salır, daha çox işləmək üçün onların sayını artırmalı və yaddaş məhdudiyyətlərini artırmağı unutmayın, əks halda server çox vaxt zibil yığacaq.

Kodun yerləşdirilməsi - əgər sizə tez və asanlıqla ehtiyacınız varsa, onda baxın (r10k-da)[https://github.com/puppetlabs/r10k], kiçik qurğular üçün kifayət qədər olmalıdır.

Əlavə 2: Kodlaşdırma Təlimatları

Bütün məntiqi siniflərə və təriflərə yerləşdirin.
Sinifləri və tərifləri qovşaqları təsvir edən manifestlərdə deyil, modullarda saxlayın.
Faktlardan istifadə edin.
Host adlarına əsaslanaraq if-lər yaratmayın.
Siniflər və təriflər üçün parametrlər əlavə etməkdən çekinmeyin - bu, sinif/müəyyənləşdirmənin gövdəsində gizlənmiş gizli məntiqdən daha yaxşıdır.

Bunu niyə etməyi tövsiyə etdiyimi növbəti məqalədə izah edəcəyəm.

Nəticə

Girişlə bitirək. Növbəti məqalədə sizə Hiera, ENC və PuppetDB haqqında məlumat verəcəyəm.

Sorğuda yalnız qeydiyyatdan keçmiş istifadəçilər iştirak edə bilər. Daxil olunxahiş edirəm.

Əslində, daha çox material var - aşağıdakı mövzularda məqalələr yaza bilərəm, oxumaqda maraqlı olduğunuza səs verə bilərəm:

59,1%Qabaqcıl kukla konstruksiyaları - bəzi növbəti səviyyəli şeylər: döngələr, xəritəçəkmə və digər lambda ifadələri, resurs kollektorları, ixrac edilmiş resurslar və Kukla vasitəsilə hostlararası əlaqə, teqlər, provayderlər, mücərrəd məlumat növləri.13
31,8%“Mən anamın adminiyəm” və ya biz Avitoda müxtəlif versiyaların bir neçə poppet serverləri ilə necə dostluq etdiyimizi və prinsipcə, poppet serverinin idarə olunması ilə bağlı hissəni.7
81,8%Kukla kodunu necə yazırıq: alətlər, sənədlər, sınaqlar, CI/CD.18

22 istifadəçi səs verib. 9 istifadəçi bitərəf qalıb.

Mənbə: www.habr.com

Kuklaya giriş

Əsas məlumat

Manifestlərə giriş

Sintaksis və kod üslubu

Pappetserverdə faylların yeri

Bir neçə döyüş nümunəsi

Düyün və üzərindəki resursun təsviri

Bir qovşaqdakı resurslar arasında əlaqələr

Resurs növləri

fayl

paketi

xidmət

exec

cron

Ümumiyyətlə resurslar haqqında

Resursun unikallığına dair tələblər

Metaparametrlər

Resurslara bağlantılar

Asılılıqlar və bildirişlər

Müəyyən edilməmiş parametrlərin idarə edilməsi

Siniflərə, dəyişənlərə və təriflərə giriş

Dərslər

Dəyişənlər

Siniflər: sinif adı və sinfi daxildir{'sinif adı':}

Müəyyən edir

Siniflər və təriflər üçün asılılıqlar və bildirişlər

Şərti ifadələr və seçicilər

if

əgər

hal

Seçicilər

Module

Modulda fayl strukturu

Moduldakı resursların adları və faylların adları

Templates

ERB haqqında qısaca

Şablondan istifadə nümunəsi

Faktlar və Daxili Dəyişənlər

İcra olunan fayllar şəklində faktlar

Ruby faktları

Mətn faktları

Faktlara çatmaq

Daxili Dəyişənlər

Əlavə 1: bütün bunları necə işlətmək və debug etmək olar?

Agent

Server

Əlavə 2: Kodlaşdırma Təlimatları

Nəticə

Əslində, daha çox material var - aşağıdakı mövzularda məqalələr yaza bilərəm, oxumaqda maraqlı olduğunuza səs verə bilərəm: