درخواستوں کو AWS سے GKE میں کیسے منتقل کیا جائے۔ [Full Book]

یہ گائیڈڈ لیب آپ کو React UI اور Express API کا استعمال کرتے ہوئے ایک چھوٹی ادائیگی کی ایپ کو منتقل کرنے کے ذریعے لے جاتی ہے جو ایک واحد AWS EC2 مثال پر چلتی ہے جبکہ PostgreSQL AWS پر رہتا ہے۔

اپنے UI اور API کو Google Kubernetes Engine میں منتقل کر کے ان عوامی URLs کو تبدیل کیے بغیر جنہیں آپ کے گاہک پہلے سے استعمال کر رہے ہیں، آپ آہستہ آہستہ ٹریفک کو AWS سے GKE میں منتقل کر دیں گے، ایک وقت میں چند فیصد۔

آخر میں، آپ ایپ کو مقامی طور پر چلائیں گے، AWS کو گھمائیں گے، آٹھ Terraform مراحل میں GKE بنائیں گے، نئے ماحول کی جانچ کریں گے، پروڈکشن ٹریفک کو GKE میں تبدیل کریں گے، کٹ اوور کو مکمل کریں گے، اور ہر وہ چیز ہٹا دیں گے جس کی آپ کو مزید ضرورت نہیں ہے۔

نیچے دی گئی تصویر مائیگریشن کے درمیان کو دکھاتی ہے، دونوں بادلوں کے ساتھ، صارف اب بھی ایک URL استعمال کر رہا ہے، اور ڈیٹا بیس AWS میں باقی ہے۔

تین اضافی نظام اس درخواست کے راستے کے ارد گرد کام انجام دیتے ہیں:

انڈیکس

اس سے پہلے کہ آپ شروع کریں۔

آپ کو جس چیز کی ضرورت ہے انسٹال کریں۔

اس باب کے لیے ضرورت کے مطابق ہر ٹول انسٹال کریں۔ آپ کو اپنے پہلے دن ہر چیز کی ضرورت نہیں ہے۔

صفحہ	سامان
1	ڈوکر ڈیسک ٹاپ (یا لینکس پر کمپوز کا استعمال کرتے ہوئے ڈوکر انجن)، گٹ، اور python3
4	AWS اکاؤنٹ، AWS CLI (چلائیں۔ aws configure ایک بار)، Terraform 1.5 یا اس سے زیادہ، rsyncاور SSH کلید
6	آپ کے لیپ ٹاپ پر Node.js 20 یا اس سے زیادہ انسٹال ہونا ضروری ہے۔ تصدیقی اسکرپٹ درج ذیل ہے: scripts/ استعمال کریں node JSON پڑھنے کے لیے
10	بلنگ کے ساتھ GCP پروجیکٹس فعال ہیں۔ gcloud CLI اور kubectl
14	آپ کا GitHub اکاؤنٹ اور GitHub پر اس ذخیرہ کی آپ کی اپنی کاپی۔
19	kustomize (اس کے ساتھ انسٹال کریں۔ brew install kustomize میک پر، kubectl.docs.kubernetes.io دیکھیں۔

ونڈوز پر، اس کتاب میں تمام کمانڈز کے لیے Git Bash یا WSL استعمال کریں۔ کمانڈ باش شیل کے لیے لکھے گئے ہیں۔

مہارت کی ضرورت ہے

کسی سابقہ ​​Kubernetes، Terraform، GCP، یا لوڈ بیلنس کے تجربے کی ضرورت نہیں ہے۔ ڈومین نہ خریدیں۔ AWS میں، کھولیں: https:// لچکدار IPs بھی شامل کیے گئے ہیں۔ براؤزر خود دستخط شدہ سرٹیفکیٹس کے بارے میں خبردار کرتے ہیں۔ اس پر کلک کریں اور آپ کو وہی کلیئر پے لاگ ان ملے گا جو آپ کے لیپ ٹاپ پر ہے۔ GCP ایک کا اضافہ کرتا ہے۔ /etc/hosts تو لائن https://api.clearpay.test جب تک آپ Cloud DNS سیٹ نہیں کرتے، یہ آپ کے لوڈ بیلنسر کی طرف اشارہ کرتا ہے۔

اس کی قیمت کتنی ہے؟

AWS کی لاگت تقریباً $1.25 فی دن ہے۔ ایک بار آپریشنل ہونے کے بعد GCP کی لاگت تقریباً $1.60 سے $3 فی دن ہے۔ ہفتے کے آخر میں ایک پوری کتاب پڑھنے میں چند ڈالر خرچ ہوتے ہیں۔

نہ ہی ماحول ایک ماہ تک چلنا چاہیے۔ اگر چند دنوں سے زیادہ رکے تو دونوں کو الگ کر دیں۔

./scripts/teardown-gcp.sh
cd infra/aws/terraform && terraform destroy

تفصیلات کے نمبر دو فائلوں میں محفوظ ہیں: infra/aws/COST.md اور infra/gcp/COST.md۔ کتاب صرف وہ دو فائلیں بھیجتی ہے، کوئی اور دستاویزات نہیں۔

یہ کتاب کیسے کام کرتی ہے۔

جب تک کہ مراحل میں وضاحت نہ کی گئی ہو، ذخیرہ کو کلون کریں اور تمام کمانڈز کو روٹ فولڈر سے چلائیں۔ cd دوسری جگہ:

git clone https://github.com/Osomudeya/migrate-api-aws-gke-devops.git

cd migrate-api-aws-gke-devops

ریپوزٹری میں پہلے سے ہی آپ کی ایپس، Terraform، Kubernetes فائلیں، پائپ لائنز اور اسکرپٹس موجود ہیں۔

آپ کوئی نیا کوڈ نہیں لکھیں گے۔ آپ کا کام ہر قدم پر عمل کرنا ہے، پڑھنا ہے کہ سسٹم کیا پرنٹ کرتا ہے، اور فیصلہ کرنا ہے کہ آیا جاری رکھنا ہے۔

کتاب آپ کے پہلے ہفتے میں ایک چھوٹی ادائیگی کمپنی میں شمولیت کی کہانی کی طرح پڑھتی ہے، اور ہر باب ٹیم میں کسی کے ذریعہ آپ کو تفویض کردہ کام ہے۔

ہر باب ٹائم اسٹیمپ اور ایک منظر کے ساتھ کھلتا ہے اور اسی لوپ کی پیروی کرتا ہے۔

سب سے اہم اصول

وہ کمانڈ نہ چلائیں جو آپ نہیں سمجھتے ہیں۔ اگر کتاب نے آپ کو پہلے ہی نہیں بتایا ہے کہ کیوں، پڑھنا جاری رکھیں۔ کیونکہ "کیوں” کلید ہے۔

اس کتاب میں دو مراحل ہیں۔

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

دوسرا آپ سے کہتا ہے کہ کیا ہوا اس کے بارے میں سوچیں۔ جب کمانڈ مکمل ہو جائے، اگلے باب پر جانے سے پہلے آؤٹ پٹ کو پڑھیں اور اس کے معنی کو سمجھیں۔

باب

ابواب کو ترتیب سے پڑھیں اور آگے بڑھیں۔ باب 1 آپ سے Kubernetes انسٹال کرنے یا GCP کھولنے کی ضرورت نہیں ہے۔ وہ بعد میں آتے ہیں۔

پارٹ ٹائم نوکری	صفحہ	کیا ہوتا ہے
1. ClearPay شروع کریں اور AWS پر تعینات کریں۔	1~6	اپنے لیپ ٹاپ پر ایپ چلائیں، اسے ایک AWS سرور پر تعینات کریں، اور رفتار ریکارڈ کریں۔
2. اپنے اقدام کی منصوبہ بندی کریں۔	7~9	اسائنمنٹ پڑھیں، نقشہ بنائیں کہ آپ کی ایپ کس چیز پر منحصر ہے، اور GCP ڈیزائن پڑھیں۔
3. ٹیرافارم کے ساتھ گوگل کلاؤڈ بنانا	10~11	آپ GCP کو آٹھ Terraform مراحل میں بناتے ہیں، ایک وقت میں ایک۔
4. ClearPay کو GKE سٹیجنگ میں تبدیل کریں۔	12~15	پائپ لائن ClearPay کو GKE سٹیجنگ میں رکھتی ہے اور پروموشن گیٹ اس کی تصدیق کرتا ہے۔
5. GKE پروڈکشن کے لیے تیار کریں۔	16~18	سیکیورٹی کا جائزہ لیں، ڈیش بورڈ سیٹ کریں، اور جان بوجھ کر سٹیجنگ کو توڑ دیں۔
6. صارفین کو GKE میں منتقل کریں۔	19~23	پیداوار کو تعینات کریں اور ٹریفک کو 1% سے 100% تک لے جائیں۔
7. ہجرت مکمل	24~28	کٹ اوور، ڈیکمیشن AWS، ڈی کنسٹریکٹ اور لاگ ہر چیز کو ثابت کریں۔

اگر کچھ کام نہیں کرتا ہے۔

اس باب میں رہیں۔ اسے استعمال کریں "اگر میں ناکام ہو جاؤں” قدم آگے نہ بڑھیں۔ آگے بڑھنے والے مسائل کو تلاش کرنا مشکل ہو جاتا ہے۔ کیونکہ اگلا باب مسئلہ پر ایک اور بادل ڈال دیتا ہے۔

کام Kubernetes یا Terraform کو حفظ کرنا نہیں ہے۔ یہ ایک حقیقی نقل مکانی کے ذریعے کام کرنے کا طریقہ سیکھنے کے بارے میں ہے۔ سمجھیں کہ کیا چل رہا ہے، جو کچھ آپ کو ملتا ہے اس کی بنیاد پر فیصلے کریں، نتائج چیک کریں، اور جانیں کہ اگر کچھ غلط ہو جاتا ہے تو کیا کرنا ہے۔

وقت لیا

اس میں ایک دن یا اس سے زیادہ وقت لگ سکتا ہے۔ اگر آپ ایک یا دو دن سے زیادہ دور رہیں گے، تو اپنے AWS اور GCP وسائل کو ضائع کر دیں تاکہ ان کے بیکار ہونے کے دوران بل وصول ہونے سے بچ سکیں۔ ہدایات اوپر "اخراجات” کے تحت ہیں۔

ٹیم

یہ لیب ہفتہ 1 میں ClearPay ٹیم میں ایک جونیئر DevOps انجینئر Zee کے ساتھ شروع ہوتی ہے۔ تم زی کھیلو۔

• مایا ایک انجینئرنگ مینیجر ہے۔ وہ ثبوت مانگتی ہے۔

• ڈینیئل ایک سینئر انجینئر ہے۔ وہ آپ کے ساتھ سرورز، کوبرنیٹس اور صلاحیت پر جوڑتا ہے۔

• عمارہ ادائیگیوں کے API کو برقرار رکھتی ہے۔ وہ صرف ایک چیز کا خیال رکھتی ہے۔ خیال یہ ہے کہ صارفین کو دو بار بل نہیں دیا جاتا ہے۔

• کرس کسٹمر سپورٹ کو سنبھالتا ہے۔ اگر ٹرانسمیشن ناکام ہوجاتی ہے، تو وہ پہلے سنتا ہے۔

آپ کا کام اس بات کو یقینی بنانا ہے کہ کسٹمرز اپنے بلنگ API کو AWS EC2 سرور سے بغیر کسی قابل توجہ رکاوٹ کے GKE میں منتقل کر سکیں، پوسٹگری ایس کیو ایل کو AWS پر رکھتے ہوئے۔

حصہ 1۔ ClearPay کو کیسے حاصل کیا جائے اور AWS پر چلایا جائے۔

نقل مکانی کے لیے ایک قابل اعتماد نقطہ آغاز کی ضرورت ہوتی ہے۔ اس حصے میں، ہم اپنے لیپ ٹاپ پر ClearPay چلائیں گے، اسے AWS پر اس طرح تعینات کریں گے جس طرح ہماری کمپنی اسے چلاتی ہے، اور نوٹ کریں کہ یہ کتنی تیز ہے۔ تمام بعد کے ابواب ان اعداد و شمار سے GKE کا موازنہ کرتے ہیں۔

باب 1۔ اپنے لیپ ٹاپ پر کلیئر پے چلائیں۔

پہلا پیر، صبح 9:05 بجے

آپ کا لیپ ٹاپ نیا ہے۔ Wi-Fi پاس ورڈ ایک چپچپا نوٹ پر ہے۔ آپ کے ان باکس میں پہلا پیغام مختصر ہے اور ہماری انجینئرنگ مینیجر مایا کی طرف سے ہے۔

مایا: "پہلے، اپنے لیپ ٹاپ پر کلیئر پے لانچ کریں۔ لاگ ان کریں، مجھے $20 بھیجیں، اور ہم آپ کے API کو GKE میں منتقل کرنے کے بارے میں بات کریں گے۔”

کوڈ مخزن میں ہے: api/، ui/اور db/. ابھی تک کچھ نہیں چل رہا ہے۔

یہ کیوں اہمیت رکھتا ہے۔

بعد کے ابواب کے لیے آپ کو درست لاگ ان تصویر اور $20 کی منتقلی کی ضرورت ہوگی۔ اگر آپ کو AWS یا GKE کے ساتھ کوئی مسئلہ ہے تو اس کا اس سے موازنہ کریں۔

آپ کیا چلانا چاہتے ہیں

ClearPay تین حصوں پر مشتمل ہے، جن میں سے ہر ایک کا ایک کام ہے۔

• کہ UI گاہک جو دیکھتا اور ٹیپ کرتا ہے وہ لاگ ان صفحہ، بیلنس اور بھیجنے کا بٹن ہے۔ UI کا مطلب ہے صارف انٹرفیس۔

• کہ API یہ وہ حصہ ہے جو کام کرتا ہے۔ کوئی سکرین نہیں ہے۔ UI ایک پیغام بھیجتا ہے جیسے "Bob کو $20 بھیجیں۔” API پیغام کو تسلیم کرتا ہے، کارروائی کرتا ہے، اور جواب واپس بھیجتا ہے جیسے "ہو گیا”۔ API کا مطلب ایپلی کیشن پروگرامنگ انٹرفیس ہے۔ اسے اصولوں کے ساتھ ایک دروازہ سمجھیں۔ UI ایک مقررہ طریقے سے پوچھتا ہے اور API ایک مقررہ طریقے سے جواب دیتا ہے۔

• کہ ڈیٹا بیس یہ وہ جگہ ہے جہاں ClearPay ہر چیز کو ریکارڈ کرتا ہے: آپ کے تمام اکاؤنٹس، بیلنس، ادائیگیاں اور بہت کچھ۔ PostgreSQL ڈیٹا بیس پروگرام ہے جسے ClearPay استعمال کرتا ہے۔

• کوئی راستہ نہیں سرور یہ ایک ایسا کمپیوٹر ہے جو سارا دن چلتا رہتا ہے اور درخواستوں کا انتظار کرتا ہے۔ API ایک پر چلتا ہے۔

کیفے اسی طرح کام کرتے ہیں۔ مینیو UI ہیں۔ ویٹر ایک API ہے۔ کچن اور اس کا ریکارڈ ایک ڈیٹا بیس ہے۔ گاہک کبھی کچن میں داخل نہیں ہوتے۔ گاہک ویٹر کو بتاتے ہیں کہ وہ کیا چاہتے ہیں۔

اس باب میں، ہم تینوں کو اپنے لیپ ٹاپ پر چلائیں گے۔ بعد کے ابواب میں، ہم UI اور API کو Google Cloud میں منتقل کریں گے۔ ڈیٹا بیس AWS میں برقرار ہے۔

قدم

ڈوکر ڈیسک ٹاپ شروع کریں۔ اس باب میں نوڈ یا PostgreSQL انسٹال نہ کریں۔ یہ ایک کنٹینر کے اندر چلتا ہے۔

محفوظ شدہ فولڈر میں docker-compose.yml:

docker compose up --build

پہلی تعمیر میں چند منٹ لگتے ہیں۔ یہ ٹرمینل لاگ کو پرنٹ کرنا جاری رکھتا ہے اور جب تک آپ Ctrl+C نہیں دباتے تب تک پیغامات کو دوبارہ ظاہر نہیں کرتا ہے۔ چلتے رہنے دو۔

تینوں لائنوں کے ظاہر ہونے تک انتظار کریں۔ بائیں طرف کا نام فولڈر کے نام سے شروع ہو سکتا ہے۔

Container -postgres-1 Healthy
api-1       | {"message":"api_started", ...}
ui-1        |   ➜  Local:   http://localhost:5173/

Healthy اس کا مطلب ہے کہ پوسٹگریس کام کر رہا ہے۔ api_started اس کا مطلب ہے کہ API کام کر رہا ہے۔ کہ localhost:5173 لائن کا مطلب ہے کہ UI کام کر رہا ہے۔

اسی فولڈر میں دوسرا ٹرمینل کھولیں۔ دو ڈیمو اکاؤنٹس بنائیں:

docker compose exec api node db/seed.js

یہ سیڈ اسکرپٹ کو براہ راست چلائے گا۔ API امیج میں جان بوجھ کر npm نہیں ہے۔ کیونکہ مجھے باب 14 میں سیکیورٹی چیک نے جھنڈا لگایا تھا۔

متوقع پیداوار:

seeded: alice@clearpay.dev (password: password123)
seeded: bob@clearpay.dev (password: password123)

اگر آپ دیکھتے ہیں skip (already exists): alice@clearpay.devپچھلے رن سے ایک اکاؤنٹ موجود ہے۔ یہ ٹھیک ہے

فی الحال جو چل رہا ہے وہ یہ ہے:

چیک کریں

دوسرے ٹرمینل میں:

curl localhost:4000/health

متوقع نتائج یہ ہیں: آپ کے instance قدر کنٹینر ID ہوگی۔

{"status":"ok","served_by":{"platform":"aws","version":"1.0.0","instance":"14b8d5d767ea","commit":"local","rollback_active":false}}

"status":"ok" یہ ایک چیک ہے۔ served_by اس پلیٹ فارم کا نام بتاتا ہے جس نے درخواست کا جواب دیا۔ یہ کہتا ہے aws آپ کے لیپ ٹاپ پر docker-compose.yml سیٹ PLATFORM: aws. بعد میں GKE اس کے ساتھ جواب دیتا ہے: gkeوہ ایک فیلڈ آپ کو بتاتا ہے کہ کس بادل نے ہر درخواست کو سنبھالا ہے۔

اب http://localhost:5173 کھولیں اور لاگ ان کریں۔ ایلس کو رجسٹر نہ کریں کیونکہ بیج اسے پہلے ہی بنا چکا ہے۔

$20 بھیجیں۔ bob@clearpay.dev. آپ کی منتقلی حالیہ سرگرمی کے تحت درج ذیل ظاہر ہوگی: Sent مثال کے طور پر، اگر آپ مختصر ID استعمال کرتے ہیں: Sent · a1b2c3d4.

اس ڈیش بورڈ پر دو جگہوں پر دیکھیں: کتاب کے بقیہ حصے میں، آپ دیکھیں گے:

1. حالیہ سرگرمی کے تحت ہر سطر اس پر ختم ہوتی ہے: served by aws/1.0.0. یہ API عمل کا پلیٹ فارم اور ورژن ہے جس نے ٹرانسپورٹ کو تخلیق کیا۔ یہ ڈیٹا بیس کی منتقلی کے ساتھ محفوظ کیا جاتا ہے۔

2. سب سے اوپر کالی بار کہتی ہے: All systems operational جب /health/ready کامیابی اس کا مطلب یہ ہے کہ API عمل چل سکتا ہے اور Postgres تک پہنچ سکتا ہے۔ یہ لاگ ان ہونے کے بارے میں کچھ نہیں کہتا۔ اگر پاس ورڈ غلط ہے، تو فارم ایک سرخ غلطی دکھاتا ہے اور بار مندرجہ ذیل پیغام کو ظاہر کرتا رہتا ہے: All systems operational.

باب 5 کے بعد، آپ اپنے AWS ایڈریس سے وہی ڈیش بورڈ کھولتے ہیں۔ ایک ہی لاگ ان، وہی دو مقامات۔

اگر یہ ناکام ہوجاتا ہے:

• failed to connect to the docker API یا docker.sock: Docker ڈیسک ٹاپ نہیں چل رہا ہے۔ اسے شروع کریں، اس کے تیار ہونے تک انتظار کریں، پھر اسے چلائیں۔ docker compose up --build دوبارہ

• email already registered رجسٹریشن کے صفحے پر: ایلس پہلے سے موجود ہے۔ لاگ ان کرنے پر واپس جائیں۔

• invalid credentials: پاس ورڈ پوری تار ہے۔ password123. اگر یہ اب بھی ناکام ہو جاتا ہے تو سیڈ کمانڈ کو دوبارہ چلائیں۔ کوئی راستہ نہیں skip (already exists) ایک لائن کا مطلب ہے کہ آپ کا اکاؤنٹ ہے۔

• docker compose up فوری طور پر باہر نکلیں: چلائیں۔ docker compose logs api دوسرے ٹرمینل میں۔ ایک سست پہلے بوٹ میں، پوسٹگریس کے کنکشن کو قبول کرنے سے پہلے API شروع ہو سکتا ہے۔ چلائیں docker compose up دوبارہ

• بندرگاہ 4000 یا 5173 پہلے سے استعمال میں ہے: آپ کے کمپیوٹر پر ایک اور پروگرام پورٹ کا مالک ہے۔ براہ کرم پورٹ میپنگ کو روکیں یا تبدیل کریں۔ docker-compose.yml.

فیصلہ

منتقلی مکمل ہونے کے بعد، درخواست کام کرے گی۔ جاری رکھیں

اگر نہیں، تو براہ کرم اسے یہاں اپنی نوٹ بک میں ٹھیک کریں۔ AWS اور GKE کو ڈیبگ کرنا زیادہ مشکل ہے۔ اس مشین میں صرف ایک ہی جواب ہے۔ docker compose logs آرڈر دور کریں۔

مکمل ہونے پر:

• docker compose up غلطی کے بغیر چلتا ہے۔

• بیج دو اکاؤنٹس کی رپورٹ کرتا ہے جو بنائے گئے یا چھوڑے گئے تھے۔

• میں نے UI سے $20 بھیجے اور میں نے اسے اپنی حالیہ سرگرمی میں دیکھا۔

باب 2۔ اہم کوڈ پڑھیں

پیر، 11:30 AM

$20 گزر گئے۔ آپ اب بھی ٹرانسفر لائن کو دیکھ رہے ہیں جب ایک کرسی آپ کے ساتھ لڑھکتی ہے۔ اگلی میز پر چیف انجینئر ڈینیئل اپنی کافی پیتا ہے اور اسے کوئی جلدی نہیں ہے۔

دانیال اسکرین کی طرف دیکھتا ہے۔ "آپ کو ہر سطر کو حفظ کرنے کی ضرورت نہیں ہے۔ یہ جاننا کہ کون سی فائلیں کرتی ہیں جو آپ کو منتقلی کے دوران انہیں تیزی سے کھولنے کی اجازت دیتی ہیں۔”

یہ کیوں اہمیت رکھتا ہے۔

اس کے بعد کے تمام ابواب ان چار فائلوں میں سے ایک کا احاطہ کرتے ہیں۔ ابھی صرف 5 منٹ نکالیں اور آپ بعد میں اپنے آپ کو ہائی پریشر کی تلاش کے گھنٹوں کی بچت کریں گے۔

قدم

فائلوں کو درج ذیل ترتیب میں کھولیں:

1. api/src/index.js API شروع کریں اور تمام راستوں کو جوڑیں: اسٹیٹس چیک کریں۔ /api/infoلاگ ان کریں اور تجارت کریں۔

2. api/src/servedBy.js یہ 17 لائنیں لمبی ہے۔ یہ پڑھتا ہے PLATFORM، APP_VERSIONاور ROLLBACK_ACTIVE ماحولیاتی متغیرات میں۔ ڈیش بورڈ اسے پرنٹ کرنے کے لیے استعمال کرتا ہے۔ served by aws/1.0.0.

3. api/src/routes/transactions.js ترسیلات زر پر عمل کرتا ہے۔ تلاش کریں۔ idempotency_key اوپر کے قریب چیک کریں۔ یہ کسی بھی چیز سے پہلے چلتا ہے۔

4. api/src/db.js اپنے API کو Postgres سے مربوط کریں۔ تلاش کریں DB_POOL_SIZE || '10'.

ڈینیئل آپ کو آخری فائل پر روکتا ہے۔

"کنکشن ڈیٹا بیس کے لیے ایک کھلی لائن ہے۔ ایک API عمل میں بیک وقت 10 لائنیں ہو سکتی ہیں۔ اس نمبر کو یاد رکھیں۔”

آپ اب کیا جانتے ہیں

index.js                 → starts the API and connects the routes
servedBy.js              → says which cloud answered (aws or gke)
routes/transactions.js   → sends money, checks the idempotency key first
db.js                    → talks to Postgres, up to 10 connections per process

servedBy.js ڈیش بورڈ لائنوں کو پُر کریں۔ served by aws/1.0.0. یہ نہیں ہے کہ کس نے لاگ ان کیا، لیکن کس بادل نے جواب دیا۔

فی الحال ایک API عمل ہے، لہذا 10 کنکشن کل پول ہے۔ GKE بیک وقت API کی متعدد کاپیاں چلاتا ہے۔ Kubernetes ہر ایک کاپی کو پوڈ کہتے ہیں۔ ہر پوڈ کا اپنا 10 پول ہوتا ہے، اور تمام پوڈ ایک ہی ڈیٹا بیس کا اشتراک کرتے ہیں۔ باب 22 اس ریاضی میں واپس آتا ہے۔

مکمل ہونے پر:

• آپ یہ دیکھے بغیر بتا سکتے ہیں کہ کون سی فائلیں کنکشن کی حدیں طے کرتی ہیں اور کون سی فائلیں پلیٹ فارم کے نام بتاتی ہیں۔

باب 3۔ ثابت کریں کہ دوبارہ کوششوں کا دو بار بل نہیں دیا جاتا ہے۔

پیر 2:10 PM

دوپہر کے کھانے کے بعد، مجھے کسی ایسے شخص کا پیغام ملتا ہے جس سے میں ابھی تک نہیں ملا۔ عمارہ ادائیگیوں کے API کو برقرار رکھتی ہے۔ مایا نے سلام کرنا چھوڑ دیا کیونکہ اس نے کہا کہ وہ اپنے لیپ ٹاپ پر ClearPay چلا رہی ہے۔

عمارہ: "ایک ہی کلید سے دو بار $20 بھیجیں۔ ایلس کا بیلنس $20 کم ہونا چاہیے، $40 نہیں۔”

یہ کیوں اہمیت رکھتا ہے۔

ایلس باب کو $20 بھیجتی ہے۔ جب میں بھیجیں پر ٹیپ کرتا ہوں، اسکرین جم جاتی ہے۔ مجھے یقین نہیں ہے کہ آیا میری ادائیگی ہو گئی، اس لیے میں دوبارہ بھیجیں پر ٹیپ کرتا ہوں۔

تحفظ کے بغیر، API دو درخواستوں کی تصدیق کرے گا اور دو بار $20 وصول کرے گا۔ ایلس ایک ادائیگی میں $40 کھو دیتی ہے۔

کہ idempotency_key یہ بند کرو۔ "Idempotent” کا مطلب ہے کہ اسے دہرانا محفوظ ہے۔ اسے دو بار کرنے سے وہی نتائج ملتے ہیں جیسے ایک بار کرنے سے۔

کلید ایک لیبل ہے جسے ایپ ہر بار جب آپ ادائیگی کرتے ہیں ظاہر کرتی ہے۔ مثال کے طور پر round-a.

1. پہلی درخواست ایک لیبل کے ساتھ آتی ہے۔ round-a. API لیبل کو ذخیرہ کرنے کے لیے $20 چارج کرتا ہے۔

2. دوسری درخواست اسی لیبل کے ساتھ آتی ہے۔ API مندرجہ ذیل ہے۔ round-a دوبارہ اس میں آپ کو کوئی پیسہ نہیں لگتا کیونکہ آپ جانتے ہیں کہ یہ ایک ہی ادائیگی ہے۔ پہلا نتیجہ واپس بھیجیں۔

ایک ہی لیبل کا مطلب ایک ہی ادائیگی ہے۔

ہجرت کے دوران یہ اور بھی اہم ہے۔ کبھی کبھی پہلا ٹیب AWS پر جاتا ہے اور دوسری بار دوبارہ کوششیں GKE پر جاتی ہیں۔ دو مختلف سرورز، لیکن ایک ڈیٹا بیس کا استعمال کرتے ہوئے. GKE اس ڈیٹا بیس کو دیکھتا ہے اور مندرجہ ذیل تلاش کرتا ہے: round-aیہ دوبارہ چارج نہیں کرے گا۔ ایک مشترکہ ڈیٹا بیس صارفین کو دونوں بادلوں میں محفوظ رکھتا ہے۔

استعمال کریں curl اس باب میں کوئی ٹرانسفر بٹن نہیں ہے۔ UI ہر کلک کے لیے ایک نئی کلید فراہم کرتا ہے، لہذا ہر کلک کے نتیجے میں ایک نئی منتقلی ہوتی ہے۔

idempotency کے بارے میں مزید معلومات کے لیے، PayFlow دیکھیں: A Production-Grade FinTech System for Real-World DevOps Learning۔

قدم

دوسرے ٹرمینل میں درج ذیل فولڈر میں رہیں: docker-compose.yml. ایک وقت میں ایک کمانڈ پر عمل کرتا ہے اور اگلی کمانڈ سے پہلے آؤٹ پٹ پڑھتا ہے۔

ایلس کے طور پر لاگ ان کریں۔ یہ اس کے لاگ ان ٹوکن کو شیل متغیر میں محفوظ کر دے گا۔ TOKEN. ٹوکن اس بات کا ثبوت ہے کہ ایلس نے لاگ ان کیا۔ $TOKEN.

TOKEN=$(curl -s -X POST localhost:4000/api/auth/login 
  -H "Content-Type: application/json" 
  -d '{"email":"alice@clearpay.dev","password":"password123"}' 
  | python3 -c "import sys, json; print(json.load(sys.stdin)['token'])")

اگر یہ کام کرتا ہے تو، کچھ بھی پرنٹ نہیں کرے گا. چلائیں echo $TOKEN تصدیق کرنا۔ آپ کو ایک لمبی تار دیکھنا چاہئے۔

پھر ایلس کی کہانی پڑھیں۔ برائے مہربانی درج ذیل تحریر کریں۔ balance_cents نمبر

curl -s localhost:4000/api/accounts/me -H "Authorization: Bearer $TOKEN"

یہ توقع کے مطابق لگتا ہے۔ آپ کا فون نمبر اور id یہ مختلف ہوگا:

{"account":{"id":"...","balance_cents":"94000","currency":"USD"},"served_by":{"platform":"aws","version":"1.0.0","instance":"...","commit":"local","rollback_active":false}}

94000 اس کا مطلب ہے $940.00۔ اگر آپ نے ابھی تک کچھ نہیں بھیجا ہے تو آپ اسے دیکھ سکتے ہیں۔ 100000 ($1,000.00)۔ حکم کے مطابق missing_token یا invalid_tokenمرحلہ 1 دوبارہ چلائیں۔

اب ایک ایسا لیبل منتخب کریں جو آپ نے ابھی تک استعمال نہیں کیا ہے۔

LABEL=round-a

Bob $20 بھیجیں۔ 2000 یہ سینٹ میں $20.00 ہے۔

curl -s -X POST localhost:4000/api/transactions 
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" 
  -d "{"to_email":"bob@clearpay.dev","amount_cents":2000,"idempotency_key":"$LABEL"}"

اسے تلاش کریں۔ "replayed" جواب سے:

• "replayed":false اس کا مطلب ہے کہ اس منتقلی کی لاگت $20 ہے۔ جاری رکھیں

• "replayed":true اس کا مطلب ہے کہ یہ لیبل پہلے استعمال کیا جا چکا ہے، ممکنہ طور پر پچھلے رن میں۔ پیسہ منتقل نہیں ہوا۔ سیٹ LABEL=round-b اور اسے دوبارہ بھیجیں جب تک کہ آپ اسے نہ دیکھیں "replayed":false.

براہ کرم وہی درخواست دوبارہ بھیجیں۔ تبدیل نہ کرو LABEL.

curl -s -X POST localhost:4000/api/transactions 
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" 
  -d "{"to_email":"bob@clearpay.dev","amount_cents":2000,"idempotency_key":"$LABEL"}"

اب آپ کو دیکھنا چاہئے "replayed":trueاور سودا id پہلی منتقلی سے میل کھاتا ہے۔

اکاؤنٹ دوبارہ پڑھیں۔

curl -s localhost:4000/api/accounts/me -H "Authorization: Bearer $TOKEN"

چیک کریں

balance_cents یہ 4000 سے کم نہیں ہے، لیکن یہ آپ کے لکھے ہوئے نمبر سے 2000 کم ہے۔ اگر آپ نے اگلی بار شروع کیا۔ 94000اب میں سمجھ گیا ہوں۔ 92000.

اگر یہ ناکام ہوجاتا ہے:

• echo $TOKEN خالی: لاگ ان کمانڈ کو دوبارہ چلائیں۔

• دوسری منتقلی ظاہر ہوتی رہتی ہے۔ "replayed":false: LABEL دو ٹرانسمیشن کے درمیان تبدیل کر دیا گیا. چلائیں echo $LABELپھر اسے دوبارہ بھیجیں۔

• دونوں کی منتقلی نظر آتی ہے۔ "replayed":true: توازن تبدیل نہیں ہوگا۔ کچھ نیا منتخب کریں۔ LABEL پھر مرحلہ 3 اور 4 کو دہرائیں۔

مکمل ہونے پر:

• ایک ٹرانسفر واپس کر دیا گیا۔ "replayed":false اور پھر واپس آگیا "replayed":true اسی لیبل کے لیے

• balance_cents یہ 4000 نہیں بلکہ 2000 تک گر گیا۔

باب 4. Terraform کا استعمال کرتے ہوئے AWS سرورز بنانا

منگل 9:15 AM

مایا میٹنگ کے لیے جاتے وقت آپ کی میز کے پاس رک جاتی ہے۔ کل آپ نے کہا کہ ClearPay آپ کے لیپ ٹاپ پر چلتا ہے اور دوبارہ کوشش کرنے کی ادائیگی صرف ایک بار وصول کی جاتی ہے۔

مایا: "ٹھیک ہے، اب لوکل ہوسٹ کا سوال ہی نہیں ہے۔ AWS پر ClearPay انسٹال کریں اور ثابت کریں کہ آپ کے صارفین وہاں لین دین مکمل کر سکتے ہیں۔ پھر ہم AWS چھوڑنے کے بارے میں بات کر سکتے ہیں۔ ڈینیل آپ کے ساتھ اس پر کام کریں گے۔”

ڈینیئل اس کے ساتھ والی میز سے اپنی کرسی گھماتا ہے۔

ڈینیل: "ہم شروع کرنے سے پہلے، یہاں ایک اصول ہے: کچھ بھی نہ چھوڑیں۔ terraform plan"

یہ کیوں اہمیت رکھتا ہے۔

یہ کتاب اس سیٹ اپ سے شروع ہوتی ہے جسے بہت سی چھوٹی کمپنیاں چلاتی ہیں: ڈوکر کے بغیر ایک لینکس سرور۔

سسٹمڈ، لینکس سروس مینیجر، سرور کے بوٹ ہونے پر نوڈ API شروع کرتا ہے۔ nginx اس کے سامنے بیٹھتا ہے اور پورٹ 443 پر HTTPS کو ہینڈل کرتا ہے۔ PostgreSQL Amazon RDS پر چلتا ہے، ایک منظم ڈیٹا بیس سروس۔

کوئی AWS لوڈ بیلنس نہیں ہے۔ ایک لوڈ بیلنسر ٹریفک کو متعدد سرورز پر تقسیم کرتا ہے، اور اس سیٹ اپ میں ایک ہے۔ ایک کو شامل کرنے سے آپ کے فی گھنٹہ کے بل میں کوئی فائدہ نہیں ہوتا ہے۔ نمبرز پر ہیں۔ infra/aws/COST.md.

فائل api/Dockerfile یہ موجود ہے، لیکن میں اسے صرف لیپ ٹاپ پر استعمال کرتا ہوں۔ AWS سرورز Docker نہیں چلاتے۔

ڈینیئل: "EC2 سرور پر کوئی Docker نہیں ہے۔ systemd بوٹ کے وقت nginx کے ساتھ نوڈ شروع کرتا ہے۔ یہ وہ سرور ہے جسے آپ وراثت میں لے رہے ہیں۔”

اوپر دیا گیا خاکہ دکھاتا ہے کہ کسٹمر کی درخواستیں AWS سے ClearPay تک کیسے پہنچتی ہیں۔ لچکدار IP آپ کے EC2 سرورز کے لیے ایک مستحکم عوامی پتہ فراہم کرتا ہے۔ Nginx پورٹ 443 پر HTTPS ٹریفک کو ہینڈل کرتا ہے، فرنٹ اینڈ فائلوں کو پیش کرتا ہے، اور پورٹ 4000 پر systemd کے ذریعے نظم کردہ Node.js عمل کو API کی درخواستیں بھیجتا ہے۔ API Amazon RDS پر PostgreSQL سے بلنگ ڈیٹا پڑھتا اور لکھتا ہے، جس کا اس مرحلے پر کوئی عوامی اختتامی نقطہ نہیں ہے۔

اس باب میں AWS کی دو اصطلاحات ہیں:

• VPC ایک نجی نیٹ ورک ہے جہاں آپ کے سرور واقع ہیں۔ AWS ہر اکاؤنٹ کے لیے ڈیفالٹ اکاؤنٹ فراہم کرتا ہے۔ اس لیب میں ہم اسے خود بنانے کے بجائے استعمال کریں گے۔

• سیکورٹی گروپس AWS کی فائر والز ہیں۔ سرور سے مربوط ہونے کے لیے دستیاب بندرگاہیں درج ہیں۔ اس لیب کے لیے، ہم صرف IPs سے SSH، ہر جگہ سے HTTPS، اور API سرور سے صرف Postgres کی اجازت دیں گے۔

قدم

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

docker --version          # still needed later
aws sts get-caller-identity
terraform version         # 1.5 or newer
ssh-keygen -t ed25519 -f ~/.ssh/clearpay-deployer -N ""

aws sts get-caller-identity اپنا AWS اکاؤنٹ پرنٹ کریں۔ اگر کوئی غلطی ہو جائے تو چلائیں۔ aws configure IAM صارفین سے رسائی کی چابیاں استعمال کریں جو EC2، RDS، VPC، اور CloudWatch کے الارم بنا سکتے ہیں۔ ڈسپوزایبل اکاؤنٹس کے منتظمین بھی کام کرتے ہیں۔

ذخیرہ کی جڑ سے:

cd infra/aws/terraform
cp terraform.tfvars.example terraform.tfvars

کھلا terraform.tfvars دو قدروں کو تبدیل کریں:

پھر:

terraform init
terraform plan
terraform apply

داخل ہونے سے پہلے منصوبہ پڑھیں yes. اس پہلی دوڑ کے لیے، آپ کو صرف EC2، RDS، اور سیکیورٹی گروپس بنانے کی ضرورت ہے۔ اگر منصوبہ یہ بتاتا ہے کہ کچھ بھی تباہ ہو جائے گا، تو روکیں اور لاگو نہ کریں۔

ٹیرافارم اسی کے لیے بنایا گیا ہے۔ سرور باب 5 تک خالی ہے۔

خاکہ AWS انفراسٹرکچر دکھاتا ہے جسے Terraform تخلیق کرتا ہے: لچکدار IP کے ساتھ ایک EC2 Ubuntu سرور، SSH اور HTTPS رسائی کو کنٹرول کرنے والے سیکیورٹی گروپس، ایک RDS PostgreSQL ڈیٹا بیس جو صرف API سرور سے قابل رسائی ہے، اور CloudWatch ہیلتھ چیکس۔ دونوں وسائل پہلے سے طے شدہ VPC کے اندر ہیں۔ EC2 سرور اب بھی خالی ہے۔ باب 5 ClearPay کو یہاں تعینات کرتا ہے۔

اخراجات پر نوٹس: چونکہ AWS تمام عوامی IPv4 پتوں (AWS عوامی IPv4 کی شرحوں) کے لیے چارج کرتا ہے، لچکدار IP کی لاگت تقریباً $0.12 فی دن ہے، یہاں تک کہ جب سرور چل رہا ہو۔

چیک کریں

terraform output instance_public_ip

یہ آپ کا عوامی IPv4 ایڈریس پرنٹ کرے گا۔ اس طرح یہ سرور تک پہنچ جاتا ہے: روٹ 53 استعمال نہیں کیا جاتا ہے کیونکہ کسی ڈومین کی ضرورت نہیں ہے (manage_dns = false)۔

اگر یہ ناکام ہوجاتا ہے:

• Error: InvalidKeyPair.Duplicate: نامزد کلیدی جوڑا clearpay-deployer یہ اس AWS ریجن میں پچھلی کوشش سے پہلے ہی موجود ہے۔ AWS کنسول میں اسے حذف کریں یا اس کا نام تبدیل کریں۔ infra/aws/terraform/ec2.tf.

• Error: UnauthorizedOperation: AWS صارف کے پاس وسائل کی ایک قسم کی اجازت نہیں ہے۔ خرابی کارروائی کے نام کی وضاحت کرتی ہے۔ ایڈمنسٹریٹر کو مکمل رسائی دینے کے بجائے، وہ اجازتیں شامل کریں۔

فیصلہ

انفراسٹرکچر موجود ہے۔ ایک سرور جس پر کچھ نہیں چل رہا ہے وہ ابھی تک نہیں ہوا ہے۔ باب 5 پر جاری رکھیں۔

مکمل ہونے پر:

باب 5. AWS سرورز پر ClearPay تعینات کریں۔

منگل 1:40 PM

ٹیرافارم کی درخواست دوپہر کے کھانے سے پہلے مکمل کر لی گئی۔ AWS اب سرورز اور ڈیٹا بیس کی فہرست دیتا ہے، لیکن ابھی تک صارفین کی خدمت کے لیے کچھ بھی دستیاب نہیں ہے۔

ٹیرافارم نے ایک خالی سرور اور ڈیٹا بیس بنایا۔ صارفین کے لیے ابھی تک کوئی سروس دستیاب نہیں ہے۔

تعیناتی شروع کرنے کے لیے، ایک ٹرمینل کھولیں۔ دانیال ایک کرسی کھینچ کر آپ کے پاس بیٹھ گیا۔

ڈینیئل: "ٹیرافارم کو حتمی شکل دینا صرف ہمیں بتاتا ہے کہ سرور موجود ہے۔ آئیے سرور پر ایپ انسٹال کریں اور اصل درخواست بھیجیں۔”

یہ کیوں اہمیت رکھتا ہے۔

خالی سرور منتقلی کا ذریعہ نہیں ہے۔ باب 6 پوچھتا ہے کہ آیا حقیقی کسٹمر کی درخواستیں AWS پر کام کرتی ہیں۔ اس سوال کا جواب اس وقت تک نہیں دیا جائے گا جب تک آپ لاگ ان صفحہ اور API نہیں دیکھتے۔

قدم

ذخیرہ کی جڑ سے شروع کریں۔ اگر آپ اب بھی اندر ہیں۔ infra/aws/terraformچلائیں cd ../../.. پہلے

اپنے سرور پر Node، nginx، اور certbot انسٹال کرکے شروع کریں۔

cd infra/aws/deploy
INSTANCE_IP=$(terraform -chdir=../terraform output -raw instance_public_ip)
echo "$INSTANCE_IP"
# Write that IP down. A new terminal will not have INSTANCE_IP.

ssh -o StrictHostKeyChecking=accept-new 
  -i ~/.ssh/clearpay-deployer ubuntu@$INSTANCE_IP 'bash -s' < bootstrap.sh

آپ کو دیکھنا چاہئے == ClearPay AWS bootstrap ==اور چند منٹوں کے بعد apt-get حساب bootstrap.sh مختصر ہے۔ براہ کرم پڑھیں۔

مندرجہ ذیل لائن کے ساتھ آؤٹ پٹ ختم ہونے پر اقدامات نے کام کیا:

== Bootstrap complete ==
Node: v20.20.2
Self-signed TLS is in /etc/letsencrypt/live/clearpay, use curl -k.

نوڈ ورژن مختلف ہو سکتے ہیں۔ سے شروع ہونے والی لکیریں۔ debconf: unable to initialize frontend یہ بے ضرر ہے۔ یہ ظاہر ہوتا ہے کیونکہ SSH سیشن میں کوئی انٹرایکٹو اسکرین نہیں ہے۔ لائن + اور * OpenSSL میں خود دستخط شدہ سرٹیفکیٹ بنائیں۔

اگر آپ کو کوئی آؤٹ پٹ بالکل نظر نہیں آتا ہے، تو SSH منسلک نہیں ہے۔ ہو سکتا ہے کہ آپ کے گھر کا IP باب 4 سے بدل گیا ہو، اس لیے آپ کا سیکیورٹی گروپ اب بھی آپ کے پرانے IP کی اجازت دے گا۔ اپنا آئی پی چیک کریں۔ curl -s ifconfig.me; echoایک پلس ڈالو /32 کو terraform.tfvars پسند ssh_allowed_cidrچلائیں terraform apply کو infra/aws/terraformاور دوبارہ کوشش کریں۔

اگلا .env اپنی API کی ضروریات جمع کروائیں اور اپنی ایپ کو متعین کریں۔ ڈیٹا بیس URL Terraform سے آتا ہے۔ JWT خفیہ لاگ ان ٹوکن پر دستخط کرتا ہے اور نئے سرے سے تیار ہوتا ہے۔

DATABASE_URL=$(terraform -chdir=../terraform output -raw database_url)

cat > /tmp/clearpay.env </dev/null || echo local)
ROLLBACK_ACTIVE=false
PORT=4000
EOF

