OpenShift साठी GitOps चा परिचय

आज आपण GitOps ची तत्त्वे आणि मॉडेल्स, तसेच हे मॉडेल्स OpenShift प्लॅटफॉर्मवर कसे लागू केले जातात याबद्दल बोलू. या विषयावर संवादात्मक मार्गदर्शक उपलब्ध आहे दुवा.

थोडक्यात, GitOps हा पायाभूत सुविधा आणि ऍप्लिकेशन कॉन्फिगरेशन व्यवस्थापित करण्यासाठी Git पुल विनंत्या वापरण्याच्या पद्धतींचा एक संच आहे. GitOps मधील Git रेपॉजिटरी ही प्रणालीच्या स्थितीबद्दल माहितीचा एक स्रोत म्हणून हाताळली जाते आणि या स्थितीतील कोणतेही बदल पूर्णपणे शोधण्यायोग्य आणि ऑडिट करण्यायोग्य आहेत.

GitOps मधील बदल ट्रॅकिंगची कल्पना कोणत्याही प्रकारे नवीन नाही; अनुप्रयोग स्त्रोत कोडसह कार्य करताना हा दृष्टिकोन जवळजवळ सर्वत्र वापरला जात आहे. GitOps इन्फ्रास्ट्रक्चर आणि ऍप्लिकेशन कॉन्फिगरेशन व्यवस्थापनामध्ये समान वैशिष्ट्ये (पुनरावलोकने, पुल विनंत्या, टॅग इ.) लागू करते आणि स्त्रोत कोड व्यवस्थापनाच्या बाबतीत समान फायदे प्रदान करते.

GitOps साठी कोणतीही शैक्षणिक व्याख्या किंवा नियमांचा मंजूर संच नाही, फक्त तत्त्वांचा संच ज्यावर ही प्रथा बांधली गेली आहे:

• प्रणालीचे घोषणात्मक वर्णन गिट रेपॉजिटरी (कॉन्फिग्स, मॉनिटरिंग इ.) मध्ये संग्रहित केले जाते.
• राज्य बदल पुल विनंतीद्वारे केले जातात.
• Git पुश विनंत्या वापरून रिपॉजिटरीमधील डेटाच्या अनुषंगाने चालू असलेल्या सिस्टमची स्थिती आणली जाते.

GitOps तत्त्वे

• सिस्टम व्याख्या स्त्रोत कोड म्हणून वर्णन केल्या आहेत

सिस्टम कॉन्फिगरेशन कोड म्हणून मानले जाते जेणेकरून ते संग्रहित केले जाऊ शकते आणि Git रिपॉझिटरीमध्ये स्वयंचलितपणे आवृत्ती केली जाऊ शकते, जे सत्याचा एक स्रोत म्हणून काम करते. हा दृष्टिकोन सिस्टीममधील बदल रोलआउट आणि रोलबॅक करणे सोपे करतो.

• सिस्टमची इच्छित स्थिती आणि कॉन्फिगरेशन Git मध्ये सेट आणि व्हर्जन केले आहे

Git मध्‍ये सिस्‍टमच्‍या इच्‍छित स्‍टेटचे स्‍टोअर आणि आवृत्‍ती करून, आम्‍ही सिस्‍टम आणि ॲप्लिकेशनमध्‍ये सहजतेने रोल आऊट करण्‍यास आणि बदल करण्‍यास सक्षम आहोत. कोड मालकी नियंत्रित करण्यासाठी आणि त्याची सत्यता सत्यापित करण्यासाठी आम्ही Git च्या सुरक्षा यंत्रणा देखील वापरू शकतो.

• कॉन्फिगरेशन बदल पुल विनंतीद्वारे स्वयंचलितपणे लागू केले जाऊ शकतात

Git पुल विनंत्या वापरून, आम्ही रेपॉजिटरीमधील कॉन्फिगरेशनमध्ये बदल कसे लागू केले जातात ते सहजपणे नियंत्रित करू शकतो. उदाहरणार्थ, ते इतर टीम सदस्यांना पुनरावलोकनासाठी दिले जाऊ शकतात किंवा CI चाचण्यांद्वारे चालवले जाऊ शकतात इ.

