पपेट एक कॉन्फिगरेशन व्यवस्थापन प्रणाली आहे. यजमानांना इच्छित स्थितीत आणण्यासाठी आणि ही स्थिती राखण्यासाठी याचा वापर केला जातो.

मी आता पाच वर्षांपासून पपेटसोबत काम करत आहे. हा मजकूर मूलत: अधिकृत दस्तऐवजीकरणातील मुख्य मुद्द्यांचे भाषांतरित आणि पुनर्क्रमित संकलन आहे, जे नवशिक्यांना पपेटचे सार त्वरीत समजून घेण्यास अनुमती देईल.

मुलभूत माहिती

पपेटची ऑपरेटिंग सिस्टीम क्लायंट-सर्व्हर आहे, जरी ती मर्यादित कार्यक्षमतेसह सर्व्हरलेस ऑपरेशनला देखील समर्थन देते.

ऑपरेशनचे पुल मॉडेल वापरले जाते: डीफॉल्टनुसार, दर अर्ध्या तासाने एकदा, क्लायंट कॉन्फिगरेशनसाठी सर्व्हरशी संपर्क साधतात आणि ते लागू करतात. जर तुम्ही Ansible सह काम केले असेल, तर ते वेगळे पुश मॉडेल वापरतात: प्रशासक कॉन्फिगरेशन लागू करण्याची प्रक्रिया सुरू करतो, क्लायंट स्वतः काहीही लागू करणार नाहीत.

नेटवर्क संप्रेषणादरम्यान, द्वि-मार्ग TLS एन्क्रिप्शन वापरले जाते: सर्व्हर आणि क्लायंटकडे त्यांच्या स्वतःच्या खाजगी की आणि संबंधित प्रमाणपत्रे असतात. सामान्यत: सर्व्हर क्लायंटसाठी प्रमाणपत्रे जारी करतो, परंतु तत्त्वतः बाह्य CA वापरणे शक्य आहे.

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

कठपुतळीच्या परिभाषेत कठपुतळी सर्व्हरला कनेक्ट करा नोडस् (नोड्स). नोड्ससाठी कॉन्फिगरेशन लिहिलेले आहे जाहीरनाम्यात विशेष प्रोग्रामिंग भाषेत - पपेट डीएसएल.

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

फाइल अस्तित्वात आहे आणि त्यात विशिष्ट सामग्री आहे.
पॅकेज स्थापित केले आहे.
सेवा सुरू झाली आहे.

संसाधने एकमेकांशी जोडली जाऊ शकतात:

अवलंबित्व आहेत, ते संसाधने वापरल्या जाणार्‍या क्रमावर परिणाम करतात.
उदाहरणार्थ, "प्रथम पॅकेज स्थापित करा, नंतर कॉन्फिगरेशन फाइल संपादित करा, नंतर सेवा सुरू करा."
अधिसूचना आहेत - जर एखादा संसाधन बदलला असेल, तर ते त्याची सदस्यता घेतलेल्या संसाधनांना सूचना पाठवते.
उदाहरणार्थ, कॉन्फिगरेशन फाइल बदलल्यास, तुम्ही आपोआप सेवा रीस्टार्ट करू शकता.

याव्यतिरिक्त, पपेट डीएसएलमध्ये फंक्शन्स आणि व्हेरिएबल्स तसेच कंडिशनल स्टेटमेंट्स आणि सिलेक्टर्स आहेत. विविध टेम्प्लेटिंग यंत्रणा देखील समर्थित आहेत - EPP आणि ERB.

पपेट रुबीमध्ये लिहिलेले आहे, त्यामुळे अनेक रचना आणि संज्ञा तिथून घेतल्या आहेत. रुबी तुम्हाला पपेटचा विस्तार करण्यास अनुमती देते - जटिल तर्कशास्त्र, नवीन प्रकारचे संसाधने, कार्ये जोडा.

पपेट चालू असताना, सर्व्हरवरील प्रत्येक विशिष्ट नोडसाठी मॅनिफेस्ट एका निर्देशिकेत संकलित केले जातात. निर्देशिका फंक्शन्स, व्हेरिएबल्स आणि कंडिशनल स्टेटमेंट्सच्या विस्ताराचे मूल्य मोजल्यानंतर संसाधनांची आणि त्यांच्या संबंधांची सूची आहे.