./deploy.sh "$INSTANCE_IP" ~/.ssh/clearpay-deployer /tmp/clearpay.env
rm /tmp/clearpay.env

deploy.sh React UI بنائیں اور اسے درج ذیل مقام پر کاپی کریں: /opt/clearpay-ui. API کو درج ذیل مقام پر کاپی کریں: /opt/clearpay-apiانسٹال کریں اور پیکیج لکھیں۔ .envسسٹمڈ سروس اور nginx کنفیگریشن انسٹال کریں یہاں سے: infra/aws/deploy/دونوں دوبارہ شروع کریں۔

اب ڈیٹا بیس اسکیما اور سیڈ ایلس اور باب کو لوڈ کریں۔ یہ کمانڈ آپ کے لیپ ٹاپ پر نہیں بلکہ سرور پر چلتی ہے۔ RDS کے پاس ابھی تک عوامی اختتامی نقطہ نہیں ہے (publicly_accessible = false کو infra/aws/terraform/rds.tf)، لہذا آپ کا لیپ ٹاپ اس تک رسائی حاصل نہیں کرسکتا۔

لیپ ٹاپ ڈیٹا بیس سے براہ راست نہیں جڑ سکتا۔ یہ ایک EC2 سرور کو بیچوان کے طور پر استعمال کرتا ہے۔

اوپر دیا گیا خاکہ ظاہر کرتا ہے کہ کیوں لیپ ٹاپ کسی نجی RDS ڈیٹا بیس سے براہ راست نہیں جڑ سکتا۔ EC2 سرور تک SSH رسائی کی اجازت ہے، اور سرور AWS نیٹ ورک کے اندر سے RDS سے جڑ سکتا ہے۔ لیپ ٹاپ سے ڈیٹا بیس تک براہ راست رسائی مسدود ہے۔ ڈیٹا بیس تک رسائی کے لیے EC2 سرور کو انٹری پوائنٹ کے طور پر استعمال کریں۔

ذیل میں ہر کمانڈ کا آغاز اس سے ہوتا ہے: ssh ... ubuntu@$INSTANCE_IP "...". یعنی، اپنے EC2 سرور میں لاگ ان ہوں اور وہاں سے حوالہ دیا ہوا حصہ چلائیں۔ تو psql بیج EC2 پر چلتا ہے، اور EC2 RDS سے بات کرتا ہے۔ آپ نتائج کو بعد میں اپنے براؤزر میں دیکھ سکتے ہیں۔ جب آپ ایلس کے طور پر لاگ ان ہوتے ہیں، تو EC2 RDS میں ایلس کا اکاؤنٹ پڑھتا ہے۔

scp -i ~/.ssh/clearpay-deployer ../../../db/schema.sql 
  ubuntu@$INSTANCE_IP:/tmp/schema.sql

ssh -i ~/.ssh/clearpay-deployer ubuntu@$INSTANCE_IP 
  "sudo apt-get install -y postgresql-client -qq && psql '$DATABASE_URL' -f /tmp/schema.sql"

ssh -i ~/.ssh/clearpay-deployer ubuntu@$INSTANCE_IP 
  "cd /opt/clearpay-api && sudo -u clearpay npm run seed"

بیج ایک جیسی رسم الخط ہے۔ اس بار میں RDS کو لکھ رہا ہوں۔

چیک کریں

ssh -i ~/.ssh/clearpay-deployer ubuntu@$INSTANCE_IP 'sudo systemctl is-active clearpay-api'

متوقع پیداوار: active.

پھر آپ کے لیپ ٹاپ پر:

curl -k https://$INSTANCE_IP/health

اسے تلاش کریں۔ "status":"ok" اور "platform":"aws". کہ -k جھنڈا curl کو خود دستخط شدہ سرٹیفکیٹ قبول کرنے کو کہتا ہے۔ bootstrap.sh بنایا

کھلا https:// آپ کے براؤزر میں۔ "محفوظ نہیں" وارننگ پر کلک کریں۔ تنبیہ خود دستخط شدہ سرٹیفکیٹس کے لیے ہوتی ہے۔ آپ کو وہی کلیئر پے لاگ ان نظر آنا چاہیے جو آپ کے لیپ ٹاپ پر ہے۔ درج ذیل اکاؤنٹ سے ایلس کے بطور لاگ ان ہوں: password123. ڈیش بورڈ اس کا بیلنس دکھاتا ہے اور served by aws/1.0.0.

ڈینیئل: "صحت کی جانچ مجھے صرف یہ بتاتی ہے کہ ایپ چل رہی ہے۔ میں اس بات کو یقینی بنانا چاہتا ہوں کہ بیس لائن کو لاگ کرنے سے پہلے اس آئی پی سے منتقلی ہو رہی ہے۔"

اپنے براؤزر سے Bob کو $20 بھیجیں۔

اگر یہ ناکام ہوجاتا ہے:

• systemctl is-active رپورٹ failed: SSH کنکشن اور عملدرآمد sudo journalctl -u clearpay-api -n 50. عام وجوہات ہیں۔ DATABASE_URL RDS سے مماثل نہیں ہے۔ کے ساتھ موازنہ کریں۔ terraform output database_urlکردار سے۔

• seed_failed کے ساتھ SELF_SIGNED_CERT_IN_CHAIN: psql چونکہ یہ پہلے ہی کام کر چکا ہے، ڈیٹا بیس ٹھیک ہے۔ نوڈ کا تازہ ترین ورژن pg لائبریری کے ناشتے sslmode=require مکمل سرٹیفکیٹ کی تصدیق کے ساتھ۔ موجودہ کاپی کریں۔ api/src/pgConfig.js، api/src/db.jsاور api/db/seed.js سرور پر دوبارہ شروع کریں clearpay-apiپھر صرف بیج کمانڈ کو دوبارہ چلائیں۔ مت بھاگو schema.sql دوبارہ

• nginx واپس آ گیا ہے۔ 502 Bad Gateway: nginx چل رہا ہے، لیکن اس کے پیچھے API نہیں چل رہا ہے۔ سب سے پہلے، اوپر سسٹمڈ اسٹیٹس چیک کریں۔

• یہ آپ کے براؤزر میں ظاہر ہوگا۔ Cannot GET /:nginx میں ابھی بھی صرف API کی ترتیب پرانی ہے۔ چلائیں ./deploy.sh "$INSTANCE_IP" ~/.ssh/clearpay-deployer تیسرا دعویٰ نہیں ہے۔ کہ .env یہ پہلے سے ہی سرور پر ہے۔ دوبارہ کبھی نہ بونا۔

• invalid credentials ایلس کے لیے: آپ کے براؤزر نے شاید محفوظ کردہ پاس ورڈ درج کیا ہے۔ باکس کو صاف کریں اور داخل کریں۔ password123براہ کرم دوبارہ کوشش کریں۔

مکمل ہونے پر:

• systemctl is-active clearpay-api پرنٹس active

• curl -k https://$INSTANCE_IP/health رپورٹ "status":"ok"

• میں نے اپنے براؤزر کے ذریعے اپنے AWS پتے پر $20 بھیجے۔

باب 6۔ AWS کی بنیادی تاریخ

بدھ صبح 10 بجے

مایا کو اس طرح کا پیغام بھیجیں: "صحت ٹھیک ہے اور ایلس ایلاسٹک آئی پی میں لاگ ان ہے۔" اس کا جواب ایک منٹ سے بھی کم وقت میں واپس آتا ہے۔

مایا: "ٹھیک ہے۔ اب اس آئی پی پر پانچ چیک چلائیں۔ براہ کرم مجھے ٹرمینل آؤٹ پٹ بھیجیں، اسکرین شاٹ نہیں۔"

دوسرا پیغام یہ ہے: "پھر ٹیسٹ لوڈ کریں اور مجھے p95 بھیجیں۔ میں GKE سے 'یہ کام کرتا ہے' کا موازنہ نہیں کرسکتا۔"

یہ کیوں اہمیت رکھتا ہے۔

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

1. یہ پاس پروموشن گیٹ سے ہے۔ پروموشن گیٹس مختصر اسکرپٹ ہیں۔ پانچ چیزوں کی جانچ کریں جو ہر پیمنٹ ایپ کو کرنی چاہیے: جانچ کریں کہ ایپ چل رہی ہے، ڈیٹا بیس سے منسلک ہو سکتی ہے، کیا صارف لاگ ان کر سکتے ہیں، صرف ایک بار بار بار ادائیگیاں کر رہے ہیں، اور مناسب رقم سے بیلنس کو کم کر رہے ہیں۔ اگر آپ تمام 5 پاس کرتے ہیں تو ایپ کام کرے گی۔

باب 15 میں، ہم اسی اسکرپٹ کو GKE پر چلاتے ہیں۔ اگر GKE وہی ٹیسٹ پاس کرتا ہے جو AWS پاس کرتا ہے، تو GKE کام کرے گا۔

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

جوتے تبدیل کرنے سے پہلے کسی رنر کے وقت کے بارے میں سوچئے۔ دوسرے کا مطلب پہلے کے بغیر کچھ نہیں۔ یہ باب پہلی بار لکھا گیا ہے۔

اس باب کا اسکرپٹ آپ کی نوٹ بک میں نوڈ کا استعمال کرتے ہوئے JSON کو پڑھتا ہے۔ اگر آپ نے ابھی تک Node.js 20 یا اس سے زیادہ انسٹال نہیں کیا ہے تو اسے ابھی انسٹال کریں۔

قدم

ذخیرہ کی جڑ سے شروع کریں۔ اگر آپ اب بھی اندر ہیں۔ infra/aws/deployچلائیں cd ../../.. پہلے

AWS کے لیے ایک پروموشنل گیٹ چلائیں۔

export INSTANCE_IP=$(terraform -chdir=infra/aws/terraform output -raw instance_public_ip)

./scripts/promotion-gate.sh https://$INSTANCE_IP 
  alice@clearpay.dev password123 bob@clearpay.dev

استعمال کریں https://. کے ساتھ http://ایسا لگتا ہے جیسے nginx ری ڈائریکٹ ہوتا ہے اور اسکرپٹ ہینگ ہوتا ہے۔

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

1. عمل شروع ہو چکا ہے (/health)۔

2. آپ ڈیٹا بیس تک رسائی حاصل کرسکتے ہیں (/health/ready)۔

3. ایلس لاگ ان کر سکتی ہے۔

4. ری سائیکل ادائیگی کی کلید واپس آ گئی ہے۔ replayed=true.

5. ایلس کا توازن ایک بار ختم ہو گیا۔

متوقع پیداوار:

PASS: health endpoint returns ok
PASS: readiness endpoint confirms DB connectivity
PASS: login succeeds and returns a token
PASS: replaying an idempotency key returns replayed=true
PASS: balance debited exactly once (100 cents), not twice

5 passed, 0 failed

GATE PASSED: safe to promote to production.

آخری لائن پیداوار کے بارے میں بات کرتی ہے۔ ابھی تک فروغ دینے کے لیے کوئی پروڈکشن نہیں ہے۔ یہ وہی اسکرپٹ ہے جسے آپ بعد میں GKE پر چلاتے ہیں۔ یہاں لائن سے مراد مواد ہے۔

اب ٹیسٹ AWS لوڈ کریں۔ اسکرپٹ لاگ ان ہوتا ہے اور اوپر نظر آتا ہے۔ /api/accounts/me اور /api/transactionsدونوں پوسٹگریس سے استفسار کرتے ہیں۔ ٹیسٹ لوڈ نہ کریں۔ /health. API کے جوابات /health بالکل اپنے طور پر۔ یہ ڈیٹا بیس سے کچھ نہیں پوچھتا ہے۔ حقیقی کسٹمر کی درخواستوں کے لیے ڈیٹا بیس سے استفسار کرنے اور جواب کا انتظار کرنے کی ضرورت ہوتی ہے، اور انتظار کا وقت عام طور پر ہوتا ہے:

/health                  laptop → API → reply                    (fast, no database)
/api/accounts/me         laptop → API → database → API → reply   (the real work)

لوڈ ٹیسٹ /health وقت صرف نصف ہے. اسٹور کے ملازم سے پوچھیں، "کیا آپ کھلے ہیں؟" بمقابلہ "کیا آپ کے پاس یہ جوتے 42 سائز کے ہیں؟" صرف دوسرا سوال انہیں گودام تک چلنے پر مجبور کرتا ہے۔

./scripts/load-test.sh https://$INSTANCE_IP 
  alice@clearpay.dev password123 10 30

آخری دو نمبر کنکرنسی (ایک وقت میں 10 درخواستیں) اور دورانیہ (30 سیکنڈ) ہیں۔

چیک کریں

اسکرپٹ ایک سکور کارڈ پرنٹ کرتا ہے۔ لیبارٹری نے جو پرنٹ کیا وہ یہ ہے:

== DB load test: https://184.194.120.157  concurrency=10  duration=30s ==
Endpoints: GET /api/accounts/me  GET /api/transactions


ok=372  failed=0

Migration Scorecard, this run

p50 latency:          673 ms
p95 latency:          745 ms
p99 latency:          1326 ms
Throughput:           12.4 req/s
4xx rate:             0.0 %
5xx rate:             0.0 %
Transaction success:  100.0 %

آپ کا سکور کارڈ مختلف ہوگا۔ آپ کا IP پتہ، درخواستوں کی تعداد، اور ملی سیکنڈز آپ کے موجودہ مقام پر منحصر ہیں۔ لوڈ ٹیسٹ لیپ ٹاپ پر چلتے ہیں، لہذا تمام درخواستیں گھر سے AWS تک جاتی ہیں۔ us-east-1 اور واپس آگیا۔

خطے کے قریب قارئین دوسرے براعظموں کے مقابلے میں بہت کم تعداد دیکھتے ہیں۔ دونوں غلط نہیں ہیں۔ اہم بات یہ ہے کہ GKE کا موازنہ اسی مقام پر ماپے گئے اسکور کارڈز سے کریں۔

دیکھو تو بھاگتا ہوا گزر جاتا ہے۔ failed=0، 5xx rate کو 0.0 %اور Transaction success کو 100.0 %.

• p95 میں تاخیر کا مطلب ہے کہ 95% درخواستیں اس نمبر سے زیادہ تیزی سے مکمل ہو جاتی ہیں۔ یہ صارفین کے سست احساسات کو ظاہر کرتا ہے جو اوسط چھپاتے ہیں۔

• 4xx اس کا مطلب ہے کہ کلائنٹ نے ایک غلط درخواست بھیجی ہے، جیسے کہ گمشدہ ٹوکن۔

• 5xx اس کا مطلب ہے کہ سرور ناکام ہو گیا ہے۔

نوٹ فائل میں پرنٹ شدہ پورے سکور کارڈ کو کاپی کریں اور وہی بلاک مایا کو بھیجیں۔ اس کا جواب جلدی سے آیا۔ "چیزوں کو زیادہ صاف ستھرا بنانے کے لیے گول نہ بنائیں۔ آئیے اس صفحہ سے GKE کا موازنہ کریں۔"

ابھی حدیں طے کریں۔

اپنے سکور کارڈ کے نیچے نمبروں کے ساتھ درج ذیل دو لائنیں لکھیں۔

Outage:   5xx rate above 1 % for more than 2 minutes in a row
Failure:  p95 more than 3 times your AWS p95 for more than 5 minutes in a row

چونکہ ہر قاری کے معیارات مختلف ہوتے ہیں، اس لیے ناکامی کی حد اپنی AWS p95 استعمال کرتی ہے۔ اس مشق میں 745 ms پر، حد تقریباً 2,235 ms ہے۔ یہ ایک مثال کی حد ہے۔ اپنا چنیں، لیکن GKE موجود ہونے سے پہلے اسے ابھی کریں۔ GKE نمبرز کو دیکھنے کے بعد، جو حدود ہم سیٹ کرتے ہیں وہ حدیں ہیں جو ہم مماثل کرنے کے لیے موڑتے ہیں۔

اپنی لاگت کا لیجر ایک لائن سے شروع کریں۔

Cost ledger, entry 1:  AWS about $1.25/day (infra/aws/COST.md)

اگر یہ ناکام ہوجاتا ہے:

تمام پانچ چیک پاس ہونے تک یہاں رہیں۔ ہجرت کے دوران جو مسائل پیدا ہوتے ہیں ان میں بعد میں دو بادل شامل ہوتے ہیں اور انہیں تلاش کرنا زیادہ مشکل ہوتا ہے۔

فیصلہ

دروازہ گزر چکا ہے۔ یہ EC2 سرور بنیادی لائن ہے۔ اس کتاب میں GKE کے تمام اعداد و شمار کا موازنہ اس سکور کارڈ سے کیا گیا ہے۔

ایک منٹ بعد، مایا نے ایک اور لائن کا اضافہ کیا۔ "اچھا۔ اب یہ میرا فون نمبر ہے۔"

مکمل ہونے پر:

• گیٹ پرنٹ ہے۔ 5 passed, 0 failed AWS IPs کے بارے میں

• لوڈ ٹیسٹ پرنٹ کیا گیا۔ failed=0اسکور کارڈ نوٹوں میں ہے۔

• ڈاؤن ٹائم اور ناکامی کی حدیں عددی طور پر ریکارڈ کی جاتی ہیں۔

حصہ 2۔ حرکت کی منصوبہ بندی کیسے کریں۔

مایا کو بتاؤ کہ گیٹ گزر گیا اور اسے اسکور کارڈ بھیج دو۔

وہ جواب دیتی ہے: "اگلی چیز GKE ہے۔ ہمیں وہاں اپنے APIs کو چلانے کی ضرورت ہے، اور ہمارے صارفین کو اس وقت ہمیں رقم بھیجنے کی ضرورت ہے جب ہم چل رہے ہوں۔ AWS پر پوسٹگریس چھوڑ دیں۔ ڈیٹا بیس اس چیلنج کا حصہ نہیں ہیں۔"

کوئی بادل اس حصے تک نہیں پہنچتا۔ آپ پڑھیں، آپ نقشہ کریں، آپ فیصلہ کریں۔

باب 7۔ نقل مکانی کے چیلنجز پڑھیں

بدھ شام 4 بجے

مایا سب سے اوپر ایک لائن شامل کرکے چیلنج کا اظہار کرتی ہے: "Terraform کھولنے سے پہلے سب کچھ پڑھیں۔"

چیلنج: ClearPay API کو AWS EC2 سے GKE میں منتقل کریں۔

ClearPay ایک EC2 سرور پر چلتا ہے۔ یہ کام کرتا ہے، لیکن اس میں آٹو اسکیلنگ، مرحلہ وار رول آؤٹ، اور تعیناتی کے عمل کا فقدان ہے جو سب ایک شخص کے سر ہے۔ ہم نے خود عمل کو باب 5 میں چلایا، تاکہ آپ دیکھ سکیں کہ کیا غائب ہے۔

انٹرپرائزز کوبرنیٹس میں اسٹیجنگ ماحول، خودکار تعیناتیاں، اور APIs کو بڑھنے کی گنجائش کے ساتھ چاہتے ہیں۔ ایک بار پھر، ڈیٹا بیس اس مختص کا حصہ نہیں ہے۔

موجودہ فن تعمیر

ClearPay چار ڈیفالٹ VPCs (ایک EC2 سرور اور ایک RDS ڈیٹا بیس) میں ایک AWS اکاؤنٹ میں رہتا ہے۔

ایسی چیز جسے تبدیل نہیں کیا جا سکتا

• ڈیٹا بیس پوسٹگریس اقدام مستقبل کا ایک الگ منصوبہ ہے۔

• API معاہدہ۔ وہی راستہ وہی JSON لوٹاتا ہے۔ /health، /api/auth/login، /api/transactions. کوئی بھی براؤزر یا اسکرپٹ جو AWS پر کام کرتا ہے اسے بغیر کسی تبدیلی کے GKE پر کام کرنا چاہیے۔

• گاہک کو کسی بھی مقام پر کسی بھی مسلسل رکاوٹ کا سامنا نہیں کرنا پڑے گا۔

قبولیت کا معیار

مکمل مطلب:

1. GKE تمام پروڈکشن ٹریفک کو ہینڈل کرتا ہے اور اچھوت رہتا ہے۔ غلطیاں اور تاخیر باب 6 میں لکھی گئی حدود کے اندر ہیں۔

2. جب تک AWS موجود ہے AWS میں رول بیکس کام کرتے رہیں گے۔

3. پھر، GKE ثابت ہونے کے بعد، ہم اسے AWS سے ریٹائر کر دیتے ہیں۔

کیا حرکت کرتا ہے اور کیا رہتا ہے:

خاکہ AWS سے GCP میں منتقلی کو ظاہر کرتا ہے۔ ClearPay UI اور API Google Kubernetes Engine (GKE) میں منتقل ہوتے ہیں جس میں EC2 سرورز پر اسٹیجنگ اور پروڈکشن چلتی ہے۔ PostgreSQL AWS پر Amazon RDS میں رہتا ہے، لہذا دونوں ماحول منتقلی کے دوران ایک ہی ڈیٹا بیس کا استعمال کرتے ہیں۔

پوری کتاب ایک ہی راستے پر چلتی ہے۔

AWS only  →  AWS and GKE together  →  GKE only, then EC2 gone

درمیانی مراحل میں، کام کیا جاتا ہے. دونوں کلاؤڈ ایک ہی ایپس چلاتے ہیں اور ایک ہی ڈیٹا بیس کے ساتھ بات چیت کرتے ہیں، اور ٹریفک ان کے درمیان چھوٹے قدموں میں حرکت کرتی ہے۔

ٹریفک کیسے چلتی ہے۔

فی الحال، صارفین ایک لچکدار IP داخل کرتے ہیں اور تمام درخواستیں AWS کو جاتی ہیں۔

1. اگر آپ گوگل لوڈ بیلنسر کو سامنے رکھتے ہیں، تو آپ کے گاہک ایک بار اس پتے پر جائیں گے۔ آپ اس ایڈریس کو بقیہ منتقلی کے لیے استعمال کرتے رہیں گے۔

2. لوڈ بیلنسر پھر کچھ درخواستیں AWS اور دیگر کو GKE کو بھیجتا ہے۔ سے شروع ہوتا ہے۔ 100% AWS اور 0% GKE.

3. براہ راست استعمال کرتے ہوئے GKE شیئر میں اضافہ کریں: scripts/shift-traffic.shایک وقت میں چند قدم اٹھائیں، ہر قدم پر نمبر چیک کریں۔

4. اگر آپ کو GKE میں پریشانی ہو رہی ہے تو بھیجیں: 100% ٹریفک AWS پر واپس آتی ہے۔ کے ساتھ shift-traffic.sh 100 0. رول بیک میں چند سیکنڈ لگتے ہیں۔

اوپر کا خاکہ دکھاتا ہے کہ کس طرح گاہک منتقلی کے دوران ایک عوامی پتے کے ذریعے ClearPay سے جڑیں گے جبکہ UI اور API AWS اور GKE دونوں پر چل رہے ہیں۔ دونوں ماحول AWS پر Amazon RDS پر ایک ہی PostgreSQL ڈیٹا بیس سے جڑتے ہیں۔ اپنے ڈیٹا بیس کو ایک جگہ پر رکھنا آپ کی درخواست کے ساتھ ادائیگی کے ڈیٹا کو منتقل ہونے سے روکتا ہے۔

ٹریفک کو تقسیم کرنے کے لیے DNS استعمال کرنے کے بارے میں کیا خیال ہے؟ DNS ایک تلاش ہے جو ناموں کو IP پتوں میں بدل دیتی ہے۔ آپ کا لیپ ٹاپ اور انٹرنیٹ فراہم کنندہ جوابات کو کیش کرتا ہے۔

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

رول بیک کے تقاضے

آپ کی منتقلی کے ہر مرحلے پر، 100% AWS پر واپسی تیز اور محفوظ ہونی چاہیے۔ یہ دوبارہ تقسیم نہیں ہے۔ یہ کوئی ڈی این ایس تبدیلی نہیں ہے جس کو پھیلانے میں ایک گھنٹہ لگتا ہے۔ باب 20 پہلی شفٹ سے پہلے بالکل اس کی جانچ کرتا ہے۔

یہاں "زیرو ڈاؤن ٹائم" کا کیا مطلب ہے۔

اس کا مطلب یہ نہیں ہے کہ کوئی بھی ناکام درخواستیں نہیں ہوں گی۔ کوئی حقیقی نظام اس کا وعدہ نہیں کر سکتا۔

اس کا مطلب ہے کہ کسی بھی صارف کو جاری بندش کا سامنا نہیں کرنا پڑے گا۔ چند ناکام درخواستوں کی اجازت ہے جب تک کہ وہ باب 6 میں لکھی گئی حدود میں رہیں۔

APIs پہلے کیوں منتقل ہوتے ہیں۔

اگر آپ کا API اور ڈیٹا بیس ایک ساتھ چلتے ہیں اور کچھ غلط ہو جاتا ہے، تو غلطی ایک یا دوسرے میں ہوسکتی ہے، یا ان کے تعامل کے طریقے میں۔ صرف API کو منتقل کرنے سے سوال چھوٹا ہوجاتا ہے۔ کیا یہ API صارفین کو نقصان پہنچائے بغیر GKE پر چل سکتا ہے؟

یہ ایک قابل جواب سوال ہے۔ "کیا ہم محفوظ طریقے سے سب کچھ ایک ساتھ منتقل کر سکتے ہیں؟" جواب دینا بہت مشکل ہے اور لائیو ڈیبگ کرنا بہت برا ہے۔

ڈیٹا بیس کو AWS پر کیوں رکھا جاتا ہے۔

باب 13 ظاہر کرتا ہے کہ کلاؤڈ ٹو کلاؤڈ کنیکٹوٹی کیا ہے۔ PostgreSQL اس وقت اس پروجیکٹ سے آگے نہیں بڑھ رہا ہے۔

مستقبل میں ایک الگ پروجیکٹ ممکنہ طور پر گوگل کی ڈیٹا بیس مائیگریشن سروس، مسلسل نقل، اور اس کے اپنے کٹ اوور کے ذریعے اس کو سنبھالے گا۔ پروجیکٹ GKE پر ایک API اور AWS پر ایک ڈیٹا بیس کے ساتھ ختم ہوگا۔ یہ ایک منصوبہ ہے، نامکمل اختتام نہیں۔

دو بادلوں کو بیک وقت چلانے کی ضرورت کیوں؟

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

GCP استعمال کرنے سے پہلے اپنا مائیگریشن بجٹ سیٹ کریں۔

یہ اب باب 9 سے پہلے کریں۔ نوٹ پیڈ پر چار نمبر لکھیں۔ وہ فیصلہ کرتے ہیں کہ اس کارروائی پر کتنی لاگت آئے گی۔

اپنے اخراجات کی منصوبہ بندی جس طرح سے آپ اپنے سفری بجٹ کی منصوبہ بندی کرتے ہیں۔

1. فی الحال AWS کی قیمت کتنی ہے؟ تقریباً $1.25 فی دن سے شروع ہو رہا ہے۔ infra/aws/COST.md.

2. GCP کی روزانہ کی قیمت کیا ہے؟ تم ابھی تک نہیں جانتے۔ "TBD" (TBD) لکھیں۔ باب 9 اس سے خطاب کرتا ہے۔ infra/gcp/COST.md اس کی قیمت تقریباً $1.60 سے $5 فی دن ہے۔

3. جب دونوں بادل چل رہے ہیں تو حرکت کرنے کی قیمت کیا ہے؟ منتقل کرتے وقت AWS اور GCP کے لیے بیک وقت ادائیگی کریں۔ اس کی لاگت روزانہ $1.25 ہے، نیز GCP یومیہ لاگت۔

4. آپ کا بجٹ. یہ زیادہ سے زیادہ رقم ہے جو آپ پوری حرکت پر خرچ کریں گے۔ اپنے پیسے خرچ کرنے سے پہلے ابھی اپنا انتخاب کریں۔

اس لیب کے اعداد و شمار:

Current AWS cost:   $1.25/day
Expected GCP cost:  about $3/day (Chapter 9 checks this)
Dual-run cost:      $1.25 + $3 = $4.25/day while both run
Migration budget:   5 days × $4.25 = about $21. Round up to $25.

چلتے چلتے مجموعی طور پر چلتے رہیں۔ ابواب 19-25 اصل دوہرے عملدرآمد کی تاریخیں شامل کرتے ہیں۔ باب 28 ایک سوال پوچھتا ہے۔ کیا آپ کا بجٹ زیادہ ہے؟ مثال کے طور پر، اگر رول بیک کی وجہ سے کسی اقدام میں زیادہ وقت لگتا ہے، تو کل بالکل وہی لاگت ظاہر کرے گا۔

ہجرت کے مراحل

مکمل ہونے پر:

• آپ مایا کو دو جملوں میں سمجھا سکتے ہیں کہ کیا حرکت کرتا ہے، کیا رہتا ہے، اور غلط اقدامات کو کیسے کالعدم کیا جائے۔

باب 8۔ جانیں کہ کلیئر پے کس چیز پر انحصار کرتا ہے۔

جمعرات صبح 9 بجے

اس سے پہلے کہ کوئی بھی GKE کے ساتھ شروع کرے، ٹیم کو اس بارے میں تحریری رہنمائی کی ضرورت ہے کہ ClearPay کیا استعمال کرتا ہے۔ یہ نظام منگل سے دستی طور پر کام کر رہا ہے۔ کاغذ یہ نہیں دکھاتا ہے کہ آپ چلتے پھرتے کام کرتے رہنے کی کیا ضرورت ہے۔

مایا: "اس سے پہلے کہ آپ ایک اور بادل بنائیں، یہ لکھیں کہ یہ نظام کس چیز پر منحصر ہے۔"

یہ کیوں اہمیت رکھتا ہے۔

رہنمائی کے بغیر ہجرت کا مطلب ہے غلط چیزوں کو منتقل کرنا یا تبدیلی کے دن اہم چیزوں کو غائب کرنا۔ ذیل میں ہر سوال کا جواب میموری کی بجائے اسٹوریج سے دیں۔

1. کیا آپ کی ایپ کنٹینر کے لیے تیار ہے؟

ہاں api/Dockerfile ہم باب 1 سے اس پر کام کر رہے ہیں۔ آپ کا کردار کیسے بدلا ہے؟ یہ میرے لیپ ٹاپ پر آسان تھا۔ یہ وہی ہے جو GKE پر پیداوار میں چلتا ہے۔

2. راز کہاں ہے؟

کھلا infra/aws/deploy/systemd/clearpay-api.service. لوڈ کیا جائے گا EnvironmentFile=/opt/clearpay-api/.env. وہ فائل Git میں موجود نہیں ہے۔ EC2 سرور پر واقع ہے، deploy.sh باب 5 سے نقل کیا گیا ہے۔

API کو درکار تمام راز ایک سرور پر ایک سادہ ٹیکسٹ فائل میں ہیں۔ براہ کرم اس کا حوالہ دیں۔ چھپنے کے راز نہ کھولیں۔ اس کے بجائے، GKE گوگل سیکریٹ مینیجر سے وہی قدر پڑھتا ہے۔

3. آپ کن بیرونی نظاموں کو کال کر رہے ہیں؟

ایک: PostgreSQL۔ کنکشن آپ کے AWS ڈیفالٹ VPC کے اندر رہتا ہے، اور RDS کا کوئی عوامی اختتامی نقطہ نہیں ہے۔ کوئی تھرڈ پارٹی APIs نہیں ہیں۔ براہ کرم پڑھیں اور چیک کریں۔ api/src/.

4. کیا سرور درخواستوں کے درمیان صارف کو یاد رکھتا ہے؟

نہیں کھلا api/src/index.js اور api/src/routes/transactions.js. ہر درخواست میں ایک دستخط شدہ لاگ ان ٹوکن (JWT) ہوتا ہے اور اکاؤنٹ کا تمام ڈیٹا پوسٹگریس میں رہتا ہے۔ سرور میموری میں کچھ نہیں رکھتا ہے۔

