🥇Ansible का परीक्षण कैसे शुरू करें, एक साल में एक प्रोजेक्ट को दोबारा तैयार करें और पागल न हो जाएं

यह प्रतिलिपि है प्रदर्शन पर DevOps-40 2020-03-18:

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

विरासत का जन्म

दिन #1: रोगी शून्य

एक बार की बात है एक सशर्त परियोजना थी। इसमें एक देव विकास टीम और ऑप्स इंजीनियर थे। वे एक ही समस्या का समाधान कर रहे थे: सर्वर कैसे तैनात करें और एप्लिकेशन कैसे चलाएं। समस्या यह थी कि प्रत्येक टीम ने इस समस्या को अपने तरीके से हल किया। परियोजना में, देव और ऑप्स टीमों के बीच ज्ञान को सिंक्रनाइज़ करने के लिए एन्सिबल का उपयोग करने का निर्णय लिया गया।

दिन #89: विरासत का जन्म

स्वयं इस पर ध्यान दिए बिना, वे इसे यथासंभव सर्वोत्तम करना चाहते थे, लेकिन यह विरासत बन गया। ये कैसे होता है?

हमें यहां एक जरूरी काम है, आइए एक गंदा हैक करें और फिर इसे ठीक करें।
आपको दस्तावेज़ लिखने की ज़रूरत नहीं है और यहां सब कुछ स्पष्ट है कि क्या हो रहा है।
मैं अन्सिबल/पायथन/बैश/टेराफॉर्म जानता हूँ! देखो मैं कैसे बच सकता हूँ!
मैं एक पूर्ण स्टैक ओवरफ़्लो डेवलपर हूं और इसे स्टैकओवरफ़्लो से कॉपी किया है, मुझे नहीं पता कि यह कैसे काम करता है, लेकिन यह अच्छा दिखता है और समस्या का समाधान करता है।

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

- hosts: localhost
  tasks:
    - shell: echo -n Z >> a.txt && cat a.txt
      register: output
      delay: 1
      retries: 5
      until: not output.stdout.find("ZZZ")

दिन #109: समस्या के प्रति जागरूकता

प्रारंभ में कल्पना और कार्यान्वित IaC मॉडल अब उपयोगकर्ताओं/व्यवसाय/अन्य टीमों की आवश्यकताओं को पूरा नहीं करता है, और बुनियादी ढांचे में बदलाव करने का समय स्वीकार्य नहीं रह जाता है। इस समय, समझ आती है कि कार्रवाई करने का समय आ गया है।

IaC रिफैक्टरिंग

दिन #139: क्या आपको वास्तव में रिफैक्टरिंग की आवश्यकता है?

इससे पहले कि आप रिफैक्टर में भाग लें, आपको कई महत्वपूर्ण प्रश्नों का उत्तर देना होगा:

आपको यह सब क्यों चाहिए?
क्या आपके पास समय है?
क्या ज्ञान पर्याप्त है?

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

दिन #149: रिफैक्टरिंग की तैयारी

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

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

उत्तरयोग्य परीक्षण प्रयास

इससे पहले कि हम यह बताएं कि हमने परियोजना पर एन्सिबल परीक्षणों को कैसे कवर किया, मैं उन प्रयासों और दृष्टिकोणों का वर्णन करूंगा जिनका उपयोग करने का अवसर मुझे पहले लिए गए निर्णयों के संदर्भ को समझने के लिए मिला था।

दिन संख्या -997: एसडीएस प्रावधान

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

दिन # -701: एन्सिबल और टेस्ट किचन

एन्सिबल परीक्षण विचार का विकास तैयार किए गए उपकरणों का उपयोग था, अर्थात् टेस्ट किचन / किचन-सीआई और इंस्पेक। विकल्प रूबी के ज्ञान द्वारा निर्धारित किया गया था (अधिक विवरण के लिए, हैब्रे पर लेख देखें: क्या YML प्रोग्रामर Ansible का परीक्षण करने का सपना देखते हैं?) तेजी से काम किया, 40 भूमिकाओं के लिए लगभग 10 मिनट। हमने वर्चुअल मशीनों का एक पैक बनाया और उसके अंदर परीक्षण चलाया।

सामान्य तौर पर, समाधान काम करता था, लेकिन विविधता के कारण कुछ तलछट थी। जब परीक्षण किए गए लोगों की संख्या 13 मूल भूमिकाओं और छोटी भूमिकाओं को मिलाकर 2 मेटा भूमिकाओं तक बढ़ा दी गई, तो अचानक परीक्षण 70 मिनट तक चलने लगे, जो लगभग 2 गुना अधिक है। एक्सपी (एक्सट्रीम प्रोग्रामिंग) प्रथाओं के बारे में बात करना मुश्किल था क्योंकि... कोई भी 70 मिनट इंतजार नहीं करना चाहता. दृष्टिकोण बदलने का यही कारण था

