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

यो सार्वभौमिक अन्यायलाई सच्याउन, मैले पहिले नै थाहा पाउनेहरूका लागि 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 मा प्रोग्राम गर्न खतरनाक छ र किन कोबोल Ansible भन्दा राम्रो छ हामी चर र jinja बारे अध्याय मा कुरा गर्नेछौं। अहिलेको लागि, एउटा कुरा भनौं - तपाइँको प्रत्येक गणनाले विश्वव्यापी चरहरूमा परिवर्तनहरूको अमिट ट्रेस छोड्छ, र तपाइँ यसको बारेमा केहि गर्न सक्नुहुन्न। दुई "ट्रेस" एकछिन हुने बित्तिकै, सबै कुरा गयो।

स्क्विमिशको लागि नोट: भूमिकाले निश्चित रूपमा नियन्त्रण प्रवाहलाई प्रभाव पार्न सक्छ। खानुहोस् 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, तर हामीलाई किन flush_handlers चाहिन्छ यदि हामी खेलमा खण्डहरूको कार्यान्वयनको क्रममा भर पर्न सक्छौं? यसबाहेक, meta: flush_handlers को प्रयोगले हामीलाई डुप्लिकेट ह्यान्डलरहरूको साथमा अप्रत्याशित चीजहरू दिन सक्छ, प्रयोग गर्दा हामीलाई अनौठो चेतावनी दिन्छ। when у block आदि तपाईलाई जवाफदेहिता जति राम्रोसँग थाहा छ, तपाईले "ठुलो" समाधानको लागि नाम दिन सक्नुहुन्छ। र एक सरल समाधान - पूर्व/भूमिका/पोस्ट बीचको प्राकृतिक विभाजन प्रयोग गरेर - बारीकनहरू उत्पन्न गर्दैन।

र, हाम्रो 'foo' मा फर्कनुहोस्। मैले यसलाई कहाँ राख्नु पर्छ? पूर्व, पद वा भूमिकामा? जाहिर छ, यो हामीलाई foo को लागि ह्यान्डलर को नतिजा चाहिन्छ कि मा निर्भर गर्दछ। यदि तिनीहरू त्यहाँ छैनन् भने, foo लाई पूर्व वा पोस्टमा राख्न आवश्यक छैन - यी खण्डहरूको विशेष अर्थ छ - कोडको मुख्य भाग अघि र पछि कार्यहरू कार्यान्वयन गर्ने।

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

Ansible को आधारभूत कुराहरू बुझ्दा स्वादको जस्तो देखिने प्रश्नहरूको उचित जवाफ दिन्छ।

कार्य र भूमिका (भाग दुई)

अब तपाई प्लेबुक लेख्न थाल्नुभएको बेलाको अवस्थाबारे छलफल गरौं। तपाईंले foo, bar र baz बनाउनु पर्छ। के यी तीन कार्य, एक भूमिका वा तीन भूमिका? प्रश्न संक्षेपमा: कुन बिन्दुमा तपाइँ भूमिका लेख्न सुरु गर्नुपर्छ? जब तपाईं कार्यहरू लेख्न सक्नुहुन्छ भूमिका लेख्नुको अर्थ के हो?... भूमिका के हो?

सबैभन्दा ठूलो गल्तीहरू मध्ये एक (मैले पहिले नै यसको बारेमा कुरा गरेको छु) यो सोच्नु हो कि भूमिका एक कार्यक्रमको पुस्तकालयमा एक प्रकार्य जस्तै हो। जेनेरिक प्रकार्य विवरण कस्तो देखिन्छ? यसले इनपुट तर्कहरू स्वीकार गर्दछ, साइड कारणहरूसँग अन्तर्क्रिया गर्छ, साइड इफेक्टहरू गर्छ, र मान फर्काउँछ।

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

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

कुल: भूमिका कुनै प्रकार्य होइन.

भूमिकाको बारेमा के राम्रो छ? पहिलो, भूमिकामा पूर्वनिर्धारित मानहरू छन् (/default/main.yaml), दोस्रो, भूमिकामा फाइलहरू भण्डारण गर्नका लागि अतिरिक्त डाइरेक्टरीहरू छन्।