یہی وجہ ہے کہ AWS اور GKE بعد میں درخواست کو تقسیم کر سکتے ہیں۔ چونکہ دونوں کلاؤڈز ایک ہی ٹوکن پاس ورڈ کی تصدیق کرتے ہیں اور ایک ہی ڈیٹا بیس کو پڑھتے ہیں، اس لیے صارف AWS میں لاگ ان کر کے GKE میں رقم بھیج سکتے ہیں۔

5. کیا میں دو بار دوبارہ کوشش کی درخواست کر سکتا ہوں؟

نہیں باب 3 نے یہ ثابت کر دیا کہ یہ بنیادی کام ہے۔ اسے تب بھی کام کرنا چاہیے جب پہلی کوشش AWS سے ٹکرا جائے اور دوبارہ کوشش GKE سے ٹکرا جائے۔

نقشہ

مندرجہ ذیل پانچ جوابات اپنے نوٹس میں لکھیں۔

Container ready:   yes, api/Dockerfile
Secrets:           one .env file on the EC2 server
Outside systems:   PostgreSQL only
Server state:      none, JWT + database
Retry safety:      idempotency key, proven in Chapter 3

اصل میں کیا منتقل کرنا ہے۔

صرف UI اور API: EC2 سرور سے GKE۔ پوسٹگریس AWS پر باقی ہے۔

براؤزر اور اسکرپٹ اب بھی ایک ہی URL کو مارتے ہیں اور وہی JSON واپس حاصل کرتے ہیں۔ پھر بھی دوبارہ کوشش کرنا آپ کو دوگنا خرچ نہیں کرنا چاہئے۔ اصول تبدیل نہیں ہوتے۔

کب مکمل کرنا ہے۔

• پانچوں جوابات ریکارڈ کیے گئے ہیں، ہر ایک فائل کی طرف اشارہ کرتا ہے۔

باب 9۔ جی سی پی ڈیزائن کو سمجھنا

جمعرات 2:30 PM

گوگل کلاؤڈ کے لیے ٹیرافارم پہلے ہی لکھا جا چکا ہے۔ آپ کے شامل ہونے سے پہلے کسی نے دو بڑے فیصلے کیے تھے۔ مایا جاننا چاہتی ہے کہ کیا آپ ان کا دفاع کر سکتے ہیں۔ وہ ٹیم چینل کے لیے لکھتی ہیں۔

مایا: "اسے کھولو۔ infra/gcp/COST.md اور infra/gcp/terraform/03-gke. پھر براہ کرم مجھے بتائیں کہ یہ ذخیرہ GKE سٹینڈرڈ کیوں استعمال کرتا ہے نہ کہ آٹو پائلٹ۔ "مجھے ایک وجہ کی ضرورت ہے جس کا میں دفاع کر سکوں۔"

ڈینیل میرے پاس میز پر بیٹھا ہے۔ infra/gcp/terraform/03-gke/main.tf کھلا وہ ایک بلاک کی طرف اشارہ کرتا ہے جس پر ایک نام ہے۔ primary. نوڈ پول ورچوئل مشینوں کا ایک گروپ ہے جس پر GKE آپ کی ایپس چلاتا ہے۔ اس میں 1 سے 3 ٹکڑے ہوتے ہیں۔ e2-medium مشین

ڈینیئل: "اگر میں اس مشین کو رکھتا ہوں، تو میں ایک وقت میں API کی کتنی کاپیاں چلا سکتا ہوں؟"

ہم اس باب میں Terraform نہیں چلائیں گے۔ فائل پہلے ہی بن چکی ہے۔ آپ نے فیصلہ پڑھ لیا ہے۔

معیاری یا آٹو پائلٹ

GKE گوگل کے زیر انتظام Kubernetes ہے۔ یہ دو طریقوں میں چلتا ہے:

• معیاری: نوڈ پول میں گروپ کردہ ورچوئل مشینیں منتخب کریں۔ گوگل آپ کے کمپیوٹر کو چارج کرتا ہے اس سے قطع نظر کہ ایپ استعمال میں ہے یا غیر فعال ہے۔

• آٹو پائلٹ: گوگل اپنی مشینوں کو چھپاتا ہے۔ آپ ہمیں بتاتے ہیں کہ آپ کو ہر کنٹینر کے لیے کتنے CPU اور میموری کی ضرورت ہے، اور Google آپ سے وہ رقم وصول کرتا ہے۔

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

دونوں اخراجات خود پورا کریں۔ معیاری چارج مشین. ایک e2-medium چلانے کے پورے دن کی قیمت تقریباً $1.44 ہے۔ infra/gcp/COST.mdCloud NAT بھی شامل ہے۔

CPU اور میموری کے لیے آٹو پائلٹ چارجز ہر پوڈ کے ذریعے محفوظ ہیں۔ k8s/base/deployment.yaml ریزرو فنڈ 250m سی پی یو (1 سی پی یو کور کا 1/4) اور 256Mi میموری فی API پوڈ۔ آٹو پائلٹ ریٹ استعمال کریں۔ infra/gcp/COST.mdتین API پوڈز کی قیمت تقریباً ہے:

0.25 vCPU × 3 × $0.0445/hour × 24  ≈  $0.80 / day
0.25 GiB  × 3 × $0.0049/hour × 24  ≈  $0.09 / day

UI پوڈ سے پہلے 3 API پوڈز کے لیے تقریباً $0.89 فی دن۔ آٹو پائلٹ کی قیمت ایک معیاری نظام سے کم ہو سکتی ہے۔ ہماری لیب میں، ہم اب بھی معیاری استعمال کر رہے ہیں، لہذا ہم نوڈ پولز کو دیکھ سکتے ہیں۔

پلیز مایا کو سارے نمبر بتا دیں اور کیوں؟

API کے عمل کی تعداد

AWS ایک API عمل چلاتا ہے۔ GKE میں، HorizontalPodAutoscaler (HPA) CPU کے استعمال کی بنیاد پر API Pods کو شامل یا ہٹاتا ہے۔ ہر پوڈ 10 ڈیٹا بیس کنکشن کے اپنے پول کے ساتھ ایک API عمل ہے۔

اس لیب میں کلسٹرز تین چھوٹے کلسٹرز ہیں۔ e2-medium مشین پیداوار HPA k8s/overlays/production/patch-hpa.yaml 1 اور 3 API pods کے درمیان چلتا ہے۔ کیونکہ اس سائز کی 3 مشینیں GKE کے اپنے سسٹم پوڈ کے ساتھ مزید فٹ نہیں ہو سکتیں۔

دانیال جواب دو۔ "میرے پاس GKE پر 1-3 API پوڈز ہیں اور 1 AWS پر جبکہ دونوں چل رہے ہیں۔ ہر ایک کے پاس 10 کنکشن کھلے ہو سکتے ہیں۔"

بڑی مشینوں والی کمپنیاں زیادہ حدیں مقرر کرتی ہیں، جیسے کہ تین سے آٹھ پوڈز۔ باب 22 دکھاتا ہے کہ ٹریفک کو منتقل کرنے سے پہلے آپ کو ڈیٹا بیس کی حدود کے خلاف اپنی حدود کو کیوں چیک کرنا چاہئے۔

ڈیزائن کردہ نیٹ ورک

AWS میں، اس لیب نے AWS کے ذریعے تخلیق کردہ ڈیفالٹ VPC استعمال کیا۔ اسے کسی نے ڈیزائن نہیں کیا۔

جی سی پی میں infra/gcp/terraform/02-network نامزد سب نیٹس اور کلاؤڈ NAT کے ساتھ اپنا VPC بنائیں۔ کلسٹر میں مشینیں صرف نجی پتے حاصل کرتی ہیں۔ وہ Cloud NAT کے ذریعے انٹرنیٹ سے اور بعد میں AWS ڈیٹا بیس سے جڑے ہوئے ہیں، جس سے ہر ایک کو ایک مشترکہ عوامی IP ملتا ہے۔

علاقہ

01-foundation/variables.tf اپنے علاقے کو اس پر سیٹ کریں: us-east4AWS کے قریب ترین گوگل کا علاقہ us-east-1. GKE میں ڈیٹا بیس کے تمام سوالات دو بادلوں کے درمیان ہوتے ہیں، اس لیے کم فاصلے کے نتیجے میں سفر کا وقت کم ہوتا ہے۔ اگر آپ کی AWS ترتیبات اس میں موجود نہیں ہیں: us-east-1کچھ بھی بنانے سے پہلے اسے تبدیل کریں۔

نقشہ

بائیں وہ ہے جو موجود ہے۔ دائیں طرف والا حصہ حصہ 3 میں بنایا گیا حصہ ہے۔

مندرجہ بالا خاکہ AWS سے GCP میں منتقلی کا نقشہ بناتا ہے۔ صارفین ایک عوامی پتہ استعمال کرتے ہیں جس کا انتظام ایک GCP لوڈ بیلنسر کرتا ہے جو موجودہ AWS EC2 سرورز اور GKE کے درمیان ٹریفک کو تقسیم کرتا ہے۔ GKE نجی نوڈس پر UI اور API چلاتا ہے، اور Cloud NAT آؤٹ باؤنڈ انٹرنیٹ تک رسائی فراہم کرتا ہے۔ دونوں ماحول AWS پر ایک ہی PostgreSQL ڈیٹا بیس سے جڑتے ہیں۔ ٹریفک دھیرے دھیرے GKE میں منتقل ہوتا ہے جبکہ ڈیٹا بیس برقرار رہتا ہے۔

آپ کو درج ذیل ترتیب میں تین عوامی IP پتوں کا سامنا کرنا پڑے گا:

1. لچکدار IP یہ ایک EC2 سرور ہے۔ آج کل صارفین اسے استعمال کرتے ہیں۔

2. GKE گیٹ وے IP۔ لوڈ بیلنسر GKE کے ٹریفک کے حصے کو لوڈ بیلنسر کی طرف لے جاتا ہے۔ گاہک کبھی بھی کچھ داخل نہیں کرتے ہیں۔

3. لوڈ بیلنسر IP 08-edge. ایک بار جب گاہک اس پتے پر چلا جاتا ہے، اس کے بعد ٹریفک کی تقسیم ہوتی ہے۔

AWS کو کب روکنا ہے۔

حصہ 3 میں، آپ کو ہر منٹ AWS چلانے کی ضرورت نہیں ہے۔ آپ کو ابواب 11 (ڈیٹا بیس یو آر ایل کو سیکرٹ مینیجر میں کاپی کرنے کے لیے) اور باب 13 (ڈیٹا بیس کو GKE میں کھولنے کے لیے) میں دوبارہ AWS کی ضرورت ہوگی۔

EC2 سرور کو نہ روکیں، RDS کو چلتے رہنے دیں۔ RDS آپ کے یومیہ AWS بل کا زیادہ تر حصہ رکھتا ہے، روکا ہوا RDS 7 دنوں کے بعد خود بخود دوبارہ شروع ہو جاتا ہے اور لچکدار IPs کا بل کسی بھی طرح سے ادا کیا جاتا ہے۔

اگر آپ ایک یا دو دن میں جاری رکھنا چاہتے ہیں تو AWS کو اکیلا چھوڑ دیں۔ اگر یہ کچھ دن رک جائے تو اسے تلف کر دیں۔

cd infra/aws/terraform && terraform destroy

واپس آنے کے لیے دوڑو terraform apply اسے اس فولڈر میں رکھیں اور باب 5 دہرائیں۔ نئے لچکدار IPs اور نئے DATABASE_URL. آپ کے چھ کارڈ کے اسکور کارڈ کو اب بھی بنیادی لائن سمجھا جاتا ہے۔

مکمل ہونے پر:

• ہم نے مایا کو معیاری اور آٹو پائلٹ کے لیے اپنے روزانہ نمبر دیے اور ہم اپنی لیب میں اسٹینڈرڈ کیوں استعمال کرتے ہیں۔

• ہم نے ڈینیئل کو بتایا کہ وہ کتنے API عمل چلا سکتا ہے اور ہر عمل کتنے کنکشن کھول سکتا ہے۔

حصہ 3۔ ٹیرافارم کا استعمال کرتے ہوئے گوگل کلاؤڈ کیسے بنایا جائے۔

میرے پاس کام کرنے والی AWS ایپ اور سکور کارڈ ہے۔ گوگل کلاؤڈ ابھی تک سیٹ اپ نہیں ہوا ہے۔ کوئی نیٹ ورک، کلسٹر، یا رجسٹری نہیں ہے جب تک کہ آپ اسے تعینات نہیں کرتے ہیں۔

UI اور API بعد میں اس کلسٹر پر چلیں گے۔ پوسٹگریس AWS پر باقی ہے۔
لہذا ترتیب یہ ہے کہ پہلے GCP میں ایک خالی جگہ بنائیں، پھر وہاں اپنی ایپ رکھیں، اور پھر ایپ کو سکھائیں کہ انٹرنیٹ پر RDS سے کیسے جڑا جائے۔

یہ حصہ صرف ایک خالی جگہ ہے۔ گاہک ابھی تک منتقل نہیں ہوا ہے۔

باب 10۔ ترتیب gcloud اور ایک پروجیکٹ منتخب کریں۔

جمعہ، صبح 8:45 بجے

گوگل کلاؤڈ ایک خالی صفحہ ہے۔ اس سے پہلے کہ آپ کچھ بھی بنا سکیں، آپ کے لیپ ٹاپ کو یہ جاننے کی ضرورت ہے کہ آپ کون سا پروجیکٹ بنا رہے ہیں اور آپ کون ہیں۔

حاصل کریں gcloud، kubectlTerraform نے دعوی کے ساتھ درست گوگل پروجیکٹ کی طرف اشارہ کیا۔

قدم

gcloud گوگل کلاؤڈ کمانڈ لائن ٹولز۔ انسٹال کرنے کے بعد، ٹرمینل بند کریں اور نیا ٹرمینل کھولیں۔

میک کے لیے:

brew install --cask google-cloud-sdk

Windows پر، Install Google Cloud CLI سے انسٹالر کو ڈاؤن لوڈ کرنے اور شامل کرنے کے لیے باکس کو چیک کریں۔ gcloud اپنے PATH پر جائیں اور Git Bash کو دوبارہ کھولیں۔ لینکس پر، اسی صفحہ پر لینکس ٹیب کی پیروی کریں۔ gcloud version آپ کو ایک ورژن پرنٹ کرنے کی ضرورت ہوگی۔

اگر kubectl version --client کے بعد ناکام gcloud آپریشن، تنصیب kubectl GKE میں لاگ ان کرنے کے لیے استعمال ہونے والا پلگ ان:

gcloud components install kubectl
gcloud components install gke-gcloud-auth-plugin

پلگ ان آپ کے PATH میں ہونا چاہیے۔ بعد میں kubectl get nodes کہتے ہیں gke-gcloud-auth-plugin not foundاسے چلائیں اور ایک نیا ٹرمینل کھولیں۔

echo 'export PATH="$(gcloud info --format="value(installation.sdk_root)")/bin:$PATH"' >> ~/.zshrc

وہ لائن zsh کے لیے ہے، پہلے سے طے شدہ میک شیل۔ باش کا استعمال کرتے ہوئے لینکس پر، درج ذیل کو تبدیل کریں: ~/.zshrc کو ~/.bashrc. ونڈوز پر، انسٹالر عام طور پر آپ کے لیے PATH کو ہینڈل کرتا ہے۔ انسٹالیشن کے بعد گٹ باش کو دوبارہ کھولیں۔

اب لاگ ان کریں اور اپنا پروجیکٹ منتخب کریں۔

gcloud auth login --update-adc
gcloud projects list
gcloud config set project YOUR_PROJECT_ID
gcloud billing projects describe YOUR_PROJECT_ID
terraform version
kubectl version --client

--update-adc یہ ضروری ہے۔ صاف gcloud auth login صرف gcloud براہ کرم اپنا اکاؤنٹ استعمال کریں۔ ٹیرافارم ایک الگ پروگرام ہے جو ایپلیکیشن ڈیفالٹ اسناد نامی فائل کو تلاش کرتا ہے۔ جھنڈا اس فائل کو اسی براؤزر لاگ ان پر لکھتا ہے۔ گوگل پیج پر اجازت دیں پر کلک کریں اور ٹیب کو جلد بند نہ کریں۔

استعمال کرنے کے لیے ID

gcloud projects list دو کالم پرنٹ کرتا ہے جو ایک جیسے نظر آتے ہیں۔

• NAME یہ ایک لیبل ہے اور بہت سے پروجیکٹس ڈیفالٹ لیبل کا اشتراک کرتے ہیں۔ My First Project.

• PROJECT_ID مثال کے طور پر، یہ منفرد ہے. my-first-project-123456.

کاپی PROJECT_IDیہ نام نہیں ہے۔ اسے چسپاں کریں جہاں کمانڈ کہتا ہے۔ YOUR_PROJECT_ID.

اگر آپ کے پاس متعدد پروجیکٹ ہیں، تو براہ کرم ایک کو منتخب کریں جس کے لیے آپ ادائیگی کر سکتے ہیں۔ چلائیں gcloud billing projects describe ہر ID کے ساتھ جب تک کہ آؤٹ پٹ پر مشتمل نہ ہو: billingEnabled: true.

آپ Google Cloud Console میں بھی اپنی ID تلاش کر سکتے ہیں۔ صفحہ کے اوپری حصے میں اپنے پروجیکٹ کے نام پر کلک کریں اور ID کالم پڑھیں۔

چیک کریں

gcloud config get-value project

یہ پروجیکٹ ID پرنٹ کرے گا۔ جب چھپی [None]پھانسی gcloud config set project دوبارہ آرڈر کریں۔

اگر یہ ناکام ہوجاتا ہے:

• Terraform بعد میں کہتا ہے: could not find default credentials: آپ بغیر کسی جھنڈے کے لاگ ان ہوئے۔ چلائیں:

gcloud auth application-default login

• حکم کہتا ہے۔ cloud-platform scope is required but not consented: آپ کے براؤزر کو اجازت دینے پر کلک کرنے سے پہلے بند کر دیا گیا تھا۔ چلائیں gcloud auth login --update-adc دوبارہ کلک کریں اور اجازت پر کلک کریں۔

آج صرف ہے gcloud لاگ ان کریں۔ نام api.clearpay.test آپ اسے بعد میں دیکھیں گے جب آپ مرحلہ 8 میں لوڈ بیلنسر بنائیں گے۔ تب تک، اسے چھوڑ دیں۔

مکمل ہونے پر:

• gcloud config get-value project پروجیکٹ ID پرنٹ کریں۔

• gcloud billing projects describe دکھائیں billingEnabled: true

• kubectl version --client پرنٹ ورژن

مایا پیغام: "جی کلاؤڈ لاگ ان ہے۔ پروجیکٹ سیٹ کر دیا گیا ہے۔ بلنگ شروع کر دی گئی ہے۔ جی سی پی شروع کرنے کے لیے تیار ہے۔"

مایا: "ایک وقت میں ایک اسٹیج بنائیں۔ مجھے بتائیں کہ جب ہر اسٹیج کی تصدیق ہوجائے۔ اگر میں ایک ہی وقت میں آٹھوں کو چلاتی ہوں اور تیسرا اسٹیج ٹوٹ جاتا ہے تو مجھے نہیں معلوم کہ کون سا اسٹیج ٹھیک کرنا ہے۔"

باب 11۔ 8 ٹیرافارم مراحل کے ساتھ جی سی پی کی تعمیر

صبح 10:30 بجے جمعہ سے مہینے کے دوسرے پیر تک

GCP آٹھ ٹیرافارم مراحل میں بنایا گیا تھا۔ ہر قدم ہدف کے ماحول کی ایک تہہ بناتا ہے۔

انہیں ترتیب سے چلائیں۔ ہر قدم کے بعد، اگلے مرحلے پر جانے سے پہلے نتائج کو چیک کریں۔

مائیگریشن کے گوگل سائیڈ کو بنانا: APIs، نیٹ ورکس، کلسٹرز، امیج رجسٹریز، شناخت، راز، ایرر الرٹس، پبلک لوڈ بیلنسرز۔

کیوں مرحلہ 8؟

Terraform 8 فولڈرز میں واقع ہے۔ 01-foundation کے ذریعے 08-edge. ہر فولڈر کی اپنی اسٹیٹ فائل ہوتی ہے اور صرف پچھلے مراحل کو پڑھا جاتا ہے۔ اگر 03-gke اگر یہ ناکام ہوجاتا ہے، تو مسئلہ کلسٹر میں ہے، کہیں 1500 لائن فائل میں نہیں۔

یہ "Terraform 8 بار چلائیں" نہیں ہے۔ کام آٹھ چیزوں کو بنانا اور ثابت کرنا ہے کہ ہر ایک موجود ہے اس سے پہلے کہ اگلی چیز کی ضرورت ہو۔

ریاست اسے لیپ ٹاپ پر مقامی رکھتی ہے، لہذا یہ ایک شخص کے لیے ٹھیک ہے۔ ٹیم ہر قدم کی حیثیت کو گوگل کلاؤڈ اسٹوریج بالٹی میں منتقل کرتی ہے اس سے پہلے کہ کوئی دوسرا شخص اس پر عمل کرے۔ apply.

اوپر والا خاکہ دکھاتا ہے کہ کس طرح Terraform آٹھ مراحل میں GCP انفراسٹرکچر بناتا ہے۔ مطلوبہ APIs کو فعال کریں، Cloud NAT کے ساتھ ایک نیٹ ورک اور نجی GKE کلسٹر بنائیں، پھر ایک تصویری رجسٹری، شناخت، خفیہ، غلطی کی نگرانی، اور ایک پبلک لوڈ بیلنس سیٹ اپ کریں۔ کلاؤڈ NAT آپ کے نجی نوڈس کو آؤٹ باؤنڈ کنیکٹیویٹی فراہم کرتا ہے، بشمول بعد میں منتقلی کے دوران AWS RDS تک رسائی۔

ہر قدم پر کیسے عمل کیا جاتا ہے۔

ہر قدم اس فولڈر میں ایک ہی تین کمانڈز استعمال کرتا ہے۔

terraform init
terraform plan
terraform apply

درخواست دینے سے پہلے منصوبہ پڑھیں۔ نیچے دیئے گئے تمام اقدامات منصوبوں کی متوقع تعداد کی فہرست دیتے ہیں۔ مثال کے طور پر Plan: 7 to add, 0 to change, 0 to destroy. اگر آپ کی تعداد مختلف ہے یا آپ اپنے منصوبوں میں کسی چیز کو تباہ کرنے کی کوشش کر رہے ہیں، تو داخل ہونے سے پہلے رکیں اور پڑھیں۔ yes.

terraform apply پوچھنا Do you want to perform these actions?. زمرہ yes انٹر دبائیں۔

ذیل میں فولڈر کے راستے ریپوزٹری روٹ سے شروع ہوتے ہیں۔ اگر آپ پہلے ہی اندر ہیں۔ infra/gcp/terraform/0X-...استعمال کریں cd ../0Y-... اگلے مرحلے پر جانے کے لیے۔

تصدیق کے لیے "کنسول میں": صفحہ کے اوپری حصے میں اپنا پروجیکٹ منتخب کریں اور ریجن کو اس پر سیٹ کریں: us-east4 اگر آپ کے صفحہ میں مقامی مینو ہے، تو اکثر خالی فہرست کا مطلب ہے کہ مینو ابھی بھی آن ہے۔ us-central1.

مرحلہ 1: گوگل API کو چالو کریں (01-foundation)

گوگل کلاؤڈ سروسز نئے پروجیکٹس میں بطور ڈیفالٹ بند ہیں۔ یہ مرحلہ 10 خصوصیات کو قابل بناتا ہے، بشمول GKE، آرٹفیکٹ رجسٹری، سیکرٹ مینیجر، IAM، اور لاگنگ۔ اگر آپ اسے چھوڑ دیتے ہیں، 03-gke یہ بعد میں اجازت کی غلطی کے ساتھ ناکام ہو جائے گا جو مفید نہیں ہے۔

cd infra/gcp/terraform/01-foundation
cp terraform.tfvars.example terraform.tfvars

اگر terraform.tfvars اگر پروجیکٹ ID پہلے سے موجود ہے تو اسے کاپی کرنا چھوڑ دیں۔ دوسری کاپی آپ کی ترامیم کو اوور رائٹ کر دیتی ہے۔

کھلا terraform.tfvars تبدیل کریں اور clearpay-migration-demo آپ کے پروجیکٹ ID کے ساتھ۔ پھر چلائیں:

terraform init
terraform plan
terraform apply

متوقع منصوبہ: google_project_service نمبر 10 اور کوئی کلسٹر نہیں۔

Plan: 10 to add, 0 to change, 0 to destroy.

Changes to Outputs:
  + project_id = "YOUR_PROJECT_ID"
  + region     = "us-east4"

اگر منصوبہ چھپا ہوا ہے۔ clearpay-migration-demoٹھیک کریں terraform.tfvars پہلے خفیہ مینیجر اور سروس نیٹ ورکنگ ممکن ہے۔ Still creating درخواست کے دوران تقریبا 30 منٹ۔

چیک کریں:

gcloud services list --enabled --filter="config.name:container.googleapis.com"

NAME                      TITLE
container.googleapis.com  Kubernetes Engine API

اگر کچھ بھی پرنٹ نہیں ہوتا ہے تو، آپ کے پروجیکٹ کے لیے API کو فعال نہیں کیا گیا ہے۔ gcloud ابھی تک مرحلہ 2 پر نہ جائیں درج ذیل تین وجوہات کو ترتیب سے دیکھیں:

1. gcloud ایک اور منصوبے کی طرف اشارہ کرتے ہیں۔ چلائیں gcloud config get-value project. اسے وہی پروجیکٹ ID پرنٹ کرنا چاہئے جو آپ نے درج کیا ہے۔ terraform.tfvars. اگر نہیں تو چلائیں: gcloud config set project YOUR_PROJECT_ID اور دوبارہ چیک کریں۔

2. آپ کی درخواست مکمل نہیں ہوئی ہے۔ چلائیں terraform plan کو 01-foundation دوبارہ اسٹیج پرنٹ مکمل No changes. اگر آپ اب بھی اپنے پلان میں وسائل شامل کرنا چاہتے ہیں تو چلائیں: terraform apply اور ٹائپ کریں۔ yes.

3. گوگل نے ابھی تک نہیں پکڑا ہے۔ آپ کے نئے فعال API کو فہرست میں ظاہر ہونے میں چند منٹ لگ سکتے ہیں۔ ایک منٹ انتظار کریں اور تصدیق کو دوبارہ چلائیں۔

مایا پیغام: "پہلا مرحلہ لاگو ہو گیا ہے اور ایسا لگتا ہے کہ Kubernetes Engine API فعال ہو گیا ہے۔"

مایا: "ٹھیک ہے۔ اگلا نیٹ ورک ہے۔ اور کچھ نہیں۔"

مرحلہ 2: اپنا نیٹ ورک بنائیں (02-network)

VPC گوگل پروجیکٹ کے اندر ایک نجی نیٹ ورک ہے۔ ان کے بارے میں ان محلوں کے طور پر سوچیں جن میں آپ کا کلسٹر رہے گا، اور اپنے کلسٹر میں ایک سب نیٹ کو ایک گلی کے طور پر سوچیں۔ یہ قدم پیدا کرتا ہے:

• clearpay-vpcنجی نیٹ ورک

• clearpay-gke-subnetکلسٹر میں مشینوں کے ذریعے استعمال ہونے والی ایڈریس رینجز (بشمول دو اضافی نامزد رینجز) pods اور services اسٹیج 3 کے لیے مخصوص ہے۔

• clearpay-router اور clearpay-natکلاؤڈ NAT کی ترتیبات

• clearpay-nat-ipکال کرتے وقت تمام کلسٹر سسٹمز کے ذریعے ایک عوامی IP کا اشتراک کیا جاتا ہے۔

• فائر وال کے دو اصول اندرونی مشینوں کو ایک دوسرے کے ساتھ بات چیت کرنے اور گوگل کے ہیلتھ چیکس تک پہنچنے کی اجازت دیتے ہیں۔

اس فولڈر میں terraform.tfvars. مرحلہ 1 اسٹیٹس فائل سے پروجیکٹ آئی ڈی پڑھیں۔

cd infra/gcp/terraform/02-network

چلائیں:

terraform init
terraform plan
terraform apply

متوقع منصوبہ:

Plan: 7 to add, 0 to change, 0 to destroy.

کوریج کا متوقع اختتام:

Apply complete! Resources: 7 added, 0 changed, 0 destroyed.

Outputs:

nat_ip_address = "x.x.x.x"
network_name = "clearpay-vpc"
subnet_name = "clearpay-gke-subnet"

چیک کریں:

gcloud compute networks describe clearpay-vpc
terraform output nat_ip_address

اسے تلاش کریں۔ name: clearpay-vpc، subnetworks کے ساتھ ختم ہونے والی لائن clearpay-gke-subnetاور autoCreateSubnetworks: false. آخری لائن کا مطلب ہے کہ یہ نیٹ ورک ڈیزائن کیا گیا تھا، تخلیق نہیں کیا گیا تھا۔

NAT IP لکھیں۔ باب 13 بالکل اسی ایڈریس کے لیے AWS ڈیٹا بیس کو کھولتا ہے۔

کنسول میں: آپ کو اپنا VPC نیٹ ورک دیکھنا چاہیے۔ clearpay-vpc. کلاؤڈ NAT شو clearpay-nat کو clearpay-router. آپ کا IP پتہ دکھایا جائے گا۔ clearpay-nat-ip.

اگر منصوبہ ناجائز ہے۔ ../01-foundation/terraform.tfstateفیز 1 مکمل نہیں ہے۔

مایا پیغام: "clearpay-vpc اور Cloud NAT موجود ہے۔ NAT IP نوٹوں میں ہے۔"

ڈینیئل اپنے نوٹوں میں NAT IP چیک کرتا ہے۔

ڈینیئل: "ہماری پوڈ بیرونی دنیا کو کی جانے والی ہر کال اس ایڈریس سے آتی ہے۔ اس میں AWS میں ڈیٹا بیس کو کالز شامل ہیں۔ بعد میں، ہم اپنے AWS ڈیٹا بیس سے کہتے ہیں کہ اس ایڈریس سے کنکشن قبول کریں نہ کہ کسی دوسرے ایڈریس سے۔"

اس کی وضاحت باب 13 میں کی گئی ہے۔ تب تک، اپنے NAT IP کو نوٹ کریں۔

مرحلہ 3: ایک GKE کلسٹر بنائیں (03-gke)

یہ مرحلہ درج ذیل معیاری کلسٹر بناتا ہے: clearpay علاقے میں us-east4-aنامزد نوڈ پولز پر مشتمل ہے۔ primary ایک سے تین تک e2-medium مشین مشینوں میں صرف پرائیویٹ IPs ہوتے ہیں اور Cloud NAT کا استعمال کرتے ہوئے جڑ جاتے ہیں۔ کنٹرول ہوائی جہاز، کلسٹرز کے لیے گوگل کا نظم کردہ API سرور، کا ایک عوامی اختتامی نقطہ ہے، لہذا kubectl آپ اپنے لیپ ٹاپ سے جڑ سکتے ہیں۔

GKE پہلے ڈیفالٹ نوڈ پول بناتا ہے، پھر Terraform اسے حذف کرتا ہے اور primaryآپ کنٹرول میں ہیں.

cd infra/gcp/terraform/03-gke

چلائیں:

terraform init
terraform plan
terraform apply

متوقع منصوبہ: کلسٹر اور primary نوڈ پول۔

Plan: 2 to add, 0 to change, 0 to destroy.

لاگو ہوتا ہے: Still creating 7-10 منٹ تک۔ Ctrl+C نہ دبائیں۔

Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

Outputs:

cluster_name = "clearpay"
get_credentials_command = "gcloud container clusters get-credentials clearpay --zone us-east4-a --project YOUR_PROJECT_ID"

cluster_endpoint پرنٹس . آپ کو اس کی ضرورت نہیں ہے۔

اشارہ کریں kubectl نئے کلسٹر میں:

$(terraform output -raw get_credentials_command)

اچھا چل رہا پرنٹ kubeconfig entry generated for clearpay.

چیک کریں:

kubectl get nodes

NAME                                 STATUS   ROLES    AGE   VERSION
gke-clearpay-primary-........        Ready       2m    v1.xx

Ready اس کا مطلب ہے کہ مشین آن ہو گئی ہے اور کلسٹر میں شامل ہو گئی ہے۔ ClearPay ابھی تک تعاون یافتہ نہیں ہے۔

اگر درخواست میں ذکر کیا گیا ہے۔ container.googleapis.comمرحلہ 1 پر واپس جائیں۔ سب نیٹ یا pods یا services رینج بتانے کے لیے مرحلہ 2 پر واپس جائیں۔ اس میں ترمیم نہ کریں۔ 03-gke اس غلطی کو چھپانے کے لیے۔

اگر kubectl کہتے ہیں gke-gcloud-auth-plugin not foundکلسٹرز ٹھیک ہیں۔ اسے تباہ نہ کریں۔ پلگ ان انسٹال کریں اور اس ٹرمینل کے PATH میں ترمیم کریں۔

gcloud components install gke-gcloud-auth-plugin
export PATH="$(gcloud info --format="value(installation.sdk_root)")/bin:$PATH"
kubectl get nodes

کنسول میں: آپ کو اپنا Kubernetes کلسٹر دیکھنا چاہیے۔ clearpay چل رہا ہے VM مثال ہے۔ gke-clearpay-primary- ایک مشین جس کا اندرونی IP ہے لیکن کوئی بیرونی IP نہیں ہے۔

مایا پیغام: "کلسٹر تیار ہے۔ ایک نوڈ تیار ہے۔ ابھی تک کوئی نوڈ نہیں چل رہے ہیں۔"

درخواست میں 9 منٹ لگے۔ آپ نے ان سب کو دیکھا ہے۔

مرحلہ 4: ایک تصویری رجسٹری بنائیں (04-registry)

کنٹینر کی تصویر آپ کی ایپ کی پیک شدہ کاپی ہے۔ GKE رجسٹری سے تصاویر ڈاؤن لوڈ کرتا ہے۔ اس مرحلے میں، آپ آرٹفیکٹ رجسٹری میں درج ذیل نجی ڈوکر رجسٹری بناتے ہیں۔ clearpayمیں us-east4. یہ اس وقت تک خالی رہے گا جب تک کہ باب 14 میں پائپ لائن کو آگے نہیں بڑھایا جاتا۔

cd infra/gcp/terraform/04-registry

چلائیں:

terraform init
terraform plan
terraform apply

دو وسائل ایک رجسٹری اور قواعد ہیں جو کلسٹر میں موجود مشینوں کو رجسٹری سے تصاویر کھینچنے کی اجازت دیتے ہیں۔

Plan: 2 to add, 0 to change, 0 to destroy.

Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

Outputs:

repository_url = "us-east4-docker.pkg.dev/YOUR_PROJECT_ID/clearpay"

چیک کریں:

gcloud artifacts repositories describe clearpay --location=us-east4

اسے تلاش کریں۔ format: DOCKER، name کے ساتھ ختم /repositories/clearpayاور Repository Size: 0.000MB. آج یہ ایک خالی رجسٹری ہے۔ آپ بھی دیکھ سکتے ہیں SCANNING_DISABLED. اس کے بجائے باب 14 میں پائپ لائن تصویر کو اسکین کرنے کے لیے Trivy کا استعمال کرتی ہے۔

مایا پیغام: "تصویری رجسٹری موجود ہے۔ یہ خالی ہے۔"

مرحلہ 5: کلیدی فائل کے بغیر ID بنائیں (05-identity)

آپ کو بعد میں دو چیزوں کے لیے گوگل کی اجازت درکار ہوگی۔ GKE پر ClearPay پوڈز اور امیجز کو آگے بڑھاتے اور تعینات کرتے وقت GitHub ایکشنز۔

روایتی طریقہ سروس اکاؤنٹ کی فائل کو ڈاؤن لوڈ کرنا ہے۔ کلیدی فائل ڈسک کا پاس ورڈ ہے۔ اگر یہ لیک ہو جائے تو کوئی بھی اسے استعمال کر سکتا ہے۔ ہم اس لیب میں کبھی نہیں بنائیں گے۔

اس کے بجائے، یہ قدم تین Google سروس اکاؤنٹس (مراعات یافتہ شناخت) بناتا ہے اور نامزد کال کرنے والوں کو مختصر مدت کے لیے انہیں ادھار لینے کی اجازت دیتا ہے۔

• clearpay-api-stagingفورڈ سے ادھار لیا staging نام کی جگہ

• clearpay-api-productionفورڈ سے ادھار لیا production نام کی جگہ

• clearpay-ciGitHub ایکشنز سے ورک لوڈ شناختی پول کے ذریعے کرائے پر لیا گیا۔ clearpay-github-pool

ورک لوڈ آئیڈینٹی ایک گوگل کی خصوصیت ہے جو کسی کوبرنیٹس سروس اکاؤنٹ یا GitHub ریپوزٹری کو بغیر کلید کے گوگل سروس اکاؤنٹ سے جوڑتی ہے۔

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

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

cd infra/gcp/terraform/05-identity
cp terraform.tfvars.example terraform.tfvars

فائل میں صرف اقدار ہیں: github_repo. اگر آپ کے پاس پہلے سے ہی اس ذخیرہ کی GitHub کاپی ہے تو اسے ڈاؤن لوڈ کریں۔ owner/name اب وہاں، کچھ بھی نہیں .git آخر میں۔ اگر نہیں تو چھوڑ دو۔ YOUR_GITHUB_USER/YOUR_REPO. باب 14 وضاحت کرتا ہے کہ اسے کب ترتیب دینا ہے اور ان مراحل کو دوبارہ لاگو کرنا ہے۔

چلائیں:

terraform init
terraform plan
terraform apply

متوقع منصوبہ:

Plan: 10 to add, 0 to change, 0 to destroy.

10 تین سروس اکاؤنٹس ہیں، ایک GitHub پول اور اس کا فراہم کنندہ، اور ان کے درمیان اجازت کے لنکس۔

Apply complete! Resources: 10 added, 0 changed, 0 destroyed.

Outputs:

ci_service_account_email = "clearpay-ci@YOUR_PROJECT_ID.iam.gserviceaccount.com"
service_account_emails = {
  "production" = "clearpay-api-production@YOUR_PROJECT_ID.iam.gserviceaccount.com"
  "staging" = "clearpay-api-staging@YOUR_PROJECT_ID.iam.gserviceaccount.com"
}

چیک کریں:

gcloud iam service-accounts list --filter="email~clearpay-"

تین ای میلز تلاش کریں: clearpay-api-staging، clearpay-api-productionاور clearpay-ci.

کنسول: سروس اکاؤنٹس کے تحت تین درج ہیں۔ کام کے بوجھ کی شناخت سے وابستگی دکھائیں۔ clearpay-github-pool سپلائر کے ساتھ clearpay-github-provider.