आणि त्याच वेळी, प्रशासक अधिकार डावीकडे आणि उजवीकडे वितरित करण्याची आवश्यकता नाही. कॉन्फिगरेशन बदल करण्यासाठी, वापरकर्त्यांना फक्त Git रेपॉजिटरीमध्ये योग्य परवानग्या आवश्यक आहेत जेथे ते कॉन्फिगरेशन संग्रहित केले जातात.

• कॉन्फिगरेशनच्या अनियंत्रित ड्रिफ्टच्या समस्येचे निराकरण करणे

एकदा गिट रेपॉजिटरीमध्ये सिस्टीमची इच्छित स्थिती संग्रहित केल्यावर, आपल्याला फक्त सॉफ्टवेअर शोधायचे आहे जे सिस्टमची वर्तमान स्थिती त्याच्या इच्छित स्थितीशी जुळते याची खात्री करेल. असे नसल्यास, या सॉफ्टवेअरने - सेटिंग्जवर अवलंबून - एकतर स्वतःहून विसंगती दूर केली पाहिजे किंवा कॉन्फिगरेशन ड्रिफ्टबद्दल आम्हाला सूचित केले पाहिजे.

OpenShift साठी GitOps मॉडेल

ऑन-क्लस्टर रिसोर्स रिकंसिलर

या मॉडेलनुसार, क्लस्टरमध्ये एक कंट्रोलर आहे जो Git रेपॉजिटरीमधील कुबर्नेट्स संसाधने (YAML फाइल्स) क्लस्टरच्या वास्तविक संसाधनांशी तुलना करण्यासाठी जबाबदार आहे. विसंगती आढळल्यास, नियंत्रक सूचना पाठवतो आणि संभाव्यत: विसंगती दुरुस्त करण्यासाठी कारवाई करतो. हे GitOps मॉडेल अँथोस कॉन्फिग मॅनेजमेंट आणि वेव्हवर्क्स फ्लक्समध्ये वापरले जाते.

बाह्य संसाधन सामंजस्य (पुश)

जेव्हा आमच्याकडे “Git repository - Kubernetes क्लस्टर” जोड्यांमध्ये संसाधने समक्रमित करण्यासाठी जबाबदार एक किंवा अधिक नियंत्रक असतात तेव्हा हे मॉडेल मागील मॉडेलचे रूपांतर मानले जाऊ शकते. येथे फरक असा आहे की प्रत्येक व्यवस्थापित क्लस्टरचे स्वतःचे स्वतंत्र नियंत्रक असणे आवश्यक नाही. Git - k8s क्लस्टर जोड्या सहसा CRDs (सानुकूल संसाधन परिभाषा) म्हणून परिभाषित केल्या जातात, जे कंट्रोलरने सिंक्रोनाइझेशन कसे करावे याचे वर्णन करू शकतात. या मॉडेलमध्ये, नियंत्रक CRD मध्ये निर्दिष्ट केलेल्या Git भांडाराची तुलना कुबर्नेट्स क्लस्टर संसाधनांशी करतात, जे CRD मध्ये देखील निर्दिष्ट केले जातात आणि तुलनाच्या परिणामांवर आधारित योग्य क्रिया करतात. विशेषतः, हे GitOps मॉडेल ArgoCD मध्ये वापरले जाते.

OpenShift प्लॅटफॉर्मवर GitOps

मल्टी-क्लस्टर कुबर्नेट्स इन्फ्रास्ट्रक्चरचे प्रशासन

कुबर्नेट्सचा प्रसार आणि मल्टी-क्लाउड स्ट्रॅटेजीज आणि एज कॉम्प्युटिंगच्या वाढत्या लोकप्रियतेमुळे, प्रति ग्राहक ओपनशिफ्ट क्लस्टरची सरासरी संख्या देखील वाढत आहे.

उदाहरणार्थ, एज कॉम्प्युटिंग वापरताना, एका ग्राहकाचे क्लस्टर शेकडो किंवा हजारो मध्ये तैनात केले जाऊ शकतात. परिणामी, त्याला सार्वजनिक क्लाउड आणि ऑन-प्रिमाइसमध्ये अनेक स्वतंत्र किंवा समन्वित OpenShift क्लस्टर व्यवस्थापित करण्यास भाग पाडले जाते.

