Sissejuhatus GitOps'i OpenShifti jaoks

Täna räägime GitOpsi printsiipidest ja mudelitest, samuti sellest, kuidas neid mudeleid rakendatakse OpenShift platvormil. Sellel teemal on saadaval interaktiivne juhend. linki pidi.

Lühidalt öeldes on GitOps rida praktilisi meetodeid Git-i pull-päringute kasutamiseks infrastruktuuri ja rakenduste konfigureerimiseks. Git-i repositooriumit GitOpsi kontekstis käsitletakse kui ainukest tõde süsteemi oleku kohta, kus kõik selle oleku muudatused on täielikult jälgitavad ja auditeeritavad.

Mõte muudatuste jälgimisest GitOpsis ei ole sugugi uus; sellist lähenemist on juba ammu ja peaaegu igal pool rakendatud rakenduste lähtekoodiga töötamisel. GitOps rakendab sarnaseid funktsioone (ülevaatuse kontrollid, pull-päringud, sildid jne) infrastruktuuri ja rakenduste konfigureerimisel ning annab sarnaseid eeliseid nagu lähtekoodi haldamisel.

GitOpsil ei ole ühtegi akadeemilist määratlust või heakskiidetud reeglite kogumit, vaid põhiprintsiipe, millel see praktika põhineb:

• Süsteemi deklaratiivne kirjeldus hoitakse Git-repositooriumis (konfiguratsioonid, jälgimine jne).
• Oleku muudatused tehakse pull-päringute kaudu.
• Töötavate süsteemide olek vastandatakse repositooriumis olevate andmetega Git push-päringute abil.

GitOpsi printsiibid

• Süsteemide määratlused kirjeldatakse kui lähtekood

Süsteemide konfiguratsiooni käsitletakse kui koodi, seega saab seda hoida ja automaatselt versioonida Git-repositooriumis, mis teenib ainukese tõe allikana. Selline lähenemine võimaldab hõlpsalt muudatusi süsteemides sisse viia (rollout) ja tagasi pöörata (rollback).

• Soovitud olek ja süsteemide konfiguratsioon määratakse ja versioonitakse Gitis.

Hoides ja versioonides soovitud olekut Gitis, saame hõlpsalt muudatusi süsteemides ja rakendustes sisse viia ja tagasi pöörata. Samuti saame kasutada Giti turvamehhanisme koodi omamise kontrollimiseks ja selle originaalsuse kinnitamiseks.

• Konfiguratsioonides toimuvad muudatused saavad automaatselt rakenduda pull-päringute kaudu.

Kasutades Git'i pull-päringuid, saame me lihtsalt hallata, kuidas muudatused rakenduvad repos olevatele konfiguratsioonidele. Näiteks saab neid anda ülevaatamiseks teistele meeskonna liikmetele või lasta neil läbi CI testide.

Ja selleks ei pea jagama administraatori õigusi vasakule ja paremale. Et teha muudatused konfiguratsioonis, peavad kasutajad omama vastavaid õigusi Git-repos, kus need konfiguratsioonid asuvad.

• Probleemi lahendamine kontrollimatust konfiguratsioonide triivimisest

Kui soovitud süsteemi seisund hoitakse Git-repos, siis jääb meil vaid leida tarkvara, mis kontrollib, kas praegune süsteemi seisund vastab selle soovitud seisundile. Kui see nii ei ole, siis peaks see tarkvara - vastavalt seadistustele - kas iseseisvalt kõrvaldama mittesobivuse või teavitama meid konfiguratsioonide triivimisest.

GitOps mudelid OpenShiftis

Klusteri sees olev ressurside kooskõlastaja

Selle mudeli kohaselt on klusteris kontroller, mis vastutab Kubernetes-ressursside (YAML-failid) võrdlemise eest Git-repos olevate tegelike klusteri ressurssidega. Erinevuste tuvastamisel saadab kontroller teate ja vajadusel võtab meetmeid mittesobivuste kõrvaldamiseks. Seda GitOps mudelit kasutatakse Anthos Config Management'is ja Weaveworks Flux'is.

Väline ressurside kooskõlastaja (Push)

