جانچ ڪيئن شروع ڪجي جوابي، هڪ سال ۾ پروجيڪٽ کي ريفيڪٽر ڪيو ۽ چريو نه ٿيو

هي نقل آهي پرفارمنس تي DevOps-40 2020-03-18:

ٻئي ڪمٽ کان شروع ڪندي، ڪو به ڪوڊ ميراث بڻجي ويندو آهي، ڇاڪاڻ ته ابتدائي خيال سخت حقيقتن کان ڌار ٿيڻ شروع ڪن ٿا. اهو نه سٺو آهي ۽ نه خراب، اهو هڪ ڏنو ويو آهي جنهن سان بحث ڪرڻ ڏکيو آهي ۽ ان سان گڏ رهڻ گهرجي. هن عمل جو حصو refactoring آهي. Refactoring infrastructure as Code. اچو ته ڪهاڻي شروع ڪريون ته ڪيئن هڪ سال ۾ جوابي ريفيڪٽر ڪيو وڃي ۽ چريو نه ٿيو.

وراثت جو جنم

ڏينهن #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 refactoring

ڏينهن # 139: ڇا توهان واقعي کي ريفيڪٽرنگ جي ضرورت آهي؟

ان کان اڳ جو توهان ريفيڪٽر ڏانهن جلدي ڪريو، توهان کي ڪجهه اهم سوالن جا جواب ڏيڻ گهرجن:

1. توهان کي اهو سڀ ڪجهه ڇو گهرجي؟
2. ڇا توهان وٽ وقت آهي؟
3. ڇا علم ڪافي آهي؟

جيڪڏهن توهان کي خبر ناهي ته سوالن جا جواب ڪيئن ڏنا وڃن، ته پوءِ ريفيڪٽرنگ شروع ٿيڻ کان اڳ ئي ختم ٿي ويندي، يا اهو صرف خراب ٿي سگهي ٿو. ڇاڪاڻ ته تجربو ڪيو ( ڇا مون 200 لائنن جي انفراسٽرڪچر ڪوڊ جي جاچ ڪرڻ مان سکيو)، پوء پروجيڪٽ کي مدد لاء درخواست ملي ته ڪردار کي درست ڪرڻ ۽ انهن کي ٽيسٽ سان ڍڪڻ لاء.

ڏينهن # 149: ريفيڪٽرنگ جي تياري

پهرين شيء تيار ڪرڻ آهي. فيصلو ڪيو ته ڇا ڪنداسين. هن کي ڪرڻ لاءِ، اسان ڳالهه ٻولهه ڪندا آهيون، مسئلن جي علائقن کي ڳولهيندا آهيون ۽ انهن کي حل ڪرڻ جا طريقا ڳوليندا آهيون. اسان نتيجن جي تصورن کي ڪنهن نه ڪنهن طريقي سان رڪارڊ ڪندا آهيون، مثال طور سنگم ۾ هڪ مضمون، تنهنڪري جڏهن سوال پيدا ٿئي ٿو ته "بهترين ڇا آهي؟" يا "ڇا صحيح آهي؟" اسان پنهنجو رستو نه وڃايو آهي. اسان جي حالت ۾، اسان خيال کي پڪڙيو ورهايو ۽ حڪومت ڪريو: اسان انفراسٽرڪچر کي ننڍڙن ٽڪرن/ سرن ۾ ٽوڙيندا آهيون. اهو طريقو توهان کي انفراسٽرڪچر جو هڪ الڳ ٽڪرو وٺڻ جي اجازت ڏئي ٿو، سمجهي ٿو ته اهو ڇا ڪري ٿو، ان کي ٽيسٽ سان ڍڪيو ۽ ان کي تبديل ڪرڻ جي بغير ڪنهن به شيء کي ٽوڙڻ جي خوف کان سواء.

اهو ظاهر ٿئي ٿو ته انفراسٽرڪچر ٽيسٽ بنيادي بنياد بڻجي وڃي ٿي ۽ هتي اهو ذڪر ڪرڻ جي قابل آهي انفراسٽرڪچر ٽيسٽ پيرامڊ. بلڪل ساڳيو خيال جيڪو ترقي ۾ آهي، پر انفراسٽرڪچر لاءِ: اسان سستا تڪڙا ٽيسٽ کان اڳتي وڌي رهيا آهيون جيڪي سادي شين کي چيڪ ڪن ٿا، جهڙوڪ انڊينٽيشن، مهانگي مڪمل ٽيسٽن ڏانهن جيڪي پوري انفراسٽرڪچر کي ترتيب ڏين ٿا.

