ProHoster > Blog > Administratioun > Aféierung zu GitOps fir OpenShift

Aféierung zu GitOps fir OpenShift

Haut wäerte mir iwwer d'Prinzipien a Modeller vu GitOps schwätzen, wéi och wéi dës Modeller op der OpenShift Plattform implementéiert ginn. En interaktive Guide iwwer dëst Thema ass verfügbar Link.

Aféierung zu GitOps fir OpenShift

An enger Nossschuel, GitOps ass eng Rei vu Praktiken fir Git Pull Ufroen ze benotzen fir Infrastruktur an Applikatiounskonfiguratiounen ze managen. De Git Repository an GitOps gëtt als eenzeg Informatiounsquell iwwer den Zoustand vum System behandelt, an all Ännerunge vun dësem Zoustand si voll tracéierbar an auditéierbar.

D'Iddi vum Changement Tracking am GitOps ass op kee Fall nei; dës Approche gouf laang bal universell benotzt wann Dir mat Applikatiounsquellcode schafft. GitOps implementéiert einfach ähnlech Funktiounen (Rezensiounen, Pull-Ufroen, Tags, etc.) an der Infrastruktur- an Applikatiounskonfiguratiounsmanagement a bitt ähnlech Virdeeler wéi am Fall vun der Quellcodemanagement.

Et gëtt keng akademesch Definitioun oder genehmegt Set vu Reegele fir GitOps, nëmmen eng Rei vu Prinzipien op deenen dës Praxis opgebaut ass:

  • Déi deklarativ Beschreiwung vum System gëtt am Git Repository (Configuratioun, Iwwerwaachung, etc.) gespäichert.
  • Staat Ännerungen ginn duerch Pull Ufroe gemaach.
  • Den Zoustand vun de lafende Systemer gëtt mat den Donnéeën am Repository mat Git Push Ufroen agefouert.

GitOps Prinzipien

  • Systemdefinitioune ginn als Quellcode beschriwwen

D'Systemkonfiguratioun gëtt als Code behandelt, sou datt et an engem Git Repository gelagert an automatesch Versioun ka ginn, deen als eenzeg Quell vun der Wourecht déngt. Dës Approche mécht et einfach ze rollout an rollback Ännerungen an Systemer.

  • De gewënschten Zoustand an d'Konfiguratioun vun de Systemer ginn a Git gesat a Versioun Versioun

Andeems Dir de gewënschten Zoustand vun de Systemer am Git späichert an verännert, kënne mir einfach Ännerungen op Systemer an Uwendungen ausrollen an zréckrollen. Mir kënnen och dem Git seng Sécherheetsmechanismen benotze fir Codebesëtzer ze kontrolléieren an seng Authentizitéit z'iwwerpréiwen.

  • Konfiguratiounsännerunge kënnen automatesch iwwer Pull-Ufroen applizéiert ginn

Mat Git Pull Ufroe kënne mir einfach kontrolléieren wéi Ännerungen op Konfiguratiounen am Repository applizéiert ginn. Zum Beispill kënne se un aner Teammembere fir Iwwerpréiwung ginn oder duerch CI Tester lafen, etc.

A gläichzäiteg ass et net néideg d'Administratiounsmuecht lénks a riets ze verdeelen. Fir Konfiguratiounsännerungen ze maachen, brauche d'Benotzer nëmmen entspriechend Permissiounen am Git Repository wou dës Konfiguratiounen gespäichert sinn.

  • Befestegt de Problem vun onkontrolléierten Drift vun Konfiguratiounen

Wann de gewënschten Zoustand vum System an engem Git Repository gespäichert ass, alles wat mir maache mussen ass Software ze fannen déi garantéiert datt den aktuellen Zoustand vum System mat sengem gewënschten Zoustand entsprécht. Wann dat net de Fall ass, da sollt dës Software - ofhängeg vun den Astellungen - entweder d'Diskrepanz eleng eliminéieren, oder eis iwwer d'Konfiguratiounsdrift informéieren.

