🥇 کوبرنیٹس #1 میں کینری تعیناتی: گٹلاب سی آئی

ہم Gitlab CI اور دستی GitOps استعمال کریں گے تاکہ Kubernetes میں کینری تعیناتی کو لاگو کریں اور استعمال کریں

اس سیریز کے مضامین:

(اس مضمون)
ArgoCI کا استعمال کرتے ہوئے کینری تعیناتی۔
اسٹیو کا استعمال کرتے ہوئے کینری تعیناتی۔
جینکنز-ایکس اسٹیو فلیگر کا استعمال کرتے ہوئے کینری تعیناتی۔

ہم GitOps کے ذریعے کینری کی تعیناتی کو دستی طور پر انجام دیں گے اور Kubernetes کے اہم وسائل کی تخلیق/ترمیم کریں گے۔ یہ مضمون بنیادی طور پر تعارف کے لیے ہے۔ Kubernetes Canary میں تعیناتی کیسے کام کرتی ہے، کیونکہ آٹومیشن کے زیادہ موثر طریقے ہیں، جن پر ہم اگلے مضامین میں غور کریں گے۔

https://www.norberteder.com/canary-deployment/

کینری تعیناتی۔

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

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 اس طرح لگتا ہے:

image: traherom/kustomize-docker

before_script:
   - printenv
   - kubectl version

stages:
 - deploy

deploy test:
   stage: deploy
   before_script:
     - echo $KUBECONFIG
   script:
     - kubectl get all
     - kubectl apply -f i/k8s

   only:
     - master

اسے خود چلانے کے لیے آپ کو ایک کلسٹر کی ضرورت ہوگی، آپ Gcloud استعمال کر سکتے ہیں:

gcloud container clusters create canary --num-nodes 3 --zone europe-west3-b

gcloud compute firewall-rules create incoming-80 --allow tcp:80

آپ کو کانٹا لگانے کی ضرورت ہے۔ https://gitlab.com/wuestkamp/k8s-deployment-example-canary-infrastructure اور ایک متغیر بنائیں KUBECONFIG GitlabCI میں، جس میں رسائی کے لیے کنفیگریشن ہوگا۔ kubectl آپ کے کلسٹر میں.

آپ کلسٹر (Gcloud) کے لیے اسناد حاصل کرنے کے طریقہ کے بارے میں پڑھ سکتے ہیں یہاں.

انفراسٹرکچر یامل

بنیادی ڈھانچے کے ذخیرے میں ہمارے پاس خدمت ہے:

apiVersion: v1
kind: Service
metadata:
 labels:
   id: app
 name: app
spec:
 ports:
 - port: 80
   protocol: TCP
   targetPort: 5000
 selector:
   id: app
 type: LoadBalancer

اور میں تعیناتی deploy.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
 name: app
spec:
 replicas: 10
 selector:
   matchLabels:
     id: app
     type: main
 template:
   metadata:
     labels:
       id: app
       type: main
   spec:
     containers:
     - image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v1
       name: app
       resources:
         limits:
           cpu: 100m
           memory: 100Mi

اور میں ایک اور تعیناتی۔ deploy-canary.yaml:

kind: Deployment
metadata:
 name: app-canary
spec:
 replicas: 0
 selector:
   matchLabels:
     id: app
     type: canary
 template:
   metadata:
     labels:
       id: app
       type: canary
   spec:
     containers:
     - image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v2
       name: app
       resources:
         limits:
           cpu: 100m
           memory: 100Mi

نوٹ کریں کہ 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 پر سیٹ کیا:

kind: Deployment
metadata:
 name: app-canary
spec:
 replicas: 1
 selector:
   matchLabels:
     id: app
     type: canary
 template:
   metadata:
     labels:
       id: app
       type: canary
   spec:
     containers:
     - image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v2
       name: app
       resources:
         limits:
           cpu: 100m
           memory: 100Mi

فائل میں deploy.yaml ہم نے نقل کی تعداد کو 9 میں تبدیل کر دیا:

kind: Deployment
metadata:
 name: app
spec:
 replicas: 9
 selector:
   matchLabels:
     id: app
...

ہم ان تبدیلیوں کو ذخیرے میں ڈالتے ہیں جہاں سے تعیناتی شروع ہوگی (بذریعہ GitlabCI) اور اس کے نتیجے میں دیکھیں:

ہماری سروس دونوں تعیناتیوں کی طرف اشارہ کرے گی، کیونکہ دونوں کے پاس ایپ سلیکٹر ہے۔ Kubernetes کی ڈیفالٹ رینڈمائزیشن کی وجہ سے، ہمیں ~10% درخواستوں کے لیے مختلف جوابات دیکھنے چاہئیں:

ہماری درخواست کی موجودہ حالت (GitOps، Git سے سچائی کے واحد ماخذ کے طور پر لیا گیا ہے) فعال نقلوں کے ساتھ دو تعیناتیوں کی موجودگی ہے، ہر ورژن کے لیے ایک۔

~10% صارفین نئے ورژن سے واقف ہو جاتے ہیں اور غیر ارادی طور پر اس کی جانچ کرتے ہیں۔ اب وقت آگیا ہے کہ نوشتہ جات میں غلطیوں کی جانچ کی جائے اور مسائل کو تلاش کرنے کے لیے ڈیٹا کی نگرانی کی جائے۔

مرحلہ 2: تمام صارفین کے لیے نیا ورژن جاری کریں۔

ہم نے فیصلہ کیا کہ سب کچھ ٹھیک ہو گیا اور اب ہمیں نئے ورژن کو تمام صارفین کے لیے رول آؤٹ کرنے کی ضرورت ہے۔ ایسا کرنے کے لیے ہم صرف اپ ڈیٹ کرتے ہیں۔ deploy.yaml تصویر کا نیا ورژن انسٹال کرنا اور نقل کی تعداد 10 کے برابر ہے۔ deploy-canary.yaml ہم نے نقل کی تعداد کو واپس 0 پر سیٹ کیا ہے۔ تعیناتی کے بعد، نتیجہ اس طرح ہوگا:

اپ میزانی

میرے لیے، اس طرح دستی طور پر تعیناتی کو چلانے سے یہ سمجھنے میں مدد ملتی ہے کہ k8s کا استعمال کرتے ہوئے اسے کتنی آسانی سے کنفیگر کیا جا سکتا ہے۔ چونکہ Kubernetes آپ کو API کے ذریعے ہر چیز کو اپ ڈیٹ کرنے کی اجازت دیتا ہے، اس لیے ان اقدامات کو اسکرپٹ کے ذریعے خودکار کیا جا سکتا ہے۔

ایک اور چیز جس کو لاگو کرنے کی ضرورت ہے وہ ہے ٹیسٹر انٹری پوائنٹ (لوڈ بیلنسر یا انگریس کے ذریعے) جس کے ذریعے صرف نئے ورژن تک رسائی حاصل کی جاسکتی ہے۔ اسے دستی براؤزنگ کے لیے استعمال کیا جا سکتا ہے۔

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

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

ماخذ: www.habr.com

Kubernetes #1 میں کینری تعیناتی: Gitlab CI