GitOps-ის შესავალი OpenShift-ისთვის

დღეს ვისაუბრებთ GitOps-ის პრინციპებსა და მოდელებზე, ასევე იმაზე, თუ როგორ ხდება ამ მოდელების დანერგვა OpenShift პლატფორმაზე. ხელმისაწვდომია ინტერაქტიული სახელმძღვანელო ამ თემაზე по ссылке.

მოკლედ, GitOps არის პრაქტიკის ერთობლიობა Git pull მოთხოვნების გამოყენებისთვის ინფრასტრუქტურისა და აპლიკაციების კონფიგურაციის სამართავად. Git საცავი GitOps-ში განიხილება, როგორც ინფორმაციის ერთი წყარო სისტემის მდგომარეობის შესახებ და ამ მდგომარეობის ნებისმიერი ცვლილება სრულად არის მიკვლევადი და აუდიტი.

GitOps-ში ცვლილებების თვალთვალის იდეა სულაც არ არის ახალი; ეს მიდგომა დიდი ხანია გამოიყენება თითქმის უნივერსალურად აპლიკაციის წყაროს კოდთან მუშაობისას. GitOps უბრალოდ ახორციელებს მსგავს ფუნქციებს (მიმოხილვა, მოთხოვნის მოთხოვნა, ტეგები და ა.შ.) ინფრასტრუქტურისა და აპლიკაციების კონფიგურაციის მენეჯმენტში და უზრუნველყოფს მსგავს სარგებელს, როგორც კოდის მართვის შემთხვევაში.

არ არსებობს აკადემიური განმარტება ან წესების დამტკიცებული ნაკრები GitOps-ისთვის, მხოლოდ პრინციპების ნაკრები, რომლებზეც აგებულია ეს პრაქტიკა:

• სისტემის დეკლარაციული აღწერა ინახება Git-ის საცავში (კონფიგურაციები, მონიტორინგი და ა.შ.).
• მდგომარეობის ცვლილებები ხდება pull-ის მოთხოვნების მეშვეობით.
• გაშვებული სისტემების მდგომარეობა შეესაბამება საცავში არსებულ მონაცემებს Git push მოთხოვნების გამოყენებით.

GitOps პრინციპები

• სისტემის განმარტებები აღწერილია, როგორც წყაროს კოდი

სისტემების კონფიგურაცია განიხილება, როგორც კოდი, ასე რომ მისი შენახვა და ავტომატურად ვერსია შესაძლებელია Git საცავში, რომელიც ემსახურება როგორც სიმართლის ერთ წყაროს. ეს მიდგომა აადვილებს სისტემებში ცვლილებების გავრცელებას და უკან დაბრუნებას.

• სისტემების სასურველი მდგომარეობა და კონფიგურაცია დაყენებულია და ვერსიდება Git-ში

Git-ში სისტემების სასურველი მდგომარეობის შენახვით და ვერსიით, ჩვენ შეგვიძლია ადვილად გავაფართოვოთ და გავაუქმოთ ცვლილებები სისტემებსა და აპლიკაციებში. ჩვენ ასევე შეგვიძლია გამოვიყენოთ Git-ის უსაფრთხოების მექანიზმები კოდის ფლობის გასაკონტროლებლად და მისი ავთენტურობის დასადასტურებლად.

• კონფიგურაციის ცვლილებები შეიძლება ავტომატურად იქნას გამოყენებული pull მოთხოვნის საშუალებით

Git pull-ის მოთხოვნების გამოყენებით, ჩვენ შეგვიძლია მარტივად ვაკონტროლოთ, თუ როგორ ხდება ცვლილებების გამოყენება საცავში არსებულ კონფიგურაციებზე. მაგალითად, ისინი შეიძლება მიეცეს სხვა გუნდის წევრებს განსახილველად ან გაიარონ CI ტესტები და ა.შ.

და ამავდროულად, არ არის საჭირო ადმინისტრატორის უფლებამოსილების განაწილება მარცხნივ და მარჯვნივ. კონფიგურაციის ცვლილებების შესასრულებლად მომხმარებლებს სჭირდებათ მხოლოდ შესაბამისი ნებართვები Git საცავში, სადაც ეს კონფიგურაციები ინახება.

• კონფიგურაციების უკონტროლო დრეიფის პრობლემის დაფიქსირება

