Introducere în GitOps pentru OpenShift

Astăzi vom vorbi despre principiile și modelele GitOps, precum și despre modul în care aceste modele sunt implementate pe platforma OpenShift. Este disponibil un ghid interactiv pe acest subiect по ссылке.

Pe scurt, GitOps este un set de practici pentru utilizarea cererilor de extragere Git pentru a gestiona infrastructura și configurațiile aplicațiilor. Depozitul Git din GitOps este tratat ca o singură sursă de informații despre starea sistemului, iar orice modificare a acestei stări este complet urmăribilă și auditabilă.

Ideea de urmărire a modificărilor în GitOps nu este deloc nouă; această abordare a fost folosită de mult timp aproape universal atunci când se lucrează cu codul sursă al aplicației. GitOps implementează pur și simplu caracteristici similare (recenzii, solicitări de extragere, etichete etc.) în gestionarea infrastructurii și a configurației aplicațiilor și oferă beneficii similare ca în cazul managementului codului sursă.

Nu există o definiție academică sau un set de reguli aprobat pentru GitOps, ci doar un set de principii pe care se bazează această practică:

• Descrierea declarativă a sistemului este stocată în depozitul Git (configurații, monitorizare etc.).
• Modificările de stat se fac prin cereri de extragere.
• Starea sistemelor care rulează este adusă în concordanță cu datele din depozit folosind cererile Git push.

Principiile GitOps

• Definițiile de sistem sunt descrise ca cod sursă

Configurația sistemelor este tratată ca cod, astfel încât să poată fi stocată și versiunea automată într-un depozit Git, care servește ca o singură sursă de adevăr. Această abordare facilitează lansarea și derularea modificărilor în sisteme.

• Starea și configurația dorită a sistemelor sunt setate și versiuni în Git

Prin stocarea și versiunea stării dorite a sistemelor în Git, suntem capabili să lansăm și să anulăm cu ușurință modificările aduse sistemelor și aplicațiilor. De asemenea, putem folosi mecanismele de securitate Git pentru a controla proprietatea codului și pentru a verifica autenticitatea acestuia.

• Modificările de configurare pot fi aplicate automat prin solicitări de extragere

Folosind cererile de extragere Git, putem controla cu ușurință modul în care modificările sunt aplicate configurațiilor din depozit. De exemplu, ele pot fi date altor membri ai echipei pentru revizuire sau parcurgerea testelor CI etc.

Și, în același timp, nu este nevoie să distribuiți puterile de administrator în stânga și în dreapta. Pentru a efectua modificări de configurare, utilizatorii au nevoie doar de permisiunile corespunzătoare în depozitul Git unde sunt stocate acele configurații.

• Rezolvarea problemei derivei necontrolate a configurațiilor

Odată ce starea dorită a sistemului este stocată într-un depozit Git, tot ce trebuie să facem este să găsim un software care să se asigure că starea curentă a sistemului se potrivește cu starea dorită. Dacă nu este cazul, atunci acest software ar trebui - în funcție de setări - fie să elimine discrepanța de la sine, fie să ne anunțe despre derapajul configurației.

Modele GitOps pentru OpenShift

Reconciliator de resurse în cluster

Conform acestui model, clusterul are un controler care este responsabil de compararea resurselor Kubernetes (fișiere YAML) din depozitul Git cu resursele reale ale clusterului. Dacă sunt detectate discrepanțe, controlorul trimite notificări și, eventual, ia măsuri pentru a corecta discrepanțe. Acest model GitOps este utilizat în Anthos Config Management și Weaveworks Flux.

Reconciliator de resurse externe (Push)

Acest model poate fi considerat ca o variație a celui precedent, atunci când avem unul sau mai mulți controlori responsabili cu sincronizarea resurselor în perechile „Repository Git - cluster Kubernetes”. Diferența aici este că fiecare cluster gestionat nu are neapărat propriul controler separat. Perechile de clustere Git - k8s sunt adesea definite ca CRD (definiții personalizate de resurse), care pot descrie modul în care controlerul ar trebui să efectueze sincronizarea. În cadrul acestui model, controlorii compară depozitul Git specificat în CRD cu resursele clusterului Kubernetes, care sunt și ele specificate în CRD, și efectuează acțiuni adecvate pe baza rezultatelor comparației. În special, acest model GitOps este utilizat în ArgoCD.

