جینکنز-ایکس اسٹیو فلیگر کا استعمال کرتے ہوئے کینری تعیناتی۔
ہم GitOps کے ذریعے کینری کی تعیناتی کو دستی طور پر انجام دیں گے اور Kubernetes کے اہم وسائل کی تخلیق/ترمیم کریں گے۔ یہ مضمون بنیادی طور پر تعارف کے لیے ہے۔ Kubernetes Canary میں تعیناتی کیسے کام کرتی ہے، کیونکہ آٹومیشن کے زیادہ موثر طریقے ہیں، جن پر ہم اگلے مضامین میں غور کریں گے۔
کینری حکمت عملی کے ساتھ، اپ ڈیٹس کا اطلاق پہلے صارفین کے صرف ذیلی سیٹ پر ہوتا ہے۔ نگرانی، لاگ ڈیٹا، دستی جانچ، یا دیگر فیڈ بیک چینلز کے ذریعے، ریلیز کو تمام صارفین کے لیے جاری کیے جانے سے پہلے ٹیسٹ کیا جاتا ہے۔
Kubernetes تعیناتی (رولنگ اپ ڈیٹ)
Kubernetes کی تعیناتی کے لیے پہلے سے طے شدہ حکمت عملی رولنگ اپ ڈیٹ ہے، جہاں تصویروں کے نئے ورژن کے ساتھ ایک خاص تعداد میں پوڈ لانچ کیے جاتے ہیں۔ اگر وہ بغیر کسی پریشانی کے بنائے گئے تھے تو، تصویروں کے پرانے ورژن والے پوڈز کو ختم کر دیا جاتا ہے، اور متوازی طور پر نئے پوڈ بنائے جاتے ہیں۔
GitOps
ہم اس مثال میں GitOps استعمال کرتے ہیں کیونکہ ہم:
گٹ کو سچائی کے واحد ذریعہ کے طور پر استعمال کرنا
ہم تعمیر اور تعیناتی کے لیے گٹ آپریشنز کا استعمال کرتے ہیں (گٹ ٹیگ/مرج کے علاوہ کسی کمانڈ کی ضرورت نہیں ہے)
مثال کے طور پر
آئیے ایک اچھی مشق کریں - درخواست کوڈ کے لیے ایک ذخیرہ اور ایک انفراسٹرکچر کے لیے۔
درخواست کا ذخیرہ
یہ ایک بہت ہی آسان Python+Flask API ہے جو JSON کے بطور جواب دیتا ہے۔ ہم GitlabCI کے ذریعے پیکج بنائیں گے اور نتیجہ کو Gitlab رجسٹری میں بھیجیں گے۔ رجسٹری میں ہمارے پاس دو مختلف ریلیز ورژن ہیں:
wuestkamp/k8s-deployment-example-app:v1
wuestkamp/k8s-deployment-example-app:v2
ان کے درمیان فرق صرف واپسی JSON فائل میں تبدیلی ہے۔ ہم اس ایپلی کیشن کو آسانی سے تصور کرنے کے لیے استعمال کرتے ہیں کہ ہم کس ورژن سے بات کر رہے ہیں۔
انفراسٹرکچر ذخیرہ
اس شلجم میں ہم GitlabCI کے ذریعے Kubernetes تک تعینات کریں گے، .gitlab-ci.yml اس طرح لگتا ہے:
نوٹ کریں کہ app-deploy میں ابھی تک کوئی نقل بیان نہیں کی گئی ہے۔
ابتدائی تعیناتی انجام دے رہا ہے۔
ابتدائی تعیناتی شروع کرنے کے لیے، آپ GitlabCI پائپ لائن کو ماسٹر برانچ پر دستی طور پر شروع کر سکتے ہیں۔ اس کے بعد kubectl مندرجہ ذیل کو آؤٹ پٹ کرنا چاہئے:
ہم دیکھیں app 10 نقلوں کے ساتھ تعیناتی اور 0 کے ساتھ ایپ کینری۔ ایک لوڈ بیلنسر بھی ہے جس سے ہم رسائی حاصل کر سکتے ہیں۔ curl بیرونی IP کے ذریعے:
while true; do curl -s 35.198.149.232 | grep label; sleep 0.1; done
ہم دیکھتے ہیں کہ ہماری ٹیسٹ ایپلی کیشن صرف "v1" واپس کرتی ہے۔
کینری تعیناتی کو انجام دینا
مرحلہ 1: کچھ صارفین کے لیے ایک نیا ورژن جاری کریں۔
ہم نے deploy-canary.yaml فائل اور نئے ورژن کی تصویر میں نقل کی تعداد کو 1 پر سیٹ کیا:
ہم ان تبدیلیوں کو ذخیرے میں ڈالتے ہیں جہاں سے تعیناتی شروع ہوگی (بذریعہ GitlabCI) اور اس کے نتیجے میں دیکھیں:
ہماری سروس دونوں تعیناتیوں کی طرف اشارہ کرے گی، کیونکہ دونوں کے پاس ایپ سلیکٹر ہے۔ Kubernetes کی ڈیفالٹ رینڈمائزیشن کی وجہ سے، ہمیں ~10% درخواستوں کے لیے مختلف جوابات دیکھنے چاہئیں:
ہماری درخواست کی موجودہ حالت (GitOps، Git سے سچائی کے واحد ماخذ کے طور پر لیا گیا ہے) فعال نقلوں کے ساتھ دو تعیناتیوں کی موجودگی ہے، ہر ورژن کے لیے ایک۔
~10% صارفین نئے ورژن سے واقف ہو جاتے ہیں اور غیر ارادی طور پر اس کی جانچ کرتے ہیں۔ اب وقت آگیا ہے کہ نوشتہ جات میں غلطیوں کی جانچ کی جائے اور مسائل کو تلاش کرنے کے لیے ڈیٹا کی نگرانی کی جائے۔
مرحلہ 2: تمام صارفین کے لیے نیا ورژن جاری کریں۔
ہم نے فیصلہ کیا کہ سب کچھ ٹھیک ہو گیا اور اب ہمیں نئے ورژن کو تمام صارفین کے لیے رول آؤٹ کرنے کی ضرورت ہے۔ ایسا کرنے کے لیے ہم صرف اپ ڈیٹ کرتے ہیں۔ deploy.yaml تصویر کا نیا ورژن انسٹال کرنا اور نقل کی تعداد 10 کے برابر ہے۔ deploy-canary.yaml ہم نے نقل کی تعداد کو واپس 0 پر سیٹ کیا ہے۔ تعیناتی کے بعد، نتیجہ اس طرح ہوگا:
اپ میزانی
میرے لیے، اس طرح دستی طور پر تعیناتی کو چلانے سے یہ سمجھنے میں مدد ملتی ہے کہ k8s کا استعمال کرتے ہوئے اسے کتنی آسانی سے کنفیگر کیا جا سکتا ہے۔ چونکہ Kubernetes آپ کو API کے ذریعے ہر چیز کو اپ ڈیٹ کرنے کی اجازت دیتا ہے، اس لیے ان اقدامات کو اسکرپٹ کے ذریعے خودکار کیا جا سکتا ہے۔
ایک اور چیز جس کو لاگو کرنے کی ضرورت ہے وہ ہے ٹیسٹر انٹری پوائنٹ (لوڈ بیلنسر یا انگریس کے ذریعے) جس کے ذریعے صرف نئے ورژن تک رسائی حاصل کی جاسکتی ہے۔ اسے دستی براؤزنگ کے لیے استعمال کیا جا سکتا ہے۔
مستقبل کے مضامین میں، ہم دوسرے خودکار حلوں کو دیکھیں گے جو ہم نے جو کچھ کیا ہے اس پر عمل درآمد کرتے ہیں۔