OpenShift के लिए GitOps का परिचय

आज हम GitOps के सिद्धांतों और मॉडलों के बारे में बात करेंगे, साथ ही इन मॉडलों को OpenShift प्लेटफ़ॉर्म पर कैसे लागू किया जाता है। इस विषय पर एक इंटरैक्टिव गाइड उपलब्ध है по ссылке.

संक्षेप में, GitOps बुनियादी ढांचे और एप्लिकेशन कॉन्फ़िगरेशन को प्रबंधित करने के लिए Git पुल अनुरोधों का उपयोग करने के लिए प्रथाओं का एक सेट है। GitOps में Git रिपॉजिटरी को सिस्टम की स्थिति के बारे में जानकारी के एकल स्रोत के रूप में माना जाता है, और इस स्थिति में कोई भी परिवर्तन पूरी तरह से पता लगाने योग्य और श्रवण योग्य है।

GitOps में परिवर्तन ट्रैकिंग का विचार कोई नया नहीं है; एप्लिकेशन स्रोत कोड के साथ काम करते समय इस दृष्टिकोण का उपयोग लगभग सार्वभौमिक रूप से किया गया है। GitOps बुनियादी ढांचे और एप्लिकेशन कॉन्फ़िगरेशन प्रबंधन में समान सुविधाओं (समीक्षा, पुल अनुरोध, टैग इत्यादि) को लागू करता है और स्रोत कोड प्रबंधन के मामले में समान लाभ प्रदान करता है।

GitOps के लिए कोई अकादमिक परिभाषा या नियमों का अनुमोदित सेट नहीं है, केवल सिद्धांतों का एक सेट है जिस पर यह अभ्यास बनाया गया है:

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

GitOps सिद्धांत

• सिस्टम परिभाषाओं को स्रोत कोड के रूप में वर्णित किया गया है

सिस्टम कॉन्फ़िगरेशन को कोड के रूप में माना जाता है ताकि इसे संग्रहीत किया जा सके और स्वचालित रूप से Git रिपॉजिटरी में संस्करणित किया जा सके, जो सत्य के एकल स्रोत के रूप में कार्य करता है। यह दृष्टिकोण सिस्टम में परिवर्तनों को रोलआउट और रोलबैक करना आसान बनाता है।

• सिस्टम की वांछित स्थिति और कॉन्फ़िगरेशन Git में सेट और संस्करणित किए गए हैं

Git में सिस्टम की वांछित स्थिति को संग्रहीत और संस्करणित करके, हम सिस्टम और एप्लिकेशन में परिवर्तनों को आसानी से रोल आउट और रोल बैक करने में सक्षम हैं। हम कोड स्वामित्व को नियंत्रित करने और उसकी प्रामाणिकता को सत्यापित करने के लिए Git के सुरक्षा तंत्र का भी उपयोग कर सकते हैं।

• कॉन्फ़िगरेशन परिवर्तन स्वचालित रूप से पुल अनुरोधों के माध्यम से लागू किए जा सकते हैं

Git पुल अनुरोधों का उपयोग करके, हम आसानी से नियंत्रित कर सकते हैं कि रिपॉजिटरी में कॉन्फ़िगरेशन में परिवर्तन कैसे लागू होते हैं। उदाहरण के लिए, उन्हें समीक्षा के लिए या सीआई परीक्षण आदि के लिए टीम के अन्य सदस्यों को दिया जा सकता है।

और साथ ही, व्यवस्थापक शक्तियों को बाएँ और दाएँ वितरित करने की कोई आवश्यकता नहीं है। कॉन्फ़िगरेशन परिवर्तन करने के लिए, उपयोगकर्ताओं को केवल Git रिपॉजिटरी में उचित अनुमतियों की आवश्यकता होती है जहां वे कॉन्फ़िगरेशन संग्रहीत होते हैं।

• कॉन्फ़िगरेशन के अनियंत्रित बहाव की समस्या को ठीक करना

एक बार जब सिस्टम की वांछित स्थिति Git रिपॉजिटरी में संग्रहीत हो जाती है, तो हमें बस सॉफ्टवेयर ढूंढना है जो यह सुनिश्चित करेगा कि सिस्टम की वर्तमान स्थिति उसकी वांछित स्थिति से मेल खाती है। यदि यह मामला नहीं है, तो इस सॉफ़्टवेयर को - सेटिंग्स के आधार पर - या तो विसंगति को स्वयं समाप्त करना चाहिए, या हमें कॉन्फ़िगरेशन बहाव के बारे में सूचित करना चाहिए।

ओपनशिफ्ट के लिए GitOps मॉडल

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

