🥇कुबरनेट क्लस्टरमधील कालबाह्य वैशिष्ट्य शाखा काढून टाकणे

हाय वैशिष्ट्य शाखा (उर्फ डिप्लॉय प्रीव्ह्यू, रिव्ह्यू अॅप) - हे तेव्हाच होते जेव्हा केवळ मास्टर ब्रँच तैनात केली जात नाही, तर प्रत्येक युनिक URL वर पुल विनंती देखील केली जाते. कोड उत्पादन वातावरणात काम करतो की नाही हे तुम्ही तपासू शकता; वैशिष्ट्य इतर प्रोग्रामर किंवा उत्पादन तज्ञांना दाखवले जाऊ शकते. तुम्ही पुल रिक्वेस्टमध्ये काम करत असताना, जुन्या कोडसाठी प्रत्येक नवीन कमिट वर्तमान डिप्लॉय हटवला जातो आणि नवीन कोडसाठी नवीन डिप्लॉय रोल आउट केला जातो. जेव्हा तुम्ही मास्टर ब्रँचमध्ये पुल विनंती विलीन करता तेव्हा प्रश्न उद्भवू शकतात. तुम्हाला यापुढे वैशिष्ट्य शाखेची आवश्यकता नाही, परंतु Kubernetes संसाधने अजूनही क्लस्टरमध्ये आहेत.

वैशिष्ट्य शाखांबद्दल अधिक

कुबर्नेट्समध्ये वैशिष्ट्य शाखा बनवण्याचा एक दृष्टीकोन म्हणजे नेमस्पेसेस वापरणे. थोडक्यात, उत्पादन कॉन्फिगरेशन असे दिसते:

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

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

वैशिष्ट्य शाखेसाठी, एक नेमस्पेस त्याच्या आयडेंटिफायरसह (उदाहरणार्थ, पुल विनंती क्रमांक) आणि काही प्रकारचे उपसर्ग/पोस्टफिक्स तयार केले जाते (उदाहरणार्थ, -pr-):

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):

आम्ही शाखेत एक नवीन वचनबद्धता ढकलतो.
बिल्डवर, लिंटर आणि/किंवा चाचण्या चालवल्या जातात.
कुबर्नेट्स पुल विनंती कॉन्फिगरेशन फ्लायवर व्युत्पन्न केले जातात (उदाहरणार्थ, त्याचा नंबर तयार टेम्पलेटमध्ये समाविष्ट केला जातो).
kubectl लागू वापरून, क्लस्टरमध्ये कॉन्फिगरेशन जोडले जातात (उपयोजन).
पुल विनंती मास्टर शाखेत विलीन केली आहे.

तुम्ही पुल रिक्वेस्टमध्ये काम करत असताना, जुन्या कोडसाठी प्रत्येक नवीन कमिट वर्तमान डिप्लॉय हटवला जातो आणि नवीन कोडसाठी नवीन डिप्लॉय रोल आउट केला जातो. परंतु जेव्हा पुल विनंती मास्टर ब्रँचमध्ये विलीन केली जाते, तेव्हा फक्त मास्टर ब्रांच बांधली जाईल. परिणामी, असे दिसून आले की आम्ही पुल विनंतीबद्दल आधीच विसरलो आहोत आणि त्याचे कुबरनेट संसाधने अद्याप क्लस्टरमध्ये आहेत.

कसे वापरावे

खालील आदेशासह प्रकल्प स्थापित करा:

$ 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 जुनी नेमस्पेस हटवण्यासाठी आवश्यक आहे. उदाहरणार्थ, नेमस्पेस तयार केल्यास 3 дня 1 час मागे, आणि पॅरामीटर सूचित करते 3 дня, हे नेमस्पेस हटवले जाईल. नेमस्पेस तयार केल्यास ते विरुद्ध दिशेने देखील कार्य करते 2 дня 23 часа मागे, आणि पॅरामीटर सूचित करते 3 дня, हे नेमस्पेस हटवले जाणार नाही.

आणखी एक पॅरामीटर आहे, सर्व नेमस्पेस किती वेळा स्कॅन करायचे आणि उपयोजनाशिवाय दिवस तपासायचे यासाठी ते जबाबदार आहे - प्रत्येक मिनिट तपासा. डीफॉल्टनुसार ते समान आहे 30 минутам.

