🥇कुबर्नेट्स क्लस्टरमा पुरानो सुविधा शाखा हटाउँदै

नमस्ते! सुविधा शाखा (उर्फ डिप्लोय प्रिभ्यू, रिभ्यु एप) - यो तब हुन्छ जब मास्टर शाखा मात्र नभई अनन्य 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 लागू प्रयोग गरेर, कन्फिगरेसनहरू क्लस्टर (डिप्लोय) मा थपिन्छन्।
पुल अनुरोध मास्टर शाखामा मर्ज गरिएको छ।

जब तपाइँ पुल अनुरोधमा काम गर्दै हुनुहुन्छ, पुरानो कोडको लागि प्रत्येक नयाँ कमिट हालको डिप्लोय मेटाइन्छ, र नयाँ कोडको लागि नयाँ डिप्लोय रोल आउट हुन्छ। तर जब पुल अनुरोध मास्टर शाखामा मर्ज हुन्छ, मास्टर शाखा मात्र निर्माण हुनेछ। नतिजाको रूपमा, यो बाहिर जान्छ कि हामीले पुल अनुरोधको बारेमा बिर्सेका छौं, र यसको 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

परिमिति 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 минутам.

यो कसरी काम गर्छ

अभ्यास मा, तपाईंलाई आवश्यक हुनेछ:

डकर एक पृथक वातावरण मा काम को लागी।
Minikube स्थानीय रूपमा Kubernetes क्लस्टर खडा गर्नेछ।
kubectl - क्लस्टर व्यवस्थापनको लागि कमाण्ड लाइन इन्टरफेस।

हामी स्थानीय रूपमा 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 क्लस्टरमा पुरानो सुविधा शाखा हटाउँदै

सुविधा शाखाहरूको बारेमा थप

प्रेरणा

कसरी प्रयोग गर्ने

यो कसरी काम गर्छ

विकल्पहरू

एक टिप्पणी थप्न Отменить ответ