पपेट एक कॉन्फ़िगरेशन प्रबंधन प्रणाली है। इसका उपयोग मेजबानों को वांछित स्थिति में लाने और इस स्थिति को बनाए रखने के लिए किया जाता है।

मैं पपेट के साथ पांच साल से अधिक समय से काम कर रहा हूं। यह पाठ मूल रूप से आधिकारिक दस्तावेज़ीकरण से मुख्य बिंदुओं का अनुवादित और पुन: व्यवस्थित संकलन है, जो शुरुआती लोगों को कठपुतली के सार को जल्दी से समझने की अनुमति देगा।

मूलभूत जानकारी

पपेट का ऑपरेटिंग सिस्टम क्लाइंट-सर्वर है, हालांकि यह सीमित कार्यक्षमता के साथ सर्वर रहित ऑपरेशन का भी समर्थन करता है।

ऑपरेशन के एक पुल मॉडल का उपयोग किया जाता है: डिफ़ॉल्ट रूप से, हर आधे घंटे में एक बार, क्लाइंट कॉन्फ़िगरेशन के लिए सर्वर से संपर्क करते हैं और इसे लागू करते हैं। यदि आपने Ansible के साथ काम किया है, तो वे एक अलग पुश मॉडल का उपयोग करते हैं: व्यवस्थापक कॉन्फ़िगरेशन लागू करने की प्रक्रिया शुरू करता है, क्लाइंट स्वयं कुछ भी लागू नहीं करेंगे।

नेटवर्क संचार के दौरान, दो-तरफ़ा टीएलएस एन्क्रिप्शन का उपयोग किया जाता है: सर्वर और क्लाइंट के पास अपनी निजी कुंजी और संबंधित प्रमाणपत्र होते हैं। आमतौर पर सर्वर क्लाइंट के लिए प्रमाणपत्र जारी करता है, लेकिन सिद्धांत रूप में बाहरी सीए का उपयोग करना संभव है।

घोषणापत्रों का परिचय

कठपुतली शब्दावली में कठपुतली सर्वर को जोड़ना नोड्स (नोड्स)। नोड्स के लिए कॉन्फ़िगरेशन लिखा गया है घोषणापत्रों में एक विशेष प्रोग्रामिंग भाषा में - पपेट डीएसएल।

पपेट डीएसएल एक घोषणात्मक भाषा है। यह व्यक्तिगत संसाधनों की घोषणाओं के रूप में नोड की वांछित स्थिति का वर्णन करता है, उदाहरण के लिए:

फ़ाइल मौजूद है और इसमें विशिष्ट सामग्री है.
पैकेज स्थापित है.
सेवा शुरू हो गई है.

संसाधनों को आपस में जोड़ा जा सकता है:

निर्भरताएँ हैं, वे संसाधनों के उपयोग के क्रम को प्रभावित करती हैं।
उदाहरण के लिए, "पहले पैकेज स्थापित करें, फिर कॉन्फ़िगरेशन फ़ाइल संपादित करें, फिर सेवा शुरू करें।"
सूचनाएं हैं - यदि कोई संसाधन बदल गया है, तो यह उसके सदस्यता प्राप्त संसाधनों को सूचनाएं भेजता है।
उदाहरण के लिए, यदि कॉन्फ़िगरेशन फ़ाइल बदलती है, तो आप स्वचालित रूप से सेवा को पुनरारंभ कर सकते हैं।

इसके अतिरिक्त, पपेट डीएसएल में फ़ंक्शन और चर, साथ ही सशर्त विवरण और चयनकर्ता भी हैं। विभिन्न टेम्प्लेटिंग तंत्र भी समर्थित हैं - ईपीपी और ईआरबी।

पपेट रूबी में लिखा गया है, इसलिए कई निर्माण और शर्तें वहीं से ली गई हैं। रूबी आपको पपेट का विस्तार करने की अनुमति देती है - जटिल तर्क, नए प्रकार के संसाधन, फ़ंक्शन जोड़ें।

जब पपेट चल रहा होता है, तो सर्वर पर प्रत्येक विशिष्ट नोड के मैनिफ़ेस्ट को एक निर्देशिका में संकलित किया जाता है। निर्देशिका फ़ंक्शन, चर और सशर्त बयानों के विस्तार के मूल्य की गणना के बाद संसाधनों और उनके संबंधों की एक सूची है।

सिंटेक्स और कोडस्टाइल

यहां आधिकारिक दस्तावेज़ के अनुभाग दिए गए हैं जो आपको सिंटैक्स को समझने में मदद करेंगे यदि दिए गए उदाहरण पर्याप्त नहीं हैं:

मेनिफेस्ट कैसा दिखता है इसका एक उदाहरण यहां दिया गया है:

# Комментарии пишутся, как и много где, после решётки.
#
# Описание конфигурации ноды начинается с ключевого слова 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 }).
मापदंडों पर तीर समान स्तर पर होने चाहिए।
उनके सामने संसाधन संबंध तीर लिखे हुए हैं।

पैपेटसर्वर पर फ़ाइलों का स्थान

आगे की व्याख्या के लिए, मैं "रूट डायरेक्टरी" की अवधारणा का परिचय दूंगा। रूट निर्देशिका वह निर्देशिका है जिसमें एक विशिष्ट नोड के लिए पपेट कॉन्फ़िगरेशन शामिल है।

रूट निर्देशिका पपेट के संस्करण और उपयोग किए गए वातावरण के आधार पर भिन्न होती है। वातावरण कॉन्फ़िगरेशन के स्वतंत्र सेट हैं जो अलग-अलग निर्देशिकाओं में संग्रहीत होते हैं। आमतौर पर गिट के साथ संयोजन में उपयोग किया जाता है, जिस स्थिति में वातावरण गिट शाखाओं से बनाया जाता है। तदनुसार, प्रत्येक नोड किसी न किसी वातावरण में स्थित होता है। इसे नोड पर या ईएनसी में ही कॉन्फ़िगर किया जा सकता है, जिसके बारे में मैं अगले लेख में बात करूंगा।

तीसरे संस्करण ("पुरानी कठपुतली") में आधार निर्देशिका थी /etc/puppet. परिवेश का उपयोग वैकल्पिक है - उदाहरण के लिए, हम पुराने पपेट के साथ उनका उपयोग नहीं करते हैं। यदि वातावरण का उपयोग किया जाता है, तो उन्हें आमतौर पर संग्रहीत किया जाता है /etc/puppet/environments, मूल निर्देशिका पर्यावरण निर्देशिका होगी। यदि परिवेश का उपयोग नहीं किया जाता है, तो मूल निर्देशिका आधार निर्देशिका होगी।
चौथे संस्करण ("नया कठपुतली") से शुरू होकर, वातावरण का उपयोग अनिवार्य हो गया, और आधार निर्देशिका को स्थानांतरित कर दिया गया /etc/puppetlabs/code. तदनुसार, वातावरण संग्रहीत किया जाता है /etc/puppetlabs/code/environments, रूट निर्देशिका पर्यावरण निर्देशिका है।