वाक्यरचना आणि कोडशैली

येथे अधिकृत दस्तऐवजीकरणाचे विभाग आहेत जे प्रदान केलेली उदाहरणे पुरेशी नसल्यास वाक्यरचना समजून घेण्यास मदत करतील:

मॅनिफेस्ट कसा दिसतो याचे येथे एक उदाहरण आहे:

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

इंडेंटेशन आणि लाइन ब्रेक हे मॅनिफेस्टचे आवश्यक भाग नाहीत, परंतु एक शिफारस केली आहे शैली मार्गदर्शक. सारांश:

दोन-स्पेस इंडेंट, टॅब वापरले जात नाहीत.
कुरळे ब्रेसेस स्पेसद्वारे वेगळे केले जातात; कोलन स्पेसद्वारे वेगळे केले जात नाहीत.
प्रत्येक पॅरामीटरनंतर स्वल्पविराम, शेवटच्या पॅरामीटरसह. प्रत्येक पॅरामीटर वेगळ्या ओळीवर आहे. पॅरामीटर्स आणि एका पॅरामीटरशिवाय केससाठी अपवाद केला जातो: तुम्ही एका ओळीवर आणि स्वल्पविरामाशिवाय लिहू शकता (उदा. resource { 'title': } и resource { 'title': param => value }).
पॅरामीटर्सवरील बाण समान स्तरावर असावेत.
त्यांच्या पुढे संसाधन संबंध बाण लिहिलेले आहेत.

पॅपेटसर्व्हरवरील फाइल्सचे स्थान

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

रूट डिरेक्टरी पपेटच्या आवृत्तीवर आणि वापरलेल्या वातावरणानुसार बदलते. पर्यावरण हे कॉन्फिगरेशनचे स्वतंत्र संच आहेत जे स्वतंत्र निर्देशिकांमध्ये संग्रहित केले जातात. सहसा git सह संयोजनात वापरले जाते, अशा परिस्थितीत git शाखांमधून वातावरण तयार केले जाते. त्यानुसार, प्रत्येक नोड एका वातावरणात किंवा दुसर्यामध्ये स्थित आहे. हे नोडवर किंवा ईएनसीमध्ये कॉन्फिगर केले जाऊ शकते, ज्याबद्दल मी पुढील लेखात बोलेन.

तिसऱ्या आवृत्तीमध्ये ("जुने कठपुतळी") बेस डिरेक्टरी होती /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 - सिमलिंक
सामग्री — फाइल सामग्री (केवळ नियमित फाइल्ससाठी योग्य, एकत्र वापरली जाऊ शकत नाही स्रोत किंवा लक्ष्य)
स्रोत — ज्या मार्गावरून तुम्ही फाईलमधील मजकूर कॉपी करू इच्छिता त्या मार्गाचा दुवा (यासह एकत्र वापरले जाऊ शकत नाही सामग्री किंवा लक्ष्य). योजनेसह एकतर URI म्हणून निर्दिष्ट केले जाऊ शकते puppet: (नंतर कठपुतळी सर्व्हरवरील फायली वापरल्या जातील), आणि योजनेसह http: (मला आशा आहे की या प्रकरणात काय होईल हे स्पष्ट आहे), आणि अगदी आकृतीसह file: किंवा स्कीमाशिवाय परिपूर्ण मार्ग म्हणून (नंतर नोडवरील स्थानिक FS मधील फाइल वापरली जाईल)
लक्ष्य — जेथे सिमलिंक निर्देशित केले पाहिजे (सह एकत्र वापरले जाऊ शकत नाही सामग्री किंवा स्रोत)
मालक — वापरकर्ता ज्याच्याकडे फाइल असावी
गट — फाइल ज्या गटाशी संबंधित असावी
मोड - फाइल परवानग्या (स्ट्रिंग म्हणून)
पुनरावृत्ती - आवर्ती निर्देशिका प्रक्रिया सक्षम करते
कोठा साफ - पपेटमध्ये वर्णन नसलेल्या फायली हटवणे सक्षम करते
शक्ती - पपेटमध्ये वर्णन न केलेल्या डिरेक्ट्री हटवणे सक्षम करते