पूर्वनिर्धारित मानहरूको फाइदाहरू के हुन्? किनभने मास्लोको पिरामिडमा, Ansible को चर प्राथमिकताहरूको बरु विकृत तालिका, भूमिका पूर्वनिर्धारितहरू सबैभन्दा कम प्राथमिकताहरू हुन् (माइनस Ansible कमाण्ड लाइन प्यारामिटरहरू)। यसको मतलब यो हो कि यदि तपाईंलाई पूर्वनिर्धारित मानहरू प्रदान गर्न आवश्यक छ र तिनीहरूलाई सूची वा समूह चरबाट मानहरू ओभरराइड गर्ने बारे चिन्ता नगर्नुहोस्, तब भूमिका पूर्वनिर्धारितहरू मात्र तपाईंको लागि सही ठाउँ हो। (म थोरै झूट बोल्दै छु - त्यहाँ धेरै छन् |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 मा अवस्थित छन्। ह्यान्डलरहरू सबै प्ले सहभागीहरू बीचको रमझम: pre/post_tasks ले भूमिका ह्यान्डलरहरूलाई तान्न सक्छ, र भूमिकाले ह्यान्डलरहरूलाई नाटकबाट तान्न सक्छ। यद्यपि, ह्यान्डलरहरूलाई "क्रस-रोल" कलहरूले तुच्छ ह्यान्डलर दोहोर्याउनु भन्दा धेरै wtf निम्त्याउँछ। (उत्तम अभ्यासहरूको अर्को तत्व भनेको ह्यान्डलर नामहरू दोहोर्याउने प्रयास नगर्नु हो)।

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

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

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

अलग रूपमा, हामीले चरहरूको उपलब्धताको बारेमा कुरा गर्न आवश्यक छ। उदाहरणका लागि, यदि तपाईंले लूपको साथ कार्यलाई सूचित गर्नुभयो भने, चरहरूमा के हुनेछ? तपाईं विश्लेषणात्मक रूपमा अनुमान गर्न सक्नुहुन्छ, तर यो सधैं मामूली हुँदैन, विशेष गरी यदि चरहरू विभिन्न ठाउँहरूबाट आउँछन्।

... त्यसैले ह्यान्डलरहरू धेरै कम उपयोगी छन् र तिनीहरूले जस्तो देखिने भन्दा धेरै समस्याग्रस्त छन्। यदि तपाइँ ह्यान्डलरहरू बिना (फ्रिलहरू बिना) राम्रोसँग केहि लेख्न सक्नुहुन्छ भने, यो तिनीहरू बिना गर्न राम्रो छ। यदि यो राम्रोसँग काम गर्दैन भने, यो तिनीहरूसँग राम्रो छ।

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

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

अलग रूपमा, म पुन: प्रयोज्य भूमिकाहरूको बारेमा केही शब्दहरू भन्न चाहन्छु। सङ्ग्रहहरू देखा पर्नु अघि, त्यहाँ एउटा विचार थियो कि तपाईंले विश्वव्यापी भूमिकाहरू बनाउन सक्नुहुन्छ जुन हुन सक्छ ansible-galaxy install र गए। सबै परिस्थितिहरूमा सबै भेरियन्टहरूको सबै OS मा काम गर्दछ। त्यसैले, मेरो विचार: यसले काम गर्दैन। मास संग कुनै पनि भूमिका include_vars, 100500 मामिलाहरूलाई समर्थन गर्दै, कुना केस बगहरूको अगाध ठाउँमा बर्बाद छ। तिनीहरू ठूलो परीक्षणको साथ कभर गर्न सकिन्छ, तर कुनै पनि परीक्षणको रूपमा, या त तपाईंसँग इनपुट मानहरूको कार्टेसियन उत्पादन र कुल प्रकार्य छ, वा तपाईंसँग "व्यक्तिगत परिदृश्यहरू कभर गरिएको छ।" मेरो विचार यो छ कि यो धेरै राम्रो छ यदि भूमिका रैखिक छ (cyclomatic जटिलता 1)।

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

निम्न भागहरूमा

• सूची, समूह चर, host_group_vars प्लगइन, hostvars बारे थोरै। स्पेगेटी संग गोर्डियन गाँठ कसरी बाँध्ने। स्कोप र अग्रता चर, उत्तरदायी मेमोरी मोडेल। "त्यसोभए हामी डाटाबेसको लागि प्रयोगकर्ता नाम कहाँ भण्डार गर्छौं?"
• jinja: {{ jinja }} - nosql notype nosense नरम प्लास्टिसिन। यो जताततै छ, जहाँ पनि तपाईले अपेक्षा नगर्नु भएको छ। बारेमा थोरै !!unsafe र स्वादिष्ट यामल।

स्रोत: www.habr.com