جوابي آزمائشي ڪوششون

ان کان اڳ جو اسين بيان ڪريون ته ڪيئن اسان پراجيڪٽ تي جوابي ٽيسٽن جو احاطو ڪيو، مان انهن ڪوششن ۽ طريقن کي بيان ڪندس جن کي مون اڳ ۾ استعمال ڪرڻ جو موقعو مليو هو ته جيئن ڪيل فيصلن جي حوالي سان سمجھڻ لاءِ.

ڏينهن نمبر -997: SDS روزي

پهريون ڀيرو مون جوابي ٽيسٽ ڪئي هئي هڪ پروجيڪٽ تي SDS (سافٽ ويئر ڊفائنڊ اسٽوريج). هن موضوع تي هڪ الڳ مضمون آهي
توهان جي ورڇ کي جانچڻ دوران ڪچين مٿان سائيڪلن کي ڪيئن ٽوڙڻ، پر مختصر ۾، اسان هڪ انوٽي ٽيسٽنگ پيرامڊ سان ختم ڪيو ۽ ٽيسٽنگ اسان هڪ ڪردار تي 60-90 منٽ گذاريا، جيڪو هڪ ڊگهو وقت آهي. بنياد e2e ٽيسٽ هو، يعني. اسان هڪ مڪمل نصب ٿيل تنصيب کي ترتيب ڏنو ۽ پوء ان کي جانچيو. ان کان به وڌيڪ ڏکوئيندڙ ڳالهه اها هئي ته سندس پنهنجي سائيڪل جي ايجاد هئي. پر مون کي تسليم ڪرڻ گهرجي، هي حل ڪم ڪيو ۽ هڪ مستحڪم ڇڏڻ جي اجازت ڏني.

ڏينهن # -701: جوابي ۽ ٽيسٽ باورچی خانه

جوابي ٽيسٽنگ خيال جي ترقيءَ جو مقصد تيار ٿيل اوزارن جو استعمال هو، يعني ٽيسٽ ڪچن/ڪچن-سي ۽ انسپيڪ. انتخاب روبي جي علم جي ذريعي طئي ڪيو ويو (وڌيڪ تفصيل لاء، هيبري تي آرٽيڪل ڏسو: ڇا YML پروگرامر جواب ڏيڻ جا خواب ڏسندا آهن؟) تيزي سان ڪم ڪيو، اٽڪل 40 منٽن لاءِ 10 ڪردار. اسان ورچوئل مشينن جو هڪ پيڪ ٺاهيو ۽ اندر ٽيسٽون ڪيون.

عام طور تي، حل ڪم ڪيو، پر heterogeneity جي ڪري ڪجهه تلخ هو. جڏهن اسان 13 بنيادي ڪردارن ۽ 2 ميٽا رولز کي ننڍڙن ڪردارن کي گڏ ڪندي ٽيسٽن جو تعداد وڌايو، تڏهن اوچتو ٽيسٽ 70 منٽن تائين هلڻ شروع ٿي، جيڪا لڳ ڀڳ 2 ڀيرا وڌيڪ آهي. XP (انتهائي پروگرامنگ) جي مشقن بابت ڳالهائڻ ڏکيو هو ڇاڪاڻ ته ... ڪو به 70 منٽ انتظار ڪرڻ نٿو چاهي. اهو ئي سبب هو جو روش بدلجي وئي

ڏينهن # -601: جوابي ۽ ماليڪيول

تصوراتي طور تي، اهو ساڳيو آهي testkitchen، صرف اسان رول ٽيسٽ کي ڊاکر ڏانهن منتقل ڪيو ۽ اسٽيڪ کي تبديل ڪيو. نتيجي طور، وقت 20 ڪردارن لاء مستحڪم 25-7 منٽن تائين گھٽجي ويو.

