نقطہ نظر IAC (انفراسٹرکچر بطور کوڈ) نہ صرف اس کوڈ پر مشتمل ہوتا ہے جو ریپوزٹری میں محفوظ ہوتا ہے بلکہ اس کوڈ کے ارد گرد موجود لوگوں اور عمل پر بھی مشتمل ہوتا ہے۔ کیا سافٹ ویئر ڈویلپمنٹ سے لے کر انفراسٹرکچر مینجمنٹ اور تفصیل تک کے طریقوں کو دوبارہ استعمال کرنا ممکن ہے؟ مضمون پڑھتے وقت اس خیال کو ذہن میں رکھنا اچھا ہوگا۔

انگریزی ورژن

یہ میرا ایک ٹرانسکرپٹ ہے۔ پرفارمنس پر DevopsConf 2019-05-28.

سلائیڈز اور ویڈیوز

• انگریزی ورژن
• روسی ورژن
• ڈرائی رن 2019-04-24 SpbLUG
• DevopsConf 2019-05-28 سے ویڈیو(RU)
• DINS DevOps شام 2019-06-20 سے ویڈیو(RU)
• سلائیڈیں

بنیادی ڈھانچہ بطور باش ہسٹری

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

کچھ خواہش کے ساتھ، ہم یہ کہہ سکتے ہیں بنیادی ڈھانچہ بطور باش ہسٹری یہ کوڈ کی طرح ہے:

1. تولیدی صلاحیت: آپ bash ہسٹری لے سکتے ہیں، وہاں سے کمانڈ چلا سکتے ہیں، اور آپ کو، ویسے بھی، آؤٹ پٹ کے طور پر ورکنگ کنفیگریشن مل سکتی ہے۔
2. ورژن بنانا: آپ جانتے ہیں کہ کون اندر آیا اور انہوں نے کیا کیا، ایک بار پھر، یہ حقیقت نہیں ہے کہ یہ آپ کو باہر نکلتے وقت ایک ورکنگ کنفیگریشن کی طرف لے جائے گا۔
3. история: کہانی کس نے کیا کیا۔ اگر آپ سرور کھو دیتے ہیں تو صرف آپ اسے استعمال نہیں کر پائیں گے۔

کیا کیا جائے؟

بنیادی ڈھانچہ بطور ضابطہ

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

خشک

اسٹوریج سسٹم ڈویلپمنٹ پروجیکٹ پر، ایک ذیلی کام تھا۔ وقتاً فوقتاً SDS ترتیب دیں۔: ہم ایک نئی ریلیز جاری کر رہے ہیں - اسے مزید جانچ کے لیے رول آؤٹ کرنے کی ضرورت ہے۔ کام بہت آسان ہے:

• ssh کے ذریعے یہاں لاگ ان کریں اور کمانڈ پر عمل کریں۔
• وہاں فائل کاپی کریں۔
• یہاں ترتیب کو درست کریں۔
• وہاں سروس شروع کریں
• ...
• منافع!

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

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

CFM کے لیے ٹھوس

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

واحد ذمہ داری کا اصول

ہر کلاس صرف ایک کام کرتی ہے۔

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

کھلا بند اصول

کھلا/بند اصول۔

• توسیع کے لیے کھلا: کا مطلب ہے کہ کسی ہستی کے طرز عمل کو نئی ہستی کی قسمیں بنا کر بڑھایا جا سکتا ہے۔
• تبدیلی کے لیے بند: کسی ہستی کے رویے میں توسیع کے نتیجے میں، ان اداروں کو استعمال کرنے والے کوڈ میں کوئی تبدیلی نہیں کی جانی چاہیے۔

ابتدائی طور پر، ہم نے ٹیسٹ کے بنیادی ڈھانچے کو ورچوئل مشینوں پر تعینات کیا، لیکن اس حقیقت کی وجہ سے کہ تعیناتی کی کاروباری منطق عمل درآمد سے الگ تھی، ہم نے بغیر کسی پریشانی کے baremetall میں رول آؤٹ شامل کیا۔