रूट डायरेक्टरी में एक उपनिर्देशिका होनी चाहिए manifests, जिसमें नोड्स का वर्णन करने वाले एक या अधिक मैनिफ़ेस्ट शामिल हैं। इसके अलावा, एक उपनिर्देशिका भी होनी चाहिए modules, जिसमें मॉड्यूल शामिल हैं। मैं आपको थोड़ी देर बाद बताऊंगा कि मॉड्यूल क्या हैं। इसके अलावा, पुराने पपेट में एक उपनिर्देशिका भी हो सकती है files, जिसमें विभिन्न फ़ाइलें शामिल हैं जिन्हें हम नोड्स में कॉपी करते हैं। नए पपेट में, सभी फ़ाइलें मॉड्यूल में रखी गई हैं।

मेनिफेस्ट फ़ाइलों में एक्सटेंशन होता है .pp.

युद्ध के कुछ उदाहरण

उस पर नोड और संसाधन का विवरण

नोड पर server1.testdomain एक फ़ाइल बनानी होगी /etc/issue सामग्री के साथ Debian GNU/Linux n l. फ़ाइल का स्वामित्व उपयोगकर्ता और समूह के पास होना चाहिए root, पहुँच अधिकार होना चाहिए 644.

हम एक घोषणापत्र लिखते हैं:

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

एक नोड पर संसाधनों के बीच संबंध

नोड पर server2.testdomain nginx को पहले से तैयार कॉन्फ़िगरेशन के साथ काम करते हुए चलना चाहिए।

आइए समस्या को विघटित करें:

पैकेज को स्थापित करने की आवश्यकता है nginx.
यह आवश्यक है कि कॉन्फ़िगरेशन फ़ाइलों को सर्वर से कॉपी किया जाए।
सेवा चालू होनी चाहिए nginx.
यदि कॉन्फ़िगरेशन अद्यतन किया गया है, तो सेवा को पुनरारंभ करना होगा।

हम एक घोषणापत्र लिखते हैं:

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

इसे काम करने के लिए, आपको कठपुतली सर्वर पर लगभग निम्नलिखित फ़ाइल स्थान की आवश्यकता है:

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

संसाधन प्रकार

समर्थित संसाधन प्रकारों की पूरी सूची यहां पाई जा सकती है दस्तावेज़ीकरण में, यहां मैं पांच बुनियादी प्रकारों का वर्णन करूंगा, जो मेरे अभ्यास में अधिकांश समस्याओं को हल करने के लिए पर्याप्त हैं।

पट्टिका

फ़ाइलों, निर्देशिकाओं, सिम्लिंक, उनकी सामग्री और पहुंच अधिकारों का प्रबंधन करता है।

विकल्प:

संसाधन का नाम - फ़ाइल का पथ (वैकल्पिक)
पथ - फ़ाइल का पथ (यदि यह नाम में निर्दिष्ट नहीं है)
सुनिश्चित - फाइल का प्रकार:
- absent - एक फ़ाइल हटाएँ
- present - किसी भी प्रकार की फ़ाइल होनी चाहिए (यदि कोई फ़ाइल नहीं है, तो एक नियमित फ़ाइल बनाई जाएगी)
- file - नियमित फ़ाइल
- directory - निर्देशिका
- link - सिम्लिंक
सामग्री - फ़ाइल सामग्री (केवल नियमित फ़ाइलों के लिए उपयुक्त, एक साथ उपयोग नहीं की जा सकती स्रोत या लक्ष्य)
स्रोत - उस पथ का एक लिंक जहां से आप फ़ाइल की सामग्री की प्रतिलिपि बनाना चाहते हैं (साथ में उपयोग नहीं किया जा सकता है)। सामग्री या लक्ष्य). किसी योजना के साथ यूआरआई के रूप में निर्दिष्ट किया जा सकता है puppet: (फिर कठपुतली सर्वर से फ़ाइलों का उपयोग किया जाएगा), और योजना के साथ http: (मुझे आशा है कि यह स्पष्ट है कि इस मामले में क्या होगा), और आरेख के साथ भी file: या स्कीमा के बिना एक पूर्ण पथ के रूप में (फिर नोड पर स्थानीय एफएस से फ़ाइल का उपयोग किया जाएगा)
लक्ष्य - जहां सिम्लिंक को इंगित करना चाहिए (साथ में उपयोग नहीं किया जा सकता है)। सामग्री या स्रोत)
मालिक - वह उपयोगकर्ता जिसके पास फ़ाइल होनी चाहिए
समूह - वह समूह जिससे फ़ाइल संबंधित होनी चाहिए
मोड - फ़ाइल अनुमतियाँ (एक स्ट्रिंग के रूप में)
फिर से इकट्ठा करना - पुनरावर्ती निर्देशिका प्रसंस्करण सक्षम करता है
शुद्ध करना - उन फ़ाइलों को हटाने में सक्षम बनाता है जिनका वर्णन पपेट में नहीं किया गया है
मजबूर - उन निर्देशिकाओं को हटाने में सक्षम बनाता है जिनका वर्णन पपेट में नहीं किया गया है

पैकेज

पैकेज स्थापित करता है और हटाता है। सूचनाओं को संभालने में सक्षम - यदि पैरामीटर निर्दिष्ट है तो पैकेज को पुनः स्थापित करता है पुनः स्थापित करें_पर_ताज़ा करें.

विकल्प:

संसाधन का नाम - पैकेज का नाम (वैकल्पिक)
नाम - पैकेज का नाम (यदि नाम में निर्दिष्ट नहीं है)
प्रदाता - उपयोग करने के लिए पैकेज मैनेजर
सुनिश्चित - पैकेज की वांछित स्थिति:
- present, installed - कोई भी संस्करण स्थापित
- latest - नवीनतम संस्करण स्थापित
- absent -हटाया गया (apt-get remove)
- purged - कॉन्फ़िगरेशन फ़ाइलों के साथ हटा दिया गया (apt-get purge)
- held - पैकेज संस्करण लॉक है (apt-mark hold)
- любая другая строка - निर्दिष्ट संस्करण स्थापित है
पुनः स्थापित करें_पर_ताज़ा करें - अगर true, तो अधिसूचना प्राप्त होने पर पैकेज पुनः स्थापित किया जाएगा। स्रोत-आधारित वितरण के लिए उपयोगी, जहां बिल्ड पैरामीटर बदलते समय पैकेजों का पुनर्निर्माण आवश्यक हो सकता है। गलती करना false.

सेवा

सेवाओं का प्रबंधन करता है. सूचनाओं को संसाधित करने में सक्षम - सेवा को पुनरारंभ करता है।

विकल्प:

संसाधन का नाम - प्रबंधित की जाने वाली सेवा (वैकल्पिक)
नाम - वह सेवा जिसे प्रबंधित करने की आवश्यकता है (यदि नाम में निर्दिष्ट नहीं है)
सुनिश्चित - सेवा की वांछित स्थिति:
- running - लॉन्च किया गया
- stopped - रोका हुआ
सक्षम - सेवा शुरू करने की क्षमता को नियंत्रित करता है:
- true - ऑटोरन सक्षम है (systemctl enable)
- mask - प्रच्छन्न (systemctl mask)
- false - ऑटोरन अक्षम है (systemctl disable)
पुनः प्रारंभ - सेवा को पुनः आरंभ करने का आदेश
हैसियत - सेवा की स्थिति जांचने के लिए आदेश
पुनरारंभ हो गया है - इंगित करें कि क्या सेवा इनिटस्क्रिप्ट पुनरारंभ करने का समर्थन करती है। अगर false और पैरामीटर निर्दिष्ट है पुनः प्रारंभ - इस पैरामीटर का मान उपयोग किया जाता है। अगर false और पैरामीटर पुनः प्रारंभ निर्दिष्ट नहीं - सेवा बंद कर दी गई है और पुनरारंभ करना शुरू कर दिया गया है (लेकिन सिस्टमडी कमांड का उपयोग करता है systemctl restart).
hasstatus - इंगित करें कि क्या सेवा इनिटस्क्रिप्ट कमांड का समर्थन करती है status। अगर false, तो पैरामीटर मान का उपयोग किया जाता है हैसियत. गलती करना true.