दिन # -601: अन्सिबल और अणु

वैचारिक रूप से, यह टेस्टकिचन के समान है, केवल हमने भूमिका परीक्षण को डॉकर में स्थानांतरित किया और स्टैक को बदल दिया। परिणामस्वरूप, 20 भूमिकाओं के लिए समय घटकर स्थिर 25-7 मिनट रह गया।

परीक्षण की गई भूमिकाओं की संख्या बढ़ाकर 17 और 45 भूमिकाएँ जोड़कर, हमने इसे 28 जेनकींस स्लेव पर 2 मिनट में चलाया।

दिन #167: प्रोजेक्ट में एन्सिबल परीक्षण जोड़ना

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

सामान्य तौर पर, इससे कोई फर्क नहीं पड़ता कि यह कैसे किया जाएगा, आप कागज के टुकड़े पर लिख सकते हैं, आप कोठरी पर स्टिकर लगा सकते हैं, आप जिरा में कार्य बना सकते हैं, या आप Google डॉक्स खोल सकते हैं और वर्तमान स्थिति लिख सकते हैं वहाँ। पैर इस तथ्य से बढ़ते हैं कि प्रक्रिया तत्काल नहीं है, यह लंबी और थकाऊ होगी। इसकी संभावना नहीं है कि कोई चाहता हो कि आप रिफैक्टरिंग के दौरान विचारों से थक जाएं, थक जाएं और अभिभूत हो जाएं।

रिफैक्टरिंग सरल है:

खाना खा लो।
सो जाओ.
कोड।
आईएसी परीक्षण.
दोहराना

और हम इसे तब तक दोहराते हैं जब तक हम इच्छित लक्ष्य तक नहीं पहुंच जाते।

हर चीज़ का तुरंत परीक्षण शुरू करना संभव नहीं हो सकता है, इसलिए हमारा पहला काम लाइनिंग और सिंटैक्स की जाँच से शुरुआत करना था।

दिन #181: ग्रीन बिल्ड मास्टर

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

लाल परीक्षण ख़राब हैं.
मैं कुछ ठीक करने आया हूं और साथ ही कोड को आपके पहले की तुलना में थोड़ा बेहतर बनाऊंगा।

दिन #193: लाइनिंग से लेकर यूनिट परीक्षण तक

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

दिन #211: इकाई से एकीकरण परीक्षण तक

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

जेनकींस का उपयोग करते हुए, हमने कई चरण तैयार किए जो समानांतर में भूमिकाओं/प्लेबुक को रेखांकित करते हैं, फिर कंटेनरों में इकाई परीक्षण और अंत में एकीकरण परीक्षण करते हैं।

जेनकींस + डॉकर + एन्सिबल = परीक्षण

रेपो चेकआउट करें और बिल्ड चरण उत्पन्न करें।
लिंट प्लेबुक चरणों को समानांतर में चलाएँ।
लिंट रोल चरणों को समानांतर में चलाएँ।
सिंटैक्स जाँच भूमिका चरणों को समानांतर में चलाएँ।
परीक्षण भूमिका चरणों को समानांतर में चलाएँ.
1. लिंट भूमिका.
2. अन्य भूमिकाओं पर निर्भरता की जाँच करें।
3. सिंटैक्स की जाँच करें.
4. डॉकर उदाहरण बनाएं
5. अणु/डिफ़ॉल्ट/प्लेबुक.yml चलाएँ।
6. निष्क्रियता की जाँच करें.
एकीकरण परीक्षण चलाएँ
अंत

दिन #271: बस फैक्टर

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

और यह यहाँ आरामदायक होना चाहिए. समीक्षा करना सुविधाजनक है, यह देखना कि यह किस कार्य के अंतर्गत किया गया था, और चर्चाओं का इतिहास क्या है। हमने जेनकींस + बिटबकेट + जिरा को एकीकृत किया है।

लेकिन वैसे भी, समीक्षा कोई रामबाण इलाज नहीं है; किसी तरह, हम मास्टर कोड में पहुँच गए, जिसने हमें फ्लॉप परीक्षण बना दिया:

- get_url:
    url: "{{ actk_certs }}/{{ item.1 }}"
    dest: "{{ actk_src_tmp }}/"
    username: "{{ actk_mvn_user }}"
    password: "{{ actk_mvn_pass }}"
  with_subelements:
    - "{{ actk_cert_list }}"
    - "{{ actk_certs }}"
  delegate_to: localhost

- copy:
    src: "{{ actk_src_tmp }}/{{ item.1 }}"
    dest: "{{ actk_dst_tmp }}"
  with_subelements:
    - "{{ actk_cert_list }}"
    - "{{ actk_certs }}"

