اگر آپ زیادہ تر لوگوں کی طرح ہیں، تو آپ شاید وسائل استعمال کر رہے ہیں جو آپ کے کلسٹر سے باہر چل رہے ہیں۔ شاید آپ ٹیکسٹ پیغامات بھیجنے کے لیے Taleo API استعمال کرتے ہیں، یا Google Cloud Vision API کا استعمال کرتے ہوئے تصاویر کا تجزیہ کرتے ہیں۔
اگر آپ اپنے تمام ماحول میں ایک ہی سرور سائیڈ درخواست کا اختتامی نقطہ استعمال کرتے ہیں اور اپنے سرورز کو Kubernetes میں منتقل کرنے کا ارادہ نہیں رکھتے ہیں، تو یہ بالکل ٹھیک ہے کہ آپ کے کوڈ میں سروس کا اختتامی نقطہ ہو۔ تاہم، واقعات کی ترقی کے لیے بہت سے دوسرے منظرنامے ہیں۔ اس Kubernetes بہترین طرز عمل کی سیریز میں، آپ یہ سیکھیں گے کہ کلسٹر کے اندر اور باہر خدمات کو دریافت کرنے کے لیے Kubernetes کے بلٹ ان میکانزم کو کس طرح استعمال کرنا ہے۔
ایک عام بیرونی سروس کی ایک مثال Kubernetes کلسٹر کے باہر چلنے والا ڈیٹا بیس ہے۔ گوگل کلاؤڈ ڈیٹا اسٹور یا گوگل کلاؤڈ اسپینر جیسے کلاؤڈ ڈیٹا بیس کے برعکس، جو تمام رسائی کے لیے ایک ہی اختتامی نقطہ استعمال کرتے ہیں، زیادہ تر ڈیٹا بیسز کے مختلف حالات کے لیے الگ الگ اختتامی نقطہ ہوتے ہیں۔
روایتی ڈیٹا بیس جیسے MySQL اور MongoDB استعمال کرنے کے بہترین طریقوں کا عام طور پر مطلب یہ ہوتا ہے کہ آپ مختلف ماحول کے لیے مختلف اجزاء سے جڑ جاتے ہیں۔ آپ کے پاس پروڈکشن ڈیٹا کے لیے ایک بڑی مشین اور ٹیسٹ کے ماحول کے لیے ایک چھوٹی مشین ہو سکتی ہے۔ ان میں سے ہر ایک کا اپنا IP ایڈریس یا ڈومین نام ہوگا، لیکن آپ شاید ایک ماحول سے دوسرے ماحول میں جاتے وقت اپنا کوڈ تبدیل نہیں کرنا چاہیں گے۔ لہٰذا ان پتوں کو سخت کوڈ کرنے کے بجائے، آپ Kubernetes کی بلٹ ان DNS پر مبنی بیرونی سروس کی دریافت کو اسی طرح استعمال کر سکتے ہیں جس طرح مقامی Kubernetes سروسز۔
فرض کریں کہ آپ Google Compute Engine پر MongoDB ڈیٹا بیس چلا رہے ہیں۔ آپ اس ہائبرڈ دنیا میں اس وقت تک پھنس جائیں گے جب تک کہ آپ اسے کلسٹر میں منتقل کرنے کا انتظام نہیں کر لیتے۔
خوش قسمتی سے، آپ اپنی زندگی کو قدرے آسان بنانے کے لیے جامد Kubernetes سروسز استعمال کر سکتے ہیں۔ اس مثال میں، میں نے گوگل کلاؤڈ لانچر کا استعمال کرتے ہوئے ایک MongoDB سرور بنایا۔ چونکہ یہ ایک ہی نیٹ ورک (یا Kubernetes کلسٹر VPC) پر بنایا گیا ہے، اس لیے اعلی کارکردگی والے اندرونی IP ایڈریس کے ذریعے اس تک رسائی حاصل کی جاتی ہے۔
یہ گوگل کلاؤڈ پر پہلے سے طے شدہ ترتیب ہے، لہذا آپ کو کچھ بھی ترتیب دینے کی ضرورت نہیں ہے۔ اب جب کہ آپ کے پاس ایک IP ایڈریس ہے، پہلا قدم ایک سروس بنانا ہے۔ آپ محسوس کر سکتے ہیں کہ اس سروس کے لیے کوئی پوڈ سلیکٹر نہیں ہیں۔ یعنی ہم نے ایک ایسی سروس بنائی ہے جس سے معلوم نہیں ہو گا کہ ٹریفک کہاں بھیجنا ہے۔ یہ آپ کو دستی طور پر ایک اینڈ پوائنٹ آبجیکٹ بنانے کی اجازت دے گا جو اس سروس سے ٹریفک وصول کرے گا۔
مندرجہ ذیل کوڈ کی مثال سے پتہ چلتا ہے کہ اختتامی پوائنٹس اسی منگو نام کا استعمال کرتے ہوئے ڈیٹا بیس کے IP ایڈریس کا تعین کرتے ہیں جو سروس ہے۔
Kubernetes تمام IP ایڈریسز کو اینڈ پوائنٹس تلاش کرنے کے لیے استعمال کرے گا گویا وہ باقاعدہ Kubernetes Pods ہیں، لہذا اب آپ مندرجہ بالا نام mongodb://mongo سے ایک سادہ کنکشن سٹرنگ کے ساتھ ڈیٹا بیس تک رسائی حاصل کر سکتے ہیں۔ آپ کے کوڈ میں آئی پی ایڈریس استعمال کرنے کی بالکل ضرورت نہیں ہے۔
اگر مستقبل میں آئی پی ایڈریسز تبدیل ہوتے ہیں، تو آپ آسانی سے اپنے اینڈ پوائنٹس کو نئے آئی پی ایڈریس کے ساتھ اپ ڈیٹ کر سکتے ہیں اور آپ کی ایپلی کیشنز کو کسی اضافی طریقے سے تبدیل کرنے کی ضرورت نہیں ہوگی۔
اگر آپ فریق ثالث کے میزبان پر ہوسٹ کردہ ڈیٹا بیس کا استعمال کر رہے ہیں، تو امکان ہے کہ میزبان کے مالکان نے آپ کو مربوط ہونے کے لیے یکساں وسائل کی شناخت کرنے والا URI فراہم کیا ہے۔ لہذا اگر آپ کو آئی پی ایڈریس دیا گیا ہے، تو آپ آسانی سے پچھلا طریقہ استعمال کر سکتے ہیں۔ یہ مثال ظاہر کرتی ہے کہ میرے پاس دو MongoDB ڈیٹا بیس ہیں جو mLab ہوسٹ پر ہوسٹ کیے گئے ہیں۔
ایک ڈویلپر ڈیٹا بیس اور دوسرا پروڈکشن ڈیٹا بیس۔ ان ڈیٹا بیس کے لیے کنکشن کے تار اس طرح نظر آتے ہیں - mLab آپ کو ایک متحرک URI اور ایک متحرک پورٹ فراہم کرتا ہے۔ جیسا کہ آپ دیکھ سکتے ہیں، وہ مختلف ہیں۔
اسے دور کرنے کے لیے، آئیے Kubernetes استعمال کریں اور ڈویلپر ڈیٹا بیس سے جڑیں۔ آپ ایک بیرونی Kubernetes سروس کا نام بنا سکتے ہیں، جو آپ کو ایک مستحکم سروس فراہم کرے گا جو ٹریفک کو بیرونی سروس کی طرف بھیجے گا۔
یہ سروس کم سے کم کارکردگی کے اثر کے ساتھ کرنل کی سطح پر سادہ CNAME فارورڈنگ انجام دے گی۔ اس کا شکریہ آپ ایک آسان کنکشن سٹرنگ استعمال کر سکتے ہیں۔
لیکن چونکہ بیرونی نام CNAME فارورڈنگ کا استعمال کرتا ہے، اس لیے یہ پورٹ فارورڈنگ نہیں کر سکتا۔ لہذا، یہ حل صرف جامد بندرگاہوں پر لاگو ہوتا ہے اور اسے متحرک بندرگاہوں کے ساتھ استعمال نہیں کیا جا سکتا۔ لیکن mLab Free Tier صارف کو بطور ڈیفالٹ ایک متحرک پورٹ نمبر دیتا ہے اور آپ اسے تبدیل نہیں کر سکتے۔ اس کا مطلب ہے کہ آپ کو dev اور prod کے لیے مختلف کنکشن کمانڈ لائنوں کی ضرورت ہے۔ بری بات یہ ہے کہ اس کے لیے آپ کو پورٹ نمبر کو ہارڈ کوڈ کرنے کی ضرورت ہوگی۔ تو آپ کام کرنے کے لیے پورٹ فارورڈنگ کیسے حاصل کرتے ہیں؟
پہلا قدم یو آر آئی سے آئی پی ایڈریس حاصل کرنا ہے۔ اگر آپ nslookup، میزبان نام، یا URI کو پنگ کرتے ہیں، تو آپ ڈیٹا بیس کا IP ایڈریس حاصل کر سکتے ہیں۔ اگر سروس آپ کو کئی IP پتے واپس کرتی ہے، تو یہ تمام پتے آبجیکٹ کے اختتامی مقامات پر استعمال کیے جا سکتے ہیں۔
ذہن میں رکھنے کی ایک بات یہ ہے کہ آئی پی یو آر آئی بغیر اطلاع کے تبدیل ہو سکتے ہیں، جس سے انہیں پروڈ میں استعمال کرنا کافی خطرناک ہو جاتا ہے۔ اس آئی پی ایڈریس کا استعمال کرتے ہوئے، آپ پورٹ کی وضاحت کیے بغیر ریموٹ ڈیٹا بیس سے جڑ سکتے ہیں۔ اس طرح، Kubernetes سروس پورٹ فارورڈنگ کو کافی شفاف طریقے سے انجام دیتی ہے۔
نقشہ سازی، یا بیرونی وسائل کو اندرونی وسائل کے ساتھ نقشہ بنانا، آپ کو ریفیکٹرنگ کی کوششوں کو کم سے کم کرتے ہوئے مستقبل میں کلسٹر کے اندر ان خدمات کو استعمال کرنے کی لچک فراہم کرتا ہے۔ یہ آپ کی کمپنی کون سی بیرونی خدمات استعمال کرتی ہے اس کا انتظام کرنا اور بصیرت فراہم کرنا بھی آسان بناتا ہے۔
بہت جلد جاری رکھا جائے گا...
کچھ اشتہارات 🙂
ہمارے ساتھ رہنے کے لیے آپ کا شکریہ۔ کیا آپ کو ہمارے مضامین پسند ہیں؟ مزید دلچسپ مواد دیکھنا چاہتے ہیں؟ آرڈر دے کر یا دوستوں کو مشورہ دے کر ہمارا ساتھ دیں، , انٹری لیول سرورز کا ایک انوکھا اینالاگ، جو ہم نے آپ کے لیے ایجاد کیا تھا: (RAID1 اور RAID10 کے ساتھ دستیاب، 24 کور تک اور 40GB DDR4 تک)۔
ایمسٹرڈیم میں Equinix Tier IV ڈیٹا سینٹر میں Dell R730xd 2 گنا سستا؟ صرف یہاں نیدرلینڈ میں! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 سے! کے بارے میں پڑھا
ماخذ: www.habr.com