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. Un ghid interactiv pe această temă este disponibil. la link.

Pe scurt, GitOps reprezintă un set de metode practice de utilizare a pull request-urilor Git pentru gestionarea configurațiilor infrastructurii și aplicațiilor. Un repo Git în cadrul GitOps este considerat o sursă unică de informații despre starea sistemului, iar orice modificare a acestei stări este complet urmărită și supusă auditului.

Ideea de a urmări modificările în GitOps nu este deloc nouă; acest abordare este deja folosită pe scară largă în lucrul cu codul sursă al aplicațiilor. GitOps pur și simplu implementează funcții similare (revizuiri, pull request-uri, etichete etc.) pentru gestionarea configurațiilor infrastructurii și aplicațiilor și oferă avantaje similare cu cele din gestionarea codului sursă.

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

• Descrierea declarativă a sistemului este stocată în repo-ul Git (configurații, monitorizare etc.).
• Modificările stării sunt efectuate prin pull request-uri.
• Starea sistemelor active este adusă în conformitate cu datele din repo prin push request-uri Git.

Principiile GitOps

• Definițiile sistemelor sunt descrise ca cod sursă.

Configurația sistemelor este tratată ca cod, astfel încât poate fi stocată și versiuni automat în repo-ul Git, care servește ca singura sursă de adevăr. Această abordare permite aplicarea ușoară (rollout) și anularea (rollback) modificărilor în sisteme.

• Starea dorită și configurația sistemelor sunt specificate și versiuni în Git.

Prin stocarea și versiunea în Git a stării dorite a sistemelor, obținem capacitatea de a aplica și anula cu ușurință modificările în sisteme și aplicații. De asemenea, putem folosi mecanismele de securitate ale Git pentru a controla proprietatea codului și a confirma autenticitatea acestuia.

• Modificările în configurații pot fi aplicate automat prin pull request-uri.

Folosind cererile pull din Git, putem gestiona cu ușurință modul în care modificările sunt aplicate configurațiilor din depozit. De exemplu, acestea pot fi trimise spre verificare altor membri ai echipei sau pot fi rulate prin teste CI.

Și în același timp, nu trebuie să acordăm drepturi administrative în stânga și în dreapta. Pentru a efectua un commit al modificărilor în configurație, utilizatorii au nevoie de permisiuni corespunzătoare în depozitul Git unde sunt stocate aceste configurații.

• Rezolvarea problemei driftului necontrolat al configurațiilor

Când starea dorită a sistemului este stocată în depozitul Git, rămâne doar să găsim un software care să controleze dacă starea curentă a sistemului coincide cu starea sa dorită. Dacă nu este așa, acest software trebuie - în funcție de setări - fie să corecteze automat neconformitatea, fie să ne notifice despre driftul configurațiilor.

Modelele GitOps pentru OpenShift

Recuperator de resurse on-cluster

Conform acestui model, în cluster există un controler care este responsabil pentru compararea resurselor Kubernetes (fișiere YAML) din depozitul Git cu resursele reale ale clusterului. La detectarea discrepanțelor, controlerul trimite notificări și, posibil, ia măsuri pentru a corecta neconformitățile. Acest model GitOps este folosit în Anthos Config Management și Weaveworks Flux.

Recuperator de resurse externe (Push)

Acest model poate fi considerat o variantă a precedentului, în care avem unul sau mai mulți controleri responsabili pentru sincronizarea resurselor în perechile „depozit Git - cluster Kubernetes”. Diferența aici este că, în fiecare cluster administrat, nu trebuie să existe neapărat un controler separat. Perechile „Git - cluster k8s” sunt adesea definite ca descrieri CRD (definiții de resurse personalizate), în care se poate descrie modul în care controlerul trebuie să efectueze sincronizarea. În cadrul acestui model, controlerii compară depozitul Git specificat în CRD cu resursele clusterului Kubernetes, care sunt de asemenea specificate în CRD, și efectuează acțiuni corespunzătoare în urma comparației. În special, un astfel de model GitOps este utilizat în ArgoCD.

