Ma bemutatjuk a GitOps elveit és modelljeit, valamint azt, hogyan valósulnak meg ezek a modellek az OpenShift platformon. Az interaktív útmutató a témában elérhető .
Röviden, a GitOps egy praktikus módszerekből álló készlet, amely a Git pull-kérelmeinek használatával irányítja az infrastruktúra és alkalmazások konfigurációit. A Git-akták a GitOps keretein belül egyetlen információforrásként működnek a rendszer állapotáról, és bármilyen változást a rendszerben teljes mértékben nyomon lehet követni és auditálni.
A GitOps-ban a változások nyomon követésének ötlete nem új, ezt a megközelítést már régóta és szinte mindenhol alkalmazzák a különböző alkalmazásforrásokkal való munkavégzés során. A GitOps egyszerűen az infrastruktúra és alkalmazások konfigurációinak kezelésében az alkalmazásforrásokkal azonos funkciókat (ellenőrzések, pull-kérelmek, címkék stb.) valósít meg, és ugyanolyan előnyöket nyújt.
A GitOps-nak nincs akadémiai definíciója vagy jóváhagyott szabályrendszere, csupán egy elvek gyűjteménye, amelyen ez a gyakorlat alapul:
- A rendszer deklaratív leírása Git-tárhelyen tárolódik (konfigurációk, monitorozás stb.).
- Az állapotváltozások pull-kérelmek útján hajtódnak végre.
- A működő rendszerek állapotát a Git push-kérelmeivel hozza összhangba a tárolóban lévő adatokkal.
A GitOps elvei
- A rendszerek leírásai kód formájában állnak rendelkezésre.
A rendszerek konfigurációja kódnak minősül, ezért tárolható és automatikusan verzionálható a Git-tárhelyen, amely az egyetlen igazság forrását jelenti. Ez a megközelítés lehetővé teszi a változások egyszerű végrehajtását (rollout) és visszaállítását (rollback) a rendszerekben.
- A kívánt állapot és a rendszerek konfigurációja a Git-ben van megadva és verzionálva.
A rendszerek kívánt állapotának Git-ben való tárolásával és verzionálásával könnyen végrehajthatók és visszaállíthatók a változások a rendszerekben és alkalmazásokban. Továbbá, a Git biztonsági mechanizmusait is felhasználhatjuk a kód tulajdonjogának ellenőrzésére és hitelesítésére.
- A konfigurációkban bekövetkező változások automatikusan alkalmazhatók pull-kérelmek révén.
A Git pull request segítségével könnyen kezelhetjük, hogyan alkalmazzák a változtatásokat a konfigurációkban a tárolóban. Például más csapattagoknak is átadhatjuk ellenőrzésre, vagy CI teszteken keresztül is futhat.
Emellett nincs szükség adminisztrátori jogosultságok szétszórására. A konfigurációk módosításainak commitálásához a felhasználóknak elegendő jogosultsággal kell rendelkezniük a Git tárolóban, ahol ezek a konfigurációk találhatók.
- A konfigurációk ellenőrizetlen driftjének megszüntetése
Amikor a rendszer kívánt állapota a Git tárolóban van tárolva, csak annyit kell tennünk, hogy megtaláljuk azt a szoftvert, amely ellenőrzi, hogy a rendszer aktuális állapota megfelel-e a kívántnak. Ha nem, akkor ennek a szoftvernek a beállítások függvényében vagy saját magának kell megszüntetnie az eltéréseket, vagy értesítenie minket a drift kérdéseiről.
GitOps modellek az OpenShift számára
On-Cluster Resource Reconciller
E modell szerint a klaszterben van egy vezérlő, amely a Kubernetes-erőforrások (YAML fájlok) összehasonlításáért felelős a Git tárolóban a klaszter valódi erőforrásaival. Ha eltéréseket észlel, a vezérlő értesítéseket küld, és esetleg intézkedéseket tesz az eltérések megszüntetésére. Ezt a GitOps modellt használják az Anthos Config Managementben és a Weaveworks Fluxban.
External Resource Reconciler (Push)
E modellt úgy is tekinthetjük, mint a korábbi változatának egy fajtája, amikor egy vagy több vezérlő felelős az erőforrások szinkronizálásáért a "Git tároló - Kubernetes klaszter" párokban. A különbség itt az, hogy minden kezelős klaszterben nem feltétlenül szükséges külön vezérlő. A "Git - k8s klaszter" párokat gyakran CRD-leírásokkal (custom resources definition) határozzák meg, amelyekben meg lehet határozni, hogyan kell a vezérlőnek végrehajtania a szinkronizálást. A modell keretein belül a vezérlők a CRD-ben megadott Git tárolót hasonlítják össze a Kubernetes klaszter, szintén CRD-ben megadott erőforrással, és a hasonlítás eredményei alapján összhangba hozzák ezeket. Különösen ezt a GitOps modellt használják az ArgoCD-ben.
GitOps az OpenShift platformon
Multiklaszteres Kubernetes-infrastruktúra adminisztrációja
A Kubernetes elterjedésével és a multi-cloud stratégiák, valamint a perifériás számítástechnika (edge computing) népszerűségének növekedésével egyre több OpenShift klaszter jut egy megrendelőre.
Például, amikor a perifériás számításokat használják, egy ügyfél klaszterei több száz vagy akár ezer darabra is kiterjedhetnek. Ennek eredményeként kénytelen több független vagy összehangolt OpenShift klasztert kezelni nyilvános felhőben és helyben.
Ezzel együtt számos problémát kell megoldani, például:
- Ellenőrizni, hogy a klaszterek azonos állapotban legyenek (konfigurációk, monitorozás, tárolók stb.)
- Újra létrehozni (vagy helyreállítani) a klasztereket egy ismert állapot alapján.
- Új klasztereket létrehozni egy ismert állapot alapján.
- Változtatásokat végrehajtani több OpenShift klaszteren.
- Visszaállítani változtatásokat több OpenShift klaszteren.
- Összeilleszteni a sablonozott konfigurációkat különböző környezetekkel.
Alkalmazás konfigurációk
Alkalmazásuk életciklusa során gyakran átmennek egy klasztersoron (dev, stage stb.), mielőtt a termelési klaszterbe kerülnek. Ezen kívül a rendelkezésre állás és skálázhatóság miatt az ügyfelek gyakran telepítik az alkalmazásokat egyszerre több helyi klaszterre vagy több régióba a nyilvános felhőplatformon.
Ekkor az alábbi feladatokat kell megoldani:
- Biztosítani az alkalmazások (binárisok, konfigurálások stb.) mozgását a klaszterek között (dev, stage stb.).
- Változtatásokat végrehajtani az alkalmazások (binárisok, konfigurálások stb.) szintjén több OpenShift klaszteren.
- Visszaállítani az alkalmazások változtatásait a korábbi ismert állapot szintjére.
OpenShift GitOps használati forgatókönyvek
1. Változtatások alkalmazása a Git-repozitóriumból
A klaszter adminisztrátora tárolhatja az OpenShift klaszter konfigurációit egy Git-repozitóriumban, és automatikusan alkalmazhatja őket, hogy felesleges erőfeszítések nélkül hozzon létre új klasztereket és hozza őket egy olyan állapotba, amely megegyezik azzal az ismert állapottal, ami a Git-repozitóriumban van tárolva.
2. Szinkronizálás a Secret Managerrel
Az adminisztrátornak jól jöhet a lehetőség, hogy szinkronizálja az OpenShift titkos objektumait a megfelelő szoftverekkel, például a Vaulttal, annak érdekében, hogy speciálisan erre a célra készített eszközökkel kezelhesse azokat.
3. A konfigurációs eltérések ellenőrzése
Az admin csak örülne, ha az OpenShift GitOps automatikusan észlelné és figyelmeztetne az eltérésekre a valós konfigurációk és a repóban megadottak között, hogy gyorsan tudjanak reagálni az eltérésekre.
4. Értesítések a konfigurációk eltéréséről
Hasznos, amikor az adminisztrátor szeretné gyorsan értesülni a konfigurációk eltéréséről, hogy önállóan gyors intézkedéseket tehessen.
5. Kézi konfigurációszinkronizálás eltérés esetén
Lehetővé teszi az adminisztrátor számára, hogy szinkronizálja az OpenShift klasztert a Git tárral, ha eltérések fordulnak elő, hogy gyorsan visszaállíthassa a klasztert egy korábbi ismert állapotra.
6. Automatikus konfigurációszinkronizálás eltérés esetén
Az adminisztrátor azt is beállíthatja, hogy az OpenShift klaszter automatikusan szinkronizáljon a tárral, ha eltérést észlel, így a klaszter konfigurációja mindig megfelel a Git-ben található konfigurációknak.
7. Több klaszter – egy tároló
Az adminisztrátor egy Git tárolóban tárolhatja több különböző OpenShift klaszter konfigurációját, és szükség szerint szelektíven alkalmazhatja azokat.
8. Klaszterkonfigurációk hierarchiája (öröklés)
Az adminisztrátor hierarchiát állíthat be a klaszterkonfigurációk között a tárolóban (staging, production, alkalmazásportfólió stb. örökléssel). Más szavakkal, meghatározhatja, hogy a konfigurációk hogyan alkalmazandók – egy vagy több klaszterre.
Például, ha az adminisztrátor a Git tárolóban a "Production klaszterek (prod) → X rendszer klaszterei → X rendszer production klaszterei" hierarchiát állít be, akkor az X rendszer production klasztereire az alábbi konfigurációk egyesítése alkalmazásra kerül:
- A minden production klaszterre vonatkozó közös konfigurációk.
- Az X rendszer klaszteréhez tartozó konfigurációk.
- Az X rendszer production klaszteréhez tartozó konfigurációk.
9. Sablonok és konfigurációk felülírása
Az adminisztrátor felülírhatja az örökölt konfigurációk készletét és azok értékeit, például a konfigurációk finomabb beállítása érdekében bizonyos klaszterekhez, amelyekhez alkalmazni fogják őket.
10. Szelektív be- és kizárások konfigurációkra, alkalmazáskonfigurációkra
Az adminisztrátor feltételeket állíthat be a konfigurációk klaszterekhez való alkalmazásának vagy nem alkalmazásának érdekében, bizonyos jellemzőkkel rendelkező klaszterek esetén.
11. Sablonok támogatása
A fejlesztők számára hasznos, hogy választhassák, hogyan határozzák meg az alkalmazás erőforrásait (Helm Chart, tiszta Kubernetes-yaml stb.), hogy a megfelelő formát használhassák minden egyes alkalmazáshoz.
GitOps eszközök az OpenShift platformon
ArgoCD
Az ArgoCD az External Resource Reconcile modellt valósítja meg, és központosított UI-t kínál a klaszterek és a Git-tárhelyek közötti kapcsolatok orchestrálására, egy „egy a többhöz” sémában. A program hátrányai közé tartozik, hogy nem lehet kezelni az alkalmazásokat, ha az ArgoCD nem működik.
Flux
A Flux az On-Cluster Resource Reconcile modellt valósítja meg, így itt nincs központosított definíciós tárhely kezelés, ami gyenge pontként jelentkezik. Másrészről, a központosítás hiánya miatt az alkalmazások kezelése ezekben az esetekben is lehetséges, még akkor is, ha egy klaszter leáll.
ArgoCD telepítése OpenShift környezetbe
Az ArgoCD nagyszerű parancssori felületet és webkonzolt kínál, így nem foglalkozunk itt a Flux-szal és más alternatívákkal.
Az ArgoCD telepítéséhez az OpenShift 4 platformon a következő lépéseket kell végrehajtania klaszteradminisztrátorként:
Az ArgoCD komponenseinek telepítése OpenShift platformon
# 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}')Az ArgoCD Server módosítása, hogy látható legyen az OpenShift Route számára
# 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=RedirectAz ArgoCD Cli Tool telepítése
# 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/argocdAz ArgoCD Server admin jelszavának megváltoztatása
# 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 Ezeknek a lépéseknek a végrehajtása után az ArgoCD Server már kezelhető az ArgoCD WebUI-n keresztül, vagy az ArgoCD Cli parancssori eszközen.
GitOps – soha nem késő
Azt mondják, hogy a „vonat elment”, amikor a lehetőség, hogy valamit megtegyenek, elmulasztásra kerül. Az OpenShift esetében a vágy, hogy azonnal elkezdjük használni ezt az új, fantasztikus platformot, gyakran éppen ezt a helyzetet teremt a nyomvonalak, deployment-ek és más OpenShift objektumok kezelésében és karbantartásában. De mindig végérvényesen el van veszve a lehetőség?
Folytatva a cikkek sorozatát, , ma megmutatjuk, hogyan alakítható át a kézzel létrehozott alkalmazás és annak erőforrásai egy olyan folyamattá, ahol mindent a GitOps eszközkészlet irányít. Ehhez először kézzel telepítjük az httpd alkalmazást. Az alábbi képernyőn látható, hogyan hozunk létre névtér, deployment és szolgáltatás, majd hogyan tesszük elérhetővé ezt a szolgáltatást, hogy létrehozzunk egy nyomvonalat.
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-appTehát, megvan a kézzel létrehozott alkalmazásunk. Most alá kell ontrolálni a GitOps által anélkül, hogy a hozzáférhetőség elveszne. Röviden, ezt így lehet megtenni:
- Git-tárhely létrehozása a kódhoz.
- Exportáljuk a jelenlegi objektumainkat és feltöltjük őket a Git tárolóba.
- Kiválasztjuk és telepítjük a GitOps eszközkészletet.
- Hozzáadjuk a tárolónkhoz ezt az eszközkészletet.
- Meghatározzuk az alkalmazást a GitOps eszközkészletünkben.
- Kísérleti futtatást végzünk az alkalmazáson a GitOps eszközkészletével.
- Szinkronizáljuk az objektumokat a GitOps eszközkészletével.
- Bekapcsoljuk a tisztítást (pruning) és az objektumok automatikus szinkronizálását.
Ahogy már említettük korábban, , a GitOps esetében egyetlen és kizárólagos forrása van az információnak az összes Kubernetes klaszterben található objektumról – a Git tároló. Továbbá arra az előfeltevésre alapozunk, hogy már van Git tároló használatban a szervezeten belül. Ez lehet nyilvános vagy privát, de mindenképpen elérhetőnek kell lennie a Kubernetes klaszterek számára. Ez lehet ugyanaz a tároló, ami az alkalmazás kódjához készült, vagy egy különálló tároló, amelyet kifejezetten a telepítésekhez hoztak létre. A tárolóban javasolt szigorú jogosultságok beállítása, mivel érzékeny biztonsági információkat, mint például titkok, útvonalak és más biztonságilag érzékeny elemek tárolódnak.
Példánkban létrehozunk egy új nyilvános tárolót a GitHub-on. Bármilyen néven elnevezhetjük, mi a blogpost nevet használjuk.
Ha az objektumok YAML-fájljai nem kerültek tárolásra lokálisan vagy Git-ben, akkor az oc vagy kubectl binárisokat kell használnunk. Az alábbi képernyőn kérjük a YAML-t a névtérből, a deploymentból, a szolgáltatásból és az útvonalból. Előtte klónoztuk az imént létrehozott tárolót, és beléptünk a cd parancsal.
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.yamlMost módosítjuk a deployment.yaml fájlt, hogy eltávolítsuk belőle azt a mezőt, amelyet az Argo CD nem tud szinkronizálni.
sed -i '/sgeneration: .* /d' deployment.yamlEzen kívül meg kell változtatnunk az útvonalat. Először definiálunk egy többsoros változót, majd kicseréljük az ingress: null-t ennek a változónak a tartalmára.
export ROUTE=" ingress:
- conditions:
- status: 'True'
type: Admitted"
sed -i "s/ ingress: null/$ROUTE/g" route.yamlTehát, a fájlokat rendezve, most már mentenünk kell őket a Git tárolóba. Ezt követően ez a tároló válik az egyetlen információforrássá, és bármilyen kézi objektumváltoztatás szigorúan tilos.
git commit -am 'az objektumok kezdeti elkötelezése'
git push origin masterTovábbá abból indulunk ki, hogy az ArgoCD már telepítve van (hogyan tehető ez meg – lásd az előző) ). Ezért hozzáadjuk az Argo CD-hez azt a tárolót, amelyet létrehoztunk, és amely a példaalkalmazás kódját tartalmazza. Csak ügyeljen arra, hogy pontosan azt a tárolót adja meg, amelyet korábban létrehozott.
argocd repo add https://github.com/cooktheryan/blogpostMost létrehozzuk az alkalmazást. Az alkalmazás beállítja az értékeket, hogy a GitOps eszköz értse, melyik tárolót és útvonalakat kell használni, melyik OpenShift szükséges az objektumok kezeléséhez, valamint hogy a tároló melyik konkrét ágát kell használni, és hogy szükséges-e az erőforrások automatikus szinkronizálása.
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 Miután az alkalmazás be lett állítva az Argo CD-ben, ez az eszköz elkezdi ellenőrizni a már telepített objektumokat, hogy megfelelnek-e a tárolóban lévő definícióknak. A példa kedvéért az automatikus szinkronizálás és a tisztítás ki van kapcsolva, ezért az elemek egyelőre nem változnak. Vegye figyelembe, hogy az Argo CD felületén az alkalmazásunk állapota „Out of Sync” (Nincs szinkronban) lesz, mivel nincs label-mutató, amelyet az ArgoCD állít be.
Ezért, amikor később elindítjuk a szinkronizálást, az objektumok újra telepítése nem fog végbémenni.
Most végezzünk egy próbaindítást, hogy megbizonyosodjunk arról, hogy a fájljainkban nincsenek hibák.
argocd app sync simple-app --dry-runHa nincsenek hibák, akkor folytathatjuk a szinkronizálást.
argocd app sync simple-appAz argocd get parancs végrehajtása után az alkalmazásunk felett látni fogjuk, hogy az alkalmazás állapota megváltozott Healthy (Egészséges) vagy Synced (Szinkronizált) értékre. Ez azt jelenti, hogy a Git tárolóban található összes erőforrás most megfelel a már telepített erőforrásoknak.
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
... Most már aktiválható az automatikus szinkronizálás és tisztítás, hogy biztosítsuk, hogy semmi ne legyen létrehozva manuálisan, és hogy minden alkalommal, amikor egy objektumot létrehoznak vagy frissítenek a tárolóban, telepítés történjen.
argocd app set simple-app --sync-policy automated --auto-prune Tehát sikeresen átállítottuk a GitOps irányítására azt az alkalmazást, amely eredetileg nem használta a GitOps-ot.
Forrás: habr.com
