پرو ہوسٹر > بلاگ > انتظامیہ > جواب دینے والے کی جانچ کیسے شروع کی جائے، ایک سال میں پروجیکٹ کو ری ایکٹر کریں اور پاگل نہ ہوں۔

جواب دینے والے کی جانچ کیسے شروع کی جائے، ایک سال میں پروجیکٹ کو ری ایکٹر کریں اور پاگل نہ ہوں۔

جواب دینے والے کی جانچ کیسے شروع کی جائے، ایک سال میں پروجیکٹ کو ری ایکٹر کریں اور پاگل نہ ہوں۔

یہ نقل ہے۔ پرفارمنس پر 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: کیا آپ کو واقعی ری فیکٹرنگ کی ضرورت ہے؟

جواب دینے والے کی جانچ کیسے شروع کی جائے، ایک سال میں پروجیکٹ کو ری ایکٹر کریں اور پاگل نہ ہوں۔

ریفیکٹر پر جلدی کرنے سے پہلے، آپ کو کئی اہم سوالات کے جوابات دینے چاہئیں:

  1. آپ کو اس سب کی ضرورت کیوں ہے؟
  2. کیا اپ کے پاس وقت ہے؟
  3. کیا علم کافی ہے؟

اگر آپ نہیں جانتے کہ سوالوں کا جواب کیسے دینا ہے، تو ری فیکٹرنگ شروع ہونے سے پہلے ہی ختم ہو جائے گی، یا یہ مزید خراب ہو سکتی ہے۔ کیونکہ تجربہ تھا( میں نے انفراسٹرکچر کوڈ کی 200 لائنوں کی جانچ سے کیا سیکھا۔)، پھر پروجیکٹ کو کرداروں کو ٹھیک کرنے اور ٹیسٹ کے ساتھ ان کا احاطہ کرنے میں مدد کی درخواست موصول ہوئی۔

دن #149: ری فیکٹرنگ کی تیاری

جواب دینے والے کی جانچ کیسے شروع کی جائے، ایک سال میں پروجیکٹ کو ری ایکٹر کریں اور پاگل نہ ہوں۔

پہلی چیز تیار کرنا ہے۔ فیصلہ کریں کہ ہم کیا کریں گے۔ ایسا کرنے کے لیے، ہم بات چیت کرتے ہیں، مسائل کے علاقے تلاش کرتے ہیں اور ان کو حل کرنے کے طریقے تلاش کرتے ہیں۔ ہم نتیجہ خیز تصورات کو کسی نہ کسی طرح ریکارڈ کرتے ہیں، مثال کے طور پر سنگم میں ایک مضمون، تاکہ جب یہ سوال پیدا ہو کہ "بہترین کیا ہے؟" یا "کون سا صحیح ہے؟" ہم اپنا راستہ نہیں بھولے۔ ہمارے معاملے میں، ہم خیال پر پھنس گئے تقسیم کرو اور حکومت کرو: ہم بنیادی ڈھانچے کو چھوٹے ٹکڑوں/اینٹوں میں توڑ دیتے ہیں۔ یہ نقطہ نظر آپ کو بنیادی ڈھانچے کا ایک الگ تھلگ حصہ لینے، یہ سمجھنے، اسے ٹیسٹوں سے ڈھانپنے اور کسی بھی چیز کے ٹوٹنے کے خوف کے بغیر اسے تبدیل کرنے کی اجازت دیتا ہے۔

جواب دینے والے کی جانچ کیسے شروع کی جائے، ایک سال میں پروجیکٹ کو ری ایکٹر کریں اور پاگل نہ ہوں۔

یہ پتہ چلتا ہے کہ بنیادی ڈھانچے کی جانچ بنیاد بن جاتی ہے اور یہاں بنیادی ڈھانچے کی جانچ کے اہرام کا ذکر کرنا ضروری ہے۔ بالکل وہی خیال جو ترقی میں ہے، لیکن انفراسٹرکچر کے لیے: ہم سستے فوری ٹیسٹوں سے آگے بڑھ رہے ہیں جو سادہ چیزوں کو چیک کرتے ہیں، جیسے انڈینٹیشن، مہنگے مکمل ٹیسٹوں کی طرف جو پورے انفراسٹرکچر کو تعینات کرتے ہیں۔

جوابدہ جانچ کی کوششیں۔

