ہیلم کا استعمال کرتے ہوئے کینری تعیناتیوں کو خودکار کرنے کا ایک آسان اور محفوظ طریقہ

کینری تعیناتی صارفین کے سب سیٹ پر نئے کوڈ کی جانچ کرنے کا ایک بہت مؤثر طریقہ ہے۔ یہ ٹریفک کے بوجھ کو نمایاں طور پر کم کرتا ہے جو تعیناتی کے عمل کے دوران مشکل ہو سکتا ہے، کیونکہ یہ صرف ایک مخصوص ذیلی سیٹ کے اندر ہوتا ہے۔ یہ نوٹ Kubernetes اور تعیناتی آٹومیشن کا استعمال کرتے ہوئے اس طرح کی تعیناتی کو کیسے منظم کیا جائے اس کے لیے وقف ہے۔ ہم فرض کرتے ہیں کہ آپ Helm اور Kubernetes وسائل کے بارے میں کچھ جانتے ہیں۔.



Kubernetes پر ایک سادہ کینری تعیناتی میں دو اہم وسائل شامل ہیں: خود سروس اور تعیناتی کا آلہ۔ کینری تعیناتی ایک واحد سروس کے ذریعے کام کرتی ہے جو ٹریفک کو اپ ڈیٹ کرنے والے دو مختلف وسائل کے ساتھ تعامل کرتی ہے۔ ان وسائل میں سے ایک "کینری" ورژن کے ساتھ کام کرے گا، اور دوسرا مستحکم ورژن کے ساتھ کام کرے گا۔ اس صورت حال میں، سروس کے لیے درکار ٹریفک کی مقدار کو کم کرنے کے لیے ہم کینری ورژنز کی تعداد کو ریگولیٹ کر سکتے ہیں۔ اگر، مثال کے طور پر، آپ Yaml استعمال کرنے کو ترجیح دیتے ہیں، تو یہ Kubernetes میں اس طرح نظر آئے گا:

kind: Deployment
metadata:
  name: app-canary
  labels:
    app: app
spec:
  replicas: 1
  ...
    image: myapp:canary
---
kind: Deployment
metadata:
  name: app
  labels:
    app: app
spec:
  replicas: 5
  ...
    image: myapp:stable
---
kind: Service
selector:
  app: app # Selector will route traffic to both deployments.

kubectl اور in کا ​​استعمال کرتے ہوئے اس اختیار کا تصور کرنا اور بھی آسان ہے۔ Kubernetes دستاویزات یہاں تک کہ اس منظر نامے پر ایک مکمل ٹیوٹوریل موجود ہے۔ لیکن اس پوسٹ کا بنیادی سوال یہ ہے کہ ہم ہیلم کا استعمال کرتے ہوئے اس عمل کو خودکار کیسے کریں گے۔

کینری تعیناتی کا آٹومیشن

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

~/charts/app
├── Chart.yaml
├── README.md
├── templates
│   ├── NOTES.txt
│   ├── _helpers.tpl
│   ├── deployment.yaml
│   └── service.yaml
└── values.yaml

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

selector:
  app.kubernetes.io/name: myapp

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

helm upgrade
  --install myapp 
  --namespace default 
  --set app.name=myapp       # Goes into app.kubernetes.io/name
  --set app.version=v1       # Goes into app.kubernetes.io/version
  --set image.tag=stable 
  --set replicaCount=5

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

helm upgrade
  --install myapp-canary 
  --namespace default 
  --set app.name=myapp       # Goes into app.kubernetes.io/name
  --set app.version=v2       # Goes into app.kubernetes.io/version
  --set image.tag=canary 
  --set replicaCount=1

بس! اگر آپ سروس کو پنگ کرتے ہیں، تو آپ دیکھ سکتے ہیں کہ کینری اپ ڈیٹ ٹریفک کو صرف وقت کا حصہ بناتی ہے۔

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

ماخذ: www.habr.com