पॅकेज

पॅकेजेस स्थापित आणि काढून टाकते. सूचना हाताळण्यास सक्षम - पॅरामीटर निर्दिष्ट केले असल्यास पॅकेज पुन्हा स्थापित करते reinstall_on_refresh.

मापदंड:

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

सेवा

सेवा व्यवस्थापित करते. सूचनांवर प्रक्रिया करण्यास सक्षम - सेवा रीस्टार्ट करते.

मापदंड:

संसाधनाचे नाव - व्यवस्थापित करण्याची सेवा (पर्यायी)
नाव - व्यवस्थापित करणे आवश्यक असलेली सेवा (नावात निर्दिष्ट नसल्यास)
याची खात्री - सेवेची इच्छित स्थिती:
- running - लाँच केले
- stopped - थांबले
सक्षम करा - सेवा सुरू करण्याची क्षमता नियंत्रित करते:
- true - ऑटोरन सक्षम आहे (systemctl enable)
- mask - वेषात (systemctl mask)
- false - ऑटोरन अक्षम आहे (systemctl disable)
पुन्हा सुरू करा - सेवा रीस्टार्ट करण्यासाठी कमांड
स्थिती - सेवा स्थिती तपासण्यासाठी आदेश
पुन्हा सुरू करा — सर्व्हिस इनिटस्क्रिप्ट रीस्टार्ट करण्यास समर्थन देते की नाही ते सूचित करा. तर false आणि पॅरामीटर निर्दिष्ट केले आहे पुन्हा सुरू करा — या पॅरामीटरचे मूल्य वापरले जाते. तर false आणि पॅरामीटर पुन्हा सुरू करा निर्दिष्ट नाही - सेवा थांबविली आहे आणि रीस्टार्ट करणे सुरू केले आहे (परंतु systemd कमांड वापरते systemctl restart).
स्टेटस — सर्व्हिस इनिटस्क्रिप्ट आदेशाला समर्थन देते की नाही ते सूचित करा status. जर false, नंतर पॅरामीटर मूल्य वापरले जाते स्थिती. डीफॉल्ट true.

exec

बाह्य आदेश चालवते. आपण पॅरामीटर्स निर्दिष्ट न केल्यास निर्माण, फक्त जर, जोपर्यंत तो किंवा ताजेतवाने, प्रत्येक वेळी पपेट चालवताना कमांड रन होईल. सूचनांवर प्रक्रिया करण्यास सक्षम - कमांड चालवते.

मापदंड:

संसाधनाचे नाव - अंमलात आणण्याची आज्ञा (पर्यायी)
आदेश — अंमलात आणण्याची आज्ञा (जर ती नावात नमूद केलेली नसेल)
मार्ग — एक्झिक्युटेबल फाइल शोधायचे मार्ग
फक्त जर — या पॅरामीटरमध्ये निर्दिष्ट केलेली कमांड शून्य रिटर्न कोडसह पूर्ण झाल्यास, मुख्य कमांड कार्यान्वित केली जाईल
जोपर्यंत तो — या पॅरामीटरमध्ये निर्दिष्ट केलेली कमांड शून्य नॉन रिटर्न कोडसह पूर्ण झाल्यास, मुख्य कमांड कार्यान्वित केली जाईल
निर्माण — या पॅरामीटरमध्ये निर्दिष्ट केलेली फाइल अस्तित्वात नसल्यास, मुख्य कमांड कार्यान्वित केली जाईल
ताजेतवाने - तर true, नंतर कमांड फक्त तेव्हाच चालवली जाईल जेव्हा या exec ला इतर स्त्रोतांकडून सूचना प्राप्त होते
cwd — डिरेक्टरी ज्यामधून कमांड चालवायची
वापरकर्ता — ज्या वापरकर्त्याकडून कमांड चालवायची आहे
प्रदाता - कमांड कशी चालवायची:
- पोझिक्स — एक मूल प्रक्रिया फक्त तयार केली आहे, निर्दिष्ट करण्याचे सुनिश्चित करा मार्ग
- शेल - कमांड शेलमध्ये लॉन्च केली जाते /bin/sh, निर्दिष्ट केले जाऊ शकत नाही मार्ग, तुम्ही ग्लोबिंग, पाईप्स आणि इतर शेल वैशिष्ट्ये वापरू शकता. कोणतेही विशेष वर्ण असल्यास सामान्यतः स्वयंचलितपणे शोधले जाते (|, ;, &&, || इ).