कार्यकारी

बाह्य आदेश चलाता है. यदि आप पैरामीटर निर्दिष्ट नहीं करते हैं बनाता है, केवल, जब तक या केवल ताज़ा करें, हर बार पपेट चलाने पर कमांड चलाया जाएगा। सूचनाओं को संसाधित करने में सक्षम - एक कमांड चलाता है।

विकल्प:

संसाधन का नाम - निष्पादित किया जाने वाला आदेश (वैकल्पिक)
आदेश - निष्पादित किया जाने वाला आदेश (यदि यह नाम में निर्दिष्ट नहीं है)
पथ - पथ जिसमें निष्पादन योग्य फ़ाइल को देखना है
केवल - यदि इस पैरामीटर में निर्दिष्ट कमांड शून्य रिटर्न कोड के साथ पूरा होता है, तो मुख्य कमांड निष्पादित किया जाएगा
जब तक - यदि इस पैरामीटर में निर्दिष्ट कमांड गैर-शून्य रिटर्न कोड के साथ पूरा हो गया है, तो मुख्य कमांड निष्पादित किया जाएगा
बनाता है - यदि इस पैरामीटर में निर्दिष्ट फ़ाइल मौजूद नहीं है, तो मुख्य कमांड निष्पादित किया जाएगा
केवल ताज़ा करें - अगर true, तो कमांड केवल तभी चलाया जाएगा जब इस निष्पादन को अन्य संसाधनों से अधिसूचना प्राप्त होगी
CWD - वह निर्देशिका जिससे कमांड चलाना है
उपयोगकर्ता - उपयोगकर्ता जिससे कमांड चलाना है
प्रदाता - कमांड कैसे चलाएं:
- POSIX - एक चाइल्ड प्रक्रिया बस बनाई गई है, निर्दिष्ट करना सुनिश्चित करें पथ
- खोल - कमांड शेल में लॉन्च किया गया है /bin/sh, निर्दिष्ट नहीं किया जा सकता पथ, आप ग्लोबिंग, पाइप और अन्य शेल सुविधाओं का उपयोग कर सकते हैं। यदि कोई विशेष वर्ण हैं तो आमतौर पर स्वचालित रूप से पता लगाया जाता है (|, ;, &&, || आदि)।

क्रॉन

क्रोनजॉब्स को नियंत्रित करता है।

विकल्प:

संसाधन का नाम - बस किसी प्रकार का पहचानकर्ता
सुनिश्चित - क्राउनजॉब स्थिति:
- present - यदि मौजूद नहीं है तो बनाएं
- absent - यदि मौजूद है तो हटा दें
आदेश - कौन सा आदेश चलाना है
वातावरण - किस वातावरण में कमांड चलाना है (पर्यावरण चर की सूची और उनके मूल्यों के माध्यम से)। =)
उपयोगकर्ता - किस उपयोगकर्ता से कमांड चलाना है
मिनट, घंटा, काम करने के दिन, माह, माह का दिन - क्रॉन कब चलाना है। यदि इनमें से कोई भी विशेषता निर्दिष्ट नहीं है, तो क्रोंटैब में इसका मान होगा *.

कठपुतली 6.0 में क्रॉन मानो बॉक्स से निकाला गया कठपुतली सर्वर में, इसलिए सामान्य साइट पर कोई दस्तावेज़ नहीं है। लेकिन वह बॉक्स में है कठपुतली-एजेंट में, इसलिए इसे अलग से स्थापित करने की कोई आवश्यकता नहीं है। आप इसके लिए दस्तावेज़ देख सकते हैं पपेट के पांचवें संस्करण के दस्तावेज़ मेंया GitHub पर.

सामान्य तौर पर संसाधनों के बारे में

संसाधन विशिष्टता के लिए आवश्यकताएँ

हमारे सामने आने वाली सबसे आम गलती है डुप्लिकेट घोषणा. यह त्रुटि तब होती है जब निर्देशिका में समान नाम वाले एक ही प्रकार के दो या दो से अधिक संसाधन दिखाई देते हैं।

इसलिए, मैं फिर से लिखूंगा: एक ही नोड के लिए मैनिफ़ेस्ट में एक ही शीर्षक के साथ एक ही प्रकार के संसाधन नहीं होने चाहिए!

कभी-कभी एक ही नाम से, लेकिन अलग-अलग पैकेज प्रबंधकों के साथ पैकेज स्थापित करने की आवश्यकता होती है। इस मामले में, आपको पैरामीटर का उपयोग करने की आवश्यकता है nameत्रुटि से बचने के लिए:

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

अन्य संसाधन प्रकारों में दोहराव से बचने में मदद के लिए समान विकल्प हैं - name у सेवा, command у कार्यकारी, और इसी तरह।

मेटापैरामीटर

प्रत्येक संसाधन प्रकार के कुछ विशेष पैरामीटर होते हैं, चाहे उसकी प्रकृति कुछ भी हो।

मेटा पैरामीटर्स की पूरी सूची कठपुतली दस्तावेज़ में.

संक्षिप्त सूची:

की आवश्यकता होती है — यह पैरामीटर इंगित करता है कि यह संसाधन किन संसाधनों पर निर्भर करता है।
से पहले - यह पैरामीटर निर्दिष्ट करता है कि कौन से संसाधन इस संसाधन पर निर्भर हैं।
सदस्यता के - यह पैरामीटर निर्दिष्ट करता है कि यह संसाधन किन संसाधनों से सूचनाएं प्राप्त करता है।
सूचित करें - यह पैरामीटर निर्दिष्ट करता है कि कौन से संसाधन इस संसाधन से सूचनाएं प्राप्त करते हैं।

सूचीबद्ध सभी मेटापैरामीटर या तो एक एकल संसाधन लिंक या वर्गाकार कोष्ठक में लिंक की एक सरणी को स्वीकार करते हैं।

संसाधनों से लिंक

संसाधन लिंक केवल संसाधन का उल्लेख है। इनका उपयोग मुख्य रूप से निर्भरता को इंगित करने के लिए किया जाता है। किसी गैर-मौजूद संसाधन को संदर्भित करने से संकलन त्रुटि उत्पन्न होगी।

लिंक का सिंटैक्स इस प्रकार है: बड़े अक्षर के साथ संसाधन प्रकार (यदि प्रकार के नाम में डबल कोलन हैं, तो कोलन के बीच नाम के प्रत्येक भाग को बड़े अक्षरों में लिखा जाता है), फिर वर्ग कोष्ठक में संसाधन का नाम (नाम का मामला) बदलना मत!)। कोई रिक्त स्थान नहीं होना चाहिए; प्रकार के नाम के तुरंत बाद वर्गाकार कोष्ठक लिखे जाते हैं।

