سب کو سلام! میرا نام پاول اگلیٹسکی ہے۔ میں ایک ٹیم میں ٹیم لیڈ کے طور پر کام کرتا ہوں جو لاموڈا ڈیلیوری سسٹم تیار کرتی ہے۔ 2018 میں، میں نے HighLoad++ کانفرنس میں بات کی، اور آج میں اپنی رپورٹ کا ایک ٹرانسکرپٹ پیش کرنا چاہوں گا۔

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

VM پر ایپلیکیشنز کی تعیناتی

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

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

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

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

اس سب میں ہمیں کیا فوائد نظر آئے؟

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

لیکن ہم نے اس سب میں کئی کوتاہیاں بھی دیکھیں:

1. پیداواری ماحول، ترقی کے ماحول کے علاوہ دیگر ماحول بھی موجود ہیں۔ مثال کے طور پر، qa اور preproduction. اس وقت ہمارے پاس بہت سے سرورز اور تقریباً 60 خدمات تھیں۔ اس وجہ سے یہ ضروری تھا۔ ہر سروس کے لیے، اس کے لیے تازہ ترین ورژن کو برقرار رکھیں مجازی مشین. مزید یہ کہ، اگر آپ لائبریریوں کو اپ ڈیٹ کرنا چاہتے ہیں یا نئے انحصار کو انسٹال کرنا چاہتے ہیں، تو آپ کو یہ تمام ماحول میں کرنے کی ضرورت ہے۔ آپ کو اس وقت کو بھی مطابقت پذیر کرنے کی ضرورت ہے جب آپ اپنی ایپلیکیشن کے اگلے نئے ورژن کو اس وقت کے ساتھ متعین کرنے جا رہے ہیں جب ڈیوپس ضروری ماحول کی ترتیبات کو انجام دیتا ہے۔ اس صورت میں، ایسی صورتحال میں جانا آسان ہے جہاں ہمارا ماحول ایک ہی وقت میں تمام ماحول میں کچھ مختلف ہوگا۔ مثال کے طور پر، QA ماحول میں لائبریریوں کے کچھ ورژن ہوں گے، اور پیداواری ماحول میں مختلف ہوں گے، جو مسائل کا باعث بنیں گے۔
2. انحصار کو اپ ڈیٹ کرنے میں دشواری آپ کی درخواست. یہ آپ پر نہیں بلکہ دوسری ٹیم پر منحصر ہے۔ یعنی ڈیوپس ٹیم سے جو سرورز کو برقرار رکھتی ہے۔ آپ کو انہیں ایک مناسب کام اور اس کی تفصیل دینا چاہیے کہ آپ کیا کرنا چاہتے ہیں۔
3. اس وقت، ہم اپنے پاس موجود بڑے بڑے یک سنگی کو الگ الگ چھوٹی خدمات میں تقسیم کرنا چاہتے تھے، کیونکہ ہم سمجھتے تھے کہ ان میں سے زیادہ سے زیادہ ہوں گے۔ اس وقت، ہمارے پاس پہلے سے ہی ان میں سے 100 سے زیادہ تھے۔ہر نئی سروس کے لیے، ایک علیحدہ نئی ورچوئل مشین بنانا ضروری تھا، جسے برقرار رکھنے اور تعینات کرنے کی بھی ضرورت تھی۔ اس کے علاوہ، آپ کو ایک کار نہیں، لیکن کم از کم دو کی ضرورت ہے۔ اس سب میں QA ماحول شامل ہے۔ اس سے مسائل پیدا ہوتے ہیں اور آپ کے لیے نئے سسٹم بنانا اور چلانا مشکل ہو جاتا ہے۔ پیچیدہ، مہنگا اور طویل عمل.

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

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

Nomad پر سوئچ کریں۔

Nomad HashiCorp کی پیداوار ہے۔ وہ اپنے دوسرے حل کے لیے بھی مشہور ہیں:

"قونصل" سروس کی دریافت کا ایک ٹول ہے۔

"ٹیرافارم" - سرورز کے انتظام کے لیے ایک ایسا نظام جو آپ کو کنفیگریشن کے ذریعے ترتیب دینے کی اجازت دیتا ہے، نام نہاد انفراسٹرکچر-ای-کوڈ۔

"آوارہ گردی" آپ کو ورچوئل مشینوں کو مقامی طور پر یا کلاؤڈ میں مخصوص کنفیگریشن فائلوں کے ذریعے تعینات کرنے کی اجازت دیتا ہے۔

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

آپ کو اپنے سسٹم کو Nomad میں تعینات کرنے کی کیا ضرورت ہے؟

