कसरी उत्तरदायी परीक्षण सुरु गर्ने, एक वर्षमा प्रोजेक्ट रिफ्याक्टर गर्नुहोस् र पागल नहुनुहोस्

यो ट्रान्सक्रिप्ट हो प्रदर्शन मा DevOps-40 २०२०-०३-१८:

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

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

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

एक समय एक सशर्त परियोजना थियो। यसमा देव विकास टोली र अप्स इन्जिनियरहरू थिए। तिनीहरूले समान समस्या समाधान गर्दै थिए: कसरी सर्भरहरू डिप्लोय गर्ने र एप्लिकेसन चलाउने। समस्या यो थियो कि प्रत्येक टोलीले आफ्नो तरिकामा यो समस्या समाधान गर्यो। परियोजनामा, देव र Ops टोलीहरू बीच ज्ञान सिंक्रोनाइज गर्न Ansible प्रयोग गर्ने निर्णय गरियो।

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

यो आफैलाई ध्यान नदिई, तिनीहरूले यसलाई सकेसम्म राम्रो गर्न चाहन्थे, तर यो विरासत भयो। यो कसरी हुन्छ?

• हामीसँग यहाँ एउटा अत्यावश्यक काम छ, फोहोर ह्याक गरौं र यसलाई ठीक गरौं।
• तपाईंले कागजातहरू लेख्नु पर्दैन र यहाँ के भइरहेको छ सबै कुरा स्पष्ट छ।
• मलाई Ansible/Python/Bash/Terraform थाहा छ! हेर म कसरी चकित गर्न सक्छु!
• म पूर्ण स्ट्याक ओभरफ्लो विकासकर्ता हुँ र यसलाई स्ट्याकओभरफ्लोबाट प्रतिलिपि गरेको छु, मलाई थाहा छैन यसले कसरी काम गर्छ, तर यो राम्रो देखिन्छ र समस्या समाधान गर्दछ।

नतिजाको रूपमा, तपाईले बुझ्न नसकिने प्रकारको कोड प्राप्त गर्न सक्नुहुन्छ जसको लागि कुनै कागजात छैन, यो स्पष्ट छैन कि यसले के गर्छ, यो आवश्यक छ कि छैन, तर समस्या यो हो कि तपाईले यसलाई विकास गर्न, परिमार्जन गर्न, बैसाखी र समर्थनहरू थप्न आवश्यक छ। , स्थिति झनै बिग्रन्छ ।

- 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: के तपाईलाई साँच्चै रिफ्याक्टरिंग चाहिन्छ?

तपाईं रिफ्याक्टरमा हतार गर्नु अघि, तपाईंले धेरै महत्त्वपूर्ण प्रश्नहरूको जवाफ दिनुपर्छ:

1. तपाईलाई यो सबै किन चाहिन्छ?
2. के तपाइँसँग समय छ?
3. के ज्ञान पर्याप्त छ?

यदि तपाईंलाई प्रश्नहरूको जवाफ कसरी दिने भन्ने थाहा छैन भने, रिफ्याक्टरिङ सुरु हुनु अघि नै समाप्त हुनेछ, वा यो अझ खराब हुन सक्छ। किनभने अनुभव थियो ( 200 लाइनहरू पूर्वाधार कोडको परीक्षणबाट मैले के सिकें), त्यसपछि परियोजनाले भूमिकाहरू ठीक गर्न र परीक्षणहरू समावेश गर्न मद्दतको लागि अनुरोध प्राप्त गर्यो।

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

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

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

उत्तरदायी परीक्षण प्रयासहरू

हामीले परियोजनामा ​​जवाफदेही परीक्षणहरू कसरी कभर गर्यौं भनेर वर्णन गर्न जानु अघि, म निर्णयहरूको सन्दर्भ बुझ्नको लागि मैले पहिले प्रयोग गर्ने मौका पाएको प्रयास र दृष्टिकोणहरू वर्णन गर्नेछु।

दिन नम्बर -997: SDS प्रावधान

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

दिन # -701: उत्तरदायी र परीक्षण भान्सा

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

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

