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

इस सार्वभौमिक अन्याय को ठीक करने के लिए, मैंने उन लोगों के लिए एन्सिबल का परिचय लिखने का निर्णय लिया जो इसे पहले से जानते हैं। मैं आपको चेतावनी देता हूं, यह मनुष्यों की पुनर्कथन नहीं है, यह एक दीर्घपाठ है जिसमें बहुत सारे अक्षर हैं और कोई चित्र नहीं है।

पाठक का अपेक्षित स्तर यह है कि यमला की कई हजार पंक्तियाँ पहले ही लिखी जा चुकी हैं, कुछ पहले से ही उत्पादन में है, लेकिन "किसी तरह सब कुछ टेढ़ा है।"

टाइटल

एक Ansible उपयोगकर्ता द्वारा की जाने वाली मुख्य गलती यह नहीं जानना है कि किसी चीज़ को क्या कहा जाता है। यदि आप नाम नहीं जानते हैं, तो आप यह नहीं समझ पाएंगे कि दस्तावेज़ क्या कहता है। एक जीवंत उदाहरण: एक साक्षात्कार के दौरान, एक व्यक्ति जो यह कहता दिख रहा था कि उसने एन्सिबल में बहुत कुछ लिखा है, वह इस सवाल का जवाब नहीं दे सका कि "प्लेबुक में कौन से तत्व शामिल होते हैं?" और जब मैंने सुझाव दिया कि "उत्तर अपेक्षित था कि प्लेबुक में खेल शामिल है," तो यह अपमानजनक टिप्पणी आई कि "हम इसका उपयोग नहीं करते हैं"। लोग पैसे के लिए Ansible लिखते हैं और प्ले का उपयोग नहीं करते हैं। वे वास्तव में इसका उपयोग करते हैं, लेकिन यह नहीं जानते कि यह क्या है।

तो आइए कुछ सरल से शुरू करें: इसे क्या कहा जाता है। हो सकता है कि आप यह जानते हों, या हो सकता है कि आप नहीं जानते हों, क्योंकि दस्तावेज़ पढ़ते समय आपने ध्यान नहीं दिया था।

ansible-playbook प्लेबुक को निष्पादित करता है। प्लेबुक yml/yaml एक्सटेंशन वाली एक फ़ाइल है, जिसके अंदर कुछ इस तरह होता है:

---
- hosts: group1
  roles:
    - role1

- hosts: group2,group3
  tasks:
    - debug:

हमें पहले ही एहसास हो गया था कि यह पूरी फ़ाइल एक प्लेबुक है। हम दिखा सकते हैं कि भूमिकाएँ कहाँ हैं और कार्य कहाँ हैं। लेकिन खेल कहाँ है? और नाटक और भूमिका या नाटकपुस्तक के बीच क्या अंतर है?

यह सब दस्तावेज़ में है. और वे इसे चूक जाते हैं. शुरुआती - क्योंकि बहुत कुछ है और आपको एक बार में सब कुछ याद नहीं रहेगा। अनुभवी - क्योंकि "तुच्छ बातें"। यदि आप अनुभवी हैं, तो हर छह महीने में कम से कम एक बार इन पृष्ठों को दोबारा पढ़ें, और आपका कोड कक्षा-अग्रणी बन जाएगा।

तो, याद रखें: प्लेबुक एक सूची है जिसमें प्ले और शामिल हैं import_playbook.
यह एक नाटक है:

- hosts: group1
  roles:
    - role1

और यह भी एक और नाटक है:

- hosts: group2,group3
  tasks:
    - debug:

खेल क्या है? वह क्यों है?

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

यदि आप "कुछ" "कहीं" प्रदर्शन करना चाहते हैं, तो आप नाटक लिखें। कोई भूमिका नहीं. मॉड्यूल और प्रतिनिधियों के साथ कोई भूमिका नहीं। आप इसे लीजिए और नाटक लिखिए. जिसमें, होस्ट फ़ील्ड में आप सूचीबद्ध करते हैं कि कहां निष्पादित करना है, और भूमिकाओं/कार्यों में - क्या निष्पादित करना है।