آزمائشي ڪردارن جو تعداد وڌائي 17 تائين ۽ 45 ڪردارن کي لڪائڻ سان، اسان ان کي 28 منٽن ۾ 2 جينڪن غلامن تي هلائي ڇڏيو.

ڏينهن #167: پروجيڪٽ ۾ جوابي ٽيسٽ شامل ڪرڻ

گهڻو ڪري، اهو ممڪن نه ٿيندو ته جلدي ۾ ريفڪٽرنگ ڪم ڪرڻ. ڪم کي ماپيبل هجڻ گهرجي ته جيئن توهان ان کي ننڍڙن ٽڪرن ۾ ٽوڙي سگهو ۽ هاٿي جي ٽڪري کي چانهه جي چمچ سان کائي سگهو. اتي ضرور سمجھڻ گھرجي ته ڇا توھان صحيح رخ ۾ ھلي رھيا آھيو، ڪيترو وقت وڃڻو آھي.

عام طور تي، اهو مسئلو ناهي ته اهو ڪيئن ٿيندو، توهان ڪاغذ جي هڪ ٽڪري تي لکي سگهو ٿا، توهان الماري تي اسٽيڪر لڳائي سگهو ٿا، توهان جيرا ۾ ڪم ٺاهي سگهو ٿا، يا توهان گوگل ڊڪس کوليو ۽ موجوده صورتحال کي لکي سگهو ٿا. اتي پير ان حقيقت کان وڌي ٿو ته اهو عمل فوري ناهي، اهو ڊگهو ۽ ٿڪل هوندو. اهو ممڪن ناهي ته ڪو به چاهي ٿو ته توهان خيالن مان ساڙيو، ٿڪجي وڃو، ۽ ريفڪٽرنگ دوران حيران ٿي وڃو.

refactoring سادو آهي:

• کائڻ
• سمهڻ.
• ڪوڊ.
• IaC ٽيسٽ.
• ورجائي ٿو

۽ اسان ان کي ٻيهر ورجائيندا آهيون جيستائين اسان مطلوب مقصد تائين پهچي نه وڃون.

اهو ممڪن ناهي ته هر شي کي فوري طور تي جاچڻ شروع ڪيو وڃي، تنهنڪري اسان جو پهريون ڪم linting ۽ نحو کي جانچڻ سان شروع ڪرڻ هو.

ڏينهن #181: گرين بلڊ ماسٽر

Linting هڪ ننڍڙو پهريون قدم آهي گرين بلڊ ماسٽر ڏانهن. اهو لڳ ڀڳ ڪجھ به نه ڀڃندو، پر اهو توهان کي اجازت ڏيندو پروسيس ڊيبگ ڪرڻ ۽ جينڪنز ۾ سائي تعميرات. خيال ٽيم جي وچ ۾ عادتون پيدا ڪرڻ آهي:

• ڳاڙهو ٽيسٽ خراب آهن.
• مان ڪجھ ٺيڪ ڪرڻ لاءِ آيو آهيان ۽ ساڳئي وقت ڪوڊ کي ٿورڙو بهتر بڻايو جيڪو توهان کان اڳ هو.

ڏينهن #193: لينٽنگ کان يونٽ ٽيسٽ تائين

ماسٽر ۾ ڪوڊ حاصل ڪرڻ جي عمل کي تعمير ڪرڻ کان پوء، توهان شروع ڪري سگهو ٿا قدم قدم بهتري جو عمل - لينٽنگ کي تبديل ڪرڻ واري ڪردار سان، توهان اهو ڪري سگهو ٿا بغير بغير بغير. توهان کي سمجهڻ جي ضرورت آهي ته ڪردار ڪيئن لاڳو ڪجي ۽ اهي ڪيئن ڪم ڪن.

ڏينهن #211: يونٽ کان انٽيگريشن ٽيسٽ تائين

جڏهن اڪثر ڪردار يونٽ ٽيسٽن سان ڍڪيل هوندا آهن ۽ هر شيءِ لڪايل هوندي آهي، توهان اڳتي وڌي سگهو ٿا انٽيگريشن ٽيسٽ شامل ڪرڻ لاءِ. اهي. بنيادي ڍانچي ۾ ھڪڙي اينٽ جي جانچ نه آھي، پر انھن جو ھڪڙو ميلاپ، مثال طور، ھڪڙي مڪمل مثال جي ترتيب.

