मी इतर लोकांच्या उत्तरदायी कोडचे बरेच पुनरावलोकन करतो आणि स्वतः बरेच काही लिहितो. चुकांचे विश्लेषण करताना (इतर लोकांच्या आणि माझ्या स्वतःच्या), तसेच अनेक मुलाखती, मला उत्तरदायी वापरकर्त्यांनी केलेली मुख्य चूक लक्षात आली - ते मूलभूत गोष्टींवर प्रभुत्व न मिळवता जटिल गोष्टींमध्ये प्रवेश करतात.

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

वाचकांची अपेक्षित पातळी अशी आहे की यमलाच्या कित्येक हजार ओळी आधीच लिहिल्या गेल्या आहेत, काहीतरी आधीच तयार आहे, परंतु "कसे तरी सर्व काही कुटिल आहे."

नावे

उत्तरदायी वापरकर्त्याने केलेली मुख्य चूक म्हणजे काहीतरी काय म्हणतात हे माहित नसणे. तुम्हाला नावे माहीत नसल्यास, दस्तऐवजात काय म्हटले आहे ते तुम्ही समजू शकत नाही. एक जिवंत उदाहरण: एका मुलाखतीदरम्यान, एक व्यक्ती ज्याला असे वाटते की त्याने उत्तरेमध्ये बरेच काही लिहिले आहे, "प्लेबुकमध्ये कोणते घटक असतात?" या प्रश्नाचे उत्तर देऊ शकत नाही. आणि जेव्हा मी असे सुचवले की "प्लेबुकमध्ये नाटकाचा समावेश आहे असे उत्तर अपेक्षित होते," तेव्हा "आम्ही ते वापरत नाही" अशी निंदनीय टिप्पणी आली. लोक पैशासाठी उत्तर लिहितात आणि नाटक वापरत नाहीत. ते प्रत्यक्षात ते वापरतात, परंतु ते काय आहे हे माहित नाही.

तर चला सोप्या गोष्टीपासून सुरुवात करूया: त्याला काय म्हणतात? कदाचित तुम्हाला हे माहित असेल किंवा कदाचित तुम्हाला नसेल, कारण तुम्ही दस्तऐवज वाचता तेव्हा तुम्ही लक्ष दिले नाही.

उत्तरदायी-प्लेबुक प्लेबुक कार्यान्वित करते. प्लेबुक ही 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 वर "x" कार्य करण्यासाठी तुम्हाला यजमान Y वर जावे लागेल आणि तेथे "y" करावे लागेल, तुम्हाला एक सोपा व्यायाम करावा लागेल: जा आणि नाटक लिहा, जे होस्ट Y वर y करते. "x" मध्ये काहीतरी जोडू नका, परंतु ते सुरवातीपासून लिहा. जरी हार्डकोड व्हेरिएबल्ससह.

असे दिसते की वरील परिच्छेदातील सर्व काही बरोबर सांगितले आहे. पण हे तुमचे केस नाही! कारण तुम्हाला पुन्हा वापरता येण्याजोगा कोड लिहायचा आहे जो DRY आणि लायब्ररीसारखा आहे आणि तुम्हाला तो कसा करायचा याची पद्धत शोधण्याची गरज आहे.

इथेच आणखी एक गंभीर चूक घडते. एक त्रुटी ज्यामुळे बर्‍याच प्रकल्पांना सुसह्यपणे लिहिलेले (ते चांगले असू शकते, परंतु सर्वकाही कार्य करते आणि पूर्ण करणे सोपे आहे) संपूर्ण भयपटात बदलले जे लेखक देखील शोधू शकत नाहीत. हे कार्य करते, परंतु देव तुम्हाला काहीही बदलण्यास मनाई करतो.

त्रुटी आहे: भूमिका एक लायब्ररी कार्य आहे. या साधर्म्याने अनेक चांगल्या सुरुवातींचा नाश केला आहे की ते पाहणे केवळ वाईट आहे. भूमिका लायब्ररी फंक्शन नाही. ती आकडेमोड करू शकत नाही आणि ती प्ले-स्तरीय निर्णय घेऊ शकत नाही. मला आठवण करून द्या की नाटक कोणते निर्णय घेते?

