Sissejuhatus GitOps-i OpenShiftile

Täna räägime GitOps'i põhimõtetest ja mudelitest ning sellest, kuidas neid mudeleid rakendatakse OpenShift platvormil. Selle teema interaktiivne juhend on saadaval. lingi kaudu.

Lühidalt öeldes on GitOps praktika meetodite kogum, mis kasutab Git'i pull-päringuid infrastruktuuri ja rakenduste konfiguratsioonide haldamiseks. Git-i repo GitOps'is vaadatakse kui ühte ainsat süsteemi oleku teabe allikat, kus igasuguseid oleku muudatusi jälgitakse täielikult ja need on auditeeritavad.

Mõte muutuste jälgimisest GitOps'is ei ole uus; sellist lähenemist on juba pikka aega ja praktiliselt igal pool rakendatud rakenduste lähtekoodi töötamisel. GitOps rakendab sarnaseid funktsioone (ülevaatuskontrollid, pull-päringud, sildid jne) infrastruktuuri ja rakenduste konfiguratsioonide haldamisel ning pakub sarnaseid eeliseid nagu lähtekoodi haldamisel.

GitOps'i jaoks ei ole ühtegi akadeemilist määratlust või kinnitatud reeglite kogumit, vaid põhimõtete kogum, millele see praktika tugineb:

• Süsteemi deklaratiivne kirjeldus hoitakse Git'i repositooriumis (konfiguratsioonid, jälgimine jne).
• Oleku oleku seisundeid hallatakse pull-päringute kaudu.
• Töötavate süsteemide olek sünkroonitakse hoidlas olevate andmetega Git-push-päringute abil.

GitOpsi põhimõtted

• Süsteemide määratlemine kirjeldatakse lähtekoodina

Süsteemide konfiguratsioon käsitletakse kui kood, mistõttu seda saab salvestada ja automaatselt versioonida Git-holdis, mis toimib ainena, kust tõde leida. See lähenemine võimaldab hõlpsalt rakendada (rollout) ja tagasi võtta (rollback) muudatusi süsteemides.

• Soovitud olek ja süsteemide konfiguratsioon määratakse ja versioonitakse Git'is

Salvestades ja versioonides Git'is soovitud süsteemide oleku, saame hõlpsasti rakendada ja tagasi võtta muudatusi süsteemides ja rakendustes. Samuti saame kasutada Git'i turvamehhanisme koodi omandi ja autentsuse kontrollimiseks.

• Konfiguratsioonide muudatusi saab automaatselt rakendada pull-päringute kaudu.

Kasutades Git'i pull-request'e, saame hõlpsasti hallata, kuidas muudatused rakendatakse repositooriumis olevatele konfigureerimistele. Näiteks saab neid anda kontrollimiseks teistele meeskonnaliikmetele või viia läbi CI testid.

Ja selleks ei pea jagama adminni õigusi igaühele. Konfiguratsiooni muudatuste kinnitamiseks on kasutajatel piisavad õigused Git'i repositooriumis, kus need konfiguratsioonid asuvad.

• Kontrollimatute konfiguratsioonide kõrvaldamine

Kui soovitud süsteemi olek on salvestatud Git'i repositooriumisse, peame leidma vaid tarkvara, mis kontrollib, kas praegune süsteemi olek vastab soovitud olekule. Kui see ei vasta, peaks see tarkvara – sõltuvalt seadistustest – kas iseseisvalt kõrvaldama lahknevuse või teavitama meid konfiguratsioonide driftist.

GitOps mudelid OpenShift'i jaoks

Klastri ressursi ühtlustaja

Selle mudeli kohaselt on klastris kontroller, mille ülesanne on võrrelda Kubernetes'i ressursse (YAML-failid) Git-repositooriumis olemasolevate klastre ressurssidega. Erinevuste tuvastamisel saadab kontroller teateid ja võtab võimalusel meetmeid ebakõlade kõrvaldamiseks. See GitOps mudel on kasutusel Anthos Config Managementis ja Weaveworks Fluxis.

Väline Ressursi Korreerija (Push)

