🥇 चाचणी कशी सुरू करावी उत्तरदायी, एका वर्षात प्रोजेक्ट रिफॅक्टर करा आणि वेडा होऊ नका

हा उतारा आहे कामगिरी वर DevOps-40 2020-03-18:

दुसऱ्या कमिटपासून प्रारंभ करून, कोणताही कोड वारसा बनतो, कारण सुरुवातीच्या कल्पना कठोर वास्तवापासून दूर जाऊ लागतात. हे चांगले किंवा वाईट नाही, हे एक दिले आहे ज्याशी वाद घालणे कठीण आहे आणि जगणे आवश्यक आहे. या प्रक्रियेचा एक भाग म्हणजे रिफॅक्टरिंग. रीफॅक्टरिंग इन्फ्रास्ट्रक्चर कोड म्हणून. एका वर्षात रीफॅक्टर ॲन्सिबल कसे करावे आणि वेडे होऊ नये यावर कथा सुरू करूया.

वारसा जन्म

दिवस #1: पेशंट शून्य

एकेकाळी सशर्त प्रकल्प होता. त्यात देव विकास संघ आणि ऑप्स अभियंते होते. ते समान समस्या सोडवत होते: सर्व्हर कसा तैनात करायचा आणि अनुप्रयोग कसा चालवायचा. समस्या अशी होती की प्रत्येक संघाने आपापल्या पद्धतीने ही समस्या सोडवली. प्रोजेक्टमध्ये, देव आणि ऑप्स टीम्समधील ज्ञान सिंक्रोनाइझ करण्यासाठी Ansible वापरण्याचा निर्णय घेण्यात आला.

दिवस #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: SDS तरतूद

मी प्रथमच Ansible ची चाचणी SDS (सॉफ्टवेअर डिफाइन्ड स्टोरेज) विकसित करण्याच्या प्रकल्पावर केली होती. या विषयावर एक स्वतंत्र लेख आहे
तुमच्या वितरणाची चाचणी करताना क्रॅचवर सायकली कशा फोडायच्या, परंतु थोडक्यात, आम्ही एका उलट्या चाचणी पिरॅमिडसह संपलो आणि चाचणीसाठी आम्ही एका भूमिकेसाठी 60-90 मिनिटे घालवली, जो बराच काळ आहे. आधार e2e चाचण्या होत्या, म्हणजे. आम्ही पूर्ण वाढीव स्थापना तैनात केली आणि नंतर त्याची चाचणी केली. त्याहूनही त्रासदायक बाब म्हणजे स्वतःच्या सायकलचा शोध. परंतु मी कबूल केलेच पाहिजे की या समाधानाने कार्य केले आणि स्थिर प्रकाशनासाठी परवानगी दिली.

दिवस # -701: उत्तरदायी आणि चाचणी स्वयंपाकघर

उत्तरदायी चाचणी कल्पनेचा विकास म्हणजे तयार साधनांचा वापर करणे, म्हणजे किचन/किचन-सीआय आणि तपासणी. रुबीच्या ज्ञानाने निवड निश्चित केली गेली (अधिक तपशीलांसाठी, हाब्रेवरील लेख पहा: YML प्रोग्रामर उत्तरदायी चाचणी करण्याचे स्वप्न पाहतात का?) जलद काम केले, सुमारे 40 मिनिटे 10 भूमिकांसाठी. आम्ही व्हर्च्युअल मशीनचा एक पॅक तयार केला आणि आत चाचण्या केल्या.

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

दिवस # -601: उत्तरदायी आणि रेणू

वैचारिकदृष्ट्या, हे टेस्टकिचेनसारखेच आहे, फक्त आम्ही रोल टेस्टिंग डॉकरमध्ये हलवले आणि स्टॅक बदलला. परिणामी, 20 भूमिकांसाठी वेळ स्थिर 25-7 मिनिटांपर्यंत कमी करण्यात आला.

चाचणी केलेल्या भूमिकांची संख्या 17 पर्यंत वाढवून आणि 45 भूमिकांद्वारे, आम्ही 28 जेनकिन्स स्लेव्हवर 2 मिनिटांत हे कार्य केले.

दिवस #167: प्रकल्पात उत्तरदायी चाचण्या जोडणे

बहुधा, घाईत रिफॅक्टरिंग कार्य करणे शक्य होणार नाही. कार्य मोजता येण्याजोगे असले पाहिजे जेणेकरुन तुम्ही त्याचे लहान तुकडे करू शकाल आणि हत्तीचा तुकडा चमचेने खाऊ शकता. तुमची वाटचाल योग्य दिशेने आहे की नाही, किती वेळ जायचे आहे, याची समज असायला हवी.