اگر درخواست ناکام ہوجاتی ہے۔ کے ساتھ Error 409: Requested entity already exists پول میں، آپ ان مراحل کو پہلے چلا چکے ہیں۔ گوگل ڈیلیٹ کیے گئے پولز کو 30 دنوں کے لیے اپنے پاس رکھتا ہے اور ان کے نام بلاک کر دیتا ہے۔ اس کے ساتھ بحال کریں: gcloud iam workload-identity-pools undelete clearpay-github-pool --location=global،
پھر بھاگو terraform import google_iam_workload_identity_pool.github projects/YOUR_PROJECT_ID/locations/global/workloadIdentityPools/clearpay-github-pool اور دوبارہ اپلائی کریں۔

اگر آپ کو فراہم کنندہ کے نام کی وضاحت کرنے میں وہی غلطی ملتی ہے، تو اسے استعمال کرکے بحال کریں: gcloud iam workload-identity-pools providers undelete clearpay-github-provider --workload-identity-pool=clearpay-github-pool --location=global،
پھر بھاگو terraform import google_iam_workload_identity_pool_provider.github projects/YOUR_PROJECT_ID/locations/global/workloadIdentityPools/clearpay-github-pool/providers/clearpay-github-provider اور دوبارہ اپلائی کریں۔

مایا پیغام: "تین سروس اکاؤنٹس ہیں۔ ابھی تک کوئی اکاؤنٹ انہیں استعمال نہیں کر رہا ہے۔"

مایا: "کیا آپ کے پاس کلیدی فائل نہیں ہے؟"

"موجود نہیں ہے۔"

مرحلہ 6: راز بنائیں (06-secrets)

GKE پر ClearPay کو دو راز درکار ہیں: ایک ڈیٹا بیس یو آر ایل اور ایک JWT سائننگ کلید۔ دونوں AWS پر پہلے سے موجود ہیں۔ اس مرحلے میں، آپ سیکرٹ مینیجر میں چار راز بناتے ہیں، ایک جوڑا فی نام کی جگہ۔

• clearpay-staging-jwt-secret

• clearpay-staging-database-url

• clearpay-production-jwt-secret

• clearpay-production-database-url

سٹیجنگ سروس اکاؤنٹ صرف سٹیجنگ جوڑوں کو پڑھ سکتا ہے۔ پروڈکشن سروس اکاؤنٹ صرف پروڈکشن جوڑے پڑھ سکتا ہے۔

ہر راز کو ایک مقفل دراز کے طور پر سوچیں۔ لیول 5 میں ہر بیج صرف اپنے متعلقہ دراز کو کھولتا ہے۔

اس مشق کے لیے، آپ دونوں جوڑوں میں ایک جیسی اقدار درج کریں گے۔ دونوں ماحول ایک ہی RDS کا استعمال کرتے ہیں، اور آپ کا AWS لاگ ان تب بھی کام کرنا چاہیے جب اگلی درخواست GKE سے ٹکرائے۔ حقیقی کمپنیاں ہر ماحول میں منفرد قدر لاتی ہیں۔

ٹیرافارم راز پیدا کرنے کے لیے پلیس ہولڈر اقدار کا استعمال کرتا ہے۔ REPLACE_ME. Terraform راز پیدا کر سکتا ہے، لیکن اسے اپنی اقدار کو تیار کرنے کی اجازت نہیں ہے۔ لہٰذا حکم یہ ہے کہ پہلے اس کا اطلاق کریں اور پھر اصل قیمت کو براہ راست نقل کریں۔

cd infra/gcp/terraform/06-secrets

چلائیں:

terraform init
terraform plan
terraform apply

Terraform 14 وسائل تخلیق کرتا ہے۔

Plan: 14 to add, 0 to change, 0 to destroy.

Apply complete! Resources: 14 added, 0 changed, 0 destroyed.

اب AWS ویلیو کاپی کریں۔ AWS چلنا ضروری ہے۔

اسے ریپوزٹری روٹ سے چلائیں، جو آپ کے پروجیکٹ کا ٹاپ لیول فولڈر ہے۔ 06-secrets اور سے نہیں۔ infra/aws/terraform. آپ ابھی تک اندر ہیں 06-secretsپہلے چار فولڈرز پر جائیں۔

cd ../../../..

ls اب مجھے دکھانا ہے۔ api، infra، k8sاور scripts.

آپ کو AWS فولڈر میں جانے کی ضرورت نہیں ہے۔ terraform -chdir=infra/aws/terraform جہاں آپ کھڑے ہیں وہاں سے AWS ویلیوز پڑھیں۔ ہر کمانڈ براہ راست سیکرٹ مینیجر کو ایک قدر بھیجتا ہے، لہذا اسکرین پر کچھ بھی پرنٹ نہیں ہوتا ہے۔

ڈیٹا بیس یو آر ایل، ہر ایک نام کی جگہ کے لیے ایک بار:

terraform -chdir=infra/aws/terraform output -raw database_url 
  | gcloud secrets versions add clearpay-staging-database-url --data-file=-
terraform -chdir=infra/aws/terraform output -raw database_url 
  | gcloud secrets versions add clearpay-production-database-url --data-file=-

اچھا چل رہا پرنٹ Created version [2] URL پرنٹ نہیں کرتا ہے۔

JWT راز سے پڑھا جاتا ہے: .env AWS سرورز پر فائلیں:

INSTANCE_IP=$(terraform -chdir=infra/aws/terraform output -raw instance_public_ip)
ssh -i ~/.ssh/clearpay-deployer ubuntu@$INSTANCE_IP 
  "sudo grep '^JWT_SECRET=' /opt/clearpay-api/.env | cut -d= -f2-" 
  | gcloud secrets versions add clearpay-staging-jwt-secret --data-file=-
ssh -i ~/.ssh/clearpay-deployer ubuntu@$INSTANCE_IP 
  "sudo grep '^JWT_SECRET=' /opt/clearpay-api/.env | cut -d= -f2-" 
  | gcloud secrets versions add clearpay-production-jwt-secret --data-file=-

بعد میں terraform apply اسے اس فولڈر میں مت ڈالیں۔ REPLACE_ME پیچھے میں۔ Terraform فائل ہمیں پہلی درخواست کے بعد اقدار کو چھوڑنے کی ہدایت کرتی ہے۔

چیک کریں:

gcloud secrets list --filter="name~clearpay-"

پھر ثابت کریں کہ کوئی راز نہیں ہے جو اب بھی پلیس ہولڈر کو برقرار رکھتا ہے۔ یہ لوپ پرنٹ کیا جاتا ہے. ok یا STILL_PLACEHOLDER راز نہیں چھاپتا۔

for s in clearpay-staging-database-url clearpay-staging-jwt-secret 
         clearpay-production-database-url clearpay-production-jwt-secret; do
  val=$(gcloud secrets versions access latest --secret="$s")
  if [ "$val" = "REPLACE_ME" ]; then echo "STILL_PLACEHOLDER $s"; else echo "ok $s"; fi
done

4 تلاش کریں۔ ok سموچ اگر کوئی کہے۔ STILL_PLACEHOLDERکاپی کمانڈ دوبارہ چلائیں۔

کنسول میں: سیکرٹ مینیجر چار رازوں کی فہرست دیتا ہے، ہر ایک تازہ ترین ورژن 2 کے ساتھ۔ شیئرنگ اسکرین پر "خفیہ قدر دکھائیں" پر کلک نہ کریں۔

مایا پیغام: "چار رازوں میں AWS ویلیو شامل ہے۔ سکرین پر کچھ بھی پرنٹ یا چیٹ میں چسپاں نہیں ہوتا۔"

مرحلہ 7: API کی غلطیوں کا حساب لگائیں (07-observability)

جب بھی API میں کچھ ہوتا ہے، میں ایک مختصر نوٹ لکھتا ہوں جسے لاگ لائن کہتے ہیں۔ ایک لاگ ان استعمال کریں۔ ایک کے لیے ادائیگی کریں۔ اگر کچھ غلط ہو جاتا ہے، تو نوٹ کچھ اس طرح کہیں گے: "level":"error". ناکام ادائیگیاں درج ذیل ہیں:

{"level":"error","message":"transaction_failed","timestamp":"2026-09-29T10:15:02.000Z","error":"..."}

GKE پر، گوگل کلاؤڈ ان تمام نوٹوں کو جمع کرتا ہے۔ یہ قدم اس کے اوپر دو چیزیں بناتا ہے۔

1. بارنامزد clearpay-api-error-count. ہر بار جب غلطی کا نوٹ ظاہر ہوتا ہے تو اس میں 1 کا اضافہ ہوتا ہے۔

2. الارمنامزد ClearPay API - elevated error rate. جب کاؤنٹر 5 منٹ کے اندر 5 بار سے زیادہ بڑھتا ہے تو یہ آن ہوتا ہے۔ ایک غلطی بد نصیبی ہو سکتی ہے۔ 5 میں سے 5 کا مطلب ہے کچھ ٹوٹ گیا ہے۔

الارم میں ابھی تک کوئی فون نمبر یا ای میل منسلک نہیں ہے۔ جب میں اسے آن کرتا ہوں، تو یہ گوگل کلاؤڈ کنسول میں ظاہر ہوتا ہے، لیکن کسی کو کوئی پیغام نہیں ملتا ہے۔ آپ اپنا ای میل بعد میں کنسول میں شامل کر سکتے ہیں۔

کاؤنٹر فی الحال 0 پر ہے کیونکہ ClearPay ابھی تک GKE پر نہیں چل رہا ہے۔ آج، 0 درست نتیجہ ہے۔

cd infra/gcp/terraform/07-observability

چلائیں:

terraform init
terraform plan
terraform apply

متوقع منصوبہ:

Plan: 2 to add, 0 to change, 0 to destroy.

Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

Outputs:

log_metric_name = "clearpay-api-error-count"

جب درخواست رک جاتی ہے۔ Error 404: Cannot find metric(s) that match typeکچھ نہیں ٹوٹا تھا۔ گوگل کو خطرے کی گھنٹی بجنے سے پہلے نئے کاؤنٹر کو رجسٹر کرنے میں چند منٹ لگیں گے۔ ایک کاؤنٹر بنایا گیا ہے۔ 5 منٹ انتظار کریں اور چلائیں۔ terraform apply دوبارہ اس بار میں ایک منصوبہ دیکھ رہا ہوں۔ 1 to addصرف الارم۔

چیک کریں:

gcloud logging metrics describe clearpay-api-error-count

اسے تلاش کریں۔ name: clearpay-api-error-count اور ایک فلٹر جس کا تذکرہ ہے: clearpay-api اور jsonPayload.level="error".

مایا پیغام: "خرابی کاؤنٹر موجود ہے اور 0 دکھاتا ہے۔ GKE پر ابھی تک کوئی ایپ نہیں چل رہی ہے۔"

مایا: "یہ آخری پتہ ہے۔ یہ وہ پتہ ہے جسے ہمارے صارفین استعمال کریں گے، لہذا اپنا وقت نکالیں۔"

مرحلہ 8. پبلک لوڈ بیلنسر بنانا (08-edge)

گھر 1 سے 7 تک کے مراحل تک بنایا گیا تھا۔ یہ مرحلہ سامنے کا دروازہ بناتا ہے، جو وہ پتہ ہوتا ہے جو گاہک بقیہ منتقلی کے لیے رکھتا ہے۔ یہ گوگل کا گلوبل لوڈ بیلنسر ہے جس کے پیچھے ٹریفک ڈائل ہے۔ ایک فیصد AWS کو دیا جاتا ہے اور باقی GKE کو دیا جاتا ہے۔ آج، 100% AWS کو منتقل کر دیا گیا ہے۔

یہ قدم پیدا کرتا ہے:

• clearpay-api-ipصارفین کے زیر استعمال تمام عمارتوں کا پتہ

• HTTPS کے کام کرنے کے لیے خود دستخط شدہ سرٹیفکیٹ

• ٹریفک کی تقسیم AWS 100، GKE 0 پر سیٹ ہے۔

• clearpay-gke-edge-ipیہ GKE کی طرف دوسرا IP ہے۔ لوڈ بیلنسرز اسے استعمال کرتے ہیں۔ گاہک ایسا کبھی نہیں کرتے۔

نیچے دیا گیا خاکہ دکھاتا ہے کہ کس طرح GCP لوڈ بیلنس کنفیگر ایبل ٹریفک ریٹس کا استعمال کرتے ہوئے AWS اور GKE کے درمیان کسٹمر ٹریفک کو ڈائریکٹ کرتا ہے۔ صارفین ایک عوامی IP کے ذریعے جڑتے ہیں۔ AWS کو لچکدار IPs پر ٹریفک موصول ہوتا ہے، جبکہ GKE کو علیحدہ کنارے والے IPs پر ٹریفک موصول ہوتا ہے جن تک صارفین براہ راست رسائی نہیں کرتے۔ دونوں ماحول AWS پر ایک ہی PostgreSQL ڈیٹا بیس سے جڑتے ہیں۔ اس مرحلے پر، آپ کا GKE کلسٹر خالی ہے۔

cd infra/gcp/terraform/08-edge
cp terraform.tfvars.example terraform.tfvars

اگر فائل موجود ہے تو کاپی چھوڑ دی جاتی ہے۔ براہ کرم اپنا لچکدار IP درج کریں۔ aws_backend_ip. اسے اپنے ذخیرے کی جڑ میں دوسرے ٹرمینل سے حاصل کریں:

terraform -chdir=infra/aws/terraform output -raw instance_public_ip

وزن کو 100 اور 0 پر چھوڑ دیں۔

aws_traffic_weight = 100
gke_traffic_weight = 0

چلائیں:

terraform init
terraform plan
terraform apply

درخواست میں تقریباً 2 منٹ لگتے ہیں۔

Plan: 17 to add, 0 to change, 0 to destroy.

Apply complete! Resources: 17 added, 0 changed, 0 destroyed.

Outputs:

current_traffic_split = "AWS: 100% / GKE: 0%"
static_ip_address = "x.x.x.x"
gke_edge_ip_address = "y.y.y.y"
hosts_file_line = "x.x.x.x api.clearpay.test"

دونوں IPs لکھیں۔ static_ip_address گاہک کا پتہ۔ gke_edge_ip_address یہ سچ نہیں ہے۔

اپنا پتہ ایک نام دیں۔

میں ڈومین کا مالک نہیں ہوں، اس لیے میں نام کی طرف اشارہ کرتا ہوں۔ api.clearpay.test آپ کے کمپیوٹر کی میزبان فائل میں لوڈ بیلنسر سے۔

آپ پہلے ہی شرکت کر رہے ہیں۔ 08-edge یہ درخواست کے بعد ہے، لہذا اسے چھوڑ دیں۔ cd نیچے لائن. اسے صرف اس صورت میں چلائیں جب آپ کے پاس ریپوزٹری روٹ میں نیا ٹرمینل کھلا ہو۔

cd infra/gcp/terraform/08-edge
LINE=$(terraform output -raw hosts_file_line)
echo "LINE is: [$LINE]"

اگر LINE یہ خالی ہے۔ اسے روکو۔ اگر یہ اس طرح لگتا ہے: x.x.x.x api.clearpay.testاسے اپنی میزبان فائل میں شامل کریں:

میک کے لیے:

echo "$LINE" | sudo tee -a /etc/hosts
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

لینکس پر، صرف پہلی لائن چلائیں۔ ونڈوز میں، ایک ہی IP اور شامل کریں۔ api.clearpay.test کو C:WindowsSystem32driversetchosts ایڈمنسٹریٹر کے طور پر کھولے گئے ایڈیٹر میں۔

مت بھاگو sudo cd. cd چونکہ یہ شیل میں بنا ہوا ہے۔ sudo فولڈر کو تبدیل نہیں کیا جا سکتا۔

چیک کریں کہ آیا وہ لائن موجود ہے۔

grep api.clearpay.test /etc/hosts

نام کے ساتھ ختم ہوتا ہے: .test مقصد پر .test جانچ کے مقاصد کے لیے محفوظ، آپ کروم میں خود دستخط شدہ سرٹیفکیٹ کی وارننگ اس پر کلک کر کے دیکھ سکتے ہیں۔ تبدیل نہ کرو lab_hostname کو .dev نام کروم ہر چیز پر سخت HTTPS نافذ کرتا ہے۔ .dev جاری رکھنے کے لیے بٹن کو چھپائیں۔

چیک کریں

curl -k https://api.clearpay.test/health

متوقع پیداوار:

{"status":"ok","served_by":{"platform":"aws","version":"1.0.0","instance":"ip-172-31-64-73","commit":"504e0cd","rollback_active":false}}

آپ کا instance اور commit آپ کی قدریں بدل جائیں گی۔ "platform":"aws" یہ ایک چیک ہے۔ درخواست نئے گوگل ایڈریس پر گئی، اور چونکہ وزن 100 اور 0 تھے، لوڈ بیلنسر نے اسے AWS کو بھیج دیا۔

آپ کے نئے Google لوڈ بیلنس کو شروع ہونے میں چند منٹ لگ سکتے ہیں۔ اگر آپ کو ابھی تک JSON نظر نہیں آتا ہے، تو آپ کو پہلے درج ذیل میں سے کوئی ایک نظر آ سکتا ہے:

• Connection reset. لوڈ بیلنس اب بھی شروع ہو رہا ہے۔ ایک لمحہ انتظار کریں اور وہی کرل دوبارہ چلائیں۔

• عنوان کے لیے گوگل صفحہ 404 Not Found. لوڈ بیلنس نے جواب دیا، لیکن یہ ابھی تک AWS تک نہیں پہنچا ہے۔ تصدیق کریں کہ AWS خود تیار اور چل رہا ہے۔

curl -k https://YOUR_ELASTIC_IP/health

اگر AWS جواب دیتا ہے، تو چند منٹ انتظار کریں اور دوبارہ کوشش کریں۔ api.clearpay.test دوبارہ مرحلہ 8 مکمل ہو جائے گا، اگرچہ اب بھی آہستہ آہستہ. باب 20 دوبارہ اس کی تصدیق کرتا ہے۔

JSON ظاہر ہونے پر، اپنے براؤزر میں https://api.clearpay.test کھولیں۔ کروم میں، ایڈوانسڈ پر کلک کریں، پھر "api.clearpay.test پر آگے بڑھیں (محفوظ نہیں)" پر کلک کریں۔ آپ اپنے نئے پتے کے ذریعے AWS کی طرف سے فراہم کردہ ClearPay لاگ ان دیکھیں گے۔ اگر آپ کا براؤزر کہتا ہے: NXDOMAINمیزبان لائن غائب ہے یا کیشے کو فلش نہیں کیا گیا ہے۔

کنسول سے: آپ کا IP پتہ دکھایا جائے گا۔ clearpay-api-ip اور clearpay-gke-edge-ip. لوڈ بیلنس شو clearpay-migration-forwarding-rule یہ لچکدار IP کو پسدید کے طور پر استعمال کرتا ہے۔

مکمل ہونے پر:

• مرحلہ 1: container.googleapis.com چالو کر دیا گیا ہے

• مرحلہ 2: terraform output nat_ip_address میں نے آئی پی کو پرنٹ کیا اور اسے لکھ دیا۔

• مرحلہ 3: kubectl get nodes کم از کم ایک دکھاتا ہے۔ Ready لفظ

• مرحلہ 4: clearpay رجسٹری موجود ہے۔

• مرحلہ 5:3 clearpay- سروس اکاؤنٹ موجود ہے۔

• مرحلہ 6: 4 لوپس پرنٹ کریں۔ ok سموچ

• مرحلہ 7: ایرر میٹرکس موجود ہیں۔

• مرحلہ 8: /etc/hosts ہے api.clearpay.testوزن 100/0 ہے۔

مایا کو بتائیں، "تمام آٹھ مراحل کی تصدیق ہو چکی ہے۔ وزن 100 اور 0 ہے۔ GKE پر ابھی تک کچھ نہیں چلا ہے۔"

ڈینیئل: "کلسٹر خالی ہے۔ اگلا، ہم یہاں کلیئر پے تعینات کریں گے۔"

حصہ 4۔ ClearPay کو GKE سٹیجنگ میں کیسے تبدیل کریں۔

مایا اپنے براؤزر میں نیا پتہ چیک کرنے کے لیے رکتی ہے۔ وہ ڈیش بورڈ کی لائنیں پڑھتی ہے اور مسکراتی ہے۔

مایا: "سامنے دروازے پر اچھا کام۔ لیکن دیکھو، یہ اب بھی یہی کہتا ہے۔ aws. صارفین نئے ایڈریس سے جڑ سکتے ہیں اور تمام درخواستیں اب بھی پرانے سرور پر بھیجی جائیں گی۔ "GKE پر کلسٹر خالی ہے، اس لیے ابھی تک کوئی بھی وہاں $20 نہیں بھیج سکتا۔"

وہ آپ کے ٹرمینل کی طرف اشارہ کرتی ہے۔

مایا: "اگلا مرحلہ اس کلسٹر پر ClearPay کو انسٹال کرنا ہے۔ ایک چیز جس میں میں دلچسپی رکھتا ہوں کہ پائپ لائن کو یہ کرنا ہے، بجائے اس کے کہ کسی شخص کو کمانڈز ٹائپ کرے۔ پائپ لائن اسے ہر بار اسی طرح کرتی ہے، اور ہم بالکل دیکھ سکتے ہیں کہ اس نے کیا کیا۔"

https://api.clearpay.test یہ سوچنا آسان ہے کہ ClearPay GKE پر ہے کیونکہ یہ پہلے سے ہی براؤزر میں کام کرتا ہے۔ یہ سچ نہیں ہے۔ وہ پتہ گوگل کا نیا فرنٹ ڈور، لیول 8 لوڈ بیلنسر ہے۔ اگر وزن 100 اور 0 ہے تو سامنے کا دروازہ AWS کو تمام درخواستیں بھیجتا ہے۔ کہ served by aws/1.0.0 ڈیش بورڈ پر لکیریں اس بات کو ثابت کرتی ہیں۔ GKE کلسٹر خود اب بھی خالی ہے۔

Browser → api.clearpay.test (Google load balancer) → 100% → AWS EC2 → RDS
                                                  →   0% → GKE (empty)

اس حصے میں، پائپ لائن ClearPay کو GKE سٹیجنگ میں رکھتی ہے، اور باب 6 میں پروموشن گیٹ طے کرتا ہے کہ آیا سٹیجنگ کافی ہے۔ اسٹیجنگ کلسٹر کے اندر آپ کی ایپ کی نجی کاپی ہے۔ گاہک آپ تک نہیں پہنچتے۔

باب 12۔ API تصویر چیک کریں۔

دوسرا منگل صبح 9 بجے

کلسٹر بن چکا ہے اور خالی ہے۔ کچھ ہونے سے پہلے، ڈینیل API Dockerfile کو اسکرین پر دکھاتا ہے۔

ڈینیئل: "میں اسے ایک کلسٹر پر تعینات کرنے کی کوشش کر رہا ہوں۔ مجھے دکھائیں کہ کنٹینر روٹ کے طور پر نہیں چل رہا ہے۔"

ثابت کریں کہ آپ کی API تصویر چھوٹی ہے، خفیہ ہے، اور اس طرح نہیں چلتی ہے: root.

یہ کیوں اہمیت رکھتا ہے۔

ایک عمل جو مندرجہ ذیل طور پر چلتا ہے: root کنٹینر کے اندر اس سے کہیں زیادہ طاقت ہوتی ہے جس کی ضرورت ہوتی ہے اگر حملہ آور اندر داخل ہوتا ہے۔ پروڈکشن امیجز کو ایک عام صارف کی طرح چلنا چاہیے۔

قدم

کھلا api/Dockerfile. اس کے دو مراحل ہیں:

1. پہلا قدم، FROM node:22-slim AS depsصرف پروڈکشن پیکجز انسٹال کریں جن میں شامل ہیں: npm install --omit=dev.

2. دوسرا مرحلہ دوبارہ شروع ہوتا ہے: node:22-slim. چلانے والے APIs پر صرف Debian سیکیورٹی اپ ڈیٹس کا اطلاق کریں اور npm اور Yarn کو ہٹا دیں۔ node src/index.js. یہ پیدا کرتا ہے appuser یوزر آئی ڈی 1001 کے ساتھ کاپی کریں۔ node_modules، srcاور db. آخری لائن میں منتقلی: USER appuser.

دیکھیں کہ تصویر میں کیا شامل نہیں ہے۔ DATABASE_URL اور JWT_SECRET. یہ سیکریٹ مینیجر سے رن ٹائم پر آتا ہے۔

Docker ڈیسک ٹاپ چل رہا ہونا چاہیے۔ ذخیرہ کی جڑ سے:

docker build -t clearpay-api:test ./api
docker run --rm clearpay-api:test whoami

چیک کریں

دوسرا کمانڈ پرنٹ کرتا ہے:

appuser

اگر یہ ناکام ہوجاتا ہے:

مکمل ہونے پر:

باب 13 ClearPay کے لیے اپنے کلسٹر کی تیاری

منگل 11 بجے

تصویر کی تصدیق مکمل ہو گئی ہے۔ GitHub کھولیں، آپ کی پائپ لائن چلانے کے لیے تیار ہے۔ دانیال نے سکرین کی طرف دیکھا اور سر ہلایا۔

ڈینیئل: "پہلی تعیناتی پائپ لائن سے غیر متعلق وجوہات کی بناء پر دو بار ناکام ہو گئی۔ پہلے اسے ٹھیک کریں۔"

اپنی ابتدائی تعیناتی سے پہلے، آپ کو دو چیزیں درکار ہوں گی جو آپ کے کلسٹر میں پہلے سے نہیں ہیں:

1. پوڈز سیکرٹ مینیجر کے راز کیسے پڑھتے ہیں۔

2. AWS پر ڈیٹا بیس تک نیٹ ورک کا راستہ۔

اگر پہلی فائل غائب ہے تو، Kubernetes سٹیجنگ فائل کو مسترد کر دیتا ہے۔ اگر دوسرا غائب ہے تو پھلی شروع ہو جائے گی لیکن تیار نہیں ہوگی۔

حصہ A۔ سیکرٹ مینیجر ایڈ آن کریں۔

ڈینیئل: "پڈز کو سیکرٹ مینیجر کی قدر کو مرحلہ 6 سے پڑھنا چاہیے۔ اگر نہیں، تو براہ کرم لکھیں کہ آپ اب بھی فائل کیوں استعمال کر رہے ہیں۔"

اسٹیجنگ اور پروڈکشن فائلیں۔ k8s/overlays/ سیکرٹ مینیجر سے ڈیٹا بیس یو آر ایل اور جے ڈبلیو ٹی سیکریٹ پڑھیں۔ ہم دو GKE ایڈونس استعمال کرتے ہیں:

• سیکریٹ مینیجر CSI ڈرائیور پوڈ کے اندر خفیہ معلومات کو فائل کے طور پر لگاتا ہے۔

• سیکرٹ سنک اس کو باقاعدہ کبرنیٹس سیکریٹ میں اس طرح کاپی کرتا ہے: clearpay-api-secrets. تعیناتی لوڈ کرتی ہے جو API کے ماحولیاتی متغیرات میں خفیہ ہے۔

  

Pods مرحلہ 5 میں سروس اکاؤنٹس کا استعمال کرتے ہیں تاکہ یہ ثابت کیا جا سکے کہ وہ کام کے بوجھ کی شناخت کے ذریعے کون ہیں۔ کلیدی فائل کہیں موجود نہیں ہے۔ API کوڈ تبدیل نہیں ہوتا ہے۔ یہ اب بھی باقاعدہ ماحولیاتی متغیرات پڑھتا ہے، بالکل AWS کی طرح۔

دونوں ایڈ آنز کو آن کریں۔ gcloud اسے دو الگ الگ کمانڈز کی ضرورت ہوتی ہے، ہر ایک میں کئی منٹ لگتے ہیں۔

gcloud container clusters update clearpay --zone us-east4-a 
  --enable-secret-manager
gcloud container clusters update clearpay --zone us-east4-a 
  --enable-secret-sync

یہ ادھر بھاگتے ہیں یہاں نہیں۔ 03-gkeلہذا کلسٹر مرحلہ چھوٹا رہتا ہے اور آپ خفیہ رسائی کے شامل ہونے کا لمحہ دیکھ سکتے ہیں۔

چھوڑ دو PROJECT_ID جیسا کہ ہے۔ k8s/overlays/staging/secretproviderclass.yaml اور patch-serviceaccount.yaml. پائپ لائن اسے تعیناتی پر اصل پروجیکٹ ID سے بدل دیتی ہے۔ اس فائل میں کوئی ID داخل نہ کریں۔

حصہ B. GKE پر AWS ڈیٹا بیس کھولنا

براہ کرم اسے 'جی کے ای کو ڈیٹا بیس سے جوڑیں' کے طور پر بیان نہ کریں۔ اس جملے کا مطلب ہے کہ ڈیٹا بیس بھی حرکت کر رہا ہے، لیکن ایسا نہیں ہے۔ یہ قدم اس بات کو یقینی بناتا ہے کہ GKE محفوظ طریقے سے حقیقی، غیر منتقل شدہ AWS ڈیٹا بیس تک پہنچ سکتا ہے اور استعمال کر سکتا ہے۔

کلسٹر میں موجود مشینوں میں عوامی IPs نہیں ہیں۔ آؤٹ باؤنڈ ٹریفک کلاؤڈ NAT کو ایک واحد عوامی پتہ کا استعمال کرتے ہوئے چھوڑ دیتا ہے، NAT IP لیول 2 سے۔ RDS پورٹ 5432 پر بالکل اسی ایڈریس سے کنکشن قبول کرتا ہے، اور کنکشن سٹرنگ پہلے سے ہی TLS پر مشتمل ہے۔sslmode=require)۔

GKE Pod  (clearpay-api)
   │
   ▼
Private node  (no public IP)
   │
   ▼
Cloud NAT  (clearpay-nat-ip)
   │
   │  public egress, one /32
   ▼
AWS security group  (additional_db_ingress_cidrs)
   │  port 5432 + SSL
   ▼
RDS PostgreSQL 16

یہ دو بادلوں کو جوڑنے کے تین طریقوں میں سے ایک ہے۔

اختیارات	ترتیب	پیشگی	یہ کیا ہے
پبلک اینڈ پوائنٹ + آئی پی وائٹ لسٹ	چند Terraform متغیرات	$0 شامل کریں (عام انٹرنیٹ ٹرانسمیشن)	RDS کو ایک عوامی IP ملتا ہے۔ سیکورٹی گروپ صرف Cloud NAT کی اجازت دیتا ہے۔ /32. TLS درکار ہے۔
کلاؤڈ وی پی این (سائٹ ٹو سائٹ)	وقت: دونوں بادلوں کا گیٹ وے	تقریباً $36 فی سرنگ فی سرنگ فی مہینہ GCP پر + $36 فی مہینہ AWS پر (GCP VPN قیمتوں کا تعین)	ذاتی راستہ۔ RDS کے پاس پبلک اینڈ پوائنٹس نہیں ہیں۔ یہ اس ذخیرہ میں نہیں ہے۔
AWS کے لیے پارٹنر ٹو کلاؤڈ انٹر کنکشن	اصل فراہمی کا لیڈ ٹائم	فکسڈ 10 یا 100 Gbps ٹائر (کراس کلاؤڈ انٹرکنیکٹ)	یہ ہائی ٹریفک کیسز کے لیے ایک سرشار نجی لنک ہے۔ یہ اس ذخیرہ میں نہیں ہے۔

اپنے نظام سے موازنہ کرنے کے لیے:

(expected monthly GB) × (price per GB on that path) + fixed monthly cost of that option

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

NAT IP حاصل کریں۔

cd infra/gcp/terraform/02-network
terraform output nat_ip_address

ڈالو infra/aws/terraform/terraform.tfvars:

db_publicly_accessible      = true
additional_db_ingress_cidrs = ["/32"]

پھر AWS اسٹیک لگائیں۔

cd infra/aws/terraform
terraform plan
terraform apply

یہ منصوبہ NAT IP کے لیے ایک نیا سیکیورٹی گروپ رول شامل کرتا ہے اور RDS سے عوامی رابطے کی اجازت دیتا ہے۔ آپ کو ایسے قوانین کو نہیں ہٹانا چاہیے جو EC2 سرورز کو RDS تک پہنچنے کی اجازت دیتے ہیں۔ یہ Terraform میں دو الگ الگ اصول ہیں۔ aws_security_group_rule.db_from_nat GKE اور کے لیے aws_security_group_rule.db_from_api EC2 کے لیے۔

چیک کریں

AWS کو اب بھی ڈیٹا بیس سے کنکشن درکار ہے۔ ذخیرہ کی جڑ سے:

export INSTANCE_IP=$(terraform -chdir=infra/aws/terraform output -raw instance_public_ip)
curl -k https://$INSTANCE_IP/health/ready

{"status":"ready", ... "platform":"aws" ...}

جب یہ پرنٹ کرتا ہے۔ not_readyمتبادل طور پر، AWS لاگ ان صفحہ کچھ اس طرح دکھائے گا: internal errorڈیٹا بیس نے EC2 سرورز کو قبول کرنا بند کر دیا ہے۔ یہاں رکیں اور ٹیرافارم پلان کو دوبارہ پڑھیں۔ AWS اب بھی تمام صارفین کو خدمات فراہم کرتا ہے، لہذا براہ کرم GKE استعمال کرنے سے پہلے AWS کو ٹھیک کریں۔

جاری رکھنے سے پہلے چیک کریں۔

باب 14 میں، آپ اپنا کوڈ دبائیں اور اپنی پائپ لائن شروع کریں۔ اگر آپ مندرجہ بالا مراحل میں سے کسی کو چھوڑ دیتے ہیں، تو پائپ لائن دو ابواب کے بعد ناکام ہو جائے گی اور آپ کو ایک ایسی خامی نظر آئے گی جو آپ کو یہ نہیں بتائے گی کہ آپ نے کون سا مرحلہ چھوڑا ہے۔ اس کے بجائے، ابھی یہ ٹیسٹ چلائیں۔ پرنٹ ok یا MISSING پائپ لائن میں درکار ہر شے کے لیے۔ ذخیرہ کی جڑ سے چلائیں:

export INSTANCE_IP=$(terraform -chdir=infra/aws/terraform output -raw instance_public_ip)
NAT_IP=$(terraform -chdir=infra/gcp/terraform/02-network output -raw nat_ip_address)
DB_HOST=$(terraform -chdir=infra/aws/terraform output -raw db_endpoint | cut -d: -f1)

grep -q '^db_publicly_accessible *= *true' infra/aws/terraform/terraform.tfvars 
  && echo "ok   RDS public setting" 
  || echo "MISSING db_publicly_accessible = true in infra/aws/terraform/terraform.tfvars"
grep -q "$NAT_IP/32" infra/aws/terraform/terraform.tfvars 
  && echo "ok   NAT IP in the allowlist" 
  || echo "MISSING $NAT_IP/32 in additional_db_ingress_cidrs"
kubectl get csidriver secrets-store-gke.csi.k8s.io >/dev/null 2>&1 
  && echo "ok   Secret Manager driver" 
  || echo "MISSING Secret Manager driver: run the two gcloud commands in Part A"
kubectl get crd secretsyncs.secret-sync.gke.io >/dev/null 2>&1 
  && echo "ok   Secret Sync" 
  || echo "MISSING Secret Sync: run the two gcloud commands in Part A"
curl -sk https://$INSTANCE_IP/health/ready | grep -q '"status":"ready"' 
  && echo "ok   AWS still reaches its database" 
  || echo "MISSING AWS cannot reach its database: read the Terraform plan again"

حتمی چیک GKE سے ڈیٹا بیس تک کے اصل راستے کی جانچ کرتا ہے۔ یہ ایک چھوٹا ڈسپوزایبل پوڈ شروع کرتا ہے، پوچھتا ہے کہ کیا یہ ڈیٹا بیس پورٹ سے کنکشن کی اجازت دیتا ہے، اور پوڈ کو حذف کر دیتا ہے۔ جب Kubernetes تصویر کو ڈاؤن لوڈ کرتا ہے تو پہلی رن تقریباً ایک منٹ لیتی ہے۔

kubectl run dbcheck --rm -i --restart=Never --image=postgres:16 -- 
  pg_isready -h "$DB_HOST" -p 5432 -t 10 
  && echo "ok   GKE reaches the database" 
  || echo "MISSING GKE cannot reach the database"

مجھے 6 کی ضرورت ہے۔ ok لائن اور نہیں MISSING. ہر ایک MISSING لائن ترمیم کا نام دیتی ہے۔ درخواست دیں اور پھر اسکین دوبارہ چلائیں۔ باب 14 شروع نہ کریں جب تک کہ تمام 6 پرنٹ نہ ہوں۔ ok.

اگر آخری لائن میں کچھ اس طرح ہے: MISSING لیکن پہلے دو کہتے ہیں: okRDS اب بھی تبدیلیاں لاگو کر سکتا ہے۔ تقریباً 2 منٹ انتظار کریں اور کمانڈ کو دوبارہ چلائیں۔

مکمل ہونے پر:

• دونوں gcloud container clusters update کمانڈ مکمل ہو گیا۔

• RDS NAT IP اور curl -k https://$INSTANCE_IP/health/ready اب بھی پرنٹ میں ready

• مندرجہ بالا چیک پر 6 چھپی ہوئی ہے۔ ok لائن اور نہیں MISSING

باب 14۔ CI/CD پائپ لائن بنانا

منگل سہ پہر 3 بجے

آپ کا کلسٹر آپ کی پہلی تعیناتی کے لیے تیار ہے۔ مایا ٹیم چینل کو پڑھتی ہے اور ایک اصول کا اضافہ کرتی ہے۔

مایا: "چلو اب سے نہیں بھاگنا۔ kubectl apply ہاتھ سے تیاری۔ پائپ لائن کو ہر بار اسی طرح تصاویر بنانا، اسکین کرنا، دھکا دینا اور تعینات کرنا چاہیے۔

ورک فلو فائل پہلے ہی بن چکی ہے۔ .github/workflows/deploy.yml. آپ کا کام اسے سمجھنا، اسے گوگل کلاؤڈ سے جوڑنا، اور اسے تعیناتی کے لیے تیار ہوتے دیکھنا ہے۔

پائپ لائن کیوں؟

جب ہاتھ سے رکھا جائے تو ہر بیچ تھوڑا مختلف ہوتا ہے۔ کسی نے اسکین کو چھوڑ دیا کیونکہ وہ دیر سے تھے۔ کوئی لیپ ٹاپ سے غیر منظم تبدیلیاں تعینات کرتا ہے۔ کچھ ٹوٹ جائے تو کوئی نہیں بتا سکتا کہ کیا بھاگا۔

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

پائپ لائنز کیسے کام کرتی ہیں۔

ورک فلو کے دو کام ہیں:

کھلا .github/workflows/deploy.yml اسے اپنے ذخیرہ میں محفوظ کریں اور اس خاکہ کے ساتھ اسے کھلا رکھیں۔ خاکہ ورک فلو اور ان کی ترتیب میں دو کاموں کا نقشہ بناتا ہے۔ فائل میں اصل GitHub ایکشن کنفیگریشن ہے۔ جب آپ محرکات، اجازتیں، امیجز بنائیں اور اسکین کریں، اسٹیجنگ تعینات کریں، اور پروڈکشن کو فروغ دیں تو ان کو ایک ساتھ فالو کریں۔

فائل کو اوپر سے نیچے تک پڑھنے کے لیے اس نقشے کا استعمال کریں۔

محرک: on: push: branches: [main] ہر دھکے پر ٹاسک 1 چلائیں۔ main. workflow_dispatch ایک چیک باکس کے ساتھ GitHub میں "رن ورک فلو" بٹن شامل کریں۔ promote_to_production. ٹاسک 1 تبھی چلے گا جب اس کا باکس آف ہو گا (if: ${{ !inputs.promote_to_production }})۔ ٹاسک 2 صرف آن ہونے پر چلے گا۔ اکیلے پش آپ کو پیداوار میں نہیں لے جائے گا۔

اتھارٹی: id-token: write ٹاسک کو GitHub سے قلیل المدت OIDC ٹوکن کی درخواست کریں، جو کہ ایک دستخط شدہ تفصیل ہے جس میں کہا گیا ہے کہ "یہ ایگزیکیوشن ریپوزٹری X سے تعلق رکھتا ہے۔" گوگل اس بیان کو پول کے خلاف مرحلہ 5 سے چیک کرتا ہے اور اس کے لیے عارضی اسناد واپس کرتا ہے: clearpay-ci. GitHub رازوں میں کلیدی فائلیں نہیں ہیں، لہذا لیک ہونے کی کوئی چابیاں نہیں ہیں۔

تصویری ٹیگز: ٹیگ مندرجہ ذیل مختصر کمٹ SHA ہے: git rev-parse --short HEAD. ہر تصویر بالکل ایک کمٹ کی طرف اشارہ کرتی ہے۔ پائپ لائن موو ٹیگز کو بھی دھکیلتی ہے۔ staging-latestتاہم، تعیناتی SHA کا استعمال کرتی ہے۔

انجکشن: ٹریوی ایک اوپن سورس سکینر ہے جو معلوم کمزوریوں کی فہرست کے خلاف تصویر کے اندر پیکجوں کو چیک کرتا ہے۔ ہر معروف خطرے کی درج ذیل ID ہوتی ہے: CVE-2026-29786. ورک فلو ترتیب دیتا ہے:

• severity: CRITICAL,HIGHلہذا، صرف سنگین نتائج کا حساب کیا جاتا ہے.

• ignore-unfixed: trueابھی تک کوئی پیچ دستیاب نہ ہونے کے نتائج تعمیر کو مسدود نہیں کریں گے۔

• exit-code: "1"باقی نتائج کے نتیجے میں آپریشن ناکام ہو جاتا ہے۔

ایک ساتھ استعمال کیا جاتا ہے، اس کا مطلب ہے کہ اگر ایک اہم خطرے میں کوئی بہتری ہے اور یہ تصویر نہیں ہے، تو یہ ناکام ہو جائے گی۔ اگر اسکین ناکام ہوجاتا ہے، تو کچھ بھی نہیں دھکیلا جاتا ہے۔

دھکا: ٹاسک ہر تصویر کو اس کے مکمل رجسٹری پاتھ کے ساتھ ٹیگ کرتا ہے۔ us-east4-docker.pkg.dev//clearpay/api:اور اسے دور دھکیل دیتا ہے۔ clearpay-ci ہے artifactregistry.writer پش مرحلہ 5 سے کام کرے گا۔

اسٹیجنگ پر تعینات کریں: قدم اندر سے باہر سے کام کرتے ہیں۔ k8s/overlays/staging:

1. سیکرٹ مینیجر سے دو اسٹیجنگ راز secrets.staging.env دوڑنے والوں پر۔ umask 077 فائل کو صرف ایگزیکیوٹر کے صارف کے ذریعہ پڑھنے کے قابل بناتا ہے۔ فائل کو نظر انداز کیا جاتا ہے اور رنر کے ساتھ ہی مر جاتا ہے۔

2. sed تبدیل کریں PROJECT_ID پلیس ہولڈر patch-serviceaccount.yaml اور secretproviderclass.yaml اصل پروجیکٹ ID کے ساتھ

3. kustomize edit set image تصویر کے اوورلے کی طرف اشارہ کرنے کے لیے اس کمٹ سے SHA کا استعمال کریں۔

4. kubectl apply -k . اوورلے کو کلسٹر میں بھیجیں۔

5. kubectl rollout status API اور UI Pods کے تیار ہونے کے لیے 180 سیکنڈ تک انتظار کریں۔ ایسا نہ کرنے سے آپریشن ناکام ہو جائے گا۔

clearpay-ci ہے container.developerآپ کام کے بوجھ کو تعینات کر سکتے ہیں، لیکن خود کلسٹر کو تبدیل نہیں کیا جا سکتا۔

پیداوار کو فروغ دینا: ٹاسک 2 واحد راستہ ہے جو پائپ لائن پیداوار تک پہنچتا ہے۔

• environment: production کام کو اس وقت تک موقوف کریں جب تک کہ نامزد جائزہ لینے والا GitHub پر Approve پر کلک نہ کرے۔

• یہ کچھ نہیں بناتا۔ امیج اسٹرنگ کو پڑھتا ہے جس پر اسٹیجنگ فی الحال چل رہی ہے اور صحیح امیج کو پروڈکشن میں تعینات کرتا ہے۔

اس اصول کو "ایک بار بنائیں، ایک جیسے نمونے کو فروغ دیں" کہا جاتا ہے۔ باب 15 گیٹ سے گزرنے والی تصویر گاہک کو بائٹ بائٹ ملتی ہے۔ دوبارہ تعمیر آپ کو ایک نیا پیکیج لینے اور ایک ایسی مصنوعات کو جاری کرنے کی اجازت دیتی ہے جس کا تجربہ کسی نے نہیں کیا ہے۔

Kustomize کے پیچھے والا ٹول تعیناتی کے دونوں مراحل میں استعمال ہوتا ہے۔ kubectl apply -k. مشترکہ فائلیں حاصل کریں۔ k8s/base/ چھوٹی، ماحول کے لحاظ سے مخصوص تبدیلیاں کریں۔ k8s/overlays/staging/ یا k8s/overlays/production/اسے اوورلے کہتے ہیں۔ سٹیجنگ اور پروڈکشن ایک مشترکہ بنیاد کا اشتراک کرتے ہیں اور صرف اس چیز میں مختلف ہوتے ہیں جس کی انہیں ضرورت ہوتی ہے۔

قدم

سب سے پہلے، اس ذخیرہ کو اپنے اکاؤنٹ کے تحت GitHub پر رکھیں۔ main بنیادی بات کی طرف۔

پھر ہمیں بتائیں کہ کون سے ذخیرے دستیاب ہیں۔ clearpay-ci. کھلا infra/gcp/terraform/05-identity/terraform.tfvars اور سیٹ github_repo آپ کے ذخیرے میں owner/nameمثال کے طور پر Osomudeya/migrate-api-aws-gke-devops. پوری چیز کو چسپاں نہ کریں۔ https://github.com/... پتہ، اور نہیں .git آخر میں۔ مرحلہ 5 دوبارہ لاگو کریں۔

cd infra/gcp/terraform/05-identity
terraform plan
terraform apply

منصوبہ پول کی جائیداد کے حالات کو تبدیل کرتا ہے اور clearpay-ci لنک یہ کلسٹر کو نہیں چھوتا ہے۔ اگر آپ نے پہلے ہی باب 11 میں اپنا اصلی نام ترتیب دیا ہے، تو آپ کو اپنے پلان میں کوئی تبدیلی نظر نہیں آئے گی۔

GitHub پر اپنا ذخیرہ کھولیں اور ترتیبات پر کلک کریں۔ بائیں مینو میں، راز اور متغیر پر کلک کریں، اور پھر اعمال پر کلک کریں۔ متغیرات کا ٹیب کھولیں اور ان تینوں میں سے ہر ایک کے لیے نیا ذخیرہ متغیر پر کلک کریں۔ ریپوزٹری سیکشن کا استعمال کریں، نہ کہ ماحول۔

نام	قدر
GCP_PROJECT_ID	GCP پروجیکٹ ID
GCP_WORKLOAD_IDENTITY_PROVIDER	طاقت کی پیداوار terraform -chdir=infra/gcp/terraform/05-identity output -raw github_actions_workload_identity_provider
GCP_CI_SERVICE_ACCOUNT	طاقت کی پیداوار terraform -chdir=infra/gcp/terraform/05-identity output -raw ci_service_account_email

یہ کوئی راز نہیں ہے، یہ ایک متغیر ہے۔ ان میں سے کوئی بھی پاس ورڈ نہیں ہے۔ پائپ لائن کو کسی GitHub راز کی ضرورت نہیں ہے۔

اگر آپ دو آؤٹ پٹ کاپی کرتے ہیں تو آپ کو مل جاتا ہے۔ terraform output -raw حکم دیں، نقل نہ کریں۔ % آخر میں۔ میک پر، ٹرمینل دکھاتا ہے: % اگر آؤٹ پٹ کے بعد کوئی لائن بریک نہیں ہے۔ یہ قیمت کا حصہ نہیں ہے۔ فراہم کنندہ کی قدر اس کے ساتھ ختم ہونی چاہیے: clearpay-github-providerسروس اکاؤنٹ اس کے ساتھ ختم ہونا چاہیے: .iam.gserviceaccount.com.

پھر، ترتیبات میں، ماحولیات پر کلک کریں، پھر نیا تجربہ۔ براہ کرم اس کا نام دیں۔ production ماحول کو ترتیب دیں پر کلک کریں۔ مطلوبہ جائزہ لینے والوں کو منتخب کریں، ان کے GitHub ناموں کو تلاش کریں اور منتخب کریں، اور پروٹیکشن رول محفوظ کریں پر کلک کریں۔

کیوں: نوکری 2 پیداوار کا واحد راستہ ہے۔ مطلوبہ جائزہ لینے والے GitHub پر کارروائی کو روکتے ہیں اور اسے کسی انسان کے منظور پر کلک کرنے کا انتظار کرنے پر مجبور کرتے ہیں، اور اسے غلطی سے گاہک کو منتقل ہونے سے روکتے ہیں۔ جاب 2 باب 19 میں منظوری کا منتظر ہے۔

اس صفحہ پر آپ کو Environment Secrets کا انتظام کرنے کا بٹن نظر آئے گا۔ کلک نہ کریں۔ کہ production آپ کے ماحول کو راز کی ضرورت نہیں ہے کیونکہ آپ کی پائپ لائن ذخیرہ شدہ پاس ورڈ کے بجائے آپ کے کام کے بوجھ کی شناخت کے ذریعے Google تک رسائی حاصل کر سکتی ہے۔ اگر آپ کے پاس پہلے سے ہی آپ کے ذخیرے میں دوسرے پروجیکٹس کے راز ہیں تو ان رازوں کو چھوڑ دیں۔

اگر GitHub اسے پیش نہیں کرتا ہے۔ جائزہ لینے والا مطلوب ہے۔مفت پلان کے تحت آپ کا ذخیرہ نجی ہو سکتا ہے۔ اس لیب کے ذخیرے کو عوامی بنائیں یا جائزہ لینے والوں کو چھوڑ دیں۔ اگر کوئی نہیں ہے تو، پروڈکشن کا کام شروع ہوتے ہی چل جائے گا۔

اگلا، آگے بڑھانے سے پہلے چیک کریں. ایک ناکام پائپ لائن کی لاگت 3 منٹ ہے اور لمبے لاگ فراہم کرتی ہے۔ چیک کی قیمت 10s ہے۔ سب سے پہلے، باب 13 کے آخر سے دوبارہ چیک کریں۔ تمام 6 لائنیں پرنٹ ہونی چاہئیں۔ ok. پھر اس ریپوزٹری کا نام چیک کریں جو آپ نے گوگل کو فراہم کیا ہے۔

REPO=$(grep '^github_repo' infra/gcp/terraform/05-identity/terraform.tfvars | cut -d'"' -f2)
case "$REPO" in
  https*|*.git|YOUR_GITHUB_USER/*) echo "MISSING github_repo must be owner/name. It is: $REPO" ;;
  */*) echo "ok   github_repo $REPO" ;;
  *)   echo "MISSING github_repo must be owner/name. It is: $REPO" ;;
esac

پرنٹ کرنے کی ضرورت ہے ok اور آپ کے اپنے owner/name.

اب پائپ لائن کو متحرک کریں۔

git commit --allow-empty -m "trigger pipeline"
git push

چیک کریں

افتتاحی عمل ٹیب پر کلک کریں اور چلنے والے ورک فلو پر کلک کریں۔ اگلے اقدامات پر نظر رکھیں۔ build-scan-push انہیں ایک ایک کرکے مکمل کریں۔ ہر آئٹم پر ایک چیک مارک ہوتا ہے۔ تعمیر اسکین API امیج، UI امیج اسکین، GCP سے تصدیق کریں۔دھکا اسٹیجنگ پر تعینات کریں۔.

جب کوئی قدم سرخ ہو جائے تو اسے یہاں تلاش کریں۔ ہر مرحلہ ورک فلو کو دوبارہ چلانے کے پیغام کے ساتھ ختم ہوتا ہے۔

سرخ قدم	تحریک
اسکین API امیج یا UI امیج اسکین	"اگر اسکین ناکام ہوجاتا ہے"
GCP سے تصدیق کریں۔	'اگر جی سی پی کی توثیق ناکام ہوجاتی ہے'
اسٹیجنگ پر تعینات کریں۔	"اگر سٹیجنگ پر تعیناتی ناکام ہو جاتی ہے"

ترمیم کے بعد دوبارہ چلانے کے لیے عمل ٹیب میں، ناکام رنز پر کلک کریں اور تمام کام دوبارہ کریں۔ اوپر دائیں طرف۔ دوبارہ دھکیلنے کی ضرورت نہیں۔

دوسرا کام، پیداوار کو فروغ دیاسلیش کے ساتھ ایک سرمئی دائرہ ظاہر ہوتا ہے۔ تم ٹھیک ہو GitHub جب بھی آپ دباتے ہیں اسے چھوڑ دیتا ہے۔ یہ صرف اس وقت چلتا ہے جب براہ راست باب 19 سے شروع ہوتا ہے۔

جب اسٹیجنگ پر تعینات کریں۔ اگر یہ گزر جاتا ہے تو کلسٹر کو چیک کریں۔

kubectl -n staging get pods

آپ API اور UI پوڈز دیکھیں گے۔ Running کے ساتھ READY 1/1.

سٹیجنگ کا کوئی عوامی پتہ نہیں ہے اور لوڈ بیلنس اب بھی تمام صارفین کو AWS پر بھیجتا ہے۔ تیاری کے لیے اپنا براؤزر نہ کھولیں۔ باب 15 ایک ذاتی سرنگ کے ذریعے پہنچا ہے۔

اگر اسکیننگ ناکام ہوجاتی ہے۔

کبھی نہیں بدلتے exit-code: "1" کو "0". اس سے سیکورٹی گیٹ بند ہو جائے گا۔

ڈاکر فائل پہلے ہی پیچ شدہ ہے، لہذا چیک پاس ہونا چاہئے۔ نئے حفاظتی سوراخ مستقبل میں سرخ ہو سکتے ہیں۔ ریڈ ٹاسک کھولیں۔ ٹریوی ٹیبل پرنٹ کرتا ہے۔ تلاش کریں۔ ہدف کالم تلاش کریں اور میچ کریں۔

ہدف کالم	معنی	کیا کرنا ہے
آپریٹنگ سسٹمز میں شامل ہیں: debian 12.xفکسڈ کالم کا ورژن ہے۔	پہلے سے طے شدہ تصویر پیچھے ہے۔	دوبارہ تعمیر کریں۔ اگر یہ سرخ رہتا ہے تو آگے بڑھیں۔ FROM node:22-slim تازہ ترین 22.x-slim Docker Hub میں ٹیگز شامل کریں۔
usr/local/lib/node_modules/npm	npm پیکج بھیجتا ہے۔	Dockerfile ڈیلیٹ npm چیک کریں کہ آیا ڈیلیٹ لائن ابھی بھی موجود ہے۔
app/node_modules یا package-lock.json	ClearPay پیکجوں میں سے ایک پیچھے ہے۔	اسے مارو api/package.json یا ui/package.json
الپائن پیکج، UI امیج اسکینفکسڈ ورژن بھی شامل ہے۔	UI ڈیفالٹ امیج اس کے پیچھے ہے۔	شامل کریں RUN apk upgrade --no-cache nginx اقدامات ui/Dockerfile.prod

Dockerfile کو تبدیل کرنے کے بعد، مقامی طور پر دوبارہ تعمیر کریں اور یقینی بنائیں کہ صارف اب بھی درست ہے۔ appuser:

docker build -t clearpay-api:test ./api
docker run --rm clearpay-api:test whoami

عہد کرنا، دھکا دینا mainکلک کریں اور ایکشن دوبارہ دیکھیں۔

اگر GCP کی توثیق ناکام ہوجاتی ہے۔

غلطی یہ ہے:

The given credential is rejected by the attribute condition.

گوگل نے قبول کیا اور پھر GitHub ٹوکنز کو مسترد کر دیا۔ مرحلہ 5 دوسرے ریپوزٹری کے لیے ایک نام بتاتا ہے، اکثر پلیس ہولڈر کا استعمال کرتے ہوئے۔ YOUR_GITHUB_USER/YOUR_REPO. اقدار بالکل درست ہونے چاہئیں۔ owner/nameشب بخیر Osomudeya/migrate-api-aws-gke-devops. مکمل URL مماثل نہیں ہے، اور نہ ہی کسی اور کا ذخیرہ۔ صحیح اقدار کے ساتھ اوپر والا مرحلہ 2 دہرائیں۔ owner/name. پھر اپنے ورک فلو کو تبدیل کیے بغیر دوبارہ کوشش کریں۔

git commit --allow-empty -m "retry pipeline after WIF repo lock"
git push

اگر اسٹیجنگ پر تعیناتی ناکام ہوجاتی ہے۔

دونوں پیغامات کا مطلب ایک ہی ہے۔ error: timed out waiting for the condition اور error: deployment "clearpay-api" exceeded its progress deadline. فائل لگائی گئی ہے، لیکن پوڈ تیار نہیں ہے۔ اپنے کلسٹر سے پوچھیں کیوں:

kubectl -n staging get pods
kubectl -n staging describe pod -l app=clearpay-api

پھر جو آپ دیکھتے ہیں اس سے ملائیں۔ پہلی دو لائنیں جاب لاگ میں ظاہر ہوتی ہیں۔ باقی پوڈ آؤٹ پٹ میں ظاہر ہوں گے۔

جو تم دیکھتے ہو	معنی	کیا کرنا ہے
no matches for kind "SecretProviderClass" یا "SecretSync"	سیکرٹ مینیجر ایڈ آن کو غیر فعال کر دیا گیا ہے۔	دو چلائیں gcloud باب 13، حصہ A آرڈر۔ ورک فلو کو دوبارہ چلائیں۔
Permission denied کو gcloud secrets versions access	پائپ لائن اکاؤنٹس اسٹیجنگ راز نہیں پڑھ سکتے ہیں۔	مرحلہ 6 دوبارہ لاگو کریں (ذیل میں ترمیم A)۔
ImagePullBackOff کے ساتھ 403 Forbidden	کلسٹر مشین رجسٹری نہیں پڑھ سکتی۔	مرحلہ 4 دوبارہ لگائیں اور پھر پوڈ کو دوبارہ شروع کریں (ذیل میں ترمیم B)۔
Insufficient cpu	کلسٹر بڑھ رہا ہے یا بھرا ہوا ہے۔	چلائیں kubectl get nodes. 3 سے کم مشینیں: براہ کرم چند منٹ انتظار کریں۔ 3 مشینیں: ترازو 1 API پوڈ (ذیل میں C میں ترمیم کریں) تک پہنچتا ہے۔
FailedMount کے ساتھ driver ... not foundیا secret "clearpay-api-secrets" not found	نئی مشین ابھی شروع ہو رہی ہے یا سیکرٹ سنک نے ابھی تک راز نہیں لکھا ہے۔	براہ کرم 2 منٹ انتظار کریں۔ پوڈ اپنے طور پر دوبارہ کوشش کرے گا۔ اسے چیک کریں kubectl -n staging get secret clearpay-api-secrets.
Running لیکن READY 0/1کے ساتھ Connection terminated due to connection timeout یا Readiness probe failed	Pod PostgreSQL سے منسلک نہیں ہو سکتا۔	باب 13 کے آخر میں چیک چلائیں۔ MISSING لائنیں نامکمل کام دکھاتی ہیں۔ باب 13، حصہ B ایک عام وجہ ہے۔ اگلی صحت کی جانچ پر پھلی خود تیار ہو جائے گی۔

ٹھیک کریں A۔ پائپ لائن کو سٹیجنگ سیکرٹ تک رسائی دیں۔

cd infra/gcp/terraform/06-secrets
terraform plan
terraform apply

B میں ترمیم کریں۔ کلسٹر کو رجسٹری پڑھنے کو کہیں۔ مشینیں پہلے سے طے شدہ کمپیوٹ انجن سروس اکاؤنٹ کے ساتھ تصاویر کھینچتی ہیں۔ artifactregistry.reader. منصوبہ ایک اصول کا اضافہ کرتا ہے:

cd infra/gcp/terraform/04-registry
terraform plan
terraform apply

پھر اسٹیجنگ پوڈ کو دوبارہ شروع کریں اور انتظار کریں۔

kubectl -n staging rollout restart deployment/clearpay-api deployment/clearpay-ui
kubectl -n staging rollout status deployment/clearpay-api --timeout=180s
kubectl -n staging rollout status deployment/clearpay-ui --timeout=180s

C میں ترمیم کریں۔ سٹیجنگ میں ایک API پوڈ چلائیں۔ ایک چھوٹا لیب کلسٹر دو فٹ نہیں ہو سکتا۔ اسکیل کرنے کے بعد، ورک فلو کو دوبارہ چلائیں۔

kubectl -n staging scale deployment/clearpay-api --replicas=1

بغیر پرنٹنگ کے API لاگز کو پڑھنے کے لیے، ان ہدایات پر عمل کریں:

kubectl -n staging logs deployment/clearpay-api --tail=20

مکمل ہونے پر:

• کیا آپ وضاحت کر سکتے ہیں کہ ہر دو کام کیا ہے؟ deploy.yml کرو

• کہ production ایک ماحول ایک مطلوبہ جائزہ نگار کے طور پر موجود ہے۔

• اسٹیجنگ پر تعینات کریں۔ گزر گیا

• kubectl -n staging get pods API اور UI دکھاتا ہے۔ Running، READY 1/1

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

باب 15 سٹیجنگ چیک کریں اور پروموشن گیٹ چلائیں۔

دوسرا بدھ صبح 10 بجے

پائپ لائن گزشتہ رات 6:40 پر بغیر کسی غلطی کے مکمل ہوئی۔ آپ نے اسکرین شاٹ لیا۔ ClearPay پر کوئی بھی اسکرین شاٹس کی پرواہ نہیں کرتا ہے۔

ڈینیئل اپنی میز پر رک جاتا ہے اور گزرتی ہوئی پائپ لائن کو دیکھتا ہے۔

ڈینیل: "تو کیا جی کے ای صحت مند ہے؟"

آپ جواب دیتے ہیں، "برتن صحت مند ہے، لیکن اس سے یہ ثابت نہیں ہوتا کہ گاہک $20 بھیج سکتا ہے۔"

مایا نے تھریڈ پڑھا۔ وہ ایک لائن کا اضافہ کرتی ہے:

مایا: "گاہک اس وقت تک یہ تعمیر حاصل نہیں کر سکتے جب تک کہ پروموشن اسکرپٹ پاس نہ ہو جائے۔ صرف پوڈ چلانا کافی نہیں ہے۔"

یہ کیوں اہمیت رکھتا ہے۔

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

پروموشن گیٹ ایک اسکرپٹ ہے جسے آپ اپنے لیپ ٹاپ پر چلاتے ہیں۔ پائپ لائن اس پر عمل نہیں کرتی ہے۔ یہ سرمئی بھی نہیں ہے۔ پیداوار کو فروغ دیا یہ وہ کام ہے جو میں نے GitHub پر دیکھا تھا۔ یہ بعد میں، باب 19 میں، اور صرف اس گیٹ وے سے گزرنے کے بعد آتا ہے۔

اسٹیجنگ کیسے چلائیں۔

GKE cluster "clearpay"   zone us-east4-a
│
├── namespace staging
│     Service clearpay-api :80
│     └── API pods   (HPA 1–3)
│
└── namespace production   (created in Chapter 19)
      Gateway clearpay-gke-edge   ← clearpay-gke-edge-ip
      HTTPRoute → Service :80
      └── API pods   (HPA 1–3)
            each pod: DB_POOL_SIZE=10

ڈینیئل اسی چارٹ کو دیکھتا ہے۔

"میں پروڈکشن میں کتنے API عمل چلا سکتا ہوں؟"

"اس کلسٹر میں زیادہ سے زیادہ 3 ہیں۔ یہ HPA کی حد ہے۔ patch-hpa.yaml"

"اور ہر ایک کے کتنے ڈیٹا بیس کنکشن کھل سکتے ہیں؟"

"10. ایک ہی چیز۔ db.js "پیر کو۔"

"تو ڈیٹا بیس کیا دیکھ سکتا ہے؟"

اسے روکو۔ GKE پر 30۔ AWS 10 کا اضافہ کرتا ہے جبکہ دونوں فعال ہیں۔ ایک کلسٹر میں جو 8 پوڈز تک پیمانہ کر سکتا ہے، اکیلے GKE کے پاس 80 ہیں۔

"یہ وہ نمبر ہے جو میں نے آپ سے یاد رکھنے کو کہا تھا۔" ڈینیل کہتے ہیں:

اب یہ تین فائلوں کو کھولنے کے قابل ہے:

• k8s/base/deployment.yaml: اسٹیٹس چیک کال /health/readyہر API پوڈ ریزرویشن کرتا ہے۔ 250m سی پی یو اور 256Mi یادداشت

• k8s/base/networkpolicy.yaml: محدود کریں کہ کون سے پوڈ API کے ساتھ بات چیت کرسکتے ہیں۔

• k8s/overlays/staging/patch-deployment.yaml: اسٹیجنگ کے لیے نقل کی گنتی اور رول آؤٹ کی ترتیبات۔

مرحلہ 1۔ GKE میں ڈیٹا بیس کا راستہ چیک کریں۔

اسٹیجنگ API پوڈ کے اندر ایک لائن نوڈ اسکرپٹ چلائیں۔ ڈیٹا بیس کنکشن کھولیں اور پرنٹ کریں۔ connected:

kubectl -n staging exec deployment/clearpay-api -- node -e 
  "require('./src/db').checkConnection().then(() => { console.log('connected'); process.exit(0); }).catch(e => { console.error(e); process.exit(1); })"

connected

مرحلہ 2۔ اپنی خفیہ آمد کی تصدیق کریں۔

Kubernetes دو کلیدوں کے ساتھ مطابقت پذیر راز رکھتا ہے۔ describe کلیدی ناموں اور سائزوں کی فہرست بنائیں، اقدار کی نہیں۔

kubectl -n staging get secret clearpay-api-secrets
kubectl -n staging describe secret clearpay-api-secrets

API کے عمل میں اقدار کو پرنٹ کیے بغیر چیک کیا جاتا ہے۔

kubectl -n staging exec deployment/clearpay-api -- node -e 'if (!process.env.DATABASE_URL) process.exit(1); console.log("DATABASE_URL is set")'

DATABASE_URL is set

اسکرپٹ کو جان بوجھ کر واحد اقتباسات میں بند کیا گیا ہے۔ پہلے سے طے شدہ میک شیل، zsh، ہینڈل: ! اسے ہسٹری کمانڈ کے ساتھ ڈبل کوٹس میں رکھیں اور اس کے ساتھ رکیں: zsh: event not found.

CSI ماؤنٹ خفیہ فائلوں کو نام سے دکھاتا ہے۔

kubectl -n staging exec deployment/clearpay-api -- ls /mnt/secrets-store

اسے تلاش کریں۔ DATABASE_URL اور JWT_SECRET.

مرحلہ 3۔ پروموشن گیٹ پر عمل کریں۔

سٹیجنگ نجی ہے۔ kubectl port-forward سرنگ کھول کر localhost:8080 یہ نوٹ بک کے اسٹیجنگ API تک پہنچ جاتا ہے۔ کہ & سرنگ کو پس منظر میں چلتے رہیں۔ ذخیرہ کی جڑ سے:

kubectl -n staging port-forward svc/clearpay-api 8080:80 &

براہ کرم جاری رکھنے سے پہلے اگلی لائن کا انتظار کریں۔

Forwarding from 127.0.0.1:8080 -> 4000

عمارہ پہلے ہی تھریڈ میں ہے۔ "پلے چلائیں۔ میں ایک ڈیبٹ دیکھنا چاہتا ہوں۔"

وہی گیٹس چلائیں جو آپ نے باب 6 میں AWS کے لیے چلائے تھے۔ چار دلائل سرنگ کا یو آر ایل، ایلس کا ای میل، ایلس کا پاس ورڈ، اور باب کا ای میل ہیں۔

./scripts/promotion-gate.sh http://localhost:8080 
  alice@clearpay.dev password123 bob@clearpay.dev

PASS: health endpoint returns ok
PASS: readiness endpoint confirms DB connectivity
PASS: login succeeds and returns a token
PASS: replaying an idempotency key returns replayed=true
PASS: balance debited exactly once (100 cents), not twice

5 passed, 0 failed

GATE PASSED: safe to promote to production.

اگلا، سرنگ کو روکیں۔ kill %1.

چونکہ GKE اسی RDS ڈیٹا بیس کو AWS کے طور پر پڑھتا ہے، ایلس GKE میں بغیر کسی نئے بیج کے موجود ہے۔

مرحلہ 4۔ چیک کریں کہ آیا صارف ابھی بھی AWS پر ہے۔

سٹیجنگ کا عوامی پتہ نہیں ہوتا ہے۔

kubectl -n staging get svc clearpay-api

NAME           TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)   AGE
clearpay-api   ClusterIP   10.x.x.x               80/TCP    12m

ClusterIP کے ساتھ اس کا مطلب ہے کہ صرف کلسٹر تک ہی پہنچ سکتا ہے۔

گاہک کے پتے ابھی بھی AWS کی طرف سے جواب دیے جاتے ہیں۔

export INSTANCE_IP=$(terraform -chdir=infra/aws/terraform output -raw instance_public_ip)
curl -sk https://$INSTANCE_IP/health

{"status":"ok","served_by":{"platform":"aws",...}}

اگر آپ دیکھتے ہیں gke یہیں رک جاؤ۔ اگر curl ناکام ہوجاتا ہے، AWS نیچے چلا جاتا ہے، جو GKE سے ٹریفک حاصل کرنے سے مختلف مسئلہ ہے۔

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

Browser  →  api.clearpay.test  →  100 percent  →  AWS EC2  (serves everyone)

GKE staging  ←  your tunnel (port-forward)  ←  the gate and the load test
GKE production  (does not exist yet, Chapter 19)

گاہک صرف باب 21 کے بعد GKE سے جڑیں گے، جب حقیقی ٹریفک سامنے کے دروازے سے بھیجنا شروع ہو جائے گی۔

ناکامی کی صورت میں

براہ کرم اس تعمیر کو فروغ نہ دیں۔

• Unexpected end of JSON input یا Connection refused: اسکرپٹ کو سرنگ کے سننے سے پہلے ہی انجام دیا گیا تھا۔ اگر Forwarding from 127.0.0.1:8080 اگر آپ پہلے سے ہی ٹرمینل میں ہیں، تو صرف اسکرپٹ کو دوبارہ چلائیں۔ دوسرا پورٹ فارورڈنگ شروع نہ کریں۔

• ریاست گزر گئی، لیکن تیاری ناکام رہی۔ Pod PostgreSQL سے منسلک نہیں ہو سکتا۔ باب 13، حصہ B پر واپس جائیں۔

• لاگ ان ناکام: بیج کے لیے آپ نے جو قدر درج کی ہے اسے چیک کریں۔ alice@clearpay.dev، password123، bob@clearpay.dev.

• checkConnection TLS یا ٹائم آؤٹ کی خرابی پرنٹ کرتا ہے۔ تیاری میں ناکامی کی طرح۔ باب 13، حصہ بی۔

• کہ ls فائل ظاہر نہیں ہوتی ہے یا پوڈ پھنس جاتا ہے۔ ContainerCreating: دوڑنا kubectl -n staging describe pod خفیہ مینیجر کی اجازت کی غلطیوں کو تلاش کریں۔ سٹیجنگ پر نوٹس clearpay-api سروس اکاؤنٹ کو مرحلہ 5، خط کے لیے خط سے اسٹیجنگ ای میل سے مماثل ہونا چاہیے۔ یہ وہ ای میل ہے جسے آپ نے مرحلہ 6 میں راز کو پڑھنے کی اجازت دی ہے۔

وجہ کو درست کریں اور، اگر کوڈ یا فائلز بدل گئی ہیں، تو انہیں پائپ لائن کے ذریعے دھکیلیں اور گیٹ کو دوبارہ چلائیں۔

فیصلہ

مایا: کیا ہم تیار ہیں؟

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

مایا: "تو پھر پروڈکشن کے بارے میں بات کرتے ہیں۔ یہ پہلے کام نہیں کرتا تھا۔"

وہ واپس ٹرمینل کی طرف دیکھتی ہے۔ "اسٹیجنگ کام کر رہی ہے۔ اب براہ کرم مجھے بتائیں کہ کیا مجھے GKE کو اسی پوسٹگریس کو انٹرنیٹ پر بھیجنا جاری رکھنا چاہیے۔"

مکمل ہونے پر:

• checkConnection پرنٹس connected اسٹیجنگ پھلی میں

• DATABASE_URL is setاور /mnt/secrets-store دونوں خفیہ ناموں کی فہرست بنائیں۔

• گیٹ پرنٹ 5 passed, 0 failed سرنگ کے ذریعے

• سٹیجنگ ہے ClusterIP کوئی بیرونی IP نہیں ہے اور لچکدار IP اب بھی جواب دے رہا ہے۔ aws

یہ چوکی ہے۔ سٹیجنگ گیٹ وے سے گزرتا ہے اور GKE اصل ڈیٹا بیس تک پہنچ جاتا ہے۔

اگلا، ہم ثابت کرتے ہیں کہ گاہک کی ٹریفک اس کے منتقل ہونے سے پہلے ہی محفوظ ہے، یہاں تک کہ بوجھ کے نیچے بھی۔

حصہ 5۔ پیداوار کے لیے GKE کو کیسے دستیاب کیا جائے۔

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

ایک نئی کار کے بارے میں سوچو جس نے ابھی اپنی پہلی ٹیسٹ ڈرائیو پاس کی ہے۔ یہ شروع ہوتا ہے اور گھومتا ہے۔ کسی کے بورڈ میں آنے سے پہلے ہم مزید تین سوالات پوچھتے ہیں۔ کیا دروازہ بند ہے؟ کیا آپ ڈیش بورڈ دیکھتے ہیں؟ ایک کھڑی پہاڑی پر کیا ہوتا ہے یا اگر آپ کو چپٹا ٹائر مل جاتا ہے؟

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

سوال	صفحہ	جو آپ چیک کرتے ہیں۔
کیا آپ کو کسی چیز کا سامنا کرنا پڑا ہے؟	16	وہ شخص جو راز پڑھ سکتا ہے۔ آیا ڈیٹا بیس کنکشن کو خفیہ کیا گیا ہے۔ چاہے ہر اکاؤنٹ کے پاس صرف وہی اجازتیں ہیں جن کی اسے ضرورت ہے۔
کیا آپ دیکھ سکتے ہیں کہ کیا ہو رہا ہے؟	17 (اختیاری)	لیپ ٹاپ پر ایک پریکٹس ڈیش بورڈ جو ایپ کی ردعمل اور ناکام درخواستوں کی تعداد کو ظاہر کرتا ہے۔ اوزار سکھائیں۔ ٹریفک شفٹوں کے دوران، ہم کمانڈ لائن معائنہ کے ذریعے نگرانی کرتے ہیں۔
دباؤ میں کیا ہوتا ہے؟	18	ایک مصروف دوپہر کی طرح، بہت سی درخواستیں ایک ساتھ آتی ہیں۔ فورڈ کام کرتے ہوئے مر گیا۔ جب صارف ایپ استعمال کر رہا ہو تو دوبارہ شروع کریں۔

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

باب 16۔ سیکیورٹی کا جائزہ لیں۔

بدھ دوپہر 2 بجے

دوپہر کے کھانے کے بعد، مایا اگلا کام بھیجتی ہے۔ اس نے پائپ لائن کے نوشتہ جات پڑھے۔

مایا: "میں چاہتی ہوں کہ میرے گاہک GKE استعمال کرنے سے پہلے ان کی سیکیورٹی چیک کریں۔ میں چلانے کے بعد فائلوں میں راز تلاش نہیں کرنا چاہتی۔"

یہ کیوں اہمیت رکھتا ہے۔

ہر پچھلے معائنہ نے پوچھا، "کیا یہ کام کرتا ہے؟" یہ پوچھتا ہے، "کیا بے نقاب ہے؟" ادائیگی کے APIs کے لیے، پوسٹ لانچ جائزہ میں بہت دیر ہو چکی ہے۔

توثیق 1. ڈیٹا بیس کی ٹریفک کو خفیہ کیا گیا ہے۔

ڈیٹا بیس کنکشن بادلوں کے درمیان عوامی انٹرنیٹ کو عبور کرتے ہیں۔ چیک کریں کہ آیا آپ کے لائیو سٹیجنگ کے عمل کو URL پرنٹ کیے بغیر TLS کی ضرورت ہے۔

kubectl -n staging exec deployment/clearpay-api -- node -e "const u=process.env.DATABASE_URL||''; console.log(u.includes('sslmode=require') ? 'sslmode=require is set' : 'sslmode=require missing')"

sslmode=require is set

ٹھیک ہے 2. خفیہ چکر سمجھ میں آ گیا ہے۔

api/src/routes/auth.js مسلسل لاگ ان ٹوکن جاری کریں۔ 12h. اگر آپ اسے گھمائیں۔ JWT_SECRETپرانے ٹوکن کے ساتھ دستخط شدہ کوئی بھی ٹوکن کام کرنا چھوڑ دے گا اور صارف کو دوبارہ لاگ ان کرنا پڑے گا۔ اس لیب کے لیے اس کی اجازت ہے۔ اس جملے کو اپنی نوٹ بک میں روٹیشن پالیسی کے طور پر لکھیں۔ یہاں گردش کو خودکار نہ کریں۔