Seda mudelit võib käsitleda kui eelneva varianti, kus meil on üks või mitu kontrollerit, mis vastutavad ressursside sünkroonimise eest „Git-repo - Kubernetes kluster” paarides. Erinevus seisneb selles, et igas hallatavaks muudetud klastris ei pea tingimata olema oma alamkontroller. „Git - k8s kluster” paarid määratletakse sageli CRD-kirjeldustes (custom resources definition), kus saab kirja panna, kuidas kontroller peaks sünkroonimist teostama. Selle mudeli raames võrreldakse kontrollerid Git-repos olevat, mis on määratud CRD-s, Kubernetes klusteri ressurssidega, mis on samuti määratud CRD-s, ja viiakse ellu vastavad tegevused võrreldes tulemusi. Eelkõige kasutatakse sellist GitOps mudelit ArgoCD-s.

GitOps OpenShift platvormil

Multiklastri Kubernetes infrastruktuuri haldamine

Kubernetes'e laienemise ja mitme pilve strateegiate ning servaarvutuse (edge computing) kasvava populaarsuse tõttu suureneb ka keskmine OpenShift klastrite arv ühe kliendi kohta.

Näiteks võivad ühe kliendi piiratud arvutusteaduse klastri välja arendamise arvud ulatuda sadade ja isegi tuhandeteni. Selle tagajärjel peab ta haldama mitmeid iseseisvaid või kooskõlastatud OpenShift klastreid avalikus pilves ja kohapeal.

Sellega tuleb lahendada palju probleeme, sealhulgas:

• Kontrollida, et klastrid oleksid sarnases olekus (konfiguratsioonid, jälgimine, salvestused jne).
• Uuesti luua (või taastada) klastreid tuntud olekust.
• Luua uusi klastreid tuntud olekust.
• Rakendada muudatusi mitmes OpenShift klastris.
• Tagasi rullida muudatusi mitmes OpenShift klastris.
• Siduda mallitud konfiguratsioonid erinevate keskkondadega.

Rakenduse konfiguratsioonid

Rakendused läbivad sageli oma eluringi jooksul ahela klastreid (arendust, etappi jne), enne kui need jõuavad tootmisklastrisse. Samuti käivitavad kliendid tihti rakendusi mitmes kohapealses klastris või mitmes piirkonnas avalikus pilveplatvormis, arvestades kättesaadavuse ja skaleeritavuse nõudeid.

Selle käigus tuleb lahendada järgmised ülesanded:

• Tagada rakenduste (binaarid, konfiguratsioonid jne) liikumine klastrite vahel (arendust, etappi jne).
• Rakendada rakendustes (binaarid, konfiguratsioonid jne) muudatusi mitmes OpenShift klastris.
• Tagasi rullida rakendustes muudatused eelmise tuntud oleku tasemeni.

OpenShift GitOps'i kasutusstsenaariumid

1. Muudatuste rakendamine Git-repositooriumist

Klastri administraator saab salvestada OpenShift klastrite konfiguratsioonid Git-repositooriumisse ja rakendada neid automaatselt, et vaevata luua uusi klastreid ja tuua need tundmisse olekusse, mis on salvestatud Git-repositooriumis.

2. Sünkroniseerimine Secret Manageriga

Administraatorile on samuti kasulik võimalus sünkroniseerida OpenShift secret-objekte sobiva tarkvaraga nagu Vault, et hallata neid spetsiaalselt loodud tööriistade abil.

3. Konfiguratsioonide drifti jälgimine

Administraator on kindel, et OpenShift GitOps suudab automaatselt tuvastada ja teavitada tõrgetest tegelike konfiguratsioonide ja nende vahel, mis on määratud repositooriumis, et saaks kiiresti reageerida drifti olukordadele.

4. Konfiguratsioonide tuvastamise teated

Need on kasulikud siis, kui administraator soovib kiiresti teada saada, kui konfiguratsioonid muutuvad, et kiiresti iseseisvalt vajalikud meetmed võtta.

5. Konfiguratsioonide käsitsi sünkroniseerimine muutumise korral

See võimaldab administraatoril sünkroniseerida OpenShifti klastri Git-repositoariumiga, kui konfiguratsioonid muutuvad, et kiiresti taastada klaster varasemasse tuntud olekusse.

6. Konfiguratsioonide automaatne sünkroniseerimine muutumise korral

Administraator saab samuti seadistada OpenShifti klastri automaatseks sünkroniseerimiseks repositooriumiga, kui muutusi avastatakse, et klastri konfiguratsioon oleks alati kooskõlas Git'is olevate seadistustega.

7. Mitmed klastrid – üks repositoorium

Administraator saab salvestada ühte Git-repositoormapist mitme erineva OpenShifti klastri konfiguratsioonid ja rakendada neid valikuliselt vastavalt vajadusele.