Seda mudelit võib pidada eelneva variandiks, kus meil on üks või mitu kontrollerit, mis vastutavad ressursside sünkroonimise eest paare „Git-repositoorium – Kubernetes klaster”. Erinevus seisneb aga selles, et igas hallatavas klastris ei pea tingimata olema oma eraldi kontrollerit. „Git – k8s klaster” paarid määratakse sageli CRD-kirjeldustena (custom resources definition), kus saab täpsustada, kuidas kontroller peaks sünkroniseerimise teostama. Selle mudeli raames võrreldakse CRD-s määratud Git-repositooriumi Kubernetes klastris sama CRD-s määratud ressurssidega ja tehakse vastavad toimingud võrreldes tulemusi. Eelkõige kasutatakse sellist GitOps mudelit ArgoCD-s.

GitOps OpenShift platvormil

Multiklastri Kubernetes-infrastruktuuri haldamine

Kubernetes'i leviku ja mitme pilve strateegiate ning servaarvutuse (edge computing) populaarsuse kasvades suureneb ka keskmine OpenShift'i klastrite arv ühe kliendi kohta.

Näiteks võivad servaarvutuse kasutamisel ühe kliendi klastrid ulatuda sajandate ja isegi tuhandete kaupa. Selle tõttu peab ta haldama mitmeid iseseisvaid või kooskõlastatud OpenShift'i klastreid avalikus pilves ja kohapeal.

Sellega kaasnevad mitmed probleemid, sealhulgas:

• Kontrollida, et klastrid on identilises seisundis (konfiguratsioonid, jälgimine, salvestused jne).
• Klastreid uuesti loomine (või taastamine) teadaolevast seisundist.
• Uute klastrite loomine teadaolevast seisundist.
• Muudatuste rakendamine mitmele OpenShift'i klastrile.
• Muudatuste tagasiviimine mitmele OpenShift'i klastrile.
• Kohandatud konfiguratsioonide sidumine erinevatesse keskkondadesse.

Rakenduse konfiguratsioonid

Rakenduste elutsükli jooksul läbivad nad sageli klastrite ahela (dev, stage jne), enne kui nad jõuavad tootmisklastrisse. Lisaks, seoses kättesaadavuse ja skaleeritavuse nõudmistega, saavad kliendid sageli rakendusi kohe mitmesugustes kohalikus keskkonnas või mitmes avaliku pilveplatvormi regioonis käitada.

Sellega seoses tuleb lahendada järgmised ülesanded:

• Tagada rakenduste (binaarfailide, konfiguratsioonide jne) liiklemine klastrite (dev, stage jne) vahel.
• Rakendustes (binaarfailides, konfiguratsioonides jne) muudatuste rakendamine mitmes OpenShift'i klastris.
• Rakenduste tagasi viimiste muutuste tühistamine varasemasse tuntud seisundisse.

OpenShift GitOps kasutusjuhtumid

1. Muudatuste rakendamine Git-i hoidlast

Klastri administraator saab salvestada OpenShift'i klastrite konfiguratsioonid Git-i hoidlasse ja rakendada neid automaatselt, et ilma liigsete pingutusteta luua uusi klastri ja viia need seisundisse, mis on identne tuntud seisundile, mis on salvestatud Git-i hoidlas.

2. Sünkroniseerimine Secret Manager'iga

Adminile on kasulik võimalus sünkroniseerida OpenShift'i saladusobjektid sobiva tarkvaraga nagu Vault, et hallata neid spetsiaalselt selleks loodud tööriistade abil.

3. Konfiguratsioonide driftide jälgimine

Admini jaoks on kasulik, kui OpenShift GitOps tuvastab ja hoiatab automaatselt erinevuste eest tegelike konfiguratsioonide ja repositooriumiga määratud konfiguratsioonide vahel, et saaks kiiresti reageerida driftidele.

4. Driftide jälgimise teated

Need on kasulikud, kui administraator tahab kiiresti teada driftide juhtumitest, et võtta vastavad meetmed iseseisvalt.

5. Konfiguratsioonide käsitsi sünkroniseerimine driftide korral

See võimaldab adminil teha OpenShift'i klastris sünkroniseerimist Git'i repositooriumiga driftide korral, et kiiresti taastada klaster eelmisse teadaolevasse seisundisse.

6. Automaatne konfiguratsioonide sünkroniseerimine driftide korral

Admin saab ka seadistada OpenShift'i klastri automaatseks sünkroniseerimiseks repositooriumiga driftide avastamise korral, et klastri konfiguratsioon vastaks alati Git'is olevatele seadistustele.