چیک کریں 3۔ چیک کریں کہ آیا آڈٹ لاگ موجود ہے۔

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

gcloud logging read 'protoPayload.serviceName=("secretmanager.googleapis.com" OR "iam.googleapis.com")' --limit=5 --freshness=7d --format="table(timestamp,protoPayload.methodName)"

مذکورہ طریقہ کا نام تلاش کریں۔ SecretManager یا iam. بس جو تم دیکھتے ہو۔ iam ایک ہی نام SetIAMPolicyتم ٹھیک ہو؟ اس سے ثابت ہوتا ہے کہ گوگل اجازت کی تبدیلیوں کو ریکارڈ کر رہا ہے۔ ٹائم سٹیمپ مختلف ہو سکتے ہیں۔

ٹھیک ہے 4. ہر ID میں صرف وہی ہوتا ہے جس کی اسے ضرورت ہوتی ہے۔

اسٹیجنگ کا اکاؤنٹ اسٹیجنگ راز کو پڑھتا ہے۔ پروڈکشن کا اکاؤنٹ پروڈکشن کا راز پڑھتا ہے۔ پائپ لائن تصاویر کو آگے بڑھاتی اور تعینات کرتی ہے، لیکن کلسٹر میں تبدیلیاں نہیں کر سکتی۔

PROJECT_ID=$(gcloud config get-value project)
gcloud secrets get-iam-policy clearpay-staging-database-url
gcloud secrets get-iam-policy clearpay-production-database-url
gcloud projects get-iam-policy "$PROJECT_ID" --flatten='bindings[].members' --filter="bindings.members:serviceAccount:clearpay-ci@" --format="table(bindings.role)"

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

• خفیہ فہرست مرتب کرنا clearpay-api-staging اور clearpay-ci. پائپ لائن تعیناتی کے دوران اسٹیجنگ جوڑی کو پڑھتی ہے۔

• پروڈکشن کی خفیہ فہرست clearpay-api-production صرف

• clearpay-ci پروجیکٹ کے دو کردار ہیں: artifactregistry.writer اور container.developer.

اگر آپ کے پروڈکشن سیکرٹ میں اسٹیجنگ اکاؤنٹ کی فہرست ہے یا آپ کی پائپ لائن میں درج ذیل کردار ہیں: owner یا editorرکیں اور مرحلہ 5 یا 6 میں تصحیح کریں۔

مکمل ہونے پر:

• دیکھے گئے نتائج کے ساتھ چاروں چیک نوٹوں میں لکھے گئے ہیں، نہ صرف "شاید ٹھیک"۔

باب 17 پرومیٹیس اور گرافانا کے ساتھ کلیئر پے دیکھیں (اختیاری)

جمعرات صبح 9:30 بجے

سیکورٹی کا جائزہ مکمل کر لیا گیا ہے۔ ڈینیئل آپ کا نوٹ پڑھتا ہے اور پھر اپنی کرسی آپ کی طرف موڑتا ہے۔

ڈینیئل: "جب ٹریفک بہنا شروع ہو جائے تو میں اندازہ لگانے کے بجائے گراف دیکھنا چاہتا ہوں۔ مجھے کیا دیکھنا چاہیے؟"

یہ کیوں اہمیت رکھتا ہے۔

یہ باب اختیاری ہے۔ یہ AWS یا GKE کو نہیں چھوتا ہے اور بعد کے ابواب میں اس کی ضرورت نہیں ہوگی۔ اگر آپ چاہیں تو باب 18 پر جائیں۔ اگر آپ یہ جاننا چاہتے ہیں کہ Prometheus اور Grafana کیسے کام کرتے ہیں، تو اس کے لیے جائیں۔

API درج ذیل مقامات پر نمبروں کو ظاہر کرتا ہے: /metrics: درخواستوں کی تعداد، تاخیر، اور ڈیٹا بیس پول کے استعمال۔ پرومیتھیس اس نمبر کو ہر چند سیکنڈ میں جمع کرتا ہے۔ گرافانا کے ذریعہ تیار کردہ۔

اس باب میں، آپ Docker Compose کا استعمال کرتے ہوئے اپنی نوٹ بک پر Prometheus اور Grafana چلائیں گے، جو باب 1 API کی طرف اشارہ کرتا ہے۔ اس سے ثابت ہوتا ہے کہ ڈیش بورڈ کام کرتا ہے۔ ہم GKE یا AWS کی نگرانی نہیں کرتے ہیں۔ ہدف فائل اس پر واقع ہے: observability/targets/ پسند .example فائل، لیکن ہم اس فائل کو اس لیب میں استعمال نہیں کریں گے۔ جب ٹریفک چل رہا ہے، باب 21 اور 22 میں کمانڈ لائن کی جانچ معلومات کا ذریعہ ہے۔

گوگل کلاؤڈ کے اپنے سات درجے کے ایرر کاؤنٹرز ہیں۔ یہ جی سی پی پر کلاؤڈ لاگنگ میٹرک ہے جو گرافانا سے الگ ہے۔

