Puppet არის კონფიგურაციის მართვის სისტემა. იგი გამოიყენება მასპინძლების სასურველ მდგომარეობაში მოსაყვანად და ამ მდგომარეობის შესანარჩუნებლად.

მე უკვე ხუთ წელზე მეტია ვმუშაობ Puppet-თან. ეს ტექსტი არსებითად არის ოფიციალური დოკუმენტაციის ძირითადი პუნქტების თარგმნილი და ხელახლა დალაგებული კომპილაცია, რაც დამწყებთათვის საშუალებას მისცემს სწრაფად გაიგონ თოჯინების არსი.

ძირითადი ინფორმაცია

Puppet-ის ოპერაციული სისტემა არის კლიენტ-სერვერი, თუმცა ის ასევე მხარს უჭერს უსერვერულ მუშაობას შეზღუდული ფუნქციონირებით.

მოქმედების pull მოდელი გამოიყენება: ნაგულისხმევად, ყოველ ნახევარ საათში ერთხელ კლიენტები დაუკავშირდებიან სერვერს კონფიგურაციისთვის და იყენებენ მას. თუ თქვენ მუშაობდით Ansible-თან, მაშინ ისინი იყენებენ სხვადასხვა push-მოდელს: ადმინისტრატორი იწყებს კონფიგურაციის გამოყენების პროცესს, თავად კლიენტები არაფერს გამოიყენებენ.

ქსელური კომუნიკაციის დროს გამოიყენება ორმხრივი TLS დაშიფვრა: სერვერს და კლიენტს აქვთ საკუთარი პირადი გასაღებები და შესაბამისი სერთიფიკატები. როგორც წესი, სერვერი გასცემს სერთიფიკატებს კლიენტებისთვის, მაგრამ პრინციპში შესაძლებელია გარე CA-ს გამოყენება.

მანიფესტების შესავალი

თოჯინების ტერმინოლოგიაში მარიონეტულ სერვერზე დაკავშირება კვანძები (კვანძები). კვანძების კონფიგურაცია დაწერილია მანიფესტებში სპეციალურ პროგრამირების ენაზე - Puppet DSL.

Puppet DSL არის დეკლარაციული ენა. იგი აღწერს კვანძის სასურველ მდგომარეობას ინდივიდუალური რესურსების დეკლარაციების სახით, მაგალითად:

• ფაილი არსებობს და მას აქვს კონკრეტული შინაარსი.
• პაკეტი დამონტაჟებულია.
• მომსახურება დაიწყო.

რესურსები შეიძლება იყოს ერთმანეთთან დაკავშირებული:

• არსებობს დამოკიდებულებები, ისინი გავლენას ახდენენ რესურსების გამოყენების თანმიმდევრობაზე.
  მაგალითად, „ჯერ დააინსტალირეთ პაკეტი, შემდეგ შეცვალეთ კონფიგურაციის ფაილი, შემდეგ დაიწყეთ სერვისი“.
• არის შეტყობინებები - თუ რესურსი შეიცვალა, ის აგზავნის შეტყობინებებს მასზე გამოწერილ რესურსებზე.
  მაგალითად, თუ კონფიგურაციის ფაილი იცვლება, შეგიძლიათ ავტომატურად გადატვირთოთ სერვისი.

გარდა ამისა, Puppet DSL-ს აქვს ფუნქციები და ცვლადები, ასევე პირობითი განცხადებები და სელექტორები. ასევე მხარდაჭერილია სხვადასხვა შაბლონის მექანიზმები - EPP და ERB.

თოჯინა დაწერილია რუბიში, ამიტომ ბევრი კონსტრუქცია და ტერმინი იქიდან არის აღებული. Ruby საშუალებას გაძლევთ გააფართოვოთ Puppet - დაამატოთ რთული ლოგიკა, ახალი ტიპის რესურსები, ფუნქციები.

სანამ Puppet მუშაობს, სერვერის თითოეული კონკრეტული კვანძის მანიფესტები შედგენილია დირექტორიაში. დირექტორია არის რესურსების სია და მათი ურთიერთობები ფუნქციების, ცვლადების მნიშვნელობის და პირობითი განცხადებების გაფართოების გამოთვლის შემდეგ.

სინტაქსი და კოდის სტილი

აქ მოცემულია ოფიციალური დოკუმენტაციის სექციები, რომლებიც დაგეხმარებათ გაიგოთ სინტაქსი, თუ მოწოდებული მაგალითები საკმარისი არ არის:

• სხვადასხვა ენობრივი კონსტრუქციის სინტაქსი.
• რესურსის სინტაქსი.
• სინტაქსი კვანძების აღწერისთვის.

აი, მაგალითი იმისა, თუ როგორ გამოიყურება მანიფესტი:

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

შეწევა და ხაზის წყვეტები არ არის მანიფესტის აუცილებელი ნაწილი, მაგრამ არსებობს რეკომენდირებული სტილის სახელმძღვანელო. Შემაჯამებელი:

• არ გამოიყენება ორსივრციანი შეწევა, ჩანართები.
• ხვეული ბრეკეტები გამოყოფილია ინტერვალით; მსხვილი ნაწლავები არ არის გამოყოფილი ინტერვალით.
• მძიმეები ყოველი პარამეტრის შემდეგ, ბოლო პარამეტრის ჩათვლით. თითოეული პარამეტრი ცალკე ხაზშია. გამონაკლისი კეთდება შემთხვევისთვის პარამეტრების და ერთი პარამეტრის გარეშე: შეგიძლიათ დაწეროთ ერთ ხაზზე და მძიმის გარეშე (ე.ი. resource { 'title': } и resource { 'title': param => value }).
• პარამეტრებზე ისრები უნდა იყოს იმავე დონეზე.
• მათ წინ იწერება რესურსებთან ურთიერთობის ისრები.

ფაილების ადგილმდებარეობა pappetserver-ზე

დამატებითი ახსნა-განმარტებისთვის მე შემოგთავაზებთ "root directory" კონცეფციას. root დირექტორია არის დირექტორია, რომელიც შეიცავს Puppet-ის კონფიგურაციას კონკრეტული კვანძისთვის.