सरल, सही? यह अन्यथा कैसे हो सकता है?

विशिष्ट क्षणों में से एक जब लोगों को खेल के माध्यम से ऐसा करने की इच्छा नहीं होती है तो वह है "भूमिका जो सब कुछ निर्धारित करती है।" मैं एक ऐसी भूमिका चाहता हूँ जो पहले प्रकार के सर्वर और दूसरे प्रकार के सर्वर दोनों को कॉन्फ़िगर करे।

एक आदर्श उदाहरण निगरानी है. मैं एक निगरानी भूमिका चाहता हूं जो निगरानी को कॉन्फ़िगर करेगी। निगरानी की भूमिका निगरानी मेजबानों को सौंपी गई है (खेल के अनुसार)। लेकिन यह पता चला है कि निगरानी के लिए हमें उन मेजबानों को पैकेज वितरित करने की आवश्यकता है जिनकी हम निगरानी कर रहे हैं। प्रतिनिधि का उपयोग क्यों नहीं करें? आपको iptables को भी कॉन्फ़िगर करना होगा. प्रतिनिधि? मॉनिटरिंग को सक्षम करने के लिए आपको DBMS के लिए एक कॉन्फिगरेशन लिखने/सही करने की भी आवश्यकता है। प्रतिनिधि! और अगर क्रिएटिविटी की कमी है तो आप एक डेलिगेशन बना सकते हैं include_role समूहों की सूची पर और अंदर एक ट्रिकी फ़िल्टर का उपयोग करके नेस्टेड लूप में include_role आप और अधिक कर सकते हैं delegate_to दोबारा। और हम चले जाते हैं...

एक अच्छी इच्छा - एक एकल निगरानी भूमिका हो, जो "सबकुछ करती है" - हमें पूर्ण नरक में ले जाती है, जहां से निकलने का अक्सर एक ही रास्ता होता है: सब कुछ नए सिरे से लिखना।

यहां गलती कहां हुई? जैसे ही आपको पता चला कि होस्ट "x" में कुछ न जोड़ें, बल्कि इसे शुरुआत से लिखें। यहां तक ​​कि हार्डकोडेड वेरिएबल्स के साथ भी।

ऐसा लगता है कि उपरोक्त पैराग्राफ में सब कुछ सही कहा गया है। लेकिन यह आपका मामला नहीं है! क्योंकि आप पुन: प्रयोज्य कोड लिखना चाहते हैं जो DRY और लाइब्रेरी जैसा है, और आपको इसे कैसे करना है इसके लिए एक विधि की तलाश करनी होगी।

यहीं पर एक और गंभीर गलती छिपी हुई है। एक त्रुटि जिसने कई परियोजनाओं को सहनीय रूप से लिखा (यह बेहतर हो सकता है, लेकिन सब कुछ काम करता है और समाप्त करना आसान है) को पूरी तरह से भयावह बना दिया, यहां तक ​​​​कि लेखक भी इसका पता नहीं लगा सका। यह काम करता है, लेकिन भगवान न करे कि आप कुछ भी बदलें।

त्रुटि यह है: भूमिका एक लाइब्रेरी फ़ंक्शन है। इस सादृश्य ने इतनी सारी अच्छी शुरुआतों को बर्बाद कर दिया है कि यह देखकर बहुत दुख होता है। भूमिका कोई लाइब्रेरी फ़ंक्शन नहीं है. वह गणना नहीं कर सकती और खेल-स्तर पर निर्णय नहीं ले सकती। मुझे याद दिलाएं कि खेल क्या निर्णय लेता है?

धन्यवाद, आप सही हैं. प्ले यह निर्णय लेता है (अधिक सटीक रूप से, इसमें जानकारी होती है) कि किस होस्ट पर कौन से कार्य और भूमिकाएँ निभानी हैं।