لسکوف متبادل اصول

باربرا لیسکوف کا متبادل اصول۔ کسی پروگرام میں موجود اشیاء کو پروگرام کے درست عمل کو تبدیل کیے بغیر ان کی ذیلی قسموں کی مثالوں کے ساتھ تبدیل کیا جاسکتا ہے۔

اگر آپ اسے مزید وسیع پیمانے پر دیکھیں تو یہ کسی خاص پروجیکٹ کی خصوصیت نہیں ہے جسے وہاں لاگو کیا جاسکے ٹھوس، یہ عام طور پر CFM کے بارے میں ہوتا ہے، مثال کے طور پر، کسی دوسرے پروجیکٹ پر مختلف جاوا، ایپلیکیشن سرورز، ڈیٹا بیس، OS، وغیرہ کے اوپر ایک باکسڈ جاوا ایپلیکیشن تعینات کرنا ضروری ہے۔ اس مثال کو استعمال کرتے ہوئے، میں مزید اصولوں پر غور کروں گا۔ ٹھوس

ہمارے معاملے میں، انفراسٹرکچر ٹیم کے اندر ایک معاہدہ ہے کہ اگر ہم نے imbjava یا oraclejava رول انسٹال کیا ہے، تو ہمارے پاس جاوا بائنری قابل عمل ہے۔ یہ ضروری ہے کیونکہ اپ اسٹریم رول اس طرز عمل پر منحصر ہے؛ وہ جاوا کی توقع کرتے ہیں۔ ایک ہی وقت میں، یہ ہمیں ایپلیکیشن کی تعیناتی منطق کو تبدیل کیے بغیر ایک جاوا نفاذ/ورژن کو دوسرے سے تبدیل کرنے کی اجازت دیتا ہے۔

یہاں مسئلہ یہ ہے کہ جواب میں اس کو نافذ کرنا ناممکن ہے، جس کے نتیجے میں ٹیم کے اندر کچھ معاہدے ظاہر ہوتے ہیں۔

انٹرفیس سیگریگیشن کا اصول

انٹرفیس علیحدگی کا اصول: "کئی کلائنٹ کے مخصوص انٹرفیس ایک عام مقصد والے انٹرفیس سے بہتر ہیں۔

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

انحصار الٹا اصول

انحصار الٹنے کا اصول۔ اعلی سطح پر ماڈیولز کو نچلی سطح پر ماڈیولز پر انحصار نہیں کرنا چاہیے۔ دونوں قسم کے ماڈیولز کا انحصار تجرید پر ہونا چاہیے۔ خلاصہ تفصیلات پر منحصر نہیں ہونا چاہئے۔ تفصیلات کا انحصار تجرید پر ہونا چاہیے۔

یہاں مثال اینٹی پیٹرن پر مبنی ہوگی۔

1. گاہکوں میں سے ایک کے پاس نجی کلاؤڈ تھا۔
2. ہم نے کلاؤڈ کے اندر ورچوئل مشینوں کا آرڈر دیا۔
3. لیکن بادل کی نوعیت کی وجہ سے، ایپلیکیشن کی تعیناتی اس سے منسلک تھی کہ VM کس ہائپر وائزر پر تھا۔

وہ. ہائی لیول ایپلیکیشن کی تعیناتی منطق ہائپر وائزر کی نچلی سطح پر انحصار کے ساتھ بہتی تھی، اور اس منطق کو دوبارہ استعمال کرتے وقت اس کا مطلب تھا۔ اس طرح مت کرو۔

انٹریکشن

کوڈ کے طور پر بنیادی ڈھانچہ صرف کوڈ کے بارے میں نہیں ہے، بلکہ کوڈ اور لوگوں کے درمیان تعلقات، بنیادی ڈھانچے کے ڈویلپرز کے درمیان تعامل کے بارے میں بھی ہے۔

بس عنصر

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

جوڑی ڈیوپسنگ

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

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