root დირექტორია განსხვავდება Puppet-ის ვერსიისა და გამოყენებული გარემოს მიხედვით. გარემო არის კონფიგურაციის დამოუკიდებელი ნაკრები, რომლებიც ინახება ცალკეულ დირექტორიაში. ჩვეულებრივ გამოიყენება git-თან ერთად, ამ შემთხვევაში გარემო იქმნება git ტოტებიდან. შესაბამისად, თითოეული კვანძი მდებარეობს ამა თუ იმ გარემოში. ამის კონფიგურაცია შესაძლებელია თავად კვანძზე, ან ENC-ში, რაზეც შემდეგ სტატიაში ვისაუბრებ.

• მესამე ვერსიაში ("ძველი თოჯინა") საბაზისო დირექტორია იყო /etc/puppet. გარემოს გამოყენება არჩევითია - მაგალითად, ჩვენ არ ვიყენებთ მათ ძველ თოჯინასთან ერთად. თუ გარემო გამოიყენება, ისინი ჩვეულებრივ ინახება /etc/puppet/environments, root დირექტორია იქნება გარემოს დირექტორია. თუ გარემო არ არის გამოყენებული, root დირექტორია იქნება საბაზისო დირექტორია.
• მეოთხე ვერსიიდან დაწყებული („ახალი თოჯინა“) გარემოს გამოყენება გახდა სავალდებულო და საბაზისო დირექტორია გადავიდა /etc/puppetlabs/code. შესაბამისად, გარემო ინახება /etc/puppetlabs/code/environments, root დირექტორია არის გარემოს დირექტორია.

root დირექტორიაში უნდა იყოს ქვედირექტორია manifests, რომელიც შეიცავს კვანძების აღწერის ერთ ან მეტ მანიფესტს. გარდა ამისა, უნდა არსებობდეს ქვედირექტორია modules, რომელიც შეიცავს მოდულებს. რა მოდულებია ცოტა მოგვიანებით გეტყვით. გარდა ამისა, ძველ თოჯინას შეიძლება ჰქონდეს ქვედირექტორიაც files, რომელიც შეიცავს სხვადასხვა ფაილებს, რომლებსაც ვაკოპირებთ კვანძებში. ახალ Puppet-ში ყველა ფაილი მოთავსებულია მოდულებში.

Manifest ფაილებს აქვთ გაფართოება .pp.

რამდენიმე საბრძოლო მაგალითი

კვანძისა და მასზე არსებული რესურსის აღწერა

კვანძზე server1.testdomain უნდა შეიქმნას ფაილი /etc/issue შინაარსით Debian GNU/Linux n l. ფაილი უნდა ეკუთვნოდეს მომხმარებელს და ჯგუფს root, წვდომის უფლებები უნდა იყოს 644.

ჩვენ ვწერთ მანიფესტს:

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

ურთიერთობები რესურსებს შორის კვანძზე

კვანძზე server2.testdomain nginx უნდა იყოს გაშვებული, მუშაობს ადრე მომზადებული კონფიგურაციით.

მოდით გავხსნათ პრობლემა:

• საჭიროა პაკეტის დაყენება nginx.
• აუცილებელია კონფიგურაციის ფაილების კოპირება სერვერიდან.
• საჭიროა სერვისის გაშვება nginx.
• თუ კონფიგურაცია განახლებულია, სერვისი უნდა გადატვირთოთ.

ჩვენ ვწერთ მანიფესტს:

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

იმისათვის, რომ ეს იმუშაოს, გჭირდებათ დაახლოებით შემდეგი ფაილის ადგილმდებარეობა მარიონეტულ სერვერზე:

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

რესურსების ტიპები

მხარდაჭერილი რესურსების ტიპების სრული სია შეგიძლიათ იხილოთ აქ დოკუმენტაციაში, აქ აღვწერ ხუთ ძირითად ტიპს, რომლებიც ჩემს პრაქტიკაში საკმარისია პრობლემების უმეტესობის გადასაჭრელად.

ფაილი

მართავს ფაილებს, კატალოგებს, სიმბოლურ ბმულებს, მათ შინაარსს და წვდომის უფლებებს.

პარამეტრები:

• რესურსის სახელი - ფაილის გზა (სურვილისამებრ)
• გზა - ფაილის გზა (თუ სახელი არ არის მითითებული)
• უზრუნველყოს - ფაილის ტიპი:
  • absent - წაშალე ფაილი
  • present — უნდა იყოს ნებისმიერი ტიპის ფაილი (თუ ფაილი არ არის, შეიქმნება ჩვეულებრივი ფაილი)
  • file - ჩვეულებრივი ფაილი
  • directory - დირექტორია
  • link - სიმბლაკი
• შინაარსი — ფაილის შიგთავსი (გამოდგება მხოლოდ ჩვეულებრივი ფაილებისთვის, არ შეიძლება გამოყენებულ იქნას ერთად წყარო ან სამიზნე)
• წყარო — ბმული იმ ბილიკზე, საიდანაც გსურთ ფაილის შინაარსის კოპირება (არ შეიძლება გამოყენებულ იქნას ერთად შინაარსი ან სამიზნე). შეიძლება მითითებული იყოს როგორც URI სქემით puppet: (შემდეგ გამოყენებული იქნება ფაილები მარიონეტული სერვერიდან) და სქემით http: (იმედი მაქვს, გასაგებია, რა მოხდება ამ შემთხვევაში) და თუნდაც დიაგრამით file: ან როგორც აბსოლუტური გზა სქემის გარეშე (მაშინ გამოყენებული იქნება ფაილი ადგილობრივი FS-დან კვანძზე)
• სამიზნე - სადაც უნდა იყოს მითითებული სიმბლაკი (არ შეიძლება გამოყენებულ იქნას ერთად შინაარსი ან წყარო)
• მფლობელი - მომხმარებელი, რომელიც უნდა ფლობდეს ფაილს
• ჯგუფი - ჯგუფი, რომელსაც ფაილი უნდა მიეკუთვნებოდეს
• რეჟიმი - ფაილის ნებართვები (სტრიქონის სახით)
• უკუცემა - ჩართავს რეკურსიულ დირექტორიაში დამუშავებას
• ნაბიჯმა - საშუალებას გაძლევთ წაშალოთ ფაილები, რომლებიც არ არის აღწერილი Puppet-ში
• აიძულებს - საშუალებას გაძლევთ წაშალოთ დირექტორიაები, რომლებიც არ არის აღწერილი Puppet-ში

პაკეტი

აყენებს და შლის პაკეტებს. შეუძლია შეტყობინებების დამუშავება - ხელახლა დააინსტალირებს პაკეტს, თუ მითითებულია პარამეტრი reinstall_on_refresh.

