🥇A GitOps for OpenShift bemutatása

Ma a GitOps alapelveiről és modelljeiről fogunk beszélni, valamint arról, hogyan valósulnak meg ezek a modellek az OpenShift platformon. Ebben a témában interaktív útmutató áll rendelkezésre по ссылке.

Dióhéjban a GitOps gyakorlatok halmaza a Git lekérési kérelmek használatára az infrastruktúra és az alkalmazáskonfigurációk kezelésére. A GitOps Git-tárát a rendszer egyetlen információforrásként kezeli a rendszer állapotáról, és ezen állapot bármely változása teljes mértékben nyomon követhető és auditálható.

A változáskövetés ötlete a GitOps-ban korántsem új, ezt a megközelítést már régóta szinte univerzálisan alkalmazzák az alkalmazás forráskódjával való munka során. A GitOps egyszerűen megvalósítja a hasonló funkciókat (áttekintések, lekérési kérések, címkék stb.) az infrastruktúra és az alkalmazások konfigurációkezelésében, és hasonló előnyöket biztosít, mint a forráskód-kezelés esetében.

A GitOps számára nincs tudományos definíció vagy jóváhagyott szabálykészlet, csak egy sor alapelv, amelyre ez a gyakorlat épül:

A rendszer deklaratív leírását a Git repository tárolja (konfigurációk, figyelés stb.).
Az állapotváltozások lehívási kérelmekkel történnek.
A futó rendszerek állapotát a Git push kérések segítségével hozzák összhangba a lerakatban lévő adatokkal.

GitOps alapelvek

A rendszerdefiníciók leírása forráskód

A rendszerkonfigurációt kódként kezeljük, így tárolható és automatikusan verziószámítható egy Git tárolóban, amely az igazság egyetlen forrásaként szolgál. Ez a megközelítés megkönnyíti a rendszerek módosításainak bevezetését és visszaállítását.

A rendszerek kívánt állapota és konfigurációja a Gitben van beállítva és verziószámítva

A kívánt rendszerek állapotának Gitben való tárolásával és verziószámával könnyedén kivezethetjük és visszaállíthatjuk a rendszerek és alkalmazások módosításait. A Git biztonsági mechanizmusait is használhatjuk a kód tulajdonjogának ellenőrzésére és annak hitelességének ellenőrzésére.

A konfigurációs változtatások automatikusan végrehajthatók lekérési kérelmekkel

A Git lekérési kérelmek segítségével egyszerűen szabályozhatjuk, hogy a változtatások hogyan vonatkozzanak a lerakat konfigurációira. Például át lehet adni őket a csapat többi tagjának áttekintésre, vagy át lehet futtatni a CI-teszteken stb.

Ugyanakkor nincs szükség az adminisztrátori jogkörök jobbra és balra osztására. A konfigurációs módosítások végrehajtásához a felhasználóknak csak a megfelelő engedélyekre van szükségük abban a Git-lerakatban, ahol ezek a konfigurációk vannak tárolva.

A konfigurációk ellenőrizetlen eltolódásának problémájának megoldása

Miután a rendszer kívánt állapotát eltároltuk egy Git repository-ban, már csak olyan szoftvert kell találnunk, amely biztosítja, hogy a rendszer aktuális állapota megfeleljen a kívánt állapotnak. Ha ez nem így van, akkor ennek a szoftvernek - a beállításoktól függően - vagy önmagában kell megszüntetnie az eltérést, vagy értesítenie kell minket a konfigurációs eltolódásról.

GitOps modellek az OpenShifthez

On-Cluster Resource Conciler

E modell szerint a fürt rendelkezik egy vezérlővel, amely a Git-lerakatban lévő Kubernetes-erőforrások (YAML-fájlok) összehasonlításáért felelős a fürt valós erőforrásaival. Ha eltéréseket észlel, a vezérlő értesítést küld, és esetleg intézkedéseket tesz az eltérések kijavítására. Ezt a GitOps-modellt az Anthos Config Management és a Weaveworks Flux használják.

Külső erőforrás-egyeztető (push)

Ez a modell az előző variációjának tekinthető, amikor a „Git repository - Kubernetes cluster” párban egy vagy több vezérlőnk van, amely az erőforrások szinkronizálásáért felelős. A különbség itt az, hogy minden felügyelt fürtnek nem feltétlenül van saját külön vezérlője. A Git - k8s fürtpárokat gyakran CRD-ként (egyéni erőforrás-definícióként) határozzák meg, amelyek leírhatják, hogy a vezérlőnek hogyan kell végrehajtania a szinkronizálást. Ezen a modellen belül a vezérlők összehasonlítják a CRD-ben meghatározott Git-tárat a CRD-ben is meghatározott Kubernetes-fürt erőforrásokkal, és az összehasonlítás eredményei alapján megfelelő műveleteket hajtanak végre. Különösen ezt a GitOps modellt használják az ArgoCD-ben.