کوڈ کا جائزہ

موضوعی طور پر، بنیادی ڈھانچے کے بارے میں علم کو پھیلانا اور کوڈ کا جائزہ لینے کے استعمال سے یہ کیسے کام کرتا ہے زیادہ مؤثر تھا:

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

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

کوڈ سٹائل۔

وقت گزرنے کے ساتھ، جائزوں کے دوران جھگڑے ظاہر ہونے لگے، کیونکہ... جائزہ لینے والوں کا اپنا انداز تھا اور جائزہ لینے والوں کی گردش نے انہیں مختلف اندازوں سے سجا دیا: 2 خالی جگہیں یا 4، کیمل کیس یا سانپ_کیس۔ اس پر فوری عمل درآمد ممکن نہیں تھا۔

• پہلا خیال یہ تھا کہ لنٹر استعمال کرنے کا مشورہ دیا جائے، آخر ہر کوئی انجینئر ہے، ہر کوئی ہوشیار ہے۔ لیکن مختلف ایڈیٹرز، OS، آسان نہیں ہیں۔
• یہ ایک بوٹ میں تیار ہوا جس نے ہر مشکل کام کے لئے سست کرنے کے لئے لکھا اور لنٹر آؤٹ پٹ کو منسلک کیا۔ لیکن زیادہ تر معاملات میں کرنے کے لیے زیادہ اہم چیزیں تھیں اور کوڈ غیر طے شدہ رہا۔

گرین بلڈ ماسٹر

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

• ایک الگ شاخ میں ترقی جاری ہے۔
• اس تھریڈ پر ٹیسٹ چل رہے ہیں۔
• اگر ٹیسٹ ناکام ہو جاتے ہیں، تو کوڈ اسے ماسٹر میں نہیں بنائے گا۔

یہ فیصلہ کرنا بہت تکلیف دہ تھا کیونکہ... بہت زیادہ تنازعہ پیدا ہوا، لیکن یہ اس کے قابل تھا، کیونکہ... جائزوں کو انداز میں فرق کے بغیر انضمام کی درخواستیں موصول ہونا شروع ہوئیں، اور وقت کے ساتھ ساتھ مسائل کے علاقوں کی تعداد کم ہونے لگی۔

آئی اے سی ٹیسٹنگ

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

کوئی پوچھ سکتا ہے کہ پیچیدہ بنیادی ڈھانچے کو مزید پیچیدہ کیوں بنایا جائے؟ بنیادی ڈھانچے کے ٹیسٹ، بالکل کوڈ کی طرح، آسان بنانے کے بارے میں نہیں ہیں، بلکہ یہ جاننے کے بارے میں ہیں کہ آپ کے بنیادی ڈھانچے کو کیسے کام کرنا چاہیے۔

IaC ٹیسٹنگ اہرام

IaC ٹیسٹنگ: جامد تجزیہ

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

باش مشکل ہے۔

آئیے ایک معمولی سی مثال دیکھتے ہیں۔ موجودہ ڈائرکٹری میں تمام فائلوں کو منتخب کریں اور کسی دوسرے مقام پر کاپی کریں۔ پہلی چیز جو ذہن میں آتی ہے:

for i in * ; do 
    cp $i /some/path/$i.bak
done

اگر فائل کے نام میں جگہ ہے تو کیا ہوگا؟ ٹھیک ہے، ٹھیک ہے، ہم ہوشیار ہیں، ہم اقتباسات کو استعمال کرنا جانتے ہیں:

for i in * ; do cp "$i" "/some/path/$i.bak" ; done

بہت اچھے؟ نہیں! کیا ہوگا اگر ڈائریکٹری میں کچھ بھی نہ ہو، یعنی گلوبنگ کام نہیں کرے گا۔

find . -type f -exec mv -v {} dst/{}.bak ;

اچھا کیا اب؟ نہیں... بھول گئے کہ فائل کے نام میں کیا ہو سکتا ہے۔ n.