GitOps Modeller fir OpenShift

On-Cluster Ressource Reconciler

Geméiss dësem Modell huet de Cluster e Controller dee verantwortlech ass fir Kubernetes Ressourcen (YAML Dateien) am Git Repository mat de reelle Ressourcen vum Cluster ze vergläichen. Wann Differenzen festgestallt ginn, schéckt de Controller Notifikatiounen a mécht méiglecherweis Handlung fir d'Diskrepanzen ze korrigéieren. Dëse GitOps Modell gëtt an Anthos Config Management a Weaveworks Flux benotzt.

Aféierung zu GitOps fir OpenShift

Extern Ressource Reconciler (Push)

Dëse Modell kann als Variatioun vun der viregter ugesi ginn, wa mir een oder méi Controller hunn, verantwortlech fir d'Synchroniséierung vu Ressourcen am "Git Repository - Kubernetes Cluster" Pairen. Den Ënnerscheed hei ass datt all geréiert Stärekoup net onbedéngt säin eegene separaten Controller huet. Git - k8s Cluster Pairen ginn dacks als CRDs definéiert (Custom Ressource Definitiounen), déi kënne beschreiwen wéi de Controller Synchroniséierung soll ausféieren. Bannent dësem Modell vergläichen d'Controller de Git Repository, deen am CRD spezifizéiert ass, mat de Kubernetes Cluster Ressourcen, déi och an der CRD spezifizéiert sinn, a maachen entspriechend Aktiounen op Basis vun de Resultater vum Verglach. Besonnesch gëtt dëse GitOps Modell an ArgoCD benotzt.

Aféierung zu GitOps fir OpenShift

GitOps op der OpenShift Plattform

Administratioun vu Multi-Cluster Kubernetes Infrastruktur

Mat der Verbreedung vu Kubernetes an der wuessender Popularitéit vu Multi-Cloud Strategien a Rand Computing, ass déi duerchschnëttlech Unzuel vun OpenShift Cluster pro Client och erop.

Zum Beispill, wann Dir Edge Computing benotzt, kënnen d'Cluster vun engem Client an Honnerte oder souguer Dausende ofgesat ginn. Als Resultat ass hien gezwongen e puer onofhängeg oder koordinéiert OpenShift Cluster an der ëffentlecher Cloud an on-premise ze managen.

An dësem Fall musse vill Problemer geléist ginn, besonnesch:

  • Kontrolléieren datt d'Cluster an engem identesche Staat sinn (Konfiguratiounen, Iwwerwaachung, Lagerung, asw.)
  • Erstellt (oder restauréiert) Cluster baséiert op engem bekannten Zoustand.
  • Erstellt nei Cluster baséiert op engem bekannte Staat.
  • Roll Ännerunge fir verschidde OpenShift Cluster aus.
  • Roll zréck Ännerungen iwwer verschidde OpenShift Cluster.
  • Link Schabloun Konfiguratiounen zu verschiddenen Ëmfeld.

Applikatioun Konfiguratiounen

Wärend hirem Liewenszyklus passéieren Uwendungen dacks duerch eng Kette vu Stärekéip (Dev, Bühn, etc.) ier se an engem Produktiounscluster ophalen. Zousätzlech, wéinst Disponibilitéit a Skalierbarkeet Ufuerderunge, setzen d'Clienten dacks Uwendungen iwwer verschidde on-premise Cluster oder verschidde Regioune vun enger ëffentlecher Cloud Plattform of.

An dësem Fall mussen déi folgend Aufgaben geléist ginn:

  • Sécherstellen d'Bewegung vun Uwendungen (Binaries, Konfiguratiounen, etc.) tëscht Cluster (Dev, Bühn, etc.).
  • Roll Ännerunge fir Uwendungen (Binaries, Konfiguratiounen, etc.) a verschiddene OpenShift Cluster aus.
  • Roll zréck Ännerungen un Uwendungen op e fréiere bekannte Staat.

OpenShift GitOps Benotzungsfäll

