कुबेरनेट्स क्लस्टर में एक पुरानी फीचर शाखा को हटाना

हाय! फ़ीचर शाखा (उर्फ परिनियोजन पूर्वावलोकन, समीक्षा ऐप) - यह तब होता है जब न केवल मास्टर शाखा तैनात की जाती है, बल्कि प्रत्येक पुल अनुरोध को एक अद्वितीय यूआरएल पर भी तैनात किया जाता है। आप जांच सकते हैं कि कोड उत्पादन परिवेश में काम करता है या नहीं; यह सुविधा अन्य प्रोग्रामर या उत्पाद विशेषज्ञों को दिखाई जा सकती है। जब आप पुल अनुरोध में काम कर रहे होते हैं, तो पुराने कोड के लिए प्रत्येक नई प्रतिबद्ध वर्तमान तैनाती हटा दी जाती है, और नए कोड के लिए नई तैनाती शुरू हो जाती है। जब आप किसी पुल अनुरोध को मास्टर शाखा में मर्ज करते हैं तो प्रश्न उठ सकते हैं। अब आपको फीचर शाखा की आवश्यकता नहीं है, लेकिन कुबेरनेट्स संसाधन अभी भी क्लस्टर में हैं।

फ़ीचर शाखाओं के बारे में अधिक जानकारी

कुबेरनेट्स में फीचर शाखाएं बनाने का एक तरीका नेमस्पेस का उपयोग करना है। संक्षेप में, उत्पादन विन्यास इस तरह दिखता है:

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 पर प्रोजेक्ट से लिंक करें. यह उन नामस्थानों को हटा देता है जो पुरानी फीचर शाखाओं से संबंधित हैं। कुबेरनेट्स में, यदि आप एक नामस्थान हटाते हैं, तो उस नामस्थान के अन्य संसाधन भी स्वचालित रूप से हटा दिए जाते हैं।

$ 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. कुबेरनेट्स पुल अनुरोध कॉन्फ़िगरेशन तुरंत उत्पन्न होते हैं (उदाहरण के लिए, इसकी संख्या तैयार टेम्पलेट में डाली जाती है)।
4. Kubectl apply का उपयोग करके, कॉन्फ़िगरेशन को क्लस्टर (तैनाती) में जोड़ा जाता है।
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

प्राचल नेमस्पेस सबस्ट्रिंग अन्य नामस्थानों से पुल अनुरोधों के लिए नामस्थानों को फ़िल्टर करने की आवश्यकता है। उदाहरण के लिए, यदि क्लस्टर में निम्नलिखित नामस्थान हैं: 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.

प्राचल तैनाती के बिना दिन के बाद पुराने नामस्थानों को हटाने की आवश्यकता है। उदाहरण के लिए, यदि नेमस्पेस बनाया गया है 3 дня 1 час वापस, और पैरामीटर इंगित करता है 3 дня, यह नामस्थान हटा दिया जाएगा. यदि नेमस्पेस बनाया जाता है तो यह विपरीत दिशा में भी काम करता है 2 дня 23 часа वापस, और पैरामीटर इंगित करता है 3 дня, यह नामस्थान हटाया नहीं जाएगा.

एक और पैरामीटर है, यह इस बात के लिए ज़िम्मेदार है कि सभी नामस्थानों को कितनी बार स्कैन करना है और तैनाती के बिना दिनों की जांच करना है - हर मिनट की जाँच करें. डिफ़ॉल्ट रूप से यह बराबर है 30 минутам.

Как это работает

व्यवहार में, आपको आवश्यकता होगी:

1. डाक में काम करनेवाला मज़दूर एक अलग वातावरण में काम करने के लिए.
2. मिनिक्यूब स्थानीय स्तर पर कुबेरनेट्स क्लस्टर तैयार करेगा।
3. 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 कई बार और सुनिश्चित करें कि उन्हें एक मिनट के भीतर हटा दिया जाए।

विकल्प

क्लस्टर में काम करने वाले ऑपरेटर की जगह क्या किया जा सकता है? कई दृष्टिकोण हैं, वे सभी अपूर्ण हैं (और उनकी कमियाँ व्यक्तिपरक हैं), और हर कोई अपने लिए निर्णय लेता है कि किसी विशेष परियोजना के लिए सबसे अच्छा क्या है:

1. मास्टर शाखा के सतत एकीकरण निर्माण के दौरान फीचर शाखा को हटा दें।

   • ऐसा करने के लिए, आपको यह जानना होगा कि कौन सा पुल अनुरोध उस कमिट से संबंधित है जिसे बनाया जा रहा है। चूँकि फ़ीचर ब्रांच नेमस्पेस में पुल अनुरोध पहचानकर्ता - इसकी संख्या, या शाखा का नाम शामिल है, पहचानकर्ता को हमेशा कमिट में निर्दिष्ट करना होगा।
   • मास्टर शाखा निर्माण विफल हो रहे हैं. उदाहरण के लिए, आपके पास निम्नलिखित चरण हैं: प्रोजेक्ट डाउनलोड करें, परीक्षण चलाएं, प्रोजेक्ट बनाएं, रिलीज़ करें, सूचनाएं भेजें, अंतिम पुल अनुरोध की सुविधा शाखा को साफ़ करें। यदि अधिसूचना भेजते समय बिल्ड विफल हो जाता है, तो आपको क्लस्टर में सभी संसाधनों को मैन्युअल रूप से हटाना होगा।
   • उचित संदर्भ के बिना, मास्टर बिल्ड में फीचर शाखाओं को हटाना स्पष्ट नहीं है।

2. वेबहुक का उपयोग करना (उदाहरण).

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

3. लिखना क्रॉन नौकरी और एक Kubernetes क्लस्टर जोड़ें।

   • लेखन और समर्थन पर समय व्यतीत करना।
   • ऑपरेटर पहले से ही समान शैली में काम करता है, दस्तावेज़ीकृत और समर्थित है।

लेख पर ध्यान देने के लिए आपका धन्यवाद। Github पर प्रोजेक्ट से लिंक करें.

स्रोत: www.habr.com