🥇 اسٹیو کے ساتھ مائیکرو سروسز پر واپس جائیں۔ حصہ 1

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

Istio - ایک اوپن سورس پروجیکٹ گوگل، IBM اور Lyft کی ٹیموں کے تعاون سے تیار کیا گیا ہے۔ یہ مائیکرو سروسز پر مبنی ایپلی کیشنز میں پیدا ہونے والی پیچیدگیوں کو حل کرتا ہے، جیسے:

ٹریفک مینجمنٹ: ٹائم آؤٹ، دوبارہ کوششیں، بوجھ توازن؛
سیکورٹی: اختتامی صارف کی توثیق اور اجازت؛
مشاہدہ: ٹریسنگ، مانیٹرنگ، لاگنگ۔

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

پروجیکٹ مینیجر: فیڈ بیک فیچر شامل کرنے میں کتنا وقت لگتا ہے؟
ڈویلپر: دو سپرنٹ۔

ایم پی: کیا؟... یہ صرف CRUD ہے!
R: CRUD کرنا آسان حصہ ہے، لیکن ہمیں پھر بھی صارفین اور خدمات کی تصدیق اور اجازت دینے کی ضرورت ہے۔ چونکہ نیٹ ورک ناقابل بھروسہ ہے، آپ کو بار بار کی درخواستوں کو لاگو کرنے کی ضرورت ہوگی، ساتھ ہی سرکٹ بریکر پیٹرن گاہکوں میں. اس کے علاوہ، یہ یقینی بنانے کے لیے کہ پورا سسٹم کریش نہ ہو، آپ کو ٹائم آؤٹ اور بلک ہیڈز (متذکرہ دونوں نمونوں کے بارے میں مزید تفصیلات کے لیے، بعد میں مضمون میں دیکھیں - تقریباً ترجمہ۔)اور مسائل کا پتہ لگانے، نگرانی، سراغ لگانے، […]
ایم پی: اوہ، تو آئیے اس فیچر کو پروڈکٹ سروس میں داخل کریں۔

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

نوٹ: یہ مضمون فرض کرتا ہے کہ آپ کوبرنیٹس کے بارے میں کام کا علم ہے۔ دوسری صورت میں، میں پڑھنے کی سفارش کرتا ہوں Kubernetes سے میرا تعارف اور اس کے بعد ہی اس مواد کو پڑھنا جاری رکھیں۔

Istio خیال

Istio کے بغیر دنیا میں، ایک سروس دوسری سے براہ راست درخواست کرتی ہے، اور ناکامی کی صورت میں، سروس کو خود ہی اسے سنبھالنا چاہیے: ایک نئی کوشش کریں، ٹائم آؤٹ فراہم کریں، سرکٹ بریکر کھولیں، وغیرہ۔

Kubernetes میں نیٹ ورک ٹریفک

Istio ایک خصوصی حل پیش کرتا ہے، نیٹ ورک کمیونیکیشن میں مداخلت کرکے خدمات اور کام کرنے سے مکمل طور پر الگ۔ اور اس طرح یہ لاگو کرتا ہے:

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

یہ صرف چند امکانات ہیں (واقعی صرف چند!) آپ کو دلچسپ بنانے کے۔ اب آئیے تکنیکی تفصیلات میں غوطہ لگائیں!

اسٹیو فن تعمیر

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

ڈیٹا پلین

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

ایلچی میں دوبارہ کوششیں اور سرکٹ بریکنگ کیسے لاگو کی جاتی ہیں۔

خلاصہ کرنے کے لئے:

ایلچی (ہم ایک سائڈ کار کنٹینر میں واقع ایک پراکسی کے بارے میں بات کر رہے ہیں، جس کو بطور تقسیم کیا جاتا ہے۔ علیحدہ مصنوعات - تقریبا. ترجمہ) سروس B کی پہلی مثال کو ایک درخواست بھیجتا ہے اور ناکام ہوجاتا ہے۔
ایلچی سائڈکار دوبارہ کوشش کرتا ہے۔ (دوبارہ کوشش کریں). (1)
درخواست ناکام ہوجاتی ہے اور اس پراکسی کو واپس کردی جاتی ہے جس نے اسے بلایا تھا۔
اس سے سرکٹ بریکر کھلتا ہے اور بعد کی درخواستوں کے لیے اگلی سروس کو کال کرتا ہے۔ (2)

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

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