1. سب سے پہلے آپ کی ضرورت ہے۔ ڈاکر کی تصویر آپ کی درخواست. آپ کو اسے بنانے اور اسے ڈاکر امیج ریپوزٹری میں رکھنے کی ضرورت ہے۔ ہمارے معاملے میں، یہ ایک آرٹفیکٹری ہے - ایک ایسا نظام جو آپ کو مختلف اقسام کے مختلف نمونے اس میں ڈالنے کی اجازت دیتا ہے۔ یہ آرکائیوز، ڈاکر امیجز، کمپوزر پی ایچ پی پیکجز، این پی ایم پیکجز وغیرہ کو اسٹور کر سکتا ہے۔
2. بھی درکار ہے۔ ترتیب فائل، جو Nomad کو بتائے گا کہ آپ کیا، کہاں اور کس مقدار میں تعینات کرنا چاہتے ہیں۔

جب ہم Nomad کے بارے میں بات کرتے ہیں، تو یہ HCL ​​زبان کو اپنے انفارمیشن فائل فارمیٹ کے طور پر استعمال کرتا ہے، جس کا مطلب ہے۔ HashiCorp کنفیگریشن لینگویج. یہ یامل کا ایک سپر سیٹ ہے جو آپ کو اپنی خدمت کو خانہ بدوش الفاظ میں بیان کرنے کی اجازت دیتا ہے۔

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

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

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

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

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

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

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

جب Nomad سروس پہلے ہی آپ کے کلسٹر میں تعینات ہے، تو ایسا لگتا ہے۔

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

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

انسانی وسائل کے لحاظ سے ہمیں منتقلی کی کتنی لاگت آئی؟

پوری کمپنی کو Nomad میں منتقل کرنے میں تقریباً 5-6 ماہ لگے۔ ہم خدمت بہ خدمت کی بنیاد پر منتقل ہوئے، لیکن کافی تیز رفتاری سے۔ ہر ٹیم کو خدمات کے لیے اپنا کنٹینر بنانا تھا۔

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

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

خانہ بدوش کو ترک کرنے کی وجوہات

Nomad اور docker کا استعمال کرتے ہوئے تعیناتی پر سوئچ کرنے سے ہمیں کیا فوائد حاصل ہوئے، دوسروں کے درمیان؟

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

لیکن ہمیں کئی نقصانات کا بھی سامنا کرنا پڑا:

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

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

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

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

Kubernetes میں منتقلی۔

میں آپ کو Kubernetes کے بنیادی تصورات کے بارے میں تھوڑا سا بتاؤں گا اور یہ کہ وہ Nomad سے کیسے مختلف ہیں۔

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

آئیے فرض کریں کہ آپ کے پاس ایک PHP ایپلی کیشن ہے جو nginx اور php-fpm پر مشتمل ہے - کلاسک اسکیم۔ زیادہ امکان ہے کہ آپ nginx اور php-fpm دونوں کنٹینرز کو ہر وقت ایک ساتھ رکھنا چاہیں گے۔ Kubernetes آپ کو اسے ایک عام پوڈ کے طور پر بیان کرکے حاصل کرنے کی اجازت دیتا ہے۔ یہ بالکل وہی ہے جو ہم خانہ بدوش کے ساتھ حاصل نہیں کر سکے۔

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

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

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

کسی ایپلی کیشن کو تیار کرنے والے کے نقطہ نظر سے سب سے اچھی چیز یہ ہے کہ آپ خود اس کا انتظام کرنے کے قابل ہیں۔ Ingress config کو ترتیب دے کر، آپ فلاں اور فلاں API پر آنے والی تمام ٹریفک کو الگ الگ کنٹینرز پر بھیج سکتے ہیں، مثال کے طور پر، Go میں۔ لیکن یہ ٹریفک، ایک ہی ڈومین پر آتی ہے، لیکن ایک مختلف یو آر ایل پر، پی ایچ پی میں لکھے ہوئے کنٹینرز پر بھیجی جانی چاہیے، جہاں بہت سی منطق ہے، لیکن وہ بہت تیز نہیں ہیں۔

اگر ہم ان تمام تصورات کا Nomad سے موازنہ کریں تو ہم کہہ سکتے ہیں کہ پہلے تین تصورات ایک ساتھ سروس ہیں۔ اور آخری تصور Nomad میں ہی غائب ہے۔ ہم نے اس کے طور پر ایک بیرونی بیلنس استعمال کیا: یہ haproxy، nginx، nginx+، وغیرہ ہو سکتا ہے۔ مکعب کی صورت میں، آپ کو اس اضافی تصور کو الگ سے متعارف کرانے کی ضرورت نہیں ہے۔ تاہم، اگر آپ Ingress کو اندرونی طور پر دیکھیں تو یہ یا تو nginx، haproxy، یا traefik ہے، لیکن Kubernetes میں بنایا گیا ہے۔

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

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

ہیلم میں بنیادی تصورات

