بنیادی ڈھانچہ بطور کوڈ: پہلا تعارف

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

ہماری داخلی تقریب میں تقاریر کی بنیاد پر لکھے گئے مضامین کے سلسلے کا تسلسل ڈیوفورم:

1. شروڈنگر کی بلی بغیر باکس کے: تقسیم شدہ نظاموں میں اتفاق رائے کا مسئلہ۔
2. بنیادی ڈھانچہ بطور کوڈ۔ (آپ یہاں ہیں)
3. C# ماڈلز کا استعمال کرتے ہوئے ٹائپ اسکرپٹ معاہدوں کی تخلیق۔ (کام جاری ہے...)
4. Raft اتفاق رائے الگورتھم کا تعارف۔ (کام جاری ہے...)
...

ہم نے آئیڈیاز کو نافذ کرتے ہوئے ایک SRE ٹیم بنانے کا فیصلہ کیا۔ گوگل sre. انہوں نے اپنے ڈویلپرز میں سے پروگرامرز کو بھرتی کیا اور انہیں کئی مہینوں کی تربیت کے لیے بھیجا۔

ٹیم کے پاس درج ذیل تربیتی کام تھے:

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

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

دنیا کے معمول کے ماڈل (کلاسیکی انتظامیہ) میں، بنیادی ڈھانچے کے بارے میں علم دو جگہوں پر موجود ہے:

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

دونوں صورتوں میں، ہم خود کو انحصار کرنے میں پھنسے ہوئے پاتے ہیں:

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

یہ کہنے کے بغیر جاتا ہے کہ مثالی طور پر ہر چیز کا ترجمہ انسانی پڑھنے کے قابل، برقرار رکھنے کے قابل، اچھی طرح سے لکھے گئے کوڈ میں کیا جانا چاہیے۔

اس طرح، انفراسٹرکچر بطور کوڈ (Incfastructure as Code - IaC) کوڈ کی شکل میں پورے موجودہ انفراسٹرکچر کی تفصیل ہے، نیز اس کے ساتھ کام کرنے اور اس سے حقیقی انفراسٹرکچر کو نافذ کرنے کے لیے متعلقہ ٹولز۔

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

نئے SRE انجینئر کہاں سے آتے ہیں؟لہذا، ہم نے نئے SRE انجینئرز کی خدمات حاصل کرنے کا فیصلہ کیا، لیکن انہیں کہاں سے حاصل کیا جائے؟ صحیح جوابات کے ساتھ کتابگوگل ایس آر ای بک) ہمیں بتاتا ہے: ڈویلپرز سے۔ سب کے بعد، وہ کوڈ کے ساتھ کام کرتے ہیں، اور آپ مثالی ریاست حاصل کرتے ہیں.

ہم نے اپنی کمپنی کے باہر پرسنل مارکیٹ میں ان کے لیے کافی دیر تک تلاش کی۔ لیکن ہمیں یہ تسلیم کرنا پڑے گا کہ ہمیں کوئی ایسا نہیں ملا جو ہماری درخواستوں کے مطابق ہو۔ مجھے اپنے ہی لوگوں میں تلاش کرنا پڑا۔

کوڈ کے طور پر بنیادی ڈھانچے کے مسائل

اب آئیے مثالوں کو دیکھتے ہیں کہ کس طرح بنیادی ڈھانچے کو کوڈ میں ہارڈ کوڈ کیا جا سکتا ہے۔ کوڈ اچھی طرح سے لکھا گیا ہے، اعلی معیار کا، تبصرے اور اشارے کے ساتھ۔

Terraforma سے مثال کوڈ۔

جوابی کوڈ کی مثال۔

حضرات، کاش یہ اتنا آسان ہوتا! ہم حقیقی دنیا میں ہیں، اور یہ ہمیشہ آپ کو حیران کرنے، آپ کو حیرت اور پریشانیوں کے ساتھ پیش کرنے کے لیے تیار ہے۔ یہاں بھی ان کے بغیر نہیں چل سکتا۔

1. پہلا مسئلہ یہ ہے کہ زیادہ تر معاملات میں IaC کسی قسم کا dsl ہے۔

اور ڈی ایس ایل، بدلے میں، ساخت کی تفصیل ہے۔ مزید واضح طور پر، آپ کے پاس کیا ہونا چاہئے: Json، Yaml، کچھ بڑی کمپنیوں کی ترمیم جو اپنے ڈی ایس ایل کے ساتھ آئی ہیں (HCL ٹیرافارم میں استعمال ہوتا ہے)۔

مصیبت یہ ہے کہ اس میں آسانی سے ایسی واقف چیزیں شامل نہیں ہوسکتی ہیں جیسے:

• متغیرات
• حالات؛
• کہیں کوئی تبصرے نہیں ہیں، مثال کے طور پر، Json میں، بطور ڈیفالٹ وہ فراہم نہیں کیے جاتے ہیں۔
• افعال؛
• اور میں ایسی اعلیٰ سطحی چیزوں کے بارے میں بھی بات نہیں کر رہا ہوں جیسے کہ کلاسز، وراثت اور یہ سب۔

2. اس طرح کے کوڈ کے ساتھ دوسرا مسئلہ یہ ہے کہ اکثر یہ ایک متفاوت ماحول ہوتا ہے۔. عام طور پر آپ بیٹھ کر C# کے ساتھ کام کرتے ہیں، یعنی ایک زبان، ایک اسٹیک، ایک ماحولیاتی نظام کے ساتھ۔ اور یہاں آپ کے پاس بہت ساری ٹیکنالوجیز ہیں۔

یہ ایک بہت ہی حقیقی صورتحال ہے جب python کے ساتھ bash کچھ عمل شروع کرتا ہے جس میں Json ڈالا جاتا ہے۔ آپ اس کا تجزیہ کریں، پھر کوئی دوسرا جنریٹر مزید 30 فائلیں تیار کرتا ہے۔ اس سب کے لیے، ان پٹ ویری ایبلز Azure Key Vault سے موصول ہوتے ہیں، جنہیں Go میں لکھے ہوئے drone.io کے لیے ایک پلگ ان کے ذریعے ایک ساتھ کھینچا جاتا ہے، اور یہ متغیرات yaml سے گزرتے ہیں، جو jsonnet ٹیمپلیٹ انجن سے پیدا ہونے کے نتیجے میں پیدا ہوا تھا۔ جب آپ کے پاس اتنا متنوع ماحول ہو تو سختی سے کوڈ کو اچھی طرح سے بیان کرنا کافی مشکل ہے۔

ایک کام کے فریم ورک کے اندر روایتی ترقی ایک زبان کے ساتھ آتی ہے۔ یہاں ہم زبانوں کی ایک بڑی تعداد کے ساتھ کام کرتے ہیں۔

3. تیسرا مسئلہ ٹیوننگ کا ہے۔. ہم ایڈیٹرز کو ٹھنڈا کرنے کے عادی ہیں (Ms Visual Studio, Jetbrains Rider) جو ہمارے لیے سب کچھ کرتے ہیں۔ اور اگر ہم بیوقوف بھی ہوں تو وہ کہیں گے کہ ہم غلط ہیں۔ یہ عام اور فطری لگتا ہے۔

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

اس تحریر کے وقت vscode-terraform پلگ ان ورژن 0.12 کو سپورٹ کرنے کے لیے ابھی تک جاری نہیں کیا گیا ہے، حالانکہ اسے 3 ماہ سے جاری کیا گیا ہے۔

یہ بھولنے کا وقت ہے...

1. ڈیبگ کرنا۔
2. ریفیکٹرنگ ٹول۔
3. خودکار تکمیل۔
4. تالیف کے دوران غلطیوں کا پتہ لگانا۔

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

سب سے بری بات یہ ہے کہ ہمیں یہ سوچنے پر مجبور کیا جاتا ہے کہ فائلوں کو کیسے ڈیزائن کیا جائے، فولڈرز میں کیسے ترتیب دیا جائے، سڑنے، کوڈ کو برقرار رکھنے کے قابل، پڑھنے کے قابل بنایا جائے، وغیرہ، بلکہ یہ سوچنے پر مجبور کیا جاتا ہے کہ میں اس کمانڈ کو صحیح طریقے سے کیسے لکھ سکتا ہوں، کیونکہ میں نے اسے غلط لکھا ہے۔ .

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

ٹیسٹوں کا کیا ہوگا؟

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

ان کے پاس اچھی دستاویزات ہیں۔ میں نے ہمیشہ مائیکروسافٹ کو اس کے دستاویزات اور تربیت کے نقطہ نظر کے لیے پسند کیا ہے۔ لیکن آپ کو یہ سمجھنے کے لیے انکل باب بننے کی ضرورت نہیں ہے کہ یہ پرفیکٹ کوڈ نہیں ہے۔ دائیں طرف توثیق کو نوٹ کریں۔

یونٹ ٹیسٹ میں مسئلہ یہ ہے کہ آپ اور میں Json آؤٹ پٹ کی درستگی کو چیک کر سکتے ہیں۔ میں نے 5 پیرامیٹرز میں پھینک دیا اور مجھے 2000 لائنوں کے ساتھ Json فٹ کلاتھ دیا گیا۔ میں تجزیہ کر سکتا ہوں کہ یہاں کیا ہو رہا ہے، ٹیسٹ کے نتائج کی توثیق کر سکتا ہوں...

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

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