1. Ännerunge vum Git Repository uwenden

E Cluster Administrateur kann OpenShift Cluster Konfiguratiounen an engem Git Repository späicheren an se automatesch applizéieren fir ouni Ustrengung nei Cluster ze kreéieren an se an e Staat ze bréngen identesch mat dem bekannte Staat am Git Repository gespäichert.

2. Synchroniséierung mat Secret Manager

Den Administrateur profitéiert och vun der Fäegkeet OpenShift Geheimobjekter mat passenden Software wéi Vault ze synchroniséieren fir se ze verwalten mat Tools déi speziell dofir erstallt goufen.

3. Kontroll vun Driftskonfiguratiounen

Den Admin wäert nëmme fir wann OpenShift GitOps selwer identifizéiert a warnt iwwer Differenzen tëscht realen Konfiguratiounen an deenen, déi am Repository spezifizéiert sinn, sou datt se séier op Drift reagéiere kënnen.

4. Notifikatiounen iwwer Configuratioun Drift

Si sinn nëtzlech am Fall wou den Administrateur séier iwwer Fäll vu Konfiguratiounsdrift léiere wëll fir séier eegent Moossnamen ze huelen.

5. Manuell Synchroniséierung vun Konfiguratiounen wann dreiwend

Erlaabt dem Administrateur den OpenShift Cluster mam Git Repository ze synchroniséieren am Fall vu Konfiguratiounsdrift, fir de Cluster séier an e fréiere bekannten Zoustand zréckzekommen.

6.Auto-Synchroniséierung vu Konfiguratiounen beim Drift

Den Administrator kann och den OpenShift Cluster konfiguréieren fir automatesch mam Repository ze synchroniséieren wann e Drift festgestallt gëtt, sou datt d'Clusterkonfiguratioun ëmmer mat de Konfiguratiounen am Git entsprécht.

7. Verschidde Cluster - ee Repository

Den Administrateur kann Konfiguratioune vu verschiddene OpenShift Cluster an engem Git Repository späicheren a se selektiv applizéieren wéi néideg.

8. Hierarchie vu Clusterkonfiguratiounen (Ierfschaft)

Den Admin kann eng Hierarchie vu Clusterkonfiguratiounen am Repository setzen (Bühn, Prod, App Portfolio, etc. mat Ierfschaft). An anere Wierder, et kann bestëmmen ob Konfiguratiounen op een oder méi Cluster applizéiert ginn.

Zum Beispill, wann en Administrateur d'Hierarchie "Produktiounscluster (Prod) → System X Cluster → Produktiounscluster vum System X" am Git Repository setzt, da gëtt eng Kombinatioun vun de folgende Konfiguratiounen op d'Produktiounscluster vum System X applizéiert:

  • Konfiguratioune gemeinsam fir all Produktiounscluster.
  • Konfiguratioun fir de System X Cluster.
  • Konfiguratioun fir den X System Produktiounscluster.

9. Schablounen an Configuratioun iwwerdribblen

Den Administrateur kann eng Rei vun ierfleche Konfiguratiounen an hir Wäerter iwwerschreiden, zum Beispill, fir d'Konfiguratioun fir spezifesch Cluster ze feinjustéieren, op déi se applizéiert ginn.

10. Selektiv enthalen an ausgeschloss fir Konfiguratiounen, Applikatiounskonfiguratiounen

Den Administrateur kann d'Konditioune fir d'Applikatioun oder Net-Uwendung vu bestëmmte Konfiguratiounen op Cluster mat bestëmmte Charakteristike setzen.

11. Schabloun Ënnerstëtzung

D'Entwéckler profitéiere vun der Fäegkeet fir ze wielen wéi d'Applikatiounsressourcen definéiert ginn (Helm Chart, pure Kubernetes yaml, etc.) fir dat passendst Format fir all spezifesch Applikatioun ze benotzen.

GitOps Tools op der OpenShift Plattform

ArgoCD