GitOps az OpenShift platformon

Több klaszteres Kubernetes infrastruktúra adminisztrációja

A Kubernetes térhódításával, valamint a többfelhős stratégiák és az élszámítástechnika növekvő népszerűségével az OpenShift-fürtök ügyfélenkénti átlagos száma is növekszik.

Például szélsőséges számítástechnika használatakor egy ügyfél fürtjei több száz vagy akár több ezer is telepíthetők. Ennek eredményeként több független vagy koordinált OpenShift-fürtöt kénytelen kezelni a nyilvános felhőben és a helyszínen.

Ebben az esetben sok problémát meg kell oldani, különösen:

Annak vezérlése, hogy a fürtök azonos állapotban legyenek (konfigurációk, figyelés, tárolás stb.)
Klaszterek újbóli létrehozása (vagy visszaállítása) ismert állapot alapján.
Hozzon létre új klasztereket egy ismert állapot alapján.
Több OpenShift-fürt módosításainak bevezetése.
A módosítások visszaállítása több OpenShift-fürtben.
Sablonos konfigurációk összekapcsolása különböző környezetekkel.

Alkalmazás konfigurációk

Életciklusuk során az alkalmazások gyakran áthaladnak egy fürtláncon (fejlesztő, szakasz stb.), mielőtt egy éles fürtbe kerülnének. Ezenkívül a rendelkezésre állási és méretezhetőségi követelmények miatt az ügyfelek gyakran több helyszíni fürtben vagy egy nyilvános felhőplatform több régiójában telepítenek alkalmazásokat.

Ebben az esetben a következő feladatokat kell megoldani:

Biztosítsa az alkalmazások (binárisok, konfigurációk stb.) mozgását a fürtök között (fejlesztő, színpad stb.).
Az alkalmazások (binárisok, konfigurációk stb.) módosításai bevezetése több OpenShift-fürtben.
Az alkalmazások módosításainak visszaállítása egy korábbi ismert állapotba.

OpenShift GitOps használati esetek

1. Módosítások alkalmazása a Git-tárból

A fürt adminisztrátora tárolhatja az OpenShift-fürtkonfigurációkat egy Git-lerakatban, és automatikusan alkalmazhatja azokat új fürtök könnyű létrehozásához, és a Git-lerakatban tárolt ismert állapottal azonos állapotba hozásához.

2. Szinkronizálás a Secret Managerrel

Az adminisztrátor előnyére válik az OpenShift titkos objektumok megfelelő szoftverekkel, például a Vault-tal történő szinkronizálásának lehetősége is, hogy a speciálisan erre a célra létrehozott eszközökkel kezelhesse őket.

3. A sodródási konfigurációk vezérlése

Az adminisztrátor csak akkor jár el, ha az OpenShift GitOps maga azonosítja és figyelmezteti a valós konfigurációk és a tárolóban megadottak közötti eltéréseket, hogy gyorsan reagálhassanak a sodródásra.

4. Értesítések a konfiguráció eltolódásáról

Hasznosak abban az esetben, ha az adminisztrátor gyorsan szeretne tájékozódni a konfigurációs sodródás eseteiről, hogy gyorsan meg tudja tenni a megfelelő intézkedéseket.

5. A konfigurációk kézi szinkronizálása sodródáskor

Lehetővé teszi, hogy a rendszergazda szinkronizálja az OpenShift-fürtöt a Git-tárral a konfigurációs eltolódások esetén, hogy gyorsan visszaállítsa a fürt korábbi ismert állapotát.

6. A konfigurációk automatikus szinkronizálása sodródáskor

Az adminisztrátor úgy is beállíthatja az OpenShift-fürtöt, hogy az automatikusan szinkronizáljon a tárhellyel, amikor a rendszer eltolódást észlel, így a fürt konfigurációja mindig megegyezik a Git konfigurációival.

7. Több klaszter – egy adattár

Az adminisztrátor több különböző OpenShift-fürt konfigurációit tárolhatja egy Git-lerakatban, és szükség szerint szelektíven alkalmazhatja azokat.

8. A fürtkonfigurációk hierarchiája (öröklődés)

Az adminisztrátor beállíthatja a fürtkonfigurációk hierarchiáját a lerakatban (szakasz, prod, alkalmazásportfólió stb. örökléssel). Más szavakkal, meghatározhatja, hogy a konfigurációkat egy vagy több fürtre kell-e alkalmazni.