جينڪنز کي استعمال ڪندي، اسان ڪيترائي مرحلا ٺاهيا جن ۾ رولز/پلے بڪ کي متوازي، پوءِ ڪنٽينر ۾ يونٽ ٽيسٽ، ۽ آخر ۾ انٽيگريشن ٽيسٽ.

جينڪنز + ڊڪر + جوابي = ٽيسٽ

1. ريپو چيڪ ڪريو ۽ ٺاھڻ جا مرحلا ٺاھيو.
2. هلو lint playbook اسٽيج متوازي ۾.
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. تبديل ڪريو docker ڏانهن.
2. رول ٽيسٽ کي هٽايو، جيڪو انحصار جي ڪري نقل ڪيو ويو آهي.
3. غلامن جو تعداد وڌايو.
4. ٽيسٽ هلائڻ جو حڪم.
5. لينٽ ڪرڻ جي صلاحيت سڀ مقامي طور تي هڪ حڪم سان.

نتيجي طور، جينکنز تي پائپ لائن پڻ متحد ٿي وئي

1. ٺاھڻ جا مرحلا ٺاھيو.
2. سڀني کي متوازي ۾ لڪايو.
3. متوازي ۾ ٽيسٽ رول ​​اسٽيج کي هلائڻ.
4. ختم ڪر.

سبق سکيو

عالمي متغيرن کان پاسو ڪريو

جوابي عالمي متغير استعمال ڪري ٿو، فارم ۾ هڪ جزوي حل آهي نجي_رول_وارس، پر هي هڪ panacea نه آهي.

اچو ته توهان کي هڪ مثال ڏيان. اسان کي ڏيو 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}}

عجيب ڳالهه اها آهي ته راندين جي ڪتابن جو نتيجو انهن شين تي منحصر هوندو جيڪي هميشه واضح نه هوندا آهن، جهڙوڪ ترتيب جنهن ۾ ڪردار درج ٿيل آهن. بدقسمتي سان، اهو جواب ڏيڻ جي فطرت آهي ۽ بهترين شيء جيڪو ڪري سگهجي ٿو اهو ڪجهه قسم جي معاهدي کي استعمال ڪرڻ آهي، مثال طور، هڪ ڪردار جي اندر، صرف هن ڪردار ۾ بيان ڪيل متغير استعمال ڪريو.

BAD: عالمي متغير استعمال ڪريو.

# 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

اڳوڻو ڪردار متغير

BAD: عالمي متغير استعمال ڪريو.

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

سٺو: متغيرن لاءِ ڪردارن ۾، ڪردار جي نالي سان اڳي ۾ متغير استعمال ڪريو؛ هي، انوینٽري کي ڏسڻ سان، اهو سمجهڻ آسان بڻائيندو ته ڇا ٿي رهيو آهي.

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

لوپ ڪنٽرول متغير استعمال ڪريو

BAD: لوپ ۾ معياري متغير استعمال ڪريو 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

هيش ڊڪشنري کان پاسو ڪريو، فليٽ ڍانچي استعمال ڪريو

جيڪڏهن ڪو ڪردار توقع ڪري ٿو ته هيش/ڊڪشنري ان جي ڪنهن به پيٽرولر ۾، پوءِ جيڪڏهن اسان چائلڊ پيرا ميٽرز مان هڪ کي تبديل ڪرڻ چاهيون ٿا، ته اسان کي پوري هيش/ڊڪشنري کي اوور رائڊ ڪرڻو پوندو، جيڪو ترتيب جي پيچيدگي کي وڌائيندو.

BAD: هيش/ ڊڪشنري استعمال ڪريو.

---
user:
  name: admin
  group: admin

سٺو: هڪ فليٽ متغير ساخت استعمال ڪريو.

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

تخليقي راند ڪتاب ۽ ڪردار ٺاهيو

ڪردار ۽ playbooks idempotent هجڻ ضروري آهي, ڇاڪاڻ ته ٺاھ جوڙ کي گھٽائي ٿو ۽ ڪنھن شيء کي ٽوڙڻ جو خوف. پر جيڪڏهن توهان ماليڪيول استعمال ڪريو ٿا، ته پوءِ هي ڊفالٽ رويي آهي.