8. Klastri konfiguratsioonide hierarhia (pärandimine)

Administraator saab määrata repositooriumis klastri konfiguratsioonide hierarhia (stage, prod, rakenduste portfell jne koos pärandiga). Teisisõnu, ta saab määrata, kuidas konfiguratsioonid rakendatakse – ühele või mitmele klastrile.

Näiteks kui administraator määrab Git-repositooriumis hieraarhiat „Tootmisklastrid (prod) → X süsteemi klastrid → X süsteemi tootmisklastrid”, siis rakendatakse X süsteemi tootmisklastritele järgmiste konfiguratsioonide koosseisu:

• Konfiguratsioonid, mis on ühised kõigile tootmisklastritele.
• X süsteemi klastrile mõeldud konfiguratsioonid.
• X süsteemi tootmisklastri konfiguratsioonid.

9. Mallid ja konfiguratsioonide ülekirjutamine

Administraator saab ülekirjutada pärandatud konfiguratsioonide komplekti ja nende väärtusi, näiteks et täpsustada teatud klastritele rakendatava konfiguratsiooni seadistusi.

10. Valikulised include-d ja exclude-d konfiguratsioonide jaoks, rakenduste konfiguratsioonid

Administraator saab määrata tingimused, millal teatud konfiguratsioonid rakendatakse või mitte rakendatakse klastritele, millel on teatud omadused.

11. Mallide toetus

