आज हम GitOps के सिद्धांतों और मॉडलों के बारे में बात करेंगे, साथ ही साथ ये मॉडल OpenShift प्लेटफॉर्म पर कैसे लागू किए जाएंगे। इस विषय के लिए एक ऑनलाइन गाइड
यहाँ उपलब्ध
है ।
संक्षेप में, GitOps अवसंरचना और अनुप्रयोग कॉन्फ़िगरेशन को प्रबंधित करने के लिए Git पुल अनुरोधों का उपयोग करने के लिए व्यावहारिक तरीकों का एक सेट है। GitOps के भीतर Git रिपॉजिटरी को सिस्टम की स्थिति के बारे में जानकारी का एक एकल स्रोत माना जाता है, और इस राज्य में किसी भी बदलाव की पूरी निगरानी और ऑडिट किया जाता है।
GitOps में परिवर्तन पर नज़र रखने का विचार किसी भी तरह से नया नहीं है, यह दृष्टिकोण लंबे समय से लगभग हर जगह उपयोग किया गया है जब एप्लिकेशन स्रोत कोड के साथ काम कर रहा है। इन्फ्रास्ट्रक्चर और एप्लिकेशन कॉन्फ़िगरेशन को प्रबंधित करते समय GitOps समान फ़ंक्शन (समीक्षा चेक, पुल अनुरोध, टैग, आदि) को लागू करता है और स्रोत कोड प्रबंधन के मामले में समान लाभ प्रदान करता है।
GitOps के लिए, कोई शैक्षणिक परिभाषा या नियमों का स्वीकृत सेट नहीं है, केवल उन सिद्धांतों का एक सेट है जिन पर यह अभ्यास आधारित है:
- सिस्टम का घोषणात्मक विवरण गिट रिपॉजिटरी (कॉन्फ़िगरेशन, निगरानी, आदि) में संग्रहीत है।
- राज्य परिवर्तन पुल अनुरोधों के माध्यम से किए जाते हैं।
- रनिंग सिस्टम की स्थिति गिट पुश अनुरोधों का उपयोग करके रिपॉजिटरी में डेटा के साथ संरेखित की जाती है।
GitOps सिद्धांत
- सिस्टम परिभाषाओं को स्रोत कोड के रूप में वर्णित किया गया है।
सिस्टम कॉन्फ़िगरेशन को कोड माना जाता है, इसलिए इसे Git रिपॉजिटरी में स्वचालित रूप से संग्रहीत और संग्रहीत किया जा सकता है, जो सत्य का एकमात्र स्रोत है। यह दृष्टिकोण सिस्टम के लिए रोलआउट और रोलबैक परिवर्तन को आसान बनाता है।
- वांछित स्थिति और सिस्टम कॉन्फ़िगरेशन Git में सेट और संस्करण किए गए हैं
सिस्टम की इच्छित स्थिति को संग्रहीत और संस्करणित करके, हम सिस्टम और अनुप्रयोगों में आसानी से परिवर्तन और रोल बैक करने की क्षमता प्राप्त करते हैं। हम कोड स्वामित्व को नियंत्रित करने और इसकी प्रामाणिकता को सत्यापित करने के लिए Git के सुरक्षा तंत्र का उपयोग कर सकते हैं।
- कॉन्फ़िगरेशन परिवर्तन पुल अनुरोधों का उपयोग करके स्वचालित रूप से लागू किया जा सकता है।
Git पुल अनुरोधों का उपयोग करते हुए, हम आसानी से नियंत्रित कर सकते हैं कि रिपॉजिटरी में कॉन्फ़िगरेशन पर कैसे परिवर्तन लागू होते हैं। उदाहरण के लिए, उन्हें अन्य टीम के सदस्यों के सत्यापन के लिए भेजा जा सकता है या CI परीक्षण आदि के माध्यम से चलाया जा सकता है।
और साथ ही साथ आपको दायें और बायें को व्यवस्थापन अधिकार देने की आवश्यकता नहीं है। कॉन्फ़िगरेशन परिवर्तन करने के लिए, उपयोगकर्ताओं के पास Git रिपॉज़िटरी में पर्याप्त अनुमतियाँ हैं जहाँ ये कॉन्फ़िगरेशन संग्रहीत हैं।
- अनियंत्रित बहाव विन्यास ठीक करें
जब सिस्टम के वांछित राज्य को गिट रिपॉजिटरी में संग्रहीत किया जाता है, तो हम केवल सॉफ्टवेयर खोज सकते हैं जो यह नियंत्रित करेगा कि सिस्टम की वर्तमान स्थिति उसकी इच्छित स्थिति से मेल खाती है। यदि ऐसा नहीं है, तो यह सॉफ़्टवेयर चाहिए - सेटिंग्स के आधार पर - या तो स्वयं विसंगति को ठीक करें या हमें कॉन्फ़िगरेशन बहाव की सूचना दें।
ओपनशिप के लिए GitOps मॉडल
ऑन-क्लस्टर संसाधन रीकंसीलर
इस मॉडल के अनुसार, क्लस्टर में एक नियंत्रक होता है जो वास्तविक क्लस्टर संसाधनों के साथ गिट रिपॉजिटरी में कुबेरनेट्स संसाधनों (YAML फाइलें) की तुलना करने के लिए जिम्मेदार होता है। विसंगतियों के मामले में, नियंत्रक सूचनाओं को भेजता है और संभवतः, विसंगतियों को खत्म करने के लिए उपाय करता है। इस GitOps मॉडल का उपयोग एंथोस कॉन्फिग मैनेजमेंट और वीवर्सवर्क्स फ्लक्स द्वारा किया जाता है।
बाहरी संसाधन रीकंसीलर (पुश)
इस मॉडल को पिछले एक की भिन्नता के रूप में माना जा सकता है, जब हमारे पास "गीट रिपॉजिटरी - कुबेरनेट्स क्लस्टर" जोड़े में संसाधनों को सिंक्रनाइज़ करने के लिए जिम्मेदार एक या अधिक नियंत्रक हैं। यहाँ अंतर यह है कि प्रत्येक प्रबंधित क्लस्टर का अपना अलग नियंत्रक नहीं होता है। Git - k8s क्लस्टर जोड़े को अक्सर कस्टम संसाधन परिभाषा CRD के रूप में परिभाषित किया जाता है, जो वर्णन करता है कि नियंत्रक को सिंक्रनाइज़ेशन कैसे करना चाहिए। इस मॉडल के भीतर, नियंत्रक CRD में निर्दिष्ट Git रिपॉजिटरी की तुलना Kubernetes क्लस्टर के संसाधनों से करते हैं, जिन्हें CRD में भी परिभाषित किया गया है, और तुलना के परिणामों के आधार पर संबंधित क्रिया करते हैं। विशेष रूप से, इस तरह के एक GitOps मॉडल का उपयोग ArgoCD में किया जाता है।
OpenShift प्लेटफ़ॉर्म पर GitOps
मल्टीक्लस्टर कुबेरनेट्स इन्फ्रास्ट्रक्चर एडमिनिस्ट्रेशन
कुबेरनेट्स के प्रसार और बहु-क्लाउड रणनीतियों और एज कंप्यूटिंग की बढ़ती लोकप्रियता के साथ, प्रति ग्राहक ओपनशिफ्ट क्लस्टर्स की औसत संख्या में भी वृद्धि हुई है।
उदाहरण के लिए, परिधीय कंप्यूटिंग का उपयोग करते समय, एकल ग्राहक के समूहों को सैकड़ों या हजारों में तैनात किया जा सकता है। नतीजतन, वह सार्वजनिक क्लाउड और ऑन-प्रिमाइस में कई स्वतंत्र या समन्वित ओपनशिफ्ट समूहों का प्रबंधन करने के लिए मजबूर है।
एक ही समय में, कई समस्याओं का हल करना होगा, विशेष रूप से:
- यह नियंत्रित करने के लिए कि क्लस्टर समान स्थिति में हैं (विन्यास, निगरानी, भंडारण, आदि)
- एक ज्ञात स्थिति के अनुसार क्लस्टर फिर से बनाएं (या पुनर्स्थापित करें)।
- एक ज्ञात स्थिति के अनुसार नए क्लस्टर बनाएं।
- कई OpenShift समूहों पर परिवर्तन खींचो।
- कई OpenShift समूहों में परिवर्तन वापस करें।
- लिंक अलग वातावरण के साथ संरचित विन्यास।
अनुप्रयोग कॉन्फ़िगरेशन
अपने जीवन चक्र के दौरान, उत्पादन क्लस्टर में आने से पहले, आवेदन अक्सर क्लस्टर (देव, मंच, आदि) की एक श्रृंखला से गुजरते हैं। इसके अलावा, उपलब्धता और स्केलेबिलिटी आवश्यकताओं के कारण, ग्राहक अक्सर कई ऑन-प्रिमाइसेस क्लस्टर्स पर या एक सार्वजनिक क्लाउड प्लेटफ़ॉर्म के कई क्षेत्रों में एप्लिकेशन को तैनात करते हैं।
इस मामले में, निम्नलिखित समस्याओं को हल करना आवश्यक है:
- समूहों (देव, मंच, आदि) के बीच अनुप्रयोगों (बायनेरिज़, कॉन्फ़िगर आदि) की गति सुनिश्चित करें।
- कई OpenShift क्लस्टर्स में एप्लिकेशन (बायनेरिज़, कॉन्फ़िगर आदि) में परिवर्तन रोल करें।
- अनुप्रयोगों में पिछले ज्ञात स्थिति के स्तर तक रोल बैक परिवर्तन।
OpenShift GitOps उपयोग परिदृश्य
1. गिट रिपॉजिटरी से परिवर्तन लागू करें
क्लस्टर व्यवस्थापक Git रिपॉजिटरी में OpenShift क्लस्टर कॉन्फ़िगरेशन को संग्रहीत कर सकता है और स्वचालित रूप से बिना किसी अतिरिक्त प्रयास के नए क्लस्टर बनाने के लिए उन्हें लागू कर सकता है और उन्हें Git रिपॉजिटरी में संग्रहीत ज्ञात स्थिति के समान स्थिति में ला सकता है।
2. सीक्रेट मैनेजर के साथ सिंक करें
व्यवस्थापक को इसके लिए विशेष रूप से बनाए गए टूल का उपयोग करके उन्हें प्रबंधित करने के लिए वॉल्ट जैसे उपयुक्त सॉफ़्टवेयर के साथ ओपनशिफ्ट गुप्त वस्तुओं को सिंक्रनाइज़ करने के लिए उपयोगी होगा।
3. नियंत्रण बहाव विन्यास
व्यवस्थापक केवल उस पक्ष में होगा जब OpenSift GitOps वास्तविक कॉन्फ़िगरेशन और रिपॉजिटरी में निर्दिष्ट लोगों के बीच विसंगतियों के बारे में पता लगाएगा और चेतावनी देगा, ताकि आप जल्दी से बहाव का जवाब दे सकें।
4. विन्यास बहाव सूचनाएं
यह तब काम आएगा जब व्यवस्थापक जल्दी से अपने दम पर उचित उपाय करने के लिए बहाव कॉन्फ़िगरेशन के बारे में पता लगाना चाहता है।
5. बहते समय कॉन्फ़िगरेशन का मैनुअल सिंक्रनाइज़ेशन
व्यवस्थापक को बहाव कॉन्फ़िगरेशन के मामले में गेट रिपॉजिटरी के साथ ओपनशिफ्ट क्लस्टर को सिंक्रनाइज़ करने की अनुमति देता है ताकि क्लस्टर को पिछली ज्ञात स्थिति में जल्दी से लौटाया जा सके।
6. बहाव के विन्यास का ऑटो-सिंक्रोनाइज़ेशन
व्यवस्थापक ओपनशिफ्ट क्लस्टर को ड्रिफ्ट का पता चलने पर रिपॉजिटरी के साथ स्वचालित रूप से सिंक्रनाइज़ करने के लिए कॉन्फ़िगर कर सकता है, ताकि क्लस्टर कॉन्फ़िगरेशन हमेशा गिट में कॉन्फ़िगरेशन से मेल खाता हो।
7. एकाधिक क्लस्टर - एक रिपॉजिटरी
व्यवस्थापक कई अलग OpenShift समूहों के कॉन्फ़िगरेशन को एक Git रिपॉजिटरी में संग्रहीत कर सकते हैं और उन्हें आवश्यकतानुसार चुन सकते हैं।
8. क्लस्टर विन्यास (वंशानुक्रम) की पदानुक्रम
व्यवस्थापक रिपॉजिटरी (चरण, ठेस, ऐप पोर्टफोलियो, इनहेरिटेंस के साथ आदि) में क्लस्टर कॉन्फ़िगरेशन के पदानुक्रम सेट कर सकता है। दूसरे शब्दों में, यह निर्धारित कर सकता है कि विन्यास कैसे लागू किया जाना चाहिए - एक या कई समूहों में।
उदाहरण के लिए, यदि व्यवस्थापक गिट रिपॉजिटरी में पदानुक्रम "प्रोडक्शन क्लस्टर्स (सिस्टम) → सिस्टम एक्स के क्लस्टर → सिस्टम एक्स के प्रोडक्शन क्लस्टर" को परिभाषित करता है, तो सिस्टम एक्स के उत्पादन क्लस्टर्स पर निम्नलिखित कॉन्फिगरेशन लागू होते हैं।
- सभी उत्पादन समूहों के लिए आम पुष्टि करता है।
- क्लस्टर सिस्टम X के लिए कन्फ़िगल्स।
- सिस्टम X के उत्पादन क्लस्टर के लिए पुष्टि करता है।
9. पैटर्न और कॉन्फ़िगरेशन ओवरराइड करता है
प्रशासक विरासत में मिले कॉन्फ़िगरेशन और उनके मूल्यों के सेट को ओवरराइड कर सकता है, उदाहरण के लिए, विशिष्ट समूहों के लिए कॉन्फ़िगरेशन को ठीक करने के लिए, जिस पर उन्हें लागू किया जाएगा।
10. विन्यास, अनुप्रयोग विन्यास के लिए चयनात्मक शामिल'य और बहिष्कृत हैं
व्यवस्थापक कुछ विशेषताओं के साथ क्लस्टर में कुछ कॉन्फ़िगरेशन लागू करने या नहीं करने के लिए शर्तें सेट कर सकता है।
11. पैटर्न का समर्थन
डेवलपर्स को यह चुनना उपयोगी होगा कि प्रत्येक विशिष्ट एप्लिकेशन के लिए सबसे उपयुक्त प्रारूप का उपयोग करने के लिए एप्लिकेशन संसाधनों को कैसे निर्धारित किया जाएगा (हेल्म चार्ट, शुद्ध कुबेरनेट्स यमल, आदि)।
OpenShift प्लेटफ़ॉर्म पर GitOps टूल
ArgoCD
ArgoCD बाहरी संसाधन सुलह मॉडल को लागू करता है और एक-से-कई फैशन में समूहों और गिट रिपॉजिटरी के बीच आर्केस्ट्रा संबंधों के लिए एक केंद्रीकृत यूआई प्रदान करता है। इस कार्यक्रम के नुकसान में अनुप्रयोगों को प्रबंधित करने की अक्षमता शामिल है जबकि 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}')
OpenShift मार्ग द्वारा देखे जाने वाले 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 Tool को तैनात करें
# 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 रिपॉजिटरी बनाएं।
- हम अपनी वर्तमान वस्तुओं को निर्यात करते हैं और उन्हें गिट रिपॉजिटरी में लोड करते हैं।
- चुनें और GitOps टूलकिट परिनियोजित करें।
- इस टूलकिट में हमारी रिपॉजिटरी जोड़ें।
- हम अपने GitOps टूलकिट में एप्लिकेशन को परिभाषित करते हैं।
- GitOps टूलकिट का उपयोग करके एप्लिकेशन का ट्रायल रन करें।
- हम GitOps टूलकिट का उपयोग करके वस्तुओं को सिंक्रनाइज़ करते हैं।
- हम वस्तुओं के छंटाई और ऑटो-सिंक्रनाइज़ेशन को चालू करते हैं।
जैसा कि पिछले
लेख में बताया गया है, GitOps में Kubernetes क्लस्टर (s) में सभी वस्तुओं के बारे में जानकारी का एक और केवल एक स्रोत है - Git रिपॉजिटरी। इसके अलावा, हम इस आधार पर आगे बढ़ते हैं कि आपका संगठन पहले ही Git रिपॉजिटरी का उपयोग करता है। यह सार्वजनिक या निजी हो सकता है, लेकिन यह कुबेरनेट्स समूहों के लिए उपलब्ध होना चाहिए। यह एप्लीकेशन कोड के लिए एक ही रिपॉजिटरी हो सकता है, या विशेष रूप से तैनाती के लिए बनाया गया एक अलग रिपॉजिटरी। यह अनुशंसा की जाती है कि आपके पास भंडार में सख्त अनुमति है, क्योंकि गुप्त वस्तुएं, मार्ग, और अन्य सुरक्षा-संवेदनशील चीजें वहां संग्रहीत की जाएंगी।
हमारे उदाहरण में, हम GitHub पर एक नया सार्वजनिक भंडार बनाएंगे। आप इसे जो चाहें नाम दे सकते हैं, हम ब्लॉगपोस्ट नाम का उपयोग करते हैं।
यदि ऑब्जेक्ट्स की YAML फ़ाइलें स्थानीय या Git में संग्रहीत नहीं की गई थीं, तो आपको महासागर या क्यूबेकल बायनेरिज़ का उपयोग करना होगा। नीचे स्क्रीनशॉट में, हम अपने नाम स्थान, तैनाती, सेवा और मार्ग के लिए 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
इसके अलावा, आपको मार्ग बदलने की आवश्यकता है। हम पहले मल्टीलाइन वेरिएबल को सेट करेंगे, और फिर इनग्रेस को रिप्लेस करेंगे: इस वेरिएबल की सामग्री के साथ।
export ROUTE=" ingress:\\ - conditions:\\ - status: 'True'\\ type: Admitted" sed -i "s/ ingress: null/$ROUTE/g" route.yaml
इसलिए, फ़ाइलों की छंटनी के साथ, यह उन्हें गिट रिपॉजिटरी में सहेजने के लिए रहता है। उसके बाद, यह रिपॉजिटरी सूचना का एकमात्र स्रोत बन जाता है, और ऑब्जेक्ट्स में किसी भी मैनुअल परिवर्तन को सख्ती से प्रतिबंधित किया जाना चाहिए।
git commit -am 'initial commit of objects' git push origin master
इसके अलावा, हम इस तथ्य से आगे बढ़ते हैं कि अर्गोसीडी आपके लिए पहले से ही तैनात है (यह कैसे करें, पिछली
पोस्ट देखें)। इसलिए, हम 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
अर्गो सीडी में आवेदन निर्दिष्ट किए जाने के बाद, यह टूलकिट रिपॉजिटरी में परिभाषाओं के अनुपालन के लिए पहले से ही तैनात वस्तुओं की जांच करना शुरू कर देता है। हमारे उदाहरण में, ऑटो-सिंक और क्लीनअप अक्षम हैं, इसलिए तत्व अभी तक नहीं बदलते हैं। कृपया ध्यान दें कि अर्गो सीडी इंटरफ़ेस में, हमारे आवेदन में "आउट ऑफ सिंक" (सिंक्रनाइज़ नहीं) की स्थिति होगी, क्योंकि कोई लेबल टैग नहीं है जो कि ArgoCD को चिपकाता है।
इसीलिए, जब हम थोड़ी देर बाद सिंक्रोनाइजेशन शुरू करते हैं, तो ऑब्जेक्ट्स की रिडिपॉर्समेंट नहीं की जाएगी।
अब यह सुनिश्चित करने के लिए एक परीक्षण चलाएं कि हमारी फ़ाइलों में कोई त्रुटि नहीं है।
argocd app sync simple-app --dry-run
यदि कोई त्रुटि नहीं है, तो आप सिंक्रनाइज़ेशन के लिए आगे बढ़ सकते हैं।
argocd app sync simple-app
हमारे आवेदन पर कमांड मिलने के बाद, हमें देखना चाहिए कि आवेदन की स्थिति स्वस्थ या सिंक हो गई है। इसका अर्थ यह होगा कि गिट रिपॉजिटरी में सभी संसाधन अब उन संसाधनों के अनुरूप हैं जो पहले से ही तैनात हैं।
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 का उपयोग नहीं करता था।