ArgoCD implementéiert den External Resource Reconcile Modell a bitt eng zentraliséiert UI fir eng-zu-vill Relatiounen tëscht Cluster a Git Repositories z'orchestréieren. D'Nodeeler vun dësem Programm enthalen d'Onméiglechkeet fir Uwendungen ze managen wann ArgoCD net funktionnéiert.

Offiziell Websäit

onkontrolléiert

Flux implementéiert en On-Cluster Resource Reconcile Modell an, als Resultat, gëtt et keng zentraliséiert Gestioun vum Definitiounsrepository, wat e schwaache Punkt ass. Op der anerer Säit, genee wéinst dem Mangel u Zentraliséierung, bleift d'Fäegkeet fir Uwendungen ze managen, och wann ee Stärekoup feelt.

Offiziell Websäit

Installéiert ArgoCD op OpenShift

ArgoCD bitt eng exzellent Kommandozeil-Interface a Webkonsole, sou datt mir Flux an aner Alternativen hei net ofdecken.

Fir ArgoCD op der OpenShift 4 Plattform z'installéieren, befollegt dës Schrëtt als Clusteradministrator:

Deploy ArgoCD Komponenten op der OpenShift Plattform

# 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}')

Verbesserung vum ArgoCD Server sou datt et duerch OpenShift Route gesi ka ginn

# 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

Deploy ArgoCD Cli Tool

# 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

Änneren vum ArgoCD Server Admin Passwuert

# 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

Nodeems Dir dës Schrëtt ofgeschloss hutt, kënnt Dir mam ArgoCD Server iwwer d'ArgoCD WebUI Webkonsole oder den ArgoCD Cli Kommandozeil Tool schaffen.
https://blog.openshift.com/is-it-too-late-to-integrate-gitops/

GitOps - Et ass ni ze spéit

"Den Zuch ass fortgaang" - dat ass wat se soen iwwer eng Situatioun wou d'Méiglechkeet eppes ze maachen verpasst ass. Am Fall vun OpenShift, de Wonsch direkt unzefänken dës cool nei Plattform ze benotzen schaaft dacks genee dës Situatioun mat der Gestioun an Ënnerhalt vu Strecken, Deployementer an aner OpenShift Objeten. Awer ass d'Chance ëmmer komplett verluer?

Weider der Serie vun Artikelen iwwer GitOps, Haut wäerte mir Iech weisen wéi Dir eng handgemaachte Applikatioun a seng Ressourcen an e Prozess transforméiert wou alles mat GitOps Tools geréiert gëtt. Fir dëst ze maachen, wäerte mir als éischt d'httpd Applikatioun manuell ofsetzen. De Screenshot hei ënnen weist wéi mir e Nummraum, Deployment a Service erstellen, an dann dëse Service ausstelle fir e Wee ze kreéieren.

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

Also hu mir eng handgemaachte Applikatioun. Elo muss et ënner GitOps Gestioun transferéiert ginn ouni Verloscht vun Disponibilitéit. Kuerz gesot, et mécht dëst:

  • Erstellt e Git Repository fir de Code.
  • Mir exportéieren eis aktuell Objekter an lued se an de Git Repository erop.
  • GitOps Tools auswielen an ofsetzen.
  • Mir addéieren eise Repository zu dësem Toolkit.
  • Mir definéieren d'Applikatioun an eisem GitOps Toolkit.
  • Mir maachen en Testrun vun der Applikatioun mam GitOps Toolkit.
  • Mir synchroniséieren Objekter mat dem GitOps Toolkit.
  • Aktivéiert Pruning an Auto-Synchroniséierung vun Objeten.

Wéi an der viregter ernimmt Artikel, an GitOps gëtt et eng an nëmmen eng Informatiounsquell iwwer all Objeten am Kubernetes Cluster(en) - de Git Repository. Als nächst gi mir aus der Viraussetzung datt Är Organisatioun schonn e Git Repository benotzt. Et kann ëffentlech oder privat sinn, awer et muss zougänglech sinn fir Kubernetes Cluster. Dëst kann deeselwechte Repository sinn wéi fir Applikatiounscode, oder e separaten Repository erstallt speziell fir Deployementer. Et ass recommandéiert strikt Permissiounen am Repository ze hunn, well Geheimnisser, Strecken an aner Sécherheetsempfindlech Saachen do gespäichert ginn.