इस मॉडल के अनुसार, क्लस्टर में एक नियंत्रक होता है जो क्लस्टर के वास्तविक संसाधनों के साथ Git रिपॉजिटरी में Kubernetes संसाधनों (YAML फ़ाइलों) की तुलना करने के लिए जिम्मेदार होता है। यदि विसंगतियों का पता चलता है, तो नियंत्रक सूचनाएं भेजता है और संभवतः विसंगतियों को ठीक करने के लिए कार्रवाई करता है। इस GitOps मॉडल का उपयोग एंथोस कॉन्फिग मैनेजमेंट और वीववर्क्स फ्लक्स में किया जाता है।

बाह्य संसाधन समाधानकर्ता (पुश)

इस मॉडल को पिछले मॉडल का एक रूपांतर माना जा सकता है, जब हमारे पास "गिट रिपॉजिटरी - कुबेरनेट्स क्लस्टर" जोड़े में संसाधनों को सिंक्रनाइज़ करने के लिए जिम्मेदार एक या अधिक नियंत्रक होते हैं। यहां अंतर यह है कि प्रत्येक प्रबंधित क्लस्टर का अपना अलग नियंत्रक होना जरूरी नहीं है। Git - k8s क्लस्टर जोड़े को अक्सर CRD (कस्टम संसाधन परिभाषाएँ) के रूप में परिभाषित किया जाता है, जो वर्णन कर सकता है कि नियंत्रक को सिंक्रनाइज़ेशन कैसे करना चाहिए। इस मॉडल के भीतर, नियंत्रक सीआरडी में निर्दिष्ट गिट रिपॉजिटरी की तुलना कुबेरनेट्स क्लस्टर संसाधनों से करते हैं, जो सीआरडी में भी निर्दिष्ट हैं, और तुलना के परिणामों के आधार पर उचित कार्रवाई करते हैं। विशेष रूप से, इस GitOps मॉडल का उपयोग ArgoCD में किया जाता है।

ओपनशिफ्ट प्लेटफॉर्म पर GitOps

मल्टी-क्लस्टर कुबेरनेट्स बुनियादी ढांचे का प्रशासन

कुबेरनेट्स के प्रसार और मल्टी-क्लाउड रणनीतियों और एज कंप्यूटिंग की बढ़ती लोकप्रियता के साथ, प्रति ग्राहक ओपनशिफ्ट क्लस्टर की औसत संख्या भी बढ़ रही है।

उदाहरण के लिए, एज कंप्यूटिंग का उपयोग करते समय, एक ग्राहक के क्लस्टर को सैकड़ों या हजारों में तैनात किया जा सकता है। परिणामस्वरूप, उसे सार्वजनिक क्लाउड और ऑन-प्रिमाइसेस में कई स्वतंत्र या समन्वित ओपनशिफ्ट क्लस्टर प्रबंधित करने के लिए मजबूर होना पड़ता है।

इस मामले में, बहुत सारी समस्याओं का समाधान करना होगा, विशेष रूप से:

• नियंत्रित करें कि क्लस्टर एक समान स्थिति में हैं (कॉन्फ़िगरेशन, निगरानी, ​​​​भंडारण, आदि)
• किसी ज्ञात स्थिति के आधार पर क्लस्टर को फिर से बनाएं (या पुनर्स्थापित करें)।
• ज्ञात स्थिति के आधार पर नए क्लस्टर बनाएं।
• अनेक OpenShift क्लस्टरों में परिवर्तन रोल आउट करें।
• एकाधिक ओपनशिफ्ट क्लस्टरों में परिवर्तन वापस लाएं।
• टेम्पलेटेड कॉन्फ़िगरेशन को विभिन्न परिवेशों से लिंक करें.

अनुप्रयोग विन्यास

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

इस मामले में, निम्नलिखित कार्यों को हल करना होगा:

• क्लस्टर (डेव, स्टेज, आदि) के बीच एप्लिकेशन (बाइनरिज़, कॉन्फ़िगरेशन, आदि) की आवाजाही सुनिश्चित करें।
• कई ओपनशिफ्ट क्लस्टरों में एप्लिकेशन (बाइनरिज़, कॉन्फ़िगरेशन आदि) में परिवर्तन रोल आउट करें।
• एप्लिकेशन में किए गए परिवर्तनों को पिछली ज्ञात स्थिति में वापस रोल करें।

ओपनशिफ्ट GitOps उपयोग मामले

1. Git रिपॉजिटरी से परिवर्तन लागू करना

एक क्लस्टर प्रशासक ओपनशिफ्ट क्लस्टर कॉन्फ़िगरेशन को Git रिपॉजिटरी में संग्रहीत कर सकता है और स्वचालित रूप से नए क्लस्टर बनाने के लिए उन्हें लागू कर सकता है और उन्हें Git रिपॉजिटरी में संग्रहीत ज्ञात स्थिति के समान स्थिति में ला सकता है।