کوڈ کے طور پر بنیادی ڈھانچے کے بہترین طرز عمل

آئیے آگے بڑھیں۔ اگر IaC میں کوئی ٹیسٹ نہیں ہیں، IDE اور ٹیوننگ خراب ہیں، تو کم از کم بہترین طریقہ کار ہونا چاہیے۔ میں ابھی گوگل کے تجزیات پر گیا اور تلاش کے دو سوالات کا موازنہ کیا: Terraform بہترین طریقوں اور c# بہترین طریقوں۔

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

جہاں تک IaC کی درخواست کا تعلق ہے: یہاں آپ ہائی لوڈ یا HashiConf رپورٹس سے، سرکاری دستاویزات اور Github پر متعدد مسائل سے تھوڑی تھوڑی معلومات جمع کرنے کی کوشش کر رہے ہیں۔ ان ماڈیولز کو عام طور پر کیسے تقسیم کیا جائے، ان کے ساتھ کیا کیا جائے؟ ایسا لگتا ہے کہ یہ ایک حقیقی مسئلہ ہے... ایک کمیونٹی ہے، حضرات، جہاں کسی بھی سوال کے لیے آپ کو Github پر 10 تبصرے دیے جائیں گے۔ لیکن ایسا بالکل نہیں ہے۔

بدقسمتی سے، اس وقت، ماہرین ابھر کر سامنے آنے لگے ہیں۔ ان میں سے اب تک بہت کم ہیں۔ اور کمیونٹی خود ہی ابتدائی سطح پر گھوم رہی ہے۔

یہ سب کہاں جا رہا ہے اور کیا کرنا ہے۔

آپ سب کچھ چھوڑ سکتے ہیں اور سوار کی دنیا میں C# پر واپس جا سکتے ہیں۔ لیکن نہیں. اگر آپ کو کوئی حل نہیں مل رہا ہے تو آپ ایسا کرنے کی زحمت کیوں کریں گے۔ ذیل میں میں اپنے موضوعی نتائج پیش کرتا ہوں۔ آپ تبصرے میں مجھ سے بحث کر سکتے ہیں، یہ دلچسپ ہو جائے گا.

ذاتی طور پر، میں کچھ چیزوں پر شرط لگا رہا ہوں:

1. اس علاقے میں ترقی بہت تیزی سے ہورہی ہے۔ یہاں DevOps کے لیے درخواستوں کا شیڈول ہے۔

   
   
   موضوع ہائپ ہو سکتا ہے، لیکن حقیقت یہ ہے کہ دائرہ بڑھ رہا ہے کچھ امید دیتا ہے۔

   اگر کوئی چیز اتنی جلدی بڑھتی ہے تو ذہین لوگ ضرور سامنے آئیں گے جو آپ کو بتائیں گے کہ کیا کرنا ہے اور کیا نہیں کرنا چاہیے۔ مقبولیت میں اضافہ اس حقیقت کی طرف جاتا ہے کہ شاید کسی کے پاس vscode کے لیے jsonnet میں پلگ ان شامل کرنے کا وقت ہو، جو آپ کو ctrl+shift+f کے ذریعے تلاش کرنے کے بجائے فنکشن کو لاگو کرنے کے لیے آگے بڑھنے کی اجازت دے گا۔ جیسے جیسے چیزیں تیار ہوتی ہیں، مزید مواد ظاہر ہوتا ہے۔ ایس آر ای کے بارے میں گوگل کی طرف سے ایک کتاب کا اجراء اس کی بہترین مثال ہے۔

2. روایتی ترقی میں ترقی یافتہ تکنیک اور طرز عمل ہیں جنہیں ہم یہاں کامیابی کے ساتھ لاگو کر سکتے ہیں۔ ہاں، ٹیسٹنگ اور متفاوت ماحول، ناکافی ٹولنگ کے ساتھ باریکیاں ہیں، لیکن بہت ساری مشقیں جمع کی گئی ہیں جو مفید اور مددگار ثابت ہو سکتی ہیں۔

   ایک چھوٹی سی مثال: جوڑی پروگرامنگ کے ذریعے تعاون۔ اس کا پتہ لگانے میں بہت مدد ملتی ہے۔ جب آپ کے پاس کوئی پڑوسی ہے جو کچھ سمجھنے کی کوشش کر رہا ہے، تو آپ مل کر بہتر سمجھیں گے۔

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

حاصل يہ ہوا

اس حقیقت کے باوجود کہ میرا استدلال مایوسی کا شکار ہو سکتا ہے، میں امید کے ساتھ مستقبل کی طرف دیکھتا ہوں اور پوری امید رکھتا ہوں کہ ہمارے (اور آپ) کے لیے سب کچھ کام آئے گا۔

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

ماخذ: www.habr.com