OpenShift को लागी GitOps को परिचय

आज हामी GitOps को सिद्धान्त र मोडेलहरूको बारेमा कुरा गर्नेछौं, साथै कसरी यी मोडेलहरू OpenShift प्लेटफर्ममा लागू गरिन्छ। यस विषयमा अन्तरक्रियात्मक गाइड उपलब्ध छ लिङ्क.

संक्षेपमा, GitOps पूर्वाधार र अनुप्रयोग कन्फिगरेसनहरू प्रबन्ध गर्न Git पुल अनुरोधहरू प्रयोग गर्ने अभ्यासहरूको सेट हो। GitOps मा Git भण्डारलाई प्रणालीको अवस्थाको बारेमा जानकारीको एकल स्रोतको रूपमा व्यवहार गरिन्छ, र यस अवस्थामा कुनै पनि परिवर्तनहरू पूर्ण रूपमा ट्रेस योग्य र अडिट योग्य छन्।

GitOps मा परिवर्तन ट्र्याकिङ को विचार कुनै पनि हिसाबले नयाँ छैन; यो दृष्टिकोण लामो समय देखि लगभग विश्वव्यापी रूपमा प्रयोग गरिएको छ जब अनुप्रयोग स्रोत कोड संग काम गर्दछ। GitOps ले केवल पूर्वाधार र अनुप्रयोग कन्फिगरेसन व्यवस्थापनमा समान सुविधाहरू (समीक्षाहरू, पुल अनुरोधहरू, ट्यागहरू, आदि) लागू गर्दछ र स्रोत कोड व्यवस्थापनको मामलामा समान फाइदाहरू प्रदान गर्दछ।

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

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

GitOps सिद्धान्तहरू

• प्रणाली परिभाषा स्रोत कोड रूपमा वर्णन गरिएको छ

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

• वांछित राज्य र प्रणालीहरूको कन्फिगरेसन Git मा सेट र संस्करण गरिएको छ

Git मा प्रणालीहरूको इच्छित अवस्था भण्डारण र संस्करण गरेर, हामी सजिलैसँग रोल आउट गर्न र प्रणाली र अनुप्रयोगहरूमा परिवर्तनहरू रोल ब्याक गर्न सक्षम छौं। हामी कोडको स्वामित्व नियन्त्रण गर्न र यसको प्रामाणिकता प्रमाणित गर्न Git को सुरक्षा संयन्त्रहरू पनि प्रयोग गर्न सक्छौं।

• कन्फिगरेसन परिवर्तनहरू पुल अनुरोधहरू मार्फत स्वचालित रूपमा लागू गर्न सकिन्छ

Git पुल अनुरोधहरू प्रयोग गरेर, हामी सजिलैसँग भण्डारमा कन्फिगरेसनहरूमा कसरी परिवर्तनहरू लागू गरिन्छ भनेर नियन्त्रण गर्न सक्छौं। उदाहरणका लागि, तिनीहरू अन्य टोली सदस्यहरूलाई समीक्षाको लागि वा CI परीक्षणहरू, आदि मार्फत चलाउन दिन सकिन्छ।

र एकै समयमा, बायाँ र दायाँ प्रशासन शक्तिहरू वितरण गर्न आवश्यक छैन। कन्फिगरेसन परिवर्तनहरू गर्न, प्रयोगकर्ताहरूलाई केवल Git भण्डारमा उपयुक्त अनुमतिहरू चाहिन्छ जहाँ ती कन्फिगरेसनहरू भण्डारण गरिन्छ।

• कन्फिगरेसनहरूको अनियन्त्रित बहावको समस्या समाधान गर्दै

एकपटक प्रणालीको वांछित अवस्था Git भण्डारमा भण्डारण भएपछि, हामीले गर्नुपर्ने भनेको सफ्टवेयर फेला पार्नु हो जसले यो सुनिश्चित गर्दछ कि प्रणालीको हालको अवस्था यसको इच्छित अवस्थासँग मेल खान्छ। यदि यो मामला होइन भने, तब यो सफ्टवेयरले - सेटिङहरूमा निर्भर गर्दछ - कि त आफैंमा विसंगति हटाउनुहोस्, वा कन्फिगरेसन बहावको बारेमा हामीलाई सूचित गर्नुहोस्।

OpenShift को लागि GitOps मोडेलहरू

अन-क्लस्टर रिसोर्स रिकन्सिलर