An eisem Beispill wäerte mir en neien ëffentleche Repository op GitHub erstellen. Dir kënnt et nennen wat Dir wëllt, mir benotzen den Numm Blogpost.

Wann d'YAML Objektdateien net lokal oder a Git gelagert goufen, da musst Dir d'oc oder kubectl Binären benotzen. Am Screenshot hei ënnen froe mir YAML fir eisen Nummraum, Deployment, Service a Route. Virun dësem hu mir den nei erstallte Repository an CD an et gekloont.

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

Loosst eis elo d'Deployment.yaml Datei änneren fir de Feld ze läschen deen Argo CD net synchroniséiere kann.

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

Ausserdeem muss de Wee geännert ginn. Mir setzen als éischt eng Multiline Variabel an ersetzen dann Ingress: null mam Inhalt vun där Variabel.

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

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

Also, mir hunn d'Fichier'en zortéiert, alles wat bleift ass se an de Git Repository ze späicheren. Duerno gëtt dëse Repository déi eenzeg Informatiounsquell, an all manuell Ännerunge fir Objete solle strikt verbueden ginn.

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

Weider gi mir aus der Tatsaach datt Dir ArgoCD schonn ofgesat hutt (wéi Dir dëst maacht - kuckt virdrun posten). Dofir addéiere mir op d'Argo CD de Repository, dee mir erstallt hunn, mat dem Applikatiounscode aus eisem Beispill. Gitt sécher datt Dir de genaue Repository spezifizéiert deen Dir virdru erstallt hutt.

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

Loosst eis elo d'Applikatioun erstellen. D'Applikatioun setzt Wäerter sou datt de GitOps Toolkit versteet wéi ee Repository a Weeër ze benotzen, wéi eng OpenShift gebraucht gëtt fir Objekter ze managen, wéi eng spezifesch Branche vum Repository gebraucht gëtt, an ob Ressourcen automatesch solle synchroniséieren.

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

Wann eng Applikatioun an der Argo CD spezifizéiert ass, fänkt d'Toolkit un d'Kontroll vu scho ofgebauten Objeten géint d'Definitiounen am Repository. An eisem Beispill sinn d'Auto-Synchroniséierung an d'Botzen behënnert, sou datt d'Elementer nach net änneren. Notéiert w.e.g. datt an der Argo CD Interface eis Applikatioun de Status "Out of Sync" huet well et kee Label ass deen ArgoCD ubitt.
Dofir, wa mir d'Synchroniséierung e bësse méi spéit ufänken, ginn d'Objeten net ëmgesat.

Loosst eis elo en Testlaf maachen fir sécher ze stellen datt et keng Feeler an eise Dateien gëtt.

argocd app sync simple-app --dry-run

Wann et keng Feeler sinn, da kënnt Dir op d'Synchroniséierung virugoen.

argocd app sync simple-app

Nodeems Dir den argocd get Kommando op eiser Applikatioun ausgefouert hutt, sollte mir gesinn datt den Uwendungsstatus op Healthy oder Synchroniséiert geännert huet. Dëst bedeit datt all Ressourcen am Git Repository elo mat deene Ressourcen entspriechen déi scho ofgesat goufen.

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
...

Elo kënnt Dir Auto-Synchroniséierung a Botzen aktivéieren fir sécherzestellen datt näischt manuell erstallt gëtt an datt all Kéier wann en Objet erstallt oder am Repository aktualiséiert gëtt, en Deployement geschitt.

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

Also, mir hunn erfollegräich eng Applikatioun ënner GitOps Kontroll bruecht déi ufanks GitOps op keng Manéier benotzt huet.

Source: will.com

Setzt e Commentaire