7. Несколько кластеров – один репозиторий

Админ может хранить в одном репозитории Git конфигурации сразу нескольких различных кластеров OpenShift и выборочно применять их по мере надобности.

8. Иерархия кластерных конфигураций (наследование)

Админ может задать иерархию кластерных конфигураций в репозитории (stage, prod, app portfolio и т. д с наследованием). Иначе говоря, он может определять, как должны применяться конфигурации – к одному или к нескольким кластерам.

Например, если админ задает в Git репозитории иерархию «Продакшн кластеры (prod) → Кластеры системы X → Продакшн кластеры системы X», то к продакшн-кластерам системы X применяется объединение следующих конфигов:

• Конфиги, общие для всех продакшн-кластеров.
• Конфиги для кластера системы X.
• Конфиги для продакшн-кластера системы X.

9. Шаблоны и переопределение конфигураций

Админ может переопределить набор унаследованных конфигов и их значений, например, чтобы тоньше настроить конфигурацию для определенных кластеров, к котором они будут применяться.

10. Избирательные include’ы и exclude’ы для конфигураций, конфигурации приложений

Admin saab seada rakendamise või mitte rakendamise tingimusi teatud omadustega klastritele.

11. Mallide tugi

Arendajatele on kasulik võimalus valida, kuidas rakenduse ressursid määratletakse (Helm Chart, puhas Kubernetes'i yaml jne), et kasutada igale konkreetsele rakendusele kõige sobivamat formaati.

GitOps tööriistad platvormil OpenShift

ArgoCD

ArgoCD rakendab väliste ressursside kooskõlastamise mudelit ja pakub keskset kasutajaliidest klastrite ja Git-repositsioonide suhete orkestreerimiseks skeemiga 'üks paljus' (one-to-many). Selle programmi miinuste hulka kuulub võimaluse puudumine rakenduste haldamiseks, kui ArgoCD ei tööta.

Ametlik veebisait

Flux

Flux rakendab klastrisisesed ressursside kooskõlastamise mudelit, mistõttu puudub keskne määratluste reposiitiumihaldus, mis on nõrk koht. Teisest küljest, just keskse juhtimise puudumise tõttu on rakenduste haldamise võimalus säilinud ka siis, kui üks klaster on välja kukkunud.

Ametlik veebisait

ArgoCD installimine OpenShiftis

ArgoCD pakub suurepärast käsurea liidest ja veebikonsoli, seega ei käsitle me siin Fluxi ja teisi alternatiive.

ArgoCD juurutamiseks OpenShift 4 platvormil järgige järgmisi samme, olles klastrihaldur:

ArgoCD komponentide juurutamine 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 OpenShift Route seda näeks

# 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 juurutamine

# 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 administraatori 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 on ArgoCD serveriga võimalik töötada läbi ArgoCD veebikonsoli või ArgoCD Cli käsurea tööriista.
https://blog.openshift.com/is-it-too-late-to-integrate-gitops/

GitOps – kunagi pole liiga hilja

„Rong on läinud“ – nii öeldakse situatsiooni kohta, kus võimalus midagi teha on möödas. OpenShifti puhul tekitab tahtmine kohe alustada selle uue ägeda platvormi kasutamist sageli just sellise olukorra marsruutide, deploy'ide ja teiste OpenShifti objektide haldamisel ja hooldamisel. Kuid kas šanss on tõeliselt igaveseks kadunud?

Jätkates artiklite seeriat GitOps, täna näitame, kuidas käsitsi loodud rakendust ja selle ressursse muuta protsessiks, kus kõike haldab GitOps tööriistakomplekt. Selleks alustame, et paigaldame rakenduse httpd käsitsi. Alloleval ekraanipildil on näidatud, kuidas me loome nimeruumi, deploymenti ja teenuse ning seejärel teeme selle teenuse ekspoose, 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 et meil on käsitsi loodud rakendus. Nüüd tuleb see viia GitOps juhtimise alla ilma juurdepääsu kaotamata. Lühidalt öeldes teeb see järgmist:

• Loome Git-reposi koodi jaoks.
• Ekspordime meie praegused objektid ja laadime need Git-reposi.
• Valime ja paigaldame GitOps tööriistakomplekti.
• Lisame sellesse tööriistakomplekti meie repo.
• Määratleme rakenduse meie GitOps tööriistakomplektis.
• Teeme rakenduse katsetamise GitOps tööriistakomplekti abil.
• Sünkroniseerime objekte GitOps tööriistakomplekti kaudu.
• Lubame puhastamise (pruning) ja objektide automaatse sünkroniseerimise.

Nagu juba öeldud, artiklison GitOps’i puhul olemas ainult üks allikas, kust leida teavet kõikide Kubernetes klastrite objektide kohta – Git-i hoidla. Eeldame, et teie organisatsioonis on juba kasutusel Git-i hoidla. See võib olla avalik või privaatne, kuid see peab olema kindlasti juurdepääsetav Kubernetes klastritele. See võib olla sama hoidla, mis sisaldab rakenduste koodi, või eraldi hoidla, mis on loodud spetsiaalselt deploy‘imiseks. Soovitav on tagada hoidlas ranged õigused, kuna seal hoitakse salajaste objektide, marsruutide ja teiste turvafunktsioonide jaoks olulisi asju.

Meie näites loome GitHubis uue avaliku hoidla. Seda saab nimetada ükskõik kuidas, meie kasutame nime blogpost.

Kui objektide YAML-failid ei ole salvestatud lokaalselt või Git’is, siis tuleb kasutada oc või kubectl binaarneid. Alloleval ekraanipildil pärime YAML meie nimetegevuse, deployment’i, teenuse ja marsruudi kohta. Enne seda kloneerisime just loodud hoidla ja liikusime sinna oma cd käsuga.

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 väli, mida Argo CD ei saa sünkroonida.

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

Nüüd, kui oleme failidega valmis saanud, tuleb need salvestada Git-repositoorsesse. Pärast seda muutub see repo ainsaks infoallikaks ja kõik käsitsi muudatused objektides peavad olema rangelt keelatud.

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

Jätkame eeldusel, et ArgoCD on juba juurutatud (kuidas seda teha – vt eelmist post). Seetõttu lisame Argo CD-sse meie loodud repositooriumi, mis sisaldab rakenduse koodi meie näites. Veenduge, et osutate just sellele repositooriumile, mille varem lõite.

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

Nüüd loome rakenduse. Rakendus määratleb väärtused, et GitOpsi tööriist saaks aru, millist hoidlat ja teid kasutada, milline OpenShift on vajalik objektide haldamiseks, samuti, milline täpselt on hoidla haru, ja kas ressursside automaatne sünkroonimine peaks 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 rakenduse seadistamist Argo CD-s hakkab see tööriist kontrollima juba väljastatud objekte, et need vastaksid hoidlas määratletud definitsioonidele. 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 rakenduse staatus "Out of Sync" (Ei ole sünkroonitud), kuna puudub ArgoCD poolt määratud label-märgis.
Sellepärast ei toimu, kui me veidi hiljem sünkroonimise käivitame, objektide uuesti väljastamist.

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

argocd app sync simple-app --dry-run

Kui vigu ei ole, siis saab jätkata sünkroonimisega.

argocd app sync simple-app

Käskluse argocd get täitmisel oma rakenduse üle peame nägema, et rakenduse staatus on muutunud Healthy (Töökorras) või Synced (Süncroniseeritud). See tähendab, et kõik Git-i hoidlas olevad ressursid vastavad nüüd neile ressurssidele, mis on juba tarnitud.

argocd app get simple-app
Nimi:               simple-app
Projekt:            default
Server:             https://kubernetes.default.svc
Nimi ruumis:        simple-app
URL:                https://argocd-server-route-argocd.apps.example.com/applications/simple-app
Repo:               https://github.com/cooktheryan/blogpost.git
Siht:              master
Teekond:           .
Süntimise poliitika:        <none>
Süntimise staatus:        Synced to master (60e1678)
Tervise staatus:      Healthy
...   

Nüüd on võimalik lubada automaatne sünkroonimine ja puhastamine, et tagada, et midagi ei luuaks käsitsi ja et iga kord, kui objekt luuakse või uuendatakse hoidlas, toimub tarnimine.

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

Seega oleme edukalt viinud GitOpsi juhtimise alla rakenduse, mis algselt ei kasutanud GitOpsi.

Allikas: habr.com