პარამეტრები:

• რესურსის სახელი - პაკეტის სახელი (სურვილისამებრ)
• სახელი - პაკეტის სახელი (თუ სახელში არ არის მითითებული)
• პროვაიდერი - გამოსაყენებლად პაკეტის მენეჯერი
• უზრუნველყოს - პაკეტის სასურველი მდგომარეობა:
  • present, installed - დაინსტალირებული ნებისმიერი ვერსია
  • latest - დაინსტალირებულია უახლესი ვერსია
  • absent - წაშლილია (apt-get remove)
  • purged - წაშლილია კონფიგურაციის ფაილებთან ერთად (apt-get purge)
  • held - პაკეტის ვერსია დაბლოკილია (apt-mark hold)
  • любая другая строка — მითითებული ვერსია დაინსტალირებულია
• reinstall_on_refresh - თუ true, შემდეგ შეტყობინების მიღებისთანავე პაკეტი ხელახლა დაინსტალირდება. სასარგებლოა წყაროზე დაფუძნებული დისტრიბუციებისთვის, სადაც შესაძლოა საჭირო გახდეს პაკეტების ხელახალი აშენება build-ის პარამეტრების შეცვლისას. ნაგულისხმევი false.

მომსახურება

მართავს სერვისებს. შეუძლია შეტყობინებების დამუშავება - განაახლებს სერვისს.

პარამეტრები:

• რესურსის სახელი — სამართავი სერვისი (არასავალდებულო)
• სახელი — სერვისი, რომლის მართვაც საჭიროა (თუ სახელში არ არის მითითებული)
• უზრუნველყოს - სერვისის სასურველი მდგომარეობა:
  • running - დაიწყო
  • stopped - გაჩერდა
• საშუალებას — აკონტროლებს სერვისის დაწყების შესაძლებლობას:
  • true — ჩართულია autorun (systemctl enable)
  • mask - გადაცმული (systemctl mask)
  • false - ავტომატური გაშვება გამორთულია (systemctl disable)
• გადატვირთვა - ბრძანება სერვისის გადატვირთვისთვის
• სტატუსი - ბრძანება მომსახურების სტატუსის შესამოწმებლად
• ჰარესტარტი — მიუთითეთ, მხარს უჭერს თუ არა სერვისის initscript გადატვირთვას. თუ false და პარამეტრი მითითებულია გადატვირთვა - გამოიყენება ამ პარამეტრის მნიშვნელობა. თუ false და პარამეტრი გადატვირთვა არ არის მითითებული - სერვისი შეჩერებულია და დაიწყო გადატვირთვა (მაგრამ systemd იყენებს ბრძანებას systemctl restart).
• აქვს სტატუსი — მიუთითეთ, მხარს უჭერს თუ არა სერვისის initscript ბრძანებას status. თუ false, შემდეგ გამოიყენება პარამეტრის მნიშვნელობა სტატუსი. ნაგულისხმევი true.

აღმასრულებელი

აწარმოებს გარე ბრძანებებს. თუ არ მიუთითებთ პარამეტრებს ქმნის, მხოლოდ თუ, თუ არ ან განახლებით, ბრძანება შესრულდება ყოველ ჯერზე Puppet-ის გაშვებისას. შეუძლია შეტყობინებების დამუშავება - აწარმოებს ბრძანებას.

პარამეტრები:

• რესურსის სახელი - ბრძანება უნდა შესრულდეს (სურვილისამებრ)
• ბრძანება — შესასრულებელი ბრძანება (თუ სახელში არ არის მითითებული)
• გზა — ბილიკები, რომლებშიც უნდა ვეძებოთ შესრულებადი ფაილი
• მხოლოდ თუ - თუ ამ პარამეტრში მითითებული ბრძანება დასრულებულია ნულოვანი დაბრუნების კოდით, მთავარი ბრძანება შესრულდება
• თუ არ — თუ ამ პარამეტრში მითითებული ბრძანება დასრულებულია არანულოვანი დაბრუნების კოდით, მთავარი ბრძანება შესრულდება
• ქმნის — თუ ამ პარამეტრში მითითებული ფაილი არ არსებობს, მთავარი ბრძანება შესრულდება
• განახლებით - თუ true, მაშინ ბრძანება შესრულდება მხოლოდ მაშინ, როდესაც ეს exec მიიღებს შეტყობინებას სხვა რესურსებიდან
• cwd — დირექტორია, საიდანაც აწარმოებს ბრძანებას
• მომხმარებელი - მომხმარებელი, ვისგანაც გაუშვით ბრძანება
• პროვაიდერი - როგორ აწარმოოთ ბრძანება:
  • posix — ბავშვის პროცესი უბრალოდ შექმნილია, აუცილებლად მიუთითეთ გზა
  • shell - ბრძანება გაშვებულია ჭურვში /bin/sh, შეიძლება არ იყოს მითითებული გზა, შეგიძლიათ გამოიყენოთ გლობინგი, მილები და ჭურვის სხვა მახასიათებლები. როგორც წესი, გამოვლენილია ავტომატურად, თუ არის რაიმე სპეციალური სიმბოლო (|, ;, &&, || და ა.შ.)

cron

აკონტროლებს cronjob-ებს.

პარამეტრები:

• რესურსის სახელი - მხოლოდ გარკვეული სახის იდენტიფიკატორი
• უზრუნველყოს - გვირგვინის მდგომარეობა:
  • present - შექმნა თუ არ არსებობს
  • absent - წაშალე, თუ არსებობს
• ბრძანება - რა ბრძანება გაუშვა
• გარემოს - რომელ გარემოში უნდა გაუშვათ ბრძანება (გარემოს ცვლადების სია და მათი მნიშვნელობები =)
• მომხმარებელი - რომელი მომხმარებლისგან გაუშვით ბრძანება
• წუთი, საათი, კვირის დღე, თვის, თვის დღე — როდის გაუშვათ კრონი. თუ რომელიმე ატრიბუტი არ არის მითითებული, მისი მნიშვნელობა კრონტაბში იქნება *.

თოჯინაში 6.0 cron თითქოს ამოღებულია ყუთიდან puppetserver-ში, ასე რომ არ არსებობს დოკუმენტაცია ზოგად საიტზე. Მაგრამ ის არის ყუთში თოჯინების აგენტში, ამიტომ არ არის საჭირო მისი ცალკე დაყენება. თქვენ შეგიძლიათ ნახოთ დოკუმენტაცია ამისთვის თოჯინების მეხუთე ვერსიის დოკუმენტაციაშიან GitHub-ზე.