उदाहरण:

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

निर्भरताएँ और सूचनाएं

दस्तावेज़ीकरण यहाँ.

जैसा कि पहले कहा गया है, संसाधनों के बीच सरल निर्भरताएँ परिवर्तनशील होती हैं। वैसे, निर्भरताएँ जोड़ते समय सावधान रहें - आप चक्रीय निर्भरताएँ बना सकते हैं, जो संकलन त्रुटि का कारण बनेगी।

निर्भरताओं के विपरीत, सूचनाएं सकर्मक नहीं होती हैं। अधिसूचनाओं के लिए निम्नलिखित नियम लागू होते हैं:

यदि संसाधन को कोई सूचना प्राप्त होती है, तो उसे अद्यतन किया जाता है। अद्यतन क्रियाएँ संसाधन प्रकार पर निर्भर करती हैं - कार्यकारी आदेश चलाता है, सेवा सेवा पुनः आरंभ करता है, पैकेज पैकेज को पुनः स्थापित करता है। यदि संसाधन में अद्यतन कार्रवाई परिभाषित नहीं है, तो कुछ नहीं होता है।
पपेट के एक रन के दौरान, संसाधन को एक से अधिक बार अपडेट नहीं किया जाता है। यह संभव है क्योंकि सूचनाओं में निर्भरताएँ शामिल होती हैं और निर्भरता ग्राफ़ में चक्र शामिल नहीं होते हैं।
यदि पपेट किसी संसाधन की स्थिति बदलता है, तो संसाधन उससे जुड़े सभी संसाधनों को सूचनाएं भेजता है।
यदि कोई संसाधन अद्यतन किया जाता है, तो यह उससे जुड़े सभी संसाधनों को सूचनाएं भेजता है।

अनिर्दिष्ट मापदंडों को संभालना

एक नियम के रूप में, यदि कुछ संसाधन पैरामीटर में डिफ़ॉल्ट मान नहीं है और यह पैरामीटर मैनिफ़ेस्ट में निर्दिष्ट नहीं है, तो पपेट नोड पर संबंधित संसाधन के लिए इस संपत्ति को नहीं बदलेगा। उदाहरण के लिए, यदि किसी प्रकार का संसाधन पट्टिका पैरामीटर निर्दिष्ट नहीं है owner, तो पपेट संबंधित फ़ाइल के स्वामी को नहीं बदलेगा।

कक्षाओं, चरों और परिभाषाओं का परिचय

मान लीजिए कि हमारे पास कई नोड हैं जिनमें कॉन्फ़िगरेशन का एक ही हिस्सा है, लेकिन अंतर भी हैं - अन्यथा हम इसे एक ब्लॉक में वर्णित कर सकते हैं node {}. बेशक, आप बस कॉन्फ़िगरेशन के समान भागों की प्रतिलिपि बना सकते हैं, लेकिन सामान्य तौर पर यह एक खराब समाधान है - कॉन्फ़िगरेशन बढ़ता है, और यदि आप कॉन्फ़िगरेशन के सामान्य भाग को बदलते हैं, तो आपको एक ही चीज़ को कई स्थानों पर संपादित करना होगा। साथ ही, गलती करना आसान है, और सामान्य तौर पर, DRY (खुद को न दोहराएं) सिद्धांत का आविष्कार एक कारण से किया गया था।

इस समस्या को हल करने के लिए ऐसा डिज़ाइन मौजूद है वर्ग.

Классы

वर्ग पॉपपेट कोड का एक नामित ब्लॉक है। कोड का पुन: उपयोग करने के लिए कक्षाओं की आवश्यकता होती है।

सबसे पहले वर्ग का वर्णन करना आवश्यक है। विवरण स्वयं कहीं भी कोई संसाधन नहीं जोड़ता है। वर्ग का वर्णन मेनिफेस्टों में किया गया है:

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

इसके बाद कक्षा का उपयोग किया जा सकता है:

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

पिछले कार्य से एक उदाहरण - आइए nginx की स्थापना और कॉन्फ़िगरेशन को एक वर्ग में ले जाएँ:

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

node 'server2.testdomain' {
    include nginx_example
}

चर

पिछले उदाहरण की कक्षा बिल्कुल भी लचीली नहीं है क्योंकि यह हमेशा समान nginx कॉन्फ़िगरेशन लाती है। आइए कॉन्फ़िगरेशन वेरिएबल के लिए पथ बनाएं, फिर इस क्लास का उपयोग किसी भी कॉन्फ़िगरेशन के साथ nginx को स्थापित करने के लिए किया जा सकता है।

यह किया जा सकता है चर का उपयोग करना.

ध्यान दें: कठपुतली में चर अपरिवर्तनीय हैं!

इसके अलावा, एक वेरिएबल को केवल घोषित होने के बाद ही एक्सेस किया जा सकता है, अन्यथा वेरिएबल का मान नहीं होगा undef.

चर के साथ काम करने का उदाहरण:

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

कठपुतली के पास है नामस्थान, और चर, तदनुसार, हैं दृश्यता का क्षेत्र: एक ही नाम वाले एक वेरिएबल को विभिन्न नामस्थानों में परिभाषित किया जा सकता है। किसी वेरिएबल के मान को हल करते समय, वेरिएबल को वर्तमान नेमस्पेस में खोजा जाता है, फिर संलग्न नेमस्पेस में, और इसी तरह।

नामस्थान उदाहरण:

वैश्विक - वर्ग या नोड विवरण के बाहर के चर वहां जाते हैं;
नोड विवरण में नोड नामस्थान;
वर्ग विवरण में वर्ग नामस्थान।

किसी वेरिएबल तक पहुँचते समय अस्पष्टता से बचने के लिए, आप वेरिएबल नाम में नेमस्पेस निर्दिष्ट कर सकते हैं:

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

आइए सहमत हैं कि nginx कॉन्फ़िगरेशन का पथ वेरिएबल में निहित है $nginx_conf_source. तब कक्षा इस तरह दिखेगी:

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

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

हालाँकि, दिया गया उदाहरण ख़राब है क्योंकि कुछ "गुप्त ज्ञान" है कि कक्षा के अंदर कहीं न कहीं अमुक नाम वाले वेरिएबल का उपयोग किया जाता है। इस ज्ञान को सामान्य बनाना कहीं अधिक सही है - कक्षाओं में पैरामीटर हो सकते हैं।

कक्षा पैरामीटर क्लास नेमस्पेस में वेरिएबल होते हैं, वे क्लास हेडर में निर्दिष्ट होते हैं और क्लास बॉडी में नियमित वेरिएबल्स की तरह उपयोग किए जा सकते हैं। मेनिफेस्ट में क्लास का उपयोग करते समय पैरामीटर मान निर्दिष्ट किए जाते हैं।

पैरामीटर को डिफ़ॉल्ट मान पर सेट किया जा सकता है। यदि किसी पैरामीटर में डिफ़ॉल्ट मान नहीं है और उपयोग किए जाने पर मान सेट नहीं किया जाता है, तो यह संकलन त्रुटि का कारण बनेगा।

