مائیگریشنز جو ناکامی پر ریلیز روک دیں

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

"ناکامی پر بند ہونے" (fail closed) سے میری یہی مراد ہے۔ ناکام مائیگریشن کو ریلیز روک دینی چاہیے، نہ کہ نئے pods کو ایسے اسکیما پر شروع ہونے دینا چاہیے جس کی انہیں توقع نہ ہو۔

مائیگریشن کہاں چلتی ہے

ClickFortify کی NestJS سروسز Prisma کے ذریعے PostgreSQL استعمال کرتی ہیں۔ مائیگریشنز prisma migrate deploy سے لاگو کی جاتی ہیں، جو ہر زیرِ التوا مائیگریشن کو ترتیب سے چلاتی ہے اور اس کے سوا کچھ نہیں بدلتی۔

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

اس کے بجائے، مائیگریشن ایک Kubernetes Job ہے جسے ArgoCD ایک PreSync ہُک کے طور پر چلاتا ہے۔ ArgoCD باقی manifests لاگو کرنے سے پہلے PreSync ہُکس چلاتا ہے۔ اگر ہُک Job ناکام ہو جائے تو sync رک جاتا ہے، اور نئی Deployment کبھی لاگو نہیں ہوتی۔

apiVersion: batch/v1
kind: Job
metadata:
  name: migrate
  annotations:
    argocd.argoproj.io/hook: PreSync
    argocd.argoproj.io/hook-delete-policy: BeforeHookCreation
spec:
  backoffLimit: 0
  activeDeadlineSeconds: 600
  template:
    spec:
      restartPolicy: Never
      containers:
        - name: migrate
          image: registry.example.com/api:sha-abc1234
          command: ['npx', 'prisma', 'migrate', 'deploy']

یہ manifest صرف وضاحت کے لیے ہے، کسی اصل manifest سے نقل نہیں کیا گیا۔

ریلیز والی ہی امیج

یہ Job اسی ریلیز کی بالکل وہی امیج چلاتی ہے جس کی وہ حفاظت کر رہی ہے۔ ڈیپلائے کرنے کا مطلب ہے اس ریپوزیٹری میں نیا امیج ٹیگ کمٹ کرنا جس پر ArgoCD نظر رکھتا ہے، اور وہ ٹیگ api Deployment کے ساتھ ساتھ مائیگریشن Job پر بھی لاگو ہوتا ہے۔ یوں جو مائیگریشنز چلتی ہیں وہ بالکل وہی ہیں جو لائیو ہونے والے کوڈ کے ساتھ بھیجی گئی ہیں۔ مائیگریشنز کی کوئی الگ امیج نہیں جو کوڈ سے بے ربط ہو سکے۔

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

اندھا دھند ری ٹرائی نہیں

backoffLimit: 0 جان بوجھ کر رکھا گیا ہے۔ Kubernetes ناکام Job کو بخوشی دوبارہ چلا دیتا، لیکن جو مائیگریشن درمیان میں ناکام ہوئی ہو وہ اسکیما کو آدھا لاگو شدہ چھوڑ سکتی ہے۔ دیکھے بغیر اسے دوبارہ چلانا صورتحال کو مزید بگاڑ سکتا ہے۔ ایک کوشش، پھر رک جائیں اور کسی انسان کو لاگز پڑھنے دیں۔

activeDeadlineSeconds یہ حد مقرر کرتا ہے کہ Job کتنی دیر تک اٹکی رہ سکتی ہے، مثلاً کسی لاک پر، اس سے پہلے کہ اسے ناکام شمار کیا جائے۔

لاگز جو محفوظ رہیں

ہُک کی ڈیلیٹ پالیسی BeforeHookCreation ہے۔ ArgoCD پرانی Job کو صرف تب حذف کرتا ہے جب وہ اگلی Job بنانے والا ہو۔ تب تک ناکام Job اور اس کے pod لاگز کلسٹر میں موجود رہتے ہیں، اور یہی وہ وقت ہے جب آپ کو ان کی ضرورت ہوتی ہے۔ ناکامی پر ہُک کو حذف کرنے والی پالیسی ثبوت کو ضائع کر دیتی۔

ان لاگز میں ایک کامیاب رن کو پہچاننا آسان ہے: Prisma ملنے والی مائیگریشنز بتاتا ہے، پھر یا تو لاگو کی گئی مائیگریشنز کی فہرست یا یہ کہ کوئی مائیگریشن زیرِ التوا نہیں تھی، اور Job مکمل ہو جاتی ہے۔

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

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

PreSync ہُک یہ ترتیب بغیر کسی اضافی محنت کے فراہم کرتا ہے۔

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

1. مائیگریشنز کو ایپلیکیشن اسٹارٹ اپ پر نہیں، بلکہ ڈیپلائے سے پہلے والے ایسے ہُک کے طور پر چلائیں جو ریلیز کو روک سکے۔
2. مائیگریشن Job کو ریلیز والے ہی امیج ٹیگ سے بنائیں، تاکہ کوڈ اور اسکیما ایک دوسرے سے بے ربط نہ ہو سکیں۔
3. backoffLimit: 0 مقرر کریں اور ناکام Job کے لاگز محفوظ رکھیں؛ آدھے لاگو شدہ اسکیما کو ری ٹرائی کی نہیں، کسی انسان کی ضرورت ہوتی ہے۔
4. صرف sync کے ذریعے ڈیپلائے کریں، کیونکہ ری اسٹارٹ ہُکس کو نظر انداز کر دیتا ہے۔