ზოგადად რესურსების შესახებ

მოთხოვნები რესურსის უნიკალურობისთვის

ყველაზე გავრცელებული შეცდომა, რომელსაც ვხვდებით დუბლიკატი დეკლარაცია. ეს შეცდომა ჩნდება, როდესაც დირექტორიაში გამოჩნდება ერთი და იგივე ტიპის ორი ან მეტი რესურსი ერთი და იგივე სახელით.

ამიტომ კიდევ ერთხელ დავწერ: მანიფესტები ერთი და იგივე კვანძისთვის არ უნდა შეიცავდეს იმავე ტიპის რესურსებს იგივე სათაურით!

ზოგჯერ საჭიროა პაკეტების დაყენება იმავე სახელით, მაგრამ სხვადასხვა პაკეტების მენეჯერებით. ამ შემთხვევაში, თქვენ უნდა გამოიყენოთ პარამეტრი nameშეცდომის თავიდან ასაცილებლად:

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

რესურსების სხვა ტიპებს აქვთ მსგავსი ვარიანტები, რათა თავიდან აიცილონ დუბლირება − name у მომსახურება, command у აღმასრულებელი, და ასე შემდეგ.

მეტაპარამეტრები

რესურსის თითოეულ ტიპს აქვს გარკვეული სპეციალური პარამეტრები, მიუხედავად მისი ბუნებისა.

მეტა პარამეტრების სრული სია თოჯინების დოკუმენტაციაში.

მოკლე სია:

• მოითხოვს — ეს პარამეტრი მიუთითებს, რომელ რესურსებზეა დამოკიდებული ეს რესურსი.
• ადრე - ეს პარამეტრი განსაზღვრავს თუ რომელი რესურსებია დამოკიდებული ამ რესურსზე.
• ხელმოწერა — ეს პარამეტრი განსაზღვრავს, თუ რომელი რესურსებიდან იღებს შეტყობინებებს ეს რესურსი.
• აცნობოს — ეს პარამეტრი განსაზღვრავს, რომელი რესურსები იღებენ შეტყობინებებს ამ რესურსიდან.

ყველა ჩამოთვლილი მეტაპარამეტრი იღებს ან ერთ რესურს ბმულს ან კვადრატულ ფრჩხილებში ბმულების მასივს.

ბმულები რესურსებთან

რესურსის ბმული უბრალოდ რესურსის ხსენებაა. ისინი ძირითადად გამოიყენება დამოკიდებულებების აღსანიშნავად. არარსებულ რესურსზე მითითება გამოიწვევს კომპილაციის შეცდომას.

ბმულის სინტაქსი ასეთია: რესურსის ტიპი მთავრული ასოებით (თუ ტიპის სახელი შეიცავს ორმაგ ორწერტილს, მაშინ სახელის თითოეული ნაწილი ორწერტილს შორის არის დიდი ასოებით), შემდეგ რესურსის სახელი კვადრატულ ფრჩხილებში (სახელის შემთხვევა არ იცვლება!). არ უნდა იყოს სივრცეები; კვადრატული ფრჩხილები იწერება უშუალოდ ტიპის სახელის შემდეგ.

მაგალითი:

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

დამოკიდებულებები და შეტყობინებები

დოკუმენტაცია აქ.

როგორც უკვე აღვნიშნეთ, რესურსებს შორის მარტივი დამოკიდებულება გარდამავალია. სხვათა შორის, ფრთხილად იყავით დამოკიდებულებების დამატებისას - შეგიძლიათ შექმნათ ციკლური დამოკიდებულებები, რაც გამოიწვევს კომპილაციის შეცდომას.

დამოკიდებულებისგან განსხვავებით, შეტყობინებები არ არის გარდამავალი. შეტყობინებებისთვის გამოიყენება შემდეგი წესები:

• თუ რესურსი მიიღებს შეტყობინებას, ის განახლდება. განახლების მოქმედებები დამოკიდებულია რესურსის ტიპზე − აღმასრულებელი აწარმოებს ბრძანებას, მომსახურება განაახლებს სერვისს, პაკეტი ხელახლა აყენებს პაკეტს. თუ რესურსს არ აქვს განსაზღვრული განახლების მოქმედება, მაშინ არაფერი ხდება.
• Puppet-ის ერთი გაშვების დროს რესურსი განახლდება არა უმეტეს ერთხელ. ეს შესაძლებელია, რადგან შეტყობინებები მოიცავს დამოკიდებულებებს და დამოკიდებულების გრაფიკი არ შეიცავს ციკლებს.
• თუ Puppet ცვლის რესურსის მდგომარეობას, რესურსი აგზავნის შეტყობინებებს მასზე გამოწერილ ყველა რესურსზე.
• თუ რესურსი განახლებულია, ის აგზავნის შეტყობინებებს მასზე გამოწერილ ყველა რესურსზე.

დაუზუსტებელი პარამეტრების დამუშავება

როგორც წესი, თუ რომელიმე რესურსის პარამეტრს არ აქვს ნაგულისხმევი მნიშვნელობა და ეს პარამეტრი არ არის მითითებული მანიფესტში, მაშინ Puppet არ შეცვლის ამ თვისებას კვანძის შესაბამისი რესურსისთვის. მაგალითად, თუ ტიპის რესურსი ფაილი პარამეტრი არ არის მითითებული owner, მაშინ Puppet არ შეცვლის შესაბამისი ფაილის მფლობელს.

კლასების, ცვლადების და განმარტებების შესავალი

დავუშვათ, გვაქვს რამდენიმე კვანძი, რომლებსაც აქვთ კონფიგურაციის ერთი და იგივე ნაწილი, მაგრამ ასევე არის განსხვავებები - წინააღმდეგ შემთხვევაში ჩვენ შეგვიძლია აღვწეროთ ეს ყველაფერი ერთ ბლოკში node {}. რა თქმა უნდა, შეგიძლიათ უბრალოდ დააკოპიროთ კონფიგურაციის იდენტური ნაწილები, მაგრამ ზოგადად ეს ცუდი გამოსავალია - კონფიგურაცია იზრდება და თუ კონფიგურაციის ზოგად ნაწილს შეცვლით, ბევრგან მოგიწევთ იგივეს რედაქტირება. ამავდროულად, ადვილია შეცდომის დაშვება და ზოგადად, DRY (არ გაიმეორო) პრინციპი გამოიგონეს მიზეზით.