आइए ऊपर दिए गए उदाहरण से क्लास को पैरामीटराइज़ करें और दो पैरामीटर जोड़ें: पहला, आवश्यक, कॉन्फ़िगरेशन का पथ है, और दूसरा, वैकल्पिक, nginx के साथ पैकेज का नाम है (उदाहरण के लिए, डेबियन में, पैकेज हैं nginx, nginx-light, nginx-full).

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

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

पपेट में वेरिएबल टाइप किए जाते हैं। खाओ कई डेटा प्रकार. डेटा प्रकार का उपयोग आम तौर पर कक्षाओं और परिभाषाओं में पारित पैरामीटर मानों को मान्य करने के लिए किया जाता है। यदि पारित पैरामीटर निर्दिष्ट प्रकार से मेल नहीं खाता है, तो एक संकलन त्रुटि उत्पन्न होगी।

प्रकार पैरामीटर नाम से ठीक पहले लिखा जाता है:

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

कक्षाएं: वर्गनाम बनाम वर्ग शामिल करें {'वर्गनाम':}

प्रत्येक वर्ग एक प्रकार का संसाधन है कक्षा. किसी भी अन्य प्रकार के संसाधन की तरह, एक ही नोड पर एक ही वर्ग के दो उदाहरण नहीं हो सकते।

यदि आप किसी क्लास को एक ही नोड में दो बार जोड़ने का प्रयास करते हैं class { 'classname':} (कोई अंतर नहीं, भिन्न या समान मापदंडों के साथ), एक संकलन त्रुटि होगी। लेकिन यदि आप संसाधन शैली में किसी वर्ग का उपयोग करते हैं, तो आप तुरंत इसके सभी मापदंडों को मेनिफेस्ट में स्पष्ट रूप से सेट कर सकते हैं।

हालाँकि, यदि आप उपयोग करते हैं include, तो कक्षा को जितनी बार चाहें उतनी बार जोड़ा जा सकता है। तथ्य यह है कि include एक इडेम्पोटेंट फ़ंक्शन है जो जांचता है कि निर्देशिका में कोई वर्ग जोड़ा गया है या नहीं। यदि क्लास निर्देशिका में नहीं है, तो यह इसे जोड़ता है, और यदि यह पहले से मौजूद है, तो यह कुछ नहीं करता है। लेकिन उपयोग के मामले में include आप वर्ग घोषणा के दौरान वर्ग पैरामीटर सेट नहीं कर सकते - सभी आवश्यक पैरामीटर बाहरी डेटा स्रोत - हिएरा या ईएनसी में सेट किए जाने चाहिए। हम उनके बारे में अगले लेख में बात करेंगे.

को परिभाषित करता है

जैसा कि पिछले ब्लॉक में कहा गया था, एक ही वर्ग एक नोड पर एक से अधिक बार मौजूद नहीं हो सकता है। हालाँकि, कुछ मामलों में आपको एक ही नोड पर विभिन्न मापदंडों के साथ कोड के एक ही ब्लॉक का उपयोग करने में सक्षम होने की आवश्यकता होती है। दूसरे शब्दों में, स्वयं के एक संसाधन प्रकार की आवश्यकता होती है।

उदाहरण के लिए, PHP मॉड्यूल को स्थापित करने के लिए, हम Avito में निम्नलिखित कार्य करते हैं:

इस मॉड्यूल के साथ पैकेज स्थापित करें।
आइए इस मॉड्यूल के लिए एक कॉन्फ़िगरेशन फ़ाइल बनाएं।
हम php-fpm के लिए कॉन्फ़िगरेशन के लिए एक सिम्लिंक बनाते हैं।
हम php cli के लिए कॉन्फ़िगरेशन के लिए एक सिम्लिंक बनाते हैं।

ऐसे मामलों में, एक डिज़ाइन जैसे परिभाषित करना (परिभाषित करें, परिभाषित प्रकार, परिभाषित संसाधन प्रकार)। डिफाइन एक वर्ग के समान है, लेकिन इसमें अंतर हैं: पहला, प्रत्येक डिफाइन एक संसाधन प्रकार है, संसाधन नहीं; दूसरे, प्रत्येक परिभाषा में एक अंतर्निहित पैरामीटर होता है $title, घोषित होने पर संसाधन का नाम कहां जाता है। जैसे वर्गों के मामले में, पहले एक परिभाषा का वर्णन किया जाना चाहिए, जिसके बाद इसका उपयोग किया जा सकता है।

PHP के लिए मॉड्यूल के साथ एक सरलीकृत उदाहरण:

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

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

डुप्लिकेट घोषणा त्रुटि को पकड़ने का सबसे आसान तरीका डिफाइन में है। ऐसा तब होता है जब परिभाषा में स्थिर नाम वाला कोई संसाधन होता है, और किसी नोड पर इस परिभाषा के दो या दो से अधिक उदाहरण होते हैं।

इससे खुद को सुरक्षित रखना आसान है: परिभाषा के अंदर सभी संसाधनों के आधार पर एक नाम होना चाहिए $title. एक विकल्प संसाधनों का निरर्थक जोड़ है; सबसे सरल मामले में, यह परिभाषा के सभी उदाहरणों के लिए सामान्य संसाधनों को एक अलग वर्ग में स्थानांतरित करने और इस वर्ग को परिभाषा में शामिल करने के लिए पर्याप्त है - फ़ंक्शन include निष्क्रिय

संसाधनों को जोड़ते समय निष्क्रियता प्राप्त करने के अन्य तरीके हैं, अर्थात् फ़ंक्शंस का उपयोग करना defined и ensure_resources, लेकिन मैं आपको इसके बारे में अगले एपिसोड में बताऊंगा।

वर्गों और परिभाषाओं के लिए निर्भरताएँ और सूचनाएं

निर्भरता और सूचनाओं को संभालने के लिए कक्षाएं और परिभाषाएं निम्नलिखित नियम जोड़ती हैं:

किसी वर्ग/परिभाषा पर निर्भरता वर्ग/परिभाषा के सभी संसाधनों पर निर्भरता जोड़ती है;
एक वर्ग/परिभाषित निर्भरता सभी वर्ग/परिभाषित संसाधनों पर निर्भरताएँ जोड़ती है;
वर्ग/परिभाषित अधिसूचना वर्ग/परिभाषित के सभी संसाधनों को सूचित करती है;
क्लास/डिफाइन सब्सक्रिप्शन क्लास/डिफाइन के सभी संसाधनों की सदस्यता लेता है।

सशर्त बयान और चयनकर्ता

दस्तावेज़ीकरण यहाँ.

if

यहाँ सब कुछ सरल है:

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

जब तक

जब तक कि इसका उलटा न हो: यदि अभिव्यक्ति गलत है तो कोड का ब्लॉक निष्पादित किया जाएगा।

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

मामला

यहां कुछ भी जटिल नहीं है. आप मान के रूप में नियमित मान (स्ट्रिंग्स, संख्याएं, आदि), नियमित अभिव्यक्ति और डेटा प्रकार का उपयोग कर सकते हैं।

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

चयनकर्ताओं

चयनकर्ता एक भाषा निर्माण के समान है case, लेकिन कोड के एक ब्लॉक को निष्पादित करने के बजाय, यह एक मान लौटाता है।

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

मॉड्यूल