GitOps pe platforma OpenShift

Administrarea infrastructurii Kubernetes multi-cluster

Odată cu extinderea Kubernetes și creșterea popularității strategiilor multi-cloud și a calculului la margine (edge computing), media numărului de clustere OpenShift pe client este în creștere.

De exemplu, în cazul utilizării calculului peripheral, clusterele unui singur client pot fi desfășurate în sute și chiar mii. Drept urmare, acesta este nevoit să gestioneze mai multe clustere OpenShift, fie independente, fie coordonate, în cloud public și on-premise.

În acest proces, trebuie să se rezolve o mulțime de probleme, în special:

• Să se controleze că clusterele se află în aceeași stare (configurații, monitorizare, stocare etc.).
• Să se recreeze (sau să se restabilească) clusterele la o stare cunoscută.
• Să se creeze clustere noi pe baza unei stări cunoscute.
• Să se aplice modificări pe mai multe clustere OpenShift.
• Să se revocă modificările pe mai multe clustere OpenShift.
• Să se coreleze configurațiile șablonizate cu diferite medii.

Configurațiile aplicației

Pe parcursul ciclului său de viață, aplicațiile trec adesea printr-un șir de clustere (dev, stage etc.) înainte de a ajunge în clusterul de producție. În plus, din cauza cerințelor de disponibilitate și scalabilitate, clienții desfășoară adesea aplicațiile pe mai multe clustere on-premise sau în mai multe regiuni ale platformei publice de cloud.

În acest proces, trebuie să se rezolve următoarele sarcini:

• Să se asigure mișcarea aplicațiilor (binare, configurații etc.) între clustere (dev, stage etc.).
• Să se aplice modificări în aplicații (binare, configurații etc.) în mai multe clustere OpenShift.
• Să se revocă modificările în aplicații la nivelul stării cunoscute anterioare.

Scenarii de utilizare OpenShift GitOps

1. Aplicarea modificărilor din repozitoriul Git

Administrația clusterului poate stoca configurațiile clusterului OpenShift în repozitorii Git și să le aplice automat pentru a crea fără efort clustere noi și a le aduce într-o stare identică unei stări cunoscute, care este stocată în repozitoriu Git.

2. Sincronizarea cu Secret Manager

Administrației îi va fi, de asemenea, utilă posibilitatea de a sincroniza obiectele de tip secret OpenShift cu software-ul corespunzător, precum Vault, pentru a le gestiona cu ajutorul instrumentelor special create.

3. Controlul driftului configurațiilor

Administrația va fi pe deplin de acord dacă OpenShift GitOps va identifica și va avertiza singur despre discrepanțele între configurațiile reale și cele definite în repozitoriu, astfel încât să poată reacționa rapid la drift.

4. Notificări despre derapajul configurațiilor

Acestea sunt utile atunci când administratorul dorește să afle rapid despre cazurile de derapaj al configurațiilor, pentru a lua măsuri corespunzătoare în mod rapid.

5. Sincronizarea manuală a configurațiilor în caz de derapaj

Aceasta permite administratorului să sincronizeze clusterul OpenShift cu repository-ul Git în cazul derapajului configurațiilor, pentru a readuce rapid clusterul la o stare anterioară cunoscută.

6. Sincronizarea automată a configurațiilor în caz de derapaj

Administratorul poate, de asemenea, să configureze clusterul OpenShift pentru a realiza sincronizarea automată cu repository-ul la detectarea derapajului, astfel încât configurația clusterului să fie întotdeauna conformă cu configurațiile din Git.

7. Mai multe clustere – un singur repository

Administratorul poate stoca într-un singur repository Git configurațiile mai multor clustere OpenShift diferite și să le aplice selectiv pe măsură ce este necesar.

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

Administratorul poate stabili o ierarhie a configurațiilor clusterelor în repository (stage, prod, app portfolio etc. cu moștenire). Cu alte cuvinte, el poate determina cum trebuie aplicate configurațiile – unui singur cluster sau mai multora.