ამ პრობლემის გადასაჭრელად არსებობს ისეთი დიზაინი, როგორიცაა კლასი.

კლასები

კლასი არის poppet კოდის დასახელებული ბლოკი. კლასები საჭიროა კოდის ხელახლა გამოსაყენებლად.

პირველ რიგში საჭიროა კლასის აღწერა. თავად აღწერა არსად არ ამატებს რესურსებს. კლასი აღწერილია მანიფესტებში:

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

ამის შემდეგ კლასის გამოყენება შესაძლებელია:

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

მაგალითი წინა ამოცანიდან - მოდით გადავიტანოთ nginx-ის ინსტალაცია და კონფიგურაცია კლასში:

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

node 'server2.testdomain' {
    include nginx_example
}

ცვლადები

წინა მაგალითის კლასი საერთოდ არ არის მოქნილი, რადგან მას ყოველთვის მოაქვს იგივე nginx კონფიგურაცია. მოდით გავაკეთოთ გზა კონფიგურაციის ცვლადისკენ, შემდეგ ეს კლასი შეიძლება გამოყენებულ იქნას nginx-ის დასაყენებლად ნებისმიერი კონფიგურაციით.

ეს შეიძლება გაკეთდეს ცვლადების გამოყენებით.

ყურადღება: Puppet-ში ცვლადები უცვლელია!

გარდა ამისა, ცვლადის წვდომა შესაძლებელია მხოლოდ მას შემდეგ, რაც გამოცხადდება, წინააღმდეგ შემთხვევაში ცვლადის მნიშვნელობა იქნება undef.

ცვლადებთან მუშაობის მაგალითი:

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

თოჯინას აქვს სახელთა სივრცეები, და ცვლადებს, შესაბამისად, აქვთ ხილვადობის ზონა: ცვლადი იგივე სახელით შეიძლება განისაზღვროს სხვადასხვა სახელების სივრცეში. ცვლადის მნიშვნელობის ამოხსნისას ცვლადი იძებნება მიმდინარე სახელთა სივრცეში, შემდეგ მიმდებარე სახელთა სივრცეში და ა.შ.

სახელთა სივრცის მაგალითები:

• გლობალური - იქ მიდის ცვლადები კლასის ან კვანძის აღწერილობის გარეთ;
• კვანძის სახელთა სივრცე კვანძის აღწერაში;
• კლასის სახელთა სივრცე კლასის აღწერაში.

ცვლადზე წვდომისას გაურკვევლობის თავიდან ასაცილებლად, შეგიძლიათ მიუთითოთ სახელთა სივრცე ცვლადის სახელში:

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

მოდით შევთანხმდეთ, რომ nginx კონფიგურაციის გზა ცვლადშია $nginx_conf_source. შემდეგ კლასი ასე გამოიყურება:

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

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

თუმცა, მოცემული მაგალითი ცუდია, რადგან არსებობს გარკვეული „საიდუმლო ცოდნა“, რომ სადღაც კლასში გამოიყენება ცვლადი ამა თუ იმ სახელით. ბევრად უფრო სწორია ამ ცოდნის ზოგადი ფორმირება - კლასებს შეიძლება ჰქონდეთ პარამეტრები.

კლასის პარამეტრები არის ცვლადები კლასის სახელთა სივრცეში, ისინი მითითებულია კლასის სათაურში და შეიძლება გამოყენებულ იქნას როგორც ჩვეულებრივი ცვლადები კლასის სხეულში. პარამეტრის მნიშვნელობები მითითებულია მანიფესტში კლასის გამოყენებისას.

პარამეტრი შეიძლება დაყენდეს ნაგულისხმევ მნიშვნელობაზე. თუ პარამეტრს არ აქვს ნაგულისხმევი მნიშვნელობა და მნიშვნელობა არ არის დაყენებული გამოყენებისას, ეს გამოიწვევს კომპილაციის შეცდომას.

მოდით გავატაროთ კლასის პარამეტრიზაცია ზემოთ მოყვანილი მაგალითიდან და დავამატოთ ორი პარამეტრი: პირველი, საჭირო, არის კონფიგურაციის გზა, ხოლო მეორე, სურვილისამებრ, არის პაკეტის სახელი nginx-ით (მაგალითად, Debian-ში არის პაკეტები nginx, nginx-light, nginx-full).

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

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

Puppet-ში ცვლადები იბეჭდება. ჭამე მონაცემთა მრავალი ტიპი. მონაცემთა ტიპები, როგორც წესი, გამოიყენება კლასებსა და განმარტებებში გადაცემული პარამეტრების მნიშვნელობების დასადასტურებლად. თუ გადაცემული პარამეტრი არ ემთხვევა მითითებულ ტიპს, მოხდება კომპილაციის შეცდომა.

ტიპი იწერება პარამეტრის სახელის წინ:

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

კლასები: მოიცავს classname vs class{'classname':}

თითოეული კლასი არის ტიპის რესურსი კლასი. როგორც ნებისმიერი სხვა ტიპის რესურსი, არ შეიძლება იყოს ერთი და იგივე კლასის ორი ინსტანცია ერთსა და იმავე კვანძზე.

თუ ცდილობთ კლასის დამატებას იმავე კვანძში ორჯერ გამოყენებით class { 'classname':} (არავითარი განსხვავება, განსხვავებული ან იდენტური პარამეტრებით), იქნება კომპილაციის შეცდომა. მაგრამ თუ იყენებთ კლასს რესურსის სტილში, შეგიძლიათ დაუყოვნებლივ დააყენოთ მისი ყველა პარამეტრი მანიფესტში.

თუმცა, თუ იყენებთ include, მაშინ კლასის დამატება შესაძლებელია რამდენჯერაც გსურთ. ფაქტია რომ include არის იდემპოტენტური ფუნქცია, რომელიც ამოწმებს, დაემატა თუ არა კლასი დირექტორიაში. თუ კლასი არ არის დირექტორიაში, ის ამატებს მას და თუ უკვე არსებობს, არაფერს აკეთებს. მაგრამ გამოყენების შემთხვევაში include თქვენ არ შეგიძლიათ კლასის პარამეტრების დაყენება კლასის დეკლარაციის დროს - ყველა საჭირო პარამეტრი უნდა იყოს მითითებული გარე მონაცემთა წყაროში - Hiera ან ENC. მათ შესახებ მომდევნო სტატიაში ვისაუბრებთ.

