🥇 Kubernetes کلسٹر میں ایک فرسودہ فیچر برانچ کو ہٹانا

ہیلو! فیچر برانچ (aka deploy preview, review app) - یہ تب ہوتا ہے جب نہ صرف ماسٹر برانچ کو تعینات کیا جاتا ہے، بلکہ ہر پل کی درخواست کو ایک منفرد URL پر بھیجا جاتا ہے۔ آپ چیک کر سکتے ہیں کہ آیا کوڈ پیداواری ماحول میں کام کرتا ہے؛ فیچر دوسرے پروگرامرز یا پروڈکٹ کے ماہرین کو دکھایا جا سکتا ہے۔ جب آپ پل کی درخواست میں کام کر رہے ہوتے ہیں، تو پرانے کوڈ کے لیے ہر نئی کمٹ موجودہ تعیناتی کو حذف کر دیا جاتا ہے، اور نئے کوڈ کے لیے نئی تعیناتی کو رول آؤٹ کر دیا جاتا ہے۔ جب آپ ماسٹر برانچ میں پل کی درخواست کو ضم کرتے ہیں تو سوالات پیدا ہوسکتے ہیں۔ اب آپ کو فیچر برانچ کی ضرورت نہیں ہے، لیکن Kubernetes وسائل اب بھی کلسٹر میں ہیں۔

خصوصیت کی شاخوں کے بارے میں مزید

Kubernetes میں فیچر برانچز بنانے کا ایک طریقہ نام کی جگہوں کا استعمال کرنا ہے۔ مختصر میں، پیداوار کی ترتیب اس طرح لگتی ہے:

kind: Namespace
apiVersion: v1
metadata:
  name: habr-back-end
...

kind: Deployment
apiVersion: apps/v1
metadata:
  namespace: habr-back-end
spec:
  replicas: 3
...

فیچر برانچ کے لیے، نام کی جگہ اس کے شناخت کنندہ (مثال کے طور پر پل ریکوئسٹ نمبر) اور کسی قسم کا سابقہ/پوسٹ فکس (مثال کے طور پر، -پی آر-):

kind: Namespace
apiVersion: v1
metadata:
  name: habr-back-end-pr-17
...

kind: Deployment
apiVersion: apps/v1
metadata:
  namespace: habr-back-end-pr-17
spec:
  replicas: 1
...

عام طور پر، میں نے لکھا Kubernetes آپریٹر (ایک ایسی ایپلی کیشن جسے کلسٹر وسائل تک رسائی حاصل ہے) Github پر پروجیکٹ کا لنک. یہ نام کی جگہوں کو ہٹاتا ہے جو پرانی خصوصیت کی شاخوں سے تعلق رکھتے ہیں۔ Kubernetes میں، اگر آپ نام کی جگہ کو حذف کرتے ہیں، تو اس نام کی جگہ کے دیگر وسائل بھی خود بخود حذف ہو جاتے ہیں۔

$ kubectl get pods --all-namespaces | grep -e "-pr-"
NAMESPACE            ... AGE
habr-back-end-pr-264 ... 4d8h
habr-back-end-pr-265 ... 5d7h

آپ اس بارے میں پڑھ سکتے ہیں کہ فیچر برانچز کو کلسٹر میں کیسے لاگو کیا جائے۔ یہاں и یہاں.

پریرتا

آئیے مسلسل انضمام کے ساتھ ایک عام پل درخواست لائف سائیکل کو دیکھیں (continuous integration):

ہم برانچ میں ایک نیا عہد کرتے ہیں۔
تعمیر پر، لنٹر اور/یا ٹیسٹ چلائے جاتے ہیں۔
Kubernetes پل کی درخواست کی ترتیب فلائی پر تیار کی جاتی ہے (مثال کے طور پر، اس کا نمبر تیار ٹیمپلیٹ میں داخل کیا جاتا ہے)۔
kubectl apply کا استعمال کرتے ہوئے، کنفیگریشنز کو کلسٹر (تعینات) میں شامل کیا جاتا ہے۔
پل کی درخواست کو ماسٹر برانچ میں ضم کر دیا گیا ہے۔

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

