اسٹیو میں ڈارک لانچ: سیکرٹ سروسز

"خطرہ میرا درمیانی نام ہے،" آسٹن پاورز، ایک بین الاقوامی پراسرار آدمی، کہتا تھا۔ لیکن جس چیز کو سپر ایجنٹوں اور انٹیلی جنس سروسز کے لیے بہت زیادہ عزت دی جاتی ہے وہ کمپیوٹر سروسز کے لیے بالکل موزوں نہیں ہے، جہاں بوریت خطرے سے کہیں بہتر ہے۔

اور Istio، OpenShift اور Kubernetes کے ساتھ مل کر، مائیکرو سروسز کی تعیناتی کو واقعی بورنگ اور قابل پیشن گوئی بناتا ہے - اور یہ بہت اچھا ہے۔ ہم اسٹیو سیریز کی چوتھی اور آخری پوسٹ میں اس اور بہت کچھ کے بارے میں بات کریں گے۔

جب بوریت صحیح ہے۔

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

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

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

بوریت کو منظم کرنا دلچسپ ہے۔

مندرجہ ذیل اسٹیو روٹنگ اصول پر ایک نظر ڈالیں، جو تمام HTTP درخواستوں کو مائیکرو سرویس کی سفارش v1 تک پہنچاتا ہے (تمام مثالیں اسٹیو ٹیوٹوریل گٹ ہب ریپو)، جب کہ بیک وقت ان کا عکس v2 مائیکرو سروس کی سفارش پر ڈالتے ہوئے:

لیبل پر توجہ دیں۔ mirror: اسکرین کے نیچے - یہ وہی ہے جو ٹریفک کی عکس بندی کو سیٹ کرتا ہے۔ جی ہاں، یہ اتنا آسان ہے!

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

آئیے ڈرامہ شامل کریں۔

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

آئیے ایک اہم نکتہ دہراتے ہیں۔

ٹریفک مررنگ کے ساتھ خفیہ لانچ (ڈارک لانچ/ریکوسٹ مررنگ) کوڈ کو کسی بھی طرح متاثر کیے بغیر انجام دیا جا سکتا ہے۔

سوچ کے لئے کھانا

کیا ہوگا اگر وہ جگہ جہاں درخواستوں کی عکس بندی کی جاتی ہے وہ ان میں سے کچھ کو v1 کو نہیں بلکہ v2 کو بھیجتی ہے؟ مثال کے طور پر، تمام درخواستوں کا ایک فیصد یا صرف صارفین کے ایک مخصوص گروپ کی درخواستیں۔ اور پھر، پہلے ہی دیکھتے ہوئے کہ v2 کیسے کام کرتا ہے، آہستہ آہستہ تمام درخواستوں کو نئے ورژن میں منتقل کریں۔ یا اس کے برعکس، اگر v1 میں کچھ غلط ہو جائے تو ہر چیز کو v2 پر واپس کر دیں۔ میرے خیال میں اسے Canary Deployment کہتے ہیں۔ کان کنی پر واپس جاتا ہے، اور اگر یہ روسی نژاد کا ہوتا تو شاید اس میں ایک حوالہ ہوتا بلیوں)، اور اب ہم اس کو مزید تفصیل سے دیکھیں گے۔

اسٹیو میں کینری تعیناتی: کمیشننگ کو آسان بنانا

احتیاط سے اور آہستہ آہستہ