जब कॉन्फ़िगरेशन छोटा होता है, तो इसे आसानी से एक मैनिफ़ेस्ट में रखा जा सकता है। लेकिन हम जितने अधिक कॉन्फ़िगरेशन का वर्णन करते हैं, मेनिफेस्ट में उतने ही अधिक वर्ग और नोड होते हैं, यह बढ़ता है, और इसके साथ काम करना असुविधाजनक हो जाता है।

इसके अलावा, कोड के पुन: उपयोग की समस्या भी है - जब सभी कोड एक मैनिफ़ेस्ट में होते हैं, तो इस कोड को दूसरों के साथ साझा करना मुश्किल होता है। इन दो समस्याओं को हल करने के लिए, पपेट के पास मॉड्यूल नामक एक इकाई है।

मॉड्यूल - ये एक अलग निर्देशिका में रखे गए वर्गों, परिभाषाओं और अन्य कठपुतली संस्थाओं के सेट हैं। दूसरे शब्दों में, एक मॉड्यूल कठपुतली तर्क का एक स्वतंत्र टुकड़ा है। उदाहरण के लिए, nginx के साथ काम करने के लिए एक मॉड्यूल हो सकता है, और इसमें nginx के साथ काम करने के लिए क्या और केवल क्या आवश्यक है, या PHP के साथ काम करने के लिए एक मॉड्यूल हो सकता है, इत्यादि।

मॉड्यूल संस्करणित हैं, और एक दूसरे पर मॉड्यूल की निर्भरता भी समर्थित है। मॉड्यूल का एक खुला भंडार है - कठपुतली फोर्ज.

कठपुतली सर्वर पर, मॉड्यूल रूट निर्देशिका के मॉड्यूल उपनिर्देशिका में स्थित होते हैं। प्रत्येक मॉड्यूल के अंदर एक मानक निर्देशिका योजना होती है - मैनिफ़ेस्ट, फ़ाइलें, टेम्पलेट, लिब, इत्यादि।

एक मॉड्यूल में फ़ाइल संरचना

मॉड्यूल की जड़ में वर्णनात्मक नामों के साथ निम्नलिखित निर्देशिकाएं हो सकती हैं:

manifests - इसमें घोषणापत्र शामिल हैं
files - इसमें फ़ाइलें हैं
templates - इसमें टेम्प्लेट शामिल हैं
lib - इसमें रूबी कोड है

यह निर्देशिकाओं और फ़ाइलों की पूरी सूची नहीं है, लेकिन अभी इस लेख के लिए यह पर्याप्त है।

मॉड्यूल में संसाधनों के नाम और फ़ाइलों के नाम

दस्तावेज़ीकरण यहाँ.

किसी मॉड्यूल में संसाधनों (वर्गों, परिभाषाओं) को आपकी इच्छानुसार नाम नहीं दिया जा सकता। इसके अलावा, संसाधन के नाम और फ़ाइल के नाम के बीच सीधा पत्राचार होता है जिसमें पपेट उस संसाधन का विवरण ढूंढेगा। यदि आप नामकरण नियमों का उल्लंघन करते हैं, तो पपेट को संसाधन विवरण नहीं मिलेगा, और आपको एक संकलन त्रुटि मिलेगी।

नियम सरल हैं:

मॉड्यूल में सभी संसाधन मॉड्यूल नेमस्पेस में होने चाहिए। यदि मॉड्यूल कहा जाता है foo, तो इसमें सभी संसाधनों का नाम दिया जाना चाहिए foo::<anything>या केवल foo.
मॉड्यूल के नाम वाला संसाधन फ़ाइल में होना चाहिए init.pp.
अन्य संसाधनों के लिए, फ़ाइल नामकरण योजना इस प्रकार है:
- मॉड्यूल नाम वाला उपसर्ग हटा दिया गया है
- सभी डबल कोलन, यदि कोई हों, स्लैश से बदल दिए जाते हैं
- एक्सटेंशन जोड़ा गया है .pp

मैं एक उदाहरण के साथ प्रदर्शित करूंगा. मान लीजिए कि मैं एक मॉड्यूल लिख रहा हूं nginx. इसमें निम्नलिखित संसाधन शामिल हैं:

वर्ग nginx प्रकट में वर्णित है init.pp;
वर्ग nginx::service प्रकट में वर्णित है service.pp;
परिभाषित करना nginx::server प्रकट में वर्णित है server.pp;
परिभाषित करना nginx::server::location प्रकट में वर्णित है server/location.pp.

टेम्पलेट्स

निश्चित रूप से आप स्वयं जानते हैं कि टेम्पलेट क्या हैं; मैं यहां उनका विस्तार से वर्णन नहीं करूंगा। लेकिन मैं इसे किसी भी हालत में छोड़ दूँगा विकिपीडिया से लिंक करें.

टेम्प्लेट का उपयोग कैसे करें: किसी फ़ंक्शन का उपयोग करके टेम्प्लेट का अर्थ बढ़ाया जा सकता है template, जो टेम्पलेट का पथ पारित कर दिया गया है। प्रकार के संसाधनों के लिए पट्टिका पैरामीटर के साथ प्रयोग किया जाता है content. उदाहरण के लिए, इस तरह:

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

पथ देखें <modulename>/<filename> फ़ाइल का तात्पर्य है <rootdir>/modules/<modulename>/templates/<filename>.

इसके अलावा, एक समारोह है inline_template — यह इनपुट के रूप में टेम्प्लेट टेक्स्ट प्राप्त करता है, फ़ाइल नाम नहीं।

टेम्प्लेट के भीतर, आप वर्तमान दायरे में सभी पपेट वेरिएबल्स का उपयोग कर सकते हैं।

पपेट ईआरबी और ईपीपी प्रारूप में टेम्पलेट्स का समर्थन करता है:

संक्षेप में ईआरबी के बारे में

नियंत्रण संरचनाएँ:

<%= ВЫРАЖЕНИЕ %> - अभिव्यक्ति का मान डालें
<% ВЫРАЖЕНИЕ %> — किसी अभिव्यक्ति के मान की गणना करें (इसे डाले बिना)। सशर्त कथन (यदि) और लूप (प्रत्येक) आमतौर पर यहां जाते हैं।
<%# КОММЕНТАРИЙ %>

ईआरबी में भाव रूबी में लिखे गए हैं (ईआरबी वास्तव में एंबेडेड रूबी है)।

मेनिफेस्ट से वेरिएबल तक पहुंचने के लिए, आपको जोड़ना होगा @ परिवर्तनीय नाम के लिए. नियंत्रण निर्माण के बाद दिखाई देने वाले लाइन ब्रेक को हटाने के लिए, आपको एक समापन टैग का उपयोग करने की आवश्यकता है -%>.

टेम्पलेट का उपयोग करने का उदाहरण

मान लीजिए कि मैं ज़ूकीपर को नियंत्रित करने के लिए एक मॉड्यूल लिख रहा हूं। कॉन्फ़िगरेशन बनाने के लिए ज़िम्मेदार वर्ग कुछ इस तरह दिखता है:

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

तथ्य और अंतर्निहित चर