استعمال کرنے کے لئے کس طرح

ذیل میں کمانڈ کے ساتھ پروجیکٹ کو انسٹال کریں:

$ kubectl apply -f https://raw.githubusercontent.com/dmytrostriletskyi/stale-feature-branch-operator/master/configs/production.yml

درج ذیل مواد کے ساتھ ایک فائل بنائیں اور اس کے ذریعے انسٹال کریں۔ kubectl apply -f:

apiVersion: feature-branch.dmytrostriletskyi.com/v1
kind: StaleFeatureBranch
metadata:
  name: stale-feature-branch
spec:
  namespaceSubstring: -pr-
  afterDaysWithoutDeploy: 3

پیرامیٹر namespace سبسٹرنگ دیگر نام کی جگہوں سے پل کی درخواستوں کے لیے نام کی جگہوں کو فلٹر کرنے کی ضرورت ہے۔ مثال کے طور پر، اگر کلسٹر میں درج ذیل نام کی جگہیں ہیں: habr-back-end, habr-front-end, habr-back-end-pr-17, habr-back-end-pr-33، پھر حذف کرنے کے امیدوار ہوں گے۔ habr-back-end-pr-17, habr-back-end-pr-33.

پیرامیٹر afterDaysWithoutDeploy پرانے نام کی جگہوں کو حذف کرنے کی ضرورت ہے۔ مثال کے طور پر، اگر نام کی جگہ بنائی گئی ہے۔ 3 дня 1 час واپس، اور پیرامیٹر اشارہ کرتا ہے۔ 3 дня، یہ نام کی جگہ کو حذف کر دیا جائے گا۔ اگر نام کی جگہ بنائی جائے تو یہ مخالف سمت میں بھی کام کرتا ہے۔ 2 дня 23 часа واپس، اور پیرامیٹر اشارہ کرتا ہے۔ 3 дня، یہ نام کی جگہ کو حذف نہیں کیا جائے گا۔

ایک اور پیرامیٹر ہے، یہ ذمہ دار ہے کہ تمام نام کی جگہوں کو کتنی بار اسکین کرنا ہے اور بغیر تعیناتی کے دنوں کے لیے چیک کرنا ہے۔ ہر منٹ چیک کریں۔. پہلے سے طے شدہ طور پر یہ برابر ہے۔ 30 минутам.

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

عملی طور پر، آپ کو ضرورت ہو گی:

میں Docker الگ تھلگ ماحول میں کام کرنے کے لیے۔
منیکوب مقامی طور پر ایک Kubernetes کلسٹر اٹھائے گا۔
کیوبیکٹل - کلسٹر مینجمنٹ کے لیے کمانڈ لائن انٹرفیس۔

ہم مقامی طور پر ایک Kubernetes کلسٹر بڑھاتے ہیں:

$ minikube start --vm-driver=docker
minikube v1.11.0 on Darwin 10.15.5
Using the docker driver based on existing profile.
Starting control plane node minikube in cluster minikube.

اشارہ کرنا kubectl مقامی کلسٹر بطور ڈیفالٹ استعمال کریں:

$ kubectl config use-context minikube
Switched to context "minikube".

پیداواری ماحول کے لیے کنفیگریشن ڈاؤن لوڈ کریں:

$ curl https://raw.githubusercontent.com/dmytrostriletskyi/stale-feature-branch-operator/master/configs/production.yml > stale-feature-branch-production-configs.yml