touch x
mv x  "$(printf "foonbar")"
find . -type f -print0 | xargs -0 mv -t /path/to/target-dir

جامد تجزیہ کے اوزار

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

زبان
کا آلہ

مار
شیل چیک

روبی
RuboCop

پادری
پائیلنٹ

جواب دہ
جوابدہ لنٹ

IaC ٹیسٹنگ: یونٹ ٹیسٹ

جیسا کہ ہم نے پچھلی مثال سے دیکھا، لنٹر قادر مطلق نہیں ہیں اور تمام مسائل کی نشاندہی نہیں کر سکتے۔ مزید، سافٹ ویئر ڈویلپمنٹ میں جانچ کے ساتھ مشابہت سے، ہم یونٹ ٹیسٹ کو یاد کر سکتے ہیں۔ یہاں فوراً ذہن میں آتا ہے۔ shunit, جونیٹ, آر ایس پی سی, پائی ٹسٹ. لیکن جوابدہ، شیف، سالٹ اسٹیک اور ان جیسے دوسرے لوگوں کا کیا کیا جائے؟

شروع میں ہی ہم نے بات کی تھی۔ ٹھوس اور یہ کہ ہمارا بنیادی ڈھانچہ چھوٹی اینٹوں پر مشتمل ہونا چاہیے۔ ان کا وقت آ گیا ہے۔

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

IaC ٹیسٹنگ: یونٹ ٹیسٹنگ ٹولز

سوال، CFM کے ٹیسٹ کیا ہیں؟ آپ آسانی سے اسکرپٹ چلا سکتے ہیں، یا آپ اس کے لیے تیار حل استعمال کر سکتے ہیں:

CFM
کا آلہ

ناممکن
ٹیسٹینفرا

شیف
انسپک

شیف
سرور اسپیک

نمکیات
گاس

testinfra کی مثال، صارفین کو چیک کرنا test1, test2 موجود ہیں اور ایک گروپ میں ہیں۔ sshusers:

def test_default_users(host):
    users = ['test1', 'test2' ]
    for login in users:
        assert host.user(login).exists
        assert 'sshusers' in host.user(login).groups

کیا انتخاب کرنا ہے؟ سوال پیچیدہ اور مبہم ہے، یہاں گیتھب پر 2018-2019 کے منصوبوں میں تبدیلیوں کی ایک مثال ہے۔

IaC ٹیسٹنگ فریم ورک

سوال یہ پیدا ہوتا ہے کہ یہ سب ایک ساتھ کیسے لایا جائے اور اسے لانچ کیا جائے؟ کر سکتے ہیں۔ اسے لے لو اور خود کرو اگر انجینئرز کی کافی تعداد موجود ہے۔ یا آپ تیار حل لے سکتے ہیں، حالانکہ ان میں سے بہت زیادہ نہیں ہیں:

CFM
کا آلہ

ناممکن
انو

شیف
ٹیسٹ کچن۔

ٹرافیفار
ٹیرٹیسٹ

2018-2019 کے لیے گیتھب پر پروجیکٹس میں تبدیلیوں کی مثال:

مالیکیول بمقابلہ ٹیسٹ کچن

ابتدائی طور پر ہم ٹیسٹ کچن استعمال کرنے کی کوشش کی۔:

1. متوازی طور پر ایک VM بنائیں۔
2. جوابدہ کرداروں کا اطلاق کریں۔
3. معائنہ چلائیں۔

25-35 کرداروں کے لیے اس نے 40-70 منٹ کام کیا، جو طویل تھا۔

اگلا مرحلہ جینکنز/ڈوکر/اینسیبل/مولیکیول میں منتقلی تھا۔ نظریاتی طور پر سب کچھ ایک جیسا ہے۔

1. لنٹ پلے بکس۔
2. کرداروں کو ترتیب دیں۔
3. کنٹینر لانچ کریں۔
4. جوابدہ کرداروں کا اطلاق کریں۔
5. testinfra چلائیں۔
6. کمزوری کی جانچ کریں۔