اور آخر میں آپ پوچھتے ہیں: "کیا یہ حسب ضرورت ہے؟"

اب آپ سمندری سفر کے لیے تیار ہیں، آئیے کنٹرول پلین سے واقف ہوں۔

طیارہ کنٹرول کریں

یہ تین اجزاء پر مشتمل ہے: پائلٹ, مکسر и درگ، جو ٹریفک کو روٹ کرنے، پالیسیوں کو نافذ کرنے اور ٹیلی میٹری ڈیٹا اکٹھا کرنے کے لیے ایلچی کو ترتیب دینے کے لیے مل کر کام کرتے ہیں۔ منصوبہ بندی سے یہ سب کچھ اس طرح لگتا ہے:

ڈیٹا پلین کے ساتھ کنٹرول طیارے کا تعامل

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

Istio سے خدمات کا رشتہ

ہم نے Istio کے خدمات سے تعلق کو بیان کیا ہے، لیکن اس کے برعکس نہیں: خدمات کا Istio سے کیا تعلق ہے؟

سچ پوچھیں تو خدمات اسٹیو کی موجودگی سے اتنی ہی آگاہ ہیں جیسے مچھلی پانی کی ہوتی ہے جب وہ اپنے آپ سے پوچھتی ہیں، "ویسے بھی پانی کیا ہے؟"

مثال وکٹوریہ دیمتراکوپولوس:- آپ کو پانی کیسا لگتا ہے؟ - ویسے بھی پانی کیا ہے؟

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

کافی تھیوری - آئیے اس علم کو عملی جامہ پہنائیں!

پریکٹس میں Istio

Istio کو کم از کم 4 vCPUs اور 8 GB RAM کے ساتھ Kubernetes کلسٹر کی ضرورت ہے۔ فوری طور پر ایک کلسٹر ترتیب دینے اور مضمون کی ہدایات پر عمل کرنے کے لیے، میں گوگل کلاؤڈ پلیٹ فارم استعمال کرنے کی تجویز کرتا ہوں، جو نئے صارفین کو پیش کرتا ہے۔ مفت $300.

ایک کلسٹر بنانے اور کنسول یوٹیلیٹی کے ذریعے Kubernetes تک رسائی کو ترتیب دینے کے بعد، آپ Helm پیکیج مینیجر کے ذریعے Istio انسٹال کر سکتے ہیں۔

ہیلم کی تنصیب

اپنے کمپیوٹر پر ہیلم کلائنٹ انسٹال کریں، جیسا کہ میں بیان کیا گیا ہے۔ سرکاری دستاویزات. ہم اسے اگلے حصے میں Istio انسٹال کرنے کے لیے ٹیمپلیٹس بنانے کے لیے استعمال کریں گے۔

Istio انسٹال کرنا

اسٹیو وسائل سے ڈاؤن لوڈ کریں۔ تازہ ترین ریلیز (ورژن 1.0.5 سے اصل مصنف کا لنک موجودہ میں تبدیل کر دیا گیا ہے، یعنی 1.0.6 - تقریباً ترجمہ۔)، مواد کو ایک ڈائریکٹری میں نکالیں، جسے میں اب کال کروں گا۔ [istio-resources].

Istio وسائل کی آسانی سے شناخت کرنے کے لیے، K8s کلسٹر میں ایک نام کی جگہ بنائیں istio-system:

$ kubectl create namespace istio-system

ڈائرکٹری میں جا کر انسٹالیشن مکمل کریں۔ [istio-resources] اور کمانڈ چلا رہا ہے:

$ helm template install/kubernetes/helm/istio 
  --set global.mtls.enabled=false 
  --set tracing.enabled=true 
  --set kiali.enabled=true 
  --set grafana.enabled=true 
  --namespace istio-system > istio.yaml

یہ کمانڈ اسٹیو کے کلیدی اجزاء کو فائل میں آؤٹ پٹ کرے گی۔ istio.yaml. ہم نے مندرجہ ذیل پیرامیٹرز کی وضاحت کرتے ہوئے، خود کے مطابق معیاری ٹیمپلیٹ میں ترمیم کی:

global.mtls.enabled میں نصب false (یعنی ایم ٹی ایل ایس کی توثیق غیر فعال ہے - تقریباً)ہمارے ڈیٹنگ کے عمل کو آسان بنانے کے لیے؛
tracing.enabled Jaeger کا استعمال کرتے ہوئے درخواست کا پتہ لگانا شامل ہے۔
kiali.enabled خدمات اور ٹریفک کو دیکھنے کے لیے کیالی کو ایک کلسٹر میں انسٹال کرتا ہے۔
grafana.enabled جمع شدہ میٹرکس کو دیکھنے کے لیے گرافانا انسٹال کرتا ہے۔

آئیے تیار کردہ وسائل کو کمانڈ کے ساتھ استعمال کریں:

$ kubectl apply -f istio.yaml

کلسٹر پر Istio کی تنصیب مکمل ہو گئی ہے! اس وقت تک انتظار کریں جب تک کہ تمام پوڈ نام کی جگہ پر نہ ہوں۔ istio-system کرنے کے قابل ہو جائے گا Running یا Completedنیچے دی گئی کمانڈ کو چلا کر:

$ kubectl get pods -n istio-system

اب ہم اگلے حصے میں جاری رکھنے کے لیے تیار ہیں، جہاں ہم ایپلیکیشن کو تیار اور چلائیں گے۔

جذباتی تجزیہ کی درخواست کا فن تعمیر

آئیے پہلے ہی مذکور میں استعمال ہونے والی Sentiment Analysis microservice ایپلی کیشن کی مثال استعمال کرتے ہیں۔ Kubernetes کا تعارفی مضمون. یہ اسٹیو کی صلاحیتوں کو عملی طور پر دکھانے کے لیے کافی پیچیدہ ہے۔

درخواست چار مائیکرو سروسز پر مشتمل ہے:

سروس SA-فرنٹ اینڈ، جو Reactjs ایپلیکیشن کے فرنٹ اینڈ پر کام کرتا ہے۔
سروس SA-WebApp، جو جذباتی تجزیہ کے سوالات کو پیش کرتا ہے۔
سروس SA- منطق، جو خود انجام دیتا ہے۔ جذبات کا تجزیہ;
سروس SA-فیڈ بیک، جو تجزیہ کی درستگی کے بارے میں صارفین سے رائے حاصل کرتا ہے۔

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

اسٹیو سے پراکسی کے ساتھ ایپلیکیشن چلانا

مضمون میں مذکور مزید کارروائیوں کے لیے، اپنے ذخیرے کو کلون کریں۔ istio-mastery. اس میں Kubernetes اور Istio کے لیے ایپلیکیشن اور مینی فیسٹس شامل ہیں۔

سائڈ کاریں داخل کرنا

اندراج کیا جا سکتا ہے۔ خود بخود یا دستی طور پر. سائڈ کار کنٹینرز کو خود بخود داخل کرنے کے لیے، آپ کو نام کی جگہ پر ایک لیبل سیٹ کرنا ہوگا۔ istio-injection=enabled، جو درج ذیل کمانڈ کے ساتھ کیا جاتا ہے:

$ kubectl label namespace default istio-injection=enabled
namespace/default labeled

اب ہر پوڈ جو پہلے سے طے شدہ نام کی جگہ میں تعینات کیا جائے گا (default) اس کا سائڈ کار کنٹینر وصول کرے گا۔ اس کی تصدیق کرنے کے لیے، آئیے ریپوزٹری کی روٹ ڈائرکٹری میں جا کر ٹیسٹ ایپلیکیشن کو تعینات کرتے ہیں۔ [istio-mastery] اور درج ذیل کمانڈ کو چلا رہے ہیں:

$ kubectl apply -f resource-manifests/kube
persistentvolumeclaim/sqlite-pvc created
deployment.extensions/sa-feedback created
service/sa-feedback created
deployment.extensions/sa-frontend created
service/sa-frontend created
deployment.extensions/sa-logic created
service/sa-logic created
deployment.extensions/sa-web-app created
service/sa-web-app created

سروسز کو تعینات کرنے کے بعد، آئیے کمانڈ چلا کر چیک کریں کہ پوڈز میں دو کنٹینرز ہیں (خود سروس اور اس کے سائڈ کار کے ساتھ) kubectl get pods اور اس بات کو یقینی بنانا کہ کالم کے نیچے READY قدر کی وضاحت کی 2/2، اس بات کی علامت ہے کہ دونوں کنٹینرز چل رہے ہیں:

$ kubectl get pods
NAME                           READY     STATUS    RESTARTS   AGE
sa-feedback-55f5dc4d9c-c9wfv   2/2       Running   0          12m
sa-frontend-558f8986-hhkj9     2/2       Running   0          12m
sa-logic-568498cb4d-2sjwj      2/2       Running   0          12m
sa-logic-568498cb4d-p4f8c      2/2       Running   0          12m
sa-web-app-599cf47c7c-s7cvd    2/2       Running   0          12m

بصری طور پر یہ اس طرح لگتا ہے:

ایک پوڈ میں ایلچی پراکسی

اب جبکہ ایپلیکیشن تیار اور چل رہی ہے، ہمیں آنے والی ٹریفک کو ایپلیکیشن میں آنے کی اجازت دینی ہوگی۔

داخلی گیٹ وے

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

Ingress Gateway جزو اور سروس جو اسے بیرونی طور پر آگے بڑھاتی ہے، اسٹیو انسٹالیشن کے دوران کلسٹر میں انسٹال کی گئی تھی۔ سروس کا بیرونی IP پتہ معلوم کرنے کے لیے، چلائیں:

$ kubectl get svc -n istio-system -l istio=ingressgateway
NAME                   TYPE           CLUSTER-IP     EXTERNAL-IP
istio-ingressgateway   LoadBalancer   10.0.132.127   13.93.30.120

ہم اس IP کا استعمال کرتے ہوئے ایپلیکیشن تک رسائی حاصل کرنا جاری رکھیں گے (میں اسے EXTERNAL-IP کہوں گا)، لہذا سہولت کے لیے ہم قیمت کو متغیر میں لکھیں گے:

$ EXTERNAL_IP=$(kubectl get svc -n istio-system 
  -l app=istio-ingressgateway 
  -o jsonpath='{.items[0].status.loadBalancer.ingress[0].ip}')

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

گیٹ وے وسائل

گیٹ وے Kubernetes میں ایک CRD (کسٹم ریسورس ڈیفینیشن) ہے، جس کی وضاحت کلسٹر میں Istio کو انسٹال کرنے اور ان پورٹس، پروٹوکول اور میزبانوں کی وضاحت کرنے کی صلاحیت کو فعال کرنے کے بعد کی گئی ہے جس کے لیے ہم آنے والی ٹریفک کی اجازت دینا چاہتے ہیں۔