अक्सर कॉन्फ़िगरेशन का विशिष्ट भाग इस बात पर निर्भर करता है कि वर्तमान में नोड पर क्या हो रहा है। उदाहरण के लिए, डेबियन रिलीज़ क्या है, इसके आधार पर, आपको पैकेज का एक या दूसरा संस्करण स्थापित करना होगा। यदि नोड्स बदलते हैं तो आप मैन्युअल रूप से इस सब की निगरानी कर सकते हैं, फिर से लिखना शुरू कर सकते हैं। लेकिन यह कोई गंभीर दृष्टिकोण नहीं है; स्वचालन बहुत बेहतर है।

नोड्स के बारे में जानकारी प्राप्त करने के लिए, पपेट के पास तथ्य नामक एक तंत्र है। तथ्यों - यह नोड के बारे में जानकारी है, जो वैश्विक नामस्थान में सामान्य चर के रूप में मैनिफ़ेस्ट में उपलब्ध है। उदाहरण के लिए, होस्ट नाम, ऑपरेटिंग सिस्टम संस्करण, प्रोसेसर आर्किटेक्चर, उपयोगकर्ताओं की सूची, नेटवर्क इंटरफेस और उनके पते की सूची, और भी बहुत कुछ। तथ्य मैनिफ़ेस्ट और टेम्प्लेट में नियमित चर के रूप में उपलब्ध हैं।

तथ्यों के साथ काम करने का एक उदाहरण:

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

औपचारिक रूप से कहें तो, एक तथ्य का एक नाम (स्ट्रिंग) और एक मान होता है (विभिन्न प्रकार उपलब्ध हैं: स्ट्रिंग्स, एरेज़, शब्दकोश)। खाओ अंतर्निहित तथ्यों का सेट. आप अपना खुद का भी लिख सकते हैं. तथ्य संग्राहकों का वर्णन किया गया है रूबी में कार्यों की तरहया इस रूप में निष्पादन योग्य फ़ाइलें. तथ्यों को प्रपत्र में भी प्रस्तुत किया जा सकता है डेटा के साथ टेक्स्ट फ़ाइलें नोड्स पर.

ऑपरेशन के दौरान, कठपुतली एजेंट पहले सभी उपलब्ध तथ्य संग्राहकों को पैपेटसर्वर से नोड पर कॉपी करता है, जिसके बाद यह उन्हें लॉन्च करता है और एकत्रित तथ्यों को सर्वर पर भेजता है; इसके बाद, सर्वर कैटलॉग संकलित करना शुरू कर देता है।

निष्पादन योग्य फ़ाइलों के रूप में तथ्य

ऐसे तथ्यों को निर्देशिका में मॉड्यूल में रखा जाता है facts.d. बेशक, फ़ाइलें निष्पादन योग्य होनी चाहिए। चलाने पर, उन्हें या तो YAML या key=value प्रारूप में मानक आउटपुट में जानकारी आउटपुट करनी होगी।

यह न भूलें कि तथ्य उन सभी नोड्स पर लागू होते हैं जो पॉपपेट सर्वर द्वारा नियंत्रित होते हैं जिस पर आपका मॉड्यूल तैनात किया गया है। इसलिए, स्क्रिप्ट में, यह जांचने का ध्यान रखें कि सिस्टम में आपके तथ्य को काम करने के लिए आवश्यक सभी प्रोग्राम और फ़ाइलें हैं।

#!/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).

यहां दस्तावेज़ का प्रासंगिक अनुभाग है।

अंतर्निर्मित चर

तथ्यों के अलावा भी है कुछ चर, वैश्विक नामस्थान में उपलब्ध है।

विश्वसनीय तथ्य - वेरिएबल जो क्लाइंट के प्रमाणपत्र से लिए गए हैं (चूंकि प्रमाणपत्र आमतौर पर एक पॉपपेट सर्वर पर जारी किया जाता है, एजेंट केवल उसका प्रमाणपत्र नहीं ले सकता है और बदल नहीं सकता है, इसलिए वेरिएबल "विश्वसनीय" हैं): प्रमाणपत्र का नाम, का नाम होस्ट और डोमेन, प्रमाणपत्र से एक्सटेंशन।
सर्वर तथ्य -सर्वर के बारे में जानकारी से संबंधित चर-संस्करण, नाम, सर्वर आईपी पता, पर्यावरण।
एजेंट तथ्य - चर सीधे कठपुतली-एजेंट द्वारा जोड़े गए, न कि कारक द्वारा - प्रमाणपत्र नाम, एजेंट संस्करण, कठपुतली संस्करण।
मास्टर चर - पैपेटमास्टर वेरिएबल्स (एसआईसी!)। यह लगभग वैसा ही है जैसा कि अंदर है सर्वर तथ्य, प्लस कॉन्फ़िगरेशन पैरामीटर मान उपलब्ध हैं।
संकलक चर - कंपाइलर वैरिएबल जो प्रत्येक दायरे में भिन्न होते हैं: वर्तमान मॉड्यूल का नाम और उस मॉड्यूल का नाम जिसमें वर्तमान ऑब्जेक्ट तक पहुंच प्राप्त की गई थी। उदाहरण के लिए, उनका उपयोग यह जांचने के लिए किया जा सकता है कि आपकी निजी कक्षाएं सीधे अन्य मॉड्यूल से उपयोग नहीं की जा रही हैं।

अतिरिक्त 1: यह सब कैसे चलाएं और डिबग करें?

लेख में कठपुतली कोड के कई उदाहरण थे, लेकिन हमें यह बिल्कुल नहीं बताया गया कि इस कोड को कैसे चलाया जाए। खैर, मैं खुद को सही कर रहा हूं।

पपेट को चलाने के लिए एक एजेंट ही काफी है, लेकिन ज्यादातर मामलों के लिए आपको एक सर्वर की भी आवश्यकता होगी।

एजेंट

कम से कम संस्करण XNUMX के बाद से, कठपुतली-एजेंट पैकेज आधिकारिक कठपुतली भंडार इसमें सभी निर्भरताएँ (रूबी और संबंधित रत्न) शामिल हैं, इसलिए स्थापना में कोई कठिनाई नहीं है (मैं डेबियन-आधारित वितरण के बारे में बात कर रहा हूँ - हम RPM-आधारित वितरण का उपयोग नहीं करते हैं)।

सबसे सरल मामले में, कठपुतली कॉन्फ़िगरेशन का उपयोग करने के लिए, एजेंट को सर्वर रहित मोड में लॉन्च करना पर्याप्त है: बशर्ते कि कठपुतली कोड को नोड में कॉपी किया गया हो, लॉन्च करें puppet apply <путь к манифесту>:

atikhonov@atikhonov ~/puppet-test $ cat helloworld.pp 
node default {
    notify { 'Hello world!': }
}
atikhonov@atikhonov ~/puppet-test $ puppet apply helloworld.pp 
Notice: Compiled catalog for atikhonov.localdomain in environment production in 0.01 seconds
Notice: Hello world!
Notice: /Stage[main]/Main/Node[default]/Notify[Hello world!]/message: defined 'message' as 'Hello world!'
Notice: Applied catalog in 0.01 seconds

बेशक, सर्वर को सेट करना और एजेंटों को डेमॉन मोड में नोड्स पर चलाना बेहतर है - फिर हर आधे घंटे में एक बार वे सर्वर से डाउनलोड किए गए कॉन्फ़िगरेशन को लागू करेंगे।