ڪمانڊ شيل ماڊل استعمال ڪرڻ کان پاسو ڪريو

شيل ماڊل استعمال ڪرڻ جي نتيجي ۾ هڪ لازمي وضاحت جي مثال جي بدران، بيان ڪندڙ هڪ جي بدران، جيڪو جواب ڏيڻ وارو بنيادي آهي.

ماليڪيول ذريعي پنهنجا ڪردار آزمايو

ماليڪيول هڪ تمام لچڪدار شيءِ آهي، اچو ته چند منظرنامي تي نظر وجهون.

ماليڪيول گھڻن مثالن

В 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

پيچيده منطق کي ماڊلز ۽ پلگ ان ۾ وجھو

جوابي وڪيل هڪ اعلاناتي طريقي جي حمايت ڪري ٿو، تنهنڪري جڏهن توهان ڪوڊ برانچنگ، ڊيٽا جي تبديلي، شيل ماڊلز، ڪوڊ پڙهڻ ڏکيو ٿي ويندو آهي. هن کي منهن ڏيڻ ۽ سمجهڻ لاءِ سادو رکڻ لاءِ، ان پيچيدگيءَ کي منهن ڏيڻ لاءِ پنهنجون ماڊلز ٺاهڻ جي ضرورت نه پوندي.

تجويزون ۽ ترڪيبون اختصار ڪريو

1. عالمي متغيرن کان پاسو ڪريو.
2. اڳوڻو ڪردار متغير.
3. لوپ ڪنٽرول متغير استعمال ڪريو.
4. ان پٽ متغير چيڪ ڪريو.
5. هيش ڊڪشنري کان پاسو ڪريو، فليٽ ڍانچي استعمال ڪريو.
6. تخليقي راند ڪتاب ۽ ڪردار ٺاهيو.
7. ڪمانڊ شيل ماڊل استعمال ڪرڻ کان پاسو ڪريو.
8. ماليڪيول ذريعي پنهنجا ڪردار آزمايو.
9. پيچيده منطق کي ماڊلز ۽ پلگ ان ۾ وجھو.

ٿڪل

توهان صرف وڃي نٿا سگهو ۽ هڪ منصوبي تي انفراسٽرڪچر کي ريفيڪٽر ڪري سگهو ٿا، جيتوڻيڪ توهان وٽ IaC آهي. اهو هڪ ڊگهو عمل آهي جنهن کي صبر، وقت ۽ علم جي ضرورت آهي.

لنڪس

• Slides جوابي ٽيسٽ ڪيئن ڪجي ۽ مايوس نه ٿيو
• وڊيو جوابي ٽيسٽ ڪيئن ڪجي ۽ مايوس نه ٿيو
• ڇا مون 200 لائنن جي انفراسٽرڪچر ڪوڊ جي جاچ ڪرڻ مان سکيو
• جواب: 120 VM ترتيب جي لڏپلاڻ Coreos کان Centos تائين 18 مهينن ۾
• توهان جي ورڇ کي جانچڻ دوران ڪچين مٿان سائيڪلن کي ڪيئن ٽوڙڻ
• مون کي آزمايو ته ڇا توهان ڪري سگهو ٿا يا ڪري سگهو ٿا YML پروگرامر ٽيسٽ ڪرڻ جا خواب جواب ڏيڻ وارا؟
• شاندار IaC جاچ مضمونن جي فهرست، تقريرون ۽ لنڪس
• ڪراس پوسٽ
• انگريزي ورزن

UPD1 2020.05.01 20:30 - راندين جي ڪتابن جي پرائمري پروفائلنگ لاءِ توھان استعمال ڪري سگھو ٿا callback_whitelist = profile_tasks سمجھڻ لاءِ ته ڇا واقعي ڊگهي وقت تائين ڪم ڪري ٿو. پوء اسان جي ذريعي وڃو جوابي تيز رفتار ڪلاس. توهان به ڪوشش ڪري سگهو ٿا mitogen
UPD2 2020.05.03 16:34 - انگريزي ورزن

جو ذريعو: www.habr.com