दिन # -601: उत्तरदायी र अणु

वैचारिक रूपमा, यो testkitchen जस्तै छ, केवल हामीले भूमिका परीक्षण डकरमा सारियो र स्ट्याक परिवर्तन गर्यौं। नतिजाको रूपमा, समय 20 भूमिकाहरूको लागि स्थिर 25-7 मिनेटमा घटाइएको थियो।

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

दिन #167: परियोजनामा ​​उत्तरदायी परीक्षणहरू थप्दै

सम्भवतः, यो हतार मा refactoring कार्य गर्न सम्भव छैन। कार्य मापनयोग्य हुनुपर्छ ताकि तपाईं यसलाई सानो टुक्राहरूमा तोड्न सक्नुहुन्छ र एक चम्चाको साथ हात्तीको टुक्रा टुक्रा टुक्रा खान सक्नुहुन्छ। तपाईं सहि दिशामा जाँदै हुनुहुन्छ कि गर्दै हुनुहुन्छ, कति लामो समयसम्म जाने हो भन्ने बुझाइ हुनुपर्छ।

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

refactoring सरल छ:

• खानुहोस्।
• निद्रा
• कोड
• IaC परीक्षण।
• दोहोर्याउनुहोस्

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

यो तुरुन्तै सबै कुराको परीक्षण सुरु गर्न सम्भव नहुन सक्छ, त्यसैले हाम्रो पहिलो कार्य linting र वाक्यविन्यास जाँच संग सुरु गर्न थियो।

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

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

• रातो परीक्षण खराब छ।
• म केहि ठीक गर्न आएको हुँ र एकै समयमा कोडलाई तपाई अघिको भन्दा अलि राम्रो बनाउनुहोस्।

दिन #193: linting देखि एकाइ परीक्षण सम्म

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

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

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

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

जेनकिन्स + डकर + उत्तरदायी = परीक्षण

1. रिपो चेकआउट गर्नुहोस् र निर्माण चरणहरू उत्पन्न गर्नुहोस्।
2. समानान्तरमा लिन्ट प्लेबुक चरणहरू चलाउनुहोस्।
3. समानान्तर रूपमा लिन्ट भूमिका चरणहरू चलाउनुहोस्।
4. समानान्तरमा सिन्ट्याक्स जाँच रोल चरणहरू चलाउनुहोस्।
5. समानान्तर रूपमा परीक्षण भूमिका चरणहरू चलाउनुहोस्।
   1. लिन्ट भूमिका।
   2. अन्य भूमिकाहरूमा निर्भरता जाँच गर्नुहोस्।
   3. सिन्ट्याक्स जाँच गर्नुहोस्।
   4. डकर उदाहरण सिर्जना गर्नुहोस्
   5. molecule/default/playbook.yml चलाउनुहोस्।
   6. इडम्पोटेन्सी जाँच गर्नुहोस्।
6. एकीकरण परीक्षणहरू चलाउनुहोस्
7. समाप्त

दिन #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: परीक्षणको गति बढाउँदै

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

कडा शब्दमा, त्यहाँ उपायहरूको सेट थियो:

1. डकरमा स्विच गर्नुहोस्।
2. भूमिका परीक्षण हटाउनुहोस्, जुन निर्भरताका कारण नक्कल गरिएको छ।
3. दासहरूको संख्या बढाउनुहोस्।
4. परीक्षण रन अर्डर।
5. लिन्ट गर्ने क्षमता सबै स्थानीय एक आदेश संग।

नतिजाको रूपमा, जेन्किन्समा पाइपलाइन पनि एकीकृत भयो

1. निर्माण चरणहरू उत्पन्न गर्नुहोस्।
2. सबै समानान्तर लिन्ट।
3. समानान्तर रूपमा परीक्षण भूमिका चरणहरू चलाउनुहोस्।
4. समाप्त गर्नुहोस्।

सिकेका पाठहरू

विश्वव्यापी चरहरूबाट बच्नुहोस्