ہیلم ہے۔ پیکیج مینیجر Kubernetes کے لئے. یہ پروگرامنگ زبانوں میں پیکیج مینیجرز کے کام کرنے کے طریقے سے بہت ملتا جلتا ہے۔ وہ آپ کو ایک سروس کو ذخیرہ کرنے کی اجازت دیتے ہیں، مثال کے طور پر، تعیناتی nginx، تعیناتی php-fpm، config for Ingress، configmaps (یہ ایک ایسا ادارہ ہے جو آپ کو اپنے سسٹم کے لیے env اور دیگر پیرامیٹرز سیٹ کرنے کی اجازت دیتا ہے) so- کی شکل میں۔ چارٹس کہا جاتا ہے. ایک ہی وقت میں ہیلم Kubernetes کے اوپر چلتا ہے۔. یعنی، یہ ایک طرف کھڑا نظام نہیں ہے، بلکہ کیوب کے اندر شروع کی گئی ایک اور سروس ہے۔ آپ اس کے ساتھ اس کے API کے ذریعے کنسول کمانڈ کے ذریعے تعامل کرتے ہیں۔ اس کی سہولت اور خوبصورتی یہ ہے کہ اگر ہیلم ٹوٹ جائے یا آپ اسے کلسٹر سے ہٹا دیں تو بھی آپ کی خدمات ختم نہیں ہوں گی، کیونکہ ہیلم بنیادی طور پر صرف سسٹم کو شروع کرنے کا کام کرتا ہے۔ تب Kubernetes خود خدمات کی کارکردگی اور حالت کے لیے ذمہ دار ہے۔

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

ہیلم ہمارے لیے چند مزید تصورات کا اضافہ کرتا ہے۔

چارٹ - یہ آپ کی خدمت کی تفصیل ہے۔ دوسرے پیکیج مینیجرز میں اسے پیکیج، بنڈل یا اس سے ملتی جلتی کوئی چیز کہا جائے گا۔ یہاں اسے چارٹ کہتے ہیں۔

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

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

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

عملی طور پر، ہم نے خانہ بدوشوں کے مقابلے میں کچھ مختلف طریقے سے کرنے کا فیصلہ کیا۔ اگر Nomad میں دونوں تعیناتی کنفیگس اور n- متغیرات جو ہماری سروس کو تعینات کرنے کے لیے درکار تھے ایک ذخیرہ میں محفوظ تھے، تو یہاں ہم نے انہیں دو الگ الگ ذخیروں میں تقسیم کرنے کا فیصلہ کیا۔ "تعینات" ذخیرہ صرف n- متغیرات کو ذخیرہ کرتا ہے جو تعیناتی کے لیے درکار ہوتا ہے، اور "ہیلم" ذخیرہ کنفیگرس یا چارٹس کو اسٹور کرتا ہے۔

اس نے ہمیں کیا دیا؟

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

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

ہر ذخیرے کے اندر، ہم نے ہر سروس کے لیے الگ الگ ڈائریکٹریوں میں ایک ڈویژن چھوڑ دیا۔ یعنی، ہر ڈائرکٹری کے اندر متعلقہ چارٹ سے متعلق ٹیمپلیٹس ہوتے ہیں اور ان وسائل کو بیان کرتے ہیں جن کو ہمارے سسٹم کو چلانے کے لیے تعینات کرنے کی ضرورت ہوتی ہے۔ ہم نے "تعینات" ذخیرہ میں صرف envs چھوڑے ہیں۔ اس معاملے میں، ہم نے جنجا کا استعمال کرتے ہوئے ٹیمپلیٹنگ کا استعمال نہیں کیا، کیونکہ ہیلم خود ہی باکس سے باہر ٹیمپلیٹنگ فراہم کرتا ہے - یہ اس کے اہم افعال میں سے ایک ہے۔

ہم نے ایک تعیناتی اسکرپٹ - deploy.sh چھوڑا ہے، جو ہیلم کا استعمال کرتے ہوئے تعیناتی کے لیے لانچ کو آسان اور معیاری بناتا ہے۔ لہذا، جو بھی تعینات کرنا چاہتا ہے، تعیناتی کا انٹرفیس بالکل ویسا ہی نظر آتا ہے جیسا کہ اس نے Nomad کے ذریعے تعیناتی کرتے وقت کیا تھا۔ وہی deploy.sh، آپ کی سروس کا نام، اور جہاں آپ اسے تعینات کرنا چاہتے ہیں۔ اس کی وجہ سے ہیلم اندرونی طور پر شروع ہوتا ہے۔ یہ، بدلے میں، ٹیمپلیٹس سے تشکیلات جمع کرتا ہے، ان میں ضروری اقدار کی فائلیں داخل کرتا ہے، پھر انہیں تعینات کرتا ہے، انہیں کبرنیٹس میں لانچ کرتا ہے۔

نتائج

Kubernetes سروس Nomad سے زیادہ پیچیدہ معلوم ہوتی ہے۔

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

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

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

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

ماخذ: www.habr.com