धन्यवाद, तुम्ही बरोबर आहात. कोणत्या यजमानांवर कोणती कार्ये आणि भूमिका पार पाडायच्या याबद्दल प्ले निर्णय घेते (अधिक अचूकपणे, त्यात माहिती असते).

जर तुम्ही हा निर्णय एखाद्या भूमिकेवर सोपवलात, आणि मोजणी करूनही, तुम्ही स्वतःला (आणि जो तुमचा कोड पार्स करण्याचा प्रयत्न करेल) दयनीय अस्तित्वात आणता. भूमिका कुठे करायची हे ठरवत नाही. हा निर्णय नाटकाद्वारे घेतला जातो. भूमिका तिला जे सांगितले जाते, जिथे सांगितले जाते ते करते.

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

स्क्वॅमिशसाठी टीप: भूमिका नक्कीच नियंत्रण प्रवाहावर प्रभाव टाकू शकते. खा delegate_to आणि त्याचे वाजवी उपयोग आहेत. खा meta: end host/play. परंतु! लक्षात ठेवा आम्ही मूलभूत शिकवतो? बद्दल विसरलो delegate_to. आम्ही सर्वात सोप्या आणि सर्वात सुंदर उत्तरदायी कोडबद्दल बोलत आहोत. जे वाचायला सोपे, लिहायला सोपे, डीबग करायला सोपे, चाचणी करायला सोपे आणि पूर्ण करायला सोपे आहे. तर, पुन्हा एकदा:

प्ले आणि फक्त प्ले हे ठरवते की कोणते होस्ट काय चालवायचे.

या विभागात, आम्ही नाटक आणि भूमिका यांच्यातील विरोधाचा सामना केला. आता टास्क वि रोल रिलेशनशिपबद्दल बोलूया.

कार्ये आणि भूमिका

खेळाचा विचार करा:

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

समजा तुम्हाला foo करणे आवश्यक आहे. आणि असे दिसते foo: name=foobar state=present. मी हे कुठे लिहू? पूर्व मध्ये? पोस्ट? भूमिका तयार करायची?

...आणि कामे कुठे गेली?

आम्ही पुन्हा मूलभूत गोष्टींसह प्रारंभ करत आहोत - प्ले डिव्हाइस. आपण या समस्येवर फ्लोट केल्यास, आपण इतर सर्व गोष्टींसाठी एक आधार म्हणून प्ले वापरू शकत नाही आणि आपला परिणाम "अचल" होईल.

प्ले डिव्हाइस: होस्ट डायरेक्टिव्ह, स्वतः प्ले करण्यासाठी सेटिंग्ज आणि pre_tasks, कार्ये, भूमिका, post_tasks विभाग. खेळासाठीचे उर्वरित पॅरामीटर्स आता आमच्यासाठी महत्त्वाचे नाहीत.

कार्ये आणि भूमिकांसह त्यांच्या विभागांचा क्रम: 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, परंतु जर आपण नाटकातील विभागांच्या अंमलबजावणीच्या क्रमावर अवलंबून राहू शकतो तर आपल्याला फ्लश_हँडलर्सची आवश्यकता का आहे? शिवाय, meta: flush_handlers चा वापर आपल्याला डुप्लिकेट हँडलर्ससह अनपेक्षित गोष्टी देऊ शकतो, वापरताना आपल्याला विचित्र चेतावणी देऊ शकतो when у block इ. तुम्हाला उत्तरदायी गोष्टी जितक्या चांगल्या प्रकारे माहित असतील तितक्या अधिक बारकावे तुम्ही “कठीण” उपायासाठी नाव देऊ शकता. आणि एक सोपा उपाय - पूर्व/भूमिका/पोस्ट मधील नैसर्गिक विभागणी वापरून - बारकावे आणत नाहीत.