چونکہ پروڈکشن کنفیگریشنز کو پرانی نام کی جگہوں کو چیک کرنے کے لیے ترتیب دیا گیا ہے، اور ہمارے نئے اٹھائے گئے کلسٹر میں وہ نہیں ہیں، اس لیے ہم ماحولیاتی متغیر کو بدل دیں گے۔ IS_DEBUG پر true. اس قدر کے ساتھ پیرامیٹر afterDaysWithoutDeploy اکاؤنٹ میں نہیں لیا جاتا ہے اور نام کی جگہوں کو بغیر تعیناتی کے دنوں تک چیک نہیں کیا جاتا ہے، صرف سبسٹرنگ کی موجودگی کے لیے (-pr-).

اگر آپ پر ہیں Linux:

$ sed -i 's|false|true|g' stale-feature-branch-production-configs.yml

اگر آپ پر ہیں macOS:

$ sed -i "" 's|false|true|g' stale-feature-branch-production-configs.yml

پروجیکٹ کی تنصیب:

$ kubectl apply -f stale-feature-branch-production-configs.yml

چیک کر رہا ہے کہ کلسٹر میں ایک وسیلہ ظاہر ہوا ہے۔ StaleFeatureBranch:

$ kubectl api-resources | grep stalefeaturebranches
NAME                 ... APIGROUP                             ... KIND
stalefeaturebranches ... feature-branch.dmytrostriletskyi.com ... StaleFeatureBranch

ہم چیک کرتے ہیں کہ ایک آپریٹر کلسٹر میں ظاہر ہوا ہے:

$ kubectl get pods --namespace stale-feature-branch-operator
NAME                                           ... STATUS  ... AGE
stale-feature-branch-operator-6bfbfd4df8-m7sch ... Running ... 38s

اگر آپ اس کے نوشتہ جات کو دیکھیں تو یہ وسائل پر کارروائی کے لیے تیار ہے۔ StaleFeatureBranch:

$ kubectl logs stale-feature-branch-operator-6bfbfd4df8-m7sch -n stale-feature-branch-operator
... "msg":"Operator Version: 0.0.1"}
...
... "msg":"Starting EventSource", ... , "source":"kind source: /, Kind="}
... "msg":"Starting Controller", ...}
... "msg":"Starting workers", ..., "worker count":1}

ہم ریڈی میڈ انسٹال کرتے ہیں۔ fixtures (ماڈلنگ کلسٹر وسائل کے لیے تیار کنفیگریشنز) وسائل کے لیے StaleFeatureBranch:

$ kubectl apply -f https://raw.githubusercontent.com/dmytrostriletskyi/stale-feature-branch-operator/master/fixtures/stale-feature-branch.yml

کنفیگریشنز ذیلی اسٹرنگ کے ساتھ نام کی جگہوں کو تلاش کرنے کی نشاندہی کرتی ہیں۔ -pr- ہر ایک بار 1 минуту.:

apiVersion: feature-branch.dmytrostriletskyi.com/v1
kind: StaleFeatureBranch
metadata:
  name: stale-feature-branch
spec:
  namespaceSubstring: -pr-
  afterDaysWithoutDeploy: 1 
  checkEveryMinutes: 1

آپریٹر نے جواب دیا ہے اور نام کی جگہوں کو چیک کرنے کے لیے تیار ہے:

$ kubectl logs stale-feature-branch-operator-6bfbfd4df8-m7sch -n stale-feature-branch-operator
... "msg":"Stale feature branch is being processing.","namespaceSubstring":"-pr-","afterDaysWithoutDeploy":1,"checkEveryMinutes":1,"isDebug":"true"}

انسٹال کریں۔ fixturesدو نام کی جگہوں پر مشتمل (project-pr-1, project-pr-2) اور انہیں deployments, services, ingress، اور اسی طرح:

$ kubectl apply -f https://raw.githubusercontent.com/dmytrostriletskyi/stale-feature-branch-operator/master/fixtures/first-feature-branch.yml -f https://raw.githubusercontent.com/dmytrostriletskyi/stale-feature-branch-operator/master/fixtures/second-feature-branch.yml
...
namespace/project-pr-1 created
deployment.apps/project-pr-1 created
service/project-pr-1 created
horizontalpodautoscaler.autoscaling/project-pr-1 created
secret/project-pr-1 created
configmap/project-pr-1 created
ingress.extensions/project-pr-1 created
namespace/project-pr-2 created
deployment.apps/project-pr-2 created
service/project-pr-2 created
horizontalpodautoscaler.autoscaling/project-pr-2 created
secret/project-pr-2 created
configmap/project-pr-2 created
ingress.extensions/project-pr-2 created