GitOps pe platforma OpenShift

Administrarea infrastructurii Kubernetes multi-cluster

Odată cu răspândirea Kubernetes și popularitatea tot mai mare a strategiilor multi-cloud și a edge computing, numărul mediu de clustere OpenShift per client crește, de asemenea.

De exemplu, atunci când se utilizează edge computing, clusterele unui client pot fi implementate în sute sau chiar mii. Ca urmare, el este forțat să gestioneze mai multe clustere OpenShift independente sau coordonate în cloud public și on-premise.

În acest caz, o mulțime de probleme trebuie rezolvate, în special:

• Controlați dacă clusterele sunt într-o stare identică (configurații, monitorizare, stocare etc.)
• Recreați (sau restaurați) clustere pe baza unei stări cunoscute.
• Creați noi clustere pe baza unei stări cunoscute.
• Desfășurați modificări în mai multe clustere OpenShift.
• Derulați înapoi modificările în mai multe clustere OpenShift.
• Conectați configurațiile șablon la diferite medii.

Configurații aplicației

Pe parcursul ciclului lor de viață, aplicațiile trec adesea printr-un lanț de clustere (dev, stadiu etc.) înainte de a ajunge într-un cluster de producție. În plus, datorită cerințelor de disponibilitate și scalabilitate, clienții implementează adesea aplicații în mai multe clustere on-premise sau în mai multe regiuni ale unei platforme de cloud public.

În acest caz, trebuie rezolvate următoarele sarcini:

• Asigurați mișcarea aplicațiilor (binare, configurații etc.) între clustere (dev, stage etc.).
• Desfășurați modificări ale aplicațiilor (binare, configurații etc.) în mai multe clustere OpenShift.
• Reveniți modificările aduse aplicațiilor la o stare anterioară cunoscută.

Cazuri de utilizare OpenShift GitOps

1. Aplicarea modificărilor din depozitul Git

Un administrator de cluster poate stoca configurațiile de cluster OpenShift într-un depozit Git și le poate aplica automat pentru a crea fără efort noi clustere și a le aduce într-o stare identică cu starea cunoscută stocată în depozitul Git.

2. Sincronizare cu Secret Manager

Administratorul va beneficia, de asemenea, de capacitatea de a sincroniza obiectele secrete OpenShift cu software adecvat precum Vault pentru a le gestiona folosind instrumente special create pentru acest lucru.

3. Controlul configurațiilor de deriva

Administratorul va fi în favoarea doar dacă OpenShift GitOps însuși identifică și avertizează despre discrepanțe între configurațiile reale și cele specificate în depozit, astfel încât acestea să poată răspunde rapid la derive.

4. Notificări despre devierea configurației

Ele sunt utile în cazul în care administratorul dorește să învețe rapid despre cazuri de derapaj de configurare pentru a lua rapid măsurile adecvate pe cont propriu.

5. Sincronizarea manuală a configurațiilor la drifting

Permite administratorului să sincronizeze clusterul OpenShift cu depozitul Git în caz de deviere a configurației, pentru a readuce rapid clusterul la o stare anterioară cunoscută.

6. Sincronizarea automată a configurațiilor la deriva

De asemenea, administratorul poate configura clusterul OpenShift să se sincronizeze automat cu depozitul atunci când este detectată o deviere, astfel încât configurația clusterului să se potrivească întotdeauna cu configurațiile din Git.

7. Mai multe clustere - un singur depozit

Administratorul poate stoca configurațiile mai multor clustere OpenShift diferite într-un singur depozit Git și le poate aplica selectiv, după cum este necesar.

8. Ierarhia configurațiilor clusterului (moștenire)