Now     localhost:4000  →  Prometheus  →  Grafana :3000
Later   AWS, GKE, load balancer  (observability/targets/*.example, optional)

قدم

پرومیتھیس پڑھتا ہے۔ host.docker.internal:4000یہ ایک باب 1 API ہے۔ اگر curl http://localhost:4000/health اگر آپ ناکام ہوجاتے ہیں تو شروع کریں۔

docker compose up -d api postgres

پھر ہم مانیٹرنگ اسٹیک شروع کرتے ہیں۔

cd observability
docker compose up

http://localhost:3000 کھولیں۔ اس لیپ ٹاپ کے مخصوص اسٹیک میں گمنام ایڈمنسٹریٹر کی رسائی فعال ہے۔ افتتاحی ClearPay - مائیگریشن ڈیش بورڈ.

چیک کریں

مقامی API کو کچھ درخواستیں بھیجیں۔

curl http://localhost:4000/health

کہ ماحولیات p95 کے ذریعہ انتظار کے وقت کی درخواست کریں۔ پینل مندرجہ ذیل سیریز دکھاتا ہے: local. خالی پینل کا مطلب ہے کہ Prometheus پورٹ 4000 سے رابطہ نہیں کر سکتا۔

مکمل ہونے پر:

• ڈیش بورڈ دکھاتا ہے: local سیریز

باب 18 مقصد کے مطابق لوڈ ٹیسٹنگ اور بندش کے اقدامات

جمعرات دوپہر 1 بجے

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

ڈینیئل: "گیٹ کو صرف ایک لاگ ان کے لیے ٹیسٹ کیا گیا ہے۔ اگر 20 درخواستیں ایک ساتھ پہنچ جائیں یا پوڈ ختم کر دیا جائے تو کیا ہوگا؟"

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

یہ کیوں اہمیت رکھتا ہے۔

صارفین ایک ساتھ GKE سے بہت سی درخواستیں کریں گے، اور Kubernetes اپ ڈیٹس اور مشین کی مرمت کے دوران پوڈز کو دوبارہ شروع کریں گے۔ اب میں دونوں کو کسٹمر کی شمولیت کے بغیر ہوتا دیکھنا چاہتا ہوں۔

ٹیسٹ کے تحت سسٹم اسٹیج 3 سے باقاعدہ نوڈ پول پر چلتا ہے۔ اگر آپ کلاؤڈ میں لوڈ جنریٹر چلا رہے ہیں، تو سستے اسپاٹ VMs مثالی ہیں کیونکہ انہیں بغیر کسی نقصان کے اتارا جا سکتا ہے۔ پیمائش کے نظام کو کبھی بھی اسپاٹ پر نہیں چلنا چاہئے کیونکہ رکاوٹ ریڈنگ کو خراب کر سکتی ہے۔

مرحلہ 1۔ لوڈ ٹیسٹنگ کی تیاری

ریپوزٹری روٹ کے لیے دو ٹرمینلز استعمال کریں۔

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

kubectl -n staging port-forward svc/clearpay-api 8080:80

اسے تلاش کریں۔ Forwarding from 127.0.0.1:8080.

ٹرمینل بی: سب سے پہلے، یقینی بنائیں کہ آپ GKE سے جڑے ہوئے ہیں اور پوسٹگریس جواب دے رہا ہے۔

curl -s http://localhost:8080/health
curl -s http://localhost:8080/health/ready

health شامل ہونا چاہیے۔ "platform":"gke". ready شامل ہونا چاہیے۔ "status":"ready".

پھر 30 سیکنڈ میں 20 سمورتی درخواستوں کے ساتھ لوڈ ٹیسٹ چلائیں۔

./scripts/load-test.sh http://localhost:8080 
  alice@clearpay.dev password123 20 30

اسکور کارڈ کو AWS اسکور کارڈ کے ساتھ اپنے نوٹوں میں کاپی کریں۔ اس لیب کے اعداد و شمار:

                AWS (Chapter 6)   GKE staging (this chapter)
p95 latency:    745 ms            655 ms
Error rate:     0.0 %             0.0 %
Recovery time
after pod kill: n/a               (fill in after Step 3)

AWS 10 سمورتی درخواستوں کے ساتھ چلا اور ok=372. GKE 20 سمورتی درخواستوں کے ساتھ چلا۔ ok=686، failed=022.9 درخواستیں فی سیکنڈ۔

GKE کا p95 AWS سے تھوڑا کم ہے۔ آپ حیران ہو سکتے ہیں۔ دونوں نمبروں کی اکثریت لیپ ٹاپ سے کلاؤڈ تک کی حرکت ہے، اور اس حرکت کا سائز دونوں کے لیے تقریباً ایک جیسا ہے۔ GKE میں ڈیٹا بیس کے تمام سوالات بھی گوگل کے سوالات کے ساتھ ایک دوسرے کو جوڑتے ہیں۔ us-east4 AWS پر us-east-1 یہ کلاؤڈ NAT کے ذریعے کیا گیا ہے، لیکن یہ اس کے اوپر تھوڑا سا اضافہ کرتا ہے۔

چونکہ دو رنز مختلف کنکرنسی استعمال کرتے ہیں (10 اور 20)، ہم نمبروں کو ریسنگ کے بجائے قریب سمجھتے ہیں۔ لائنوں کو صاف رکھنا ضروری ہے۔ failed=0. دونوں لیٹنسی نمبرز کو ذہن میں رکھیں۔ وہ کتاب کے آخر میں دوبارہ لوٹتے ہیں۔

مرحلہ 2۔ پڑھیں served by سموچ

ClearPay ڈیش بورڈ کھولیں۔ api.clearpay.test حالیہ سرگرمی پر ایک نظر ڈالیں۔ سب سے زیادہ متوقع aws لائن اور ایک یا دو gke سموچ یہ لیبارٹری تھی:

-$1.00  served by aws/1.0.0        ← a send you made in the browser
-$1.00  served by gke/0.0.0-unset  ← the promotion gate from Chapter 15
-$5.00  served by aws/1.0.0        ← an older send

ہر لائن اس عمل کا نام دیتی ہے جس نے منتقلی کو تخلیق کیا۔ دونوں بادل ایک ہی ڈیٹا بیس پر لکھتے ہیں اور UI ہر قطار کو پڑھتا ہے۔ اتنا کم کیوں؟ gke سموچ؟

• آپ کا براؤزر اسے AWS کو بھیجتا ہے۔ کیونکہ سامنے کا دروازہ اب بھی آپ کی 100% ٹریفک وہاں بھیجتا ہے۔

• میں نے صرف GKE کے ذریعے پرومو گیٹ بنایا اور سرنگ کے ذریعے $1.00 ادا کیا۔ لوڈ ٹیسٹ صرف ڈیٹا کو پڑھتا ہے، لہذا اس میں کوئی لکیریں شامل نہیں ہوتی ہیں۔

کوئی راستہ نہیں gke اس لائن کا مطلب یہ نہیں ہے کہ لوڈ بیلنسر نے صفحہ GKE کو بھیجا ہے۔ اس کا مطلب ہے کہ GKE پوڈ نے اس منتقلی کو سنبھالا۔

دونوں نام ماحولیاتی متغیرات سے آتے ہیں۔ aws/1.0.0 EC2 سے آرہا ہے۔ .env فائل gke/0.0.0-unset سے آتا ہے k8s/base/deployment.yamlکہاں APP_VERSION یہ ایک پلیس ہولڈر ہے جو پائپ لائن کو تبدیل نہیں کرتا ہے۔ پلیس ہولڈر متوقع ہے، تنازعہ نہیں۔

اوپر کی کالی بار اس بات کی نشاندہی کرتی ہے کہ فی الحال کون سا عمل جواب دے رہا ہے۔ آپ کی حالیہ سرگرمی کی سرگزشت ظاہر کی جائے گی۔

مرحلہ 3۔ پوڈ کو بند کریں اور بحالی کا وقت مقرر کریں۔

ایک API Pod کو تباہ کریں اور پیمائش کریں کہ Kubernetes کو اسے تبدیل کرنے میں کتنا وقت لگتا ہے۔

kubectl -n staging get pods -l app=clearpay-api
POD=$(kubectl -n staging get pod -l app=clearpay-api -o jsonpath="{.items[0].metadata.name}")
echo "deleting $POD"
START=$(date +%s)
kubectl -n staging delete pod "$POD"
kubectl -n staging wait --for=condition=Ready pod -l app=clearpay-api --timeout=120s
echo "recovery $(( $(date +%s) - START )) s"
kubectl -n staging get pods -l app=clearpay-api

kubectl delete pod پچھلی پوڈ کے غائب ہونے کا انتظار کریں، بشمول 5 سیکنڈ۔ preStop وقفہ k8s/base/deployment.yaml. موقوف جاری درخواستوں کو عمل کو روکنے سے پہلے مکمل کرنے کی اجازت دیتا ہے۔ کہ recovery لائن حذف ہونے سے لے کر نیا پوڈ تیار ہونے تک کا وقت ہے۔ اس لیب کا پچھلا رن پرنٹ کیا جا چکا ہے۔ 42 s. آپ کا معاملہ مختلف ہوگا۔ براہ کرم اوپر والے جدول میں اپنا فون نمبر درج کریں۔

اگر wait وقت ختم، چلائیں kubectl -n staging get pods اور kubectl -n staging describe pod پوڈ کے نئے نام میں۔

ٹرمینل ایک سرنگ کو اس وقت حذف کیا جا سکتا ہے جب پوڈ جس کی طرف اشارہ کرتا ہے اسے حذف کر دیا جاتا ہے۔ ٹرمینل A بند ہونے پر، مرحلہ 4 سے پہلے دوبارہ پورٹ فارورڈنگ شروع کریں۔

مرحلہ 4۔ لوڈنگ تعیناتی کو دوبارہ شروع کریں۔

اس قدم کے لیے آپ کو درج ذیل میں سے ایک کو تبدیل کرنے کی ضرورت ہے: scripts/load-test.sh. اس کے بغیر، failed= یہاں تک کہ اگر درخواست ختم ہوجاتی ہے، 0 پڑھا جاتا ہے۔ اسکرپٹ صرف ان درخواستوں کو شمار کرتا ہے جن کا جواب موصول ہوتا ہے۔ جب پوڈ دوبارہ شروع ہوتا ہے، سرنگ لٹک جاتی ہے، درخواست کا کوئی جواب نہیں ہوتا ہے، اور اسکرپٹ ناکامی کو شمار کیے بغیر اس کارکن کو روک دیتا ہے۔

کھلا scripts/load-test.sh آپ کے ایڈیٹر میں۔ پوری چیز کو بدل دیں۔ hit() اس کے ساتھ فنکشن۔ دو نئی چیزیں: 2>/dev/null || true کرل لائن اور if آخر میں لائن.

hit() {
  local path="$1" out code secs
  out=$(curl "${CURL_OPTS[@]}" -o /dev/null -w '%{http_code} %{time_total}' 
    -H "Authorization: Bearer $TOKEN" 
    "$BASE_URL$path" 2>/dev/null || true)
  code="${out%% *}"
  secs="${out##* }"
  echo "$code" >> "$CODES"
  node -e "process.stdout.write(String(Math.round(Number(process.argv[1]) * 1000)) + 'n')" "$secs" >> "$TIMES"
  if [ "$code" = "000" ]; then sleep 0.5; fi
}

000 جب کوئی جواب نہیں آتا ہے تو یہ وہی ہے جو curl کی اطلاع دیتا ہے۔ ایک مختصر وقفہ ناکام کارکن کو اپنے آپ کو فی سیکنڈ ہزاروں بار دہرانے سے روکتا ہے۔

اب ٹرمینل B پر لوڈ ٹیسٹ چلائیں۔ یہ 40 سیکنڈ تک چلتا ہے، لہذا دوبارہ شروع کرنا اس کے اندر فٹ ہوجاتا ہے۔

./scripts/load-test.sh http://localhost:8080 
  alice@clearpay.dev password123 5 40

اس کمانڈ پر انٹر دبانے سے پہلے، تیسرے ٹرمینل میں ری اسٹارٹ کمانڈ ٹائپ کریں اور اسے تیار رہنے دیں۔ لوڈ ٹیسٹ شروع کرنے کے 3 سیکنڈ کے اندر تیسرے ٹرمینل پر Enter دبائیں۔

kubectl -n staging rollout restart deployment/clearpay-api
kubectl -n staging rollout status deployment/clearpay-api
kubectl -n staging get events --sort-by=.lastTimestamp | tail

ایونٹس ایک وقت میں پرانے پوڈز کو روکتے ہوئے اور نئے پوڈ شروع ہوتے دکھاتے ہیں۔

اسٹیجنگ کے ساتھ، متبادل شروع ہونے سے پہلے ایک پوڈ کو ہٹا دیا جاتا ہے (maxUnavailable: 1 اور maxSurge: 0 کو k8s/overlays/staging/patch-deployment.yaml)۔ چھوٹے لیب کلسٹرز میں اضافی پھلیوں کے لیے جگہ نہیں ہوتی۔ لہذا، دوبارہ شروع کرنے کے دوران درخواستیں مختصر مدت کے لیے ناکام ہو جائیں گی۔ failed= 0 سے اوپر کوئی بھی چیز نارمل ہے۔ نمبر لکھ دیں۔ ٹرمینل A پرنٹ کرسکتا ہے۔ lost connection to pod. Ctrl+C کے ساتھ رکیں اور جانچ کے بعد سرنگ کو دوبارہ شروع کریں۔

پیداوار زیادہ محفوظ ہے۔ پہلے سے طے شدہ ترتیب پرانے کو روکنے سے پہلے نئے پوڈ شروع کرتی ہے (maxSurge: 1 اور maxUnavailable: 0)۔

فیصلہ

پاس: failed=0 30 سیکنڈ کے ٹیسٹ میں، ڈیلیٹ کرنے کے بعد متبادل پوڈ تیار تھا۔ rollout status مکمل اگرچہ GKE کا p95 AWS سے زیادہ ہے، آپ اس راستے پر اس وقت تک جا سکتے ہیں جب تک کہ آپ AWS p95 کی غلطی کی حد سے 3x نیچے رہیں جس کے بارے میں ہم نے باب 6 میں لکھا ہے۔

ناکام: 30 سیکنڈ ٹیسٹ میں 5xx غلطی، لاگ ان internal_errorیا ایک نئی پھلی جو تیار نہیں ہے۔ اپنے سٹیجنگ کو ٹھیک کرنے اور اپنی پائپ لائن کو آگے بڑھانے کے بعد، اس باب کو دوبارہ چلائیں۔

مکمل ہونے پر:

• نوٹ میں دونوں سکور کارڈ ساتھ ساتھ ہیں۔

• پوڈ کی بازیابی کا وقت متعین ہے۔

• جب لوڈ چل رہا تھا ایک رولنگ دوبارہ شروع کیا گیا تھا اور یہ نوٹ کیا گیا تھا. failed=

Ctrl+C کا استعمال کرتے ہوئے ٹرمینل A پر پورٹ فارورڈنگ بند کریں۔

یہ چوکی ہے۔ GKE بوجھ اور پوڈ شٹ ڈاؤن سے بچ گیا۔ اب تک تمام چیکس روٹ پر گاہکوں کے بغیر کئے گئے ہیں۔

اب یہ بدل گیا ہے۔

حصہ 6۔ صارفین کو GKE میں کیسے منتقل کیا جائے۔

یہ وہ جگہ ہے جہاں گاہک GKE استعمال کر سکتے ہیں۔ دونوں بادل درخواستوں پر کارروائی کر سکتے ہیں۔ یہاں ہر قدم ایک سوال پوچھتا ہے: زیادہ ٹریفک چلانے کا کیا ثبوت ہے؟

باب 19۔ پیداوار اور جی کے ای گیٹ وے کی تعیناتی۔

تیسرا پیر صبح 9 بجے

یہ وہ ریاستیں ہیں جن میں GKE صارفین کے لیے دستیاب ہے۔ کوئی اسے اونچی آواز میں نہیں کہتا۔ دفتر معمول سے تھوڑا سا پرسکون ہے۔

ابھی تک GKE کے پاس صرف اسٹیجنگ ہے۔ اسٹیجنگ ایک نجی کاپی ہے جو سرنگ کے ذریعے پہنچتی ہے۔ کسٹمر ایک علیحدہ کاپی استعمال کرتا ہے جسے پروڈکشن کہتے ہیں۔ اس باب میں، آپ وہ کاپی بنائیں گے اور اس ایڈریس کو لنک کریں گے جہاں آپ کے گاہک آپ کو کال کریں گے۔

دو چیزیں غائب ہیں۔

1. یہ پروڈکشن نام کی جگہ ہے۔ نام کی جگہ کلسٹر کے اندر ایک الگ علاقہ ہے۔ اسٹیجنگ میں ایک ہے۔ پروڈکشن پوڈ موجود نہیں ہے کیونکہ ابھی تک پروڈکشن میں ایک نہیں ہے۔ اسے بنائیں اور وہی تصویر ڈالیں جو اسٹیجنگ گیٹ سے گزری تھی۔

2. GKE ایج آئی پی کے پیچھے کچھ ہے۔ مرحلہ 8 میں، آپ نے GKE کے لیے ایک عوامی پتہ محفوظ کیا، جسے edge IP کہا جاتا ہے۔ یہ ایک محفوظ لیکن غیر منسلک فون نمبر کی طرح کام کرتا ہے۔ گھنٹی بجتی ہے اور کوئی جواب نہیں دیتا۔ اپنے گیٹ وے سے جڑیں۔ گیٹ وے ہر درخواست کا جواب دیتا ہے اور اسے پروڈکشن پوڈ پر بھیج دیتا ہے۔

مکمل ہونے کے بعد، GKE اصل درخواستوں کا جواب دے سکتا ہے۔ اب بھی ٹریفک نہیں چل رہی۔ مین گیٹ باب 21 تک اپنے 100% صارفین کو AWS کو بھیجتا رہے گا۔

یہ کیوں اہمیت رکھتا ہے۔

لوڈ بیلنسر صرف GKE کو ٹریفک بھیج سکتا ہے جب GKE میں کچھ جواب دیتا ہے۔ یہ ایک گیٹ وے ہے۔ ایک Kubernetes اعتراض جو Google کو آپ کی سروس کے سامنے لوڈ بیلنسر تعینات کرنے کی ہدایت کرتا ہے۔ یہاں سنو clearpay-gke-edge-ip پروڈکشن APIs اور UI کو ڈیلیور کیا گیا۔

کہ 08-edge لوڈ بیلنسر انٹرنیٹ NEG (ایک نیٹ ورک اینڈ پوائنٹ گروپ جو بیرونی IP ایڈریس کی طرف اشارہ کرتا ہے) کے ذریعے دونوں بادلوں تک پہنچتا ہے۔ اس قسم کے لیے کوئی صحت کی جانچ نہیں ہے۔ اگر بیک اینڈ نیچے جاتا ہے، تو لوڈ بیلنسر ٹریفک بھیجتا رہے گا اور صارفین کو 502 ایرر موصول ہوگا۔ آپ کی حفاظت synthetic-health.shفیصلہ گیٹ اور rollback.sh.

مرحلہ 1. گیٹ وے API کو آن کریں۔

مرحلہ 3 میں کلسٹرز میں یہ خصوصیت نہیں ہے۔

gcloud container clusters update clearpay --zone us-east4-a 
  --gateway-api=standard

اس کے مکمل ہونے کا انتظار کریں، پھر درج ذیل کریں:

kubectl get gatewayclass

اسے تلاش کریں۔ gke-l7-global-external-managed. وہ کلاس ہے۔ k8s/gateway/gke-gateway.yaml میں اسے استعمال کرتا ہوں۔

مرحلہ 2۔ اپنے نوڈ پول میں جگہ خالی کریں۔

تین چیزیں e2-medium مشینوں میں تقریباً 940m CPUs ہیں، GKE میں ان کے اپنے سسٹم پوڈ کے پیچھے۔ اسٹیجنگ اور پروڈکشن کو ایک ساتھ استعمال کرنا مناسب نہیں ہے۔ جگہ بچانے کے لیے سٹیجنگ کو سمیٹیں۔ تصاویر کو آرٹفیکٹ رجسٹری میں برقرار رکھا جاتا ہے اور گیٹ کے نتائج کو نوٹوں میں برقرار رکھا جاتا ہے۔

سب سے پہلے، اپنے عین مطابق امیج سٹیجنگ رن کو ریکارڈ کرنے کی کوشش کریں۔ پیداوار میں آپ کو اس کے برابر سٹرنگ چلانی چاہئے:

kubectl -n staging get deploy clearpay-api 
  -o jsonpath="{.spec.template.spec.containers[0].image}{"n"}"
kubectl -n staging get deploy clearpay-ui 
  -o jsonpath="{.spec.template.spec.containers[0].image}{"n"}"

پھر اسٹیجنگ کو 0 پر ایڈجسٹ کریں۔

kubectl -n staging scale deploy/clearpay-api --replicas=0
kubectl -n staging scale deploy/clearpay-ui --replicas=0

دھکا مت کرو main ٹریفک شفٹ کے دوران۔ پش اسٹیجنگ کو پورے سائز میں دوبارہ تقسیم کرتا ہے اور CPU کو واپس لے جاتا ہے۔

جب پروڈکشن API پوڈز کو برقرار رکھا جاتا ہے۔ Pending کے ساتھ Insufficient cpu بعد میں سٹیجنگ اب بھی CPU رکھتا ہے۔ اپنے نوڈ پول میں زیادہ سے زیادہ اضافہ نہ کریں جب تک کہ آپ دوسری مشینوں کی قیمت کو قبول نہ کریں۔

مرحلہ 3. پیداوار کی تعیناتی۔

پائپ لائنوں کا استعمال کریں۔ یہ وہ راستہ ہے جسے باب 14 نے اس لمحے کے لیے بنایا ہے۔

پائپ لائن کا استعمال کرتے ہوئے:

1. GitHub میں اپنا ٹاسک کھولیں، پھر بائیں طرف کی فہرست سے Build، Scan، اور Deploy کریں۔ اس ورک فلو صفحہ سے شروع کریں، مکمل رن سے نہیں۔ اگر آپ ایک ہی رن دیکھ رہے ہیں تو اس کے نام کے آگے پیچھے والے تیر پر کلک کریں۔ کہ promote-to-production پچھلے رنز کے ٹاسک دکھاتے ہیں "یہ کام چھوڑ دیا گیا تھا" اور چھوڑ دیا جاتا ہے۔ ایک نئے نفاذ کی ضرورت ہے۔

2. ورک فلو چلائیں پر کلک کریں۔ اپنی شاخیں کھلی رکھیں main,promote_to_production کو منتخب کریں اور رن ورک فلو پر کلک کریں۔

3. کہ promote-to-production نوکری "جائزہ کے منتظر" کے طور پر قطار میں ہے۔ پر کلک کریں اور ریویو تعیناتی کو منتخب کریں۔ productionاور منظور کریں اور تعینات کریں پر کلک کریں۔

4. اپنی فی الحال متعین اسٹیجنگ امیج کو تلاش کریں اور چیک مارک استعمال کریں کہ اس تصویر کو پروڈکشن کی تکمیل تک کیسے لگایا جائے۔

اب، یہاں تک کہ اگر اسٹیجنگ 0 پوڈز چلاتا ہے، ٹاسک اسٹیجنگ تعیناتی سے امیج سٹرنگ کو پڑھتا ہے اور صحیح امیج کو تعینات کرتا ہے۔

اگر آپ کے پاس پائپ لائن سیٹ اپ نہیں ہے تو دستی طور پر:

یہ وہی مراحل ہیں جن میں کام چلتا ہے۔ PROJECT_ID فائل میں موجود نام پلیس ہولڈرز ہیں، اس لیے انہیں اپنی پائپ لائن کی طرح تبدیل کریں۔ میک پر، sed -i کچھ خالی جگہ کی ضرورت ہے۔ '' اس کے بعد:

cd k8s/overlays/production
PROJECT_ID=$(gcloud config get-value project)
sed -i '' "s/@PROJECT_ID.iam/@${PROJECT_ID}.iam/" patch-serviceaccount.yaml
sed -i '' "s#projects/PROJECT_ID/#projects/${PROJECT_ID}/#" secretproviderclass.yaml

لینکس پر '' ~ بعد -i.

ان دو تصویروں پر اوورلے کی طرف اشارہ کریں جنہیں آپ نے مرحلہ 2 میں نوٹ کیا ہے۔ اسے کبھی استعمال نہ کریں۔ latest:

kustomize edit set image 
  REGION-docker.pkg.dev/PROJECT_ID/clearpay/api=STAGING_API_IMAGE
kustomize edit set image 
  REGION-docker.pkg.dev/PROJECT_ID/clearpay/ui=STAGING_UI_IMAGE
kubectl apply -k .
kubectl -n production rollout status deployment/clearpay-api --timeout=180s
kubectl -n production rollout status deployment/clearpay-ui --timeout=180s

تبدیلی STAGING_API_IMAGE اور STAGING_UI_IMAGE مرحلہ 2 سے پوری سٹرنگ کو درج ذیل فارمیٹ میں استعمال کریں: us-east4-docker.pkg.dev/.../api:.

اس کے بعد فائل کا ارتکاب نہ کریں۔ sed اور kustomize edit. اب اس میں پروجیکٹ ID اور اصل ٹیگز شامل ہیں۔ چلائیں git checkout k8s/overlays/production تعیناتی کے بعد کالعدم کرنے کے لیے، ریپوزٹری روٹ سے چلائیں۔

پیداوار کی تصدیق

ریپوزٹری روٹ پر واپس جائیں۔ پوڈ تیار ہونے تک انتظار کریں۔

kubectl -n production get pods

ڈسپلے API اور UI پوڈز Running اور READY 1/1. پھر، اسٹیجنگ کے بجائے پروڈکشن پوڈ میں ڈیٹا بیس کو چیک کریں۔

kubectl -n production exec deployment/clearpay-api -- node -e 
  "require('./src/db').checkConnection().then(() => { console.log('connected'); process.exit(0); }).catch(e => { console.error(e); process.exit(1); })"

connected

مرحلہ 4۔ GKE گیٹ وے کا اطلاق کریں۔

مرحلہ 8 محفوظ clearpay-gke-edge-ip اور سند clearpay-gke-edge-cert. اب انہیں خدمت کے لیے کچھ دیں:

kubectl apply -f k8s/gateway/gke-gateway.yaml
kubectl apply -f k8s/gateway/httproute-production.yaml
kubectl apply -f k8s/gateway/healthcheck-api.yaml
kubectl -n production get gateway clearpay-gke-edge

براہ کرم انتظار کریں۔ PROGRAMMED دکھائیں True. اس میں چند منٹ لگ سکتے ہیں جب کہ Google لوڈ بیلنسر بناتا ہے۔

تین فائلیں تین چیزیں کرتی ہیں:

• gke-gateway.yaml سرٹیفکیٹ کا استعمال کرتے ہوئے محفوظ IP پر ایک گیٹ وے بنائیں۔

• httproute-production.yaml پروڈکشن سروس کو درخواست بھیجیں۔

• healthcheck-api.yaml Google کو اپنی حیثیت چیک کرنے کی ہدایت کریں۔ /health. بصورت دیگر، گوگل چیک کرے گا۔ /API 404 کے ساتھ جواب دیتا ہے اور درخواست ناکام ہوجاتی ہے۔ no healthy upstream.

اپنا گیٹ وے چیک کریں۔

GKE کو براہ راست کنارے آئی پی کے ذریعے کال کریں۔ --resolve GKE IP سے جڑتے وقت سرٹیفکیٹ کا میزبان نام بھیجیں۔

HOST=$(terraform -chdir=infra/gcp/terraform/08-edge output -raw public_hostname)
EDGE=$(terraform -chdir=infra/gcp/terraform/08-edge output -raw gke_edge_ip_address)
curl -k --resolve "$HOST:443:$EDGE" "https://$HOST/health"

اسے تلاش کریں۔ "platform":"gke". کرل پرنٹ ہوتے ہیں۔ no healthy upstreamبراہ کرم ایک لمحہ انتظار کریں اور دوبارہ کوشش کریں۔ صحت کی جانچ میں پھلی کو صحت مند کے طور پر نشان زد کرنے میں کچھ وقت لگتا ہے۔

بغیر --resolveچونکہ وزن 100/0 ہے، وہی میزبان نام اب بھی AWS پر جائے گا۔

مکمل ہونے پر:

• kubectl get gatewayclass جھکاؤ gke-l7-global-external-managed

• پروڈکشن API اور UI پوڈز ہیں۔ Running، READY 1/1اسٹیجنگ امیج ٹیگز شامل کریں۔

• checkConnection پرنٹس connected پروڈکشن پھلی میں

• گیٹ وے شو PROGRAMMED Trueکنارے کا IP واپس آ گیا ہے۔ "platform":"gke"

باب 20۔ ہماری پری کنورژن چیک لسٹ پر ایک نظر ڈالیں۔

پیر کی سہ پہر 3 بجے

پیداوار شروع ہو چکی ہے۔ مایا اپنے لیپ ٹاپ کو بازو کے نیچے رکھے اپنی میز کے سامنے رک گئی۔

مایا: "مجھے ٹھیک سے بتائیں کہ آپ ٹریفک کو منتقل کرنے سے پہلے گاہکوں کو AWS کی طرف واپس کیسے لائیں گے۔ پھر مجھے دکھائیں کہ یہ کام کرتا ہے۔"

رول بیک ٹریننگ کیوں ضروری ہے۔

scripts/rollback.sh ہم اس ترتیب میں دو چیزیں کرتے ہیں:

1. چلتا ہے shift-traffic.sh 100 0یہ تمام ٹریفک کو سیکنڈوں میں واپس AWS پر بھیج دیتا ہے۔

2. SSH کے ذریعے اپنے AWS سرور سے جڑیں اور اسے ترتیب دیں۔ ROLLBACK_ACTIVE=true اس کا .envAPI کو دوبارہ شروع کریں۔ اس کے بعد UI ایک رول بیک بینر ڈسپلے کرے گا۔

ڈیش بورڈ میں جان بوجھ کر دو پیغامات ہیں:

• نئے ورژن کا پیغام نیچے دائیں طرف ایک چھوٹا سا پاپ اپ ہے۔ 'ہمیں تبدیلیاں ملی ہیں۔ یہ درخواست gke/... (سابقہ ​​aws/...)' سے جاری کی گئی تھی اور 5 سیکنڈ کے بعد غائب ہو جاتی ہے۔ جب دوسرا ورژن جواب دے گا تو یہ ظاہر ہوگا۔

• رول بیک بینر یہ ڈیش بورڈ کے اوپری حصے میں ایک سرخ پٹی ہے۔ آپ کو ایک پیغام نظر آئے گا جس میں لکھا ہوگا کہ "ہم AWS پر واپس آ گئے ہیں اور GKE کے مسئلے کی تحقیقات کے دوران ٹریفک بحال ہو گئی ہے۔" یہ تب تک رہے گا جب تک آپ جھنڈا صاف نہیں کرتے۔

جو بھی آپ کی ایپ کو دیکھ رہا ہے وہ دیکھے گا کہ "کچھ غلط ہو گیا ہے اور اسے ٹھیک کر دیا گیا ہے" کے برعکس "ایک نیا ورژن بھیج دیا گیا ہے"۔

پہلی بار جب آپ رول بیک چلاتے ہیں تو وہ کسی حقیقی ایونٹ کے دوران نہیں ہونا چاہئے جہاں گاہک اس امید میں ناکام ہوجاتا ہے کہ اس کی SSH کلیدیں کام کریں گی۔ جب کوئی مسئلہ نہ ہو تو اسے ابھی چلائیں۔ وزن پہلے ہی 100/0 ہے، لہذا ٹریفک کے مرحلے میں کچھ بھی نہیں بدلتا ہے۔ SSH اقدامات اور بینرز کی جانچ کی جاتی ہے۔

چیک لسٹ

ہر سطر کو اس کمانڈ کے ذریعے منتخب کریں جس پر عمل کیا گیا ہے، میموری کے ذریعے نہیں۔ اپنا لچکدار IP اور میزبان نام استعمال کریں۔

اب کمانڈ کو صرف چار لائنوں کی ضرورت ہے: GKE سمٹ، رول بیک ٹیسٹ کیا گیا۔، اے ڈبلیو ایس ہیلتھاور مصنوعی ٹیسٹ چل رہا ہے۔. میرے پاس پہلے سے ہی دوسرے 5 نتائج ہیں، لہذا انہیں پڑھیں اور چیک کریں۔ باب 21 اور 22 اس چیک لسٹ کو نہیں دہراتے ہیں۔ صرف مصنوعی ٹیسٹ دوبارہ استعمال کریں جو اپنے ٹرمینل میں مسلسل چلتے ہیں۔

Pre-Cutover Checklist

[ ] GKE healthy
    kubectl -n production get pods
    (all Running, READY)

[ ] Database healthy
    the production checkConnection from Chapter 19 prints connected

[ ] Monitoring up (optional, only if you did Chapter 17)
    Grafana at http://localhost:3000 loads.
    It does not watch GKE. Do not block on an empty GKE series.

[ ] Rollback tested
    YOUR_ELASTIC_IP is your AWS server's public IP. Get it with:
    terraform -chdir=infra/aws/terraform output -raw instance_public_ip
    ./scripts/rollback.sh YOUR_ELASTIC_IP ~/.ssh/clearpay-deployer
    Open https://YOUR_ELASTIC_IP, log in, and look for the red strip
    at the top of the dashboard ("Rolled back to AWS ..."). Then clear it:
    ./scripts/clear-rollback-flag.sh YOUR_ELASTIC_IP ~/.ssh/clearpay-deployer

[ ] AWS healthy
    ./scripts/promotion-gate.sh https://YOUR_ELASTIC_IP 
      alice@clearpay.dev password123 bob@clearpay.dev
    5 passed, 0 failed

[ ] Synthetic test running
    ./scripts/synthetic-health.sh https://YOUR_PUBLIC_HOSTNAME
    Leave it running in its own terminal for the whole shift.
    YOUR_PUBLIC_HOSTNAME is api.clearpay.test. From the repository root, confirm with:
    terraform -chdir=infra/gcp/terraform/08-edge output -raw public_hostname
    It prints one line per second: time, status code, latency.

[ ] Limits confirmed
    Chapter 6 limits, plus the Chapter 18 table:
    AWS p95 745 ms, GKE staging p95 655 ms, both 0.0 % errors, plus your pod recovery time from Chapter 18

[ ] Security review passed
    Chapter 16, all four checks written down

[ ] Cost ledger current
    infra/aws/COST.md and infra/gcp/COST.md, both clouds now billing

کیا رول بیک ڈرل پرنٹس

ٹریفک کا وزن پہلے سے ہی 100/0 ہے، لہذا مرحلہ 1 میں کچھ بھی نہیں بدلتا۔ مرحلہ 2 اصل امتحان ہے۔ یہ اس طرح ختم ہوتا ہے:

== Traffic split updated ==
"AWS: 100% / GKE: 0%"

== Step 2: flagging AWS as the active rollback target ==
AWS ROLLBACK_ACTIVE=true, service restarted.

== Rollback complete ==

اسکرپٹ کے نام کی آخری سطر پچھلا باب نمبر ہے۔ اسے نظر انداز کریں۔ اصل رول بیک اقدامات باب 23 میں دیے گئے ہیں۔

اگر مرحلہ 2 اس طرح رک جاتا ہے: ssh: connect to host ... port 22: Operation timed outمیرے گھر کا IP بدل گیا ہے اور AWS فائر وال اب بھی پرانے IP کی اجازت دیتا ہے۔ اگلا اپنا IP حاصل کریں۔ curl -s ifconfig.me; echo. اسے ایک پلس کے طور پر رکھو /32 کو ssh_allowed_cidr کو infra/aws/terraform/terraform.tfvars. چلائیں terraform apply کو infra/aws/terraform، پھر اسکرپٹ کو دوبارہ چلائیں۔

فیصلہ

جب تمام لائنیں منتخب ہو جاتی ہیں، GKE کنارے IP واپس آ جاتا ہے۔ "platform":"gke": باب 21 پر جائیں۔

منتخب نہیں: یہاں رکیں۔ مت بھاگو ./scripts/shift-traffic.sh 99 1 GKE کنارے کا IP خالی ہے۔ 1% صارفین ایسے پتے پر جائیں گے جس کے پیچھے کچھ بھی نہیں ہے۔

مایا سے کہو: "رول بیک ایک اسکرپٹ ہے۔ یہ ٹریفک کو حرکت دیتا ہے اور سیکنڈوں میں ایک بینر دکھاتا ہے۔ ہم نے اسے 5 منٹ پہلے چلایا۔"

مکمل ہونے پر:

• ہر چیک لسٹ لائن وہ نتائج دکھاتی ہے جو آپ نے دیکھے۔

باب 21۔ ٹریفک کا 1% GKE کو بھیجیں۔

منگل صبح 10 بجے

پوری ٹیم ایک کال پر ہے۔ کرس کا سپورٹ ان باکس دوسری اسکرین پر کھلا ہے۔ عمارہ نے اپنا ٹریڈنگ ٹیبل کھلا چھوڑ دیا۔ ڈینیل لوڈ بیلنسر کا صفحہ کھول کر آپ کے پاس بیٹھا ہے۔

مایا: "1% GKE کو جاتا ہے۔ غلطیاں اور ٹرانسفرز تلاش کریں۔ اگر کچھ غلط لگتا ہے تو سب کچھ دوبارہ بھیج دیں۔"

1 فیصد کیوں؟

درخواستوں کا 1%۔ درخواست ایک واحد پیغام ہے (لاگ ان، چیک بیلنس، ادائیگی) براؤزر سے API کو بھیجا جاتا ہے۔ 100 میں سے تقریباً 99 درخواستیں AWS کو جاتی ہیں اور تقریباً 1 GKE کو جاتی ہے۔ لوڈ بیلنسر ہر درخواست کے لیے انتخاب کرتا ہے، ہر گاہک کے لیے نہیں۔ یہ ایک گاہک کو ایک ہی دورے میں دونوں بادلوں تک رسائی کی اجازت دیتا ہے۔

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

قدم

./scripts/shift-traffic.sh 99 1

اسکرپٹ کو دوبارہ لاگو کیا جائے گا۔ 08-edge لوڈ بیلنسر کے یو آر ایل میپ پر نئے وزن لاگو کیے گئے ہیں۔ کوئی DNS تبدیلیاں یا تعیناتی نہیں۔

اب برابر وزن کے ساتھ infra/gcp/terraform/08-edge/terraform.tfvars:

aws_traffic_weight = 99
gke_traffic_weight = 1

اسکرپٹ وزن کو کمانڈ لائن ویلیو کے بطور پاس کرتا ہے۔ اگلا میدان terraform apply کو 08-edge فائل پڑھیں۔ اگر آپ اب بھی فائل میں 100s اور 0s دیکھتے ہیں، تو اسے لگائیں اور ٹریفک خاموشی سے پھر سے حرکت میں آجائے گا۔

یقینی بنائیں کہ فائل اور ریئل ٹائم اسٹیٹس مماثل ہیں۔

grep traffic_weight infra/gcp/terraform/08-edge/terraform.tfvars
terraform -chdir=infra/gcp/terraform/08-edge output current_traffic_split

آپ کو دیکھنا چاہئے aws_traffic_weight = 99، gke_traffic_weight = 1اور "AWS: 99% / GKE: 1%". اگر آپ کی فائل اب بھی 100s اور 0s دکھاتی ہے تو اسے ابھی ٹھیک کریں۔

چیک کریں: کیا آپ کی درخواست GKE تک پہنچی؟

1% پر، تقریباً تمام درخواستیں اب بھی AWS کو بھیجی جاتی ہیں۔ ہر کوئی لگاتار 40 درخواستوں کے بارے میں بات کر رہا ہے۔ aws یہ عام بات ہے۔ جب تک کوئی نہ کہے دہرائیں۔ gke:

HOST=$(terraform -chdir=infra/gcp/terraform/08-edge output -raw public_hostname)
IP=$(terraform -chdir=infra/gcp/terraform/08-edge output -raw static_ip_address)
while true; do
  curl -sk --resolve "$HOST:443:$IP" "https://$HOST/health"
  echo
  sleep 0.2
done

جب آپ اسے دیکھیں تو اسے Ctrl+C کے ساتھ روک دیں۔ "platform":"gke". اس لیب میں ایک رن کے لیے 200 درخواستیں درکار ہیں: 197 aws اور 3 gke.

اس بات کو یقینی بنانے کے لیے کہ GKE انتظار کیے بغیر جواب دینا جاری رکھے، کنارے کے IP کو براہ راست کال کریں۔ یہ گاہک کی درخواست نہیں ہے۔

HOST=$(terraform -chdir=infra/gcp/terraform/08-edge output -raw public_hostname)
EDGE=$(terraform -chdir=infra/gcp/terraform/08-edge output -raw gke_edge_ip_address)
curl -sk --resolve "$HOST:443:$EDGE" "https://$HOST/health"

اسے تلاش کریں۔ "status":"ok" اور "platform":"gke". اس لیب میں ہم نے پرنٹ کیا:

{"status":"ok","served_by":{"platform":"gke","version":"0.0.0-unset","instance":"clearpay-api-6f9448c857-mj2j6","commit":"unset","rollback_active":false}}

آپ کا instance یہ مختلف ہوگا۔ اگر platform کہتے ہیں awsیا، اگر curl ناکام ہو جاتا ہے، تو GKE غیر جوابدہ ہو جاتا ہے۔ وزن نہ بڑھاؤ۔

چیک کریں: کیا پبلک ایڈریس کے ذریعے لاگ ان کرنا کام کرتا ہے؟

اب سے، ایک صارف ایک درخواست کے لیے AWS اور دوسری درخواست کے لیے GKE استعمال کر سکتا ہے۔ دونوں لوگوں کو ایک ہی درخواست کو قبول کرنا چاہیے اور ایک ہی جواب دینا چاہیے۔ اگر وہ مختلف ہیں، تو آپ اب 1% پر معلوم کرنا چاہیں گے، بعد میں 50% پر نہیں۔ لاگ ان کو عوامی پتے کے ذریعے بھیجیں۔

HOST=$(terraform -chdir=infra/gcp/terraform/08-edge output -raw public_hostname)
IP=$(terraform -chdir=infra/gcp/terraform/08-edge output -raw static_ip_address)
curl -sk --resolve "$HOST:443:$IP" 
  -H 'Content-Type: application/json' 
  -d '{"email":"alice@clearpay.dev","password":"password123"}' 
  "https://$HOST/api/auth/login"

اسے تلاش کریں۔ "token" اور "user" جواب میں۔ اگر آپ دیکھتے ہیں internal_errorمت روکو اور وزن بڑھاؤ.

چیک آؤٹ کریں: گاہک کی طرح ایپ کا استعمال کریں۔

https://api.clearpay.test کھولیں اور سرٹیفکیٹ وارننگ پر کلک کریں۔ لاگ ان کرنے کے بعد، اپنا بیلنس چیک کریں اور تھوڑی رقم بھیجیں۔ حالیہ سرگرمی کے تحت ہر نئی لائن اس طرح نظر آتی ہے: served by aws/1.0.0 یا served by gke/0.0.0-unset. صرف تازہ ترین لائن ہی آپ کو اس درخواست کے بارے میں مطلع کرتی ہے۔ پرانی سطریں اس وقت سے ڈاک ٹکٹوں کو برقرار رکھتی ہیں جب وہ لکھے گئے تھے۔

اوپر کی کالی بار تقریباً ہمیشہ AWS کو 1% پر دکھاتی ہے۔ نئی لائنیں اور سرگرمی کے لوپس تلاش کریں، نہ صرف بار۔

ایک نظر میں synthetic-health.sh ٹرمینل ہر لائن کو ایک حیثیت ظاہر کرنی چاہیے۔ 200.

فیصلہ

• لوپ دکھایا gke کم از کم ایک بار لاگ ان کرنے کے بعد، ٹوکن واپس آ جاتا ہے اور صرف جامع حیثیت ظاہر ہوتی ہے۔ 200: باب 22 پر جائیں۔

• اور کچھ بھی: روکیں اور تفتیش کریں۔ وزن نہ بڑھاؤ۔ اگر آپ کا گاہک متاثر ہوتا ہے، تو براہ کرم درج ذیل کام کریں: rollback.sh پھر باب 23 پر جائیں۔

مکمل ہونے پر:

• فائل اور فائل دونوں کے لیے وزن 99/1 ہے۔ current_traffic_split

• لوپ پرنٹ کیا جاتا ہے. "platform":"gke" کم از کم ایک بار

• جب آپ اپنے عوامی پتے کے ذریعے لاگ ان ہوتے ہیں تو ایک ٹوکن واپس آ جاتا ہے۔

باب 22۔ ٹریفک میں 100% اضافہ کریں

صبح 11:30 بجے منگل سے بدھ کی سہ پہر تک

1٪ نے کام کیا۔ اس کا مطلب ہے کہ 100 میں سے 1 درخواستیں GKE کو پہنچائی گئیں۔ اب ایک وقت میں ڈائل کو تھوڑا سا اوپر کریں۔ میں تمہارے لیے کچھ نہیں کر سکتا۔ اسے اپنے ہاتھ میں پکڑیں ​​اور ہر قدم سے پہلے نمبر دیکھیں۔

ہر بار ایک ہی تین چیزیں چیک کریں۔

• سکور کارڈ: آپ دیکھ سکتے ہیں کہ آپ کی ایپ کتنی جلدی جواب دیتی ہے اور کتنی درخواستیں ناکام ہوتی ہیں۔

• نقل کی تعداد: چلانے والی API کاپیوں کی تعداد

• کنکشن ریاضی: آیا ڈیٹا بیس میں اب بھی تمام کنکشنز کی گنجائش ہے۔

99 / 1     AWS ████████████████████░    GKE ░
90 / 10    AWS ██████████████████░░     GKE ██
75 / 25    AWS ███████████████░░░░░     GKE █████
50 / 50    AWS ██████████░░░░░░░░░░     GKE ██████████
25 / 75    AWS █████░░░░░░░░░░░░░░░     GKE ███████████████
10 / 90    AWS ██░░░░░░░░░░░░░░░░░░     GKE ██████████████████
 0 / 100   AWS                          GKE ████████████████████

50/50 سے پہلے: مربوط ریاضی کرنا

ڈینیئل، جو فون پر ہے، آدھے راستے پر پہنچنے سے پہلے ہی مداخلت کرتا ہے۔ "جب AWS کام کرنا جاری رکھے گا تو GKE اسکیل آؤٹ ہونے پر کتنے ڈیٹا بیس کنکشن RDS تک پہنچ سکتے ہیں؟"

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

اپنے ڈیٹا بیس کی حدود کو چیک کریں۔ یہ چلتا ہے۔ psql AWS سرور پر جس میں پہلے سے ہی باب 5 ہے:

export INSTANCE_IP=$(terraform -chdir=infra/aws/terraform output -raw instance_public_ip)
DATABASE_URL=$(terraform -chdir=infra/aws/terraform output -raw database_url)
ssh -i ~/.ssh/clearpay-deployer ubuntu@$INSTANCE_IP "psql '$DATABASE_URL' -c 'SHOW max_connections;'"

GKE کی حدود کو چیک کریں۔ maxReplicas کو k8s/overlays/production/patch-hpa.yaml. پھر درج ذیل جدول میں نمبر درج کریں۔

RDS max_connections:          ___
AWS, 1 process × 10:          10
GKE, maxReplicas × 10:        ___
Worst case, both at once:     10 + ___ = ___

آپ اس مشق میں بھری ہوئی میز کے ساتھ اپنی میز کی جانچ کر سکتے ہیں۔

RDS max_connections:          81
AWS, 1 process × 10:          10
GKE, maxReplicas × 10:        30    (3 pods × 10)
Worst case, both at once:     10 + 30 = 40

40 81 سے کم ہے، اس لیے ٹریفک بڑھانے کی گنجائش ہے۔ آپ کا max_connections اگر آپ کے RDS کی مثالیں مختلف سائز کی ہوں تو یہ مختلف ہو سکتا ہے۔ اہم بات یہ ہے کہ سب سے برا معاملہ اس کے نیچے ہے۔

اب ایک بڑے سیٹ اپ کے لیے وہی حساب چلائیں۔ بڑی مشینوں والی کمپنیاں چھوٹی RDS مثالوں کے لیے 3 سے 8 پوڈز (10 + 80 = 90 کنکشنز) کے HPAs چلا سکتی ہیں، جو تقریباً 87 کی اجازت دیتی ہے۔

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

اگر بدترین صورت حال آپ سے بڑا ہے۔ max_connectionsاس سے پہلے کہ آپ وزن اٹھائیں، روکیں اور ترمیم کے اختیارات کے لیے باب 23 پڑھیں۔

قدم

ہر مرحلے میں ایک جیسی چار حرکتیں ہوتی ہیں۔ چاروں کام کرنے کے بعد، نمبروں کے اگلے جوڑے کے ساتھ دہرائیں۔

1. منتقل: چلائیں ./scripts/shift-traffic.sh ایک نئی جوڑی کے ساتھ۔ پہلا نمبر AWS کا حصہ ہے اور دوسرا نمبر GKE کا حصہ ہے۔

2. حاصل کریں: براہ کرم 2 ایک جیسے نمبر درج کریں۔ terraform.tfvars کو 08-edge.

3. چیک کریں: مندرجہ ذیل حصوں میں چھ ٹیسٹ چلائیں۔ ایک اسکرپٹ سب کچھ نہیں کر سکتی۔ یہ چند کمانڈز اور دو اسکرپٹ استعمال کرتا ہے۔ synthetic-health.shیہ پہلے ہی چل رہا ہے۔ load-test.sh.

4. فیصلہ کریں: اگر تمام چیک پاس ہو جاتے ہیں تو اگلے مرحلے پر جائیں۔ اگر تمام چیکس ناکام ہو جائیں تو روک دیں۔

اقدامات درج ذیل ہیں:

قدم	حکم	AWS	جی کے ای
1	./scripts/shift-traffic.sh 90 10	90%	10%
2	./scripts/shift-traffic.sh 75 25	75%	25%
3	./scripts/shift-traffic.sh 50 50	50%	50%
4	./scripts/shift-traffic.sh 25 75	25%	75%
5	./scripts/shift-traffic.sh 10 90	10%	90%
6	./scripts/shift-traffic.sh 0 100	0%	100%

ایک وقت میں ایک قطار چلائیں، ان سب کو ایک ساتھ نہ چلائیں۔

ہر قدم پر چیک کیا۔

1. ڈائل منتقل ہو گیا ہے۔ اسکرپٹ کا پرنٹ آؤٹ ٹیرافارم میں ایک ترتیب ہے، ثبوت نہیں۔ یقینی بنائیں کہ فائلیں مماثل ہیں۔

grep traffic_weight infra/gcp/terraform/08-edge/terraform.tfvars
terraform -chdir=infra/gcp/terraform/08-edge output current_traffic_split

2. اصل درخواست ڈائل کے بعد آتی ہے۔ ہر شفٹ کے بعد تین منٹ انتظار کریں اور گنیں کہ کون جواب دیتا ہے۔

HOST=$(terraform -chdir=infra/gcp/terraform/08-edge output -raw public_hostname)
IP=$(terraform -chdir=infra/gcp/terraform/08-edge output -raw static_ip_address)

for i in $(seq 1 40); do
  curl -sk --resolve "$HOST:443:$IP" "https://$HOST/health"
  echo
done | tee /tmp/clearpay-health.txt

grep -c '"platform":"aws"' /tmp/clearpay-health.txt
grep -c '"platform":"gke"' /tmp/clearpay-health.txt

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

90 / 10   80 requests:  75 aws,  5 gke
50 / 50   40 requests:  34 aws,  6 gke
25 / 75   40 requests:  17 aws, 23 gke
10 / 90   40 requests:   8 aws, 31 gke
 0 / 100  40 requests, 1 minute later:    3 aws, 37 gke
 0 / 100  40 requests, 90 seconds later:  0 aws, 40 gke

اگر 10 منٹ کے بعد بھی نمبرز ڈائل کی پیروی نہیں کرتے ہیں تو گوگل سے پوچھیں کہ کون سی تقسیم برقرار ہے۔

gcloud compute url-maps describe clearpay-migration-map | grep -B2 -A2 weight

0/100 پر clearpay-gke-backend لائن شو weight: 100چونکہ گوگل نے 0 کو چھوڑ دیا ہے، AWS لائن بالکل بھی وزن نہیں دکھاتی ہے۔ اگر آپ کا وزن آپ کی فائل سے مختلف ہے تو چلائیں: terraform apply دوبارہ 08-edge.

3. GKE ٹھیک ہے۔

kubectl -n production get pods -l app=clearpay-api
kubectl -n production get hpa clearpay-api

فورڈ Running اور تیار۔ HPA لائن موجودہ CPU اور نقل کی موجودہ تعداد کو 70% ہدف کے نسبت دکھاتی ہے۔ یہ لیب 25/75 تک 1 نقل اور 4-7% CPU کو برقرار رکھتی تھی۔

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

5. غلطیاں حد کے اندر ہیں۔ کہ synthetic-health.sh آپ کے ٹرمینل کو صرف درج ذیل دکھانا چاہیے: 200. اگر آپ لائن پر کچھ اور دیکھتے ہیں، تو روکیں اور اسے نہ اٹھائیں.

6.UI۔ پیسے بھیجنے اور تازہ ترین خبریں پڑھنے کے لیے https://api.clearpay.test پر لاگ ان کریں۔ served by لائن

ہر قدم پر فیصلے

مایا ہر بار ایک ہی سوال کرتی ہے۔ "کیا آپ اگلے مرحلے کے لیے تیار ہیں؟"

ثبوت کی بنیاد پر جواب دیں۔ "ڈائل فائل سے میل کھاتا ہے اور GKE کی درخواست کا حصہ بڑھ گیا ہے۔ پوڈز صحت مند ہیں، لاگ ان کام کر رہے ہیں، اور جامع سٹیٹس تمام 200 ہیں۔ کنکشنز کی سب سے خراب صورت ڈیٹا بیس کی حد کے اندر ہے۔"

اگر یہ ٹیسٹ میں ناکام ہو جاتا ہے تو اپ لوڈ نہ کریں۔ اگر آپ کا گاہک متاثر ہوا ہے، تو براہ کرم ابھی باب 23 پر جائیں۔

مکمل ہونے پر:

• فائل سے فائل تک وزن 0/100 ہے۔ current_traffic_split

• لگاتار 40 درخواستیں واپس کرتا ہے۔ "platform":"gke"

• کنکشن کی ریاضی اس کے اپنے نمبروں کے ساتھ لکھی جاتی ہے۔

• مصنوعی حالت میں کسی بھی مرحلے پر کوئی مستقل غلطی نہیں دیکھی گئی۔

باب 23۔ جب نمبر خراب ہوں۔

بدھ شام 4:12 بجے

آخری شفٹ مکمل ہو چکی ہے۔ اب ہمارے تمام صارفین GKE استعمال کر رہے ہیں اور ہیلتھ چیک 200 پرنٹ کرتا رہتا ہے۔ اس کا مطلب ہے کہ سب کچھ ٹھیک ہے۔ سپورٹ ان باکس پچھلے ایک گھنٹے سے خاموش ہے۔ عمارہ ایک بار پھر ٹریڈنگ ٹیبل چیک کرتا ہے۔

"یہ بورنگ لگ رہا ہے،" وہ کہتی ہیں۔ وہ سب سے بہتر یہ کہہ سکتی ہے۔

میں انتظار کر رہا ہوں کہ کوئی اسے کامیاب ہجرت کہے۔

ڈینیل اب بھی تعیناتی کا جائزہ لے رہا ہے۔ وہ GKE پر چلنے والی API کاپیوں کی تعداد گنتا ہے اور ڈیٹا بیس میٹرکس کو دیکھتا ہے۔

"کیا میں آپ کو آپ کی آخری نوکری کی بدترین دوپہر کے بارے میں بتا سکتا ہوں؟"

کرس نے کرسی موڑ دی۔

ڈینیئل پیچھے جھک گیا۔

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

وہ ایک لمحے کے لیے رکا۔

"ہمارا پچھلا ماحول اب بھی چل رہا تھا۔ ہم ان صارفین کی خدمت کر رہے تھے جو ابھی منتقل نہیں ہوئے تھے۔"

اپنی اسکرین پر تعیناتی دیکھیں۔

"تو دونوں ماحول ڈیٹا بیس استعمال کر رہے تھے؟" "ہاں، اور API کی ہر کاپی کے لیے ڈیٹا بیس کنکشن کی ضرورت ہے۔"

وہ خاکوں کے ڈیٹا بیس کی طرف اشارہ کرتا ہے۔

"یہی ہے جہاں ہم مصیبت میں بھاگ گئے." ڈینیئل اپنے قلم کے لیے پہنچتا ہے۔

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

وہ وائٹ بورڈ پر دو گروپ بناتا ہے۔

"AWS ایک گروپ تھا اور GKE دوسرا گروپ تھا۔ دونوں گروپ ایک ہی ریستوراں استعمال کر رہے تھے۔"

اس نے GKE کے آگے ایک اور گروپ شامل کیا۔

"پھر ٹریفک میں اضافہ ہوا۔ GKE نے API کی مزید کاپیاں شامل کیں، اور ہر نئی کاپی کے لیے ڈیٹا بیس کنکشن کی ضرورت ہے۔ پرانی AWS کاپی اب بھی کنکشن برقرار رکھے ہوئے تھی۔"

اس نے قلم نیچے رکھا۔

"ڈیٹا بیس محدود تھا۔ ہم ڈیٹا بیس سے کنکشن کی تعداد میں اضافہ کرتے رہے۔"

"جب حد ہو گئی تو کیا ہوا؟" تم پوچھو

"درخواست کنکشن کا انتظار کرنے لگی۔ پھر ٹائم آؤٹ شروع ہوا۔"

وہ آپ کو دیکھتا ہے۔

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

کرس تعیناتی پر غور کرتا ہے۔

"تو آپ ایک نئے ماحول کا مشاہدہ کر رہے تھے، لیکن ڈیٹا بیس دونوں ماحول کا احاطہ کر رہا تھا۔"

"درست طریقے سے۔"

دانیال پھر سے خاکے کو دیکھتا ہے۔

"یہ وہی ہے جو ہم نے کھو دیا۔ ہم نے حساب لگایا کہ ہمیں نئے ماحول میں کیا ضرورت ہے۔ ہم نے حساب نہیں لگایا کہ ہمیں ڈیٹا بیس میں کیا ضرورت ہے جب دونوں ماحول چل رہے تھے۔"

وہ پھر بیٹھ جاتا ہے۔

"آخرکار ہم نے ٹریفک کو پچھلے ماحول میں منتقل کر دیا اور ٹھیک ہو گئے، لیکن واقعہ پھر بھی برقرار رہا۔"

GKE کی تعیناتیوں کو دریافت کریں۔ "اب آپ مختلف طریقے سے کیا کریں گے؟"

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

ڈینیئل اپنا لیپ ٹاپ آپ کی طرف موڑتا ہے۔

"آپ کی لیب محفوظ ہے۔ ہم نے 81 ڈیٹا بیس کنکشن کی حد کے لیے 3 کاپیاں چلائیں اور بمشکل کام کا بوجھ ختم کیا۔"

وہ نوٹوں کا ایک اور سیٹ کھولتا ہے۔

"میرا کیس مختلف تھا۔ میرے پاس زیادہ سے زیادہ 8 کاپیاں تھیں اور ڈیٹا بیس نے 87 کنکشن کی اجازت دی تھی۔"

وہ آپ کو دیکھتا ہے۔ "تو پھر وہ نمبر استعمال کرتے ہیں۔"

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

"میں آپ کو واقعات اسی ترتیب سے بتاؤں گا جس ترتیب سے وہ پیش آئے۔ آپ ابھی ہولڈ پر ہیں۔ یہ مت سمجھو کہ آپ کو انجام معلوم ہے۔ جیسے ہی ہر کیس سامنے آتا ہے، مجھے بتائیں کہ آپ کیا دیکھتے ہیں اور آپ کے خیال میں کیا ہوگا۔"

وہ ایک ٹرمینل کھولتا ہے۔

تربیت 8 API کاپیوں اور 2 ماحول میں دستیاب 87 ڈیٹا بیس کنکشن کی حد سے شروع ہوتی ہے۔

اس بار نمبروں میں فرق پڑے گا۔

کیا آپ اس باب میں کچھ کرتے ہیں؟ اسے اخلاقیات کے ساتھ کہانی کی طرح پڑھیں۔ آپ کی لیب میں کوئی حادثہ نہیں ہوا تھا، اس لیے ٹھیک کرنے کے لیے کچھ نہیں ہے۔ اگر آپ واضح ثبوت چاہتے ہیں تو، مرحلہ 2 میں دو کمانڈز چلائیں اور ان کا موازنہ "اپنے کلسٹر" سے کریں۔ اگر لاگ میں کوئی خرابی ظاہر نہیں ہوتی ہے اور HPA 1 ریپلیکا پر ہے، تو آپریشن مکمل ہو گیا ہے۔ باب 24 پر جائیں۔

یہ کیسا لگتا ہے

50/50 شفٹ کے بعد پہلے چند منٹ نارمل لگتے ہیں۔ پھر ردعمل کا وقت تیز اور تیز تر ہونا شروع ہوتا ہے۔

عمارہ نے ٹیم چینل میں یہ سب سے پہلے دیکھا۔

"کئی ٹرانسمیشنز کا وقت ختم ہو گیا۔"

ڈینیئل پروڈکشن ڈیش بورڈ کھولتا ہے۔ API کو 7 replicas پر سکیل کیا گیا ہے اور p95 میں تاخیر بڑھ رہی ہے۔

کرس نے سست منتقلی کے بارے میں دو کسٹمر رپورٹس پوسٹ کیں۔

دانیال نے دوبارہ گراف کو دیکھا۔ "کیا یہ تمام درخواستوں کو متاثر کرے گا؟"

"ابھی تک نہیں۔" کرس نے کہا۔ "میں اب تک کئی بار ٹرانسفر کر چکا ہوں۔"

عمارہ اپنی ادائیگی کی تاریخ چیک کرتی ہے۔ "آئیے یقینی بنائیں کہ ٹائم آؤٹ ڈپلیکیٹ چارجز کا نتیجہ نہیں بنتا ہے۔"

ڈینیئل ڈیٹا بیس میٹرکس کو دیکھتا ہے۔ "یہ ایک ڈیٹا بیس ہوسکتا ہے۔"

تم ابھی تک نہیں جانتے۔

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

کوئی "ڈیٹا بیس کنکشن کھو گیا" غلطی کا پیغام نہیں ہے۔ پہلی چیز جو آپ دیکھیں گے وہ یہ ہے کہ سب سے سست ردعمل (p95 لیٹنسی) آہستہ سے آہستہ ہوتا جا رہا ہے۔ ایپ میں اسٹیٹس بار (ui/src/comComponents/StatusRibbon.jsx) "ڈیگریڈڈ۔ انویسٹی گیشن" میں تبدیل ہوتا ہے جب ایک سے زیادہ اسٹیٹس چیک لگاتار ناکام ہو جاتے ہیں، اس لیے یہ ایک ہی سست درخواست سے متحرک نہیں ہوتا ہے۔

آپ کیا جانتے ہیں

ٹریفک دونوں بادلوں میں ہے۔ تاخیر AWS بیس لائن سے بدتر ہے۔ صرف ایک غلطی کی بجائے متعدد تصدیقی ناکامیوں کے بعد اسٹیٹس بار کو پلٹ دیا گیا۔

جو آپ ابھی تک نہیں جانتے

چاہے یہ لوڈ بیلنسر، پوڈ، ڈیٹا بیس، یا خراب تعیناتی ہو۔ اس لیے قیاس آرائیاں نہ کریں۔ پہلے معلومات اکٹھی کریں۔

مرحلہ 1۔ شفٹ کرنا بند کریں۔

مت بھاگو shift-traffic.sh GKE پر واپس جائیں جب تک کہ آپ سمجھ نہ لیں کہ کیا ہوا ہے۔ وہ اوقات لکھیں جو آپ محسوس کرتے ہیں۔

کچھ اور کرنے سے پہلے، آپ جو کچھ دیکھتے ہیں اسے نوٹ کر لیں: اصل غلطی کا پیغام، نقل کی اصل تعداد، اور اصل ٹائم سٹیمپ۔

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

مرحلہ 2۔ ثبوت جمع کریں۔

API کی غلطیاں پڑھیں۔

kubectl -n production logs deployment/clearpay-api --tail=100 | grep error

ڈیٹا بیس کے لیے الفاظ تلاش کریں۔ کنکشن کی خرابی، "بہت زیادہ کنکشنز"، یا پول میں کلائنٹ کا انتظار کرتے وقت ٹائم آؤٹ ہوا۔ ڈیٹا بیس کے لفظ کے بغیر 5xx کی غلطی کسی دوسرے مقام کی طرف اشارہ کرتی ہے، جیسے گیٹ وے یا خراب تقسیم۔

چیک کریں کہ کبرنیٹس کتنے پوڈز چل رہے ہیں۔

kubectl -n production get hpa clearpay-api

موازنہ REPLICAS کے ساتھ maxReplicas. زیادہ چڑھنے کا مطلب ہے بوجھ میں اضافہ۔ یہ ایک اشارہ ہے، ابھی تک کوئی وجہ نہیں ہے۔

پھر باب 22 میں جدول میں اصل اعداد درج کریں۔

RDS max_connections:          87
AWS, 1 process × 10:          10
GKE, 7 replicas × 10:         70
Right now:                    80, close to the limit
GKE at maxReplicas 8:         80, worst case 90, over the limit

50/50 میرا کلسٹر

فرض کریں کہ آپ ڈینیئل کی کہانی میں شامل ہو رہے ہیں، اپنے کلسٹر پر وہی دو کمانڈ چلائیں: AWS 50/GKE 50 پر اس لیب نے دکھایا:

HPA:       cpu 4%/70%, MINPODS 1, MAXPODS 3, REPLICAS 1
pods:      1 Running
logs:      no error lines in the last 100
RDS:       max_connections=81
           two sessions on database clearpay
status:    not Degraded

یہاں سب سے زیادہ خراب صورت حال 40 تک ہے، لیکن 81 سے کم۔ بھاگیں نہیں۔ rollback.sh جب تک کہ آپ کے نمبر باب 6 کی حد سے زیادہ خراب نہیں ہیں۔

اگر HPA اب بھی 1 ہے اور نوشتہ جات خاموش ہیں، تو اس کا دھیان رکھیں۔ یہی ثبوت ہے۔ اسے جاری رکھیں۔

ناکامی کیسے بنتی ہے۔

AWS اکیلے یہ کبھی حاصل نہیں کر سکتا۔ اکیلا GKE کبھی بھی اس مسئلے کو حل نہیں کرے گا۔ یہ صرف اس وقت ہوتا ہے جب دونوں پورے بوجھ سے چل رہے ہوں، اور ہجرت کا منصوبہ جان بوجھ کر دونوں کے لیے چلتا رہے۔

ڈینیئل کو بتائیں: "ریپلیکس کی تعداد میں اضافہ ہوا ہے۔ پول کیلکولیشن ہمیں ہمارے ڈیٹا بیس کی حدود کے قریب لے جا رہے ہیں۔ یہ صلاحیت ہے، کوبرنیٹس نہیں۔"

مرحلہ 3۔ رول بیک

مایا: "آپ کیا تجویز کرتے ہیں؟"

نمبروں کا باب 6 میں لکھی گئی حدود سے موازنہ کریں۔ ابھی نئی انتہا نہ بنائیں۔

"کسٹمر کو واپس AWS پر بھیجیں۔ غلطی حد سے زیادہ ہے، گاہک متاثر ہوتا ہے، اور رول بیک کی جانچ کی جاتی ہے۔"

مایا: "ٹھیک ہے، کوشش کرو۔"

./scripts/rollback.sh  ~/.ssh/clearpay-deployer

مندرجہ بالا خاکہ دو کاموں کو دکھاتا ہے جس کے ذریعہ انجام دیا گیا ہے: rollback.sh. سب سے پہلے shift-traffic.sh 100 0 تمام کسٹمر ٹریفک کو واپس AWS پر بھیجیں اور GKE سے ٹریفک ہٹا دیں۔ دوسرا، اسکرپٹ AWS EC2 سرور سے SSH کے ذریعے جڑتا ہے، ROLLBACK_ACTIVE=true API ماحول فائل کو محفوظ کریں اور API سروس کو دوبارہ شروع کریں۔ API پھر AWS کو فعال پلیٹ فارم کے طور پر رپورٹ کرے گا اور ClearPay UI میں ایک منفرد "رول بیک ٹو AWS" بینر کو فعال کرے گا۔ یہ اقدامات ٹریفک کو بحال کریں گے اور آپریٹرز کو رول بیکس دیکھنے کی اجازت دیں گے۔

سیٹ terraform.tfvars کو 08-edge یہ 100 اور 0 پر واپس آجاتا ہے، لہذا اسے بعد میں لاگو کرنے سے رول بیک منسوخ نہیں ہوگا۔

مرحلہ 4۔ تصدیق کریں کہ رول بیک نے کام کیا۔

curl -k https://api.clearpay.test/api/info

platform پڑھیں aws اور rollback_active پڑھیں true. UI ریفریش: ایک سرخ "رول بیک ٹو AWS" بینر ظاہر ہوتا ہے اور اسٹیٹس بار All systems operational ایک بار جب صحت کی کافی جانچ پڑتال ہو جائے۔

پھر ان میں سے ہر ایک کو ثبوت کے ساتھ تصدیق کریں، مفروضوں سے نہیں۔

• درخواستیں ناکام ہونا بند ہوگئیں (synthetic-health.sh ریٹرن 200)۔

• تاخیر AWS باب 6 کی سطح پر واپس آگئی ہے۔

• ڈیٹا بیس مستقل ہے۔ رول بیک سے ٹھیک پہلے کی منتقلی بالکل 1 ڈیبٹ دکھائے گی، 0 یا 2 نہیں۔

عمارہ: "مجھے پرواہ نہیں ہے کہ ٹریفک AWS سے واپس آجائے۔ کیا ٹرانسفر ایک بار ہوا؟"

ڈیٹا بیس لین دین کی تاریخ کے ساتھ جواب دیتا ہے، نہ کہ لوڈ بیلنس کے ساتھ۔ باب 3 میں آئیڈیمپوٹنٹ کلید وہ ہے جو یہاں دوبارہ کوشش کی گئی منتقلی کو محفوظ بناتی ہے یہاں تک کہ اگر پہلی کوشش GKE میں گئی اور دوبارہ کوشش AWS میں گئی۔

واقعے کے جائزے کے مقاصد کے لیے، "اطلاع" سے لے کر "AWS سے ٹریفک واپس" تک منٹوں کی تعداد ریکارڈ کریں۔

مرحلہ 5۔ وجہ علاج

ڈینیئل: "ان نمبروں کو دوبارہ ہونے سے روکنے کے لیے آپ کیا تبدیل کریں گے؟"

چار حقیقی اختیارات ہیں، اور ہر ایک کی قیمت ہے۔

• کم DB_POOL_SIZE درج ذیل معیار: فی عمل کم کنکشن۔ یہ سستا اور تیز ہے۔ ہر پوڈ بیک وقت کم ڈیٹا بیس سوالات کی خدمت کرسکتا ہے۔

• اپنا HPA کم کریں۔ maxReplicas کو k8s/overlays/production/patch-hpa.yaml. رقم کو محدود کریں۔ GKE حقیقی دنیا کے ٹریفک اسپائکس کے دوران مزید پیمانہ نہیں لگا سکتا۔

• آر ڈی ایس اپ لوڈ کریں۔ max_connections حسب ضرورت پیرامیٹر گروپس استعمال کریں۔ ہر کنکشن ڈیٹا بیس میموری استعمال کرتا ہے اور اس کی ایک چھوٹی سی مثال استعمال کرتا ہے: db.t3.micro اسے بہت زیادہ سیٹ کرنا اسے شروع ہونے سے روک سکتا ہے۔ سب سے پہلے، مثال کے سائز کے لیے AWS رہنما خطوط چیک کریں۔

• پوسٹگریس کے سامنے کنکشن پولر رکھیںجیسے PgBouncer یا RDS Proxy۔ بہت سے ایپ کنکشن کئی ڈیٹا بیس کنکشن کا اشتراک کرتے ہیں۔ یہ بہترین طویل مدتی حل ہے اور اسے ترتیب دینے کے لیے سب سے زیادہ محنت درکار ہے۔

یہ کتاب آپ کے لیے کسی ایک کا انتخاب نہیں کرتی ہے۔ لکھیں کہ آپ نے کیا انتخاب کیا اور کیا چھوڑ دیا۔

اصل تبدیلیوں کو کم کرنے کے لیے، پول کا سائز کم کریں۔ 6 فی پوڈ (GKE پر 8 × 6 = 48، AWS پر 10) 58 ہے۔ یہ پوری چھت پر بھی 87 سے کم فٹ بیٹھتا ہے۔

ہنگامی حالات میں، اسے حقیقی وقت میں ترتیب دیا جا سکتا ہے۔

kubectl -n production set env deployment/clearpay-api DB_POOL_SIZE=6

لائیو تبدیلیاں کوئی ریکارڈ نہیں چھوڑتی ہیں اور اگلی تعیناتی انہیں صاف کر دیتی ہے۔ پائپ لائن کے ذریعے حقیقی تبدیلیاں کرنا: ترتیبات DB_POOL_SIZE کو k8s/base/deployment.yamlکمٹ اور پش main. پائپ لائنیں اسٹیجنگ کی تعمیر، بازیافت اور تعیناتی کرتی ہیں۔ اپنے HPA کو زیادہ سے زیادہ تک پہنچانے کے لیے کافی طاقتور لوڈ ٹیسٹ کی تیاری کے لیے باب 18 کے اقدامات کو زیادہ ہم آہنگی کے ساتھ استعمال کریں۔ ایک فکس جو صرف ہلکے بوجھ کے نیچے سے گزرتا ہے کچھ بھی ثابت نہیں کرتا ہے۔ اس کے بعد یہ پروموشن گیٹ چلاتا ہے اور باب 19 پائپ لائن کے کام کو فروغ دیتا ہے۔

مرحلہ 6۔ دوبارہ شروع کریں۔

مایا: "کیا آپ 10 فیصد کے لیے تیار ہیں؟"

"ہاں۔ API ٹھیک ہے، مصنوعی جانچیں صاف ہیں، غلطیاں حد کے اندر ہیں، پول ریاضی حد میں ہے، رول بیکس کی جانچ کی جاتی ہے۔"

ڈینیل: "میں متفق ہوں۔"

مایا: "یہ آپ کا فون ہے۔"

پہلے رول بیک پرچم کو صاف کریں۔

./scripts/clear-rollback-flag.sh  ~/.ssh/clearpay-deployer

UI کو ریفریش کریں۔ رول بیک بینر غائب ہو گیا ہے۔ اگر آپ جھنڈا چھوڑ دیتے ہیں تو، بینر صحت یاب ہونے کے بعد بھی نظر آتا رہے گا، لوگوں کو اسے نظر انداز کرنے کی تربیت دیں گے۔

پھر شروع سے ابواب 21 اور 22 کو دہرائیں۔

./scripts/shift-traffic.sh 99 1
# observe, compare, record, decide

./scripts/shift-traffic.sh 90 10
# observe, compare, record, decide

./scripts/shift-traffic.sh 75 25
./scripts/shift-traffic.sh 50 50
./scripts/shift-traffic.sh 25 75
./scripts/shift-traffic.sh 10 90
./scripts/shift-traffic.sh 0 100

اس مرحلے پر جہاں آخری واقعہ پیش آیا تھا وہاں HPA اور ایرر لائنز کا بغور مشاہدہ کریں۔ وہ مرحلہ ہے جہاں اصلاح خود بولتی ہے۔

اخراجات کے لیجر میں ایک لائن شامل کریں۔ دوسری بار شفٹ پاس کرنے کا مطلب ہے دونوں کلاؤڈ بلز پر زیادہ وقت۔ لاگت کو ایک "مائیگریشن لاگت" نمبر میں ڈالنے کے بجائے، انہیں مرئی رکھیں۔

اس باب میں ہنر

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

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

یہ چوکی ہے۔ GKE 100% سروس فراہم کرتا ہے۔

AWS اب ایک قیمتی حفاظتی جال ہے، نہ کہ بھولی ہوئی باقیات۔

حصہ 7۔ ہجرت کیسے مکمل کی جائے۔

GKE تمام صارفین کی خدمت کرتا ہے۔ AWS اب بھی حفاظتی جال کے طور پر چل رہا ہے اور وہ اب بھی آپ سے چارج لیتے ہیں۔ یہ حصہ کٹ اوور کو ثبوت، تاریخوں کے حفاظتی جالوں میں بدل دیتا ہے، اور ہر وہ چیز ہٹا دیتا ہے جس کی آپ کو مزید ضرورت نہیں ہے۔

باب 24۔ نمبروں کے ساتھ کٹ اوور ثابت کرنا

جمعرات صبح 9 بجے

مایا کی 10 بجے کمپنی کے لیڈروں کے ساتھ میٹنگ ہے۔ وہ آپ کی میز کے سامنے رکی، اس کا لیپ ٹاپ ایک خالی صفحے پر کھلا ہے۔

مایا: "لیڈرز ہماری کال پر بالکل نہیں تھے اور وہ صرف ایک بات پوچھتے ہیں: کیا صارفین نے اس حرکت کو دیکھا ہے؟ مجھے ایک فوری سمری کی ضرورت ہے جو میں اسکرین پر دکھا سکوں: درخواستوں کی تعداد، ناکام درخواستوں کی تعداد، اے ڈبلیو ایس کے مقابلے میں ایپ کتنی تیز ہے، اور کیا کسی نے کوئی بندش دیکھی ہے۔ کیا آپ اسے 10 سے پہلے حاصل کر سکتے ہیں؟"

آپ سر ہلاتے ہیں۔ اس نے جو بھی نمبر مانگے وہ دو اسکرپٹس سے آیا جسے آپ پہلے سے جانتے تھے۔

قدم

100% GKE اب دو چیک چلاتا ہے جو عوامی پتوں کے لیے مشکل نمبر تیار کرتے ہیں۔

HOST=$(terraform -chdir=infra/gcp/terraform/08-edge output -raw public_hostname)
./scripts/promotion-gate.sh "https://$HOST" 
  alice@clearpay.dev password123 bob@clearpay.dev

پھر بھاگو load-test.sh کے خلاف https://$HOST اسکور کارڈ کو باب 6 کی ترتیبات میں کاپی کریں۔ باب 22 لوپس کی تعداد شامل کریں۔ synthetic-health.sh لاگ

ثبوت

ذیل میں ہماری لیب سے ایک ٹیبل ہے۔ آپ کا فون نمبر ہے:

Production requests (counted checks, not a full dashboard total):
  40 /health one minute after 0 / 100:  3 aws, 37 gke
  40 /health ninety seconds later:      0 aws, 40 gke
  load-test.sh 10 × 20s:                ok=310  failed=0
  promotion-gate.sh:                    5 passed, 0 failed
Successful requests:                 310 + 40 + 5 in those runs
Failed requests:                     0
5xx errors:                          0.0 %
p95 latency (GKE, 100%):             647 ms
  Chapter 6 AWS baseline was 164 ms.
  Chapter 18 GKE staging (port-forward) was 1157 ms.
Sustained customer-visible outage:   0 seconds

چونکہ مقامی Prometheus GKE نہیں دیکھتا تھا، اس لیے یہ جدول حسابی چیک استعمال کرتا ہے۔ ڈیش بورڈ کے ٹوٹل نہ بنائیں جو آپ نے کبھی ناپے ہوں۔

GKE کے وجود سے پہلے ہم نے باب 6 میں جو حدیں بنائی تھیں ان کے خلاف جدول کو چیک کریں۔

• بندش کی حد: کوئی 5xx غلطیاں حد سے زیادہ نہیں ہوں گی۔ اس لیب میں کوئی ناکام درخواستیں نہیں ہیں۔

• ناکامی کی حد: p95 چھت سے نیچے۔ اس مشق کا 647 ms مثال کے طور پر 1500 ms کی اوپری حد سے نیچے ہے، لہذا یہ گزر جاتا ہے۔

پاس ہونا ہی سب کچھ نہیں ہے۔ 647ms AWS 164ms کا تقریباً 4 گنا ہے۔ صارفین کو کسی قسم کی بندش کا سامنا نہیں کرنا پڑا، لیکن تمام درخواستوں کو سست کر دیا گیا۔ اسے مت چھپائیں، ایمانداری سے لکھیں۔ اس کتاب کا آخری حصہ اس کی وجہ بتاتا ہے۔

ٹیبل یہ کیوں نہیں کہتا کہ "کوئی بھی ناکام درخواستیں نہیں ہیں"؟

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

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

مکمل ہونے پر:

• ٹیبل کی ہر لائن میں ایک ناپا ہوا نمبر ہوتا ہے۔

• ناکام لائنوں سمیت ہر لائن کو باب 6 کی حدود کے خلاف چیک کیا جاتا ہے۔

باب 25۔ GKE پر چل رہا ہے اور AWS کی تاریخیں ترتیب دے رہا ہے۔

جمعہ صبح 10 بجے

مایا قائدین کے سوالات کے ساتھ میٹنگ سے واپس آگئیں۔

مایا: "تو صارفین کے لیے کیا بدلا ہے؟"

آپ نمبروں کو دیکھیں۔ ٹریفک 100% GKE ہے۔ منتقلی کامیاب رہی۔ تمام مصنوعی ٹیسٹ پاس ہوتے ہیں۔ PostgreSQL اب بھی AWS پر ہے۔ EC2 سرورز کسی کی خدمت نہیں کرتے۔

"پتہ وہی رہا اور کسی نے بھی بندش کا مشاہدہ نہیں کیا۔"

مایا: "پھر یہ سسٹم اب آپ کا ہے۔ اور میں پرانے سرور کو بند کرنے کے لیے کیلنڈر کی تاریخ چاہتی ہوں۔"

مرحلہ 1. رن دیکھیں

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

اس لیپ کے لیے 100% ونڈو 5/5 گیٹ کے ساتھ کئی منٹ تک جاری رہی۔ failed=0. اسے لکھ دیں۔ ہفتے کے آخر میں لیب ایک نتیجہ خیز ہفتہ نہیں ہے۔

مرحلہ 2۔ اطلاعات چیک کریں۔

مرحلہ 7 میں، آپ نے الرٹ پالیسی بنائی۔ ClearPay API - elevated error rate5 منٹ میں 5+ ایرر لائنوں پر چلتا ہے۔ کوئی نوٹیفکیشن چینل نہیں ہے، اس لیے کسی کو پتہ نہیں چلے گا کہ یہ کب چلتا ہے۔ ایک انتباہ جو کسی تک نہیں پہنچتا ہے بالکل بھی انتباہ نہیں ہے۔

ایک حقیقی نظام کے لیے، کلاؤڈ مانیٹرنگ میں ایک نوٹیفکیشن چینل شامل کریں اور اپنے صارفین کو غلطیاں بھیجے بغیر سٹیجنگ ٹیسٹ کو متحرک کریں۔ اس مشق کے لیے، اس فرق کو نوٹ کریں کہ پالیسی موجود ہے اور کسی کو صفحہ نہیں بنایا جا رہا ہے۔

مرحلہ 3۔ صلاحیت کا جائزہ

اپنی کھڑکی سے باہر اپنے HPA پر ایک نظر ڈالیں۔

kubectl -n production get hpa clearpay-api

لیب نے 100% لوڈ ٹیسٹنگ کے دوران 1 ریپلیکا اور 4-7% CPU کو برقرار رکھا، یہاں تک کہ 15.5 درخواستیں فی سیکنڈ پر بھی۔ ایک پھلی کافی تھی۔ تین e2-medium ایک API Pod کے لیے درکار مشینوں کی تعداد اس ٹریفک کی ضرورت سے زیادہ ہے۔

گوگل کمٹڈ استعمال ڈسکاؤنٹس (CUD) پیش کرتا ہے۔ یعنی، وہ ایک یا تین سال تک مشین کی ایک مخصوص مقدار استعمال کرنے کے وعدے کے بدلے کم قیمت پیش کرتے ہیں۔

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

مرحلہ 4۔ ایک ہینڈ اوور بنائیں

یہ ان لوگوں کے لیے لکھیں جو ہجرت میں شامل نہیں ہیں۔ یہ ہینڈ آن ورژن:

Logs:       kubectl -n production logs deployment/clearpay-api
Dashboard:  http://localhost:3000 if observability/docker-compose.yml
            is up. GKE series may be empty.
Alert:      Cloud Monitoring "ClearPay API - elevated error rate"
            No notification channel.
Rollback:   scripts/rollback.sh, only while EC2 still exists.
Hostname:   terraform output public_hostname
            terraform output static_ip_address
            (yours, not a hostname copied from this book)

مرحلہ 5. AWS میں تاریخیں درج کرنا

scripts/rollback.sh یہ صرف اس وقت تک کام کرتا ہے جب تک EC2 سرور موجود ہے، اور سرور کو اس کے موجود ہونے والے ہر دن کا بل دیا جاتا ہے۔ فیصلہ کریں کہ آپ اسے کب تک رکھنا چاہتے ہیں، اس کی وجہ بتائیں اور قیمت مقرر کریں۔

AWS daily cost:              ~$1.25/day (infra/aws/COST.md)
Retention window:            ___ days
Decommission date:           ___
Total safety-margin cost:    ___ days × $1.25 = $___

اس لیب میں، کوئی اضافی دن استعمال نہیں کیے گئے تھے اور 100% GKE کو ظاہر کرنے کے لیے اسی دن AWS کمپیوٹ کو ختم کر دیا گیا تھا۔ کیونکہ یہ ایک جداگانہ مشق ہے۔

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

اس بات کو یقینی بنانے کے لیے کہ ڈیڈ لائن کا دباؤ آپ کو فیصلے کرنے پر مجبور نہ کرے۔

اس لیبارٹری کے قوانین: وزن 0/100، گیٹ 5/5، لوڈ ٹیسٹ failed=0HPA 1 ہے اور کوئی رول بیک نہیں ہے۔

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

مکمل ہونے پر:

• میں نے پیداوار کے عمل کو براہ راست اور تحریری طور پر دیکھا۔

• انتباہی جگہیں لاگ ان ہیں۔

• صلاحیت کا جائزہ لیں اور CUD کے تعین کو ریکارڈ کریں۔

• حوالگی کا نوٹ موجود ہے۔

• برقرار رکھنے کی مدت، ضائع کرنے کی تاریخ، لاگت اور قواعد درج ہیں۔

باب 26۔ AWS سرور کا خاتمہ

جمعہ 3 بجے

تاریخ آچکی ہے اور باب 25 کے قواعد پورے ہوچکے ہیں۔ EC2 سرور کو ہٹا دیں اور ڈیٹا بیس کو رکھیں۔ یہ اس ہجرت کا حصہ نہیں تھا۔

قدم

ریپوزٹری روٹ پر حتمی جانچ پڑتال کی جاتی ہے۔ GKE کو گیٹ سے گزرنے کے لیے عوامی پتے درکار ہیں۔

HOST=$(terraform -chdir=infra/gcp/terraform/08-edge output -raw public_hostname)
./scripts/promotion-gate.sh "https://$HOST" 
  alice@clearpay.dev password123 bob@clearpay.dev

پھر یقینی بنائیں کہ Terraform ان سرورز کو ٹریک کر رہا ہے جنہیں آپ ہٹانا چاہتے ہیں۔

cd infra/aws/terraform
terraform state show aws_instance.api   # confirm you have the right resource

اگلا، استعمال کرتے ہوئے ذخیرہ کی جڑ پر واپس جائیں: cd ../../..صرف AWS کمپیوٹ وسائل کو ہٹاتا ہے۔

./scripts/teardown-aws-compute.sh
# Pass --yes to add -auto-approve after you have read a plan once.

اس قدم کے بعد، AWS میں کوئی رول بیک نہیں ہے۔ یہ باب 25 میں آپ کے فیصلے کا خلاصہ ہے۔

تباہی کا منصوبہ پڑھیں

اسکرپٹ صرف درج ذیل آئٹمز کو حذف کرتا ہے۔

RDS برقرار ہے۔

ڈیٹا بیس کے قواعد ان کے اپنے Terraform وسائل ہیں۔ aws_security_group_rule.db_from_apiاسکرپٹ پہلے اسے ہٹا دے گا۔ اگر قاعدہ ڈیٹا بیس سیکیورٹی گروپ کے اندر موجود ہے تو، AWS API سیکیورٹی گروپ کو حذف کرنے سے انکار کرتا ہے جبکہ ڈیٹا بیس API سیکیورٹی گروپ کا حوالہ دیتا ہے۔

پوری terraform destroy کو infra/aws/terraform PostgreSQL کو بھی حذف کر دیا جائے گا۔ اسے یہاں استعمال نہ کریں۔

اپنے اسناد کو صاف کریں۔

• AWS پر میری SSH کلیدی جوڑی میری اسکرپٹ کے ساتھ غائب ہوگئی۔ مقامی نجی کلید کو حذف کریں۔ ~/.ssh/clearpay-deployer اگر صرف اس سرور پر استعمال کیا جائے۔

• پرانے سرور کی طرف اشارہ کرنے والی دیگر تمام اندراجات کو ہٹا دیں، جیسے پرانے IP کے ساتھ ذخیرہ کردہ میزبان یا اسکرپٹ۔

• کسی بھی CI/CD راز یا متغیرات کو ہٹا دیں جو پرانے سرور کا حوالہ دیتے ہیں۔

خاکہ اپ ڈیٹ

اب باب 7 میں ڈبل کلاؤڈ خاکہ غلط ہے۔ نئی تصویر صرف ایک لوڈ بیلنسر کے پیچھے GKE ہے جس میں ڈیٹا بیس ابھی بھی AWS میں ہے، جیسا کہ ہم نے باب 7 میں کہا تھا کہ پروجیکٹ کو ختم کر دیا جائے گا۔

مکمل ہونے پر:

• انہدام سے پہلے گیٹ عوامی خطاب کے لیے گزرا۔

• AWS کمپیوٹ تباہ ہو گیا ہے اور RDS اب بھی موجود ہے۔

• مقامی تعیناتی کیز کو ہٹا دیا جاتا ہے یا جان بوجھ کر محفوظ کیا جاتا ہے۔

• یہ اس سے میل کھاتا ہے جو آرکیٹیکچر ڈایاگرام چل رہا ہے۔

باب 27 جی سی پی اور ڈیٹا بیس کو ختم کرنا

جمعہ شام 5:30 بجے

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

یہ ایک تجربہ گاہ ہے۔ ایک بار جب آپ کے نوٹس مکمل ہو جائیں، تو ایسی کوئی بھی چیز ہٹا دیں جس پر آپ کے پیسے خرچ ہوں، بشمول گیٹ وے لوڈ بیلنسرز، GKE مشینیں، کلاؤڈ NAT، رجسٹریاں، اور RDS ڈیٹا بیس۔

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

قدم

ذخیرہ کی جڑ سے:

./scripts/teardown-gcp.sh
# Pass --yes to skip the prompt and -auto-approve each stage.

سکرپٹ:

1. گیٹ وے اور اس کی پیداوار اور اسٹیجنگ ورک بوجھ کو حذف کریں۔ Kubernetes گیٹ وے کے لیے گوگل لوڈ بیلنسر کا ایک حصہ بناتا ہے، لیکن Terraform اس کے بارے میں نہیں جانتا۔ اگر آپ پہلے اسے حذف کرتے ہیں تو آپ Google سے اپنا گیٹ وے ہٹا سکتے ہیں۔ اگر آپ اسے چھوڑ دیتے ہیں، تو آپ ان وسائل کے ساتھ پھنس سکتے ہیں جو Terraform نے نہیں بنائے تھے۔

2. پھانسی terraform destroy الٹ ترتیب میں: 08-edge → 07-observability → 06-secrets → 05-identity → 04-registry → 03-gke → 02-network → 01-foundation. بعد کے مراحل پچھلے مراحل پر منحصر ہوتے ہیں، اس لیے وہ پہلے نیچے آتے ہیں۔

زمرہ yes اسکرپٹ پرامپٹ سے ہر ٹیرافارم پلان کو پڑھیں اور تصدیق کریں۔

نام کی جگہ اس میں واقع ہوسکتی ہے: Terminating چند منٹوں کے لیے۔ جاری رکھنے سے پہلے اسکرپٹ ہر حذف کے لیے 180 سیکنڈ تک انتظار کرے گا۔ کلسٹر کو حذف کرنے سے کلسٹر بھی ہٹ جاتا ہے۔

پھر ڈیٹا بیس کو ہٹا دیں۔ منتقلی کو جان بوجھ کر AWS میں ختم کیا گیا تھا، لیکن لیب کو اس کے لیے تقریباً $0.80 فی دن ادا کرنا جاری نہیں رکھنا چاہیے۔

cd infra/aws/terraform
terraform destroy

آخر میں، اسے حذف کریں. api.clearpay.test لائن /etc/hosts.

یہ کتاب GCP پروجیکٹس کو تخلیق یا حذف نہیں کرتی ہے۔ پروجیکٹ کو حذف نہ کریں جب تک کہ اس میں صرف یہ لیب نہ ہو۔

مکمل ہونے پر:

• kubectl get ns اب ظاہر نہیں کیا گیا ہے۔ staging یا productionیا کلسٹر غائب ہو گیا ہے۔

• ہر infra/gcp/terraform/0*-* سٹیج تباہ ہو گیا ہے

• terraform destroy میں ختم ہوا infra/aws/terraform

• آپ کے GCP اور AWS بل اس لیب کو ابھی تک چلتے ہوئے نہیں دکھاتے ہیں۔

یہ چوکی ہے۔ کام ہو گیا ہے۔

اس سے پہلے کہ آپ بھول جائیں، لکھیں کہ اصل میں کیا ہوا، بشمول آپ کے بل۔

باب 28۔ نقل مکانی کی تاریخ بنائیں

چوتھی سوموار صبح 9 بجے

لکھیں کہ کیا ہوا، فن تعمیر، بل، اور تفصیلات غائب ہونے سے پہلے آپ کیا تبدیل کریں گے۔

حصہ 1۔ تعمیراتی ریکارڈ

پہلے:

User → nginx (TLS) → systemd-managed Node process → RDS Postgres

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

نقل مکانی:

بعد میں:

پھر ہر ماڈل کے بارے میں ایک مختصر پیراگراف لکھیں۔

• ٹریفک: عالمی بیرونی ایپلیکیشن لوڈ بیلنسر کے لیے وزنی پسدید، جس کے ذریعے تبدیل کیا گیا: shift-traffic.sh. یہ DNS نہیں ہے۔ اس کی وجہ یہ ہے کہ کیشڈ DNS جوابات رول بیکس کو سست کر دیتے ہیں۔

• تقسیم: GitHub ایکشنز اسٹیجنگ کے لیے تمام وعدوں کی تعمیر، بازیافت اور تعیناتی کرتی ہیں۔ پروڈکشنز کو صرف اس وقت درست سٹیجنگ امیجز ملتی ہیں جب انہیں پروموشنل گیٹ اور جائزہ لینے والوں کی طرف سے منظوری مل جاتی ہے۔

• ڈیٹا بیس: یہ کبھی منتقل نہیں ہوا۔ باب 4 میں وہی آر ڈی ایس مثال پورے وقت سچائی کا واحد ذریعہ رہا۔

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

• مشاہدہ: API کا اپنا JSON لاگ اور /metrics اختتامی پوائنٹس AWS اور GKE کے لیے ایک جیسے ہیں، اور کلاؤڈ لاگنگ سے لاگ پر مبنی ایرر میٹرکس بھی ہیں۔

• رول بیک: ٹریفک کے وزن کو تبدیل کرنے اور AWS پر جھنڈے لگانے کے لیے ایک اسکرپٹ، پہلی شفٹ سے پہلے جانچا گیا۔

حصہ 2۔ پوسٹ مارٹم

آپ چاروں مل کر نوٹوں کو دیکھتے ہیں۔ مایا اس سوال سے شروع ہوتی ہے جس کی ہر کوئی توقع کرتا ہے:

مایا: "کیا Kubernetes مسئلہ تھا؟"

"نہیں، اس نے وہی کیا جو ہم نے اسے کرنے کے لیے کہا تھا۔ صرف نوٹ کرنے والی چیز ڈیٹا بیس تھی۔ API کی ہر کاپی میں 10 کنکشن کھلے ہو سکتے ہیں، GKE ایک سے زیادہ کاپیاں چلا سکتا ہے، اور AWS اب بھی ایک ہی وقت میں صارفین کی خدمت کر رہا ہے۔ یہ ڈیٹا بیس کی حد کے قریب پہنچنے میں اضافہ کرتا ہے۔

اس چھوٹے کلسٹر میں کوئی مسئلہ نہیں تھا، جو کہ 81 کے مقابلے میں 40 کنکشنز تک پہنچ گیا ہے۔ ایک کلسٹر میں جو 8 کاپیوں تک پیمانہ ہے، وہی کل حد سے تجاوز کر جائے گا۔"

دانیال نے سر ہلایا۔ "یہ وہی ہے جو میں نے اپنی آخری کمپنی میں یاد کیا. تمام نمبر وہاں تھے اور کسی نے انہیں ایک ساتھ نہیں لگایا. آپ نے ٹریفک کے منتقل ہونے سے پہلے یہ کیا."

عمارہ: "ادائیگی کی رقم کا کیا ہوگا؟ کیا تمام ٹرانسفرز کا بل ایک بار دیا جاتا ہے؟"

"ہاں، فی شفٹ میں 3 غیرمعمولی چابیاں برقرار رکھی گئیں۔ حتیٰ کہ میں نے 100% GKE پر ادائیگی کو دوبارہ چلایا اور کوئی دوسرا چارج نہیں تھا۔"

مایا نے اپنا لیپ ٹاپ بند کر دیا۔ "تو اگلی بار ہم مختلف طریقے سے کیا کریں گے؟"

درج ذیل حصوں کو مکمل کریں:

کیا کام کیا:

• GKE کے وجود سے پہلے، بلٹ ان آئیڈیمپوٹینٹ کیز نے صارفین کی دوبارہ کوششوں کو پہلی کوشش سے مختلف کلاؤڈ تک محفوظ طریقے سے پہنچنے کی اجازت دی۔

• اسٹیجڈ ٹیرافارم کا مطلب ہے کہ ہر ناکامی ایک مرحلے کی طرف اشارہ کرتی ہے۔

• پائپ لائن کا مطلب ہے کہ پروڈکشن بالکل وہی تصویریں چلائیں جو گیٹ کے ذریعے پہنچی تھیں۔

• رول بیک کا باب 20 میں تجربہ کیا گیا، اس سے پہلے کہ اس کی ضرورت ہو۔

اس لیب میں درپیش مسائل:

• چونکہ مقامی پرومیتھیس نے کبھی GKE نہیں دیکھا، باب 24 نے ڈیش بورڈ کے ٹوٹل کے بجائے حسابی چیک استعمال کیا۔

• الرٹ پالیسی میں کوئی اطلاعی چینل نہیں ہے۔

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

• GKE کا p95 AWS سے تقریباً 4 گنا تھا۔

بنیادی وجہ: دو معقول ترتیبات، DB_POOL_SIZE=10 اور HPA کی maxReplicasمختلف جگہوں سے منتخب۔ کسی نے بھی ڈیٹا بیس کی حدود کے لیے پروڈکٹ کو اس وقت تک چیک نہیں کیا جب تک کہ ہجرت دونوں بادلوں کو بیک وقت نہیں چلاتی۔ ایک بار جب آپ اسے تلاش کر لیتے ہیں تو حل پیچیدہ نہیں ہوتا ہے۔ اسے تلاش کرنے کے لیے، آپ کو جوابات کو چھوڑنے کے بجائے باب 23 کو ایک حقیقی تحقیقات کے طور پر سمجھنا چاہیے۔

فیصلے اور ان کے فائدے اور نقصانات:

• آٹو پائلٹ کے ساتھ GKE سٹینڈرڈ: نوڈ پولز اور آٹو اسکیلنگ پر مکمل کنٹرول، لیکن آپ کو ان کو سمجھنا اور اسکیل کرنا چاہیے۔ اس لیب نے تین کمپیوٹرز کے لیے ادائیگی کی جو زیادہ تر بیکار تھے۔ آٹو پائلٹ نے کنکشن کی حدود کے اس خطرے کو اپنے شیڈول کے اندر چھپا رکھا ہے، بہتر یا بدتر۔

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

• VPN کے بجائے IP وائٹ لسٹ کے ساتھ عوامی ڈیٹا بیس کے اختتامی پوائنٹس: کوئی سیٹ اپ ٹائم اور کوئی ماہانہ VPN چارجز نہیں۔ لاگت یہ ہے کہ RDS صرف ایک IP کی اجازت دیتا ہے اور TLS کی ضرورت ہونے پر بھی اس کا پبلک اینڈ پوائنٹ ہوتا ہے۔

• اپنے ڈیٹا بیس کو AWS پر رکھنا: بادلوں کے درمیان سے گزرنے والے تمام سوالات کی قیمت پر ایک آسان اور زیادہ محفوظ منتقلی۔

تو دوسری ہجرت میں کیا تبدیلی آتی ہے؟ ٹریفک کو منتقل کرنے سے پہلے ڈیٹا بیس کا اشتراک کرنے والے تمام ماحول میں کنکشن کی بدترین تعداد کا حساب لگائیں۔ اپنی اصل حدود سے اس کا موازنہ کریں۔ ریئل ٹائم دریافت کے بجائے اسے چیک لسٹ آئٹم بنائیں۔

حصہ 3۔ پوسٹ لاگت

یہ ہینڈ آن ورژن:

بجٹ: GCP کے پانچ دنوں کی لاگت تقریباً $25 ہے۔

اصل دوہری عملدرآمد: کل $4.30، AWS $1.25 + GCP $3.05۔ GCP $3.05 پر مفت ٹرائل کریڈٹ لاگو کیا گیا تھا، لہذا اصل GCP بل $0 تھا۔

ہجرت شیڈول کے مطابق ہوئی۔ کوئی حادثات، رول بیک یا دوسری شفٹوں کی ضرورت نہیں تھی۔

کلسٹر زیادہ پروویژنڈ ہے۔ 3 GKE نوڈس نے 1 API Pod کو 4-7% CPU کے ساتھ سپورٹ کیا۔

معیاری GKE کو اس کی تعلیمی قدر کے لیے منتخب کیا گیا تھا۔ اس کام کے بوجھ کے لیے آٹو پائلٹ سستا ہوتا۔

میں نے کوئی CUD نہیں خریدا ہے۔

نتیجہ: ہجرت بجٹ کے اندر اچھی طرح رہی، لیکن GKE سیٹ اپ نے کام کے بوجھ سے زیادہ صلاحیت استعمال کی۔

اپنے کلاؤڈ بل سے اپنا نمبر درج کریں۔ اس کتاب میں اس کا کوئی نعم البدل نہیں ہے، اور اندازہ لگایا گیا نمبر وہی غلط درستگی کا ہوگا جس سے پورا پروجیکٹ گریز کرتا ہے۔

مکمل ہونے پر:

• پہلے، دوران، اور بعد کے خاکے ملتے ہیں جو کیا گیا تھا۔

• پوسٹ مارٹم کی تفتیش واضح طور پر بنیادی وجہ بتاتی ہے۔

• پوسٹ مارٹم میں اصل تعداد شامل ہے۔

اس منصوبے کے بعد کیا آتا ہے

یہ پروجیکٹ آپ کو کن سوالات کے ساتھ چھوڑتا ہے؟

باب 13 نے اس پر جھنڈا لگایا اور جان بوجھ کر اگلے مرحلے پر چلا گیا۔ کس مقام پر پوسٹگری ایس کیو ایل کو AWS پر رکھنا خطرے اور انجینئرنگ کے وقت کے لحاظ سے اسے منتقل کرنے سے زیادہ مہنگا ہو جاتا ہے؟ بادلوں کے درمیان منتقل ہونا، دو فراہم کنندگان پر انحصار، اور باب 23 میں کنکشن پول کے دباؤ سب اس پیمانے کے ایک ہی طرف ہیں۔

اپنے نوٹ سے دو نمبر ساتھ ساتھ رکھیں۔

AWS, Chapter 6:             p95 164 ms
GKE at 100%, Chapter 24:    p95 647 ms

API کو منتقل کر دیا گیا تھا اور صارفین کو کسی قسم کی بندش کا سامنا نہیں کرنا پڑا۔ تاہم، تمام درخواستیں تقریباً 4x سست تھیں۔

کوڈ تبدیل نہیں ہوا ہے۔ لوڈ ٹیسٹنگ میں کوئی تبدیلی نہیں آئی ہے۔ جو بدلا ہے وہ فاصلہ ہے۔ AWS میں، API اور ڈیٹا بیس ایک ہی ڈیٹا سینٹر میں واقع تھے۔ GKE پر، تمام سوالات Google کو چھوڑ دیتے ہیں۔ us-east4Cloud NAT کے ذریعے باہر نکلیں اور انٹرنیٹ پر AWS پر جائیں۔ us-east-1اور یہ واپس آتا ہے۔ ایک ہی منتقلی متعدد سوالات کو انجام دیتی ہے، لہذا آپ اس اقدام کے لیے متعدد بار ادائیگی کرتے ہیں۔ گوگل لوڈ بیلنسر سامنے ایک اور ہاپ کا اضافہ کرتا ہے۔

مایا ٹیبل پڑھتی ہے۔ "یہ سست کیوں ہے؟"

"ڈیٹا بیس AWS پر ہی رہا۔ تمام سوالات بادلوں کے درمیان سے گزر گئے۔"

"کیا یہ غلطی تھی؟"

"نہیں۔ باب 7 میں، ہم نے آپ سے صرف API کو منتقل کرنے کو کہا، کیونکہ دونوں کو ایک ہی وقت میں منتقل کرنے سے ناکامیوں کو ٹریک کرنا بہت مشکل ہو جاتا ہے۔ مسئلہ API، نیٹ ورک، یا ڈیٹا بیس کی منتقلی سے ہی ہو سکتا ہے۔ لیکن کالز کی قیمت ہوتی ہے، لہذا اب ہم اس کی پیمائش کر سکتے ہیں۔"

مایا: "پھر، اگلا پروجیکٹ یہ ہے۔"

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

ایک بار پھر، یہ اس کی اپنی کتاب کے ساتھ ایک علیحدہ منصوبہ ہے۔ یہ یہاں ختم ہوتا ہے۔ GKE پر ClearPay API، جیسا کہ باب 7 میں بتایا گیا ہے، ڈیٹا بیس ابھی بھی AWS میں ہے۔

آخر میں کیا ہونا ہے۔

• Fintech API آپریشن اور کم سے کم کسٹمر UI (api/، ui/)

• AWS تعیناتی (infra/aws/)

• جی سی پی آرکیٹیکچر، سٹیجڈ ٹیرافارم (infra/gcp/terraform/)

• تجربہ شدہ تصاویر (.github/workflows/deploy.yml)

• Kubernetes مینی فیسٹ، دو ماحول کسٹمائز اوورلے (k8s/base/، k8s/overlays/)

• ڈیٹا بیس کنکشنز جن کی توثیق کی گئی ہے لیکن منتقلی نہیں ہوئی ہے (باب 13)

• خفیہ انتظام، اپ گریڈ .env فائل کو خفیہ مینیجر کو منتقل کریں (k8s/overlays/*/secretproviderclass.yaml، secretsync.yaml)