आणि, आमच्या 'फू' वर परत. मी कुठे ठेवू? पूर्व, पोस्ट किंवा भूमिकांमध्ये? अर्थात, हे आम्हाला foo साठी हँडलरच्या निकालांची आवश्यकता आहे की नाही यावर अवलंबून आहे. ते तेथे नसल्यास, foo ला पूर्व किंवा पोस्टमध्ये ठेवण्याची आवश्यकता नाही - या विभागांचा विशेष अर्थ आहे - कोडच्या मुख्य भागाच्या आधी आणि नंतर कार्ये चालवणे.

आता "भूमिका किंवा कार्य" या प्रश्नाचे उत्तर आधीपासून सुरू असलेल्या गोष्टींवर येते - जर तेथे कार्ये असतील तर तुम्हाला ती कार्यांमध्ये जोडण्याची आवश्यकता आहे. भूमिका असल्यास, तुम्हाला भूमिका तयार करणे आवश्यक आहे (अगदी एका कार्यातूनही). मी तुम्हाला आठवण करून देतो की कार्ये आणि भूमिका एकाच वेळी वापरल्या जात नाहीत.

Ansible च्या मूलभूत गोष्टी समजून घेतल्याने चवीच्या वरवरच्या प्रश्नांची वाजवी उत्तरे मिळतात.

कार्ये आणि भूमिका (भाग दोन)

आता जेव्हा तुम्ही प्लेबुक लिहायला सुरुवात करता तेव्हा परिस्थितीवर चर्चा करूया. तुम्हाला foo, bar आणि baz बनवणे आवश्यक आहे. ही तीन कामे, एक भूमिका की तीन भूमिका? प्रश्नाचा सारांश देण्यासाठी: आपण कोणत्या टप्प्यावर भूमिका लिहायला सुरुवात करावी? जेव्हा तुम्ही टास्क लिहू शकता तेव्हा भूमिका लिहिण्यात काय अर्थ आहे?... भूमिका म्हणजे काय?

सर्वात मोठी चूक (मी याबद्दल आधीच बोललो आहे) म्हणजे भूमिका ही प्रोग्रामच्या लायब्ररीतील फंक्शनसारखी असते. जेनेरिक फंक्शनचे वर्णन कसे दिसते? हे इनपुट युक्तिवाद स्वीकारते, साइड कारणांशी संवाद साधते, साइड इफेक्ट्स करते आणि मूल्य परत करते.

आता, लक्ष. या भूमिकेतून काय करता येईल? साइड इफेक्ट्स कॉल करण्यासाठी तुमचे नेहमीच स्वागत आहे, हे संपूर्ण उत्तराचे सार आहे - साइड इफेक्ट्स तयार करणे. साइड कारणे आहेत? प्राथमिक. परंतु "एक मूल्य पास करा आणि ते परत करा" सह - तिथेच ते कार्य करत नाही. प्रथम, आपण एखाद्या भूमिकेसाठी मूल्य देऊ शकत नाही. तुम्ही भूमिकेसाठी vars विभागात खेळाच्या आजीवन आकारासह जागतिक चल सेट करू शकता. तुम्ही भूमिकेत आजीवन खेळासह ग्लोबल व्हेरिएबल सेट करू शकता. किंवा अगदी प्लेबुक्सच्या आयुष्यासह (set_fact/register). परंतु आपल्याकडे "स्थानिक चल" असू शकत नाही. आपण "मूल्य घेऊ" आणि "ते परत" करू शकत नाही.

यावरून मुख्य गोष्ट पुढे येते: साइड इफेक्ट्स झाल्याशिवाय तुम्ही Ansible मध्ये काहीतरी लिहू शकत नाही. ग्लोबल व्हेरिएबल्स बदलणे हा फंक्शनसाठी नेहमीच दुष्परिणाम असतो. गंज मध्ये, उदाहरणार्थ, जागतिक चल बदलणे आहे unsafe. आणि Ansible मध्ये भूमिकेसाठी मूल्यांवर प्रभाव टाकण्याची एकमेव पद्धत आहे. वापरलेल्या शब्दांची नोंद घ्या: "भूमिकेसाठी मूल्य द्या" नाही तर "भूमिका वापरत असलेली मूल्ये बदला". भूमिकांमध्ये वेगळेपणा नाही. कार्ये आणि भूमिकांमध्ये वेगळेपणा नाही.

एकूण: भूमिका हे कार्य नाही.