फिर उन्होंने इसे ठीक कर दिया, लेकिन अवशेष रह गया।

get_url:
    url: "{{ actk_certs }}/{{ actk_item }}"
    dest: "{{ actk_src_tmp }}/{{ actk_item }}"
    username: "{{ actk_mvn_user }}"
    password: "{{ actk_mvn_pass }}"
  loop_control:
    loop_var: actk_item
  with_items: "{{ actk_cert_list }}"
  delegate_to: localhost

- copy:
    src: "{{ actk_src_tmp }}/{{ actk_item }}"
    dest: "{{ actk_dst_tmp }}"
  loop_control:
    loop_var: actk_item
  with_items: "{{ actk_cert_list }}"

दिन #311: परीक्षणों में तेजी लाना

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

कड़ाई से बोलते हुए, उपायों का एक सेट था:

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

परिणामस्वरूप, जेनकींस पर पाइपलाइन भी एकीकृत हो गई

निर्माण चरण उत्पन्न करें.
सभी को समानांतर में लिंट करें।
परीक्षण भूमिका चरणों को समानांतर में चलाएँ.
खत्म करो.

सबक सीखा

वैश्विक चर से बचें

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

मैं आपको एक उदाहरण देता हूं। चलो हम हासिल करें role_a и role_b

# cat role_a/defaults/main.yml
---
msg: a

# cat role_a/tasks/main.yml
---
- debug:
    msg: role_a={{ msg }}

# cat role_b/defaults/main.yml
---
msg: b

# cat role_b/tasks/main.yml
---
- set_fact:
    msg: b
- debug:
    msg: role_b={{ msg }}

- hosts: localhost
  vars:
    msg: hello
  roles:
    - role: role_a
    - role: role_b
  tasks:
    - debug:
        msg: play={{msg}}

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

खराब: वैश्विक चर का उपयोग करें।

# cat roles/some_role/tasks/main.yml
---
debug:
  var: java_home

GOOD: वी defaults आवश्यक चरों को परिभाषित करें और बाद में केवल उनका उपयोग करें।

# cat roles/some_role/defaults/main.yml
---
r__java_home:
 "{{ java_home | default('/path') }}"

# cat roles/some_role/tasks/main.yml
---
debug:
  var: r__java_home

उपसर्ग भूमिका चर

खराब: वैश्विक चर का उपयोग करें।

# cat roles/some_role/defaults/main.yml
---
db_port: 5432

GOOD: वेरिएबल्स के लिए भूमिकाओं में, रोल नाम के पहले वेरिएबल्स का उपयोग करें; इससे, इन्वेंट्री को देखकर, यह समझना आसान हो जाएगा कि क्या हो रहा है।

# cat roles/some_role/defaults/main.yml
---
some_role__db_port: 5432

लूप नियंत्रण चर का प्रयोग करें

खराब: लूप में मानक चर का उपयोग करें item, यदि यह कार्य/प्लेबुक कहीं शामिल है, तो इससे अप्रत्याशित व्यवहार हो सकता है

---
- hosts: localhost
  tasks:
    - debug:
        msg: "{{ item }}"
      loop:
        - item1
        - item2

GOOD: लूप में एक वेरिएबल को फिर से परिभाषित करें loop_var.

---
- hosts: localhost
  tasks:
    - debug:
        msg: "{{ item_name }}"
      loop:
        - item1
        - item2
      loop_control:
        loop_var: item_name

इनपुट वेरिएबल्स की जाँच करें

हम परिवर्तनीय उपसर्गों का उपयोग करने के लिए सहमत हुए; यह जांचना अतिश्योक्तिपूर्ण नहीं होगा कि उन्हें हमारी अपेक्षा के अनुसार परिभाषित किया गया है और, उदाहरण के लिए, किसी खाली मान से ओवरराइड नहीं किया गया है

GOOD: चर की जाँच करें.

- name: "Verify that required string variables are defined"
  assert:
    that: ahs_var is defined and ahs_var | length > 0 and ahs_var != None
    fail_msg: "{{ ahs_var }} needs to be set for the role to work "
    success_msg: "Required variables {{ ahs_var }} is defined"
  loop_control:
    loop_var: ahs_var
  with_items:
    - ahs_item1
    - ahs_item2
    - ahs_item3

हैश शब्दकोशों से बचें, सपाट संरचना का उपयोग करें

यदि कोई भूमिका अपने किसी पैरामीटर में हैश/डिक्शनरी की अपेक्षा करती है, तो यदि हम चाइल्ड पैरामीटर में से किसी एक को बदलना चाहते हैं, तो हमें संपूर्ण हैश/डिक्शनरी को ओवरराइड करना होगा, जिससे कॉन्फ़िगरेशन जटिलता बढ़ जाएगी।

खराब: हैश/शब्दकोश का प्रयोग करें.

---
user:
  name: admin
  group: admin