क्रोन

क्रोनजॉब्स नियंत्रित करते.

मापदंड:

संसाधनाचे नाव - फक्त एक प्रकारचा अभिज्ञापक
याची खात्री - क्राउनजॉब स्थिती:
- present - अस्तित्वात नसल्यास तयार करा
- absent - अस्तित्वात असल्यास हटवा
आदेश - कोणती आज्ञा चालवायची
पर्यावरण — कोणत्या वातावरणात कमांड चालवायची (पर्यावरण व्हेरिएबल्सची सूची आणि त्यांची मूल्ये द्वारे =)
वापरकर्ता — कोणत्या वापरकर्त्याकडून कमांड चालवायची
मिनिट, तास, आठवड्याचा दिवस, महिन्यात, महिन्याचा दिवस - क्रॉन कधी चालवायचा. यापैकी कोणतीही विशेषता निर्दिष्ट केलेली नसल्यास, क्रॉन्टॅबमध्ये त्याचे मूल्य असेल *.

पपेट 6.0 मध्ये क्रोन जसे की बॉक्समधून काढले puppetserver मध्ये, त्यामुळे सामान्य साइटवर कोणतेही दस्तऐवजीकरण नाही. पण तो बॉक्समध्ये आहे कठपुतळी-एजंटमध्ये, म्हणून ते स्वतंत्रपणे स्थापित करण्याची आवश्यकता नाही. त्यासाठी तुम्ही कागदपत्रे पाहू शकता पपेटच्या पाचव्या आवृत्तीच्या दस्तऐवजीकरणात, किंवा GitHub वर.

सर्वसाधारणपणे संसाधनांबद्दल

संसाधनाच्या विशिष्टतेसाठी आवश्यकता

आपल्याला आढळणारी सर्वात सामान्य चूक आहे डुप्लिकेट घोषणा. जेव्हा निर्देशिकेत एकाच नावाचे दोन किंवा अधिक संसाधने दिसतात तेव्हा ही त्रुटी उद्भवते.

म्हणून, मी पुन्हा लिहीन: समान नोडसाठी मॅनिफेस्टमध्ये समान शीर्षकासह समान प्रकारची संसाधने नसावीत!

काहीवेळा समान नावाची पॅकेजेस स्थापित करण्याची आवश्यकता असते, परंतु भिन्न पॅकेज व्यवस्थापकांसह. या प्रकरणात, आपल्याला पॅरामीटर वापरण्याची आवश्यकता आहे nameत्रुटी टाळण्यासाठी:

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

इतर संसाधन प्रकारांमध्ये डुप्लिकेशन टाळण्यासाठी मदत करण्यासाठी समान पर्याय आहेत - name у सेवा, command у exec, आणि असेच.

मेटापॅरामीटर्स

प्रत्येक संसाधन प्रकारात काही विशेष मापदंड असतात, त्याचे स्वरूप काहीही असो.

मेटा पॅरामीटर्सची संपूर्ण यादी कठपुतळी दस्तऐवजात.

छोटी यादी:

आवश्यक — हे पॅरामीटर सूचित करते की हे संसाधन कोणत्या संसाधनांवर अवलंबून आहे.
आधी - हे पॅरामीटर निर्दिष्ट करते की या संसाधनावर कोणती संसाधने अवलंबून आहेत.
सदस्यता — हे पॅरामीटर निर्दिष्ट करते की हे संसाधन कोणत्या स्त्रोतांकडून सूचना प्राप्त करते.
सूचित करा — हे पॅरामीटर निर्दिष्ट करते की कोणत्या संसाधनांना या स्त्रोताकडून सूचना प्राप्त होतात.

सर्व सूचीबद्ध मेटापॅरामीटर्स एकतर रिसोर्स लिंक किंवा स्क्वेअर ब्रॅकेटमधील लिंक्सचा अॅरे स्वीकारतात.

संसाधनांचे दुवे