Canary Deployment تعیناتی ماڈل کا نچوڑ انتہائی آسان ہے: جب آپ اپنے سافٹ ویئر کا نیا ورژن لانچ کرتے ہیں (ہمارے معاملے میں، ایک مائیکرو سروس)، تو آپ سب سے پہلے صارفین کے ایک چھوٹے سے گروپ کو اس تک رسائی دیتے ہیں۔ اگر سب کچھ ٹھیک ہو جاتا ہے، تو آپ اس گروپ کو آہستہ آہستہ بڑھاتے ہیں جب تک کہ نیا ورژن کام کرنا شروع نہ کر دے، یا - اگر ایسا نہیں ہوتا ہے - آخر کار تمام صارفین کو اس میں منتقل کر دیتے ہیں۔ سوچ سمجھ کر اور بتدریج ایک نیا ورژن متعارف کروا کر اور صارفین کو کنٹرول شدہ انداز میں اس میں تبدیل کر کے، آپ خطرات کو کم کر سکتے ہیں اور فیڈ بیک کو زیادہ سے زیادہ کر سکتے ہیں۔

یقینا، Istio ذہین درخواست کی روٹنگ کے لیے کئی اچھے اختیارات پیش کر کے کینری تعیناتی کو آسان بناتا ہے۔ اور ہاں، یہ سب کچھ آپ کے سورس کوڈ کو چھوئے بغیر بھی کیا جا سکتا ہے۔

براؤزر کو فلٹر کرنا

روٹنگ کے آسان ترین معیارات میں سے ایک براؤزر پر مبنی ری ڈائریکشن ہے۔ فرض کریں کہ آپ سفاری براؤزرز سے صرف v2 پر جانے کی درخواستیں چاہتے ہیں۔ یہاں یہ ہے کہ یہ کیسے ہوتا ہے:

آئیے اس روٹنگ اصول کو لاگو کریں اور پھر کمانڈ استعمال کریں۔ curl ہم مائیکرو سروس کے لیے حقیقی درخواستوں کو ایک لوپ میں نقل کریں گے۔ جیسا کہ آپ اسکرین شاٹ میں دیکھ سکتے ہیں، وہ سب v1 پر جاتے ہیں:

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

لامحدود طاقت

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

اب تک آپ کو شاید اندازہ ہو گیا ہو گا کہ ریگولر ایکسپریشن کیا کر سکتے ہیں۔

سمارٹ کام کریں۔

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

دلچسپی؟

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

اسٹیو ایگریس: سووینئر شاپ سے باہر نکلیں۔

Istio کو Red Hat OpenShift اور Kubernetes کے ساتھ استعمال کرکے، آپ مائیکرو سروسز کے ساتھ اپنی زندگی کو بہت آسان بنا سکتے ہیں۔ Istio کی سروس میش Kubernetes pods کے اندر چھپی ہوئی ہے، اور آپ کا کوڈ (زیادہ تر) تنہائی میں چلتا ہے۔ کارکردگی، تبدیلی میں آسانی، ٹریسنگ وغیرہ۔ یہ سب سائیڈ کار کنٹینرز کے استعمال کی بدولت استعمال کرنا آسان ہے۔ لیکن کیا ہوگا اگر آپ کی مائیکرو سروس کو دوسری سروسز کے ساتھ بات چیت کرنے کی ضرورت ہو جو آپ کے OpenShift-Kubernetes سسٹم سے باہر واقع ہیں؟

یہ وہ جگہ ہے جہاں اسٹیو ایگریس بچاؤ کے لئے آتا ہے۔ مختصر طور پر، یہ آپ کو ان وسائل تک رسائی کی اجازت دیتا ہے (پڑھیں: "سروسز") جو آپ کے Kubernetes pods کے سسٹم کا حصہ نہیں ہیں۔ اگر آپ اضافی کنفیگریشن نہیں کرتے ہیں، تو Istio Egress ماحول میں ٹریفک کو صرف پوڈز کے کلسٹر کے اندر اور اندرونی IP ٹیبلز پر مبنی ایسے کلسٹروں کے درمیان روٹ کیا جاتا ہے۔ اور جب تک آپ کو باہر سے خدمات تک رسائی کی ضرورت نہیں ہے اس طرح کی پپشن بہت اچھا کام کرتی ہے۔

Egress آپ کو مندرجہ بالا IP ٹیبلز کو نظرانداز کرنے کی اجازت دیتا ہے، یا تو Egress کے اصولوں کی بنیاد پر یا IP پتوں کی ایک رینج پر۔