आप काम के पुश मॉडल का अनुकरण कर सकते हैं - जिस नोड में आप रुचि रखते हैं उस पर जाएं और शुरू करें sudo puppet agent -t. चाभी -t (--test) वास्तव में कई विकल्प शामिल हैं जिन्हें व्यक्तिगत रूप से सक्षम किया जा सकता है। इन विकल्पों में निम्नलिखित शामिल हैं:

डेमॉन मोड में न चलाएं (डिफ़ॉल्ट रूप से एजेंट डेमॉन मोड में प्रारंभ होता है);
कैटलॉग लागू करने के बाद बंद करें (डिफ़ॉल्ट रूप से, एजेंट काम करना जारी रखेगा और हर आधे घंटे में एक बार कॉन्फ़िगरेशन लागू करेगा);
एक विस्तृत कार्य लॉग लिखें;
फ़ाइलों में परिवर्तन दिखाएँ.

एजेंट के पास बिना बदलाव के एक ऑपरेटिंग मोड है - आप इसका उपयोग तब कर सकते हैं जब आप सुनिश्चित नहीं हैं कि आपने सही कॉन्फ़िगरेशन लिखा है और यह जांचना चाहते हैं कि ऑपरेशन के दौरान एजेंट वास्तव में क्या बदलेगा। यह मोड पैरामीटर द्वारा सक्षम किया गया है --noop कमांड लाइन पर: sudo puppet agent -t --noop.

इसके अलावा, आप कार्य के डिबगिंग लॉग को सक्षम कर सकते हैं - इसमें, कठपुतली अपने द्वारा किए जाने वाले सभी कार्यों के बारे में लिखती है: उस संसाधन के बारे में जिसे वह वर्तमान में संसाधित कर रही है, इस संसाधन के मापदंडों के बारे में, यह कौन से प्रोग्राम लॉन्च करती है। बेशक यह एक पैरामीटर है --debug.

सेवक

मैं इस लेख में पैपेटसर्वर के पूर्ण सेटअप और उस पर कोड को तैनात करने पर विचार नहीं करूंगा; मैं केवल यह कहूंगा कि बॉक्स के बाहर सर्वर का एक पूरी तरह कार्यात्मक संस्करण है जिसे कम संख्या में काम करने के लिए अतिरिक्त कॉन्फ़िगरेशन की आवश्यकता नहीं है नोड्स (मान लीजिए, सौ तक)। बड़ी संख्या में नोड्स को ट्यूनिंग की आवश्यकता होगी - डिफ़ॉल्ट रूप से, पपेटसर्वर चार से अधिक श्रमिकों को लॉन्च नहीं करता है, बेहतर प्रदर्शन के लिए आपको उनकी संख्या बढ़ाने की आवश्यकता है और मेमोरी सीमा को बढ़ाना न भूलें, अन्यथा सर्वर अधिकांश समय कचरा एकत्र करेगा।

कोड परिनियोजन - यदि आपको इसकी शीघ्रता और आसानी से आवश्यकता है, तो देखें (r10k पर)[https://github.com/puppetlabs/r10k], छोटी स्थापनाओं के लिए यह काफी पर्याप्त होना चाहिए।

परिशिष्ट 2: कोडिंग दिशानिर्देश

सभी तर्कों को कक्षाओं और परिभाषाओं में रखें।
कक्षाओं और परिभाषाओं को मॉड्यूल में रखें, नोड्स का वर्णन करने वाले मैनिफ़ेस्ट में नहीं।
तथ्यों का प्रयोग करें.
होस्टनाम के आधार पर ifs न बनाएं।
कक्षाओं और परिभाषाओं के लिए पैरामीटर जोड़ने के लिए स्वतंत्र महसूस करें - यह कक्षा/परिभाषा के मुख्य भाग में छिपे अंतर्निहित तर्क से बेहतर है।

मैं अगले लेख में बताऊंगा कि मैं ऐसा करने की अनुशंसा क्यों करता हूं।

निष्कर्ष

आइए परिचय के साथ समाप्त करें। अगले लेख में मैं आपको Hiera, ENC और PuppetDB के बारे में बताऊंगा।

केवल पंजीकृत उपयोगकर्ता ही सर्वेक्षण में भाग ले सकते हैं। साइन इन करेंकृपया।

वास्तव में, बहुत अधिक सामग्री है - मैं निम्नलिखित विषयों पर लेख लिख सकता हूं, जिस बारे में पढ़ने में आपकी रुचि होगी उस पर वोट कर सकता हूं:

59,1% तक उन्नत कठपुतली निर्माण - कुछ अगले स्तर की चीजें: लूप, मैपिंग और अन्य लैम्ब्डा अभिव्यक्ति, संसाधन संग्राहक, निर्यातित संसाधन और कठपुतली, टैग, प्रदाताओं, अमूर्त डेटा प्रकारों के माध्यम से अंतर-होस्ट संचार।13
31,8% तक "मैं अपनी मां का व्यवस्थापक हूं" या हमने एविटो में विभिन्न संस्करणों के कई पॉपपेट सर्वरों के साथ दोस्ती कैसे की, और, सिद्धांत रूप में, पॉपपेट सर्वर को प्रशासित करने का हिस्सा।7
81,8% तक हम कठपुतली कोड कैसे लिखते हैं: उपकरण, दस्तावेज़ीकरण, परीक्षण, सीआई/सीडी.18

22 उपयोगकर्ताओं ने मतदान किया। 9 उपयोगकर्ता अनुपस्थित रहे।

स्रोत: www.habr.com

कठपुतली का परिचय

मूलभूत जानकारी

घोषणापत्रों का परिचय

सिंटेक्स और कोडस्टाइल

पैपेटसर्वर पर फ़ाइलों का स्थान

युद्ध के कुछ उदाहरण

उस पर नोड और संसाधन का विवरण

एक नोड पर संसाधनों के बीच संबंध

संसाधन प्रकार

पट्टिका

पैकेज

सेवा

कार्यकारी

क्रॉन

सामान्य तौर पर संसाधनों के बारे में

संसाधन विशिष्टता के लिए आवश्यकताएँ

मेटापैरामीटर

संसाधनों से लिंक

निर्भरताएँ और सूचनाएं

अनिर्दिष्ट मापदंडों को संभालना

कक्षाओं, चरों और परिभाषाओं का परिचय

Классы

चर

कक्षाएं: वर्गनाम बनाम वर्ग शामिल करें {'वर्गनाम':}

को परिभाषित करता है

वर्गों और परिभाषाओं के लिए निर्भरताएँ और सूचनाएं

सशर्त बयान और चयनकर्ता

if

जब तक

मामला

चयनकर्ताओं

मॉड्यूल

एक मॉड्यूल में फ़ाइल संरचना

मॉड्यूल में संसाधनों के नाम और फ़ाइलों के नाम

टेम्पलेट्स

संक्षेप में ईआरबी के बारे में

टेम्पलेट का उपयोग करने का उदाहरण

तथ्य और अंतर्निहित चर

निष्पादन योग्य फ़ाइलों के रूप में तथ्य

रूबी तथ्य

पाठ तथ्य

तथ्यों तक पहुंचना

अंतर्निर्मित चर

अतिरिक्त 1: यह सब कैसे चलाएं और डिबग करें?

एजेंट

सेवक

परिशिष्ट 2: कोडिंग दिशानिर्देश

निष्कर्ष