Administratorul poate seta o ierarhie a configurațiilor clusterului în depozit (etapă, prod, portofoliu de aplicații etc. cu moștenire). Cu alte cuvinte, poate determina dacă configurațiile ar trebui aplicate unuia sau mai multor clustere.

De exemplu, dacă un administrator definește ierarhia „Clustere de producție (prod) → Clustere ale sistemului X → Clustere de producție ale sistemului X” în depozitul Git, atunci o combinație a următoarelor configurații este aplicată clusterelor de producție ale sistemului X:

• Configurații comune tuturor clusterelor de producție.
• Configurații pentru clusterul System X.
• Configurații pentru clusterul de producție a sistemului X.

9. Șabloane și modificări de configurare

Administratorul poate suprascrie un set de configurații moștenite și valorile acestora, de exemplu, pentru a ajusta configurația pentru anumite clustere la care vor fi aplicate.

10. Includere și excludere selectivă pentru configurații, configurații de aplicații

Administratorul poate seta condițiile pentru aplicarea sau neaplicarea anumitor configurații la clustere cu anumite caracteristici.

11. Suport pentru șabloane

Dezvoltatorii vor beneficia de posibilitatea de a alege modul în care vor fi definite resursele aplicației (Helm Chart, pur Kubernetes yaml, etc.) pentru a utiliza cel mai potrivit format pentru fiecare aplicație specifică.

Instrumente GitOps pe platforma OpenShift

ArgoCD

ArgoCD implementează modelul External Resource Reconcile și oferă o interfață de utilizare centralizată pentru orchestrarea relațiilor unu-la-mai multe dintre clustere și depozitele Git. Dezavantajele acestui program includ incapacitatea de a gestiona aplicațiile atunci când ArgoCD nu funcționează.

Site-ul oficial

Flux

Flux implementează un model de reconciliere a resurselor pe cluster și, ca urmare, nu există un management centralizat al depozitului de definiții, ceea ce este un punct slab. Pe de altă parte, tocmai din cauza lipsei de centralizare, capacitatea de a gestiona aplicațiile rămâne chiar dacă un cluster eșuează.

Site-ul oficial

Instalarea ArgoCD pe OpenShift

ArgoCD oferă o interfață excelentă de linie de comandă și o consolă web, așa că nu vom acoperi Flux și alte alternative aici.

Pentru a implementa ArgoCD pe platforma OpenShift 4, urmați acești pași ca administrator de cluster:

Implementarea componentelor ArgoCD pe platforma 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}')

Îmbunătățirea serverului ArgoCD, astfel încât să poată fi văzut de 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

Implementarea 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

Schimbarea parolei de administrator al serverului 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

După parcurgerea acestor pași, puteți lucra cu ArgoCD Server prin consola web ArgoCD WebUI sau instrumentul de linie de comandă ArgoCD Cli.
https://blog.openshift.com/is-it-too-late-to-integrate-gitops/

GitOps - Niciodată nu este prea târziu

„Trenul a plecat” - așa spun ei despre o situație în care se pierde ocazia de a face ceva. În cazul OpenShift, dorința de a începe imediat să utilizați această nouă platformă cool creează adesea exact această situație cu gestionarea și întreținerea rutelor, implementărilor și a altor obiecte OpenShift. Dar șansa este întotdeauna complet pierdută?

Continuarea seriei de articole despre GitOps, astăzi vă vom arăta cum să transformați o aplicație manuală și resursele acesteia într-un proces în care totul este gestionat de instrumentele GitOps. Pentru a face acest lucru, mai întâi vom implementa manual aplicația httpd. Captura de ecran de mai jos arată cum creăm un spațiu de nume, implementare și serviciu, apoi expunem acest serviciu pentru a crea o rută.

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

Deci avem o aplicație manuală. Acum trebuie să fie transferat sub managementul GitOps fără pierderea disponibilității. Pe scurt, face asta:

• Creați un depozit Git pentru cod.
• Exportăm obiectele noastre curente și le încărcăm în depozitul Git.
• Selectarea și implementarea instrumentelor GitOps.
• Adăugăm depozitul nostru la acest set de instrumente.
• Definim aplicația în setul nostru de instrumente GitOps.
• Efectuăm un test de rulare a aplicației folosind setul de instrumente GitOps.
• Sincronizăm obiectele folosind setul de instrumente GitOps.
• Activați tăierea și sincronizarea automată a obiectelor.

După cum sa menționat deja în precedentul articol, în GitOps există una și o singură sursă de informații despre toate obiectele din clusterul (clusterele) Kubernetes - depozitul Git. În continuare, pornim de la premisa că organizația dvs. utilizează deja un depozit Git. Poate fi public sau privat, dar trebuie să fie accesibil clusterelor Kubernetes. Acesta poate fi același depozit ca și pentru codul aplicației sau un depozit separat creat special pentru implementări. Se recomandă să aveți permisiuni stricte în depozit, deoarece secretele, rutele și alte lucruri sensibile la securitate vor fi stocate acolo.

În exemplul nostru, vom crea un nou depozit public pe GitHub. Îi poți numi cum vrei, noi folosim numele blogpost.

Dacă fișierele obiect YAML nu au fost stocate local sau în Git, atunci va trebui să utilizați binarele oc sau kubectl. În captura de ecran de mai jos, solicităm YAML pentru spațiul de nume, implementarea, serviciul și ruta noastră. Înainte de aceasta, am clonat depozitul nou creat și cd-ul în el.

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

Acum să edităm fișierul deployment.yaml pentru a elimina câmpul pe care CD-ul Argo nu îl poate sincroniza.

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

În plus, traseul trebuie schimbat. Mai întâi vom seta o variabilă cu mai multe linii și apoi vom înlocui ingress: null cu conținutul acelei variabile.

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

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

Deci, am sortat fișierele, tot ce rămâne este să le salvăm în depozitul Git. După care acest depozit devine singura sursă de informații, iar orice modificare manuală a obiectelor ar trebui să fie strict interzisă.

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

Mai departe, pornim de la faptul că ați deja implementat ArgoCD (cum să faceți acest lucru - vezi anterior rapid). Prin urmare, vom adăuga pe CD-ul Argo depozitul creat de noi, care conține codul aplicației din exemplul nostru. Doar asigurați-vă că specificați depozitul exact pe care l-ați creat mai devreme.

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

Acum să creăm aplicația. Aplicația setează valori astfel încât setul de instrumente GitOps să înțeleagă ce depozit și căile de utilizat, ce OpenShift este necesar pentru a gestiona obiectele, ce ramură specifică a depozitului este necesară și dacă resursele ar trebui să se sincronizeze automat.

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

Odată ce o aplicație este specificată în CD-ul Argo, setul de instrumente începe să verifice obiectele deja implementate cu definițiile din depozit. În exemplul nostru, sincronizarea automată și curățarea sunt dezactivate, astfel încât elementele nu se schimbă încă. Vă rugăm să rețineți că în interfața Argo CD aplicația noastră va avea starea „Nesincronizat” deoarece ArgoCD nu o oferă nicio etichetă.
Acesta este motivul pentru care atunci când începem sincronizarea puțin mai târziu, obiectele nu vor fi redistribuite.

Acum să facem un test de rulare pentru a ne asigura că nu există erori în fișierele noastre.

argocd app sync simple-app --dry-run

Dacă nu există erori, atunci puteți trece la sincronizare.

argocd app sync simple-app

După rularea comenzii argocd get în aplicația noastră, ar trebui să vedem că starea aplicației s-a schimbat în Sănătate sau Sincronizat. Aceasta va însemna că toate resursele din depozitul Git corespund acum acelor resurse care au fost deja implementate.

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
...   

Acum puteți activa sincronizarea automată și curățarea pentru a vă asigura că nimic nu este creat manual și că de fiecare dată când un obiect este creat sau actualizat în depozit, va avea loc o implementare.

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

Deci, am adus cu succes o aplicație sub controlul GitOps care inițial nu a folosit GitOps în niciun fel.

Sursa: www.habr.com