संसाधन दुवा म्हणजे फक्त संसाधनाचा उल्लेख. ते प्रामुख्याने अवलंबित्व दर्शविण्यासाठी वापरले जातात. अस्तित्वात नसलेल्या संसाधनाचा संदर्भ दिल्याने संकलन त्रुटी निर्माण होईल.

दुव्याचे वाक्यरचना खालीलप्रमाणे आहे: मोठ्या अक्षरासह संसाधन प्रकार (जर प्रकाराच्या नावात दुहेरी कोलन असतील, तर कोलनमधील नावाचा प्रत्येक भाग कॅपिटल केला जातो), नंतर चौरस कंसात संसाधनाचे नाव (नावाचे केस) बदलत नाही!). रिक्त स्थान नसावे; चौरस कंस प्रकाराच्या नावानंतर लगेच लिहिला जातो.

उदाहरण:

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

अवलंबित्व आणि सूचना

येथे दस्तऐवजीकरण.

आधी सांगितल्याप्रमाणे, संसाधनांमधील साधे अवलंबित्व हे सकर्मक असते. तसे, अवलंबन जोडताना सावधगिरी बाळगा - आपण चक्रीय अवलंबन तयार करू शकता, ज्यामुळे संकलन त्रुटी निर्माण होईल.

अवलंबनांप्रमाणे, सूचना संक्रमणात्मक नसतात. सूचनांसाठी खालील नियम लागू होतात:

संसाधनास सूचना प्राप्त झाल्यास, ते अद्यतनित केले जाते. अद्यतन क्रिया संसाधन प्रकारावर अवलंबून असतात - exec कमांड चालवते, सेवा सेवा पुन्हा सुरू करते, पॅकेज पॅकेज पुन्हा स्थापित करते. जर संसाधनामध्ये अद्यतन क्रिया परिभाषित केली नसेल, तर काहीही होणार नाही.
पपेटच्या एका रन दरम्यान, संसाधन एकापेक्षा जास्त वेळा अद्यतनित केले जात नाही. हे शक्य आहे कारण अधिसूचनांमध्ये अवलंबित्वांचा समावेश होतो आणि अवलंबित्व आलेखामध्ये चक्र नसतात.
जर कठपुतळीने संसाधनाची स्थिती बदलली तर, संसाधन त्याच्या सदस्यता घेतलेल्या सर्व संसाधनांना सूचना पाठवते.
एखादे संसाधन अद्यतनित केले असल्यास, ते सदस्यत्व घेतलेल्या सर्व संसाधनांना सूचना पाठवते.

अनिर्दिष्ट पॅरामीटर्स हाताळणे

नियमानुसार, काही संसाधन पॅरामीटरमध्ये डीफॉल्ट मूल्य नसल्यास आणि हे पॅरामीटर मॅनिफेस्टमध्ये निर्दिष्ट केलेले नसल्यास, पपेट नोडवरील संबंधित संसाधनासाठी ही गुणधर्म बदलणार नाही. उदाहरणार्थ, जर संसाधनाचे प्रकार फाइल पॅरामीटर निर्दिष्ट नाही 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,
) {
  ...
}

वर्ग: वर्गनाम वि वर्ग{'classname':} समाविष्ट करा

प्रत्येक वर्ग एक प्रकारचा स्त्रोत आहे वर्ग. इतर कोणत्याही प्रकारच्या संसाधनाप्रमाणे, एकाच नोडवर एकाच वर्गाची दोन उदाहरणे असू शकत नाहीत.

तुम्ही एकाच नोडमध्ये दोनदा वर्ग जोडण्याचा प्रयत्न केल्यास class { 'classname':} (कोणताही फरक नाही, भिन्न किंवा समान पॅरामीटर्ससह), एक संकलन त्रुटी असेल. परंतु जर तुम्ही संसाधन शैलीमध्ये वर्ग वापरत असाल, तर तुम्ही त्याचे सर्व पॅरामीटर्स मॅनिफेस्टमध्ये लगेचच स्पष्टपणे सेट करू शकता.