Arendajatele on kasulik võimalus valida, kuidas rakenduse ressursid määratakse (Helm Chart, puhas Kubernetes'lik yaml jne), et kasutada iga konkreetse rakenduse jaoks kõige sobivamat vormingut.

GitOps tööriistad OpenShifti platvormil

ArgoCD

ArgoCD rakendab External Resource Reconcile mudelit ning pakub tsentraliseeritud kasutajaliidest klastrite ja Git-repositorite suhete orksestreerimiseks skeemis "üks paljudele". Selle programmi puudusteks on võimetus hallata rakendusi, kui ArgoCD ei tööta.

Ametlik veebisait

Flux

Flux rakendab On-Cluster Resource Reconcile mudelit ja seetõttu puudub tsentraliseeritud haldus määrangute repositoriumi jaoks, mis on nõrkus. Teisalt, just tsentraliseerimise puudumise tõttu on rakenduste haldamise võimalus säilinud ka siis, kui üks klaster on välja langenud.

Ametlik veebisait

ArgoCD installimine OpenShiftis

ArgoCD pakub suurepärast käsurealiidest ja veebi konsooli, seega ei vaatle me siin Fluxi ja teisi alternatiive.

ArgoCD-deployimine OpenShift 4 platvormil, järgige järgmisi samme klastrihaldurina:

ArgoCD komponentide deployimine OpenShift platvormil

# 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 Serveri kohandamine, et see oleks OpenShift Route'ile nähtav

# 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 Tööriista deployimine

# 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 Serveri admin parooli muutmine

# 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

Pärast nende sammude täitmist saab ArgoCD Serverit hallata ArgoCD WebUI kaudu või ArgoCD Cli käsureatööriistaga.
https://blog.openshift.com/is-it-too-late-to-integrate-gitops/

GitOps - kunagi pole liiga hilja

"Rong on läinud" - nii öeldakse olukorra kohta, kus midagi teha on juba hilja. OpenShiftis soov alustada selle uue ägeda platvormi kasutamist loob sageli just sellise olukorra marsruutide, deploymendide ja teiste OpenShift objektide haldamisel ja teenindamisel. Kuid kas võimalus on tõeliselt igaveseks kaotsi läinud?

Jätkates artiklite sarja GitOps, täna näitame, kuidas käsitsi loodud rakendust ja selle ressursse muuta protsessiks, mida haldab GitOps tööriist. Selleks deployime esmalt käsitsi httpd rakenduse. Alloleval ekraanipildil näeme, kuidas loome nimespetsi, deploymendi ja teenuse, seejärel teeme selle teenuse expose, et luua marsruut.

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

Nii, meil on käsitsi loodud rakendus. Nüüd peame selle viima GitOps juhtimise alla ilma kasutatavust kaotamata. Lühidalt, see teeb järgmist:

• Loome Git-reposiitiumi koodi jaoks.
• Eksportime meie praegused objektid ja laadime need Git-reposiiti.
• Valime ja seadistame GitOpsi tööriistade komplekti.
• Lisame meie reposse selle tööriistade komplekti.
• Määratleme rakenduse meie GitOpsi tööriistade komplektis.
• Teeme rakendusele proovikäivituse, kasutades GitOpsi tööriistade komplekti.
• Sünkroniseerime objekte GitOpsi tööriistade komplekti abil.
• Aktiveerime objektide puhastamise (pruning) ja automaatse sünkroniseerimise.

Nagu eelnevalt mainitud, artiklis, on GitOpsis üks ja ainus teabeallikas kõigi Kubernetes klaster(i) objektide kohta – Git-reposiit. Edasi eeldame, et teie organisatsioonis on juba kasutusel Git-reposiit. See võib olla avalik või privaatne, kuid see peab olema kergesti kättesaadav Kubernetes klastritele. See võib olla sama repod, mis on rakenduse koodiks, või eraldi repo, mis on loodud spetsiaalselt juurutamise jaoks. Repositooriumis on soovitatav rakendada ranget ligipääsu, kuna seal hoitakse saladusobjekte, marsruute ja teisi turvalisuse seisukohalt tundlikke asju.

Meie näite puhul loome uue avaliku repodi GitHubis. Selle nime saab panna ükskõik millise, meie kasutame nime blogpost.

Kui objekti YAML-failid ei olnud salvestatud kohapeal või Gitis, tuleb kasutada binaarfaile oc või kubectl. Alloleval pildil küsime YAMLi meie nimesse, juurutusse, teenusesse ja marsruuti. Enne seda kloneerisime just loodud repodie ja liikusime sinna käsuga 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

Nüüd muudame faili deployment.yaml, et eemaldada sealt väli, mida Argo CD ei saa sünkroniseerida.

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

Lisaks tuleb muuta marsruuti. Esiteks määratleme mitmerealise muutuja ja seejärel asendame ingress: null selle muutuja sisuga.

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

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

Nii et failid on korras, nüüd tuleks need salvestada Git-reposiiti. Pärast seda muutub see repo ainus teabeallikas, ja kõik käsitsi tehtud muudatused objektides peavad olema rangelt keelatud.

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

Jätkame sellest, et ArgoCD on juba seadistatud (kuidas seda teha – vt eelmist postitus). Seega lisame Argo CD-sse meie loodud repositooriumi, mis sisaldab rakenduse koodi meie näitest. Veenduge, et osutate just sellele repositooriumile, mille eelnevalt loote.

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

Nüüd loome rakenduse. Rakendus määratleb väärtused, et GitOps tööriist mõistaks, millist repositooriumi ja teid kasutada, millist OpenShifti on vaja objektide haldamiseks, samuti millist konkreetset repositooriumi haru on vaja ja kas ressursside automaatne sünkroonimine peab toimuma.

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

Pärast seda, kui rakendus on Argo CD-s määratud, hakkab see tööriist kontrollima juba rakendatud objekte vastavuses repositooriumis toodud määratlustega. Meie näites on automaatne sünkroonimine ja puhastamine välja lülitatud, seega elemendid ei muutu. Pange tähele, et Argo CD liideses on meie rakendusel staatuseks „Out of Sync” (Ei ole sünkroniseeritud), kuna ei ole ArgoCD poolt määratud label-silti.
Just seetõttu, kui me veidi hiljem sünkroonimise käivitame, ei toimu objektide uuesti rakendamist.

Nüüd teeme katse, et veenduda, et meie failides ei ole vigu.

argocd app sync simple-app --dry-run

Kui vigu ei ole, siis võime minna sünkroonimise juurde.

argocd app sync simple-app

Pärast käsu argocd get käimist meie rakenduse üle peaksime nägema, et rakenduse staatus on muutunud Healthy (Töökorras) või Synced (Sünkroniseeritud). See tähendaks, et kõik ressursid Git-repositooriumis vastavad juba rakendatud ressurssidele.

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:        
Sync Status:        Synced to master (60e1678)
Health Status:      Healthy
...   

Nüüd on juba võimalik sisse lülitada automaatne sünkroonimine ja puhastamine, et tagada, et midagi ei luleta käsitsi ja et iga kord, kui objekt luuakse või värskendatakse repositooriumis, toimub rakendamine.

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

Nii et, me oleme edukalt viinud GitOps juhtimise alla rakenduse, mis algselt ei kasutanud GitOps-i.

Allikas: habr.com