ہم چیک کرتے ہیں کہ مذکورہ بالا تمام وسائل کامیابی کے ساتھ بنائے گئے ہیں:

$ kubectl get namespace,pods,deployment,service,horizontalpodautoscaler,configmap,ingress -n project-pr-1 && kubectl get namespace,pods,deployment,service,horizontalpodautoscaler,configmap,ingress -n project-pr-2
...
NAME                              ... READY ... STATUS  ... AGE
pod/project-pr-1-848d5fdff6-rpmzw ... 1/1   ... Running ... 67s

NAME                         ... READY ... AVAILABLE ... AGE
deployment.apps/project-pr-1 ... 1/1   ... 1         ... 67s
...

چونکہ ہم نے شامل کیا۔ debugنام کی جگہیں project-pr-1 и project-pr-2لہذا دیگر تمام وسائل کو پیرامیٹر کو مدنظر رکھے بغیر فوری طور پر حذف کرنا ہوگا۔ afterDaysWithoutDeploy. یہ آپریٹر لاگز میں دیکھا جا سکتا ہے:

$ kubectl logs stale-feature-branch-operator-6bfbfd4df8-m7sch -n stale-feature-branch-operator
... "msg":"Namespace should be deleted due to debug mode is enabled.","namespaceName":"project-pr-1"}
... "msg":"Namespace is being processing.","namespaceName":"project-pr-1","namespaceCreationTimestamp":"2020-06-16 18:43:58 +0300 EEST"}
... "msg":"Namespace has been deleted.","namespaceName":"project-pr-1"}
... "msg":"Namespace should be deleted due to debug mode is enabled.","namespaceName":"project-pr-2"}
... "msg":"Namespace is being processing.","namespaceName":"project-pr-2","namespaceCreationTimestamp":"2020-06-16 18:43:58 +0300 EEST"}
... "msg":"Namespace has been deleted.","namespaceName":"project-pr-2"}

اگر آپ وسائل کی دستیابی کو چیک کریں تو وہ حالت میں ہوں گے۔ Terminating (حذف کرنے کا عمل) یا پہلے ہی حذف شدہ (کمانڈ آؤٹ پٹ خالی ہے)۔

$ kubectl get namespace,pods,deployment,service,horizontalpodautoscaler,configmap,ingress -n project-pr-1 && kubectl get namespace,pods,deployment,service,horizontalpodautoscaler,configmap,ingress -n project-pr-2
...

آپ تخلیق کے عمل کو دہرا سکتے ہیں۔ fixtures کئی بار اور یقینی بنائیں کہ وہ ایک منٹ میں ہٹا دیے گئے ہیں۔

متبادل

کلسٹر میں کام کرنے والے آپریٹر کے بجائے کیا کیا جا سکتا ہے؟ بہت سے نقطہ نظر ہیں، ان میں سے سبھی نامکمل ہیں (اور ان کی کوتاہیاں موضوعی ہیں)، اور ہر کوئی خود فیصلہ کرتا ہے کہ کسی خاص پروجیکٹ کے لیے کیا بہتر ہے:

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

مضمون پر آپ کی توجہ کا شکریہ۔ Github پر پروجیکٹ سے لنک کریں۔.

ماخذ: www.habr.com

Kubernetes کلسٹر میں فرسودہ فیچر برانچ کو ہٹانا

خصوصیت کی شاخوں کے بارے میں مزید

پریرتا

استعمال کرنے کے لئے کس طرح

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

متبادل

نیا تبصرہ شامل کریں جواب منسوخ کریں