پرو هوسٽر > بلاگ > انتظاميه > Kubernetes ڪلستر ۾ هڪ پراڻي خصوصيت شاخ کي هٽائڻ

Kubernetes ڪلستر ۾ هڪ پراڻي خصوصيت شاخ کي هٽائڻ

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
...

عام طور تي، مون لکيو ڪبرنيٽس آپريٽر (هڪ ايپليڪيشن جيڪا ڪلسٽر وسيلن تائين رسائي آهي) 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):

  1. اسان برانچ ڏانهن هڪ نئين عزم کي ڌڪايو.
  2. تعمير تي، لينٽر ۽ / يا ٽيسٽ هلائي رهيا آهن.
  3. Kubernetes پل جي درخواست جي ترتيب کي اڏام تي ٺاهيا ويا آهن (مثال طور، ان جو نمبر مڪمل ٿيل ٽيمپليٽ ۾ داخل ڪيو ويو آهي).
  4. kubectl لاڳو ڪرڻ سان، ترتيبن کي ڪلستر ۾ شامل ڪيو ويو آھي (تعمير).
  5. پل جي درخواست ماسٽر برانچ ۾ ملائي وئي آهي.

جڏهن توهان هڪ پل جي درخواست ۾ ڪم ڪري رهيا آهيو، هر نئين وابستگي جي موجوده مقرري کي پراڻي ڪوڊ لاء ختم ڪيو ويو آهي، ۽ نئين ڪوڊ لاء نئين ترتيب کي ختم ڪيو ويو آهي. پر جڏهن هڪ پل جي درخواست ماسٽر برانچ ۾ ملائي ويندي آهي، صرف ماسٽر برانچ ٺاهي ويندي. نتيجي طور، اهو ظاهر ٿئي ٿو ته اسان اڳ ۾ ئي پل جي درخواست بابت وساري چڪا آهيون، ۽ ان جي ڪبرنيٽس وسيلن اڃا تائين ڪلستر ۾ آهن.

ڪيئن استعمال ڪجي

هيٺ ڏنل حڪم سان منصوبي کي انسٽال ڪريو:

$ 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

نيم namespaceSubstring ٻين نالن جي جڳهن مان پلڻ جي درخواستن لاءِ نالا اسپيس کي فلٽر ڪرڻ جي ضرورت آهي. مثال طور، جيڪڏهن ڪلستر ۾ هيٺيان نالا آهن: 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 پراڻي namespace کي ختم ڪرڻ جي ضرورت آهي. مثال طور، جيڪڏهن namespace ٺاهي وئي آهي 3 дня 1 час واپس، ۽ پيٽرولر اشارو ڪري ٿو 3 дня, هن namespace کي ختم ڪيو ويندو. اهو پڻ ڪم ڪري ٿو سامهون واري هدايت ۾ جيڪڏهن نالي جي جاء ٺاهي وئي آهي 2 дня 23 часа واپس، ۽ پيٽرولر اشارو ڪري ٿو 3 дня, هن namespace کي ختم نه ڪيو ويندو.

ھڪڙو وڌيڪ پيٽرولر آھي، اھو ذميوار آھي ته ڪيترا ڀيرا سڀني نالن جي اسپيس کي اسڪين ڪيو وڃي ۽ بغير لڳائڻ جي ڏينھن لاء چيڪ ڪريو - هر منٽ چيڪ ڪريو. ڊفالٽ طور اهو برابر آهي 30 минутам.

ڪيئن هن ڪم ڪندو

عملي طور تي، توهان جي ضرورت پوندي:

  1. Docker هڪ الڳ ماحول ۾ ڪم ڪرڻ لاء.
  2. منيڪيوب مقامي طور تي ڪبرنيٽس ڪلستر کي وڌائيندو.
  3. ڪيوبڪبل - ڪلستر مينيجمينٽ لاءِ ڪمانڊ لائن انٽرفيس.

اسان مقامي طور تي ڪبرنيٽس ڪلستر بلند ڪريون ٿا:

$ 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, namespaces 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 ڪيترائي ڀيرا ۽ پڪ ڪريو ته اهي هڪ منٽ اندر ختم ٿي ويا آهن.

متبادل

ڪلستر ۾ ڪم ڪندڙ آپريٽر جي بدران ڇا ٿي سگهي ٿو؟ اتي ڪيترائي طريقا آھن، اھي سڀ ناقص آھن (۽ انھن جون نقصون تابع آھن)، ۽ ھر ڪو پاڻ لاءِ فيصلو ڪري ٿو ته ڪنھن خاص منصوبي لاءِ بھترين ڇا آھي:

  1. ماسٽر برانچ جي مسلسل انضمام جي تعمير دوران خصوصيت شاخ کي ختم ڪريو.

    • هن کي ڪرڻ لاءِ، توهان کي ڄاڻڻ جي ضرورت آهي ته ڪهڙي پل جي درخواست ان ڪمٽمينٽ سان لاڳاپيل آهي جيڪا تعمير ڪئي پئي وڃي. جيئن ته خصوصيت شاخ جي نالي جي جاء تي شامل آهي پل درخواست جي سڃاڻپ ڪندڙ - ان جو نمبر، يا شاخ جو نالو، سڃاڻپ ڪندڙ کي هميشه ڪمٽ ۾ بيان ڪرڻو پوندو.
    • ماسٽر برانچ تعميرات ناڪام ٿي رهيا آهن. مثال طور، توھان وٽ ھيٺيون مرحلا آھن: پروجيڪٽ ڊائون لوڊ ڪريو، ٽيسٽ ھلايو، پروجيڪٽ ٺاھيو، رليز ڪريو، نوٽيفڪيشن موڪليو، آخري پل جي درخواست جي خصوصيت شاخ کي صاف ڪريو. جيڪڏهن نوٽيفڪيشن موڪلڻ وقت تعمير ناڪام ٿئي ٿي، توهان کي دستي طور ڪلستر ۾ سڀني وسيلن کي حذف ڪرڻو پوندو.
    • مناسب مقصدن کان سواء، ماسٽر تعمير ۾ خصوصيت شاخن کي ختم ڪرڻ واضح ناهي.

  2. ويب هڪس استعمال ڪندي (مثال).

    • اهو شايد توهان جو طريقو نه آهي. مثال طور، ۾ جينکنصرف هڪ قسم جي پائيپ لائين ان جي ترتيبن کي ماخذ ڪوڊ ۾ محفوظ ڪرڻ جي صلاحيت جي حمايت ڪري ٿي. جڏهن ويب هوڪس استعمال ڪندي، توهان کي انهن کي پروسيس ڪرڻ لاءِ پنهنجو اسڪرپٽ لکڻو پوندو. هن اسڪرپٽ کي جينڪنز انٽرفيس ۾ رکڻو پوندو، جيڪو برقرار رکڻ ڏکيو آهي.

  3. لکڻ لاء ڪرونجوب ۽ ڪبرنيٽس ڪلستر شامل ڪريو.

    • لکڻ ۽ سپورٽ تي وقت گذارڻ.
    • آپريٽر اڳ ۾ ئي ساڳئي انداز ۾ ڪم ڪري ٿو، دستاويزي ۽ سپورٽ ٿيل آهي.

مضمون ڏانهن ڌيان ڏيڻ لاء توهان جي مهرباني. Github تي منصوبي سان ڳنڍيو.

جو ذريعو: www.habr.com

تبصرو شامل ڪريو