सर्वसाधारणपणे, ते कसे केले जाईल याने काही फरक पडत नाही, तुम्ही कागदाच्या तुकड्यावर लिहू शकता, तुम्ही कपाटावर स्टिकर्स लावू शकता, तुम्ही जिरामध्ये कार्ये तयार करू शकता किंवा तुम्ही Google डॉक्स उघडू शकता आणि वर्तमान स्थिती लिहू शकता. तेथे. पाय या वस्तुस्थितीपासून वाढतात की प्रक्रिया त्वरित नाही, ती लांब आणि कंटाळवाणा असेल. रिफॅक्टरिंगच्या वेळी तुम्ही कल्पनांना उजाळा द्यावा, थकवावे आणि भारावून जावे असे कोणालाही वाटेल अशी शक्यता नाही.

रिफॅक्टरिंग सोपे आहे:

खा.
झोप
कोड
IaC चाचणी.
पुनरावृत्ती करा

आणि आम्ही अपेक्षित ध्येय गाठेपर्यंत याची पुनरावृत्ती करतो.

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

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

लिंटिंग हे ग्रीन बिल्ड मास्टरच्या दिशेने एक लहान पहिले पाऊल आहे. हे जवळजवळ काहीही खंडित करणार नाही, परंतु ते तुम्हाला प्रक्रिया डीबग करण्यास आणि जेनकिन्समध्ये ग्रीन बिल्ड बनविण्यास अनुमती देईल. संघामध्ये सवयी विकसित करणे ही कल्पना आहे:

लाल चाचण्या वाईट आहेत.
मी काहीतरी दुरुस्त करण्यासाठी आलो आहे आणि त्याच वेळी कोड तुमच्या आधी होता त्यापेक्षा थोडा चांगला बनवतो.

दिवस #193: लिंटिंगपासून युनिट चाचण्यांपर्यंत

मास्टरमध्ये कोड मिळविण्याची प्रक्रिया तयार केल्यावर, आपण चरण-दर-चरण सुधारणेची प्रक्रिया सुरू करू शकता - लाँचिंग भूमिकांसह लिंटिंगची जागा घेऊन, आपण ते अशक्तपणाशिवाय देखील करू शकता. तुम्हाला भूमिका कशा लागू करायच्या आणि त्या कशा काम करतात हे समजून घेणे आवश्यक आहे.

दिवस #211: युनिट ते इंटिग्रेशन चाचण्या

जेव्हा बहुतेक भूमिका युनिट चाचण्यांनी कव्हर केल्या जातात आणि सर्वकाही लिंट केलेले असते, तेव्हा तुम्ही एकत्रीकरण चाचण्या जोडण्यासाठी पुढे जाऊ शकता. त्या. पायाभूत सुविधांमध्ये एका विटाची चाचणी करत नाही, परंतु त्यांचे संयोजन, उदाहरणार्थ, संपूर्ण उदाहरण कॉन्फिगरेशन.

जेनकिन्स वापरून, आम्ही समांतर भूमिका/प्लेबुक्स, नंतर कंटेनरमध्ये युनिट चाचण्या आणि शेवटी एकत्रीकरण चाचण्या करणारे अनेक टप्पे व्युत्पन्न केले.

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

रेपो चेकआउट करा आणि बिल्ड टप्पे व्युत्पन्न करा.
लिंट प्लेबुकचे टप्पे समांतर चालवा.
लिंट रोल टप्पे समांतर चालवा.
सिंटॅक्स चेक रोल टप्पे समांतर चालवा.
चाचणी भूमिका टप्पे समांतर चालवा.
1. लिंट भूमिका.
2. इतर भूमिकांवरील अवलंबित्व तपासा.
3. वाक्यरचना तपासा.
4. डॉकर उदाहरण तयार करा
5. molecule/default/playbook.yml चालवा.
6. अशक्तपणा तपासा.
एकीकरण चाचण्या चालवा
समाप्त

दिवस #२७१: बस फॅक्टर

सुरुवातीला, रिफॅक्टरिंग दोन किंवा तीन लोकांच्या लहान गटाद्वारे केले जात असे. त्यांनी मास्टरमधील कोडचे पुनरावलोकन केले. कालांतराने, संघाने कोड कसे लिहावे याचे ज्ञान विकसित केले आणि कोड पुनरावलोकनामुळे पायाभूत सुविधांबद्दल आणि ते कसे कार्य करते याबद्दल ज्ञानाचा प्रसार करण्यास हातभार लागला. येथे ठळक गोष्ट अशी होती की समीक्षकांची निवड एका शेड्यूलनुसार केली गेली होती, म्हणजे. काही प्रमाणात संभाव्यतेसह तुम्ही पायाभूत सुविधांच्या नवीन तुकड्यात जाल.