या कसे कार्य करते

सराव मध्ये, आपल्याला याची आवश्यकता असेल:

गोदी कामगार वेगळ्या वातावरणात काम करण्यासाठी.
मिनीकुबे स्थानिक पातळीवर कुबर्नेट्स क्लस्टर वाढवेल.
kubectl - क्लस्टर व्यवस्थापनासाठी कमांड लाइन इंटरफेस.

आम्ही स्थानिक पातळीवर कुबर्नेट्स क्लस्टर वाढवतो:

$ 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 अनेक वेळा आणि ते एका मिनिटात काढले जातील याची खात्री करा.

विकल्प

क्लस्टरमध्ये काम करणाऱ्या ऑपरेटरऐवजी काय करता येईल? तेथे अनेक दृष्टिकोन आहेत, ते सर्व अपूर्ण आहेत (आणि त्यांच्या उणीवा व्यक्तिनिष्ठ आहेत), आणि प्रत्येकजण स्वत: साठी ठरवतो की एखाद्या विशिष्ट प्रकल्पासाठी काय सर्वोत्तम आहे:

मास्टर शाखेच्या सतत एकत्रीकरणादरम्यान वैशिष्ट्य शाखा हटवा.
- हे करण्यासाठी, तुम्हाला कोणती पुल विनंती बांधली जात असलेल्या कमिटशी संबंधित आहे हे माहित असणे आवश्यक आहे. वैशिष्ट्य शाखेच्या नेमस्पेसमध्ये पुल रिक्वेस्ट आयडेंटिफायर - त्याचा क्रमांक किंवा शाखेचे नाव असल्याने, अभिज्ञापक नेहमी कमिटमध्ये निर्दिष्ट करावा लागेल.
- मुख्य शाखा बिल्ड अयशस्वी होत आहेत. उदाहरणार्थ, तुमच्याकडे खालील टप्पे आहेत: प्रोजेक्ट डाउनलोड करा, चाचण्या चालवा, प्रोजेक्ट तयार करा, रिलीझ करा, सूचना पाठवा, शेवटच्या पुल विनंतीची वैशिष्ट्य शाखा साफ करा. सूचना पाठवताना बिल्ड अयशस्वी झाल्यास, तुम्हाला क्लस्टरमधील सर्व संसाधने व्यक्तिचलितपणे हटवावी लागतील.
- योग्य संदर्भाशिवाय, मास्टर बिल्डमधील वैशिष्ट्य शाखा हटवणे स्पष्ट नाही.
वेबहुक वापरणे (उदाहरण).
- हा तुमचा दृष्टिकोन असू शकत नाही. उदाहरणार्थ, मध्ये जेनकिन्स, फक्त एक प्रकारची पाइपलाइन त्याची कॉन्फिगरेशन स्त्रोत कोडमध्ये जतन करण्याच्या क्षमतेस समर्थन देते. वेबहुक वापरताना, त्यावर प्रक्रिया करण्यासाठी तुम्हाला तुमची स्वतःची स्क्रिप्ट लिहावी लागेल. ही स्क्रिप्ट जेनकिन्स इंटरफेसमध्ये ठेवावी लागेल, जी राखणे कठीण आहे.
लिहायला क्रोनजॉब आणि कुबर्नेट्स क्लस्टर जोडा.
- लेखन आणि समर्थनासाठी वेळ घालवणे.
- ऑपरेटर आधीपासूनच समान शैलीमध्ये कार्य करतो, दस्तऐवजीकरण आणि समर्थित आहे.

लेखाकडे लक्ष दिल्याबद्दल धन्यवाद. Github वर प्रकल्पाचा दुवा.

स्त्रोत: www.habr.com

Kubernetes क्लस्टरमधील कालबाह्य वैशिष्ट्य शाखा काढून टाकत आहे

वैशिष्ट्य शाखांबद्दल अधिक

प्रेरणा

कसे वापरावे

या कसे कार्य करते

विकल्प

एक टिप्पणी जोडा Отменить ответ