यदि आप इस निर्णय को किसी भूमिका में सौंपते हैं, और यहां तक ​​कि गणनाओं के साथ भी, तो आप स्वयं को (और वह जो आपके कोड को पार्स करने का प्रयास करेगा) एक दयनीय अस्तित्व के लिए बर्बाद कर देते हैं। भूमिका यह तय नहीं करती कि उसे कहां निभाया जाए। यह निर्णय खेल द्वारा किया जाता है. भूमिका वही करती है जो उसे बताया जाता है, जहां उसे बताया जाता है।

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

व्यंग्यकारों के लिए ध्यान दें: भूमिका निश्चित रूप से नियंत्रण प्रवाह को प्रभावित कर सकती है। खाओ delegate_to और इसका उचित उपयोग है। खाओ meta: end host/play. लेकिन! याद रखें हम बुनियादी बातें पढ़ाते हैं? के बारे में भूल गया delegate_to. हम सबसे सरल और सबसे सुंदर Ansible कोड के बारे में बात कर रहे हैं। जिसे पढ़ना आसान है, लिखना आसान है, डीबग करना आसान है, परीक्षण करना आसान है और पूरा करना आसान है। तो, एक बार फिर:

प्ले और केवल प्ले ही यह तय करता है कि किस मेजबान पर क्या क्रियान्वित किया जाएगा।

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

कार्य और भूमिकाएँ

खेलने पर विचार करें:

- hosts: somegroup
  pre_tasks:
    - some_tasks1:
  roles:
     - role1
     - role2
  post_tasks:
     - some_task2:
     - some_task3:

मान लीजिए कि आपको फू करने की ज़रूरत है। और ऐसा दिखता है foo: name=foobar state=present. मुझे यह कहां लिखना चाहिए? पूर्व में? डाक? कोई भूमिका बनाएँ?

...और कार्य कहां गए?

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

प्ले डिवाइस: होस्ट निर्देश, प्ले के लिए सेटिंग्स और प्री_टास्क, कार्य, भूमिकाएं, पोस्ट_टास्क अनुभाग। खेल के बाकी पैरामीटर अब हमारे लिए महत्वपूर्ण नहीं हैं.

कार्यों और भूमिकाओं के साथ उनके अनुभागों का क्रम: pre_tasks, roles, tasks, post_tasks. चूँकि शब्दार्थ की दृष्टि से निष्पादन का क्रम बीच का है tasks и roles स्पष्ट नहीं है, तो सर्वोत्तम प्रथाएँ कहती हैं कि हम एक अनुभाग जोड़ रहे हैं tasks, केवल यदि नहीं roles। अगर वहाँ है roles, फिर सभी संलग्न कार्यों को अनुभागों में रखा गया है pre_tasks/post_tasks.

जो कुछ बचा है वह यह है कि सब कुछ शब्दार्थ रूप से स्पष्ट है: पहला pre_tasks, तब roles, तब post_tasks.

लेकिन हमने अभी भी इस प्रश्न का उत्तर नहीं दिया है: मॉड्यूल कॉल कहां है? foo लिखना? क्या हमें प्रत्येक मॉड्यूल के लिए पूरी भूमिका लिखने की ज़रूरत है? या क्या हर चीज़ के लिए एक मोटी भूमिका रखना बेहतर है? और अगर भूमिका नहीं तो फिर कहां लिखूं-पूर्व में या बाद में?

यदि इन प्रश्नों का कोई तर्कसंगत उत्तर नहीं है, तो यह अंतर्ज्ञान की कमी का संकेत है, यानी वही "अस्थिर नींव"। आइए इसका पता लगाएं। सबसे पहले, एक सुरक्षा प्रश्न: यदि खेल है pre_tasks и post_tasks (और कोई कार्य या भूमिकाएँ नहीं हैं), यदि मैं पहला कार्य करता हूँ तो क्या कुछ टूट सकता है post_tasks मैं इसे अंत तक ले जाऊंगा pre_tasks?

निःसंदेह, प्रश्न के शब्दों से संकेत मिलता है कि यह टूट जाएगा। लेकिन वास्तव में क्या?

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