განსაზღვრავს

როგორც წინა ბლოკში ითქვა, ერთი და იგივე კლასი არ შეიძლება იყოს ერთზე მეტჯერ კვანძზე. თუმცა, ზოგიერთ შემთხვევაში თქვენ უნდა შეგეძლოთ გამოიყენოთ კოდის ერთი და იგივე ბლოკი სხვადასხვა პარამეტრით იმავე კვანძზე. სხვა სიტყვებით რომ ვთქვათ, საჭიროა საკუთარი რესურსის ტიპი.

მაგალითად, PHP მოდულის დასაყენებლად Avito-ში ვაკეთებთ შემდეგს:

1. დააინსტალირეთ პაკეტი ამ მოდულით.
2. მოდით შევქმნათ კონფიგურაციის ფაილი ამ მოდულისთვის.
3. ჩვენ ვქმნით სიმლინკს კონფიგურაციასთან php-fpm-ისთვის.
4. ჩვენ ვქმნით სიმბოლურ ბმულს php cli კონფიგურაციისთვის.

ასეთ შემთხვევებში, ისეთი დიზაინი, როგორიცაა განსაზღვრა (განსაზღვრა, განსაზღვრული ტიპი, განსაზღვრული რესურსის ტიპი). A Define კლასის მსგავსია, მაგრამ არის განსხვავებები: პირველი, თითოეული Define არის რესურსის ტიპი და არა რესურსი; მეორეც, თითოეულ განმარტებას აქვს იმპლიციტური პარამეტრი $title, სადაც იწერება რესურსის სახელი მისი დეკლარაციისას. ისევე, როგორც კლასების შემთხვევაში, ჯერ განმარტება უნდა იყოს აღწერილი, რის შემდეგაც მისი გამოყენება შეიძლება.

გამარტივებული მაგალითი PHP მოდულით:

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

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

დუბლიკატი დეკლარაციის შეცდომის დაჭერის უმარტივესი გზა არის Define-ში. ეს ხდება იმ შემთხვევაში, თუ განსაზღვრებას აქვს რესურსი მუდმივი სახელით და არის ამ განმარტების ორი ან მეტი შემთხვევა ზოგიერთ კვანძზე.

ამისგან თავის დაცვა მარტივია: განმარტების შიგნით არსებულ ყველა რესურსს უნდა ჰქონდეს სახელი იმის მიხედვით $title. ალტერნატივა არის რესურსების არაპოტენტური დამატება; უმარტივეს შემთხვევაში, საკმარისია განსაზღვრების ყველა ინსტანციისთვის საერთო რესურსები ცალკე კლასში გადავიტანოთ და ეს კლასი შეიტანოთ განმარტებაში - ფუნქციაში. include უძლური.

არსებობს რესურსების დამატებისას იმპოტენციის მიღწევის სხვა გზები, კერძოდ ფუნქციების გამოყენება defined и ensure_resources, მაგრამ ამის შესახებ მომდევნო ეპიზოდში მოგიყვებით.

დამოკიდებულებები და შეტყობინებები კლასებისა და განმარტებებისთვის

კლასები და განმარტებები ამატებენ შემდეგ წესებს დამოკიდებულებებისა და შეტყობინებების მართვაში:

• დამოკიდებულება კლასზე/define ამატებს დამოკიდებულებებს კლასის ყველა რესურსზე/define;
• კლასის/განსაზღვის დამოკიდებულება ამატებს დამოკიდებულებებს ყველა კლასის/განსაზღვის რესურსებს;
• class/define შეტყობინება აცნობებს კლასის ყველა რესურსს/define;
• class/define გამოწერა გამოიწერს კლასის/define-ის ყველა რესურსს.

პირობითი განცხადებები და სელექტორები

დოკუმენტაცია აქ.

if

აქ მარტივია:

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

თუ არ

თუ არ არის if საპირისპირო: კოდის ბლოკი შესრულდება, თუ გამოთქმა მცდარია.

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

შემთხვევაში

აქაც არაფერია რთული. მნიშვნელობებად შეგიძლიათ გამოიყენოთ რეგულარული მნიშვნელობები (სტრიქონები, რიცხვები და ა.შ.), რეგულარული გამონათქვამები და მონაცემთა ტიპები.

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

სელექტორები

სელექტორი არის ენის მსგავსი კონსტრუქცია case, მაგრამ კოდის ბლოკის შესრულების ნაცვლად, ის აბრუნებს მნიშვნელობას.

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

მოდულები

როდესაც კონფიგურაცია მცირეა, ის ადვილად შეინახება ერთ მანიფესტში. მაგრამ რაც უფრო მეტ კონფიგურაციას აღვწერთ, მით უფრო მეტი კლასი და კვანძია მანიფესტში, ის იზრდება და უხერხული ხდება მუშაობა.

გარდა ამისა, არსებობს კოდის ხელახალი გამოყენების პრობლემა - როდესაც ყველა კოდი ერთ მანიფესტშია, ძნელია ამ კოდის სხვებთან გაზიარება. ამ ორი პრობლემის გადასაჭრელად, Puppet-ს აქვს ერთეული, რომელსაც ეწოდება მოდულები.

მოდულები - ეს არის კლასების კომპლექტი, განმარტებები და სხვა თოჯინების ერთეულები, რომლებიც განთავსებულია ცალკე დირექტორიაში. სხვა სიტყვებით რომ ვთქვათ, მოდული არის მარიონეტული ლოგიკის დამოუკიდებელი ნაწილი. მაგალითად, შეიძლება იყოს nginx-თან მუშაობის მოდული და მასში იყოს ის, რაც და მხოლოდ ის არის საჭირო nginx-თან მუშაობისთვის, ან შეიძლება იყოს PHP-თან მუშაობის მოდული და ა.შ.

მოდულები ვერსიირებულია და ასევე მხარდაჭერილია მოდულების ერთმანეთზე დამოკიდებულებები. არსებობს მოდულების ღია საცავი - თოჯინების გაყალბება.