اس سے پہلے کہ ہم یہ بیان کرنے جائیں کہ ہم نے پروجیکٹ پر جوابی ٹیسٹوں کا احاطہ کیسے کیا، میں ان کوششوں اور طریقوں کی وضاحت کروں گا جن کا مجھے پہلے استعمال کرنے کا موقع ملا تاکہ کیے گئے فیصلوں کے سیاق و سباق کو سمجھ سکیں۔

دن نمبر -997: SDS کی فراہمی

جواب دینے والے کی جانچ کیسے شروع کی جائے، ایک سال میں پروجیکٹ کو ری ایکٹر کریں اور پاگل نہ ہوں۔

پہلی بار جب میں نے Ansible کا تجربہ کیا وہ SDS (سافٹ ویئر ڈیفائنڈ سٹوریج) تیار کرنے کے پروجیکٹ پر تھا۔ اس موضوع پر ایک الگ مضمون ہے۔
اپنی ڈسٹری بیوشن کی جانچ کرتے وقت سائیکلوں کو بیساکھیوں پر کیسے توڑا جائے۔لیکن مختصراً، ہم نے ایک الٹی ٹیسٹنگ اہرام کے ساتھ اختتام کیا اور ٹیسٹنگ میں ہم نے ایک رول پر 60-90 منٹ گزارے، جو کہ ایک طویل وقت ہے۔ بنیاد e2e ٹیسٹ تھا، یعنی ہم نے ایک مکمل تنصیب کو تعینات کیا اور پھر اس کا تجربہ کیا۔ اس سے بھی زیادہ پریشان کن بات ان کی اپنی سائیکل کی ایجاد تھی۔ لیکن مجھے تسلیم کرنا چاہیے، اس حل نے کام کیا اور مستحکم رہائی کی اجازت دی۔

دن # -701: جوابدہ اور ٹیسٹ کچن

جواب دینے والے کی جانچ کیسے شروع کی جائے، ایک سال میں پروجیکٹ کو ری ایکٹر کریں اور پاگل نہ ہوں۔

جواب دہ جانچ کے آئیڈیا کی ترقی کے لیے تیار شدہ ٹولز کا استعمال تھا، یعنی ٹیسٹ کچن/کچن-سی اور معائنہ۔ انتخاب کا تعین روبی کے علم سے کیا گیا تھا (مزید تفصیلات کے لیے، Habré پر مضمون دیکھیں: کیا YML پروگرامرز جوابی ٹیسٹنگ کا خواب دیکھتے ہیں؟) نے تیزی سے کام کیا، 40 کرداروں کے لیے تقریباً 10 منٹ۔ ہم نے ورچوئل مشینوں کا ایک پیکٹ بنایا اور اندر ہی ٹیسٹ چلائے۔

جواب دینے والے کی جانچ کیسے شروع کی جائے، ایک سال میں پروجیکٹ کو ری ایکٹر کریں اور پاگل نہ ہوں۔

عام طور پر، حل نے کام کیا، لیکن تفاوت کی وجہ سے کچھ تلچھٹ موجود تھی۔ جب ٹیسٹ کیے گئے لوگوں کی تعداد بڑھا کر 13 بنیادی کرداروں اور 2 میٹا رولز کو ملا کر چھوٹے کرداروں کو ملایا گیا تو اچانک ٹیسٹ 70 منٹ تک چلنے لگے جو تقریباً 2 گنا زیادہ ہے۔ XP (انتہائی پروگرامنگ) کے طریقوں کے بارے میں بات کرنا مشکل تھا کیونکہ... کوئی بھی 70 منٹ انتظار نہیں کرنا چاہتا۔ نقطہ نظر کو تبدیل کرنے کی وجہ یہ تھی۔

دن # -601: جوابدہ اور مالیکیول

جواب دینے والے کی جانچ کیسے شروع کی جائے، ایک سال میں پروجیکٹ کو ری ایکٹر کریں اور پاگل نہ ہوں۔

تصوراتی طور پر، یہ ٹیسٹ کچن کی طرح ہے، صرف ہم نے رول ٹیسٹنگ کو ڈوکر میں منتقل کیا اور اسٹیک کو تبدیل کیا۔ نتیجے کے طور پر، 20 کرداروں کے لیے وقت کو 25-7 منٹ تک کم کر دیا گیا۔

جواب دینے والے کی جانچ کیسے شروع کی جائے، ایک سال میں پروجیکٹ کو ری ایکٹر کریں اور پاگل نہ ہوں۔