भूमिकेबद्दल काय चांगले आहे? प्रथम, भूमिकेची डीफॉल्ट मूल्ये आहेत (/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:

भूमिकेचे हँडलर्स rolename/handlers/main.yaml मध्ये स्थित आहेत. हँडलर्स सर्व प्ले सहभागींमध्‍ये गोंधळ घालतात: प्री/पोस्‍ट_टास्क रोल हँडलर्सला खेचू शकतात आणि रोल हँडलर्सना नाटकातून खेचू शकतात. तथापि, हँडलरला "क्रॉस-रोल" कॉलमुळे क्षुल्लक हँडलरची पुनरावृत्ती करण्यापेक्षा जास्त wtf होते. (सर्वोत्तम पद्धतींचा आणखी एक घटक म्हणजे हँडलरच्या नावांची पुनरावृत्ती न करण्याचा प्रयत्न करणे).

मुख्य फरक असा आहे की कार्य नेहमी (आदर्शपणे) केले जाते (प्लस/मायनस टॅग आणि when), आणि हँडलर - राज्य बदलानुसार (ते बदलले असल्यासच आग सूचित करा). याचा अर्थ काय? उदाहरणार्थ, जेव्हा आपण रीस्टार्ट करता तेव्हा, जर काही बदलले नसेल तर तेथे कोणतेही हँडलर नसेल. जनरेटिंग टास्कमध्ये कोणताही बदल नसताना आम्हाला हँडलर कार्यान्वित करण्याची आवश्यकता का असू शकते? उदाहरणार्थ, कारण काहीतरी तुटले आणि बदलले, परंतु अंमलबजावणी हँडलरपर्यंत पोहोचली नाही. उदाहरणार्थ, नेटवर्क तात्पुरते बंद असल्याने. कॉन्फिगरेशन बदलले आहे, सेवा रीस्टार्ट झाली नाही. पुढच्या वेळी तुम्ही ते सुरू केल्यावर, कॉन्फिगरेशन यापुढे बदलणार नाही आणि सेवा कॉन्फिगच्या जुन्या आवृत्तीसह राहते.

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

हँडलरचा आणखी एक सकारात्मक गुणधर्म म्हणजे तो आउटपुट बंद करत नाही. कोणतेही बदल नाहीत - आउटपुटमध्ये कोणतेही अतिरिक्त वगळलेले किंवा ठीक नाही - वाचण्यास सोपे. हे देखील एक नकारात्मक गुणधर्म आहे - जर तुम्हाला पहिल्याच रनवर रेखीयरित्या अंमलात आणलेल्या टास्कमध्ये टायपो आढळल्यास, हँडलर बदलल्यावरच कार्यान्वित केले जातील, म्हणजे. काही परिस्थितींमध्ये - फार क्वचितच. उदाहरणार्थ, पाच वर्षांनंतर माझ्या आयुष्यात पहिल्यांदा. आणि, अर्थातच, नावात एक टायपो होईल आणि सर्वकाही खंडित होईल. आणि तुम्ही त्यांना दुसऱ्यांदा न चालवल्यास, त्यात कोणताही बदल होणार नाही.

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

...म्हणून हँडलर्स हे वाटतात त्यापेक्षा खूपच कमी उपयुक्त आणि जास्त समस्याप्रधान आहेत. आपण हँडलर्सशिवाय (फ्रिलशिवाय) काहीतरी सुंदर लिहू शकत असल्यास, त्यांच्याशिवाय ते करणे चांगले आहे. जर ते सुंदरपणे कार्य करत नसेल तर ते त्यांच्याबरोबर चांगले आहे.

गंजलेल्या वाचकाने बरोबर नमूद केले आहे की आम्ही चर्चा केलेली नाही listenएक हँडलर दुसर्‍या हँडलरला सूचित करू शकतो, की हँडलर import_tasks समाविष्ट करू शकतो (जो समाविष्ट_role with_items करू शकतो), की Ansible मधील हँडलर सिस्टीम ट्युरिंग-पूर्ण आहे, की समावेश_रोल मधील हँडलर प्लेमधील हँडलर्ससह उत्सुकतेने एकमेकांना छेदतात, इ. डी. - हे सर्व स्पष्टपणे "मूलभूत" नाही).