როდესაც სისტემის სასურველი მდგომარეობა ინახება Git-ის საცავში, ჩვენ მხოლოდ უნდა ვიპოვოთ პროგრამული უზრუნველყოფა, რომელიც უზრუნველყოფს სისტემის ამჟამინდელი მდგომარეობის შესაბამისობას მის სასურველ მდგომარეობას. თუ ეს ასე არ არის, მაშინ ეს პროგრამული უზრუნველყოფა უნდა - პარამეტრებიდან გამომდინარე - ან თავისით აღმოფხვრას შეუსაბამობა, ან შეგვატყობინოს კონფიგურაციის დრიფტის შესახებ.

GitOps მოდელები OpenShift-ისთვის

კლასტერული რესურსების შემრიგებელი

ამ მოდელის მიხედვით, კლასტერს აქვს კონტროლერი, რომელიც პასუხისმგებელია Git საცავში Kubernetes რესურსების (YAML ფაილების) შედარებაზე კლასტერის რეალურ რესურსებთან. როდესაც გამოვლენილია შეუსაბამობები, კონტროლერი აგზავნის შეტყობინებებს და შესაძლოა იღებს ზომებს შეუსაბამობების გამოსასწორებლად. ეს GitOps მოდელი გამოიყენება Anthos Config Management-ში და Weaveworks Flux-ში.

გარე რესურსების დამამშვიდებელი (Push)

ეს მოდელი შეიძლება ჩაითვალოს წინა მოდელის ვარიაციად, როდესაც ჩვენ გვყავს ერთი ან მეტი კონტროლერი, რომელიც პასუხისმგებელია რესურსების სინქრონიზაციაზე "Git საცავი - Kubernetes კლასტერი" წყვილებში. განსხვავება აქ არის ის, რომ თითოეულ მართულ კლასტერს სულაც არ აქვს საკუთარი ცალკე კონტროლერი. Git - k8s კლასტერების წყვილები ხშირად განიმარტება როგორც CRD (საბაჟო რესურსების განმარტებები), რომელიც აღწერს, თუ როგორ უნდა შეასრულოს კონტროლერმა სინქრონიზაცია. ამ მოდელის ფარგლებში, კონტროლერები ადარებენ CRD-ში მითითებულ Git საცავს Kubernetes კლასტერულ რესურსებს, რომლებიც ასევე მითითებულია CRD-ში და ახორციელებენ შესაბამის მოქმედებებს შედარების შედეგებზე დაყრდნობით. კერძოდ, ეს GitOps მოდელი გამოიყენება ArgoCD-ში.

GitOps OpenShift პლატფორმაზე

მრავალკლასტერული Kubernetes ინფრასტრუქტურის ადმინისტრირება

Kubernetes-ის გავრცელებასთან და მრავალ ღრუბლოვან სტრატეგიებთან და edge computing-ის მზარდი პოპულარობით, ასევე იზრდება OpenShift კლასტერების საშუალო რაოდენობა თითოეულ მომხმარებელზე.

მაგალითად, edge computing-ის გამოყენებისას, ერთი მომხმარებლის კლასტერები შეიძლება განლაგდეს ასობით ან თუნდაც ათასობით. შედეგად, ის იძულებულია მართოს რამდენიმე დამოუკიდებელი ან კოორდინირებული OpenShift კლასტერი საჯარო ღრუბელში და შიდა შენობაში.

ამ შემთხვევაში ბევრი პრობლემა უნდა გადაიჭრას, კერძოდ:

• აკონტროლეთ, რომ კლასტერები იყვნენ იდენტურ მდგომარეობაში (კონფიგურაცია, მონიტორინგი, შენახვა და ა.შ.)
• შექმენით (ან აღადგინეთ) კლასტერები ცნობილი მდგომარეობის საფუძველზე.
• შექმენით ახალი კლასტერები ცნობილი მდგომარეობის საფუძველზე.
• განათავსეთ ცვლილებები მრავალ OpenShift კლასტერში.
• ცვლილებების უკან დაბრუნება მრავალ OpenShift კლასტერში.
• დააკავშირეთ შაბლონის კონფიგურაციები სხვადასხვა გარემოში.

აპლიკაციის კონფიგურაციები

მათი სასიცოცხლო ციკლის განმავლობაში, აპლიკაციები ხშირად გადიან კლასტერების ჯაჭვს (dev, stage და ა.შ.), სანამ დასრულდება წარმოების კლასტერში. გარდა ამისა, ხელმისაწვდომობისა და მასშტაბურობის მოთხოვნების გამო, მომხმარებლები ხშირად განათავსებენ აპლიკაციებს რამდენიმე შიდა კლასტერში ან საჯარო ღრუბლოვანი პლატფორმის მრავალ რეგიონში.

ამ შემთხვევაში, შემდეგი ამოცანები უნდა გადაწყდეს:

• უზრუნველყოს აპლიკაციების გადაადგილება (ორობითი ფაილები, კონფიგურაციები და ა.შ.) კლასტერებს შორის (dev, stage და ა.შ.).
• განათავსეთ ცვლილებები აპლიკაციებში (ორობითი ფაილები, კონფიგურაციები და ა.შ.) რამდენიმე OpenShift კლასტერში.
• დააბრუნეთ ცვლილებები აპლიკაციებში წინა ცნობილ მდგომარეობაში.

OpenShift GitOps-ის გამოყენების შემთხვევები

1. ცვლილებების გამოყენება Git საცავიდან

კლასტერის ადმინისტრატორს შეუძლია შეინახოს OpenShift კლასტერული კონფიგურაციები Git საცავში და ავტომატურად გამოიყენოს ისინი ახალი კლასტერების უპრობლემოდ შესაქმნელად და მათ იდენტურ მდგომარეობაში გადაყვანა Git საცავში შენახული ცნობილი მდგომარეობისთვის.

2. სინქრონიზაცია საიდუმლო მენეჯერთან

ადმინისტრატორი ასევე ისარგებლებს OpenShift საიდუმლო ობიექტების სინქრონიზაციის შესაძლებლობით შესაბამისი პროგრამული უზრუნველყოფით, როგორიცაა Vault, რათა მართოს ისინი სპეციალურად შექმნილი ინსტრუმენტების გამოყენებით.

3. დრიფტის კონფიგურაციების კონტროლი

ადმინი მომხრე იქნება მხოლოდ იმ შემთხვევაში, თუ OpenShift GitOps თავად ამოიცნობს და გააფრთხილებს შეუსაბამობის შესახებ რეალურ კონფიგურაციებსა და საცავში მითითებულებს შორის, რათა მათ სწრაფად უპასუხონ დრიფტს.

4. შეტყობინებები კონფიგურაციის დრიფტის შესახებ

ისინი სასარგებლოა იმ შემთხვევაში, როდესაც ადმინისტრატორს სურს სწრაფად გაეცნოს კონფიგურაციის დრიფტის შემთხვევებს, რათა სწრაფად მიიღოს შესაბამისი ზომები დამოუკიდებლად.

5. კონფიგურაციების ხელით სინქრონიზაცია დრიფტის დროს

საშუალებას აძლევს ადმინისტრატორს მოახდინოს OpenShift კლასტერის სინქრონიზაცია Git საცავთან კონფიგურაციის დრიფტის შემთხვევაში, სწრაფად დააბრუნოს კლასტერი წინა ცნობილ მდგომარეობაში.

6. დრიფტის დროს კონფიგურაციების ავტომატური სინქრონიზაცია

ადმინისტრატორს ასევე შეუძლია OpenShift კლასტერის კონფიგურაცია, რათა ავტომატურად მოხდეს საცავთან სინქრონიზაცია, როდესაც დრიფტი აღმოჩენილია, რათა კლასტერის კონფიგურაცია ყოველთვის ემთხვეოდეს Git-ის კონფიგურაციას.

7. რამდენიმე კლასტერი - ერთი საცავი

ადმინისტრატორს შეუძლია შეინახოს რამდენიმე განსხვავებული OpenShift კლასტერის კონფიგურაცია ერთ Git საცავში და შერჩევით გამოიყენოს ისინი საჭიროებისამებრ.

8. კლასტერული კონფიგურაციების იერარქია (მემკვიდრეობა)

ადმინისტრატორს შეუძლია საცავში დააყენოს კლასტერების კონფიგურაციების იერარქია (სტადია, პროდ, აპლიკაციის პორტფოლიო და ა.შ. მემკვიდრეობით). სხვა სიტყვებით რომ ვთქვათ, მას შეუძლია განსაზღვროს, უნდა იქნას გამოყენებული თუ არა კონფიგურაციები ერთ ან მეტ კლასტერზე.

მაგალითად, თუ ადმინისტრატორი ადგენს იერარქიას „წარმოების კლასტერები (პროდ) → სისტემის X კლასტერები → სისტემის X წარმოების კლასტერები“ Git საცავში, მაშინ შემდეგი კონფიგურაციების კომბინაცია გამოიყენება X სისტემის წარმოების კლასტერებზე:

• კონფიგურაციები საერთოა ყველა საწარმოო კლასტერისთვის.
• კონფიგურაციები System X კლასტერისთვის.
• კონფიგურაციები X სისტემის წარმოების კლასტერისთვის.

9. შაბლონები და კონფიგურაციის უგულებელყოფა