آزمائشی کرداروں کی تعداد کو 17 تک بڑھا کر اور 45 کرداروں کو لِنٹ کر کے، ہم نے اسے 28 منٹ میں جینکنز کے 2 غلاموں پر چلایا۔

دن #167: پروجیکٹ میں جوابدہ ٹیسٹ شامل کرنا

جواب دینے والے کی جانچ کیسے شروع کی جائے، ایک سال میں پروجیکٹ کو ری ایکٹر کریں اور پاگل نہ ہوں۔

زیادہ تر امکان ہے کہ ری فیکٹرنگ کا کام جلدی میں کرنا ممکن نہیں ہوگا۔ کام کی پیمائش ہونی چاہیے تاکہ آپ اسے چھوٹے چھوٹے ٹکڑوں میں توڑ سکیں اور ہاتھی کے ٹکڑے کو ایک چائے کے چمچ سے کھا سکیں۔ اس بات کی سمجھ ہونی چاہیے کہ آیا آپ صحیح سمت میں جا رہے ہیں، کب تک جانا ہے۔

جواب دینے والے کی جانچ کیسے شروع کی جائے، ایک سال میں پروجیکٹ کو ری ایکٹر کریں اور پاگل نہ ہوں۔

عام طور پر، اس سے کوئی فرق نہیں پڑتا کہ یہ کیسے ہوگا، آپ کاغذ کے ٹکڑے پر لکھ سکتے ہیں، آپ الماری پر اسٹیکرز لگا سکتے ہیں، آپ جیرا میں ٹاسک بنا سکتے ہیں، یا آپ Google Docs کھول کر موجودہ صورتحال لکھ سکتے ہیں۔ وہاں. ٹانگیں اس حقیقت سے بڑھتی ہیں کہ یہ عمل فوری طور پر نہیں ہے، یہ طویل اور تکلیف دہ ہو جائے گا. اس بات کا امکان نہیں ہے کہ کوئی بھی یہ چاہے کہ آپ خیالات سے باہر ہو جائیں، تھک جائیں، اور ری فیکٹرنگ کے دوران مغلوب ہو جائیں۔

ری فیکٹرنگ آسان ہے:

  • کھاؤ۔
  • سو جاؤ.
  • کوڈ
  • IaC ٹیسٹ۔
  • دہرائیں

اور ہم اسے اس وقت تک دہراتے ہیں جب تک کہ ہم مطلوبہ مقصد تک نہ پہنچ جائیں۔

جواب دینے والے کی جانچ کیسے شروع کی جائے، ایک سال میں پروجیکٹ کو ری ایکٹر کریں اور پاگل نہ ہوں۔

ہر چیز کی جانچ شروع کرنا ممکن نہیں ہے، اس لیے ہمارا پہلا کام لنٹنگ اور نحو کی جانچ کرنا تھا۔

دن #181: گرین بلڈ ماسٹر

جواب دینے والے کی جانچ کیسے شروع کی جائے، ایک سال میں پروجیکٹ کو ری ایکٹر کریں اور پاگل نہ ہوں۔

لنٹنگ گرین بلڈ ماسٹر کی طرف ایک چھوٹا پہلا قدم ہے۔ اس سے تقریباً کچھ نہیں ٹوٹے گا، لیکن یہ آپ کو جینکنز میں عمل کو ڈیبگ کرنے اور گرین بلڈ بنانے کی اجازت دے گا۔ خیال ٹیم کے درمیان عادات کو فروغ دینا ہے:

  • ریڈ ٹیسٹ خراب ہیں۔
  • میں کچھ ٹھیک کرنے آیا ہوں اور ساتھ ہی کوڈ کو آپ سے پہلے سے تھوڑا بہتر بناؤں گا۔

دن #193: لنٹنگ سے یونٹ ٹیسٹ تک

جواب دینے والے کی جانچ کیسے شروع کی جائے، ایک سال میں پروجیکٹ کو ری ایکٹر کریں اور پاگل نہ ہوں۔

ماسٹر میں کوڈ حاصل کرنے کے عمل کو تیار کرنے کے بعد، آپ مرحلہ وار بہتری کا عمل شروع کر سکتے ہیں - لانچنگ رولز کے ساتھ لنٹنگ کی جگہ لے کر، آپ اسے بے حسی کے بغیر بھی کر سکتے ہیں۔ آپ کو یہ سمجھنے کی ضرورت ہے کہ کرداروں کو کیسے لاگو کرنا ہے اور وہ کیسے کام کرتے ہیں۔