Például, ha egy adminisztrátor beállítja a „Termelő fürtök (termék) → X rendszer fürtjei → X rendszer termelési fürtjei” hierarchiát a Git lerakatban, akkor a következő konfigurációk kombinációja kerül alkalmazásra az X rendszer éles fürtjeire:

Az összes éles klaszterben közös konfigurációk.
A System X fürt konfigurációi.
Az X rendszer éles fürtjének konfigurációi.

9. Sablonok és konfigurációs felülírások

Az adminisztrátor felülírhatja az örökölt konfigurációkat és azok értékeit, például az adott fürtök konfigurációjának finomhangolásához, amelyekre alkalmazni fogják őket.

10. Szelektív be- és kizárás konfigurációkhoz, alkalmazáskonfigurációkhoz

Az adminisztrátor beállíthatja a feltételeket bizonyos konfigurációk alkalmazásának vagy nem alkalmazásának feltételeit bizonyos jellemzőkkel rendelkező fürtökhöz.

11. Sablon támogatás

A fejlesztők számára előnyös, hogy megválaszthatják az alkalmazás-erőforrások meghatározásának módját (Helm Chart, tiszta Kubernetes yaml stb.), hogy az egyes alkalmazásokhoz a legmegfelelőbb formátumot használják.

GitOps eszközök az OpenShift platformon

ArgoCD

Az ArgoCD az External Resource Reconcile modellt valósítja meg, és központosított felhasználói felületet kínál a fürtök és a Git-tárolók közötti egy-a többhez kapcsolatok összehangolásához. Ennek a programnak a hátrányai közé tartozik, hogy nem tudja kezelni az alkalmazásokat, amikor az ArgoCD nem működik.

Hivatalos oldal

Fényáram

A Flux egy On-Cluster Resource Reconcile modellt valósít meg, és ennek eredményeként nincs központosított felügyeleti definíciós tárház, ami gyenge pont. Másrészt éppen a központosítás hiánya miatt az alkalmazások kezelésének képessége akkor is megmarad, ha valamelyik klaszter meghibásodik.

Hivatalos oldal

Az ArgoCD telepítése OpenShift-re

Az ArgoCD kiváló parancssori felületet és webkonzolt kínál, ezért itt nem térünk ki a Fluxra és más alternatívákra.

Az ArgoCD OpenShift 4 platformon történő üzembe helyezéséhez fürtrendszergazdaként kövesse az alábbi lépéseket:

ArgoCD összetevők telepítése az 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 továbbfejlesztése, hogy az OpenShift Route által is látható legyen

# 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

Az ArgoCD Cli eszköz 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/argocd

Az ArgoCD Server rendszergazdai jelszó módosítá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

A lépések elvégzése után az ArgoCD Serverrel az ArgoCD WebUI webkonzolon vagy az ArgoCD Cli parancssori eszközön keresztül dolgozhat.
https://blog.openshift.com/is-it-too-late-to-integrate-gitops/

GitOps – Soha nem késő

„Elment a vonat” - ezt mondják egy olyan helyzetről, amikor elszalasztják a lehetőséget, hogy tegyenek valamit. Az OpenShift esetében az a vágy, hogy azonnal elkezdjük használni ezt a nagyszerű új platformot, gyakran pontosan ezt a helyzetet teremti meg az útvonalak, telepítések és más OpenShift-objektumok kezelésével és karbantartásával kapcsolatban. De vajon mindig teljesen kimarad a lehetőség?

A cikksorozat folytatása arról GitOps, ma megmutatjuk, hogyan alakíthat át egy kézzel készített alkalmazást és erőforrásait olyan folyamattá, amelyben mindent a GitOps eszközök kezelnek. Ehhez először manuálisan telepítjük a httpd alkalmazást. Az alábbi képernyőképen látható, hogyan hozhatunk létre névteret, üzembe helyezést és szolgáltatást, majd tesszük közzé ezt a szolgáltatást az útvonal létrehozásához.

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

Tehát van egy kézzel készített alkalmazásunk. Most át kell vinni a GitOps felügyelet alá anélkül, hogy elveszítené a rendelkezésre állást. Röviden ezt teszi:

Hozzon létre egy Git-tárat a kódhoz.
Aktuális objektumainkat exportáljuk, és feltöltjük a Git-tárba.
GitOps eszközök kiválasztása és telepítése.
Ehhez az eszköztárhoz adjuk hozzá a tárhelyünket.
Az alkalmazást a GitOps eszköztárunkban határozzuk meg.
A GitOps eszközkészlettel teszteljük az alkalmazást.
Az objektumokat a GitOps eszközkészlettel szinkronizáljuk.
Engedélyezze az objektumok metszését és automatikus szinkronizálását.

