ایک ہی قدم میں Kubernetes پر منتقلی

ClickFortify کا آغاز ایک واحد VM پر docker-compose چلاتے ہوئے ہوا۔ اب یہ GCP پر Kubernetes پر چلتا ہے اور ArgoCD کے ذریعے ڈیپلائے ہوتا ہے۔ یہ تحریر ان دونوں کے درمیان منتقلی کے بارے میں ہے، اور اس بارے میں کہ میں نے اسے بتدریج منتقلی کے بجائے ایک ہی قدم میں کیوں کیا۔

پروڈکٹ رک نہیں سکتی

ClickFortify لائیو ٹریفک پر اشتہاری کلکس جمع کرتا ہے، انہیں اسکور کرتا ہے، اور اخراج کو Google Ads اور Meta میں واپس لکھتا ہے۔ کلکس دن رات آتے رہتے ہیں۔ ایسا منتقلی کا منصوبہ جسے مینٹیننس ونڈو درکار ہو، یا جو ٹریکر کو آدھا ایک اسٹیک پر اور آدھا دوسرے پر چھوڑ دے، حقیقی مشتہرین کا حقیقی بجٹ ضائع کرتا ہے۔

اس لیے سوال یہ نہیں تھا کہ "ہم سب کچھ کیسے منتقل کریں؟" سوال یہ تھا کہ "ہم اس تبدیلی کو ایک واحد، چھوٹا اور قابلِ واپسی قدم کیسے بنائیں؟"

پہلے ڈیپلائے کا راستہ درست کریں

کسی بھی ٹریفک کی منتقلی سے پہلے، کلسٹر کو ڈیپلائے کے ایسے راستے کی ضرورت تھی جس پر مجھے بھروسہ ہو۔ GitOps سیٹ اپ تین ریپوزیٹریز استعمال کرتا ہے: ایپلیکیشن، وہ manifests جنہیں ArgoCD ڈیپلائے کرتا ہے، اور پلیٹ فارم انفراسٹرکچر۔ اصل منصوبے میں manifests ایپلیکیشن کی monorepo کے اندر رکھے گئے تھے۔ میں نے انہیں الگ کیا کیونکہ ArgoCD ہر ریفریش پر ریپوزیٹری کو دوبارہ کلون کرتا ہے اور monorepo بڑی ہے، کیونکہ پلیٹ فارم کا اپنا لائف سائیکل اور اپنے ریویورز ہیں، اور کیونکہ اس صورت میں ایپ کی CI کو پلیٹ فارم ریپوزیٹری تک کوئی رسائی حاصل نہیں رہتی۔

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

اسٹیج ہوسٹ نیمز کا ایک متوازی سیٹ

جس منصوبے پر میں نے اتفاق کیا اس کے تین مراحل تھے:

1. پورے نئے اسٹیک کو کلسٹر پر اسٹیج ہوسٹ نیمز کے ایک متوازی سیٹ کے پیچھے ڈیپلائے کرنا، جیسے stage.example.com۔
2. وہیں اس کی تصدیق کرنا۔
3. ایک ہی قدم میں پروڈکشن ہوسٹ نیمز کا رخ کلسٹر کی طرف موڑ دینا۔

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

ڈیٹا کی منتقلی نہیں، اور اس کے ساتھ آنے والی شرط

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

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

ورکر صفر پر کیوں رہا

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

# Illustrative: keep the new side's worker off until the flip
kubectl scale deployment worker --replicas=0

تبدیلی، اور اس کے برقرار رہنے کی جانچ

تبدیلی بذاتِ خود ایک DNS تبدیلی تھی: پروڈکشن ہوسٹ نیمز کا رخ کلسٹر کی طرف کر دیا گیا۔ اس سے پہلے میں نے جانچا کہ کلسٹر پر چلنے والی امیج digests وہی ہیں جن کے بھیجے جانے کی مجھے توقع تھی۔

اس کے بعد سب سے اہم جانچ ٹریکر پر تھی۔ یہ ایک CDN اور ایک reverse proxy کے پیچھے ہے، اور اس کے پیچھے وزیٹر کا اصل IP معلوم کرنا بالکل اسی قسم کی چیز ہے جو ٹوپولوجی بدلنے پر ٹوٹ جاتی ہے۔ تبدیلی کے بعد ٹریکر کی لائیو ٹریفک میں وزیٹرز کے اصل IPs نظر آئے اور CDN کے edge ایڈریسز نہیں۔ جب یہ برقرار رہا تو اسٹیج ہوسٹ نیمز ہٹا دیے گئے۔

تبدیلی کے فوراً بعد، واپسی کا طریقہ یہی قدم الٹا اٹھانا تھا: ہوسٹ نیمز کا رخ واپس پرانی VM کی طرف کرنا، جسے میں نے حذف کرنے کے بجائے صرف بند کیا تھا۔

یہی منتقلی کرنے والے کو میرا مشورہ

1. اگر دونوں سائیڈز ڈیٹا بیسز شیئر کر سکتی ہیں تو ایسا ہی کریں۔ یہ ڈیٹا کی منتقلی کو ختم کر دیتا ہے اور کٹ اوور کو ایک DNS تبدیلی بنا دیتا ہے۔
2. ہر شیڈول شدہ جاب کی فہرست بنائیں اور یقینی بنائیں کہ اسٹیجنگ کے دوران وہ بالکل ایک ہی جگہ چلے، چاہے اس کا مطلب یہ ہو کہ کسی سروس کی ریہرسل نہ ہو سکے۔
3. تبدیلی سے پہلے قطار میں موجود اور مؤخر جابز کو خالی کریں یا ایکسپورٹ کریں۔ وہ ڈیٹا بیس سے باہر رہتی ہیں۔
4. تصدیق کی جانچ تبدیلی سے پہلے طے کریں، اور اسے health endpoints کے بجائے حقیقی ٹریفک پر مبنی رکھیں۔