या प्रकरणात, बर्याच समस्यांचे निराकरण करावे लागेल, विशेषतः:

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

ऍप्लिकेशन कॉन्फिगरेशन

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

या प्रकरणात, खालील कार्ये सोडवणे आवश्यक आहे:

• क्लस्टर्स (देव, स्टेज, इ.) दरम्यान अनुप्रयोगांची हालचाल (बायनरी, कॉन्फिग, इ.) सुनिश्चित करा.
• अनेक OpenShift क्लस्टर्समध्ये ऍप्लिकेशन्स (बायनरी, कॉन्फिग, इ.) मध्ये बदल रोल आउट करा.
• मागील ज्ञात स्थितीत ऍप्लिकेशन्समधील बदल परत करा.

OpenShift GitOps वापर प्रकरणे

1. Git रेपॉजिटरीमधील बदल लागू करणे

क्लस्टर प्रशासक Git रेपॉजिटरीमध्ये OpenShift क्लस्टर कॉन्फिगरेशन संचयित करू शकतो आणि नवीन क्लस्टर्स तयार करण्यासाठी आपोआप लागू करू शकतो आणि Git रिपॉजिटरीमध्ये संग्रहित ज्ञात स्थितीप्रमाणेच स्थितीत आणू शकतो.

2. सीक्रेट मॅनेजरसह सिंक्रोनाइझेशन

यासाठी खास तयार केलेल्या साधनांचा वापर करून त्यांचे व्यवस्थापन करण्यासाठी Vault सारख्या योग्य सॉफ्टवेअरसह OpenShift गुप्त वस्तू समक्रमित करण्याच्या क्षमतेचा देखील प्रशासकाला फायदा होईल.

3. ड्रिफ्ट कॉन्फिगरेशनचे नियंत्रण

जर OpenShift GitOps स्वतःच वास्तविक कॉन्फिगरेशन आणि रिपॉजिटरीमध्ये निर्दिष्ट केलेल्या विसंगती ओळखून त्याबद्दल चेतावणी देत ​​असेल तरच प्रशासक त्याच्या बाजूने असेल, जेणेकरून ते ड्रिफ्टला त्वरीत प्रतिसाद देऊ शकतील.

4. कॉन्फिगरेशन ड्रिफ्टबद्दल सूचना

जेव्हा प्रशासकास स्वतःहून योग्य उपाययोजना करण्यासाठी कॉन्फिगरेशन ड्रिफ्टच्या प्रकरणांबद्दल त्वरीत जाणून घ्यायचे असेल तेव्हा ते उपयुक्त आहेत.

5. ड्रिफ्टिंग करताना कॉन्फिगरेशनचे मॅन्युअल सिंक्रोनाइझेशन

क्लस्टरला पूर्वीच्या ज्ञात स्थितीत त्वरीत परत करण्यासाठी, कॉन्फिगरेशन ड्रिफ्टच्या घटनेत Git रेपॉजिटरीसह OpenShift क्लस्टर सिंक्रोनाइझ करण्याची प्रशासकास अनुमती देते.

6. ड्रिफ्टिंग करताना कॉन्फिगरेशनचे ऑटो-सिंक्रोनाइझेशन

अॅडमिनिस्ट्रेटर ओपनशिफ्ट क्लस्टरला रिपॉजिटरीसह आपोआप सिंक्रोनाइझ करण्यासाठी कॉन्फिगर देखील करू शकतो जेव्हा ड्रिफ्ट आढळतो, जेणेकरून क्लस्टर कॉन्फिगरेशन नेहमी Git मधील कॉन्फिगरेशनशी जुळते.

7. अनेक क्लस्टर्स - एक भांडार

प्रशासक एका गिट रेपॉजिटरीमध्ये अनेक भिन्न ओपनशिफ्ट क्लस्टर्सचे कॉन्फिगरेशन संचयित करू शकतो आणि आवश्यकतेनुसार त्यांना निवडकपणे लागू करू शकतो.

8. क्लस्टर कॉन्फिगरेशनची पदानुक्रम (वारसा)