2. गुप्त प्रबंधक के साथ तुल्यकालन

व्यवस्थापक को इसके लिए विशेष रूप से बनाए गए टूल का उपयोग करके उन्हें प्रबंधित करने के लिए वॉल्ट जैसे उपयुक्त सॉफ़्टवेयर के साथ ओपनशिफ्ट गुप्त वस्तुओं को सिंक्रनाइज़ करने की क्षमता से भी लाभ होगा।

3. बहाव विन्यास का नियंत्रण

व्यवस्थापक केवल तभी पक्ष में होगा यदि OpenShift GitOps स्वयं वास्तविक कॉन्फ़िगरेशन और रिपॉजिटरी में निर्दिष्ट कॉन्फ़िगरेशन के बीच विसंगतियों की पहचान करता है और चेतावनी देता है, ताकि वे बहाव पर तुरंत प्रतिक्रिया दे सकें।

4. कॉन्फ़िगरेशन बहाव के बारे में सूचनाएं

वे उस स्थिति में उपयोगी होते हैं जब प्रशासक स्वयं उचित उपाय करने के लिए कॉन्फ़िगरेशन बहाव के मामलों के बारे में शीघ्रता से जानना चाहता है।

5. बहते समय कॉन्फ़िगरेशन का मैन्युअल सिंक्रनाइज़ेशन

कॉन्फ़िगरेशन बहाव की स्थिति में व्यवस्थापक को ओपनशिफ्ट क्लस्टर को Git रिपॉजिटरी के साथ सिंक्रनाइज़ करने की अनुमति देता है, ताकि क्लस्टर को पिछली ज्ञात स्थिति में तुरंत वापस लाया जा सके।

6. बहते समय कॉन्फ़िगरेशन का ऑटो-सिंक्रनाइज़ेशन

व्यवस्थापक किसी बहाव का पता चलने पर रिपॉजिटरी के साथ स्वचालित रूप से सिंक्रनाइज़ करने के लिए ओपनशिफ्ट क्लस्टर को भी कॉन्फ़िगर कर सकता है, ताकि क्लस्टर कॉन्फ़िगरेशन हमेशा Git में कॉन्फ़िगरेशन से मेल खाए।

7. कई क्लस्टर - एक भंडार

व्यवस्थापक एक Git रिपॉजिटरी में कई अलग-अलग OpenShift क्लस्टरों के कॉन्फ़िगरेशन को संग्रहीत कर सकता है और आवश्यकतानुसार उन्हें चुनिंदा रूप से लागू कर सकता है।

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

व्यवस्थापक रिपॉजिटरी (स्टेज, प्रोड, ऐप पोर्टफोलियो, आदि विरासत के साथ) में क्लस्टर कॉन्फ़िगरेशन का पदानुक्रम सेट कर सकता है। दूसरे शब्दों में, यह निर्धारित कर सकता है कि कॉन्फ़िगरेशन को एक या अधिक क्लस्टर पर लागू किया जाना चाहिए या नहीं।

उदाहरण के लिए, यदि कोई व्यवस्थापक Git रिपॉजिटरी में पदानुक्रम "प्रोडक्शन क्लस्टर्स (प्रोड) → सिस्टम

• सभी उत्पादन समूहों के लिए सामान्य कॉन्फ़िगरेशन।
• सिस्टम X क्लस्टर के लिए कॉन्फ़िगरेशन।
• एक्स सिस्टम उत्पादन क्लस्टर के लिए कॉन्फ़िगरेशन।

9. टेम्प्लेट और कॉन्फ़िगरेशन ओवरराइड होते हैं

व्यवस्थापक विरासत में मिली कॉन्फ़िगरेशन और उनके मानों के एक सेट को ओवरराइड कर सकता है, उदाहरण के लिए, उन विशिष्ट समूहों के लिए कॉन्फ़िगरेशन को ठीक करने के लिए जिन पर उन्हें लागू किया जाएगा।

10. कॉन्फ़िगरेशन, एप्लिकेशन कॉन्फ़िगरेशन के लिए चयनात्मक शामिल करें और बहिष्कृत करें

व्यवस्थापक कुछ विशेषताओं वाले क्लस्टरों पर कुछ कॉन्फ़िगरेशन के अनुप्रयोग या गैर-अनुप्रयोग के लिए शर्तें निर्धारित कर सकता है।

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

प्रत्येक विशिष्ट एप्लिकेशन के लिए सबसे उपयुक्त प्रारूप का उपयोग करने के लिए डेवलपर्स को यह चुनने की क्षमता से लाभ होगा कि एप्लिकेशन संसाधनों को कैसे परिभाषित किया जाएगा (हेल्म चार्ट, शुद्ध कुबेरनेट्स yaml, आदि)।