GOOD: एक समतल चर संरचना का उपयोग करें.

---
user_name: admin
user_group: "{{ user_name }}"

आदर्श प्लेबुक और भूमिकाएँ बनाएँ

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

कमांड शेल मॉड्यूल का उपयोग करने से बचें

शेल मॉड्यूल का उपयोग करने से घोषणात्मक के बजाय एक अनिवार्य विवरण प्रतिमान प्राप्त होता है, जो कि एन्सिबल का मूल है।

अणु के माध्यम से अपनी भूमिका का परीक्षण करें

अणु एक बहुत ही लचीली चीज़ है, आइए कुछ परिदृश्यों पर नज़र डालें।

अणु एकाधिक उदाहरण

В molecule.yml अनुभाग में platforms आप कई होस्ट का वर्णन कर सकते हैं जिन्हें आप तैनात कर सकते हैं।

---
    driver:
      name: docker
    platforms:
      - name: postgresql-instance
        hostname: postgresql-instance
        image: registry.example.com/postgres10:latest
        pre_build_image: true
        override_command: false
        network_mode: host
      - name: app-instance
        hostname: app-instance
        pre_build_image: true
        image: registry.example.com/docker_centos_ansible_tests
        network_mode: host

तदनुसार, ये मेजबान तब हो सकते हैं converge.yml उपयोग:

---
- name: Converge all
  hosts: all
  vars:
    ansible_user: root
  roles:
    - role: some_role

- name: Converge db
  hosts: db-instance
  roles:
    - role: some_db_role

- name: Converge app
  hosts: app-instance
  roles:
    - role: some_app_role

उत्तरयोग्य सत्यापनकर्ता

अणु में यह जांचने के लिए ansible का उपयोग करना संभव है कि इंस्टेंस सही ढंग से कॉन्फ़िगर किया गया है, इसके अलावा, रिलीज़ 3 के बाद से यह डिफ़ॉल्ट रहा है। यह testinfra/inspec जितना लचीला नहीं है, लेकिन हम जाँच सकते हैं कि फ़ाइल की सामग्री हमारी अपेक्षाओं से मेल खाती है:

---
- name: Verify
  hosts: all
  tasks:
    - name: copy config
      copy:
        src: expected_standalone.conf
        dest: /root/wildfly/bin/standalone.conf
        mode: "0644"
        owner: root
        group: root
      register: config_copy_result

    - name: Certify that standalone.conf changed
      assert:
        that: not config_copy_result.changed

या सेवा को तैनात करें, इसके उपलब्ध होने की प्रतीक्षा करें और धूम्रपान परीक्षण करें:

---
  - name: Verify
    hosts: solr
    tasks:
      - command: /blah/solr/bin/solr start -s /solr_home -p 8983 -force
      - uri:
          url: http://127.0.0.1:8983/solr
          method: GET
          status_code: 200
        register: uri_result
        until: uri_result is not failed
        retries: 12
        delay: 10
      - name: Post documents to solr
        command: /blah/solr/bin/post -c master /exampledocs/books.csv

मॉड्यूल और प्लगइन्स में जटिल तर्क डालें

Ansible एक घोषणात्मक दृष्टिकोण की वकालत करता है, इसलिए जब आप कोड ब्रांचिंग, डेटा ट्रांसफ़ॉर्मेशन, शेल मॉड्यूल करते हैं, तो कोड को पढ़ना मुश्किल हो जाता है। इससे निपटने के लिए और इसे समझने में सरल बनाए रखने के लिए, अपने स्वयं के मॉड्यूल बनाकर इस जटिलता का मुकाबला करना अतिश्योक्तिपूर्ण नहीं होगा।

टिप्स और ट्रिक्स को संक्षेप में प्रस्तुत करें

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

निष्कर्ष

आप किसी प्रोजेक्ट पर जाकर बुनियादी ढांचे को दोबारा तैयार नहीं कर सकते, भले ही आपके पास IaC हो। यह एक लंबी प्रक्रिया है जिसके लिए धैर्य, समय और ज्ञान की आवश्यकता होती है।

लिंक

UPD1 2020.05.01 20:30 — प्लेबुक की प्राथमिक प्रोफाइलिंग के लिए आप इसका उपयोग कर सकते हैं callback_whitelist = profile_tasks यह समझने के लिए कि वास्तव में लंबे समय तक क्या काम करता है। फिर हम आगे बढ़ते हैं उत्तरदायी त्वरण क्लासिक्स. आप भी कोशिश कर सकते हैं माइटोजन
UPD2 2020.05.03 16:34 - अंग्रेज़ी अनुवाद

स्रोत: www.habr.com

Ansible का परीक्षण कैसे शुरू करें, एक वर्ष में प्रोजेक्ट को दोबारा तैयार करें और पागल न हो जाएं