प्रशासक रेपॉजिटरीमध्ये (स्टेज, प्रोड, अॅप पोर्टफोलिओ, इ. इनहेरिटन्ससह) क्लस्टर कॉन्फिगरेशनची पदानुक्रम सेट करू शकतो. दुसर्‍या शब्दात, कॉन्फिगरेशन एक किंवा अधिक क्लस्टरवर लागू केले जावे की नाही हे निर्धारित करू शकते.

उदाहरणार्थ, जर प्रशासकाने गिट रेपॉजिटरीमध्ये “प्रॉडक्शन क्लस्टर्स (प्रॉड) → सिस्टम एक्स क्लस्टर्स → सिस्टम एक्सचे प्रोडक्शन क्लस्टर्स” हा पदानुक्रम सेट केला, तर खालील कॉन्फिगचे संयोजन सिस्टम X च्या उत्पादन क्लस्टरवर लागू केले जाते:

• कॉन्फिग सर्व उत्पादन क्लस्टर्ससाठी सामान्य.
• सिस्टम X क्लस्टरसाठी कॉन्फिग्स.
• X प्रणाली उत्पादन क्लस्टरसाठी कॉन्फिग.

9. टेम्पलेट्स आणि कॉन्फिगरेशन ओव्हरराइड्स

प्रशासक अनुवांशिक कॉन्फिगरेशनचा संच आणि त्यांची मूल्ये ओव्हरराइड करू शकतो, उदाहरणार्थ, विशिष्ट क्लस्टरसाठी कॉन्फिगरेशन फाइन-ट्यून करण्यासाठी ज्यावर ते लागू केले जातील.

10. कॉन्फिगरेशन, ऍप्लिकेशन कॉन्फिगरेशनसाठी निवडक समाविष्ट आणि वगळणे

प्रशासक विशिष्ट वैशिष्ट्यांसह क्लस्टरमध्ये अनुप्रयोगासाठी किंवा विशिष्ट कॉन्फिगरेशनच्या गैर-अर्जासाठी अटी सेट करू शकतो.

11. टेम्पलेट समर्थन

प्रत्येक विशिष्ट अनुप्रयोगासाठी सर्वात योग्य स्वरूप वापरण्यासाठी अनुप्रयोग संसाधने कशी परिभाषित केली जातील (हेल्म चार्ट, शुद्ध कुबर्नेट्स यामल इ.) निवडण्याच्या क्षमतेचा विकासकांना फायदा होईल.

OpenShift प्लॅटफॉर्मवर GitOps टूल्स

ArgoCD

ArgoCD बाह्य संसाधन सामंजस्य मॉडेल लागू करते आणि क्लस्टर आणि Git रेपॉजिटरीजमधील एक-ते-अनेक संबंधांचे आयोजन करण्यासाठी केंद्रीकृत UI ऑफर करते. या प्रोग्रामच्या तोट्यांमध्ये ArgoCD कार्य करत नसताना अनुप्रयोग व्यवस्थापित करण्यात अक्षमता समाविष्ट आहे.

अधिकृत वेबसाइट

प्रवाह

फ्लक्स ऑन-क्लस्टर रिसोर्स रिकन्साइल मॉडेल लागू करते आणि परिणामी, डेफिनेशन रिपॉझिटरीचे कोणतेही केंद्रीकृत व्यवस्थापन नाही, जो एक कमकुवत मुद्दा आहे. दुसरीकडे, तंतोतंत केंद्रीकरणाच्या अभावामुळे, एक क्लस्टर अयशस्वी झाला तरीही अनुप्रयोग व्यवस्थापित करण्याची क्षमता राहते.

अधिकृत वेबसाइट

OpenShift वर ArgoCD स्थापित करत आहे

ArgoCD उत्कृष्ट कमांड लाइन इंटरफेस आणि वेब कन्सोल ऑफर करते, म्हणून आम्ही येथे फ्लक्स आणि इतर पर्यायांचा समावेश करणार नाही.

OpenShift 4 प्लॅटफॉर्मवर ArgoCD तैनात करण्यासाठी, क्लस्टर प्रशासक म्हणून या चरणांचे अनुसरण करा:

OpenShift प्लॅटफॉर्मवर ArgoCD घटक तैनात करणे