მარიონეტულ სერვერზე მოდულები განლაგებულია root დირექტორიას მოდულების ქვედირექტორიაში. თითოეული მოდულის შიგნით არის სტანდარტული დირექტორია სქემა - მანიფესტები, ფაილები, შაბლონები, lib და ა.შ.

ფაილის სტრუქტურა მოდულში

მოდულის ფესვი შეიძლება შეიცავდეს შემდეგ საქაღალდეებს აღწერითი სახელებით:

• manifests - შეიცავს მანიფესტებს
• files - შეიცავს ფაილებს
• templates - შეიცავს შაბლონებს
• lib - შეიცავს Ruby კოდს

ეს არ არის დირექტორიებისა და ფაილების სრული სია, მაგრამ ამ სტატიისთვის ამ დროისთვის საკმარისია.

რესურსების სახელები და ფაილების სახელები მოდულში

დოკუმენტაცია აქ.

რესურსები (კლასები, განმარტებები) მოდულში არ შეიძლება დასახელდეს ისე, როგორც გსურთ. გარდა ამისა, არსებობს პირდაპირი მიმოწერა რესურსის სახელსა და ფაილის სახელს შორის, რომელშიც Puppet ეძებს ამ რესურსის აღწერას. თუ თქვენ დაარღვევთ დასახელების წესებს, მაშინ Puppet უბრალოდ ვერ იპოვის რესურსის აღწერას და მიიღებთ კომპილაციის შეცდომას.

წესები მარტივია:

• მოდულის ყველა რესურსი უნდა იყოს მოდულის სახელთა სივრცეში. თუ მოდული გამოძახებულია foo, მაშინ მასში არსებული ყველა რესურსი უნდა იყოს დასახელებული foo::<anything>, ან უბრალოდ foo.
• რესურსი მოდულის სახელით უნდა იყოს ფაილში init.pp.
• სხვა რესურსებისთვის, ფაილის დასახელების სქემა შემდეგია:
  • მოდულის სახელის პრეფიქსი გაუქმებულია
  • ყველა ორმაგი ორწერტილი, ასეთის არსებობის შემთხვევაში, შეიცვლება შტრიხებით
  • დამატებულია გაფართოება .pp

დემონსტრირებას გავაკეთებ მაგალითით. ვთქვათ, ვწერ მოდულს nginx. იგი შეიცავს შემდეგ რესურსებს:

• კლასი nginx აღწერილია მანიფესტში init.pp;
• კლასი nginx::service აღწერილია მანიფესტში service.pp;
• განსაზღვრა nginx::server აღწერილია მანიფესტში server.pp;
• განსაზღვრა nginx::server::location აღწერილია მანიფესტში server/location.pp.

Templates

რა თქმა უნდა, თქვენ თვითონ იცით, რა არის შაბლონები; მე მათ დეტალურად არ აღვწერ აქ. მაგრამ ყოველი შემთხვევისთვის დავტოვებ ბმული ვიკიპედიაზე.

როგორ გამოვიყენოთ შაბლონები: შაბლონის მნიშვნელობა შეიძლება გაფართოვდეს ფუნქციის გამოყენებით template, რომელსაც გაივლის გზა შაბლონისკენ. ტიპის რესურსებისთვის ფაილი გამოიყენება პარამეტრთან ერთად content. მაგალითად, ასე:

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

ბილიკის ნახვა <modulename>/<filename> გულისხმობს ფაილს <rootdir>/modules/<modulename>/templates/<filename>.

გარდა ამისა, არსებობს ფუნქცია inline_template - ის იღებს შაბლონის ტექსტს შეყვანის სახით და არა ფაილის სახელს.

შაბლონებში შეგიძლიათ გამოიყენოთ თოჯინების ყველა ცვლადი მიმდინარე მასშტაბში.

თოჯინა მხარს უჭერს შაბლონებს ERB და EPP ფორმატში:

• EPP დოკუმენტაცია.
• ERB დოკუმენტაცია.

მოკლედ 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-შიან როგორ შესრულებადი ფაილები. ფაქტები ასევე შეიძლება წარმოდგენილი იყოს ფორმით ტექსტური ფაილები მონაცემებით კვანძებზე.

ოპერაციის დროს მარიონეტული აგენტი ჯერ აკოპირებს ყველა ხელმისაწვდომ ფაქტების შემგროვებელს pappetserver-დან კვანძში, რის შემდეგაც ის იწყებს მათ და აგზავნის შეგროვებულ ფაქტებს სერვერზე; ამის შემდეგ სერვერი იწყებს კატალოგის შედგენას.

ფაქტები შესრულებადი ფაილების სახით

ასეთი ფაქტები მოთავსებულია დირექტორიაში მოდულებში facts.d. რა თქმა უნდა, ფაილები უნდა იყოს შესრულებადი. გაშვებისას მათ უნდა მიაწოდონ ინფორმაცია სტანდარტულ გამოსავალზე YAML ან key=value ფორმატში.

არ დაგავიწყდეთ, რომ ფაქტები ეხება ყველა კვანძს, რომელსაც აკონტროლებს poppet სერვერი, რომელზედაც განლაგებულია თქვენი მოდული. ამიტომ, სკრიპტში დარწმუნდით, რომ სისტემას აქვს ყველა პროგრამა და ფაილი, რომელიც აუცილებელია თქვენი ფაქტის მუშაობისთვის.

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

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

ლალის ფაქტები

ასეთი ფაქტები მოთავსებულია დირექტორიაში მოდულებში lib/facter.

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

ტექსტის ფაქტები

ასეთი ფაქტები განთავსებულია დირექტორიაში არსებულ კვანძებზე /etc/facter/facts.d ძველ თოჯინაში ან /etc/puppetlabs/facts.d ახალ თოჯინაში.

examplefact=examplevalue

---
examplefact2: examplevalue2
anotherfact: anothervalue

ფაქტებთან მოხვედრა

ფაქტებთან მიახლოების ორი გზა არსებობს:

• ლექსიკონის მეშვეობით $facts: $facts['fqdn'];
• ფაქტის სახელის გამოყენება ცვლადის სახელად: $fqdn.

უმჯობესია გამოიყენოთ ლექსიკონი $facts, ან კიდევ უკეთესი, მიუთითეთ გლობალური სახელების სივრცე ($::facts).

აქ არის დოკუმენტაციის შესაბამისი ნაწილი.

ჩამონტაჟებული ცვლადები

გარდა ფაქტებისა, არის ასევე ზოგიერთი ცვლადი, ხელმისაწვდომია გლობალურ სახელთა სივრცეში.