40 کرداروں کے لیے لنٹنگ اور ایک درجن کے لیے ٹیسٹ میں تقریباً 15 منٹ لگنے لگے۔

کیا منتخب کرنا ہے اس کا انحصار بہت سے عوامل پر ہوتا ہے، جیسے استعمال شدہ اسٹیک، ٹیم میں مہارت وغیرہ۔ یہاں ہر کوئی خود فیصلہ کرتا ہے کہ یونٹ ٹیسٹنگ سوال کو کیسے بند کیا جائے۔

IaC ٹیسٹنگ: انٹیگریشن ٹیسٹ

انفراسٹرکچر ٹیسٹنگ اہرام میں اگلا مرحلہ انضمام ٹیسٹ ہوگا۔ وہ یونٹ ٹیسٹ سے ملتے جلتے ہیں:

1. بنیادی ڈھانچے کو چھوٹی اینٹوں میں تقسیم کیا گیا ہے، مثال کے طور پر جوابی کردار۔
2. کسی قسم کا ماحول تعینات کیا جاتا ہے، چاہے وہ ڈاکر ہو یا VM۔
3. اس امتحانی ماحول کے لیے درخواست دیں۔ بہت سے جوابدہ کردار۔
4. ہم چیک کرتے ہیں کہ ہر چیز ہماری توقع کے مطابق کام کرتی ہے (ہم ٹیسٹ چلاتے ہیں)۔
5. ہم فیصلہ کرتے ہیں کہ ٹھیک ہے یا نہیں۔

موٹے طور پر، ہم سسٹم کے انفرادی عنصر کی کارکردگی کی جانچ نہیں کرتے جیسا کہ یونٹ ٹیسٹوں میں ہوتا ہے، ہم یہ چیک کرتے ہیں کہ سرور کو مجموعی طور پر کس طرح ترتیب دیا گیا ہے۔

IaC ٹیسٹنگ: اینڈ ٹو اینڈ ٹیسٹ

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

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

اس سکیم نے فریم ورک کے اندر تک کافی عرصے تک کام کیا۔ تحقیق ہم نے اسے Openshift میں منتقل کرنے کی کوشش نہیں کی ہے۔ کنٹینرز وہی ہیں، لیکن لانچ کا ماحول بدل گیا ہے (ہیلو DRY دوبارہ)۔

تحقیقی خیال مزید آگے بڑھا، اور اوپن شفٹ میں انہیں APB (Ansible Playbook Bundle) جیسی چیز ملی، جو آپ کو کنٹینر میں انفراسٹرکچر کو کیسے تعینات کرنے کے بارے میں علم پیک کرنے کی اجازت دیتی ہے۔ وہ. بنیادی ڈھانچے کو کیسے تعینات کرنا ہے اس کے بارے میں علم کا ایک قابل دہرایا جا سکتا ہے، جانچنے کے قابل نقطہ ہے۔

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

نتیجہ

بنیادی ڈھانچہ جیسا کہ کوڈ ہے۔

• ذخیرہ میں کوڈ۔
• انسانی تعامل۔
• انفراسٹرکچر ٹیسٹنگ۔

لنکس

• انگریزی ایڈیشن
• ذاتی بلاگ سے کراس پوسٹ
• ڈرائی رن 2019-04-24 SpbLUG
• DevopsConf 2019-05-28 سے ویڈیو(RU)
• DINS DevOps شام 2019-06-20 سے ویڈیو(RU)
• انفراسٹرکچر کوڈ کی 300,000 لائنوں سے زیادہ لکھنے سے سیکھے گئے اسباق & متن ورژن
• ایک مسلسل ڈیلیوری پائپ لائن میں بنیادی ڈھانچے کو کوڈ کے طور پر ضم کرنا
• کوڈ کے طور پر بنیادی ڈھانچے کی جانچ کرنا
• جوابدہ کرداروں کی مؤثر ترقی اور دیکھ بھال
• جواب دہ نہیں ہے!

ماخذ: www.habr.com