Ansible ले ग्लोबल चरहरू प्रयोग गर्दछ, त्यहाँ फारममा आंशिक समाधान छ निजी_भूमिका_vars, तर यो एक रामबाण उपाय होइन।

म तपाईंलाई एउटा उदाहरण दिन्छु। गरौं 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

असल: वि 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

असल: चलका लागि भूमिकाहरूमा, भूमिकाको नामसँग उपसर्ग लगाइएको चरहरू प्रयोग गर्नुहोस्; यसले, सूची हेरेर, के भइरहेको छ भनेर बुझ्न सजिलो बनाउनेछ।

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

लूप नियन्त्रण चर प्रयोग गर्नुहोस्

नराम्रो: loops मा मानक चर प्रयोग गर्नुहोस् item, यदि यो कार्य/प्लेबुक कतै समावेश गरिएको छ भने, यसले अनपेक्षित व्यवहार निम्त्याउन सक्छ

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

असल: मार्फत लूपमा चर पुन: परिभाषित गर्नुहोस् loop_var.

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

इनपुट चर जाँच गर्नुहोस्

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

असल: चर जाँच गर्नुहोस्।

- 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

असल: समतल चर संरचना प्रयोग गर्नुहोस्।

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

मोड्युल र प्लगइनहरूमा जटिल तर्क राख्नुहोस्

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

सुझाव र युक्तिहरू संक्षेप गर्नुहोस्

1. विश्वव्यापी चरहरूबाट बच्नुहोस्।
2. उपसर्ग भूमिका चर।
3. लूप नियन्त्रण चर प्रयोग गर्नुहोस्।
4. इनपुट चर जाँच गर्नुहोस्।
5. ह्यास शब्दकोशहरू नदिनुहोस्, समतल संरचना प्रयोग गर्नुहोस्।
6. इम्पोटेन्ट प्लेबुक र भूमिकाहरू सिर्जना गर्नुहोस्।
7. कमाण्ड शेल मोड्युलहरू प्रयोग नगर्नुहोस्।
8. अणु मार्फत आफ्नो भूमिका परीक्षण गर्नुहोस्।
9. मोड्युल र प्लगइनहरूमा जटिल तर्क राख्नुहोस्।

निष्कर्षमा

तपाईंसँग IaC छ भने पनि, तपाईं गएर परियोजनामा ​​​​पूर्वाधारलाई रिफ्याक्टर गर्न सक्नुहुन्न। यो एक लामो प्रक्रिया हो जसलाई धैर्य, समय र ज्ञान चाहिन्छ।

लिंक

• स्लाइडहरू कसरी उत्तरदायी परीक्षण गर्ने र पागल नजानुहोस्
• भिडियो कसरी उत्तरदायी परीक्षण गर्ने र पागल नजानुहोस्
• 200 लाइनहरू पूर्वाधार कोडको परीक्षणबाट मैले के सिकें
• उत्तरदायी: 120 महिनामा Coreos बाट Centos मा 18 VM कन्फिगरेसनको माइग्रेसन
• तपाईंको वितरण परीक्षण गर्दा बैसाखीमाथि साइकलहरू कसरी तोड्ने
• यदि तपाइँ YML प्रोग्रामरहरूले उत्तरदायी परीक्षण गर्ने सपना देख्न सक्नुहुन्छ भने मलाई जाँच्नुहोस्?
• उत्कृष्ट IaC परीक्षण लेख, भाषण र लिङ्कहरूको सूची
• क्रस पोस्ट
• संस्करण française

UPD1 2020.05.01 20:30 - प्लेबुकहरूको प्राथमिक प्रोफाइलिङको लागि तपाईंले प्रयोग गर्न सक्नुहुन्छ callback_whitelist = profile_tasks लामो समयको लागि वास्तवमा के काम गर्दछ भनेर बुझ्न। त्यसपछि हामी जान्छौं उत्तरदायी त्वरण क्लासिक्स। तपाईं पनि प्रयास गर्न सक्नुहुन्छ माइटोजेन
UPD2 2020.05.03 16:34 - संस्करण française

स्रोत: www.habr.com