• სანდო ფაქტები - ცვლადები, რომლებიც აღებულია კლიენტის სერთიფიკატიდან (რადგან სერთიფიკატი ჩვეულებრივ გაიცემა poppet სერვერზე, აგენტს არ შეუძლია უბრალოდ მიიღოს და შეცვალოს მისი სერტიფიკატი, ამიტომ ცვლადები "სანდო"): სერთიფიკატის სახელი, სახელი ჰოსტი და დომენი, გაფართოებები სერტიფიკატისგან.
• სერვერის ფაქტები — სერვერის შესახებ ინფორმაციასთან დაკავშირებული ცვლადები — ვერსია, სახელი, სერვერის IP მისამართი, გარემო.
• აგენტის ფაქტები - ცვლადები დამატებულია უშუალოდ მარიონეტული აგენტის მიერ და არა ფაქტორების მიხედვით - სერტიფიკატის სახელი, აგენტის ვერსია, მარიონეტული ვერსია.
• სამაგისტრო ცვლადები - Pappetmaster ცვლადები (sic!). ეს დაახლოებით იგივეა, რაც შიგნით სერვერის ფაქტები, პლუს კონფიგურაციის პარამეტრის მნიშვნელობები ხელმისაწვდომია.
• შემდგენელი ცვლადები - შემდგენელი ცვლადები, რომლებიც განსხვავდება თითოეულ საზღვრებში: მიმდინარე მოდულის სახელი და მოდულის სახელი, რომელშიც წვდომა იქნა მიმდინარე ობიექტზე. ისინი შეიძლება გამოყენებულ იქნას, მაგალითად, იმის შესამოწმებლად, რომ თქვენი პირადი გაკვეთილები არ გამოიყენება პირდაპირ სხვა მოდულებიდან.

დამატება 1: როგორ უნდა გაუშვათ და გამართოთ ეს ყველაფერი?

სტატია შეიცავს მარიონეტული კოდის ბევრ მაგალითს, მაგრამ საერთოდ არ გვითხრა, როგორ უნდა გაუშვათ ეს კოდი. ისე, თავს ვისწორებ.

აგენტი საკმარისია Puppet-ის გასაშვებად, მაგრამ უმეტეს შემთხვევაში თქვენ დაგჭირდებათ სერვერიც.

აგენტი

ყოველ შემთხვევაში მე-XNUMX ვერსიიდან, მარიონეტული აგენტის პაკეტები ოფიციალური თოჯინების საცავი შეიცავს ყველა დამოკიდებულებას (რუბი და შესაბამისი ძვირფასი ქვები), ასე რომ, ინსტალაციის სირთულეები არ არის (მე ვსაუბრობ 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.

სერვერი

ამ სტატიაში არ განვიხილავ pappetserver-ის სრულ დაყენებას და მასზე კოდის განთავსებას; მხოლოდ ვიტყვი, რომ ყუთიდან არის სერვერის სრულად ფუნქციონალური ვერსია, რომელიც არ საჭიროებს დამატებით კონფიგურაციას მცირე რაოდენობით სამუშაოდ. კვანძები (ვთქვათ, ასამდე). კვანძების უფრო დიდი რაოდენობა საჭიროებს დარეგულირებას - ნაგულისხმევად, თოჯინების სერვერი უშვებს არაუმეტეს ოთხ მუშაკს, უფრო დიდი შესრულებისთვის საჭიროა მათი რიცხვის გაზრდა და არ დაგავიწყდეთ მეხსიერების ლიმიტების გაზრდა, წინააღმდეგ შემთხვევაში სერვერი უმეტეს დროს აგროვებს ნაგავს.

კოდის გავრცელება - თუ ეს გჭირდებათ სწრაფად და მარტივად, მაშინ ნახეთ (r10k)[https://github.com/puppetlabs/r10k], მცირე დანადგარებისთვის ეს საკმაოდ საკმარისი უნდა იყოს.

დანართი 2: კოდირების სახელმძღვანელო პრინციპები

1. მოათავსეთ მთელი ლოგიკა კლასებში და განმარტებებში.
2. შეინახეთ კლასები და განმარტებები მოდულებში და არა კვანძებში, რომლებიც აღწერენ მანიფესტებს.
3. გამოიყენეთ ფაქტები.
4. ნუ გააკეთებთ if-ებს ჰოსტების სახელებზე დაყრდნობით.
5. თავისუფლად შეგიძლიათ დაამატოთ პარამეტრები კლასებისთვის და განმარტებებისთვის - ეს უკეთესია, ვიდრე კლასის სხეულში დამალული იმპლიციტური ლოგიკა/განსაზღვრა.

რატომ გირჩევთ ამის გაკეთებას შემდეგ სტატიაში აგიხსნით.

დასკვნა

მოდით დავასრულოთ შესავალი. შემდეგ სტატიაში მოგიყვებით Hiera-ს, ENC-სა და PuppetDB-ზე.

გამოკითხვაში მონაწილეობა შეუძლიათ მხოლოდ დარეგისტრირებულ მომხმარებლებს. Შებრძანდითგთხოვთ

სინამდვილეში, გაცილებით მეტი მასალაა - შემიძლია დავწერო სტატიები შემდეგ თემებზე, მივცე ხმა იმას, რისი წაკითხვაც გაინტერესებს:

• 59,1%მოწინავე მარიონეტული კონსტრუქციები - შემდეგი დონის სისულელეები: მარყუჟები, რუკების და სხვა ლამბდა გამონათქვამები, რესურსების შემგროვებლები, ექსპორტირებული რესურსები და მასპინძელთა შორის კომუნიკაცია თოჯინების, ტეგების, პროვაიდერების, მონაცემთა აბსტრაქტული ტიპების საშუალებით.13
• 31,8%„მე ვარ დედაჩემის ადმინი“ ან როგორ დავმეგობრდით Avito-ში სხვადასხვა ვერსიის რამდენიმე პოპეტ სერვერთან და, პრინციპში, პოპეტის სერვერის ადმინისტრირების ნაწილთან.7
• 81,8%როგორ ვწერთ მარიონეტულ კოდს: ინსტრუმენტაცია, დოკუმენტაცია, ტესტირება, CI/CD.18

მისცა ხმა 22 მომხმარებელმა. 9 მომხმარებელმა თავი შეიკავა.

წყარო: www.habr.com