De exemplu, dacă administratorul stabilește în repository-ul Git ierarhia „Clustere de producție (prod) → Clustere ale sistemului X → Clustere de producție ale sistemului X”, atunci la clusterele de producție ale sistemului X se aplică combinația următoarelor configurații:

• Configuri comune pentru toate clusterele de producție.
• Configuri pentru clusterul sistemului X.
• Configuri pentru clusterul de producție al sistemului X.

9. Șabloane și suprascrierea configurațiilor

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

10. Include-uri și exclude-uri selective pentru configurații, configurațiile aplicațiilor

Administratorul poate stabili condiții pentru a aplica sau a nu aplica diverse configurații la clustere cu caracteristici specifice.

11. Suport pentru șabloane

Dezvoltatorii vor beneficia de posibilitatea de a alege cum vor fi definite resursele aplicației (Helm Chart, yaml Kubernetes standard etc.), pentru a utiliza formatul cel mai potrivit pentru fiecare aplicație specifică.

Instrumente GitOps pe platforma OpenShift

ArgoCD

ArgoCD implementează modelul External Resource Reconcile și oferă o interfață UI centralizată pentru orchestrationa relațiilor între clustere și repository-uri Git conform schemei „unu la mulți”. Un dezavantaj al acestui program este imposibilitatea de a gestiona aplicațiile atunci când ArgoCD nu funcționează.

Site oficial

Flux

Flux implementează modelul On-Cluster Resource Reconcile, iar din această cauză nu există o gestionare centralizată a repository-ului definițiilor, ceea ce reprezintă un punct slab. Pe de altă parte, tocmai datorită lipsei de centralizare, posibilitatea de a gestiona aplicațiile rămâne valabilă și în cazul eșecului unui cluster.

Site oficial

Instalarea ArgoCD pe OpenShift

ArgoCD oferă o interfață excelentă de linie de comandă și o consolă web, prin urmare, nu vom aborda Flux și alte alternative.

Pentru a desfășura ArgoCD pe platforma OpenShift 4, urmați acești pași ca administrator al clusterului:

Desfășurarea 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}')

Modificarea serverului ArgoCD pentru a fi vizibil pentru 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

Desfășurarea instrumentului CLI ArgoCD

# 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 pentru serverul 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ă finalizarea acestor pași, se poate lucra cu serverul ArgoCD prin consola web ArgoCD WebUI sau prin 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 se spune despre o situație în care oportunitatea de a acționa a fost pierdută. În cazul OpenShift, dorința de a începe imediat să folosești această nouă platformă interesantă creează adesea o astfel de situație în gestionarea și întreținerea routelor, deployment-urilor și altor obiecte OpenShift. Dar este mereu o șansă să fie pierdută definitiv?

Continuând seria de articole despre GitOps, astăzi vom arăta cum să transformăm aplicația creată manual și resursele sale într-un proces unde totul este gestionat de instrumentarul GitOps. Pentru aceasta, vom desfășura mai întâi manual aplicația httpd. În captura de ecran de mai jos se arată cum creăm un spațiu de nume, un deployment și un serviciu, și apoi facem expose pentru acest serviciu pentru a crea un 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

Astfel, avem o aplicație creată manual. Acum trebuie să o trecem sub managementul GitOps fără a pierde disponibilitatea. Pe scurt, aceasta se realizează astfel:

• Creăm un repository Git pentru cod.
• Exportăm obiectele noastre curente și le încărcăm în depozitul Git.
• Selectăm și desfășurăm instrumentarul GitOps.
• Adăugăm depozitul nostru în acest instrumentar.
• Definim aplicația în instrumentarul nostru GitOps.
• Executăm un test al aplicației folosind instrumentarul GitOps.
• Sincronizăm obiectele cu ajutorul instrumentarului GitOps.
• Activăm curățarea (pruning) și auto-sincronizarea obiectelor.