इस प्रकार, यदि आप किसी कार्य को खींचते हैं post_tasks в pre_tasks, तो संभावित रूप से आप हैंडलर निष्पादित होने से पहले इसे निष्पादित करेंगे। उदाहरण के लिए, यदि में pre_tasks वेब सर्वर स्थापित और कॉन्फ़िगर किया गया है, और post_tasks इसमें कुछ भेजा जाता है, फिर इस कार्य को अनुभाग में स्थानांतरित करें pre_tasks इस तथ्य को जन्म देगा कि "भेजने" के समय सर्वर अभी भी चालू नहीं होगा और सब कुछ टूट जाएगा।

अब आइए फिर से सोचें कि हमें इसकी आवश्यकता क्यों है pre_tasks и post_tasks? उदाहरण के लिए, भूमिका को पूरा करने से पहले आवश्यक सभी चीजें (हैंडलर सहित) पूरी करने के लिए। ए post_tasks हमें भूमिकाओं के निष्पादन (हैंडलर सहित) के परिणामों के साथ काम करने की अनुमति देगा।

एक चतुर अन्सिबल विशेषज्ञ हमें बताएगा कि यह क्या है। meta: flush_handlers, लेकिन अगर हम खेल में अनुभागों के निष्पादन के क्रम पर भरोसा कर सकते हैं तो हमें फ्लश_हैंडलर की आवश्यकता क्यों है? इसके अलावा, मेटा: फ्लश_हैंडलर का उपयोग हमें डुप्लिकेट हैंडलर के साथ अप्रत्याशित चीजें दे सकता है, उपयोग करने पर हमें अजीब चेतावनियां दे सकता है when у block वगैरह। जितना बेहतर आप उत्तर देने योग्य जानते हैं, उतनी ही अधिक बारीकियाँ आप "मुश्किल" समाधान के लिए बता सकते हैं। और एक सरल समाधान - पूर्व/भूमिकाओं/पद के बीच प्राकृतिक विभाजन का उपयोग करना - बारीकियों का कारण नहीं बनता है।

और, वापस हमारे 'फू' पर। मुझे इसे कहां रखना चाहिए? पूर्व, पद या भूमिकाओं में? जाहिर है, यह इस बात पर निर्भर करता है कि हमें फू के लिए हैंडलर के परिणामों की आवश्यकता है या नहीं। यदि वे वहां नहीं हैं, तो foo को प्री या पोस्ट में रखने की आवश्यकता नहीं है - इन अनुभागों का एक विशेष अर्थ है - कोड के मुख्य भाग से पहले और बाद में कार्यों को निष्पादित करना।

अब "भूमिका या कार्य" प्रश्न का उत्तर इस बात पर आता है कि क्या पहले से ही चल रहा है - यदि वहां कार्य हैं, तो आपको उन्हें कार्यों में जोड़ने की आवश्यकता है। यदि भूमिकाएँ हैं, तो आपको एक भूमिका बनाने की आवश्यकता है (एक कार्य से भी)। मैं आपको याद दिला दूं कि कार्यों और भूमिकाओं का उपयोग एक ही समय में नहीं किया जाता है।

एन्सिबल की मूल बातें समझने से रुचि के प्रतीत होने वाले प्रश्नों के उचित उत्तर मिलते हैं।

कार्य और भूमिकाएँ (भाग दो)

अब आइए उस स्थिति पर चर्चा करें जब आप एक प्लेबुक लिखना शुरू कर रहे हैं। आपको फू, बार और बाज़ बनाने की ज़रूरत है। क्या ये तीन कार्य, एक भूमिका या तीन भूमिकाएँ हैं? प्रश्न को संक्षेप में प्रस्तुत करने के लिए: आपको किस बिंदु पर भूमिकाएँ लिखना शुरू करना चाहिए? जब आप कार्य लिख सकते हैं तो भूमिकाएँ लिखने का क्या मतलब है?... भूमिका क्या है?

सबसे बड़ी गलतियों में से एक (मैंने पहले ही इस बारे में बात की थी) यह सोचना है कि एक भूमिका किसी प्रोग्राम की लाइब्रेरी में एक फ़ंक्शन की तरह है। सामान्य फ़ंक्शन विवरण कैसा दिखता है? यह इनपुट तर्क स्वीकार करता है, साइड कारणों के साथ इंटरैक्ट करता है, साइड इफेक्ट करता है, और एक मान लौटाता है।