# Create a new namespace for ArgoCD components
oc create namespace argocd
# Apply the ArgoCD Install Manifest
oc -n argocd apply -f https://raw.githubusercontent.com/argoproj/argo-cd/v1.2.2/manifests/install.yaml
# Get the ArgoCD Server password
ARGOCD_SERVER_PASSWORD=$(oc -n argocd get pod -l "app.kubernetes.io/name=argocd-server" -o jsonpath='{.items[*].metadata.name}')

आर्गोसीडी सर्व्हरमध्ये सुधारणा करणे जेणेकरून ते ओपनशिफ्ट रूटद्वारे पाहिले जाऊ शकते

# Patch ArgoCD Server so no TLS is configured on the server (--insecure)
PATCH='{"spec":{"template":{"spec":{"$setElementOrder/containers":[{"name":"argocd-server"}],"containers":[{"command":["argocd-server","--insecure","--staticassets","/shared/app"],"name":"argocd-server"}]}}}}'
oc -n argocd patch deployment argocd-server -p $PATCH
# Expose the ArgoCD Server using an Edge OpenShift Route so TLS is used for incoming connections
oc -n argocd create route edge argocd-server --service=argocd-server --port=http --insecure-policy=Redirect

ArgoCD Cli टूल तैनात करत आहे

# Download the argocd binary, place it under /usr/local/bin and give it execution permissions
curl -L https://github.com/argoproj/argo-cd/releases/download/v1.2.2/argocd-linux-amd64 -o /usr/local/bin/argocd
chmod +x /usr/local/bin/argocd

ArgoCD सर्व्हर प्रशासक पासवर्ड बदलणे

# Get ArgoCD Server Route Hostname
ARGOCD_ROUTE=$(oc -n argocd get route argocd-server -o jsonpath='{.spec.host}')
# Login with the current admin password
argocd --insecure --grpc-web login ${ARGOCD_ROUTE}:443 --username admin --password ${ARGOCD_SERVER_PASSWORD}
# Update admin's password
argocd --insecure --grpc-web --server ${ARGOCD_ROUTE}:443 account update-password --current-password ${ARGOCD_SERVER_PASSWORD} --new-password

या पायऱ्या पूर्ण केल्यानंतर, तुम्ही ArgoCD WebUI वेब कन्सोल किंवा ArgoCD Cli कमांड लाइन टूलद्वारे ArgoCD सर्व्हरसह कार्य करू शकता.
https://blog.openshift.com/is-it-too-late-to-integrate-gitops/

GitOps - कधीही खूप उशीर झालेला नाही

"ट्रेन निघाली आहे" - जेव्हा काहीतरी करण्याची संधी गमावली जाते अशा परिस्थितीबद्दल ते असे म्हणतात. OpenShift च्या बाबतीत, या छान नवीन प्लॅटफॉर्मचा वापर ताबडतोब सुरू करण्याची इच्छा अनेकदा मार्ग, उपयोजन आणि इतर OpenShift ऑब्जेक्ट्सच्या व्यवस्थापन आणि देखरेखीसह ही परिस्थिती निर्माण करते. पण संधी नेहमीच चुकते का?

बद्दल लेखांची मालिका सुरू ठेवत आहे GitOps, आज आम्‍ही तुम्‍हाला हँडक्राफ्ट केलेले अॅप्लिकेशन आणि त्‍याच्‍या संसाधनांचे अशा प्रक्रियेमध्‍ये रूपांतर कसे करायचे ते दाखवू जेथे सर्वकाही GitOps टूल्सद्वारे व्‍यवस्‍थापित केले जाते. हे करण्यासाठी, आम्ही प्रथम httpd अनुप्रयोग स्वहस्ते तैनात करू. खालील स्क्रीनशॉट दाखवतो की आम्ही नेमस्पेस, उपयोजन आणि सेवा कशी तयार करतो आणि नंतर मार्ग तयार करण्यासाठी ही सेवा उघड करतो.