După cum am menționat anterior, pe care l-ați cititîn GitOps există o singură sursă de informații pentru toate obiectele din cluster(e) Kubernetes – depozitul Git. Mai departe, presupunem că organizația dumneavoastră folosește deja un depozit Git. Acesta poate fi public sau privat, dar trebuie să fie accesibil clusterelor Kubernetes. Poate fi același depozit utilizat pentru codul aplicațiilor sau un depozit separat creat special pentru desfășurări. Este recomandat ca depozitul să aibă permisiuni stricte, deoarece acolo vor fi stocate obiecte secret, rute și alte elemente sensibile din punct de vedere al securității.

În exemplul nostru, vom crea un nou depozit public pe GitHub. Îi putem da orice nume, noi vom folosi numele blogpost.

Dacă fișierele YAML ale obiectelor nu au fost păstrate local sau în Git, va trebui să folosim binarele oc sau kubectl. În captura de ecran de mai jos, solicităm YAML pentru spațiul nostru de nume, desfășurarea, serviciul și ruta. Înainte, am clonat depozitul recent creat și am trecut în el cu comanda 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

Acum vom modifica fișierul deployment.yaml pentru a elimina câmpul pe care Argo CD nu îl poate sincroniza.

sed -i 's/generation: .*//d' deployment.yaml

De asemenea, trebuie să schimbăm ruta. Mai întâi, vom defini o variabilă pe mai multe linii, iar apoi vom înlocui ingress: null cu conținutul acestei variabile.

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

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

Astfel, am rezolvat problema fișierelor, rămâne să le salvăm în depozitul Git. După care, acest depozit devine singura sursă de informații, iar orice modificări manuale ale obiectelor trebuie să fie strict interzise.

git commit -am 'initial commit of objects'
git push origin master

În continuare, presupunem că ArgoCD este deja instalat (pentru instrucțiuni, vezi anterior) post). Așadar, vom adăuga în Argo CD repository-ul creat de noi, care conține codul aplicației din exemplul nostru. Asigurați-vă că specificați exact repository-ul pe care l-ați creat anterior.

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

Acum creăm aplicația. Aplicația specifică valorile necesare pentru ca instrumentele GitOps să înțeleagă ce repository și căi să folosească, ce OpenShift este necesar pentru gestionarea obiectelor și ce ramură specifică a repository-ului este necesară, precum și dacă resursele trebuie să fie sincronizate 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

După ce aplicația este definită în Argo CD, acest instrument începe să verifice obiectele deja instalate pentru a se asigura că respectă definițiile din repository. În exemplul nostru, sincronizarea automată și curățarea sunt dezactivate, astfel că elementele nu se schimbă deocamdată. Rețineți că în interfața Argo CD aplicația noastră va avea statutul „Out of Sync” (Ne-sincronizată), deoarece nu există eticheta denumită de ArgoCD.
De aceea, când vom lansa sincronizarea puțin mai târziu, redeploy-ul obiectelor nu va avea loc.

Acum vom face o rulare de test pentru a ne asigura că nu există erori în fișierele noastre.

argocd app sync simple-app --dry-run

Dacă nu există erori, putem trece la sincronizare.

argocd app sync simple-app

După ce am executat comanda argocd get pentru aplicația noastră, ar trebui să vedem că statutul aplicației s-a schimbat în Healthy (Sănătos) sau Synced (Sincronizat). Aceasta va însemna că toate resursele din repository-ul Git se află acum în conformitate cu resursele deja instalate.

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:        Sincronizat pe master (60e1678)
Health Status:      Sănătos
...   

Acum putem activa sincronizarea automată și curățarea, pentru a ne asigura că nimic nu va fi creat manual și că de fiecare dată când un obiect este creat sau actualizat în repository, va avea loc un redeploy.

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

Așadar, am reușit să migrăm aplicația la gestionarea GitOps, care inițial nu utiliza deloc GitOps.

Sursa: habr.com