آج میں اس بارے میں بات کرنے کا ارادہ رکھتا ہوں کہ ایپلی کیشنز کیسے لکھیں اور آپ کی درخواست کے لیے کوبرنیٹس میں اچھی طرح سے کام کرنے کے لیے کیا تقاضے ہیں۔ تاکہ ایپلیکیشن کے ساتھ کوئی سر درد نہ ہو، تاکہ آپ کو اس کے ارد گرد کوئی "کریچ" ایجاد کرنے اور بنانے کی ضرورت نہ پڑے - اور سب کچھ اسی طرح کام کرتا ہے جس طرح Kubernetes نے خود ارادہ کیا تھا۔
یہ لیکچر اس کا حصہ ہے "" آپ شام کے اسکول کے کھلے نظریاتی لیکچرز دیکھ سکتے ہیں۔ . ان لوگوں کے لیے جو ویڈیو کے بجائے متن کو ترجیح دیتے ہیں، ہم نے یہ مضمون تیار کیا ہے۔
میرا نام Pavel Selivanov ہے، اس وقت میں Mail.ru Cloud Solutions میں معروف DevOps انجینئر ہوں، ہم بادل بناتے ہیں، ہم مینجمنٹ کوبرنیٹس وغیرہ بناتے ہیں۔ میرے کاموں میں اب ترقی میں مدد، ان بادلوں کو رول آؤٹ کرنا، ان ایپلیکیشنز کو رول آؤٹ کرنا جو ہم لکھتے ہیں اور براہ راست ان ٹولز کو تیار کرنا جو ہم اپنے صارفین کے لیے فراہم کرتے ہیں۔
میں DevOps کر رہا ہوں، میرے خیال میں پچھلے، شاید، تین سالوں سے۔ لیکن، اصولی طور پر، میں وہی کر رہا ہوں جو ڈی او اوپس تقریباً پانچ سالوں سے کرتا ہے۔ اس سے پہلے، میں زیادہ تر ایڈمن کی چیزوں میں شامل تھا۔ میں نے کبرنیٹس کے ساتھ کافی عرصہ پہلے کام کرنا شروع کیا تھا - غالباً اس کے ساتھ کام شروع کیے تقریباً چار سال گزر چکے ہیں۔
عام طور پر، میں نے اس وقت شروع کیا جب Kubernetes کا ورژن 1.3 تھا، شاید، اور شاید 1.2 - جب یہ ابھی بچپن میں تھا۔ اب یہ اپنے بچپن میں نہیں ہے - اور یہ ظاہر ہے کہ مارکیٹ میں ان انجینئرز کی بہت زیادہ مانگ ہے جو کوبرنیٹس کرنا چاہیں گے۔ اور کمپنیوں میں ایسے لوگوں کی بہت زیادہ مانگ ہے۔ لہذا، حقیقت میں، یہ لیکچر شائع ہوا.
اگر ہم اس منصوبے کے مطابق بولیں جس کے بارے میں میں بات کروں گا، تو ایسا لگتا ہے، بریکٹ میں لکھا ہے (TL;DR) - "بہت لمبا؛ مت پڑھو" میری آج کی پیشکش لامتناہی فہرستوں پر مشتمل ہوگی۔
درحقیقت، میں خود اس طرح کی پیشکشوں کو پسند نہیں کرتا جب وہ بنائے جاتے ہیں، لیکن یہ ایک ایسا موضوع ہے کہ جب میں یہ پیشکش تیار کر رہا تھا، تو مجھے یہ سمجھ نہیں آیا کہ اس معلومات کو مختلف طریقے سے کیسے ترتیب دیا جائے۔
کیونکہ، مجموعی طور پر، یہ معلومات "ctrl+c, ctrl+v" ہے، دوسری چیزوں کے ساتھ، ہمارے Wiki سے، DevOps سیکشن میں، جہاں ہم نے ڈویلپرز کے لیے تقاضے لکھے ہیں: "یار، تاکہ ہم آپ کی درخواست کو لانچ کریں۔ Kubernetes، یہ اس طرح ہونا چاہئے."
اسی لیے پریزنٹیشن اتنی بڑی فہرست نکلی۔ معذرت میں زیادہ سے زیادہ بتانے کی کوشش کروں گا تاکہ اگر ممکن ہو تو بورنگ نہ ہو۔
اب ہم کیا دیکھنے جا رہے ہیں:
- یہ سب سے پہلے لاگز ہیں
- Kubernetes میں کنفیگریشن کے ساتھ کیا کرنا ہے، Kubernetes کے لیے ایپلیکیشن کو کنفیگر کرنے کے بہترین اور بدترین طریقے کیا ہیں؛
- آئیے اس کے بارے میں بات کرتے ہیں کہ عام طور پر رسائی کے چیک کیا ہوتے ہیں، انہیں کیسا نظر آنا چاہیے؛
- آئیے اس بارے میں بات کرتے ہیں کہ ایک خوبصورت بند کیا ہے؛
- آئیے وسائل کے بارے میں دوبارہ بات کرتے ہیں۔
- آئیے ایک بار پھر ڈیٹا اسٹوریج کے موضوع پر بات کرتے ہیں۔
- اور آخر میں میں آپ کو بتاؤں گا کہ اس پراسرار کلاؤڈ کی مقامی ایپلی کیشن کی اصطلاح کیا ہے۔ Cloudnativeness، اس اصطلاح کی صفت کے طور پر۔
نوشتہ جات
میں نوشتہ جات کے ساتھ شروع کرنے کا مشورہ دیتا ہوں - جہاں ان لاگز کو کبرنیٹس میں پھینکنے کی ضرورت ہے۔ اب آپ نے Kubernetes میں ایک ایپلیکیشن شروع کی ہے۔ کلاسیکی کے مطابق، پہلے ایپلی کیشنز ہمیشہ فائل میں کہیں نہ کہیں لاگ لکھتی تھیں۔ خراب ایپلی کیشنز نے ایپلیکیشن لانچ کرنے والے ڈویلپر کی ہوم ڈائرکٹری میں ایک فائل پر لاگ لکھے۔ اچھی ایپلی کیشنز نے کہیں فائل میں لاگ لکھے۔ /var/log.
اس کے مطابق، مزید، اچھے منتظمین نے اپنے انفراسٹرکچر میں کچھ چیزیں ترتیب دی تھیں کہ یہ لاگز گھوم سکتے ہیں - وہی rsyslog، جو ان لاگز کو دیکھتا ہے اور جب ان کے ساتھ کچھ ہوتا ہے، تو ان میں سے بہت سی چیزیں ہوتی ہیں، یہ بیک اپ کاپیاں بناتا ہے، وہاں لاگ رکھتا ہے۔ پرانی فائلوں کو حذف کرتا ہے، ایک ہفتے سے زیادہ، چھ ماہ اور کچھ اور۔ اصولی طور پر، ہمارے پاس پروویژن ہونا چاہیے تاکہ صرف اس لیے کہ ایپلی کیشن لاگ لکھتی ہے، پروڈکشن سرورز (جنگی سرور؟) پر جگہ ختم نہ ہو۔ اور، اس کے مطابق، لاگز کی وجہ سے پوری پیداوار بند نہیں ہوئی.
جب ہم Kubernetes کی دنیا میں جاتے ہیں اور وہاں وہی چیز چلاتے ہیں، تو سب سے پہلی چیز جس پر آپ توجہ دے سکتے ہیں وہ یہ ہے کہ لوگ، جیسا کہ انہوں نے ایک فائل میں لاگ لکھے ہیں، انہیں لکھنا جاری رکھیں۔
اس سے پتہ چلتا ہے کہ اگر ہم Kubernetes کے بارے میں بات کرتے ہیں تو، ڈاکر کنٹینر سے کہیں لاگ لکھنے کے لیے صحیح جگہ یہ ہے کہ انہیں ایپلی کیشن سے نام نہاد Stdout/Stderr، یعنی آپریٹنگ سسٹم کے معیاری آؤٹ پٹ اسٹریمز پر لکھنا، معیاری خرابی کی پیداوار Docker اور خاص طور پر Kubernetis میں اصولی طور پر لاگ لگانے کا یہ سب سے درست، آسان اور منطقی طریقہ ہے۔ کیونکہ اگر آپ کی ایپلیکیشن Stdout/Stderr پر لاگز لکھتی ہے، تو یہ Docker اور Kubernetes ایڈ آن پر منحصر ہے کہ وہ ان لاگز کے ساتھ کیا کریں۔ ڈوکر ڈیفالٹ طور پر اپنی خصوصی فائلیں JSON فارمیٹ میں بنائے گا۔
یہاں سوال یہ پیدا ہوتا ہے کہ آپ ان نوشتہ جات کے ساتھ آگے کیا کریں گے؟ سب سے آسان طریقہ واضح ہے، ہم میں کرنے کی صلاحیت ہے۔ kubectl logs اور ان "پوڈز" کے ان نوشتہ جات کو دیکھیں۔ لیکن، شاید، یہ بہت اچھا آپشن نہیں ہے - نوشتہ جات کے ساتھ کچھ اور کرنے کی ضرورت ہے۔
ابھی کے لیے، آئیے ایک ہی وقت میں بات کرتے ہیں، چونکہ ہم نے نوشتہ جات کے موضوع کو چھو لیا ہے، ایسی چیز کے بارے میں جیسے لاگز کو نظر آنا چاہیے۔ یعنی، یہ براہ راست Kubernetes پر لاگو نہیں ہوتا، لیکن جب ہم یہ سوچنا شروع کرتے ہیں کہ لاگز کے ساتھ کیا کرنا ہے، تو اس کے بارے میں بھی سوچنا اچھا ہوگا۔
ہمیں کسی قسم کے ٹول کی ضرورت ہے، خوش اسلوبی سے، جو ان لاگز کو لے جائے جو ہمارا ڈاکر اپنی فائلوں میں رکھتا ہے اور انہیں کہیں بھیج دیتا ہے۔ بڑے پیمانے پر، ہم عام طور پر ڈیمون سیٹ کی شکل میں کبرنیٹس کے اندر کسی قسم کے ایجنٹ کو لانچ کرتے ہیں - ایک لاگ جمع کرنے والا، جسے صرف یہ بتایا جاتا ہے کہ ڈوکر جو لاگ جمع کرتا ہے وہ کہاں واقع ہے۔ اور یہ جمع کرنے والا ایجنٹ انہیں آسانی سے لے جاتا ہے، شاید کسی نہ کسی طرح انہیں راستے میں پارس کرتا ہے، شاید انہیں کچھ اضافی میٹا معلومات سے مالا مال کرتا ہے اور بالآخر، انہیں کہیں ذخیرہ کرنے کے لیے بھیج دیتا ہے۔ تغیرات وہاں پہلے سے ہی ممکن ہیں۔ سب سے عام شاید Elasticsearch ہے، جہاں آپ لاگز کو محفوظ کر سکتے ہیں اور آپ انہیں وہاں سے آسانی سے بازیافت کر سکتے ہیں۔ پھر، درخواست کا استعمال کرتے ہوئے، Kibana کا استعمال کرتے ہوئے، مثال کے طور پر، ان کی بنیاد پر گراف بنائیں، ان کی بنیاد پر الرٹس بنائیں، وغیرہ۔
سب سے اہم خیال، میں اسے دوبارہ دہرانا چاہتا ہوں، وہ یہ ہے کہ Docker کے اندر، خاص طور پر Kubernetes کے اندر، اپنے لاگز کو فائل میں محفوظ کرنا بہت برا خیال ہے۔
کیونکہ سب سے پہلے، فائل میں کنٹینر کے اندر لاگز حاصل کرنا مشکل ہے۔ آپ کو پہلے کنٹینر میں جانا چاہیے، وہاں پر عمل کرنا چاہیے، اور پھر لاگز کو دیکھنا چاہیے۔ اگلا نکتہ یہ ہے کہ اگر آپ کے پاس کسی فائل میں لاگز ہیں، تو کنٹینرز میں عام طور پر کم سے کم ماحول ہوتا ہے اور ایسی کوئی افادیت نہیں ہوتی جو لاگز کے ساتھ عام کام کے لیے درکار ہوتی ہیں۔ انہیں دفن کریں، انہیں دیکھیں، انہیں ٹیکسٹ ایڈیٹر میں کھولیں۔ اگلا لمحہ وہ ہے جب ہمارے پاس کنٹینر کے اندر ایک فائل میں لاگ ان ہوتے ہیں، اگر اس کنٹینر کو ڈیلیٹ کر دیا جاتا ہے، تو آپ سمجھیں گے، لاگز اس کے ساتھ ہی مر جائیں گے۔ اس کے مطابق، کنٹینر کو دوبارہ شروع کرنے کا مطلب ہے کہ مزید لاگز نہیں ہیں۔ ایک بار پھر، برا اختیار.
اور آخری نکتہ یہ ہے کہ کنٹینرز کے اندر آپ کے پاس عام طور پر آپ کی درخواست ہوتی ہے اور بس - یہ عام طور پر واحد عمل ہوتا ہے۔ کسی بھی عمل کے بارے میں کوئی بات نہیں ہے جو آپ کے لاگز کے ساتھ فائلوں کو گھمائے گی۔ جیسے ہی لاگز فائل میں لکھے جانے لگتے ہیں، اس کا مطلب ہے کہ معاف کیجئے گا، ہم پروڈکشن سرور سے محروم ہونا شروع کر دیں گے۔ کیونکہ، سب سے پہلے، انہیں تلاش کرنا مشکل ہے، کوئی بھی ان کا سراغ نہیں لگاتا، اور کوئی بھی ان پر قابو نہیں رکھتا ہے - اس کے مطابق، فائل لامتناہی طور پر بڑھتی ہے جب تک کہ سرور پر جگہ ختم نہ ہو جائے۔ لہذا، میں دوبارہ کہتا ہوں کہ Docker میں لاگ ان کرنا، خاص طور پر Kubernetes میں، فائل میں لاگ ان کرنا برا خیال ہے۔
اگلا نکتہ، یہاں میں اس کے بارے میں دوبارہ بات کرنا چاہتا ہوں - چونکہ ہم نوشتہ جات کے موضوع پر بات کر رہے ہیں، لہٰذا اس کے بارے میں بات کرنا اچھا ہو گا کہ لاگز کو کیسا نظر آنا چاہیے تاکہ ان کے ساتھ کام کرنا آسان ہو۔ جیسا کہ میں نے کہا، موضوع کا براہ راست تعلق Kubernetes سے نہیں ہے، لیکن یہ DevOps کے موضوع سے بہت اچھی طرح سے متعلق ہے۔ ان دو مختلف محکموں - دیو اور اوپس کے درمیان ترقی ثقافت اور دوستی کے موضوع پر، تاکہ سب کو آرام ہو۔
اس کا مطلب یہ ہے کہ مثالی طور پر، آج، نوشتہ جات کو JSON فارمیٹ میں لکھا جانا چاہیے۔ اگر آپ کے پاس آپ کی اپنی کوئی ناقابل فہم ایپلی کیشن ہے، جو لاگز کو ناقابل فہم فارمیٹس میں لکھتی ہے کیونکہ آپ کسی قسم کا پرنٹ یا اس طرح کی کوئی چیز ڈالتے ہیں، تو اب وقت آگیا ہے کہ کسی قسم کے فریم ورک، کسی قسم کا ریپر گوگل کریں جو آپ کو عام لاگنگ کو لاگو کرنے کی اجازت دیتا ہے۔ وہاں JSON میں لاگنگ پیرامیٹرز کو فعال کریں، کیونکہ JSON ایک سادہ شکل ہے، اس کی تجزیہ کرنا آسان ہے۔
اگر آپ کا JSON کچھ معیارات کے مطابق کام نہیں کرتا ہے، کوئی نہیں جانتا ہے، تو کم از کم لاگ ان فارمیٹ میں لکھیں جس کی تجزیہ کی جا سکے۔ یہاں، بلکہ، اس حقیقت کے بارے میں سوچنے کے قابل ہے کہ، مثال کے طور پر، اگر آپ کنٹینرز کا ایک گروپ چلا رہے ہیں یا صرف nginx کے ساتھ پروسیس کر رہے ہیں، اور ہر ایک کی اپنی لاگنگ سیٹنگز ہیں، تو ایسا لگتا ہے کہ یہ آپ کے لیے بہت تکلیف دہ ہو گا۔ ان کی تجزیہ کریں. کیونکہ ہر نئی nginx مثال کے لئے آپ کو اپنا تجزیہ کار لکھنے کی ضرورت ہے، کیونکہ وہ لاگز کو مختلف طریقے سے لکھتے ہیں۔ ایک بار پھر، یہ یقینی بنانے کے بارے میں سوچنے کے قابل تھا کہ ان تمام nginx مثالوں میں ایک ہی لاگنگ کنفیگریشن ہے اور ان کے تمام لاگز بالکل یکساں طور پر لکھے ہیں۔ بالکل اسی طرح تمام ایپلی کیشنز پر لاگو ہوتا ہے۔
آخر میں، میں آگ میں ایندھن بھی شامل کرنا چاہتا ہوں کہ مثالی طور پر، ملٹی لائن فارمیٹ لاگ سے گریز کیا جانا چاہیے۔ یہاں بات یہ ہے، اگر آپ نے کبھی لاگ جمع کرنے والوں کے ساتھ کام کیا ہے، تو غالباً آپ نے دیکھا ہوگا کہ وہ آپ سے کیا وعدہ کرتے ہیں، کہ وہ ملٹی لائن لاگز کے ساتھ کام کر سکتے ہیں، انہیں جمع کرنے کا طریقہ جانتے ہیں، وغیرہ۔ درحقیقت، میری رائے میں، آج کل کوئی ایک بھی جمع کرنے والا کثیر لائن لاگز کو عام طور پر، مکمل طور پر اور غلطیوں کے بغیر جمع نہیں کر سکتا۔ انسانی طریقے سے، تاکہ یہ آسان اور غلطی سے پاک ہو۔
لیکن اسٹیک ٹریس ہمیشہ ملٹی لائن لاگز ہوتا ہے اور ان سے کیسے بچنا ہے۔ یہاں سوال یہ ہے کہ لاگ ایک واقعہ کا ریکارڈ ہے، اور stactrace دراصل لاگ نہیں ہے۔ اگر ہم لاگز جمع کرتے ہیں اور انہیں Elasticsearch میں کہیں رکھتے ہیں اور پھر ان سے گراف کھینچتے ہیں، اپنی سائٹ پر صارف کی سرگرمیوں کی کچھ رپورٹس بناتے ہیں، پھر جب آپ کو اسٹیک ٹریس ملتا ہے، تو اس کا مطلب ہے کہ کچھ غیر متوقع ہو رہا ہے۔ آپ کی درخواست میں ایک غیر منظم صورتحال۔ اور خود بخود اسٹیک ٹریس کو کسی ایسے سسٹم میں اپ لوڈ کرنا سمجھ میں آتا ہے جو انہیں ٹریک کر سکے۔
یہ سافٹ ویئر ہے (وہی سنٹری) جو خاص طور پر اسٹیک ٹریس کے ساتھ کام کرنے کے لیے بنایا گیا ہے۔ یہ فوری طور پر خودکار کام بنا سکتا ہے، انہیں کسی کو تفویض کر سکتا ہے، stacttraces ہونے پر الرٹ کر سکتا ہے، ان stacttraces کو ایک قسم کے مطابق گروپ کر سکتا ہے، وغیرہ۔ اصولی طور پر، جب ہم نوشتہ جات کے بارے میں بات کرتے ہیں تو stactraces کے بارے میں بات کرنا زیادہ معنی نہیں رکھتا، کیونکہ یہ سب کے بعد، مختلف مقاصد کے ساتھ مختلف چیزیں ہیں۔
تشکیل
اس کے بعد ہم کبرنیٹس میں کنفیگریشن کے بارے میں بات کرتے ہیں: اس کے ساتھ کیا کرنا ہے اور کبرنیٹس کے اندر ایپلی کیشنز کو کنفیگر کیا جانا چاہیے۔ عام طور پر، میں عام طور پر کہتا ہوں کہ ڈوکر کنٹینرز کے بارے میں نہیں ہے۔ ہر کوئی جانتا ہے کہ ڈوکر کنٹینرز کے بارے میں ہے، یہاں تک کہ جنہوں نے ڈوکر کے ساتھ زیادہ کام نہیں کیا ہے۔ میں دہراتا ہوں، ڈوکر کنٹینرز کے بارے میں نہیں ہے۔
ڈوکر، میری رائے میں، معیارات کے بارے میں ہے۔ اور عملی طور پر ہر چیز کے معیارات ہیں: آپ کی ایپلیکیشن بنانے کے معیار، آپ کی ایپلیکیشن انسٹال کرنے کے معیار۔
اور یہ چیز - ہم نے اسے پہلے استعمال کیا تھا، یہ صرف کنٹینرز کی آمد کے ساتھ خاص طور پر مقبول ہوا - اس چیز کو ENV (ماحول) متغیر کہتے ہیں، یعنی ماحولیاتی متغیرات جو آپ کے آپریٹنگ سسٹم میں ہیں۔ یہ عام طور پر آپ کی ایپلیکیشن کو کنفیگر کرنے کا ایک مثالی طریقہ ہے، کیونکہ اگر آپ کے پاس JAVA, Python, Go, Perl, God forbid میں ایپلی کیشنز ہیں اور وہ سبھی ڈیٹا بیس ہوسٹ، ڈیٹا بیس صارف، ڈیٹا بیس پاس ورڈ کے متغیرات کو پڑھ سکتے ہیں، تو یہ مثالی ہے۔ آپ کے پاس چار مختلف زبانوں میں ایپلی کیشنز ہیں جو ڈیٹا بیس پلان میں اسی طرح ترتیب دی گئی ہیں۔ مزید مختلف تشکیلات نہیں ہیں۔
ہر چیز کو ENV متغیرات کا استعمال کرتے ہوئے ترتیب دیا جا سکتا ہے۔ جب ہم Kubernetes کے بارے میں بات کرتے ہیں، تو تعیناتی کے اندر ہی ENV متغیرات کا اعلان کرنے کا ایک بہترین طریقہ ہے۔ اس کے مطابق، اگر ہم خفیہ ڈیٹا کے بارے میں بات کر رہے ہیں، تو ہم فوری طور پر ENV متغیرات (پاس ورڈ سے ڈیٹا بیس وغیرہ) کے خفیہ ڈیٹا کو ایک خفیہ میں دھکیل سکتے ہیں، ایک خفیہ کلسٹر بنا سکتے ہیں اور تعیناتی میں ENV کی تفصیل میں اشارہ کر سکتے ہیں کہ ہم براہ راست اعلان نہیں کر رہے ہیں۔ اس متغیر کی قدر، اور اس ڈیٹا بیس پاس ورڈ متغیر کی قدر کو راز سے پڑھا جائے گا۔ یہ معیاری Kubernetes سلوک ہے۔ اور یہ آپ کی ایپلی کیشنز کو کنفیگر کرنے کا سب سے بہترین آپشن ہے۔ صرف کوڈ کی سطح پر، دوبارہ یہ ڈویلپرز پر لاگو ہوتا ہے۔ اگر آپ DevOps ہیں، تو آپ پوچھ سکتے ہیں: "یار، براہ کرم اپنی درخواست کو ماحولیاتی متغیرات پڑھنا سکھائیں۔ اور ہم سب خوش ہوں گے۔"
اگر کمپنی میں ہر کوئی ایک ہی نام کے ماحولیاتی متغیرات کو پڑھتا ہے، تو یہ بہت اچھا ہے۔ تاکہ ایسا نہ ہو کہ کچھ پوسٹگریس ڈیٹا بیس کا انتظار کر رہے ہیں، دوسرے ڈیٹا بیس کے نام کا انتظار کر رہے ہیں، دوسرے کسی اور چیز کا انتظار کر رہے ہیں، دوسرے کسی قسم کے ڈی بی این کا انتظار کر رہے ہیں، تاکہ، اس کے مطابق، یکسانیت ہو۔
مسئلہ تب آتا ہے جب آپ کے پاس اتنے زیادہ ماحولیاتی متغیرات ہوتے ہیں کہ آپ صرف Deployment کھولتے ہیں - اور ماحولیاتی متغیرات کی پانچ سو لائنیں ہیں۔ اس صورت میں، آپ کے پاس ماحول کے متغیرات کو صرف بڑھا دیا گیا ہے - اور آپ کو مزید اپنے آپ کو اذیت دینے کی ضرورت نہیں ہے۔ اس صورت میں، configs کا استعمال شروع کرنا سمجھ میں آئے گا۔ یعنی اپنی ایپلیکیشن کو کنفیگس استعمال کرنے کی تربیت دیں۔
صرف سوال یہ ہے کہ تشکیلات وہ نہیں ہیں جو آپ سوچتے ہیں۔ Config.pi ایسی تشکیل نہیں ہے جو استعمال کرنے میں آسان ہو۔ یا آپ کے اپنے فارمیٹ میں کچھ تشکیل، متبادل طور پر تحفے میں - یہ بھی وہ تشکیل نہیں ہے جس کا میرا مطلب ہے۔
میں جس کے بارے میں بات کر رہا ہوں وہ قابل قبول فارمیٹس میں کنفیگریشن ہے، یعنی اب تک کا سب سے مشہور معیار .yaml سٹینڈرڈ ہے۔ یہ واضح ہے کہ اسے کیسے پڑھنا ہے، یہ انسانی پڑھنے کے قابل ہے، یہ واضح ہے کہ اسے درخواست سے کیسے پڑھنا ہے۔
اس کے مطابق، YAML کے علاوہ، آپ بھی، مثال کے طور پر، JSON استعمال کر سکتے ہیں، وہاں سے ایپلیکیشن کنفیگریشن کو پڑھنے کے معاملے میں پارس کرنا YAML کی طرح ہی آسان ہے۔ لوگوں کو پڑھنے میں یہ نمایاں طور پر زیادہ تکلیف دہ ہے۔ آپ فارمیٹ کی کوشش کر سکتے ہیں, ایک la ini. انسانی نقطہ نظر سے اسے پڑھنا کافی آسان ہے، لیکن خود بخود اس پر کارروائی کرنا تکلیف دہ ہو سکتا ہے، اس لحاظ سے کہ اگر آپ کبھی بھی اپنی تشکیلات تیار کرنا چاہتے ہیں، تو ini فارمیٹ پیدا کرنے میں پہلے سے ہی تکلیف ہو سکتی ہے۔
لیکن کسی بھی صورت میں، آپ جو بھی فارمیٹ منتخب کرتے ہیں، بات یہ ہے کہ Kubernetes کے نقطہ نظر سے یہ بہت آسان ہے۔ آپ کنفیگ میپ میں اپنی پوری تشکیل کوبرنیٹس کے اندر رکھ سکتے ہیں۔ اور پھر اس کنفیگریشن میپ کو لیں اور اسے اپنے پوڈ کے اندر کسی مخصوص ڈائرکٹری میں نصب کرنے کو کہیں، جہاں آپ کی ایپلی کیشن اس کنفیگریشن میپ سے اس طرح پڑھے گی جیسے یہ صرف ایک فائل ہو۔ درحقیقت، یہ وہی ہے جو کرنا اچھا ہے جب آپ کے پاس آپ کی درخواست میں ترتیب کے بہت سے اختیارات ہوں۔ یا یہ صرف ایک قسم کا پیچیدہ ڈھانچہ ہے، گھوںسلا ہے۔
اگر آپ کے پاس کنفیگریشن میپ ہے، تو آپ اپنی ایپلیکیشن کو بہت اچھی طرح سے سکھا سکتے ہیں، مثال کے طور پر، فائل میں تبدیلیوں کو خود بخود ٹریک کرنا جہاں کنفیگ میپ لگایا گیا ہے، اور کنفیگریشنز تبدیل ہونے پر آپ کی ایپلیکیشن کو خود بخود دوبارہ لوڈ کرنا۔ یہ عام طور پر ایک مثالی آپشن ہوگا۔
ایک بار پھر، میں نے پہلے ہی اس کے بارے میں بات کی ہے - خفیہ معلومات configmap میں نہیں ہے، خفیہ معلومات متغیر میں نہیں ہے، خفیہ معلومات راز میں نہیں ہے. وہاں سے، اس خفیہ معلومات کو سفارت کاری سے جوڑیں۔ عام طور پر ہم گٹ میں Kubernetes اشیاء، تعیناتیوں، configmaps، خدمات کی تمام تفصیل محفوظ کرتے ہیں۔ اس کے مطابق، گٹ میں ڈیٹا بیس میں پاس ورڈ ڈالنا، چاہے وہ آپ کا گٹ ہی ہو، جو آپ کے پاس کمپنی میں اندرونی طور پر موجود ہے، برا خیال ہے۔ کیونکہ، کم از کم، گٹ سب کچھ یاد رکھتا ہے اور وہاں سے پاس ورڈ ہٹانا اتنا آسان نہیں ہے۔
صحت کی جانچ
اگلا نکتہ یہ چیز ہے جسے ہیلتھ چیک کہتے ہیں۔ عام طور پر، ہیلتھ چیک صرف ایک چیک ہے کہ آپ کی درخواست کام کر رہی ہے۔ اسی وقت، ہم اکثر کچھ مخصوص ویب ایپلی کیشنز کے بارے میں بات کرتے ہیں، جن کے لیے، صحت کی جانچ کے نقطہ نظر سے (بہتر ہے کہ یہاں ترجمہ نہ کیا جائے) معیاری، وہ عام طور پر کرتے ہیں /health.
اس یو آر ایل تک رسائی حاصل کرتے وقت، اس کے مطابق، ہماری درخواست یا تو کہتی ہے "ہاں، ٹھیک ہے، میرے ساتھ سب کچھ ٹھیک ہے، 200" یا "نہیں، میرے ساتھ سب کچھ ٹھیک نہیں ہے، کچھ 500۔" اس کے مطابق، اگر ہماری ایپلی کیشن HTTP نہیں ہے، ویب ایپلیکیشن نہیں ہے، اب ہم کسی قسم کے ڈیمون کے بارے میں بات کر رہے ہیں، ہم یہ جان سکتے ہیں کہ صحت کی جانچ کیسے کی جائے۔ یعنی یہ ضروری نہیں ہے، اگر ایپلی کیشن HTTP نہیں ہے، تو ہر چیز صحت کی جانچ کے بغیر کام کرتی ہے اور یہ کسی بھی طرح نہیں ہو سکتا۔ آپ وقتا فوقتا فائل میں کچھ معلومات کو اپ ڈیٹ کر سکتے ہیں، آپ اپنے ڈیمون کے لیے کچھ خاص کمانڈ لے کر آ سکتے ہیں، جیسے، daemon status، جو کہے گا "ہاں، سب کچھ ٹھیک ہے، ڈیمن کام کر رہا ہے، یہ زندہ ہے۔"
یہ کس لیے ہے؟ پہلی اور سب سے واضح چیز شاید یہ ہے کہ ہیلتھ چیک کی ضرورت کیوں ہے - یہ سمجھنے کے لیے کہ ایپلی کیشن کام کر رہی ہے۔ میرا مطلب ہے، یہ صرف بیوقوف ہے، جب یہ اب ہے، ایسا لگتا ہے کہ یہ کام کر رہا ہے، لہذا آپ یقین کر سکتے ہیں کہ یہ کام کر رہا ہے۔ اور یہ پتہ چلتا ہے کہ ایپلی کیشن چل رہی ہے، کنٹینر چل رہا ہے، مثال کام کر رہی ہے، سب کچھ ٹھیک ہے - اور پھر صارفین نے پہلے ہی تکنیکی مدد سے تمام فون نمبر کاٹ دیے ہیں اور کہتے ہیں "آپ کیا ہیں...، آپ؟ سو گیا، کچھ کام نہیں کر رہا۔"
صحت کی جانچ صارف کے نقطہ نظر سے دیکھنے کا ایک ایسا طریقہ ہے کہ یہ کام کرتا ہے۔ طریقوں میں سے ایک۔ آئیے اسے اس طرح ڈالتے ہیں۔ Kubernetes کے نقطہ نظر سے، یہ بھی سمجھنے کا ایک طریقہ ہے کہ ایپلیکیشن کب شروع ہوتی ہے، کیونکہ ہم سمجھتے ہیں کہ کنٹینر کو کب لانچ کیا گیا، بنایا گیا اور شروع کیا گیا، اور اس کنٹینر میں ایپلی کیشن کو براہ راست کب لانچ کیا گیا اس میں فرق ہے۔ کیونکہ اگر ہم کچھ اوسط جاوا ایپلی کیشن لیتے ہیں اور اسے گودی میں لانچ کرنے کی کوشش کرتے ہیں، تو چالیس سیکنڈ، یا ایک منٹ، یا دس منٹ تک، یہ بالکل ٹھیک شروع ہو سکتا ہے۔ اس صورت میں، آپ کم از کم اس کی بندرگاہوں پر دستک دے سکتے ہیں، یہ وہاں جواب نہیں دے گا، یعنی یہ ابھی تک ٹریفک حاصل کرنے کے لیے تیار نہیں ہے۔
ایک بار پھر، صحت کی جانچ کی مدد سے اور اس حقیقت کی مدد سے کہ ہم یہاں کا رخ کر رہے ہیں، ہم Kubernetes میں سمجھ سکتے ہیں کہ درخواست میں نہ صرف کنٹینر بڑھ گیا ہے، بلکہ ایپلی کیشن خود شروع ہو چکی ہے، یہ پہلے ہی جواب دے رہی ہے۔ ہیلتھ چیک، جس کا مطلب ہے کہ ہم وہاں ٹریفک بھیج سکتے ہیں۔
میں اب جس کے بارے میں بات کر رہا ہوں اسے Kubernetes کے اندر ریڈی نیس/Liveness ٹیسٹ کہا جاتا ہے؛ اس کے مطابق، ہمارے تیاری کے ٹیسٹ بیلنسنگ میں ایپلیکیشن کی دستیابی کے ذمہ دار ہیں۔ یعنی، اگر درخواست میں تیاری کے ٹیسٹ کیے جائیں، تو سب کچھ ٹھیک ہے، کلائنٹ ٹریفک ایپلی کیشن پر جا رہا ہے۔ اگر تیاری کے ٹیسٹ نہیں کیے جاتے ہیں، تو درخواست صرف حصہ نہیں لیتی ہے، یہ خاص مثال توازن میں حصہ نہیں لیتی ہے، اسے توازن سے ہٹا دیا جاتا ہے، کلائنٹ ٹریفک نہیں چلتی ہے۔ اس کے مطابق، Kubernetes کے اندر لائیونس ٹیسٹ کی ضرورت ہے تاکہ اگر ایپلی کیشن پھنس جائے، تو اسے دوبارہ شروع کیا جا سکے۔ اگر لائیونس ٹیسٹ کسی ایسی ایپلیکیشن کے لیے کام نہیں کرتا جس کا اعلان Kubernetes میں کیا گیا ہے، تو ایپلیکیشن کو نہ صرف توازن سے ہٹایا جاتا ہے، بلکہ اسے دوبارہ شروع کیا جاتا ہے۔
اور یہاں ایک اہم نکتہ ہے جس کا میں ذکر کرنا چاہوں گا: ایک عملی نقطہ نظر سے، تیاری کا امتحان عام طور پر زیادہ کثرت سے استعمال ہوتا ہے اور اس کی زیادہ کثرت سے ضرورت ہوتی ہے۔ یعنی، بغیر سوچے سمجھے تیاری اور زندہ دلی دونوں ٹیسٹوں کا اعلان کرنا، کیونکہ Kubernetes ایسا کر سکتا ہے، اور آئیے ہر وہ چیز استعمال کریں جو یہ کر سکتا ہے، بہت اچھا خیال نہیں ہے۔ میں اس کی وجہ بتاؤں گا۔ کیونکہ ٹیسٹنگ میں پوائنٹ نمبر دو یہ ہے کہ اپنے ہیلتھ چیکس میں بنیادی سروس کو چیک کرنا اچھا خیال ہوگا۔ اس کا مطلب یہ ہے کہ اگر آپ کے پاس کوئی ایسی ویب ایپلیکیشن ہے جو کچھ معلومات فراہم کرتی ہے، جس کے نتیجے میں اسے، قدرتی طور پر، کہیں سے لینا چاہیے۔ مثال کے طور پر ڈیٹا بیس میں۔ ٹھیک ہے، یہ اس REST API میں آنے والی معلومات کو اسی ڈیٹا بیس میں محفوظ کرتا ہے۔ پھر، اس کے مطابق، اگر آپ کا ہیلتھ چیک صرف رابطہ شدہ سلیش ہیلتھ کی طرح جواب دیتا ہے، تو ایپلیکیشن کہتی ہے "200، ٹھیک ہے، سب کچھ ٹھیک ہے" اور ساتھ ہی آپ کی درخواست کا ڈیٹا بیس ناقابل رسائی ہے، اور ہیلتھ چیک کی درخواست کہتی ہے "200، ٹھیک ہے، سب کچھ ٹھیک ہے۔ "- یہ صحت کی خراب جانچ ہے۔ اس طرح کام نہیں کرنا چاہیے۔
یعنی آپ کی درخواست، جب اس پر کوئی درخواست آتی ہے۔ /health، یہ صرف جواب نہیں دیتا، "200، ٹھیک ہے"، یہ سب سے پہلے، مثال کے طور پر، ڈیٹا بیس میں جاتا ہے، اس سے جڑنے کی کوشش کرتا ہے، وہاں کوئی بہت بنیادی کام کرتا ہے، جیسے کہ ایک کو منتخب کریں، بس چیک کرتا ہے کہ اس میں کوئی کنکشن موجود ہے۔ ڈیٹا بیس اور آپ ڈیٹا بیس سے استفسار کرسکتے ہیں۔ اگر یہ سب کامیاب رہا، تو جواب ہے "200، ٹھیک ہے۔" اگر یہ کامیاب نہیں ہوتا ہے، تو یہ کہتا ہے کہ ایک خرابی ہے، ڈیٹا بیس دستیاب نہیں ہے۔
لہذا، اس سلسلے میں، میں دوبارہ ریڈی نیس/لیونیس ٹیسٹس کی طرف لوٹتا ہوں - کیوں کہ آپ کو ریڈی نیس ٹیسٹ کی ضرورت ہے، لیکن لائیونس ٹیسٹ زیر بحث ہے۔ کیونکہ اگر آپ صحت کی جانچ کو بالکل ٹھیک بیان کرتے ہیں جیسا کہ میں نے ابھی کہا ہے، تو پتہ چلے گا کہ یہ مثال کے حصے میں دستیاب نہیں ہے۔в или со всех instanceمثال کے طور پر ڈیٹا بیس میں۔ جب آپ نے تیاری کے ٹیسٹ کا اعلان کیا تو ہماری صحت کی جانچیں ناکام ہونے لگیں، اور اس کے مطابق وہ تمام ایپلی کیشنز جن سے ڈیٹا بیس تک رسائی ممکن نہیں ہے، وہ صرف توازن سے بند کر دی جاتی ہیں اور درحقیقت صرف ایک نظر انداز حالت میں "ہینگ" ہوتی ہیں اور اپنے ڈیٹا بیس کا انتظار کرتی ہیں۔ کام.
اگر ہم نے لائیونس ٹیسٹ کا اعلان کر دیا ہے، تو تصور کریں، ہمارا ڈیٹا بیس ٹوٹ گیا ہے، اور آپ کے Kubernetes میں آدھی ہر چیز دوبارہ شروع ہو جاتی ہے کیونکہ لائیونس ٹیسٹ ناکام ہو جاتا ہے۔ اس کا مطلب ہے کہ آپ کو دوبارہ شروع کرنے کی ضرورت ہے۔ یہ آپ کی خواہش بالکل نہیں ہے، مجھے عملی طور پر ذاتی تجربہ بھی تھا۔ ہمارے پاس ایک چیٹ ایپلی کیشن تھی جو جے ایس میں لکھی گئی تھی اور اسے مونگو ڈیٹا بیس میں فیڈ کیا گیا تھا۔ اور مسئلہ یہ تھا کہ یہ کبرنیٹس کے ساتھ میرے کام کے آغاز میں تھا، ہم نے ٹیسٹوں کی تیاری، زندہ دلی کو اس اصول پر بیان کیا کہ کبرنیٹس یہ کر سکتے ہیں، لہذا ہم اسے استعمال کریں گے۔ اس کے مطابق، کسی وقت مونگو تھوڑا سا "خراب" ہو گیا اور نمونہ ناکام ہونے لگا۔ اس کے مطابق، بارش کے ٹیسٹ کے مطابق، پھلیوں نے "مارنا" شروع کر دیا.
جیسا کہ آپ سمجھتے ہیں، جب وہ "مارے" جاتے ہیں، تو یہ ایک چیٹ ہے، یعنی اس پر کلائنٹس کے بہت سے رابطے ہوتے ہیں۔ وہ "مارے گئے" بھی ہیں - نہیں، کلائنٹ نہیں، صرف کنکشنز - سب ایک ہی وقت میں نہیں، اور اس حقیقت کی وجہ سے کہ وہ ایک ہی وقت میں نہیں مارے گئے، کچھ پہلے، کچھ بعد میں، وہ ایک ہی وقت میں شروع نہیں ہوتے ہیں۔ وقت اس کے علاوہ معیاری بے ترتیب، ہم ہر بار درخواست کے آغاز کے وقت کی ملی سیکنڈ کی درستگی کے ساتھ پیشین گوئی نہیں کر سکتے، اس لیے وہ اسے ایک وقت میں ایک بار کرتے ہیں۔ ایک انفو اسپاٹ بڑھتا ہے، بیلنسنگ میں شامل ہوتا ہے، تمام کلائنٹ وہاں آتے ہیں، یہ اتنا بوجھ برداشت نہیں کر سکتا، کیونکہ یہ اکیلا ہے، اور، تقریباً ایک درجن لوگ وہاں کام کر رہے ہیں، اور وہ گر جاتا ہے۔ اگلا اٹھتا ہے، سارا بوجھ اس پر ہے، وہ بھی گرتا ہے۔ ٹھیک ہے، یہ فالس صرف جھرن جاری ہے. آخر میں، یہ کیسے حل ہوا - ہمیں صرف اس ایپلی کیشن پر صارف کی ٹریفک کو سختی سے روکنا تھا، تمام مثالوں کو بڑھنے دینا تھا اور پھر تمام صارف ٹریفک کو ایک ساتھ شروع کرنا تھا تاکہ یہ پہلے ہی تمام دس مثالوں میں تقسیم ہو جائے۔
اگر اس لائیونس ٹیسٹ کا اعلان نہ کیا جاتا، جو اس سب کو دوبارہ شروع کرنے پر مجبور کر دیتا، تو ایپلیکیشن اسے ٹھیک ہینڈل کر لیتی۔ لیکن توازن سے لے کر ہر چیز ہمارے لیے غیر فعال ہے، کیونکہ ڈیٹا بیس ناقابل رسائی ہیں اور تمام صارفین "گر گئے" ہیں۔ پھر، جب یہ ڈیٹا بیس دستیاب ہو جاتا ہے، تو سب کچھ توازن میں شامل ہو جاتا ہے، لیکن ایپلی کیشنز کو دوبارہ شروع کرنے کی ضرورت نہیں ہے، اور اس پر وقت اور وسائل کو ضائع کرنے کی ضرورت نہیں ہے۔ وہ سب پہلے ہی یہاں موجود ہیں، وہ ٹریفک کے لیے تیار ہیں، اس لیے ٹریفک کھلتا ہے، سب کچھ ٹھیک ہے - ایپلیکیشن اپنی جگہ پر ہے، سب کچھ کام کرتا رہتا ہے۔
لہذا، تیاری اور زندہ دلی کے ٹیسٹ مختلف ہیں، اس کے علاوہ، آپ نظریاتی طور پر مختلف صحت کی جانچ کر سکتے ہیں، ایک قسم کا radii، ایک قسم کا liv، مثال کے طور پر، اور مختلف چیزوں کو چیک کر سکتے ہیں۔ تیاری کے ٹیسٹ کے دوران، اپنے بیک اینڈ کو چیک کریں۔ اور لائیونس ٹیسٹ پر، مثال کے طور پر، آپ اس نقطہ نظر سے چیک نہیں کرتے ہیں کہ لائیونس ٹیسٹ عام طور پر صرف جواب دینے والی درخواست ہے، اگر یہ بالکل بھی جواب دینے کے قابل ہے۔
کیونکہ زندہ دلی کا امتحان، بڑے پیمانے پر، تب ہوتا ہے جب ہم "پھنسے" ہوتے ہیں۔ ایک لامتناہی لوپ شروع ہو گیا ہے یا کچھ اور - اور مزید درخواستوں پر کارروائی نہیں کی جاتی ہے۔ لہذا، ان کو الگ کرنا بھی سمجھ میں آتا ہے - اور ان میں مختلف منطق کو نافذ کرنا۔
اس بارے میں کہ جب آپ کا ٹیسٹ ہوتا ہے، جب آپ صحت کی جانچ کرتے ہیں تو آپ کو کیا جواب دینے کی ضرورت ہوتی ہے۔ یہ صرف واقعی ایک درد ہے. جو لوگ اس سے واقف ہیں وہ شاید ہنسیں گے - لیکن سنجیدگی سے، میں نے اپنی زندگی میں ایسی خدمات دیکھی ہیں جو 200% معاملات میں "XNUMX" کا جواب دیتی ہیں۔ یعنی کون کامیاب ہے۔ لیکن ایک ہی وقت میں جواب کے جسم میں وہ لکھتے ہیں "فلاں فلاں غلطی"۔
یعنی رسپانس سٹیٹس آپ کے پاس آتا ہے - سب کچھ کامیاب ہے۔ لیکن ایک ہی وقت میں، آپ کو جسم کو پارس کرنا ہوگا، کیونکہ جسم کہتا ہے "معذرت، درخواست ایک غلطی کے ساتھ ختم ہوئی" اور یہ صرف حقیقت ہے۔ میں نے اسے حقیقی زندگی میں دیکھا۔
اور اس لیے کہ کچھ لوگوں کو یہ مضحکہ خیز نہیں لگتا، اور دوسروں کو یہ بہت تکلیف دہ لگتا ہے، پھر بھی یہ ایک سادہ اصول پر عمل کرنے کے قابل ہے۔ صحت کی جانچ میں، اور اصولی طور پر ویب ایپلیکیشنز کے ساتھ کام کرتے وقت۔
اگر سب کچھ ٹھیک رہا تو پھر دو سواں جواب دیں۔ اصولی طور پر، کوئی بھی دو سواں جواب آپ کے مطابق ہوگا۔ اگر آپ ragsy کو اچھی طرح سے پڑھتے ہیں اور جانتے ہیں کہ کچھ ردعمل کی کیفیتیں دوسروں سے مختلف ہیں، تو مناسب کے ساتھ جواب دیں: 204، 5، 10، 15، جو بھی ہو۔ اگر یہ بہت اچھا نہیں ہے، تو صرف "دو صفر صفر"۔ اگر سب کچھ خراب ہو جائے اور ہیلتھ چیک کا جواب نہ آئے تو کسی بھی پانچ سوویں کے ساتھ جواب دیں۔ ایک بار پھر، اگر آپ سمجھتے ہیں کہ کس طرح جواب دینا ہے، تو جواب کی مختلف حالتیں ایک دوسرے سے کیسے مختلف ہیں۔ اگر آپ کو سمجھ نہیں آتی ہے، تو 502 آپ کا اختیار ہے کہ اگر کچھ غلط ہو جائے تو ہیلتھ چیکس کا جواب دیں۔
یہ ایک اور نقطہ ہے، میں بنیادی خدمات کی جانچ پڑتال کے بارے میں تھوڑا سا واپس کرنا چاہتا ہوں۔ اگر آپ شروع کرتے ہیں، مثال کے طور پر، ان تمام بنیادی خدمات کی جانچ کرنا جو آپ کی درخواست کے پیچھے کھڑی ہیں - عمومی طور پر ہر چیز۔ مائیکرو سروس فن تعمیر کے نقطہ نظر سے ہمیں جو کچھ ملتا ہے، ہمارے پاس "کم کپلنگ" جیسا تصور ہے - یعنی جب آپ کی خدمات ایک دوسرے پر کم سے کم انحصار کرتی ہیں۔ اگر ان میں سے کوئی ایک ناکام ہو جاتا ہے، تو اس فعالیت کے بغیر باقی سب کام کرتے رہیں گے۔ کچھ فعالیت صرف کام نہیں کرتی ہے۔ اس کے مطابق، اگر آپ تمام صحت کی جانچ پڑتال کو ایک دوسرے سے جوڑ دیتے ہیں، تو آپ بنیادی ڈھانچے میں ایک چیز گرنے کے ساتھ ختم ہو جائیں گے، اور چونکہ یہ گر گئی ہے، تمام خدمات کی تمام صحت کی جانچ پڑتال بھی ناکام ہونے لگتی ہے - اور عام طور پر اس کے لیے مزید انفراسٹرکچر موجود ہے۔ مکمل مائیکرو سروس فن تعمیر نمبر وہاں سب کچھ اندھیرا ہو گیا۔
لہذا، میں اسے دوبارہ دہرانا چاہتا ہوں کہ آپ کو بنیادی خدمات کو چیک کرنے کی ضرورت ہے، جن کے بغیر آپ کی درخواست سو فیصد معاملات میں اپنا کام نہیں کر سکتی۔ یعنی، یہ منطقی ہے کہ اگر آپ کے پاس REST API ہے جس کے ذریعے صارف ڈیٹا بیس میں محفوظ کرتا ہے یا ڈیٹا بیس سے بازیافت کرتا ہے، تو ڈیٹا بیس کی عدم موجودگی میں، آپ اپنے صارفین کے ساتھ کام کرنے کی ضمانت نہیں دے سکتے۔
لیکن اگر آپ کے صارفین، جب آپ انہیں ڈیٹا بیس سے باہر لے جاتے ہیں تو، اضافی طور پر کسی دوسرے بیک اینڈ سے، جو آپ فرنٹ اینڈ کو جواب بھیجنے سے پہلے درج کرتے ہیں، کچھ دوسرے میٹا ڈیٹا کے ساتھ افزودہ کیا جاتا ہے - اور یہ بیک اینڈ دستیاب نہیں ہے، اس کا مطلب ہے کہ آپ اپنے میٹا ڈیٹا کے کسی حصے کے بغیر جواب دیں۔
اگلا، ایپلی کیشنز لانچ کرتے وقت ہمارے پاس ایک تکلیف دہ مسئلہ بھی ہے۔
درحقیقت، یہ صرف بڑے پیمانے پر Kubernetes پر لاگو نہیں ہوتا ہے؛ ایسا ہی ہوا کہ کسی قسم کی بڑے پیمانے پر ترقی اور خاص طور پر DevOps کی ثقافت اسی وقت Kubernetes کی طرح پھیلنا شروع ہوئی۔ لہذا، بڑے پیمانے پر، یہ پتہ چلتا ہے کہ آپ کو Kubernetes کے بغیر اپنی درخواست کو خوبصورتی سے بند کرنے کی ضرورت ہے۔ Kubernetes سے پہلے بھی، لوگ ایسا کرتے تھے، لیکن Kubernetes کی آمد کے ساتھ، ہم نے بڑے پیمانے پر اس کے بارے میں بات کرنا شروع کردی۔
مکرم شٹ ڈاؤن
عمومی طور پر گریس فل شٹ ڈاؤن کیا ہے اور اس کی ضرورت کیوں ہے؟ یہ اس وقت ہوتا ہے جب آپ کی درخواست کسی وجہ سے کریش ہو جاتی ہے، آپ کو یہ کرنے کی ضرورت ہے۔ app stop - یا آپ کو، مثال کے طور پر، آپریٹنگ سسٹم سے سگنل موصول ہوتا ہے، آپ کی درخواست کو اسے سمجھنا چاہیے اور اس کے بارے میں کچھ کرنا چاہیے۔ بدترین صورت حال، یقیناً، وہ ہے جب آپ کی درخواست کو ایک SIGTERM موصول ہوتا ہے اور یہ "SIGTERM، چلتے ہیں، کام کرتے ہیں، کچھ نہیں کرتے۔" یہ سراسر برا آپشن ہے۔
تقریباً اتنا ہی برا آپشن ہوتا ہے جب آپ کی درخواست کو SIGTERM موصول ہوتا ہے اور وہ اس طرح ہوتا ہے کہ "انہوں نے کہا segterm، اس کا مطلب ہے کہ ہم ختم ہو رہے ہیں، میں نے نہیں دیکھا، مجھے کسی صارف کی درخواستوں کا علم نہیں ہے، مجھے نہیں معلوم کہ کس قسم کی درخواستوں پر میں ابھی کام کر رہا ہوں، انہوں نے SIGTERM کہا، اس کا مطلب ہے کہ ہم ختم کر رہے ہیں" یہ بھی ایک برا آپشن ہے۔
کون سا آپشن اچھا ہے؟ پہلا نکتہ یہ ہے کہ آپریشنز کی تکمیل کو مدنظر رکھا جائے۔ آپ کے سرور کے لیے ایک اچھا آپشن یہ ہے کہ اگر اسے SIGTERM موصول ہوتا ہے تو وہ کیا کرتا ہے۔
SIGTERM ایک نرم شٹ ڈاؤن ہے، اسے خاص طور پر ڈیزائن کیا گیا ہے، اسے کوڈ کی سطح پر روکا جا سکتا ہے، اس پر کارروائی کی جا سکتی ہے، کہو کہ اب انتظار کرو، ہم پہلے جو کام ہمارے پاس ہے وہ ختم کریں گے، پھر باہر نکلیں گے۔
Kubernetes کے نقطہ نظر سے، یہ ایسا ہی لگتا ہے۔ جب ہم Kubernetes کلسٹر میں چلنے والے کسی پوڈ سے کہتے ہیں، "براہ کرم روکیں، چلے جائیں" یا ہمیں دوبارہ شروع کیا جاتا ہے، یا ایک اپ ڈیٹ اس وقت ہوتا ہے جب Kubernetes پوڈ کو دوبارہ بناتا ہے، Kubernetes پوڈ کو صرف وہی SIGTERM پیغام بھیجتا ہے، انتظار کرتا ہے۔ کچھ وقت، اور، یہ وہ وقت ہے جس کا وہ انتظار کرتا ہے، اسے بھی ترتیب دیا جاتا ہے، ڈپلوموں میں ایسا خاص پیرامیٹر ہوتا ہے اور اسے گریس فل شٹ ڈاؤن ٹائم آؤٹ کہتے ہیں۔ جیسا کہ آپ سمجھتے ہیں، اس کو کچھ بھی نہیں کہا جاتا ہے، اور یہ کسی بھی چیز کے لیے نہیں ہے جس کے بارے میں ہم اب بات کر رہے ہیں۔
وہاں ہم خاص طور پر یہ کہہ سکتے ہیں کہ ہمیں SIGTERM کو ایپلیکیشن بھیجنے کے وقت کے درمیان کتنا انتظار کرنے کی ضرورت ہے اور جب ہم سمجھتے ہیں کہ لگتا ہے کہ ایپلی کیشن کسی چیز کے لیے پاگل ہو گئی ہے یا "اٹک" گئی ہے اور ختم ہونے والی نہیں ہے - اور ہمیں اسے SIGKILL بھیجیں، یعنی مشکل سے اس کا کام مکمل کریں۔ یعنی، اس کے مطابق، ہمارے پاس کسی قسم کا ڈیمون چل رہا ہے، یہ کارروائیوں پر کارروائی کرتا ہے۔ ہم سمجھتے ہیں کہ اوسطاً ہمارے آپریشنز جن پر ڈیمون کام کرتا ہے ایک وقت میں 30 سیکنڈ سے زیادہ نہیں چلتے۔ اس کے مطابق، جب SIGTERM آتا ہے، ہم سمجھتے ہیں کہ ہمارا ڈیمون، زیادہ سے زیادہ، SIGTERM کے 30 سیکنڈ بعد ختم کر سکتا ہے۔ ہم اسے لکھتے ہیں، مثال کے طور پر، صرف اس صورت میں 45 سیکنڈ اور کہتے ہیں کہ SIGTERM۔ اس کے بعد ہم 45 سیکنڈ انتظار کرتے ہیں۔ نظریہ میں، اس وقت کے دوران شیطان کو اپنا کام مکمل کر لینا چاہیے تھا اور خود ہی ختم ہو جانا چاہیے۔ لیکن اگر اچانک ایسا نہیں ہو سکا، تو اس کا مطلب ہے کہ یہ زیادہ تر پھنس گیا ہے—یہ اب ہماری درخواستوں پر عام طور پر کارروائی نہیں کر رہا ہے۔ اور 45 سیکنڈ میں آپ محفوظ طریقے سے، درحقیقت، اسے کیل مار سکتے ہیں۔
اور یہاں، حقیقت میں، یہاں تک کہ 2 پہلوؤں کو بھی مدنظر رکھا جا سکتا ہے۔ سب سے پہلے، یہ سمجھیں کہ اگر آپ کو کوئی درخواست موصول ہوئی تو آپ نے کسی طرح اس کے ساتھ کام کرنا شروع کر دیا اور صارف کو کوئی جواب نہیں دیا، لیکن مثال کے طور پر آپ کو SIGTERM موصول ہوا۔ اسے بہتر کرنا اور صارف کو جواب دینا سمجھ میں آتا ہے۔ اس سلسلے میں یہ پوائنٹ نمبر ایک ہے۔ یہاں پوائنٹ نمبر دو یہ ہے کہ اگر آپ اپنی درخواست خود لکھتے ہیں تو عام طور پر فن تعمیر کو اس طرح بنائیں کہ آپ کو درخواست کی درخواست موصول ہو، پھر آپ کوئی کام شروع کریں، کہیں سے فائلیں ڈاؤن لوڈ کرنا شروع کریں، ڈیٹا بیس ڈاؤن لوڈ کریں، اور کیا کچھ نہیں۔ وہ. عام طور پر، آپ کا صارف، آپ کی درخواست آدھے گھنٹے کے لیے لٹکی رہتی ہے اور آپ کو اس کا جواب دینے کا انتظار کرتا ہے - پھر، زیادہ تر امکان ہے، آپ کو فن تعمیر پر کام کرنے کی ضرورت ہے۔ یعنی، صرف عام فہم کو بھی مدنظر رکھیں کہ اگر آپ کے کام مختصر ہیں، تو SIGTERM کو نظر انداز کرنا اور اس میں ترمیم کرنا سمجھ میں آتا ہے۔ اگر آپ کے کام طویل ہیں، تو اس معاملے میں SIGTERM کو نظر انداز کرنا کوئی معنی نہیں رکھتا۔ اس طرح کی طویل کارروائیوں سے بچنے کے لیے فن تعمیر کو دوبارہ ڈیزائن کرنا سمجھ میں آتا ہے۔ تاکہ صارفین صرف انتظار نہ کریں اور انتظار کریں۔ مجھے نہیں معلوم، وہاں کسی قسم کی ویب ساکٹ بنائیں، ریورس ہکس بنائیں جو آپ کا سرور پہلے ہی کلائنٹ کو بھیجے گا، اور کچھ بھی، لیکن صارف کو آدھے گھنٹے تک لٹکنے پر مجبور نہ کریں اور صرف ایک سیشن کا انتظار کریں جب تک کہ آپ اسے جواب دو. کیونکہ یہ غیر متوقع ہے کہ یہ کہاں ٹوٹ سکتا ہے۔
جب آپ کی درخواست ختم ہوجاتی ہے، تو آپ کو کچھ مناسب ایگزٹ کوڈ فراہم کرنا چاہیے۔ یعنی، اگر آپ کی درخواست کو بند کرنے، روکنے کے لیے کہا گیا تھا، اور یہ خود کو عام طور پر روکنے کے قابل ہے، تو آپ کو کسی قسم کا ایگزٹ کوڈ 1,5,255 وغیرہ واپس کرنے کی ضرورت نہیں ہے۔ کوئی بھی چیز جو صفر کوڈ نہیں ہے، کم از کم لینکس سسٹم میں، مجھے اس کا یقین ہے، ناکام سمجھا جاتا ہے۔ یعنی، یہ سمجھا جاتا ہے کہ اس معاملے میں آپ کی درخواست ایک غلطی کے ساتھ ختم ہوئی ہے۔ اس کے مطابق، خوشگوار طریقے سے، اگر آپ کی درخواست بغیر کسی غلطی کے مکمل ہو جاتی ہے، تو آپ آؤٹ پٹ پر 0 کہتے ہیں۔ اگر آپ کی درخواست کسی وجہ سے ناکام ہوجاتی ہے، تو آپ آؤٹ پٹ میں غیر 0 کہتے ہیں۔ اور آپ اس معلومات کے ساتھ کام کر سکتے ہیں۔
اور آخری آپشن۔ یہ برا ہوتا ہے جب آپ کا صارف درخواست بھیجتا ہے اور آپ اس پر کارروائی کرتے وقت آدھے گھنٹے تک لٹکا رہتا ہے۔ لیکن عام طور پر، میں اس کے بارے میں بھی کہنا چاہوں گا جو عام طور پر کلائنٹ کی طرف سے اس کے قابل ہے۔ اس سے کوئی فرق نہیں پڑتا کہ آپ کے پاس موبائل ایپلیکیشن، فرنٹ اینڈ وغیرہ ہے۔ یہ ذہن میں رکھنا ضروری ہے کہ عام طور پر صارف کا سیشن ختم کیا جاسکتا ہے، کچھ بھی ہوسکتا ہے۔ ایک درخواست بھیجی جا سکتی ہے، مثال کے طور پر، کم کارروائی ہوئی اور کوئی جواب واپس نہیں آیا۔ آپ کا فرنٹ اینڈ یا آپ کی موبائل ایپلیکیشن - عام طور پر کوئی بھی فرنٹ اینڈ، آئیے اسے اس طرح رکھیں - اسے دھیان میں رکھنا چاہیے۔ اگر آپ ویب ساکٹس کے ساتھ کام کرتے ہیں، تو یہ عام طور پر سب سے زیادہ تکلیف ہے جو مجھے کبھی ہوئی ہے۔
جب کچھ باقاعدہ چیٹس کے ڈویلپرز کو یہ معلوم نہیں ہوتا ہے، تو پتہ چلتا ہے کہ ویب ساکٹ ٹوٹ سکتا ہے۔ ان کے لیے، جب پراکسی میں کچھ ہوتا ہے، ہم صرف کنفیگریشن کو تبدیل کرتے ہیں، اور یہ دوبارہ لوڈ ہوتا ہے۔ قدرتی طور پر، تمام طویل مدتی سیشن اس معاملے میں پھٹے ہوئے ہیں۔ ڈویلپرز ہمارے پاس دوڑتے ہوئے آتے ہیں اور کہتے ہیں: "دوست، آپ کیا کر رہے ہیں، ہمارے تمام کلائنٹس کے لیے چیٹ ٹوٹ گئی ہے!" ہم ان سے کہتے ہیں: "تم کیا کر رہے ہو؟ کیا آپ کے کلائنٹ دوبارہ رابطہ قائم کرنے سے قاصر ہیں؟ وہ کہتے ہیں: "نہیں، ہمیں سیشنوں کی ضرورت ہے کہ وہ پھٹے نہ جائیں۔" مختصر میں، یہ اصل میں بکواس ہے. کلائنٹ کی طرف کو اکاؤنٹ میں لینے کی ضرورت ہے. خاص طور پر، جیسا کہ میں کہتا ہوں، ویب ساکٹس جیسے طویل المدت سیشنز کے ساتھ، یہ ٹوٹ سکتا ہے اور، صارف کی طرف سے کسی کا دھیان نہیں، آپ کو ایسے سیشنز کو دوبارہ انسٹال کرنے کے قابل ہونے کی ضرورت ہے۔ اور پھر سب کچھ کامل ہے۔
وسائل
دراصل، یہاں میں آپ کو ایک سیدھی کہانی سناؤں گا۔ ایک بار پھر حقیقی زندگی سے۔ سب سے بیمار چیز جو میں نے وسائل کے بارے میں کبھی سنی ہے۔
اس معاملے میں وسائل، میرا مطلب ہے، کچھ قسم کی درخواستیں، حدود جو آپ اپنے Kubernetes کلسٹرز میں pods پر رکھ سکتے ہیں۔ سب سے مزے کی بات جو میں نے ایک ڈویلپر سے سنی... میرے ساتھی ڈویلپرز میں سے ایک سابقہ کام کی جگہ پر ایک بار کہا: "میری درخواست کلسٹر میں شروع نہیں ہوگی۔" میں نے دیکھا کہ یہ شروع نہیں ہو رہا ہے، لیکن یا تو یہ وسائل میں فٹ نہیں ہے، یا انہوں نے بہت چھوٹی حدود طے کر رکھی ہیں۔ مختصر یہ کہ وسائل کی وجہ سے درخواست شروع نہیں ہو سکتی۔ میں کہتا ہوں: "یہ وسائل کی وجہ سے شروع نہیں ہوگا، آپ فیصلہ کرتے ہیں کہ آپ کو کتنی ضرورت ہے اور مناسب قیمت مقرر کریں۔" وہ کہتا ہے: "کس قسم کے وسائل؟" میں نے اسے سمجھانا شروع کیا کہ کبرنیٹس، درخواستوں کی حدیں اور بلہ، بلہ، بلاہ مقرر کرنے کی ضرورت ہے۔ آدمی نے پانچ منٹ تک سنا، سر ہلایا اور کہا: "میں یہاں ایک ڈویلپر کے طور پر کام کرنے آیا ہوں، میں کسی وسائل کے بارے میں کچھ نہیں جاننا چاہتا۔ میں یہاں کوڈ لکھنے آیا ہوں اور بس۔ یہ دکھ کی بات ہے. یہ ایک ڈویلپر کے نقطہ نظر سے ایک بہت افسوسناک تصور ہے۔ خاص طور پر جدید دنیا میں، ترقی پسند ڈیوپس کے بارے میں۔
وسائل کی ضرورت کیوں ہے؟ Kubernetes میں وسائل کی 2 اقسام ہیں۔ کچھ کو درخواستیں کہتے ہیں، دوسروں کو حد کہتے ہیں۔ وسائل سے ہم سمجھیں گے کہ بنیادی طور پر ہمیشہ صرف دو بنیادی پابندیاں ہوتی ہیں۔ یعنی، Kubernetes میں چلنے والے کنٹینر کے لیے CPU وقت کی حد اور RAM کی حد۔
ایک حد اس بات پر ایک بالائی حد رکھتی ہے کہ آپ کی درخواست میں وسائل کو کس طرح استعمال کیا جا سکتا ہے۔ یعنی، اس کے مطابق، اگر آپ حدود میں 1 جی بی ریم کہتے ہیں، تو آپ کی ایپلی کیشن 1 جی بی سے زیادہ ریم استعمال نہیں کر سکے گی۔ اور اگر وہ اچانک یہ چاہتا ہے اور ایسا کرنے کی کوشش کرتا ہے، تو اوم قاتل نامی ایک عمل، میموری سے باہر، یعنی آکر آپ کی درخواست کو ختم کردے گا - یعنی یہ آسانی سے دوبارہ شروع ہوجائے گا۔ درخواستیں CPU کی بنیاد پر دوبارہ شروع نہیں ہوں گی۔ سی پی یو کے لحاظ سے، اگر کوئی ایپلی کیشن حد سے زیادہ استعمال کرنے کی کوشش کرتی ہے، تو سی پی یو کو سختی سے منتخب کیا جائے گا۔ اس سے دوبارہ شروع نہیں ہوتا ہے۔ یہ حد ہے - یہ اوپری حد ہے۔
اور ایک درخواست ہے۔ ایک درخواست یہ ہے کہ Kubernetes کیسے سمجھتا ہے کہ کس طرح آپ کے Kubernetes کلسٹر میں نوڈس ایپلی کیشنز کے ساتھ آباد ہوتے ہیں۔ یعنی درخواست آپ کی درخواست کی ایک قسم ہے۔ اس میں کہا گیا ہے کہ میں کیا استعمال کرنا چاہتا ہوں: "میں چاہوں گا کہ آپ اتنا سی پی یو اور اتنی میموری میرے لیے محفوظ رکھیں۔" اتنی سادہ سی تشبیہ۔ کیا ہوگا اگر ہمارے پاس کوئی نوڈ ہے جس میں، مجھے نہیں معلوم، کل 8 سی پی یو۔ اور وہاں ایک پوڈ آتا ہے، جس کی درخواستیں 1 CPU کہتے ہیں، جس کا مطلب ہے کہ نوڈ میں 7 CPU باقی ہیں۔ یعنی، اس کے مطابق، جیسے ہی 8 پوڈز اس نوڈ پر پہنچیں، جن میں سے ہر ایک کی درخواستوں میں 1 سی پی یو ہے، نوڈ، گویا کبرنیٹس کے نقطہ نظر سے، سی پی یو سے باہر ہو چکا ہے اور درخواستوں کے ساتھ مزید پوڈز نہیں ہو سکتے۔ اس نوڈ پر شروع کیا. اگر تمام نوڈس CPU سے باہر ہو جاتے ہیں، تو Kubernetes یہ کہنا شروع کر دے گا کہ آپ کے پوڈز کو چلانے کے لیے کلسٹر میں کوئی مناسب نوڈس نہیں ہیں کیونکہ CPU ختم ہو چکا ہے۔
درخواستوں کی ضرورت کیوں ہے اور درخواستوں کے بغیر کیوں، میرے خیال میں کبرنیٹس میں کچھ بھی لانچ کرنے کی ضرورت نہیں ہے؟ آئیے ایک فرضی صورت حال کا تصور کریں۔ آپ درخواستوں کے بغیر اپنی ایپلیکیشن لانچ کرتے ہیں، Kubernetes نہیں جانتا کہ آپ کے پاس کتنا ہے، آپ اسے کن نوڈس پر دھکیل سکتے ہیں۔ ٹھیک ہے، وہ نوڈس پر دھکیلتا ہے، دھکا دیتا ہے، ہلاتا ہے۔ کسی وقت، آپ کو اپنی درخواست پر ٹریفک ملنا شروع ہو جائے گا۔ اور ایک ایپلی کیشن اچانک اس حد تک وسائل استعمال کرنا شروع کر دیتی ہے جو اس کے پاس حدود کے مطابق ہے۔ پتہ چلا کہ قریب ہی ایک اور ایپلیکیشن ہے اور اسے بھی وسائل کی ضرورت ہے۔ نوڈ اصل میں جسمانی طور پر وسائل ختم ہونے لگتا ہے، مثال کے طور پر، او پی۔ نوڈ اصل میں جسمانی طور پر وسائل ختم ہونے لگتا ہے، مثال کے طور پر، بے ترتیب رسائی میموری (RAM)۔ جب کسی نوڈ کی طاقت ختم ہوجاتی ہے، تو سب سے پہلے ڈاکر جواب دینا بند کردے گا، پھر کیوبلیٹ، پھر OS۔ وہ صرف بے ہوش ہو جائیں گے اور ہر چیز یقینی طور پر آپ کے لیے کام کرنا بند کر دے گی۔ یعنی، اس سے آپ کا نوڈ پھنس جائے گا اور آپ کو اسے دوبارہ شروع کرنے کی ضرورت ہوگی۔ مختصر یہ کہ حالات بہت اچھے نہیں ہیں۔
اور جب آپ کے پاس درخواستیں ہوتی ہیں، حدود بہت مختلف نہیں ہوتیں، کم از کم حدوں یا درخواستوں سے کئی گنا زیادہ نہیں ہوتیں، تب آپ کوبرنیٹس کلسٹرز کے نوڈس میں درخواستوں کی اتنی عام، عقلی بھرائی ہو سکتی ہے۔ ایک ہی وقت میں، Kubernetes تقریبا اس بات سے واقف ہے کہ یہ کہاں رکھتا ہے، کتنا کہاں استعمال کیا جاتا ہے. یعنی یہ صرف ایک لمحہ ہے۔ اسے سمجھنا ضروری ہے۔ اور یہ کنٹرول کرنا ضروری ہے کہ یہ اشارہ کیا گیا ہے۔
ڈیٹا اسٹوریج
ہمارا اگلا نکتہ ڈیٹا اسٹوریج کے بارے میں ہے۔ ان کے ساتھ کیا کرنا ہے اور عام طور پر، Kubernetes میں استقامت کے ساتھ کیا کرنا ہے؟
مجھے لگتا ہے، ایک بار پھر، ہمارے اندر , Kubernetes میں ڈیٹا بیس کے بارے میں ایک موضوع تھا۔ اور مجھے ایسا لگتا ہے کہ میں تقریباً جانتا ہوں کہ جب آپ کے ساتھیوں نے آپ سے پوچھا: "کیا Kubernetes میں ڈیٹا بیس چلانا ممکن ہے؟" کسی وجہ سے، مجھے لگتا ہے کہ آپ کے ساتھیوں کو آپ کو بتانا چاہیے تھا کہ اگر آپ یہ سوال پوچھ رہے ہیں کہ کیا Kubernetes میں ڈیٹا بیس چلانا ممکن ہے، تو یہ ناممکن ہے۔
یہاں منطق سادہ ہے۔ صرف اس صورت میں، میں ایک بار پھر وضاحت کروں گا، اگر آپ واقعی ایک اچھے آدمی ہیں جو تقسیم شدہ نیٹ ورک سٹوریج کا کافی حد تک خرابی برداشت کرنے والا نظام بنا سکتا ہے، تو سمجھیں کہ اس معاملے میں ڈیٹا بیس کو کیسے فٹ کیا جائے، کنٹینرز میں کلاؤڈ کو کیسے کام کرنا چاہیے۔ عام طور پر ڈیٹا بیس میں۔ زیادہ تر امکان ہے، آپ کو اس کے چلانے کے بارے میں کوئی سوال نہیں ہے۔ اگر آپ کے پاس ایسا سوال ہے، اور آپ اس بات کو یقینی بنانا چاہتے ہیں کہ یہ سب کچھ ظاہر ہو جائے اور پیداوار میں موت کے عین مطابق کھڑا ہو اور کبھی گر نہ جائے، تو ایسا نہیں ہوتا۔ آپ کو اس نقطہ نظر کے ساتھ اپنے پاؤں میں گولی مارنے کی ضمانت ہے۔ اس لیے نہ ہی بہتر ہے۔
ہمیں اس ڈیٹا کے ساتھ کیا کرنا چاہیے جسے ہماری ایپلیکیشن اسٹور کرنا چاہتی ہے، کچھ تصویریں جو صارفین اپ لوڈ کرتے ہیں، کچھ چیزیں جو ہماری ایپلی کیشن اپنے آپریشن کے دوران، مثال کے طور پر تیار کرتی ہے، شروع کے وقت؟ Kubernetes میں ان کے ساتھ کیا کرنا ہے؟
عام طور پر، مثالی طور پر، ہاں، بلاشبہ، Kubernetes بہت اچھی طرح سے ڈیزائن کیا گیا ہے اور عام طور پر ابتدائی طور پر بے وطن ایپلی کیشنز کے لیے تصور کیا گیا تھا۔ یعنی ان ایپلی کیشنز کے لیے جو معلومات کو بالکل بھی ذخیرہ نہیں کرتی ہیں۔ یہ مثالی ہے۔
لیکن، یقینا، مثالی اختیار ہمیشہ موجود نہیں ہے. تو کیا؟ پہلا اور آسان ترین نکتہ یہ ہے کہ کسی قسم کا S3 لینا ہے، نہ کہ گھریلو ساختہ، جو یہ بھی واضح نہیں ہے کہ یہ کیسے کام کرتا ہے، لیکن کسی فراہم کنندہ سے۔ ایک اچھا، عام فراہم کنندہ - اور اپنی درخواست کو S3 استعمال کرنا سکھائیں۔ یعنی، جب آپ کا صارف کوئی فائل اپ لوڈ کرنا چاہتا ہے، تو کہے "یہاں، براہ کرم، اسے S3 پر اپ لوڈ کریں۔" جب وہ اسے وصول کرنا چاہے تو کہے: "یہ ہے S3 کا لنک واپس اور اسے یہاں سے لے لو۔" یہ مثالی ہے۔
اگر اچانک کسی وجہ سے یہ مثالی آپشن مناسب نہیں ہے، تو آپ کے پاس ایک ایسی ایپلی کیشن ہے جسے آپ نے نہیں لکھا، آپ تیار نہیں کرتے، یا یہ کسی قسم کی خوفناک میراث ہے، یہ S3 پروٹوکول استعمال نہیں کر سکتا، لیکن اسے مقامی ڈائریکٹریز کے ساتھ کام کرنا چاہیے۔ مقامی فولڈرز کم و بیش کچھ آسان لیں، Kubernetes تعینات کریں۔ یعنی، فوری طور پر کچھ کم سے کم کاموں کے لیے Ceph کو باڑ لگانا، یہ مجھے لگتا ہے، ایک برا خیال ہے۔ کیونکہ Ceph، یقیناً اچھا اور فیشن ایبل ہے۔ لیکن اگر آپ واقعی یہ نہیں سمجھتے ہیں کہ آپ کیا کر رہے ہیں، تو ایک بار جب آپ سیف پر کچھ ڈال دیتے ہیں، تو آپ بہت آسانی سے اور آسانی سے اسے دوبارہ وہاں سے کبھی نہیں نکال سکتے۔ کیونکہ، جیسا کہ آپ جانتے ہیں، Ceph ڈیٹا کو اپنے کلسٹر میں بائنری شکل میں اسٹور کرتا ہے، نہ کہ سادہ فائلوں کی شکل میں۔ لہذا، اگر اچانک سیف کلسٹر ٹوٹ جاتا ہے، تو اس بات کا مکمل اور زیادہ امکان ہے کہ آپ کو وہاں سے اپنا ڈیٹا دوبارہ کبھی نہیں ملے گا۔
ہمارے پاس سیف پر ایک کورس ہوگا، آپ کر سکتے ہیں۔ .
لہذا، NFS سرور کی طرح کچھ آسان کرنا بہتر ہے۔ Kubernetes ان کے ساتھ کام کر سکتے ہیں، آپ NFS سرور کے تحت ایک ڈائریکٹری کو ماؤنٹ کر سکتے ہیں - آپ کی ایپلیکیشن بالکل مقامی ڈائریکٹری کی طرح ہے۔ اسی وقت، قدرتی طور پر، آپ کو یہ سمجھنے کی ضرورت ہے کہ، دوبارہ، آپ کو اپنے NFS کے ساتھ کچھ کرنے کی ضرورت ہے، آپ کو یہ سمجھنے کی ضرورت ہے کہ بعض اوقات یہ ناقابل رسائی ہو سکتا ہے اور اس سوال پر غور کریں کہ آپ اس معاملے میں کیا کریں گے۔ شاید اس کا بیک اپ کسی الگ مشین پر ہونا چاہیے۔
اگلا نکتہ جس کے بارے میں میں نے بات کی ہے وہ یہ ہے کہ اگر آپ کی ایپلی کیشن آپریشن کے دوران کچھ فائلیں تیار کرتی ہے۔ مثال کے طور پر، جب یہ شروع ہوتا ہے، تو یہ کچھ جامد فائل تیار کرتا ہے، جو کچھ معلومات پر مبنی ہوتی ہے جو ایپلیکیشن کو صرف لانچ کے وقت موصول ہوتی ہے۔ کیا ایک لمحہ ہے. اگر اتنا زیادہ ڈیٹا نہیں ہے تو آپ کو بالکل بھی پریشان ہونے کی ضرورت نہیں ہے، بس اپنے لیے یہ ایپلی کیشن انسٹال کریں اور کام کریں۔ یہاں صرف سوال یہ ہے کہ کیا دیکھو۔ اکثر، تمام قسم کے میراثی نظام، جیسے کہ ورڈپریس وغیرہ، خاص طور پر ترمیم شدہ کسی قسم کے ہوشیار پلگ انز، ہوشیار پی ایچ پی ڈویلپرز کے ساتھ، وہ اکثر جانتے ہیں کہ اسے کیسے بنانا ہے تاکہ وہ اپنے لیے کسی قسم کی فائل تیار کریں۔ اس کے مطابق، ایک ایک فائل بناتا ہے، دوسرا دوسری فائل بناتا ہے۔ وہ مختلف ہیں۔ کلائنٹس کے Kubernetes کلسٹر میں توازن محض اتفاق سے ہوتا ہے۔ اس کے مطابق، یہ پتہ چلتا ہے کہ وہ نہیں جانتے کہ مثال کے طور پر کیسے مل کر کام کرنا ہے. ایک ایک معلومات دیتا ہے، دوسرا صارف کو دوسری معلومات دیتا ہے۔ یہ وہی ہے جس سے آپ کو بچنا چاہئے۔ یعنی، Kubernetes میں، آپ جو کچھ بھی لانچ کرتے ہیں اس کی ضمانت دی جاتی ہے کہ وہ متعدد مثالوں میں کام کر سکے گا۔ کیونکہ Kubernetes ایک متحرک چیز ہے۔ اس کے مطابق، وہ کسی سے پوچھے بغیر، جب چاہے، کچھ بھی منتقل کر سکتا ہے۔ لہذا، آپ کو اس پر اعتماد کرنے کی ضرورت ہے. ایک مثال میں شروع کی گئی ہر چیز جلد یا بدیر ناکام ہو جائے گی۔ آپ کے پاس جتنے زیادہ تحفظات ہوں گے، اتنا ہی بہتر ہے۔ لیکن پھر، میں کہتا ہوں، اگر آپ کے پاس ایسی چند فائلیں ہیں، تو آپ انہیں اپنے نیچے رکھ سکتے ہیں، ان کا وزن بہت کم ہے۔ اگر ان میں سے کچھ اور بھی ہیں، تو شاید آپ کو انہیں کنٹینر کے اندر نہیں دھکیلنا چاہیے۔
میں مشورہ دوں گا کہ کبرنیٹس میں ایسی شاندار چیز ہے، آپ حجم استعمال کر سکتے ہیں۔ خاص طور پر خالی دیر کی قسم کا حجم ہے۔ یعنی، یہ صرف اتنا ہے کہ Kubernetes خود بخود اس سرور پر اپنی سروس ڈائریکٹریز میں ایک ڈائرکٹری بنائے گا جہاں آپ نے شروعات کی تھی۔ اور وہ تمہیں دے گا تاکہ تم اسے استعمال کر سکو۔ صرف ایک اہم نکتہ ہے۔ یعنی، آپ کا ڈیٹا کنٹینر کے اندر ذخیرہ نہیں کیا جائے گا، بلکہ اس میزبان پر رکھا جائے گا جس پر آپ چل رہے ہیں۔ مزید برآں، Kubernetes اس طرح کے خالی ڈائر کو عام کنفیگریشن کے تحت کنٹرول کر سکتا ہے اور ان کے زیادہ سے زیادہ سائز کو کنٹرول کرنے کے قابل ہے اور اس سے تجاوز کرنے کی اجازت نہیں دیتا ہے۔ صرف ایک نکتہ یہ ہے کہ جو کچھ آپ نے خالی دیر میں لکھا ہے وہ پوڈ کے دوبارہ شروع ہونے کے دوران ضائع نہیں ہوتا ہے۔ یعنی اگر آپ کی پھلی غلطی سے گر جائے اور دوبارہ اٹھ جائے تو خالی دیر میں موجود معلومات کہیں نہیں جائیں گی۔ وہ اسے ایک نئے آغاز پر دوبارہ استعمال کر سکتا ہے - اور یہ اچھا ہے۔ اگر آپ کی پھلی کہیں سے نکل جاتی ہے، تو قدرتی طور پر وہ بغیر ڈیٹا کے چلے جائیں گے۔ یعنی جیسے ہی نوڈ سے پوڈ جہاں اسے خالی دیر کے ساتھ لانچ کیا گیا تھا غائب ہو جاتا ہے، خالی دیر حذف ہو جاتی ہے۔
خالی دیر کے بارے میں اور کیا اچھا ہے؟ مثال کے طور پر، اسے کیشے کے طور پر استعمال کیا جا سکتا ہے۔ آئیے تصور کریں کہ ہماری ایپلیکیشن پرواز پر کچھ پیدا کرتی ہے، اسے صارفین کو دیتی ہے، اور طویل عرصے تک کرتی ہے۔ لہذا، ایپلی کیشن، مثال کے طور پر، پیدا کرتی ہے اور اسے صارفین کو دیتی ہے، اور ساتھ ہی اسے کہیں ذخیرہ کرتی ہے، تاکہ اگلی بار جب صارف ایک ہی چیز کے لیے آئے، تو اسے فوری طور پر پیدا کردہ دینے میں تیزی آئے گی۔ کوبرنیٹس سے خالی ڈائر میموری میں بنانے کے لیے کہا جا سکتا ہے۔ اور اس طرح، آپ کے کیچز عام طور پر بجلی کی رفتار سے کام کر سکتے ہیں - ڈسک تک رسائی کی رفتار کے لحاظ سے۔ یعنی، آپ کے پاس میموری میں ایک خالی ڈائرکٹری ہے، OS میں یہ میموری میں محفوظ ہے، لیکن آپ کے لیے، پوڈ کے اندر موجود صارف کے لیے، یہ صرف ایک مقامی ڈائریکٹری کی طرح لگتا ہے۔ آپ کو خاص طور پر کوئی جادو سکھانے کے لیے ایپ کی ضرورت نہیں ہے۔ آپ اپنی فائل کو براہ راست لے کر ڈائرکٹری میں ڈالتے ہیں، لیکن حقیقت میں، OS پر میموری میں۔ یہ بھی Kubernetes کے لحاظ سے ایک بہت آسان خصوصیت ہے۔
Minio کو کیا مسائل ہیں؟ Minio کے ساتھ بنیادی مسئلہ یہ ہے کہ اس چیز کے کام کرنے کے لیے اسے کہیں نہ کہیں چلانے کی ضرورت ہے، اور وہاں کسی قسم کا فائل سسٹم ہونا چاہیے، یعنی اسٹوریج۔ اور یہاں ہمیں وہی مسائل درپیش ہیں جو سیف کو ہیں۔ یعنی، Minio کو اپنی فائلوں کو کہیں اسٹور کرنا چاہیے۔ یہ آپ کی فائلوں کا صرف ایک HTTP انٹرفیس ہے۔ مزید یہ کہ، فعالیت ایمیزون کے S3 کے مقابلے میں واضح طور پر غریب ہے۔ پہلے، یہ صارف کو مناسب طریقے سے اجازت دینے کے قابل نہیں تھا۔ اب، جہاں تک میں جانتا ہوں، یہ پہلے سے ہی مختلف اجازتوں کے ساتھ بالٹیاں بنا سکتا ہے، لیکن ایک بار پھر، مجھے لگتا ہے کہ اصل مسئلہ ہے، تو بات کرنے کے لیے، کم از کم اسٹوریج سسٹم کا۔
میموری میں خالی دیر حدود کو کیسے متاثر کرتی ہے؟ کسی بھی طرح سے حدود کو متاثر نہیں کرتا ہے۔ یہ میزبان کی یاد میں ہے، نہ کہ آپ کے کنٹینر کی یاد میں۔ یعنی، آپ کا کنٹینر میموری میں موجود خالی دیر کو اپنی زیر قبضہ میموری کے حصے کے طور پر نہیں دیکھتا ہے۔ میزبان یہ دیکھتا ہے۔ اس کے مطابق، ہاں، کبرنیٹس کے نقطہ نظر سے، جب آپ اسے استعمال کرنا شروع کرتے ہیں، تو یہ سمجھنا اچھا ہو گا کہ آپ اپنی یادداشت کا کچھ حصہ خالی دیر کے لیے وقف کر رہے ہیں۔ اور اس کے مطابق، یہ سمجھیں کہ میموری صرف ایپلی کیشنز کی وجہ سے نہیں بلکہ اس وجہ سے بھی ختم ہو سکتی ہے کہ کوئی ان خالی ڈائر کو لکھتا ہے۔
کلاؤڈنیٹیشن
اور حتمی ذیلی عنوان وہی ہے جو Cloudnative ہے۔ اس کی ضرورت کیوں ہے؟ Cloudnativeness اور اسی طرح.
یعنی وہ ایپلی کیشنز جو جدید کلاؤڈ انفراسٹرکچر میں کام کرنے کے قابل اور تحریری ہیں۔ لیکن، حقیقت میں، Cloudnative کا ایک اور پہلو ہے۔ کہ یہ نہ صرف ایک ایسی ایپلی کیشن ہے جو جدید کلاؤڈ انفراسٹرکچر کی تمام ضروریات کو مدنظر رکھتی ہے، بلکہ یہ بھی جانتا ہے کہ اس جدید کلاؤڈ انفراسٹرکچر کے ساتھ کیسے کام کرنا ہے، اس کے فوائد اور نقصانات سے فائدہ اٹھانا ہے کہ یہ ان بادلوں میں کام کرتا ہے۔ صرف اوور بورڈ نہ جائیں اور بادلوں میں کام کریں، بلکہ بادل میں کام کرنے کے فوائد سے فائدہ اٹھائیں۔
آئیے صرف Kubernetes کو ایک مثال کے طور پر لیتے ہیں۔ آپ کی درخواست Kubernetes میں چل رہی ہے۔ آپ کی درخواست ہمیشہ، یا آپ کی درخواست کے منتظمین، ہمیشہ ایک سروس اکاؤنٹ بنا سکتے ہیں۔ یعنی، اس کے سرور میں خود Kubernetes میں اجازت کے لیے ایک اکاؤنٹ۔ کچھ حقوق شامل کریں جن کی ہمیں وہاں ضرورت ہے۔ اور آپ اپنی درخواست کے اندر سے Kubernetes تک رسائی حاصل کر سکتے ہیں۔ آپ اس طرح کیا کر سکتے ہیں؟ مثال کے طور پر، ایپلی کیشن سے، اس بارے میں ڈیٹا حاصل کریں کہ آپ کی دوسری ایپلیکیشنز، اسی طرح کی دوسری مثالیں کہاں واقع ہیں، اور اگر ایسی ضرورت ہو تو ایک ساتھ کسی نہ کسی طرح Kubernetes کے اوپر کلسٹر کریں۔
ایک بار پھر، ہمارے پاس لفظی طور پر حال ہی میں ایک کیس تھا۔ ہمارے پاس ایک کنٹرولر ہے جو قطار کی نگرانی کرتا ہے۔ اور جب کچھ نئے کام اس قطار میں ظاہر ہوتے ہیں، تو یہ Kubernetes کو جاتا ہے - اور Kubernetes کے اندر یہ ایک نیا پوڈ بناتا ہے۔ اس پوڈ کو کچھ نیا کام دیتا ہے اور اس پوڈ کے فریم ورک کے اندر، پوڈ اس کام کو انجام دیتا ہے، خود کنٹرولر کو جواب بھیجتا ہے، اور کنٹرولر پھر اس معلومات کے ساتھ کچھ کرتا ہے۔ مثال کے طور پر، یہ ایک ڈیٹا بیس کا اضافہ کرتا ہے۔ یعنی ایک بار پھر، یہ اس حقیقت کا ایک پلس ہے کہ ہماری ایپلیکیشن Kubernetes میں چلتی ہے۔ ہم بلٹ ان Kubernetes فعالیت کو استعمال کر سکتے ہیں تاکہ کسی نہ کسی طرح اپنی ایپلیکیشن کی فعالیت کو مزید آسان بنا سکیں۔ یعنی کسی ایپلیکیشن کو کیسے لانچ کیا جائے، ورکر کو کیسے لانچ کیا جائے، اس بارے میں کسی قسم کا جادو نہ چھپائیں۔ Kubernetes میں، اگر ایپلی کیشن Python میں لکھی گئی ہے تو آپ صرف ایپ میں درخواست بھیجتے ہیں۔
یہی بات لاگو ہوتی ہے اگر ہم Kubernetes سے آگے بڑھیں۔ ہمارے پاس ہمارے Kubernetes کہیں چل رہے ہیں - یہ اچھا ہے اگر یہ کسی قسم کے بادل میں ہو۔ ایک بار پھر، ہم استعمال کر سکتے ہیں، اور یہاں تک کہ، مجھے یقین ہے، بادل کی صلاحیتوں کو خود استعمال کرنا چاہیے جہاں ہم چل رہے ہیں۔ ان ابتدائی چیزوں سے جو بادل ہمیں فراہم کرتا ہے۔ بیلنسنگ، یعنی ہم کلاؤڈ بیلنسرز بنا سکتے ہیں اور انہیں استعمال کر سکتے ہیں۔ یہ اس کا براہ راست فائدہ ہے جو ہم استعمال کر سکتے ہیں۔ کیونکہ کلاؤڈ بیلنسنگ، سب سے پہلے، محض احمقانہ طور پر ہم سے ذمہ داری ہٹاتا ہے کہ یہ کیسے کام کرتا ہے، اسے کس طرح ترتیب دیا جاتا ہے۔ اس کے علاوہ یہ بہت آسان ہے، کیونکہ باقاعدہ کبرنیٹس بادلوں کے ساتھ مل سکتے ہیں۔
اسی طرح پیمانہ کے لئے جاتا ہے. باقاعدہ Kubernetes کلاؤڈ فراہم کرنے والوں کے ساتھ ضم کر سکتے ہیں۔ جانتا ہے کہ کس طرح سمجھنا ہے کہ اگر کلسٹر نوڈس سے باہر ہو گیا ہے، یعنی نوڈ کی جگہ ختم ہو گئی ہے، تو آپ کو شامل کرنے کی ضرورت ہے - Kubernetes خود آپ کے کلسٹر میں نئے نوڈس شامل کر دے گا اور ان پر پوڈز لانچ کرنا شروع کر دے گا۔ یعنی جب آپ کا بوجھ آتا ہے تو چولہوں کی تعداد بڑھنے لگتی ہے۔ جب ان پوڈز کے لیے کلسٹر میں نوڈس ختم ہو جاتے ہیں، تو Kubernetes نئے نوڈس لانچ کرتا ہے اور اس کے مطابق، pods کی تعداد اب بھی بڑھ سکتی ہے۔ اور یہ بہت آسان ہے۔ یہ مکھی پر کلسٹر پیمانہ کرنے کا براہ راست موقع ہے۔ بہت تیز نہیں، اس لحاظ سے کہ یہ ایک سیکنڈ نہیں ہے، نئے نوڈس کو شامل کرنے کے لیے یہ ایک منٹ کی طرح ہے۔
لیکن میرے تجربے سے، ایک بار پھر، یہ سب سے اچھی چیز ہے جو میں نے کبھی دیکھی ہے۔ جب Cloudnative کلسٹر دن کے وقت کی بنیاد پر اسکیل کیا جاتا ہے۔ یہ ایک بیک اینڈ سروس تھی جسے لوگ بیک آفس میں استعمال کرتے تھے۔ یعنی، وہ صبح 9 بجے کام پر آتے ہیں، سسٹم میں لاگ ان کرنا شروع کر دیتے ہیں، اور اس کے مطابق، کلاؤڈ نیٹیو کلسٹر، جہاں یہ سب چل رہا ہے، پھولنا شروع ہو جاتا ہے، نئے پوڈز لانچ کیے جاتے ہیں تاکہ جو بھی کام پر آتا ہے وہ ایپلیکیشن کے ساتھ کام کر سکے۔ جب وہ رات 8 یا 6 بجے کام سے نکلتے ہیں، تو Kubernetes کلسٹرز نے نوٹس لیا کہ اب کوئی بھی ایپلیکیشن استعمال نہیں کر رہا ہے اور سکڑنا شروع کر دیتے ہیں۔ 30 فیصد تک کی بچت کی ضمانت ہے۔ یہ اس وقت ایمیزون میں کام کرتا تھا؛ اس وقت روس میں کوئی نہیں تھا جو اسے اتنی اچھی طرح سے کر سکتا تھا۔
میں آپ کو سیدھا بتاؤں گا، بچت صرف 30 فیصد ہے کیونکہ ہم Kubernetes استعمال کرتے ہیں اور کلاؤڈ کی صلاحیتوں سے فائدہ اٹھاتے ہیں۔ اب یہ روس میں کیا جا سکتا ہے۔ یقیناً میں کسی کو اشتہار نہیں دوں گا، لیکن ہم صرف اتنا کہہ دیتے ہیں کہ ایسے فراہم کنندگان ہیں جو یہ کر سکتے ہیں، اسے بٹن کے ساتھ باکس کے باہر فراہم کریں۔
ایک آخری نکتہ ہے جس کی طرف میں بھی آپ کی توجہ مبذول کرانا چاہتا ہوں۔ آپ کی درخواست کے لیے، آپ کا بنیادی ڈھانچہ کلاؤڈنیٹیو ہونے کے لیے، آخر کار بنیادی ڈھانچے کو بطور ضابطہ اپنانا شروع کرنا سمجھ میں آتا ہے۔ یعنی، اس کا مطلب یہ ہے کہ آپ کی درخواست، یا آپ کے بنیادی ڈھانچے کی بالکل اسی طرح ضرورت ہے۔ کوڈ اپنی درخواست، اپنی کاروباری منطق کو کوڈ کی شکل میں بیان کریں۔ اور اس کے ساتھ بطور کوڈ کام کریں، یعنی اسے ٹیسٹ کریں، اسے رول آؤٹ کریں، اسے گٹ میں اسٹور کریں، اس پر CICD لگائیں۔
اور یہ بالکل وہی ہے جو آپ کو، سب سے پہلے، اپنے بنیادی ڈھانچے پر ہمیشہ کنٹرول رکھنے، ہمیشہ یہ سمجھنے کی اجازت دیتا ہے کہ یہ کس حالت میں ہے۔ دوم، دستی کارروائیوں سے بچیں جو غلطیوں کا سبب بنتے ہیں۔ تیسرا، جب آپ کو مسلسل وہی دستی کام انجام دینے کی ضرورت ہوتی ہے تو اسے ٹرن اوور کہلانے سے بچیں۔ چوتھا، یہ آپ کو ناکامی کی صورت میں بہت تیزی سے صحت یاب ہونے کی اجازت دیتا ہے۔ روس میں، جب بھی میں اس کے بارے میں بات کرتا ہوں، وہاں ہمیشہ لوگوں کی ایک بڑی تعداد ہوتی ہے جو کہتے ہیں: "ہاں، یہ واضح ہے، لیکن آپ کے پاس نقطہ نظر ہے، مختصر یہ کہ، کچھ بھی ٹھیک کرنے کی ضرورت نہیں ہے۔" لیکن یہ سچ ہے. اگر آپ کے انفراسٹرکچر میں کوئی چیز ٹوٹ گئی ہے، تو Cloudnative اپروچ کے نقطہ نظر سے اور انفراسٹرکچر کو بطور ضابطہ کے نقطہ نظر سے، اسے ٹھیک کرنے کے بجائے، سرور پر جاکر یہ معلوم کرنا کہ کیا ٹوٹا ہے اور اسے ٹھیک کرنا آسان ہے۔ سرور کو حذف کرنے اور اسے دوبارہ بنانے کے لیے۔ اور میں یہ سب کچھ بحال کر دوں گا۔
ان تمام مسائل پر مزید تفصیل سے بحث کی گئی ہے۔ . لنک پر عمل کرکے آپ پروگرام اور شرائط سے خود کو واقف کر سکتے ہیں۔ آسان بات یہ ہے کہ آپ گھر سے پڑھ کر یا دن میں 1-2 گھنٹے کام کر کے Kubernetes میں مہارت حاصل کر سکتے ہیں۔
ماخذ: www.habr.com