ადმინისტრატორს შეუძლია გადალახოს მემკვიდრეობითი კონფიგურაციების ნაკრები და მათი მნიშვნელობები, მაგალითად, კონფიგურაციის დაზუსტების მიზნით კონკრეტული კლასტერებისთვის, რომლებზეც ისინი გამოყენებული იქნება.

10. შერჩევითი მოიცავს და გამორიცხავს კონფიგურაციებს, აპლიკაციის კონფიგურაციას

ადმინისტრატორს შეუძლია დააყენოს გარკვეული მახასიათებლების მქონე კლასტერებზე გარკვეული კონფიგურაციების გამოყენების ან გამოუყენებლობის პირობები.

11. შაბლონის მხარდაჭერა

დეველოპერები ისარგებლებენ უნარით აირჩიონ როგორ განისაზღვროს აპლიკაციის რესურსები (Helm Chart, სუფთა Kubernetes yaml და ა.შ.), რათა გამოიყენონ ყველაზე შესაფერისი ფორმატი თითოეული კონკრეტული აპლიკაციისთვის.

GitOps ინსტრუმენტები OpenShift პლატფორმაზე

ArgoCD

ArgoCD ახორციელებს External Resource Reconcile მოდელს და გთავაზობთ ცენტრალიზებულ ინტერფეისს კლასტერებსა და Git საცავებს შორის ერთ-ერთი ურთიერთობის ორკესტრირებისთვის. ამ პროგრამის უარყოფითი მხარე მოიცავს აპლიკაციების მართვის შეუძლებლობას, როდესაც ArgoCD არ მუშაობს.

ოფიციალური ვებგვერდი

Flux

Flux ახორციელებს On-Cluster Resource Reconcile მოდელს და, შედეგად, არ არსებობს განმარტებების საცავი ცენტრალიზებული მართვა, რაც სუსტი წერტილია. მეორეს მხრივ, ზუსტად ცენტრალიზაციის არარსებობის გამო, აპლიკაციების მართვის შესაძლებლობა რჩება მაშინაც კი, თუ ერთი კლასტერი ვერ ხერხდება.

ოფიციალური ვებგვერდი

ArgoCD-ის ინსტალაცია OpenShift-ზე

ArgoCD გთავაზობთ ბრძანების ხაზის შესანიშნავ ინტერფეისს და ვებ კონსოლს, ამიტომ აქ Flux-ს და სხვა ალტერნატივებს არ განვიხილავთ.

იმისათვის, რომ განათავსოთ ArgoCD OpenShift 4 პლატფორმაზე, მიჰყევით ამ ნაბიჯებს, როგორც კლასტერის ადმინისტრატორი:

ArgoCD კომპონენტების დაყენება OpenShift პლატფორმაზე

# 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 Route-ით

# 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 სერვერთან მუშაობა ArgoCD WebUI ვებ კონსოლის ან ArgoCD Cli ბრძანების ხაზის ხელსაწყოს მეშვეობით.
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 ჩვენი სახელების სივრცისთვის, განლაგების, სერვისისა და მარშრუტისთვის. მანამდე ჩვენ მოვახდინეთ ახლად შექმნილი საცავი და მასში cd-ის კლონირება.

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

ახლა მოდით დაარედაქტიროთ deployment.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 (როგორ გავაკეთოთ ეს - იხილეთ წინა პოსტი). ამიტომ, ჩვენ დავამატებთ 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-ში, ხელსაწყოების ნაკრები იწყებს უკვე განლაგებული ობიექტების შემოწმებას საცავში არსებული განმარტებების შესაბამისად. ჩვენს მაგალითში, ავტომატური სინქრონიზაცია და გასუფთავება გამორთულია, ამიტომ ელემენტები ჯერ არ იცვლება. გთხოვთ, გაითვალისწინოთ, რომ Argo CD-ის ინტერფეისში ჩვენს აპლიკაციას ექნება სტატუსი „Out of Sync“, რადგან არ არსებობს ეტიკეტი, რომელსაც ArgoCD აწვდის.
სწორედ ამიტომ, როდესაც სინქრონიზაციას ცოტა მოგვიანებით დავიწყებთ, ობიექტები არ განლაგდება.

ახლა მოდით გავაკეთოთ სატესტო გაშვება, რათა დავრწმუნდეთ, რომ ჩვენს ფაილებში შეცდომები არ არის.

argocd app sync simple-app --dry-run

თუ შეცდომები არ არის, შეგიძლიათ გააგრძელოთ სინქრონიზაცია.

argocd app sync simple-app

ჩვენს აპლიკაციაში argocd get ბრძანების გაშვების შემდეგ, უნდა დავინახოთ, რომ განაცხადის სტატუსი შეიცვალა Healthy ან Synced. ეს ნიშნავს, რომ 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