ہمارے معاملے میں، ہم تمام میزبانوں کے لیے پورٹ 80 پر HTTP ٹریفک کی اجازت دینا چاہتے ہیں۔ کام کو مندرجہ ذیل تعریف کے ذریعہ نافذ کیا گیا ہے۔ (http-gateway.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: http-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
- "*"

اس ترتیب کو سلیکٹر کے علاوہ کسی وضاحت کی ضرورت نہیں ہے۔ istio: ingressgateway. اس سلیکٹر کے ساتھ ہم یہ بتا سکتے ہیں کہ کنفیگریشن کو کس Ingress Gateway پر لاگو کرنا ہے۔ ہمارے معاملے میں، یہ Ingress Gateway کنٹرولر ہے، جو Istio میں بطور ڈیفالٹ انسٹال ہوا تھا۔

مندرجہ ذیل کمانڈ کو کال کرکے کنفیگریشن کا اطلاق ہوتا ہے۔

$ kubectl apply -f resource-manifests/istio/http-gateway.yaml gateway.networking.istio.io/http-gateway created

گیٹ وے اب پورٹ 80 تک رسائی کی اجازت دیتا ہے، لیکن اسے کوئی اندازہ نہیں ہے کہ درخواستوں کو کہاں سے روٹ کرنا ہے۔ اس کے لیے آپ کو ضرورت ہوگی۔ ورچوئل سروسز۔.

ورچوئل سروس ریسورس

ورچوئل سروس انگریس گیٹ وے کو بتاتی ہے کہ کلسٹر کے اندر اجازت یافتہ درخواستوں کو کیسے روٹ کیا جائے۔

http-گیٹ وے کے ذریعے آنے والی ہماری درخواست کی درخواستیں sa-frontend، sa-web-app اور sa-feedback سروسز کو بھیجی جائیں:

وہ راستے جنہیں ورچوئل سروسز کے ساتھ کنفیگر کرنے کی ضرورت ہے۔

آئیے ان درخواستوں کو دیکھتے ہیں جو SA-Frontend کو بھیجی جانی چاہئیں:

راستے میں عین مطابق میچ / index.html حاصل کرنے کے لیے SA-Frontend پر بھیجا جانا چاہیے۔
پریفکسڈ راستے /static/* فرنٹ اینڈ میں استعمال ہونے والی جامد فائلیں حاصل کرنے کے لیے SA-Frontend کو بھیجنا ضروری ہے، جیسے CSS اور JavaScript؛
ریگولر ایکسپریشن سے مماثل راستے '^.*.(ico|png|jpg)$'SA-Frontend پر بھیجنا ضروری ہے، کیونکہ یہ وہ تصاویر ہیں جو صفحہ پر دکھائی گئی ہیں۔

عمل درآمد درج ذیل ترتیب سے حاصل کیا جاتا ہے۔ (sa-virtualservice-external.yaml):

kind: VirtualService
metadata:
  name: sa-external-services
spec:
  hosts:
  - "*"
  gateways:
  - http-gateway                      # 1
  http:
  - match:
    - uri:
        exact: /
    - uri:
        exact: /callback
    - uri:
        prefix: /static
    - uri:
        regex: '^.*.(ico|png|jpg)$'
    route:
    - destination:
        host: sa-frontend             # 2
        port:
number: 80

اہم نکات:

اس ورچوئل سروس سے مراد آنے والی درخواستیں ہیں۔ http-گیٹ وے;
В destination جس سروس کو درخواستیں بھیجی جاتی ہیں اس کا تعین کیا جاتا ہے۔

نوٹ: اوپر کی ترتیب ایک فائل میں محفوظ ہے۔ sa-virtualservice-external.yamlجس میں SA-WebApp اور SA-Feedback میں روٹنگ کی ترتیبات بھی شامل ہیں، لیکن اختصار کے لیے مضمون میں اسے مختصر کر دیا گیا ہے۔

آئیے کال کرکے ورچوئل سروس کا اطلاق کریں:

$ kubectl apply -f resource-manifests/istio/sa-virtualservice-external.yaml
virtualservice.networking.istio.io/sa-external-services created

نوٹ: جب ہم Istio وسائل استعمال کرتے ہیں، Kubernetes API سرور ایک ایسا واقعہ تخلیق کرتا ہے جو Istio Control Plane کو موصول ہوتا ہے، اور اس کے بعد نئی ترتیب ہر پوڈ کے Envoy پراکسی پر لاگو ہوتی ہے۔ اور Ingress Gateway کنٹرولر ایسا لگتا ہے کہ کنٹرول پلین میں ترتیب دیا گیا ایک اور ایلچی ہے۔ یہ سب خاکہ میں اس طرح نظر آتا ہے:

درخواست کی روٹنگ کے لیے Istio-IngressGateway کنفیگریشن

جذباتی تجزیہ کی درخواست اب دستیاب ہے۔ http://{EXTERNAL-IP}/. اگر آپ کو Not Found اسٹیٹس ملتا ہے تو پریشان نہ ہوں: بعض اوقات کنفیگریشن کو اثر انداز ہونے اور ایلچی کیشز کو اپ ڈیٹ ہونے میں تھوڑا زیادہ وقت لگتا ہے۔.

آگے بڑھنے سے پہلے، ٹریفک پیدا کرنے کے لیے ایپ کے ساتھ تھوڑا سا کھیلیں۔ (اس کی موجودگی بعد کے اعمال میں وضاحت کے لیے ضروری ہے - تقریباً ترجمہ۔).

کیالی: مشاہدہ

Kiali انتظامی انٹرفیس پر جانے کے لیے، درج ذیل کمانڈ کو چلائیں:

$ kubectl port-forward 
    $(kubectl get pod -n istio-system -l app=kiali 
    -o jsonpath='{.items[0].metadata.name}') 
    -n istio-system 20001

... اور کھولیں http://localhost:20001/ایڈمن/ ایڈمن کے طور پر لاگ ان کرنا۔ یہاں آپ کو بہت ساری مفید خصوصیات ملیں گی، مثال کے طور پر، Istio اجزاء کی ترتیب کو چیک کرنے کے لیے، نیٹ ورک کی درخواستوں کو روکنے سے جمع کی گئی معلومات کا استعمال کرتے ہوئے خدمات کا تصور کرنا، "کون کس سے رابطہ کر رہا ہے؟"، "سروس کا کون سا ورژن تجربہ کر رہا ہے" کے سوالات کے جوابات حاصل کریں۔ ناکامیاں؟" اور اسی طرح. عام طور پر، Grafana کے ساتھ میٹرکس کو دیکھنے کی طرف بڑھنے سے پہلے Kiali کی صلاحیتوں کو دریافت کریں۔

گرافانا: میٹرکس ویژولائزیشن

اسٹیو میں جمع کردہ میٹرکس پرومیتھیس میں جاتے ہیں اور گرافانا کے ساتھ تصور کیے جاتے ہیں۔ Grafana انتظامی انٹرفیس پر جانے کے لیے، نیچے دی گئی کمانڈ کو چلائیں اور پھر کھولیں۔ http://localhost:3000/:

$ kubectl -n istio-system port-forward 
    $(kubectl -n istio-system get pod -l app=grafana 
    -o jsonpath={.items[0].metadata.name}) 3000

مینو پر کلک کرنا ہوم پیج (-) اوپر بائیں اور منتخب کرنا اسٹیو سروس ڈیش بورڈ اوپر بائیں کونے میں، سروس کے ساتھ شروع کریں۔ sa-web-appجمع شدہ میٹرکس کو دیکھنے کے لیے:

یہاں جو چیز ہمارا انتظار کر رہی ہے وہ ایک خالی اور مکمل طور پر بورنگ کارکردگی ہے - انتظامیہ اسے کبھی بھی منظور نہیں کرے گی۔ آئیے درج ذیل کمانڈ کے ساتھ ایک چھوٹا بوجھ بنائیں:

$ while true; do 
    curl -i http://$EXTERNAL_IP/sentiment 
    -H "Content-type: application/json" 
    -d '{"sentence": "I love yogobella"}'; 
    sleep .8; done

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

آخر میں، آئیے سروسز میں ٹریسنگ کی درخواستوں کو دیکھتے ہیں۔

Jaeger: سراغ لگانا

ہمیں ٹریسنگ کی ضرورت ہوگی کیونکہ ہمارے پاس جتنی زیادہ خدمات ہیں، ناکامی کی وجہ تک پہنچنا اتنا ہی مشکل ہے۔ آئیے نیچے دی گئی تصویر سے ایک سادہ کیس دیکھیں:

بے ترتیب ناکام درخواست کی عام مثال

درخواست آتی ہے، پڑتی ہے کیا وجہ ہے؟ پہلی خدمت؟ یا دوسرا؟ دونوں میں مستثنیات ہیں - آئیے ہر ایک کے نوشتہ جات کو دیکھیں۔ آپ نے خود کو کتنی بار ایسا کرتے ہوئے پکڑا ہے؟ ہمارا کام ڈویلپرز سے زیادہ سافٹ ویئر جاسوسوں جیسا ہے...

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

TraceId درخواست کی شناخت کے لیے استعمال کیا جاتا ہے۔

Istio Jaeger Tracer کا استعمال کرتا ہے، جو وینڈر سے آزاد OpenTracing API فریم ورک کو نافذ کرتا ہے۔ آپ مندرجہ ذیل کمانڈ کے ساتھ Jaeger صارف انٹرفیس تک رسائی حاصل کر سکتے ہیں:

$ kubectl port-forward -n istio-system 
    $(kubectl get pod -n istio-system -l app=jaeger 
    -o jsonpath='{.items[0].metadata.name}') 16686

اب جائیں http://localhost:16686/ اور ایک سروس منتخب کریں۔ sa-web-app. اگر ڈراپ ڈاؤن مینو میں سروس نہیں دکھائی دیتی ہے تو صفحہ پر سرگرمی دکھائیں/جنریٹ کریں اور انٹرفیس کو اپ ڈیٹ کریں۔ اس کے بعد، بٹن پر کلک کریں نشانات تلاش کریں۔، جو تازہ ترین نشانات دکھائے گا - کوئی بھی منتخب کریں - تمام نشانات پر تفصیلی معلومات ظاہر ہوں گی:

یہ نشان ظاہر کرتا ہے:

درخواست آتی ہے۔ istio-ingressgateway (یہ کسی ایک سروس کے ساتھ پہلا تعامل ہے، اور درخواست کے لیے ٹریس آئی ڈی تیار کی جاتی ہے)، جس کے بعد گیٹ وے درخواست کو سروس کو بھیجتا ہے۔ sa-web-app.
سروس میں sa-web-app درخواست کو ایلچی سائڈ کار کے ذریعے اٹھایا جاتا ہے، اس دورانیے میں ایک "بچہ" بنایا جاتا ہے (اسی وجہ سے ہم اسے نشانات میں دیکھتے ہیں) اور اسے کنٹینر کی طرف بھیج دیا جاتا ہے۔ sa-web-app. (پھیلاؤ - Jaeger میں کام کی ایک منطقی اکائی، جس کا ایک نام، آپریشن کے آغاز کا وقت اور اس کی مدت ہے۔ اسپین کو گھونسلا اور آرڈر کیا جاسکتا ہے۔ اسپین کا ایک ڈائریکٹڈ ایسکلک گراف ایک ٹریس بناتا ہے۔ - تقریبا. ترجمہ)
یہاں درخواست پر طریقہ کار سے کارروائی کی جاتی ہے۔ جذباتی تجزیہ. یہ نشانات پہلے ہی ایپلی کیشن کے ذریعہ تیار کیے گئے ہیں، یعنی انہیں کوڈ میں تبدیلی کی ضرورت تھی۔
اس لمحے سے، POST کی درخواست شروع کی گئی ہے۔ منطق. ٹریس آئی ڈی کو فارورڈ کرنا ضروری ہے۔ sa-web-app.
...

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

(A) Istio ہیڈر کو آگے بھیجنے کا ذمہ دار ہے۔ (B) خدمات ہیڈرز کے لیے ذمہ دار ہیں۔

Istio زیادہ تر کام کرتا ہے کیونکہ... آنے والی درخواستوں کے لیے ہیڈر تیار کرتا ہے، ہر سائیڈ کیئر میں نئے اسپین بناتا ہے اور انہیں آگے بھیجتا ہے۔ تاہم، سروسز کے اندر ہیڈر کے ساتھ کام کیے بغیر، مکمل درخواست کا ٹریس پاتھ ختم ہو جائے گا۔

درج ذیل ہیڈرز کو مدنظر رکھنا ضروری ہے:

x-request-id
x-b3-traceid
x-b3-spanid
x-b3-parentspanid
x-b3-sampled
x-b3-flags
x-ot-span-context

یہ کوئی مشکل کام نہیں ہے، لیکن اس کے نفاذ کو آسان بنانا پہلے سے موجود ہے۔ بہت سی لائبریریاں - مثال کے طور پر، sa-web-app سروس میں، RestTemplate کلائنٹ ان ہیڈرز کو آگے بھیج دیتا ہے اگر آپ صرف Jaeger اور OpenTracing لائبریریوں کو شامل کرتے ہیں۔ اس کی لتیں.

نوٹ کریں کہ Sentiment Analysis ایپلی کیشن فلاسک، اسپرنگ، اور ASP.NET کور میں نفاذ کو ظاہر کرتی ہے۔

اب جب کہ یہ واضح ہے کہ ہم باکس سے باہر کیا حاصل کرتے ہیں (یا تقریباً باکس سے باہر)، آئیے دیکھتے ہیں فائن ٹیونڈ روٹنگ، نیٹ ورک ٹریفک مینجمنٹ، سیکیورٹی وغیرہ!

نوٹ. ترجمہ: اس کے بارے میں Rinor Maloku سے اسٹیو پر مواد کے اگلے حصے میں پڑھیں، جن کے تراجم مستقبل قریب میں ہمارے بلاگ پر آئیں گے۔ اپ ڈیٹ (14 مارچ): دوسرا حصہ پہلے ہی شائع کیا گیا ہے.

مترجم سے PS

ہمارے بلاگ پر بھی پڑھیں:

"استیو کے ساتھ مائیکرو سروسز پر واپس جائیں": حصہ 2 (روٹنگ، ٹریفک کنٹرول), حصہ 3 (تصدیق اور اجازت);
«نالی - Kubernetes کے لیے ہلکا پھلکا سروس میش؛ "
«سروس میش کیا ہے اور مجھے اس کی ضرورت کیوں ہے [مائیکرو سروسز کے ساتھ کلاؤڈ ایپلیکیشن کے لیے]؟؛ "
«Kubernetes میں نیٹ ورکنگ کے لیے ایک واضح گائیڈ۔ حصہ 1 اور 2؛ "
«یہ سائڈ کار کنٹینر یہاں [کوبرنیٹس میں] کیسے ختم ہوا؟'.

ماخذ: www.habr.com

Istio کے ساتھ مائیکرو سروسز پر واپس جائیں۔ حصہ 1