तथापि, आपण वापरल्यास include, नंतर वर्ग पाहिजे तितक्या वेळा जोडला जाऊ शकतो. वस्तुस्थिती अशी आहे include डिरेक्टरीमध्ये क्लास जोडला गेला आहे की नाही हे तपासणारे एक इडम्पोटेंट फंक्शन आहे. जर वर्ग निर्देशिकेत नसेल, तर तो जोडतो आणि जर तो आधीपासून अस्तित्वात असेल तर ते काहीही करत नाही. पण वापरण्याच्या बाबतीत include तुम्ही क्लास डिक्लेरेशन दरम्यान क्लास पॅरामीटर्स सेट करू शकत नाही - सर्व आवश्यक पॅरामीटर्स बाह्य डेटा स्त्रोतामध्ये सेट करणे आवश्यक आहे - Hiera किंवा ENC. पुढील लेखात आपण त्यांच्याबद्दल बोलू.

व्याख्या करतो

मागील ब्लॉकमध्ये म्हटल्याप्रमाणे, समान वर्ग नोडवर एकापेक्षा जास्त वेळा उपस्थित राहू शकत नाही. तथापि, काही प्रकरणांमध्ये तुम्हाला समान नोडवर भिन्न पॅरामीटर्ससह कोडचा समान ब्लॉक वापरण्यास सक्षम असणे आवश्यक आहे. दुसऱ्या शब्दांत, स्वतःच्या संसाधन प्रकाराची आवश्यकता आहे.

उदाहरणार्थ, 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 {
  ...
}

जोपर्यंत तो

जोपर्यंत एक if विरुद्ध आहे: जर अभिव्यक्ती असत्य असेल तर कोडचा ब्लॉक कार्यान्वित केला जाईल.

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

केस

येथे देखील काहीही क्लिष्ट नाही. तुम्ही रेग्युलर व्हॅल्यूज (स्ट्रिंग्स, नंबर्स इ.), रेग्युलर एक्स्प्रेशन्स आणि डेटा प्रकार व्हॅल्यू म्हणून वापरू शकता.

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

निवडकर्ते

सिलेक्टर ही भाषा सारखी रचना आहे case, परंतु कोडचा ब्लॉक कार्यान्वित करण्याऐवजी, ते मूल्य परत करते.

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

मॉड्यूल्स

जेव्हा कॉन्फिगरेशन लहान असते, तेव्हा ते सहजपणे एका मॅनिफेस्टमध्ये ठेवता येते. परंतु आपण जितके अधिक कॉन्फिगरेशनचे वर्णन करू तितके अधिक वर्ग आणि नोड्स मॅनिफेस्टमध्ये आहेत, ते वाढतात आणि त्यांच्यासह कार्य करणे गैरसोयीचे होते.

याव्यतिरिक्त, कोडच्या पुनर्वापराची समस्या आहे - जेव्हा सर्व कोड एकाच मॅनिफेस्टमध्ये असतात, तेव्हा हा कोड इतरांसह सामायिक करणे कठीण असते. या दोन समस्यांचे निराकरण करण्यासाठी, कठपुतळीमध्ये मॉड्यूल्स नावाचे अस्तित्व आहे.

मॉड्यूल्स - हे वर्ग, व्याख्या आणि वेगळ्या निर्देशिकेत ठेवलेल्या इतर पपेट घटकांचे संच आहेत. दुसऱ्या शब्दांत, मॉड्यूल हा पपेट लॉजिकचा एक स्वतंत्र भाग आहे. उदाहरणार्थ, nginx सह कार्य करण्यासाठी एक मॉड्यूल असू शकते आणि त्यात nginx सह कार्य करण्यासाठी काय आणि फक्त काय आवश्यक आहे ते समाविष्ट असेल किंवा PHP सह कार्य करण्यासाठी मॉड्यूल असू शकते, इत्यादी.

मॉड्युल्सची आवृत्ती केली जाते आणि मॉड्यूल्सची एकमेकांवरील अवलंबित्व देखील समर्थित आहेत. मॉड्यूल्सचे खुले भांडार आहे - कठपुतळी फोर्ज.

कठपुतळी सर्व्हरवर, मॉड्यूल रूट निर्देशिकेच्या मॉड्यूल्स उपनिर्देशिकेमध्ये स्थित आहेत. प्रत्येक मॉड्यूलच्या आत एक मानक निर्देशिका योजना असते - मॅनिफेस्ट, फाइल्स, टेम्पलेट्स, lib आणि असेच.

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