अब, ध्यान दें. इससे भूमिका में क्या किया जा सकता है? साइड इफेक्ट्स को कॉल करने के लिए आपका हमेशा स्वागत है, यह संपूर्ण एन्सिबल का सार है - साइड इफेक्ट्स पैदा करना। क्या इसके कोई पार्श्व कारण हैं? प्राथमिक. लेकिन "एक मान पास करें और उसे लौटाएँ" के साथ - यह वह जगह है जहाँ यह काम नहीं करता है। सबसे पहले, आप किसी भूमिका के लिए कोई मान नहीं दे सकते। आप भूमिका के लिए vars अनुभाग में जीवनकाल के आकार के साथ एक वैश्विक चर सेट कर सकते हैं। आप भूमिका के अंदर जीवनकाल के साथ एक वैश्विक चर सेट कर सकते हैं। या यहां तक ​​कि प्लेबुक के जीवनकाल के साथ भी (set_fact/register). लेकिन आपके पास "स्थानीय चर" नहीं हो सकते। आप "मूल्य नहीं ले सकते" और "उसे वापस नहीं कर सकते"।

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

कुल: भूमिका कोई कार्य नहीं है.

भूमिका के बारे में क्या अच्छा है? सबसे पहले, भूमिका में डिफ़ॉल्ट मान होते हैं (/default/main.yaml), दूसरे, भूमिका में फ़ाइलें संग्रहीत करने के लिए अतिरिक्त निर्देशिकाएँ हैं।

डिफ़ॉल्ट मानों के क्या लाभ हैं? क्योंकि मास्लो के पिरामिड में, अंसिबल की परिवर्तनीय प्राथमिकताओं की बल्कि विकृत तालिका में, भूमिका डिफ़ॉल्ट सबसे कम-प्राथमिकता (माइनस अंसिबल कमांड लाइन पैरामीटर) हैं। इसका मतलब यह है कि यदि आपको डिफ़ॉल्ट मान प्रदान करने की आवश्यकता है और इन्वेंट्री या समूह चर से मूल्यों को ओवरराइड करने के बारे में चिंता नहीं करनी है, तो भूमिका डिफ़ॉल्ट आपके लिए एकमात्र सही जगह है। (मैं थोड़ा झूठ बोल रहा हूं - और भी बहुत कुछ है |d(your_default_here), लेकिन अगर हम स्थिर स्थानों के बारे में बात करते हैं, तो केवल भूमिका डिफ़ॉल्ट)।

भूमिकाओं के बारे में और क्या बढ़िया है? क्योंकि उनके पास अपने स्वयं के कैटलॉग हैं। ये चर के लिए निर्देशिकाएं हैं, दोनों स्थिर (यानी भूमिका के लिए गणना) और गतिशील (या तो एक पैटर्न या एक विरोधी पैटर्न है - include_vars साथ {{ ansible_distribution }}-{{ ansible_distribution_major_version }}.yml.). ये के लिए निर्देशिकाएं हैं files/, templates/. साथ ही, यह आपको अपने स्वयं के मॉड्यूल और प्लगइन्स रखने की अनुमति देता है (library/). लेकिन, प्लेबुक में कार्यों की तुलना में (जिसमें यह सब भी हो सकता है), यहां एकमात्र लाभ यह है कि फ़ाइलों को एक ढेर में नहीं, बल्कि कई अलग-अलग ढेरों में डंप किया जाता है।

एक और विवरण: आप ऐसी भूमिकाएँ बनाने का प्रयास कर सकते हैं जो पुन: उपयोग के लिए उपलब्ध होंगी (गैलेक्सी के माध्यम से)। संग्रहों के आगमन के साथ, भूमिका वितरण को लगभग भुला दिया गया माना जा सकता है।

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

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

Существует возможность делать import_role как таску, но если вы такое пишете, то будьте готовы к объяснительной для собственного чувства прекрасного, зачем вы это хотите делать.