Ahogy az előzőben már említettük cikk, a GitOpsban egy és egyetlen információforrás van a Kubernetes-fürt(ek)ben lévő összes objektumról - a Git-tárház. Ezután abból indulunk ki, hogy szervezete már használ Git-tárat. Lehet nyilvános vagy privát, de elérhetőnek kell lennie a Kubernetes-fürtök számára. Ez lehet ugyanaz a lerakat, mint az alkalmazáskód esetében, vagy egy különálló, kifejezetten a telepítésekhez létrehozott lerakat. Javasoljuk, hogy szigorú engedélyekkel rendelkezzen a tárolóban, mivel a titkok, útvonalak és egyéb biztonsági szempontból érzékeny dolgok lesznek ott tárolva.

Példánkban egy új nyilvános adattárat fogunk létrehozni a GitHubon. Nevezheted, ahogy akarod, mi a blogbejegyzés elnevezést használjuk.

Ha a YAML objektumfájlokat nem helyben vagy Gitben tárolták, akkor az oc vagy a kubectl binárisokat kell használnia. Az alábbi képernyőképen YAML-t kérünk névterünkhöz, telepítésünkhöz, szolgáltatásunkhoz és útvonalunkhoz. Ezt megelőzően az újonnan létrehozott repository-t és a cd-t klónoztuk bele.

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

Most szerkesszük a deployment.yaml fájlt, hogy eltávolítsuk azt a mezőt, amelyet az Argo CD nem tud szinkronizálni.

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

Ráadásul az útvonalat is módosítani kell. Először beállítunk egy többsoros változót, majd az ingress: null-t lecseréljük a változó tartalmára.

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

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

Tehát rendeztük a fájlokat, csak el kell menteni őket a Git tárolóba. Ezt követően ez a tár lesz az egyetlen információforrás, és az objektumok bármilyen manuális módosítását szigorúan meg kell tiltani.

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

Továbbá abból indulunk ki, hogy már telepítette az ArgoCD-t (hogyan kell ezt megtenni - lásd az előzőt posta). Ezért hozzáadjuk az Argo CD-hez az általunk létrehozott tárolót, amely a példánkból származó alkalmazáskódot tartalmazza. Csak győződjön meg arról, hogy pontosan a korábban létrehozott tárat adja meg.

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

Most hozzuk létre az alkalmazást. Az alkalmazás úgy állít be értékeket, hogy a GitOps eszközkészlet megértse, melyik tárolót és elérési utat kell használni, melyik OpenShift szükséges az objektumok kezeléséhez, a tár melyik ágára van szükség, és hogy az erőforrásokat kell-e automatikusan szinkronizálni.

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 Argo CD-n meg van adva egy alkalmazás, az eszközkészlet megkezdi a már telepített objektumok ellenőrzését a lerakatban található definíciók alapján. Példánkban az automatikus szinkronizálás és tisztítás le van tiltva, így az elemek még nem változnak. Kérjük, vegye figyelembe, hogy az Argo CD felületén az alkalmazásunk állapota „Out of Sync” lesz, mivel az ArgoCD-nek nincs címke.
Ez az oka annak, hogy amikor egy kicsit később kezdjük el a szinkronizálást, az objektumok nem kerülnek újratelepítésre.

Most végezzünk egy próbaüzemet, hogy megbizonyosodjunk arról, hogy nincsenek-e hibák a fájljainkban.

argocd app sync simple-app --dry-run

Ha nincs hiba, akkor folytathatja a szinkronizálást.

argocd app sync simple-app

Miután futtattuk az argocd get parancsot az alkalmazásunkon, látnunk kell, hogy az alkalmazás állapota egészségesre vagy szinkronizáltra változott. Ez azt jelenti, hogy a Git-tárhely összes erőforrása 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:        <none>
Sync Status:        Synced to master (60e1678)
Health Status:      Healthy
...

Mostantól engedélyezheti az automatikus szinkronizálást és tisztítást, így biztosítva, hogy semmi sem jön létre manuálisan, és minden alkalommal, amikor egy objektumot létrehoznak vagy frissítenek a lerakatban, telepítésre kerüljön sor.

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

Tehát sikeresen átvezettünk egy olyan alkalmazást a GitOps vezérlés alá, amely kezdetben semmilyen módon nem használta a GitOps-t.

Forrás: will.com

Az OpenShifthez készült GitOps bemutatása