यस मोडेलका अनुसार, क्लस्टरसँग एक नियन्त्रक छ जुन क्लस्टरको वास्तविक स्रोतहरूसँग Git भण्डारमा Kubernetes स्रोतहरू (YAML फाइलहरू) तुलना गर्न जिम्मेवार छ। यदि विसंगतिहरू पत्ता लगाइयो भने, नियन्त्रकले सूचनाहरू पठाउँछ र सम्भवतः भिन्नताहरू सच्याउनको लागि कारबाही गर्छ। यो GitOps मोडेल एन्थोस कन्फिग व्यवस्थापन र Weaveworks फ्लक्स मा प्रयोग गरिन्छ।

बाह्य स्रोत मेलमिलापकर्ता (पुश)

यस मोडेललाई अघिल्लोको भिन्नताको रूपमा मान्न सकिन्छ, जब हामीसँग "Git भण्डार - Kubernetes क्लस्टर" जोडीहरूमा स्रोतहरू सिङ्क्रोनाइज गर्न जिम्मेवार एक वा बढी नियन्त्रकहरू छन्। यहाँ भिन्नता यो हो कि प्रत्येक व्यवस्थित क्लस्टरको आफ्नै छुट्टै नियन्त्रक हुनु आवश्यक छैन। Git - k8s क्लस्टर जोडीहरू प्राय: CRDs (अनुकूल स्रोत परिभाषाहरू) को रूपमा परिभाषित गरिन्छ, जसले नियन्त्रकले कसरी सिङ्क्रोनाइजेसन प्रदर्शन गर्नुपर्छ भनेर वर्णन गर्न सक्छ। यस मोडेल भित्र, नियन्त्रकहरूले CRD मा निर्दिष्ट Git भण्डारलाई Kubernetes क्लस्टर स्रोतहरूसँग तुलना गर्छन्, जुन CRD मा पनि निर्दिष्ट गरिएको छ, र तुलनाको नतिजाहरूमा आधारित उपयुक्त कार्यहरू प्रदर्शन गर्दछ। विशेष गरी, यो GitOps मोडेल ArgoCD मा प्रयोग गरिन्छ।

OpenShift प्लेटफर्ममा GitOps

बहु-क्लस्टर Kubernetes पूर्वाधार को प्रशासन

Kubernetes को प्रसार र बहु-क्लाउड रणनीति र किनारा कम्प्युटिङ को बढ्दो लोकप्रियता संग, प्रति ग्राहक OpenShift क्लस्टर को औसत संख्या पनि बढ्दै छ।

उदाहरणका लागि, एज कम्प्युटिङ प्रयोग गर्दा, एक ग्राहकको क्लस्टरहरू सयौं वा हजारौंमा तैनाथ गर्न सकिन्छ। नतिजाको रूपमा, उनी सार्वजनिक क्लाउड र अन-प्रिमाइसमा धेरै स्वतन्त्र वा समन्वयित ओपनशिफ्ट क्लस्टरहरू व्यवस्थापन गर्न बाध्य छन्।

यस अवस्थामा, धेरै समस्याहरू समाधान गर्न आवश्यक छ, विशेष गरी:

• नियन्त्रण गर्नुहोस् कि क्लस्टरहरू समान अवस्थामा छन् (कन्फिग, निगरानी, ​​भण्डारण, आदि)
• ज्ञात स्थितिमा आधारित क्लस्टरहरू पुन: सिर्जना गर्नुहोस् (वा पुनर्स्थापना गर्नुहोस्)।
• ज्ञात राज्यमा आधारित नयाँ क्लस्टरहरू सिर्जना गर्नुहोस्।
• धेरै OpenShift क्लस्टरहरूमा परिवर्तनहरू रोल आउट गर्नुहोस्।
• धेरै OpenShift क्लस्टरहरूमा परिवर्तनहरू रोल ब्याक गर्नुहोस्।
• टेम्प्लेट गरिएका कन्फिगरेसनहरूलाई विभिन्न वातावरणहरूमा लिङ्क गर्नुहोस्।

आवेदन कन्फिगरेसनहरू

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

यस अवस्थामा, निम्न कार्यहरू समाधान गर्नुपर्छ:

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

OpenShift GitOps प्रयोग केसहरू

1. Git भण्डारबाट परिवर्तनहरू लागू गर्दै

एक क्लस्टर प्रशासकले Git भण्डारमा OpenShift क्लस्टर कन्फिगरेसनहरू भण्डारण गर्न सक्छ र तिनीहरूलाई स्वचालित रूपमा नयाँ क्लस्टरहरू सिर्जना गर्न र Git भण्डारमा भण्डार गरिएको ज्ञात राज्यको समान स्थितिमा ल्याउन लागू गर्न सक्छ।

2. गोप्य प्रबन्धक संग सिंक्रोनाइजेसन