जरी एक विशिष्ट WTF आहे जे प्रत्यक्षात एक वैशिष्ट्य आहे जे आपण लक्षात ठेवणे आवश्यक आहे. जर आपले कार्य यासह कार्यान्वित केले असेल delegate_to आणि त्यास सूचित केले आहे, त्यानंतर संबंधित हँडलरशिवाय कार्यान्वित केले जाते delegate_to, म्हणजे होस्टवर जेथे नाटक नियुक्त केले आहे. (जरी हँडलरला नक्कीच असेल delegate_to त्याच).

स्वतंत्रपणे, मला पुन्हा वापरता येण्याजोग्या भूमिकांबद्दल काही शब्द सांगायचे आहेत. संग्रह दिसण्यापूर्वी, अशी कल्पना होती की आपण सार्वत्रिक भूमिका करू शकता जे असू शकते ansible-galaxy install आणि गेला. सर्व परिस्थितींमध्ये सर्व प्रकारांच्या सर्व OS वर कार्य करते. तर, माझे मत: ते कार्य करत नाही. वस्तुमान असलेली कोणतीही भूमिका include_vars, 100500 केसेसला समर्थन देणारे, कॉर्नर केस बग्सच्या अथांगतेसाठी नशिबात आहे. ते मोठ्या चाचणीसह संरक्षित केले जाऊ शकतात, परंतु कोणत्याही चाचणीप्रमाणे, एकतर तुमच्याकडे इनपुट मूल्यांचे कार्टेशियन उत्पादन आणि एकूण कार्य आहे किंवा तुम्ही "वैयक्तिक परिस्थिती कव्हर केलेले" आहेत. माझे मत असे आहे की भूमिका रेखीय असल्यास ते अधिक चांगले आहे (सायक्लोमॅटिक कॉम्प्लेक्सिटी 1).

कमी ifs (स्पष्ट किंवा घोषणात्मक - फॉर्ममध्ये when किंवा फॉर्म include_vars व्हेरिएबल्सच्या संचानुसार), भूमिका जितकी चांगली. काहीवेळा आपल्याला शाखा बनवाव्या लागतात, परंतु, मी पुन्हा सांगतो, जितके कमी असतील तितके चांगले. त्यामुळे आकाशगंगा (ते कार्य करते!) सह एक चांगली भूमिका असल्यासारखे दिसते when पाच कार्यांमधून "स्वतःच्या" भूमिकेपेक्षा कमी श्रेयस्कर असू शकते. जेव्हा आपण काहीतरी लिहायला सुरुवात करता तेव्हा गॅलेक्सीसह भूमिका अधिक चांगली असते. जेव्हा ते खराब होते तो क्षण म्हणजे जेव्हा एखादी गोष्ट तुटते आणि तुम्हाला अशी शंका येते की ते "आकाशगंगासोबतच्या भूमिकेमुळे" आहे. तुम्ही ते उघडा आणि त्यात पाच समावेश, आठ टास्क शीट आणि एक स्टॅक आहे when'ओव्ह... आणि आपल्याला हे शोधून काढण्याची गरज आहे. 5 कार्यांऐवजी, एक रेखीय सूची ज्यामध्ये खंडित करण्यासाठी काहीही नाही.

पुढील भागांमध्ये

• इन्व्हेंटरी, ग्रुप व्हेरिएबल्स, host_group_vars प्लगइन, hostvars बद्दल थोडेसे. स्पॅगेटीसह गॉर्डियन गाठ कशी बांधायची. व्याप्ती आणि प्राधान्य व्हेरिएबल्स, उत्तरदायी मेमरी मॉडेल. "तर आम्ही डेटाबेससाठी वापरकर्तानाव कोठे संग्रहित करू?"
• jinja: {{ jinja }} — nosql notype nosense सॉफ्ट प्लास्टिसिन. हे सर्वत्र आहे, जिथे तुम्हाला त्याची अपेक्षा नाही. बद्दल थोडे !!unsafe आणि स्वादिष्ट यम्ल.

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