oc create -f https://raw.githubusercontent.com/openshift/federation-dev/master/labs/lab-4-assets/namespace.yaml
oc create -f https://raw.githubusercontent.com/openshift/federation-dev/master/labs/lab-4-assets/deployment.yaml
oc create -f https://raw.githubusercontent.com/openshift/federation-dev/master/labs/lab-4-assets/service.yaml
oc expose svc/httpd -n simple-app

म्हणून आमच्याकडे एक हस्तकला अनुप्रयोग आहे. आता ते GitOps व्यवस्थापन अंतर्गत उपलब्धता न गमावता हस्तांतरित करणे आवश्यक आहे. थोडक्यात, हे असे करते:

• कोडसाठी गिट रेपॉजिटरी तयार करा.
• आम्ही आमच्या वर्तमान वस्तू निर्यात करतो आणि त्यांना Git भांडारात अपलोड करतो.
• GitOps साधने निवडणे आणि उपयोजित करणे.
• आम्ही आमचे भांडार या टूलकिटमध्ये जोडतो.
• आम्ही आमच्या GitOps टूलकिटमध्ये अनुप्रयोग परिभाषित करतो.
• आम्ही GitOps टूलकिट वापरून अनुप्रयोगाची चाचणी चालवतो.
• आम्ही GitOps टूलकिट वापरून ऑब्जेक्ट्स सिंक्रोनाइझ करतो.
• ऑब्जेक्ट्सची छाटणी आणि स्वयं-सिंक्रोनाइझेशन सक्षम करा.

पूर्वी नमूद केल्याप्रमाणे लेख, GitOps मध्ये Kubernetes क्लस्टर(s) मधील सर्व वस्तूंबद्दल माहितीचा एकच स्रोत आहे - Git repository. पुढे, तुमची संस्था आधीच Git रेपॉजिटरी वापरते या आधारावर आम्ही पुढे जाऊ. हे सार्वजनिक किंवा खाजगी असू शकते, परंतु ते Kubernetes क्लस्टरमध्ये प्रवेश करण्यायोग्य असणे आवश्यक आहे. हे ऍप्लिकेशन कोड प्रमाणेच रिपॉझिटरी किंवा डिप्लॉयमेंटसाठी खास तयार केलेले वेगळे भांडार असू शकते. रेपॉजिटरीमध्ये कठोर परवानग्या ठेवण्याची शिफारस केली जाते कारण तेथे रहस्ये, मार्ग आणि इतर सुरक्षा-संवेदनशील गोष्टी संग्रहित केल्या जातील.

आमच्या उदाहरणात, आम्ही GitHub वर एक नवीन सार्वजनिक भांडार तयार करू. तुम्हाला आवडेल ते तुम्ही म्हणू शकता, आम्ही ब्लॉगपोस्ट हे नाव वापरतो.

YAML ऑब्जेक्ट फाइल्स स्थानिक किंवा Git मध्ये संग्रहित केल्या नसल्यास, तुम्हाला oc किंवा kubectl binaries वापरावे लागतील. खालील स्क्रीनशॉटमध्ये आम्ही आमच्या नेमस्पेस, उपयोजन, सेवा आणि मार्गासाठी YAML ची विनंती करत आहोत. याआधी, आम्ही नवीन तयार केलेल्या रेपॉजिटरी आणि सीडीचे क्लोन केले.

oc get namespace simple-app -o yaml --export > namespace.yaml
oc get deployment httpd -o yaml -n simple-app --export > deployment.yaml
oc get service httpd -o yaml -n simple-app --export > service.yaml
oc get route httpd -o yaml -n simple-app --export > route.yaml

आता Argo CD सिंक करू शकत नाही असे फील्ड काढून टाकण्यासाठी deployment.yaml फाइल संपादित करू.

sed -i '/sgeneration: .*/d' deployment.yaml

याव्यतिरिक्त, मार्ग बदलणे आवश्यक आहे. आम्ही प्रथम मल्टीलाइन व्हेरिएबल सेट करू आणि नंतर त्या व्हेरिएबलच्या सामग्रीसह प्रवेश: नल बदलू.

export ROUTE="  ingress:                                                            
    - conditions:
        - status: 'True'
          type: Admitted"

sed -i "s/  ingress: null/$ROUTE/g" route.yaml

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

git commit -am ‘initial commit of objects’
git push origin master