ہم کہتے ہیں کہ ہمارے پاس جاوا پروگرام ہے جو httpbin.org/headers پر GET کی درخواست کرتا ہے۔

(httpbin.org باہر جانے والی سروس کی درخواستوں کی جانچ کے لیے صرف ایک آسان وسیلہ ہے۔)

اگر آپ کمانڈ لائن پر داخل ہوتے ہیں۔ curl http://httpbin.org/headers، ہم مندرجہ ذیل دیکھیں گے:

یا آپ براؤزر میں وہی پتہ کھول سکتے ہیں:

جیسا کہ آپ دیکھ سکتے ہیں، وہاں موجود سروس آسانی سے اس پر پاس کردہ ہیڈر واپس کر دیتی ہے۔

ہم درآمدات کی جگہ لے رہے ہیں۔

اب آئیے اس سروس کا جاوا کوڈ لیں، جو ہمارے سسٹم میں ایکسٹرنل ہے، اور اسے خود چلائیں، جہاں، یاد کریں، اسٹیو انسٹال ہے۔ (آپ رابطہ کرکے یہ کام خود کرسکتے ہیں۔ ہمارا اسٹیو ٹیوٹوریل.) مناسب تصویر بنانے اور اسے OpenShift پلیٹ فارم پر لانچ کرنے کے بعد، ہم اس سروس کو کمانڈ کے ساتھ کال کریں گے۔ curl egresshttpbin-istioegress.$(minishift ip).nip.io، جس کے بعد ہم اسے اسکرین پر دیکھیں گے:

اف، کیا ہوا؟ سب کچھ صرف کام کیا. Not Found کا کیا مطلب ہے؟ ہم نے صرف اس کے لیے کیا۔ curl.

آئی پی ٹیبلز کو پورے انٹرنیٹ تک بڑھانا

اس کے لیے اسٹیو کو مورد الزام ٹھہرایا جانا چاہیے (یا شکریہ ادا کیا جانا چاہیے)۔ سب کے بعد، Istio صرف سائڈ کار کنٹینرز ہے جو پتہ لگانے اور روٹنگ کے ذمہ دار ہیں (اور بہت سی دوسری چیزیں جن کے بارے میں ہم نے پہلے بات کی تھی)۔ اس وجہ سے، آئی پی ٹیبلز صرف یہ جانتی ہیں کہ آپ کے کلسٹر سسٹم کے اندر کیا ہے۔ اور httpbin.org باہر واقع ہے اور اس وجہ سے ناقابل رسائی ہے۔ اور یہ وہ جگہ ہے جہاں Istio Egress بچاؤ کے لیے آتا ہے - آپ کے سورس کوڈ میں معمولی تبدیلی کے بغیر۔

نیچے Egress کا اصول اسٹیو کو مطلوبہ سروس کے لیے (اگر ضروری ہو تو پورے انٹرنیٹ پر) تلاش کرنے پر مجبور کرتا ہے، اس صورت میں، httpbin.org۔ جیسا کہ آپ اس فائل (egress_httpbin.yml) سے دیکھ سکتے ہیں، یہاں کی فعالیت کافی آسان ہے۔

اس اصول کو لاگو کرنا باقی ہے:

istioctl create -f egress_httpbin.yml -n istioegress

آپ کمانڈ کے ساتھ Egress کے اصول دیکھ سکتے ہیں۔ istioctl get egressrules:

اور آخر کار، ہم دوبارہ کمانڈ چلاتے ہیں۔ curl کے - اور ہم دیکھتے ہیں کہ سب کچھ کام کرتا ہے:

ہم کھل کر سوچتے ہیں۔

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

یہ اسٹیو پر سیریز کی آخری پوسٹ تھی۔ دیکھتے رہیں - آگے بہت سی دلچسپ چیزیں ہیں!

ماخذ: www.habr.com