دن #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: ٹیسٹوں کو تیز کرنا

جواب دینے والے کی جانچ کیسے شروع کی جائے، ایک سال میں پروجیکٹ کو ری ایکٹر کریں اور پاگل نہ ہوں۔

وقت گزرنے کے ساتھ ساتھ، مزید ٹیسٹ ہوئے، تعمیرات کی رفتار آہستہ چلی، بدترین صورت میں ایک گھنٹے تک۔ ریٹرو میں سے ایک پر ایک جملہ تھا جیسے "یہ اچھا ہے کہ ٹیسٹ ہیں، لیکن وہ سست ہیں۔" نتیجے کے طور پر، ہم نے ورچوئل مشینوں پر انضمام کے ٹیسٹ کو ترک کر دیا اور اسے تیز تر بنانے کے لیے انہیں Docker کے لیے ڈھال لیا۔ ہم نے استعمال شدہ ٹولز کی تعداد کو کم کرنے کے لیے ٹیسٹینفرا کو جوابی تصدیق کنندہ سے بھی بدل دیا۔

جواب دینے والے کی جانچ کیسے شروع کی جائے، ایک سال میں پروجیکٹ کو ری ایکٹر کریں اور پاگل نہ ہوں۔

سخت الفاظ میں، اقدامات کا ایک سیٹ تھا:

  1. ڈوکر پر سوئچ کریں۔
  2. رول ٹیسٹنگ کو ہٹا دیں، جو انحصار کی وجہ سے ڈپلیکیٹ ہے۔
  3. غلاموں کی تعداد میں اضافہ کریں۔
  4. ٹیسٹ رن آرڈر۔
  5. لنٹ کرنے کی صلاحیت تمام مقامی طور پر ایک کمانڈ کے ساتھ۔

جواب دینے والے کی جانچ کیسے شروع کی جائے، ایک سال میں پروجیکٹ کو ری ایکٹر کریں اور پاگل نہ ہوں۔

نتیجے کے طور پر، جینکنز پر پائپ لائن کو بھی متحد کیا گیا تھا

  1. تعمیر کے مراحل بنائیں۔
  2. تمام کو متوازی طور پر لنٹ کریں۔
  3. ٹیسٹ رول کے مراحل کو متوازی طور پر چلائیں۔
  4. ختم کرو.

سیکھا اسباق

عالمی متغیرات سے بچیں۔

جوابدہ عالمی متغیرات کا استعمال کرتا ہے، فارم میں ایک جزوی حل موجود ہے۔ نجی_کردار_وارلیکن یہ کوئی علاج نہیں ہے۔

میں آپ کو ایک مثال دیتا ہوں۔ ہمارے پاس ہے 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 }}"

ناقابل یقین پلے بکس اور کردار بنائیں

کرداروں اور پلے بکس کو بے ضمیر ہونا چاہیے، کیونکہ کنفیگریشن ڈرفٹ اور کسی چیز کے ٹوٹنے کے خوف کو کم کرتا ہے۔ لیکن اگر آپ مالیکیول استعمال کرتے ہیں، تو یہ پہلے سے طے شدہ سلوک ہے۔

کمانڈ شیل ماڈیول استعمال کرنے سے گریز کریں۔

شیل ماڈیول کے استعمال کے نتیجے میں اعلانیہ کی بجائے ایک لازمی وضاحتی نمونہ بنتا ہے، جو جواب کا بنیادی حصہ ہے۔

مالیکیول کے ذریعے اپنے کردار کی جانچ کریں۔

مالیکیول بہت لچکدار چیز ہے، آئیے چند منظرنامے دیکھتے ہیں۔

مالیکیول ایک سے زیادہ مثالیں۔

В 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 ہو۔ یہ ایک طویل عمل ہے جس میں صبر، وقت اور علم کی ضرورت ہوتی ہے۔

UPD1 2020.05.01 20:30 - پلے بکس کی بنیادی پروفائلنگ کے لیے آپ استعمال کر سکتے ہیں۔ callback_whitelist = profile_tasks یہ سمجھنے کے لیے کہ طویل عرصے تک کیا کام کرتا ہے۔ پھر ہم گزرتے ہیں۔ جوابدہ ایکسلریشن کلاسیکی. آپ بھی کوشش کر سکتے ہیں۔ mitogen
UPD2 2020.05.03 16:34 - انگریزی ورژن

ماخذ: www.habr.com

نیا تبصرہ شامل کریں