मॉड्यूलच्या रूटमध्ये वर्णनात्मक नावांसह खालील निर्देशिका असू शकतात:

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 — ते इनपुट म्हणून टेम्पलेट मजकूर प्राप्त करते, फाइलचे नाव नाही.

टेम्प्लेट्समध्ये, तुम्ही सध्याच्या स्कोपमधील सर्व पपेट व्हेरिएबल्स वापरू शकता.

पपेट ईआरबी आणि ईपीपी फॉरमॅटमध्ये टेम्पलेट्सचे समर्थन करते:

थोडक्यात ERB बद्दल

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

<%= ВЫРАЖЕНИЕ %> - अभिव्यक्तीचे मूल्य घाला
<% ВЫРАЖЕНИЕ %> — अभिव्यक्तीच्या मूल्याची गणना करा (ते न घालता). सशर्त विधाने (जर) आणि लूप (प्रत्येक) सहसा येथे जातात.
<%# КОММЕНТАРИЙ %>

ERB मधील अभिव्यक्ती रुबीमध्ये लिहिलेली आहेत (ERB प्रत्यक्षात एम्बेडेड रुबी आहे).

मॅनिफेस्टमधून व्हेरिएबल्समध्ये प्रवेश करण्यासाठी, तुम्हाला जोडणे आवश्यक आहे @ व्हेरिएबलच्या नावावर. कंट्रोल कंस्ट्रक्ट नंतर दिसणारा लाइन ब्रेक काढण्यासाठी, तुम्हाला क्लोजिंग टॅग वापरण्याची आवश्यकता आहे -%>.

टेम्पलेट वापरण्याचे उदाहरण

समजा मी 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 -%>

तथ्ये आणि अंगभूत चल

बहुतेकदा कॉन्फिगरेशनचा विशिष्ट भाग नोडवर सध्या काय घडत आहे यावर अवलंबून असतो. उदाहरणार्थ, डेबियन रिलीझ काय आहे यावर अवलंबून, आपल्याला पॅकेजची एक किंवा दुसरी आवृत्ती स्थापित करण्याची आवश्यकता आहे. तुम्ही हे सर्व मॅन्युअली मॉनिटर करू शकता, नोड्स बदलल्यास पुन्हा लिहिणे. परंतु हा एक गंभीर दृष्टीकोन नाही; ऑटोमेशन बरेच चांगले आहे.

नोड्सबद्दल माहिती मिळविण्यासाठी, पपेटमध्ये तथ्य नावाची यंत्रणा असते. तथ्ये - ही नोडविषयी माहिती आहे, जी जागतिक नेमस्पेसमध्ये सामान्य व्हेरिएबल्सच्या स्वरूपात मॅनिफेस्टमध्ये उपलब्ध आहे. उदाहरणार्थ, होस्टचे नाव, ऑपरेटिंग सिस्टम आवृत्ती, प्रोसेसर आर्किटेक्चर, वापरकर्त्यांची यादी, नेटवर्क इंटरफेस आणि त्यांचे पत्ते आणि बरेच काही. तथ्ये मॅनिफेस्ट आणि टेम्पलेट्समध्ये नियमित व्हेरिएबल्स म्हणून उपलब्ध आहेत.

तथ्यांसह कार्य करण्याचे उदाहरण:

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).

दस्तऐवजीकरणाचा संबंधित विभाग येथे आहे.

अंगभूत व्हेरिएबल्स

तथ्यांव्यतिरिक्त, आहे काही चल, जागतिक नेमस्पेसमध्ये उपलब्ध आहे.