पुढे आम्ही या वस्तुस्थितीपासून पुढे जाऊ की तुम्ही आधीच ArgoCD तैनात केले आहे (हे कसे करायचे - मागील पहा पोस्ट). म्हणून, आम्ही आमच्या उदाहरणातील ऍप्लिकेशन कोडसह आम्ही तयार केलेले भांडार Argo CD मध्ये जोडू. फक्त तुम्ही आधी तयार केलेला अचूक रेपॉजिटरी निर्दिष्ट केल्याची खात्री करा.

argocd repo add https://github.com/cooktheryan/blogpost

आता अनुप्रयोग तयार करूया. अॅप्लिकेशन व्हॅल्यू सेट करते जेणेकरून GitOps टूलकिट कोणते रेपॉजिटरी आणि पथ वापरायचे, ऑब्जेक्ट्स व्यवस्थापित करण्यासाठी कोणती OpenShift आवश्यक आहे, रिपॉझिटरीची कोणती विशिष्ट शाखा आवश्यक आहे आणि संसाधने स्वयं-सिंक्रोनाइझ करावी की नाही हे समजते.

argocd app create --project default 
--name simple-app --repo https://github.com/cooktheryan/blogpost.git 
--path . --dest-server https://kubernetes.default.svc 
--dest-namespace simple-app --revision master --sync-policy none

एकदा अर्ज आर्गो सीडीमध्ये निर्दिष्ट केल्यावर, टूलकिट रेपॉजिटरीमधील व्याख्यांच्या विरूद्ध आधीपासून तैनात केलेल्या वस्तू तपासण्यास सुरुवात करते. आमच्या उदाहरणामध्ये, स्वयं-सिंक आणि क्लीनअप अक्षम केले आहेत, त्यामुळे घटक अद्याप बदलत नाहीत. कृपया लक्षात घ्या की Argo CD इंटरफेसमध्ये आमच्या अर्जाची स्थिती "आऊट ऑफ सिंक" असेल कारण ArgoCD प्रदान करते असे कोणतेही लेबल नाही.
म्हणूनच जेव्हा आम्ही थोड्या वेळाने सिंक्रोनाइझेशन सुरू करतो, तेव्हा ऑब्जेक्ट्स पुन्हा तैनात केल्या जाणार नाहीत.

आता आमच्या फायलींमध्ये त्रुटी नाहीत याची खात्री करण्यासाठी एक चाचणी करू.

argocd app sync simple-app --dry-run

कोणतीही त्रुटी नसल्यास, आपण सिंक्रोनाइझेशनवर पुढे जाऊ शकता.

argocd app sync simple-app

आमच्या ऍप्लिकेशनवर argocd get कमांड चालवल्यानंतर, ऍप्लिकेशनची स्थिती हेल्दी किंवा सिंकमध्ये बदलली आहे हे पाहावे. याचा अर्थ असा होईल की Git रेपॉजिटरीमधील सर्व संसाधने आता त्या संसाधनांशी संबंधित आहेत जी आधीच तैनात केली गेली आहेत.

argocd app get simple-app
Name:               simple-app
Project:            default
Server:             https://kubernetes.default.svc
Namespace:          simple-app
URL:                https://argocd-server-route-argocd.apps.example.com/applications/simple-app
Repo:               https://github.com/cooktheryan/blogpost.git
Target:             master
Path:               .
Sync Policy:        <none>
Sync Status:        Synced to master (60e1678)
Health Status:      Healthy
...   

आता तुम्ही स्वयं-सिंक्रोनाइझेशन आणि क्लीनअप सक्षम करू शकता हे सुनिश्चित करण्यासाठी की काहीही मॅन्युअली तयार केले जात नाही आणि प्रत्येक वेळी एखादी वस्तू तयार केली जाते किंवा रेपॉजिटरीमध्ये अद्यतनित केली जाते तेव्हा एक उपयोजन होईल.

argocd app set simple-app --sync-policy automated --auto-prune

म्हणून, आम्ही यशस्वीरित्या GitOps नियंत्रणाखाली एक ऍप्लिकेशन आणले आहे जे सुरुवातीला कोणत्याही प्रकारे GitOps वापरत नव्हते.

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