"کلاؤڈ مقامی" یا صرف "کلاؤڈ" ایپلی کیشنز کو خاص طور پر کلاؤڈ انفراسٹرکچر میں کام کرنے کے لیے بنایا گیا ہے۔ وہ عام طور پر کنٹینرز میں پیک کیے گئے ڈھیلے جوڑے ہوئے مائیکرو سروسز کے ایک سیٹ کے طور پر بنائے جاتے ہیں، جن کا انتظام کلاؤڈ پلیٹ فارم کے ذریعے کیا جاتا ہے۔ اس طرح کی ایپلی کیشنز پہلے سے طے شدہ طور پر ناکامیوں کے لیے تیار کی جاتی ہیں، جس کا مطلب ہے کہ وہ بنیادی ڈھانچے کی سطح کی سنگین ناکامیوں کی صورت میں بھی قابل اعتماد طریقے سے کام کرتے ہیں اور پیمانے پر کام کرتے ہیں۔ سکے کا دوسرا رخ پابندیوں کے سیٹ (معاہدے) ہیں جو کلاؤڈ پلیٹ فارم کنٹینر ایپلی کیشنز پر عائد کرتا ہے تاکہ ان کا خود بخود انتظام کر سکے۔
کلاؤڈ بیسڈ ایپلی کیشنز پر جانے کی ضرورت اور اہمیت سے پوری طرح آگاہ ہونے کے باوجود، بہت سی تنظیمیں ابھی تک نہیں جانتی ہیں کہ کہاں سے آغاز کرنا ہے۔ اس پوسٹ میں، ہم بہت سے اصولوں پر غور کریں گے، جن پر عمل کرنے کی صورت میں کنٹینرائزڈ ایپلی کیشنز تیار کرتے وقت، آپ کو کلاؤڈ پلیٹ فارمز کی صلاحیت کا ادراک کرنے اور آئی ٹی انفراسٹرکچر میں سنگین ناکامیوں کی صورت میں بھی ایپلی کیشنز کے قابل اعتماد آپریشن اور اسکیلنگ حاصل کرنے میں مدد ملے گی۔ سطح یہاں بیان کردہ اصولوں کا حتمی مقصد یہ سیکھنا ہے کہ ایسی ایپلی کیشنز کیسے بنائی جائیں جن کا خود بخود کلاؤڈ پلیٹ فارم جیسے Kubernetes کے ذریعے انتظام کیا جا سکے۔
سافٹ ویئر ڈیزائن کے اصول
پروگرامنگ کی دنیا میں، اصول کافی عمومی اصولوں کا حوالہ دیتے ہیں جن پر سافٹ ویئر تیار کرتے وقت عمل کرنا ضروری ہے۔ وہ کسی بھی پروگرامنگ زبان کے ساتھ کام کرتے وقت استعمال کیے جا سکتے ہیں۔ ہر اصول کے اپنے اہداف ہوتے ہیں، حاصل کرنے کے اوزار جو عام طور پر ٹیمپلیٹس اور طرز عمل ہوتے ہیں۔ اعلیٰ معیار کے سافٹ ویئر بنانے کے لیے بھی بہت سے بنیادی اصول ہیں، جن سے باقی سب نکلتے ہیں۔ یہاں بنیادی اصولوں کی کچھ مثالیں ہیں:
- (اسے سادہ رکھیں، احمقانہ) – اسے پیچیدہ نہ بنائیں؛
- (اپنے آپ کو نہ دہرائیں) - اپنے آپ کو نہ دہرائیں؛
- (آپ کو اس کی ضرورت نہیں ہے) - ایسی چیز نہ بنائیں جس کی فوری ضرورت نہ ہو۔
- خدشات کی علیحدگی - ذمہ داریاں بانٹیں۔
جیسا کہ آپ دیکھ سکتے ہیں، یہ اصول کوئی خاص اصول متعین نہیں کرتے ہیں، لیکن عملی تجربے پر مبنی نام نہاد عام فہم غور و فکر کے زمرے سے تعلق رکھتے ہیں، جن کا اشتراک بہت سے ڈویلپرز کرتے ہیں اور جن کا وہ باقاعدگی سے حوالہ دیتے ہیں۔
اس کے علاوہ، وہاں ہے - آبجیکٹ پر مبنی پروگرامنگ اور ڈیزائن کے پہلے پانچ اصولوں کا ایک مجموعہ، جو رابرٹ مارٹن نے تیار کیا ہے۔ SOLID میں وسیع، اوپن اینڈڈ، تکمیلی اصول شامل ہیں جو کہ جب ایک ساتھ لاگو ہوتے ہیں تو بہتر سافٹ ویئر سسٹم بنانے میں مدد کرتے ہیں اور انہیں طویل مدت تک بہتر طریقے سے برقرار رکھتے ہیں۔
SOLID اصول OOP کے شعبے سے تعلق رکھتے ہیں اور کلاسز، انٹرفیس اور وراثت جیسے تصورات اور تصورات کی زبان میں وضع کیے گئے ہیں۔ تشبیہ سے، کلاؤڈ ایپلی کیشنز کے لیے بھی ترقیاتی اصول وضع کیے جا سکتے ہیں، یہاں صرف بنیادی عنصر کلاس نہیں ہوگا، بلکہ ایک کنٹینر ہوگا۔ ان اصولوں پر عمل کر کے، آپ کنٹینرائزڈ ایپلی کیشنز بنا سکتے ہیں جو Kubernetes جیسے کلاؤڈ پلیٹ فارم کے اہداف اور مقاصد کو بہتر طریقے سے پورا کرتی ہیں۔
کلاؤڈ مقامی کنٹینرز: ریڈ ہیٹ اپروچ
آج، تقریباً کسی بھی درخواست کو نسبتاً آسانی سے کنٹینرز میں پیک کیا جا سکتا ہے۔ لیکن ایپلی کیشنز کو مؤثر طریقے سے خودکار اور کوبرنیٹس جیسے کلاؤڈ پلیٹ فارم کے اندر ترتیب دینے کے لیے، اضافی کوشش کی ضرورت ہے۔
ذیل میں بیان کردہ نظریات کی بنیاد طریقہ کار تھا۔ اور بہت سے دوسرے کام ویب ایپلیکیشنز کی تعمیر کے مختلف پہلوؤں پر، سورس کوڈ مینجمنٹ سے لے کر اسکیلنگ ماڈلز تک۔ بیان کردہ اصول صرف کنٹینرائزڈ ایپلی کیشنز کی ترقی پر لاگو ہوتے ہیں جو مائیکرو سروسز کے اوپر بنائے گئے ہیں اور کلاؤڈ پلیٹ فارمز جیسے کہ Kubernetes کے لیے ڈیزائن کیے گئے ہیں۔ ہماری بحث کا بنیادی عنصر کنٹینر کی تصویر ہے، اور ہدف کنٹینر رن ٹائم کنٹینر آرکیسٹریشن پلیٹ فارم ہے۔ مجوزہ اصولوں کا مقصد کنٹینرز بنانا ہے جس کے لیے زیادہ تر آرکیسٹریشن پلیٹ فارمز پر شیڈولنگ، اسکیلنگ اور نگرانی کے کام خودکار کیے جاسکتے ہیں۔ اصولوں کو کسی خاص ترتیب میں پیش نہیں کیا گیا ہے۔
سنگل کنسرن پرنسپل (SCP)
یہ اصول کئی طریقوں سے واحد ذمہ داری کے اصول سے ملتا جلتا ہے۔ )، جو SOLID سیٹ کا حصہ ہے اور یہ بتاتا ہے کہ ہر شے کی ایک ذمہ داری ہونی چاہیے، اور اس ذمہ داری کو مکمل طور پر ایک کلاس میں شامل کیا جانا چاہیے۔ SRP کا نکتہ یہ ہے کہ ہر ذمہ داری تبدیلی کی ایک وجہ ہوتی ہے، اور ایک طبقے کے پاس تبدیلی کی ایک اور صرف ایک وجہ ہونی چاہیے۔
SCP میں، ہم OOP کلاس کے مقابلے میں ایک کنٹینر کے تجرید کی اعلی سطح اور وسیع تر مقصد کی نشاندہی کرنے کے لیے لفظ "ذمہ داری" کے بجائے لفظ "تشویش" استعمال کرتے ہیں۔ اور اگر SRP کا مقصد تبدیلی کی صرف ایک وجہ ہے، تو SCP کے پیچھے کنٹینرز کو دوبارہ استعمال کرنے اور تبدیل کرنے کی صلاحیت کو بڑھانے کی خواہش ہے۔ SRP کی پیروی کرکے اور ایک ایسا کنٹینر بنا کر جو کسی ایک مسئلے کو حل کرتا ہے اور اسے مکمل طور پر کام کرتا ہے، آپ اس کنٹینر کی تصویر کو مختلف ایپلیکیشن سیاق و سباق میں دوبارہ استعمال کرنے کے امکانات کو بڑھا دیتے ہیں۔
SCP اصول یہ بتاتا ہے کہ ہر کنٹینر کو ایک ہی مسئلہ حل کرنا چاہئے اور اسے اچھی طرح سے کرنا چاہئے۔ مزید یہ کہ، کنٹینر کی دنیا میں SCP کا حصول OOP دنیا میں SRP کے مقابلے میں آسان ہے، کیونکہ کنٹینرز عام طور پر ایک ہی عمل کو چلاتے ہیں، اور زیادہ تر وقت یہ عمل ایک ہی کام کو حل کرتا ہے۔
اگر ایک کنٹینر مائیکرو سروس کو ایک ساتھ کئی مسائل کو حل کرنا ہوگا، تو اسے سنگل ٹاسک کنٹینرز میں تقسیم کیا جا سکتا ہے اور سائڈ کار اور انیٹ کنٹینر ٹیمپلیٹس کا استعمال کرتے ہوئے ایک پوڈ (کنٹینر پلیٹ فارم کی تعیناتی کی اکائی) کے اندر جوڑا جا سکتا ہے۔ اس کے علاوہ، SCP ایک پرانے کنٹینر (جیسے ویب سرور یا میسج بروکر) کو ایک نئے کنٹینر سے بدلنا آسان بناتا ہے جو ایک ہی مسئلہ کو حل کرتا ہے لیکن اس کی فعالیت یا اسکیل کو بہتر بنایا گیا ہے۔
اعلی مشاہداتی اصول (HOP)
جب کنٹینرز کو ایپلی کیشنز کو پیک کرنے اور چلانے کے لیے ایک متحد طریقہ کے طور پر استعمال کیا جاتا ہے، تو ایپلی کیشنز کو خود بلیک باکس سمجھا جاتا ہے۔ تاہم، اگر یہ کلاؤڈ کنٹینرز ہیں، تو انہیں کنٹینرز کی صحت کی نگرانی کے لیے رن ٹائم کے لیے خصوصی API فراہم کرنا چاہیے اور اگر ضروری ہو تو مناسب کارروائی کریں۔ اس کے بغیر، کنٹینرز کو اپ ڈیٹ کرنے اور ان کے لائف سائیکل کو منظم کرنے کے آٹومیشن کو یکجا کرنا ممکن نہیں ہو گا، جس کے نتیجے میں، سافٹ ویئر سسٹم کے استحکام اور استعمال کو مزید خراب ہو جائے گا۔
عملی طور پر، ایک کنٹینرائزڈ ایپلی کیشن میں، کم از کم، مختلف قسم کے ہیلتھ چیکس کے لیے ایک API ہونا چاہیے: زندہ دلی کے ٹیسٹ اور تیاری کے ٹیسٹ۔ اگر کوئی درخواست زیادہ کام کرنے کا دعوی کرتی ہے، تو اسے اپنی ریاست کی نگرانی کے دوسرے ذرائع فراہم کرنے چاہئیں۔ مثال کے طور پر، Fluentd، Logstash اور اسی طرح کے دوسرے ٹولز کا استعمال کرتے ہوئے لاگ ایگریگیشن کے لیے STDERR اور STDOUT کے ذریعے اہم ایونٹس کو لاگ کرنا۔ نیز ٹریسنگ اور میٹرکس کلیکشن لائبریریوں کے ساتھ انضمام، جیسے اوپن ٹریسنگ، پرومیتھیس وغیرہ۔
عام طور پر، ایپلیکیشن کو اب بھی بلیک باکس کے طور پر سمجھا جا سکتا ہے، لیکن اسے وہ تمام APIs فراہم کیے جانے چاہئیں جن کی پلیٹ فارم کو ضرورت ہے تاکہ اس کی نگرانی اور بہترین ممکنہ طریقے سے انتظام کیا جا سکے۔
لائف سائیکل کنفارمنس پرنسپل (LCP)
LCP HOP کا مخالف ہے۔ جبکہ HOP کا کہنا ہے کہ کنٹینر کو لازمی طور پر پڑھنے والے APIs کو پلیٹ فارم پر ظاہر کرنا چاہیے، LCP کے لیے درخواست ہے کہ پلیٹ فارم سے معلومات کو قبول کرنے کے قابل ہو۔ مزید برآں، کنٹینر کو نہ صرف واقعات موصول ہونے چاہئیں، بلکہ دوسرے لفظوں میں، ان پر ردعمل بھی ظاہر کرنا چاہیے۔ لہذا اس اصول کا نام، جسے پلیٹ فارم کو تحریری APIs فراہم کرنے کی ضرورت کے طور پر سمجھا جا سکتا ہے۔
پلیٹ فارمز میں کنٹینر کے لائف سائیکل کو منظم کرنے میں مدد کے لیے مختلف قسم کے واقعات ہوتے ہیں۔ لیکن یہ خود درخواست پر منحصر ہے کہ وہ فیصلہ کرے کہ ان میں سے کس کو سمجھنا ہے اور کس طرح کا ردعمل ظاہر کرنا ہے۔
یہ واضح ہے کہ کچھ واقعات دوسروں سے زیادہ اہم ہیں۔ مثال کے طور پر، اگر کوئی ایپلیکیشن کریشوں کو اچھی طرح سے برداشت نہیں کرتی ہے، تو اسے سگنل: ٹرمینیٹ (SIGTERM) پیغامات کو قبول کرنا چاہیے اور اس سگنل کو پکڑنے کے لیے جتنی جلدی ممکن ہو اس کے خاتمے کا معمول شروع کرنا چاہیے: kill (SIGKILL) جو SIGTERM کے بعد آتا ہے۔
مزید برآں، پوسٹ اسٹارٹ اور پری اسٹاپ جیسے واقعات کسی ایپلیکیشن کے لائف سائیکل کے لیے اہم ہوسکتے ہیں۔ مثال کے طور پر، ایک ایپلیکیشن شروع کرنے کے بعد، درخواستوں کا جواب دینے سے پہلے اسے کچھ وارم اپ وقت درکار ہو سکتا ہے۔ یا ایپلیکیشن کو بند کرتے وقت وسائل کو کسی خاص طریقے سے جاری کرنا چاہیے۔
تصویری عدم استحکام کا اصول (IIP)
یہ عام طور پر قبول کیا جاتا ہے کہ کنٹینرائزڈ ایپلی کیشنز کو تعمیر ہونے کے بعد کوئی تبدیلی نہیں ہونی چاہیے، چاہے وہ مختلف ماحول میں چلائی جائیں۔ اس سے رن ٹائم کے وقت ڈیٹا اسٹوریج کو بیرونی بنانے کی ضرورت ہوتی ہے (دوسرے لفظوں میں، اس کے لیے بیرونی ٹولز استعمال کرنے کے لیے) اور ہر ماحول کے لیے منفرد کنٹینرز میں ترمیم کرنے یا تخلیق کرنے کے بجائے بیرونی، رن ٹائم کے لیے مخصوص کنفیگریشنز پر انحصار کرنا پڑتا ہے۔ ایپلیکیشن میں کسی بھی تبدیلی کے بعد، کنٹینر کی تصویر کو دوبارہ بنایا جانا چاہیے اور استعمال کیے گئے تمام ماحول میں تعینات کیا جانا چاہیے۔ ویسے، آئی ٹی سسٹمز کا انتظام کرتے وقت، اسی طرح کا ایک اصول استعمال کیا جاتا ہے، جسے سرورز اور انفراسٹرکچر کی عدم تغیر کے اصول کے نام سے جانا جاتا ہے۔
IIP کا مقصد مختلف رن ٹائم ماحول کے لیے علیحدہ کنٹینر امیجز کی تخلیق کو روکنا اور مناسب ماحول کے ساتھ مخصوص کنفیگریشن کے ساتھ ایک ہی تصویر کو ہر جگہ استعمال کرنا ہے۔ اس اصول کی پیروی آپ کو کلاؤڈ سسٹم کے آٹومیشن کے نقطہ نظر سے رول بیک اور ایپلی کیشن اپ ڈیٹس کو آگے بڑھانے جیسے اہم طریقوں کو نافذ کرنے کی اجازت دیتا ہے۔
عمل ڈسپوزایبلٹی اصول (PDP)
ایک کنٹینر کی سب سے اہم خصوصیات میں سے ایک اس کی عارضی ہے: کنٹینر کی مثال بنانا آسان ہے اور اسے تباہ کرنا آسان ہے، لہذا اسے کسی بھی وقت آسانی سے دوسری مثال سے تبدیل کیا جا سکتا ہے۔ اس طرح کی تبدیلی کی بہت سی وجوہات ہو سکتی ہیں: سروس ایبلٹی ٹیسٹ میں ناکامی، ایپلیکیشن کی سکیلنگ، کسی دوسرے میزبان کو منتقلی، پلیٹ فارم کے وسائل کی تھکن، یا دیگر حالات۔
نتیجے کے طور پر، کنٹینرائزڈ ایپلی کیشنز کو کچھ بیرونی ذرائع استعمال کرتے ہوئے اپنی حالت کو برقرار رکھنا چاہیے، یا اس کے لیے فالتو پن کے ساتھ اندرونی تقسیم شدہ اسکیموں کا استعمال کرنا چاہیے۔ اس کے علاوہ، ایپلیکیشن کو جلدی سے شروع ہونا چاہیے اور جلدی سے بند کرنا چاہیے، اور اچانک مہلک ہارڈویئر کی ناکامی کے لیے تیار رہنا چاہیے۔
ایک مشق جو اس اصول کو نافذ کرنے میں مدد کرتی ہے وہ ہے کنٹینرز کو چھوٹا رکھنا۔ کلاؤڈ ماحول خود بخود کسی کنٹینر کو شروع کرنے کے لیے ایک میزبان کا انتخاب کر سکتا ہے، اس لیے کنٹینر جتنا چھوٹا ہوگا، اتنی ہی تیزی سے یہ شروع ہوگا - یہ آسانی سے نیٹ ورک پر ہدف والے میزبان پر تیزی سے نقل کرے گا۔
خود پر قابو پانے کا اصول (S-CP)
اس اصول کے مطابق، اسمبلی کے مرحلے میں، تمام ضروری اجزاء کنٹینر میں شامل ہیں. کنٹینر کو اس مفروضے پر بنایا جانا چاہیے کہ سسٹم میں صرف خالص لینکس کرنل ہے، اس لیے تمام ضروری اضافی لائبریریوں کو کنٹینر میں ہی رکھا جانا چاہیے۔ اس میں متعلقہ پروگرامنگ لینگویج کے لیے رن ٹائم، ایپلیکیشن پلیٹ فارم (اگر ضروری ہو)، اور دیگر انحصار جیسی چیزیں بھی ہونی چاہئیں جن کی کنٹینر ایپلیکیشن کے چلتے وقت ضرورت ہوگی۔
استثنیٰ کنفیگریشنز کے لیے بنائے جاتے ہیں جو ماحول سے دوسرے ماحول میں مختلف ہوتی ہیں اور رن ٹائم کے وقت فراہم کی جانی چاہیے، مثال کے طور پر Kubernetes ConfigMap کے ذریعے۔
ایک ایپلیکیشن میں کئی کنٹینرائزڈ اجزاء شامل ہو سکتے ہیں، مثال کے طور پر، کنٹینرائزڈ ویب ایپلیکیشن کے اندر ایک علیحدہ DBMS کنٹینر۔ S-CP اصول کے مطابق، ان کنٹینرز کو ایک میں نہیں ملایا جانا چاہیے، بلکہ اس طرح بنایا جانا چاہیے کہ DBMS کنٹینر میں ڈیٹا بیس کے آپریشن کے لیے ضروری تمام چیزیں موجود ہوں، اور ویب ایپلیکیشن کنٹینر میں ویب کے آپریشن کے لیے ضروری تمام چیزیں موجود ہوں۔ ایپلی کیشن، ایک ہی ویب سرور۔ نتیجے کے طور پر، رن ٹائم پر ویب ایپلیکیشن کنٹینر DBMS کنٹینر پر منحصر ہوگا اور ضرورت کے مطابق اس تک رسائی حاصل کرے گا۔
رن ٹائم کنفینمنٹ پرنسپل (RCP)
S-CP اصول اس بات کی وضاحت کرتا ہے کہ کنٹینر کو کس طرح بنایا جانا چاہئے اور تصویر بائنری میں کیا ہونا چاہئے۔ لیکن ایک کنٹینر صرف ایک "بلیک باکس" نہیں ہے جس میں صرف ایک خصوصیت ہے - فائل کا سائز۔ عملدرآمد کے دوران، کنٹینر دیگر جہتیں اختیار کرتا ہے: استعمال شدہ میموری کی مقدار، CPU وقت، اور سسٹم کے دیگر وسائل۔
اور یہاں RCP اصول کام آتا ہے، جس کے مطابق کنٹینر کو سسٹم کے وسائل کے لیے اپنی ضروریات کا سر قلم کرنا چاہیے اور انہیں پلیٹ فارم پر منتقل کرنا چاہیے۔ ہر کنٹینر کے وسائل کے پروفائلز کے ساتھ (اس کے لیے کتنے CPU، میموری، نیٹ ورک، اور ڈسک وسائل کی ضرورت ہے)، پلیٹ فارم بہترین طریقے سے شیڈولنگ اور آٹو اسکیلنگ انجام دے سکتا ہے، IT کی صلاحیت کا انتظام کر سکتا ہے، اور کنٹینرز کے لیے SLA کی سطح کو برقرار رکھ سکتا ہے۔
کنٹینر کے وسائل کی ضروریات کو پورا کرنے کے علاوہ، درخواست کے لیے یہ بھی ضروری ہے کہ وہ اپنی حدود سے باہر نہ جائے۔ دوسری صورت میں، جب وسائل کی کمی واقع ہوتی ہے، تو پلیٹ فارم اس کو ان ایپلی کیشنز کی فہرست میں شامل کرنے کا زیادہ امکان رکھتا ہے جنہیں ختم یا منتقل کرنے کی ضرورت ہے۔
جب ہم کلاؤڈ فرسٹ ہونے کے بارے میں بات کرتے ہیں، تو ہم اپنے کام کرنے کے طریقے کے بارے میں بات کر رہے ہیں۔
اوپر، ہم نے کئی عمومی اصول وضع کیے جو کلاؤڈ ماحول کے لیے اعلیٰ معیار کے کنٹینر ایپلی کیشنز کی تعمیر کے لیے طریقہ کار کی بنیاد رکھتے ہیں۔
نوٹ کریں کہ ان عمومی اصولوں کے علاوہ، آپ کو کنٹینرز کے ساتھ کام کرنے کے لیے اضافی جدید طریقوں اور تکنیکوں کی بھی ضرورت ہوگی۔ اس کے علاوہ، ہمارے پاس چند مختصر سفارشات ہیں جو زیادہ مخصوص ہیں اور صورت حال کے لحاظ سے لاگو کی جانی چاہئیں (یا لاگو نہیں)
- امیجز کا سائز کم کرنے کی کوشش کریں: عارضی فائلوں کو ڈیلیٹ کریں اور غیر ضروری پیکجز کو انسٹال نہ کریں - کنٹینر کا سائز جتنا چھوٹا ہوگا، اسے نیٹ ورک پر ٹارگٹ ہوسٹ پر اتنی ہی تیزی سے جمع اور کاپی کیا جائے گا۔
- صوابدیدی User-IDs پر توجہ مرکوز کریں: اپنے کنٹینرز کو لانچ کرنے کے لیے sudo کمانڈ یا کوئی خاص userid استعمال نہ کریں۔
- اہم بندرگاہوں کو نشان زد کریں: آپ رن ٹائم پر پورٹ نمبر سیٹ کر سکتے ہیں، لیکن EXPOSE کمانڈ کا استعمال کرتے ہوئے ان کی وضاحت کرنا بہتر ہے - اس سے دوسرے لوگوں اور پروگراموں کے لیے آپ کی تصاویر استعمال کرنا آسان ہو جائے گا۔
- حجم پر مستقل ڈیٹا ذخیرہ کریں: کنٹینر کے تباہ ہونے کے بعد جو ڈیٹا باقی رہنا چاہیے اسے جلدوں میں لکھا جانا چاہیے۔
- تصویری میٹا ڈیٹا لکھیں: ٹیگز، لیبلز اور تشریحات تصاویر کو استعمال میں آسان بناتے ہیں - دوسرے ڈویلپر آپ کا شکریہ ادا کریں گے۔
- ہوسٹ اور امیجز کو سنکرونائز کریں: کچھ کنٹینرائزڈ ایپلی کیشنز کے لیے کنٹینر کو میزبان کے ساتھ مخصوص صفات، جیسے کہ وقت یا مشین آئی ڈی پر مطابقت پذیری کی ضرورت ہوتی ہے۔
- آخر میں، ہم ٹیمپلیٹس اور بہترین طریقوں کا اشتراک کرتے ہیں جو اوپر درج اصولوں کو زیادہ مؤثر طریقے سے نافذ کرنے میں آپ کی مدد کریں گے۔
11 جون کو 11.00 بجے
آپ کیا سیکھیں گے:
- ناقابل تغیر ریڈ ہیٹ انٹرپرائز لینکس کور او ایس
- اوپن شفٹ سروس میش
- آپریٹر فریم ورک
- Knative فریم ورک
ماخذ: www.habr.com