विश्वसनीय तथ्ये — व्हेरिएबल्स जे क्लायंटच्या प्रमाणपत्रावरून घेतले जातात (प्रमाणपत्र सहसा पॉपपेट सर्व्हरवर जारी केले जात असल्याने, एजंट फक्त त्याचे प्रमाणपत्र घेऊ शकत नाही आणि बदलू शकत नाही, म्हणून व्हेरिएबल्स "विश्वसनीय" आहेत): प्रमाणपत्राचे नाव, नाव होस्ट आणि डोमेन, प्रमाणपत्रातील विस्तार.
सर्व्हर तथ्ये —सर्व्हरविषयी माहितीशी संबंधित व्हेरिएबल्स—आवृत्ती, नाव, सर्व्हरचा IP पत्ता, पर्यावरण.
एजंट तथ्ये — व्हेरिएबल्स थेट कठपुतळी-एजंटद्वारे जोडले जातात, आणि फॅक्टरद्वारे नाही — प्रमाणपत्राचे नाव, एजंट आवृत्ती, कठपुतळी आवृत्ती.
मास्टर व्हेरिएबल्स - पॅपेटमास्टर व्हेरिएबल्स (sic!). मध्ये सारखेच आहे सर्व्हर तथ्ये, अधिक कॉन्फिगरेशन पॅरामीटर मूल्ये उपलब्ध आहेत.
कंपाइलर व्हेरिएबल्स — कंपाइलर व्हेरिएबल्स जे प्रत्येक स्कोपमध्ये भिन्न असतात: वर्तमान मॉड्यूलचे नाव आणि ज्या मॉड्यूलमध्ये वर्तमान ऑब्जेक्ट ऍक्सेस केला होता त्याचे नाव. ते वापरले जाऊ शकतात, उदाहरणार्थ, तुमचे खाजगी वर्ग इतर मॉड्यूल्समधून थेट वापरले जात नाहीत हे तपासण्यासाठी.

जोड 1: हे सर्व कसे चालवायचे आणि डीबग कसे करायचे?

लेखात कठपुतळी कोडची अनेक उदाहरणे आहेत, परंतु हा कोड कसा चालवायचा हे आम्हाला अजिबात सांगितले नाही. बरं, मी स्वतःला सुधारत आहे.

पपेट चालवण्यासाठी एजंट पुरेसा आहे, परंतु बर्याच बाबतीत तुम्हाला सर्व्हरची देखील आवश्यकता असेल.

एजंट

किमान आवृत्ती XNUMX पासून, कठपुतळी-एजंट संकुल पासून अधिकृत Puppetlabs भांडार सर्व अवलंबित्व (रुबी आणि संबंधित रत्ने) समाविष्ट आहेत, त्यामुळे इंस्टॉलेशन अडचणी नाहीत (मी डेबियन-आधारित वितरणांबद्दल बोलत आहे - आम्ही 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%आम्ही कठपुतळी कोड कसा लिहितो: इन्स्ट्रुमेंटेशन, डॉक्युमेंटेशन, टेस्टिंग, CI/CD.18

22 वापरकर्त्यांनी मतदान केले. 9 वापरकर्ते दूर राहिले.

स्त्रोत: www.habr.com

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

मुलभूत माहिती

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

वाक्यरचना आणि कोडशैली

पॅपेटसर्व्हरवरील फाइल्सचे स्थान

लढाऊ उदाहरणे दोन

त्यावरील नोड आणि संसाधनाचे वर्णन

नोडवरील संसाधनांमधील संबंध

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

फाइल

पॅकेज

सेवा

exec

क्रोन

सर्वसाधारणपणे संसाधनांबद्दल

संसाधनाच्या विशिष्टतेसाठी आवश्यकता

मेटापॅरामीटर्स

संसाधनांचे दुवे

अवलंबित्व आणि सूचना

अनिर्दिष्ट पॅरामीटर्स हाताळणे

वर्ग, चल आणि व्याख्यांचा परिचय

वर्ग

चल

वर्ग: वर्गनाम वि वर्ग{'classname':} समाविष्ट करा

व्याख्या करतो

वर्ग आणि व्याख्यांसाठी अवलंबन आणि अधिसूचना

सशर्त विधाने आणि निवडकर्ते

if

जोपर्यंत तो

केस

निवडकर्ते

मॉड्यूल्स

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

मॉड्यूलमधील संसाधनांची नावे आणि फाइल्सची नावे

नमुने

थोडक्यात ERB बद्दल

टेम्पलेट वापरण्याचे उदाहरण

तथ्ये आणि अंगभूत चल

एक्झिक्युटेबल फाइल्सच्या स्वरूपात तथ्ये

रुबी तथ्ये

मजकूर तथ्ये

तथ्यांकडे जाणे

अंगभूत व्हेरिएबल्स

जोड 1: हे सर्व कसे चालवायचे आणि डीबग कसे करायचे?

एजंट

Сервер

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

निष्कर्ष