यसका लागि विशेष रूपमा सिर्जना गरिएका उपकरणहरू प्रयोग गरेर व्यवस्थापन गर्नका लागि उपयुक्त सफ्टवेयर जस्तै भल्टसँग OpenShift गोप्य वस्तुहरू सिङ्क्रोनाइज गर्ने क्षमताबाट प्रशासकले पनि लाभ उठाउनेछ।

3. बहाव कन्फिगरेसनहरूको नियन्त्रण

यदि OpenShift GitOps ले वास्तविक कन्फिगरेसनहरू र भण्डारमा निर्दिष्ट गरिएका बीचको भिन्नताहरू पहिचान गर्दछ र चेतावनी दिन्छ भने प्रशासक मात्र पक्षमा हुनेछन्, ताकि तिनीहरूले द्रुत रूपमा बहावमा प्रतिक्रिया दिन सक्छन्।

4. कन्फिगरेसन बहाव बारे सूचनाहरू

तिनीहरू त्यस अवस्थामा उपयोगी हुन्छन् जब प्रशासकले कन्फिगरेसन बहावको केसहरूको बारेमा चाँडै जान्न चाहन्छ ताकि छिट्टै आफैंमा उपयुक्त उपायहरू लिनको लागि।

5. बहाव गर्दा कन्फिगरेसनहरूको म्यानुअल सिङ्क्रोनाइजेसन

कन्फिगरेसन बहावको घटनामा, क्लस्टरलाई अघिल्लो ज्ञात स्थितिमा द्रुत रूपमा फर्काउनको लागि, Git भण्डारसँग OpenShift क्लस्टर सिङ्क्रोनाइज गर्न प्रशासकलाई अनुमति दिन्छ।

6. बहिरा हुँदा कन्फिगरेसनहरूको स्वत: सिंक्रोनाइजेसन

प्रशासकले पनि ओपनशिफ्ट क्लस्टर कन्फिगर गर्न सक्छ भण्डारसँग स्वचालित रूपमा सिङ्क्रोनाइज गर्नको लागि जब एक बहाव पत्ता लगाइन्छ, ताकि क्लस्टर कन्फिगरेसन सधैं Git मा कन्फिगरेसनसँग मेल खान्छ।

7. धेरै क्लस्टरहरू - एउटा भण्डार

प्रशासकले एक Git भण्डारमा धेरै फरक OpenShift क्लस्टरहरूको कन्फिगरेसनहरू भण्डारण गर्न सक्छ र आवश्यक रूपमा तिनीहरूलाई छनौट रूपमा लागू गर्न सक्छ।

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

प्रशासकले भण्डारमा क्लस्टर कन्फिगरेसनहरूको पदानुक्रम सेट गर्न सक्छ (स्टेज, प्रोड, एप पोर्टफोलियो, आदि। इनहेरिटेन्सको साथ)। अर्को शब्दमा, यसले कन्फिगरेसनहरू एक वा बढी क्लस्टरहरूमा लागू गर्नुपर्छ कि भनेर निर्धारण गर्न सक्छ।

उदाहरणका लागि, यदि प्रशासकले Git भण्डारमा पदानुक्रम "उत्पादन क्लस्टरहरू (उत्पादन) → प्रणाली X क्लस्टरहरू → प्रणाली X को उत्पादन क्लस्टरहरू" सेट गर्दछ, त्यसपछि निम्न कन्फिगहरूको संयोजन प्रणाली 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}')

ArgoCD सर्भर को सुधार ताकि यो OpenShift मार्ग द्वारा देख्न सकिन्छ

# 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 भण्डार सिर्जना गर्नुहोस्।
• हामी हाम्रा हालका वस्तुहरू निर्यात गर्छौं र तिनीहरूलाई Git भण्डारमा अपलोड गर्छौं।
• GitOps उपकरणहरू चयन र तैनाती गर्दै।
• हामी यस टूलकिटमा हाम्रो भण्डार थप्छौं।
• हामी हाम्रो GitOps टूलकिटमा अनुप्रयोग परिभाषित गर्छौं।
• हामी GitOps टूलकिट प्रयोग गरेर अनुप्रयोगको परीक्षण रन प्रदर्शन गर्छौं।
• हामी GitOps टूलकिट प्रयोग गरेर वस्तुहरू सिङ्क्रोनाइज गर्छौं।
• वस्तुहरूको छाँट्ने र स्वत: सिंक्रोनाइजेसन सक्षम गर्नुहोस्।

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

हाम्रो उदाहरणमा, हामी 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

अब Argo CD ले सिंक गर्न नसक्ने फिल्ड हटाउन deployment.yaml फाइल सम्पादन गरौं।

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