एक चतुर पाठक कह सकता है कि भूमिकाएँ भूमिकाओं को आयात कर सकती हैं, भूमिकाओं में Galaxy.yml के माध्यम से निर्भरताएँ हो सकती हैं, और एक भयानक और भयानक भी है include_role - मैं आपको याद दिलाता हूं कि हम बेसिक एन्सिबल में कौशल में सुधार कर रहे हैं, न कि फिगर जिम्नास्टिक में।

संचालक और कार्य

आइए एक और स्पष्ट बात पर चर्चा करें: हैंडलर। इनका सही तरीके से उपयोग करना जानना लगभग एक कला है। हैंडलर और ड्रैग के बीच क्या अंतर है?

चूँकि हम मूल बातें याद कर रहे हैं, यहाँ एक उदाहरण है:

- hosts: group1
  tasks:
    - foo:
      notify: handler1
  handlers:
     - name: handler1
       bar:

भूमिका के हैंडलर, रोलनेम/हैंडलर/main.yaml में स्थित हैं। हैंडलर सभी खेल प्रतिभागियों के बीच खोजबीन करते हैं: प्री/पोस्ट_टास्क भूमिका हैंडलर को खींच सकते हैं, और एक भूमिका हैंडलर को खेल से खींच सकती है। हालाँकि, हैंडलर को "क्रॉस-रोल" कॉल एक मामूली हैंडलर को दोहराने की तुलना में बहुत अधिक wtf का कारण बनती है। (सर्वोत्तम प्रथाओं का एक अन्य तत्व हैंडलर के नामों को न दोहराने का प्रयास करना है)।

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

कॉन्फ़िगरेशन के साथ स्थिति को हल नहीं किया जा सकता है (अधिक सटीक रूप से, आप फ़ाइल फ़्लैग आदि के साथ अपने लिए एक विशेष पुनरारंभ प्रोटोकॉल का आविष्कार कर सकते हैं, लेकिन यह अब किसी भी रूप में 'बुनियादी उत्तर देने योग्य' नहीं है)। लेकिन एक और आम कहानी है: हमने एप्लिकेशन इंस्टॉल किया, उसे रिकॉर्ड किया .service-फ़ाइल, और अब हम इसे चाहते हैं daemon_reload и state=started. और इसके लिए प्राकृतिक स्थान हैंडलर ही प्रतीत होता है। लेकिन यदि आप इसे हैंडलर नहीं बल्कि किसी कार्यसूची या भूमिका के अंत में एक कार्य बनाते हैं, तो इसे हर बार निष्क्रिय रूप से निष्पादित किया जाएगा। भले ही प्लेबुक बीच में टूट जाए. यह पुनरारंभ की गई समस्या को बिल्कुल भी हल नहीं करता है (आप पुनरारंभ विशेषता के साथ कोई कार्य नहीं कर सकते, क्योंकि निष्क्रियता खो जाती है), लेकिन यह निश्चित रूप से राज्य = प्रारंभ करने लायक है, प्लेबुक की समग्र स्थिरता बढ़ जाती है, क्योंकि कनेक्शनों की संख्या और गतिशील स्थिति घट जाती है।

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

अलग से, हमें चर की उपलब्धता के बारे में बात करने की ज़रूरत है। उदाहरण के लिए, यदि आप किसी कार्य को लूप के साथ सूचित करते हैं, तो वेरिएबल्स में क्या होगा? आप विश्लेषणात्मक रूप से अनुमान लगा सकते हैं, लेकिन यह हमेशा मामूली नहीं होता है, खासकर यदि चर अलग-अलग स्थानों से आते हैं।

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

संक्षारक पाठक ठीक ही बताते हैं कि हमने चर्चा नहीं की है listenकि एक हैंडलर किसी अन्य हैंडलर के लिए सूचित करने के लिए कॉल कर सकता है, कि एक हैंडलर में आयात_कार्य (जो with_items के साथ include_role कर सकता है) शामिल हो सकता है, कि Ansible में हैंडलर सिस्टम ट्यूरिंग-पूर्ण है, कि include_role के हैंडलर खेल के हैंडलर के साथ एक जिज्ञासु तरीके से प्रतिच्छेद करते हैं, आदि.डी. - यह सब स्पष्ट रूप से "बुनियादी बातें" नहीं है)।