आणि ते येथे आरामदायक असावे. पुनरावलोकन करणे, ते कोणते कार्य केले गेले आणि चर्चेचा इतिहास पहाणे सोयीचे आहे. आम्ही जेनकिन्स + बिटबकेट + जिरा एकत्रित केले आहे.

परंतु अशा प्रकारे, पुनरावलोकन हा रामबाण उपाय नाही, आम्ही मास्टर कोडमध्ये प्रवेश केला, ज्यामुळे आमच्या चाचण्या फ्लॉप झाल्या:

- 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: चाचण्यांना गती देणे

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

काटेकोरपणे सांगायचे तर, उपायांचा एक संच होता:

डॉकरवर स्विच करा.
भूमिका चाचणी काढून टाका, जी अवलंबित्वांमुळे डुप्लिकेट झाली आहे.
गुलामांची संख्या वाढवा.
चाचणी रन ऑर्डर.
लिंट करण्याची क्षमता सर्व स्थानिक पातळीवर एका आदेशाने.

त्यामुळे जेनकिन्सवरील पाइपलाइनही एकरूप झाली

बिल्ड टप्पे व्युत्पन्न करा.
लिंट सर्व समांतर.
चाचणी भूमिका टप्पे समांतर चालवा.
समाप्त.

शिकलेले धडे

ग्लोबल व्हेरिएबल्स टाळा

उत्तरदायी जागतिक व्हेरिएबल्सचा वापर करते, फॉर्ममध्ये आंशिक वर्कअराउंड आहे खाजगी_भूमिका_वार, पण हा रामबाण उपाय नाही.

मी तुम्हाला एक उदाहरण देतो. आम्हाला असू द्या 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

लूप कंट्रोल व्हेरिएबल वापरा

वाईट: लूपमध्ये मानक व्हेरिएबल वापरा 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 }}"

अशक्त प्लेबुक आणि भूमिका तयार करा

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

कमांड शेल मॉड्यूल्स वापरणे टाळा

शेल मॉड्युलचा वापर केल्याने घोषणात्मक ऐवजी अनिवार्य वर्णनाचा नमुना येतो, जो Ansible चा गाभा आहे.

रेणूद्वारे तुमच्या भूमिका तपासा

रेणू एक अतिशय लवचिक गोष्ट आहे, चला काही परिस्थिती पाहू.

रेणू अनेक उदाहरणे

В 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

उत्तरदायी सत्यापनकर्ता

रेणूमध्ये उदाहरण योग्यरित्या कॉन्फिगर केले गेले आहे हे तपासण्यासाठी उत्तरदायी वापरणे शक्य आहे, शिवाय, रिलीज 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

मॉड्यूल आणि प्लगइनमध्ये जटिल तर्क ठेवा

उत्तरदायी एक घोषणात्मक दृष्टिकोनाचे समर्थन करते, म्हणून जेव्हा तुम्ही कोड ब्रँचिंग, डेटा ट्रान्सफॉर्मेशन, शेल मॉड्यूल्स करता तेव्हा कोड वाचणे कठीण होते. याचा सामना करण्यासाठी आणि समजण्यास सोपे ठेवण्यासाठी, आपले स्वतःचे मॉड्यूल तयार करून या जटिलतेचा सामना करणे अनावश्यक होणार नाही.

टिपा आणि युक्त्या सारांशित करा

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

निष्कर्ष

तुमच्याकडे IaC असले तरीही तुम्ही फक्त जाऊन एखाद्या प्रकल्पावरील पायाभूत सुविधांची पुनर्रचना करू शकत नाही. ही एक लांब प्रक्रिया आहे ज्यासाठी संयम, वेळ आणि ज्ञान आवश्यक आहे.

दुवे

UPD1 2020.05.01 20:30 - प्लेबुकच्या प्राथमिक प्रोफाइलिंगसाठी तुम्ही वापरू शकता callback_whitelist = profile_tasks बर्याच काळापासून नेमके काय कार्य करते हे समजून घेण्यासाठी. मग आम्ही जातो उत्तरदायी प्रवेग क्लासिक्स. तुम्ही पण प्रयत्न करू शकता mitogen
UPD2 2020.05.03 16:34 - इंग्रजी आवृत्ती

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

उत्तरदायी चाचणी कशी सुरू करावी, एका वर्षात प्रकल्प रिफॅक्टर करा आणि वेडा होऊ नका