OpenShift प्लेटफ़ॉर्म पर GitOps उपकरण

आर्गोसीडी

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}')

ArgoCD सर्वर में सुधार ताकि इसे ओपनशिफ्ट रूट द्वारा देखा जा सके

# 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 - कभी भी देर नहीं होती

"ट्रेन निकल गई है" - यही वे उस स्थिति के बारे में कहते हैं जब कुछ करने का अवसर चूक जाता है। ओपनशिफ्ट के मामले में, इस शानदार नए प्लेटफॉर्म का तुरंत उपयोग शुरू करने की इच्छा अक्सर मार्गों, तैनाती और अन्य ओपनशिफ्ट ऑब्जेक्ट्स के प्रबंधन और रखरखाव के साथ बिल्कुल यही स्थिति पैदा करती है। लेकिन क्या मौका हमेशा पूरी तरह चूक जाता है?

के बारे में लेखों की शृंखला जारी है 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 रिपॉजिटरी बनाएं।
• हम अपनी वर्तमान वस्तुओं को निर्यात करते हैं और उन्हें Git रिपॉजिटरी में अपलोड करते हैं।
• GitOps टूल का चयन और तैनाती।
• हम इस टूलकिट में अपना भंडार जोड़ते हैं।
• हम अपने GitOps टूलकिट में एप्लिकेशन को परिभाषित करते हैं।
• हम GitOps टूलकिट का उपयोग करके एप्लिकेशन का परीक्षण चलाते हैं।
• हम GitOps टूलकिट का उपयोग करके ऑब्जेक्ट को सिंक्रोनाइज़ करते हैं।
• वस्तुओं की छंटाई और ऑटो-सिंक्रनाइज़ेशन सक्षम करें।

जैसा कि पिछले में बताया गया है लेख, GitOps में Kubernetes क्लस्टर में सभी ऑब्जेक्ट के बारे में जानकारी का एक और केवल एक ही स्रोत है - Git रिपॉजिटरी। इसके बाद, हम इस आधार पर आगे बढ़ते हैं कि आपका संगठन पहले से ही Git रिपॉजिटरी का उपयोग करता है। यह सार्वजनिक या निजी हो सकता है, लेकिन इसे कुबेरनेट्स समूहों तक पहुंच योग्य होना चाहिए। यह एप्लिकेशन कोड के समान ही रिपॉजिटरी हो सकता है, या तैनाती के लिए विशेष रूप से बनाई गई एक अलग रिपॉजिटरी हो सकती है। रिपॉजिटरी में सख्त अनुमतियाँ रखने की अनुशंसा की जाती है क्योंकि रहस्य, मार्ग और अन्य सुरक्षा-संवेदनशील चीजें वहां संग्रहीत की जाएंगी।

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

यदि YAML ऑब्जेक्ट फ़ाइलें स्थानीय रूप से या Git में संग्रहीत नहीं थीं, तो आपको oc या kubectl बायनेरिज़ का उपयोग करना होगा। नीचे दिए गए स्क्रीनशॉट में हम अपने नामस्थान, परिनियोजन, सेवा और मार्ग के लिए 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

आइए अब उस फ़ील्ड को हटाने के लिए परिनियोजन.yaml फ़ाइल को संपादित करें जिसे Argo CD सिंक नहीं कर सकता है।

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

इसके अलावा रूट भी बदलना होगा. हम पहले एक मल्टीलाइन वेरिएबल सेट करेंगे और फिर उस वेरिएबल की सामग्री के साथ ingress: null को प्रतिस्थापित करेंगे।

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 तैनात कर दिया है (यह कैसे करें - पिछला देखें पद). इसलिए, हम अर्गो सीडी में हमारे द्वारा बनाए गए रिपॉजिटरी को जोड़ देंगे, जिसमें हमारे उदाहरण से एप्लिकेशन कोड शामिल होगा। बस यह सुनिश्चित करें कि आपने वही सटीक रिपॉजिटरी निर्दिष्ट की है जो आपने पहले बनाई थी।

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

अब एप्लिकेशन बनाते हैं। एप्लिकेशन मान सेट करता है ताकि GitOps टूलकिट समझ सके कि किस रिपॉजिटरी और पथ का उपयोग करना है, ऑब्जेक्ट्स को प्रबंधित करने के लिए किस ओपनशिफ्ट की आवश्यकता है, रिपॉजिटरी की किस विशिष्ट शाखा की आवश्यकता है, और क्या संसाधनों को ऑटो-सिंक करना चाहिए।

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