• وزنی بوجھ بیلنسر کے پیچھے GKE گیٹ وے (k8s/gateway/، infra/gcp/terraform/08-edge/)

• نوٹ بک میں مشاہداتی ڈیش بورڈ، اگر آپ نے اختیاری باب 17 مکمل کیا ہے۔observability/)

• لوڈ ٹیسٹنگ، پروموشن گیٹس، اور مصنوعی سٹیٹ اسکرپٹس (scripts/)

• مائیگریشن اسکور کارڈ (باب 6، 18، اور 24)

• لاگت کا لیجر، شروع سے آخر تک (باب 6 تا 28)

• ٹریفک کی نقل و حرکت کا طریقہ کار (scripts/shift-traffic.sh)

• رول بیک طریقہ کار (scripts/rollback.sh، scripts/clear-rollback-flag.sh)

• فن تعمیر کا خاکہ (باب 4، 7، 9، 11، 13، 14، 19، 28)

• مائیگریشن رن بک (یہ کتاب)

• تکنیکی پوسٹ مارٹم (باب 28)

• لاگت کے بعد کا تجزیہ (باب 28)

ClearPay API کو ایک AWS EC2 سرور سے GKE میں منتقل کر دیا گیا ہے۔ PostgreSQL جان بوجھ کر ابھی بھی AWS پر ہے۔ صارف نے ٹریفک کو منتقل کرتے ہوئے، رول بیکس کی مشق کرتے ہوئے، اور کٹ اوور کو مکمل کرتے ہوئے ایک پتہ برقرار رکھا۔

مایا نے گاہک سے پوچھا کہ کیا بدلا ہے؟ پتہ ایسا نہیں تھا۔ توازن نہیں تھا۔ بندش کو کسی نے نہیں دیکھا۔ اب آپ سمجھ گئے ہیں کہ یہ مشکل حصہ کیوں ہے، اور 647 ملی سیکنڈ اگلا حصہ کیوں ہے۔

لیب میں بتایا گیا کہ ہر قدم کو کیسے ثابت کیا جائے، شواہد کو کیسے پڑھا جائے، اور خراب تبدیلی کو کیسے ختم کیا جائے۔ کسی بھی چیز کو تباہ کریں جس کی آپ ابھی بھی ادائیگی کر رہے ہیں۔

نئے تکنیکی مضامین، پروجیکٹ واک تھرو، اور مستقبل کی ریلیز کے لیے ہمارے نیوز لیٹر کو سبسکرائب کریں۔

ایک انٹرویو میں اس منصوبے پر بات کرنے کا طریقہ

میں نے کلاؤڈ مائیگریشن پروجیکٹ پر کلیئر پے نامی ادائیگی کی درخواست کے لیے کام کیا۔ ایپلیکیشن AWS پر چل رہی تھی، اور مقصد سروس تک رسائی میں خلل ڈالے بغیر اسے گوگل کلاؤڈ میں منتقل کرنا تھا۔

سب سے بڑا چیلنج محفوظ طریقے سے آگے بڑھنا تھا۔ سب کچھ ایک ساتھ تبدیل کرنے کے بجائے، ہم نے ایک کنٹرول شدہ ہجرت کو ڈیزائن کیا جس نے ہمیں آہستہ آہستہ ٹریفک کو نئے ماحول میں منتقل کرنے کی اجازت دی۔ اگر کچھ غلط ہو جاتا ہے، تو آپ ٹریفک کو واپس اصل سسٹم پر بھیج سکتے ہیں۔ ہم نے نقل مکانی کے دائرہ کار کو کم کرنے اور غیر ضروری خطرات سے بچنے کے لیے ڈیٹا بیس کو AWS پر بھی رکھا۔

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

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

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

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