हालाँकि एक विशिष्ट डब्ल्यूटीएफ है जो वास्तव में एक ऐसी सुविधा है जिसे आपको ध्यान में रखना होगा। यदि आपका कार्य निष्पादित हो गया है delegate_to और इसने सूचित किया है, तो संबंधित हैंडलर को बिना निष्पादित किया जाता है delegate_to, अर्थात। होस्ट पर जहां खेल सौंपा गया है। (हालाँकि, निश्चित रूप से, हैंडलर के पास हो सकता है delegate_to वही)।

अलग से, मैं पुन: प्रयोज्य भूमिकाओं के बारे में कुछ शब्द कहना चाहता हूं। संग्रह सामने आने से पहले, एक विचार था कि आप सार्वभौमिक भूमिकाएँ बना सकते हैं जो हो सकती हैं ansible-galaxy install और चला गया। सभी स्थितियों में सभी वेरिएंट के सभी ओएस पर काम करता है। तो, मेरी राय: यह काम नहीं करता है। द्रव्यमान के साथ कोई भी भूमिका include_vars, 100500 मामलों का समर्थन करते हुए, कॉर्नर केस बग के रसातल में बर्बाद हो गया है। उन्हें बड़े पैमाने पर परीक्षण के साथ कवर किया जा सकता है, लेकिन किसी भी परीक्षण की तरह, या तो आपके पास इनपुट मानों और कुल फ़ंक्शन का कार्टेशियन उत्पाद है, या आपके पास "व्यक्तिगत परिदृश्य शामिल हैं।" मेरी राय है कि यदि भूमिका रैखिक (साइक्लोमैटिक जटिलता 1) हो तो यह बहुत बेहतर है।

फॉर्म में जितने कम ifs (स्पष्ट या घोषणात्मक) होंगे when या रूप include_vars चरों के सेट द्वारा), भूमिका उतनी ही बेहतर होगी। कभी-कभी आपको शाखाएँ बनानी पड़ती हैं, लेकिन, मैं दोहराता हूँ, जितनी कम शाखाएँ होंगी, उतना बेहतर होगा। तो ऐसा लगता है कि यह आकाशगंगा के साथ एक अच्छी भूमिका है (यह काम करती है!) when पाँच कार्यों में से "किसी की अपनी" भूमिका से कम बेहतर हो सकता है। वह क्षण जब आकाशगंगा के साथ भूमिका बेहतर होती है, जब आप कुछ लिखना शुरू करते हैं। वह क्षण जब यह बदतर हो जाता है जब कोई चीज़ टूटती है और आपको संदेह होता है कि यह "आकाशगंगा के साथ भूमिका" के कारण है। आप इसे खोलें, और इसमें पांच समावेशन, आठ कार्य पत्रक और एक स्टैक है when'ओव... और हमें इसका पता लगाने की जरूरत है। 5 कार्यों के स्थान पर एक रेखीय सूची जिसमें तोड़ने योग्य कुछ भी नहीं है।

निम्नलिखित भागों में

• इन्वेंट्री, ग्रुप वेरिएबल्स, होस्ट_ग्रुप_वर्स प्लगइन, होस्टवर्स के बारे में थोड़ा। स्पेगेटी के साथ गॉर्डियन गाँठ कैसे बाँधें। दायरा और प्राथमिकता चर, अन्सिबल मेमोरी मॉडल। "तो हम डेटाबेस के लिए उपयोगकर्ता नाम कहाँ संग्रहीत करते हैं?"
• jinja: {{ jinja }} - नोएसक्यूएल नॉटाइप नोसेंस सॉफ्ट प्लास्टिसिन। यह हर जगह है, यहां तक ​​कि जहां आप इसकी उम्मीद नहीं करते हैं। के बारे में थोड़ा !!unsafe और स्वादिष्ट यम.

स्रोत: www.habr.com