Einführung in GitOps für OpenShift

Heute werden wir über die Prinzipien und Modelle von GitOps sprechen und darüber, wie diese Modelle auf der OpenShift-Plattform implementiert werden. Zu diesem Thema steht ein interaktiver Leitfaden zur Verfügung Link.

Kurz gesagt handelt es sich bei GitOps um eine Reihe von Praktiken zur Verwendung von Git-Pull-Anfragen zur Verwaltung von Infrastruktur- und Anwendungskonfigurationen. Das Git-Repository in GitOps wird als einzige Informationsquelle über den Zustand des Systems behandelt und alle Änderungen an diesem Zustand sind vollständig nachvollziehbar und überprüfbar.

Die Idee der Änderungsverfolgung in GitOps ist keineswegs neu; dieser Ansatz wird seit langem fast überall bei der Arbeit mit Anwendungsquellcode verwendet. GitOps implementiert einfach ähnliche Funktionen (Reviews, Pull Requests, Tags usw.) im Infrastruktur- und Anwendungskonfigurationsmanagement und bietet ähnliche Vorteile wie im Fall der Quellcodeverwaltung.

Es gibt keine akademische Definition oder ein anerkanntes Regelwerk für GitOps, sondern lediglich eine Reihe von Prinzipien, auf denen diese Praxis aufbaut:

• Die deklarative Beschreibung des Systems wird im Git-Repository gespeichert (Konfigurationen, Überwachung usw.).
• Zustandsänderungen werden durch Pull-Requests vorgenommen.
• Mithilfe von Git-Push-Requests wird der Zustand laufender Systeme mit den Daten im Repository abgeglichen.

GitOps-Prinzipien

• Systemdefinitionen werden als Quellcode beschrieben

Die Systemkonfiguration wird als Code behandelt, sodass sie in einem Git-Repository gespeichert und automatisch versioniert werden kann, das als einzige Quelle der Wahrheit dient. Dieser Ansatz erleichtert das Rollout und Rollback von Änderungen in Systemen.

• Der gewünschte Zustand und die gewünschte Konfiguration von Systemen werden in Git festgelegt und versioniert

Durch die Speicherung und Versionierung des gewünschten Zustands von Systemen in Git sind wir in der Lage, Änderungen an Systemen und Anwendungen einfach auszurollen und rückgängig zu machen. Wir können auch die Sicherheitsmechanismen von Git nutzen, um den Besitz des Codes zu kontrollieren und seine Authentizität zu überprüfen.

• Konfigurationsänderungen können automatisch über Pull-Requests angewendet werden

Mithilfe von Git-Pull-Requests können wir einfach steuern, wie Änderungen auf Konfigurationen im Repository angewendet werden. Sie können beispielsweise anderen Teammitgliedern zur Überprüfung übergeben werden oder CI-Tests durchlaufen usw.

Und gleichzeitig besteht keine Notwendigkeit, die Verwaltungsbefugnisse nach links und rechts zu verteilen. Um Konfigurationsänderungen zu übernehmen, benötigen Benutzer lediglich entsprechende Berechtigungen im Git-Repository, in dem diese Konfigurationen gespeichert sind.

• Behebung des Problems der unkontrollierten Drift von Konfigurationen

Sobald der gewünschte Zustand des Systems in einem Git-Repository gespeichert ist, müssen wir nur noch Software finden, die sicherstellt, dass der aktuelle Zustand des Systems mit dem gewünschten Zustand übereinstimmt. Ist dies nicht der Fall, sollte diese Software – abhängig von den Einstellungen – entweder die Abweichung von selbst beheben oder uns über Konfigurationsdrift informieren.

GitOps-Modelle für OpenShift

Ressourcenabgleicher im Cluster

Nach diesem Modell verfügt der Cluster über einen Controller, der für den Vergleich der Kubernetes-Ressourcen (YAML-Dateien) im Git-Repository mit den realen Ressourcen des Clusters verantwortlich ist. Werden Unstimmigkeiten festgestellt, sendet der Verantwortliche Benachrichtigungen und ergreift ggf. Maßnahmen zur Behebung der Unstimmigkeiten. Dieses GitOps-Modell wird in Anthos Config Management und Weaveworks Flux verwendet.

Externer Ressourcenabgleich (Push)

Dieses Modell kann als Variation des vorherigen Modells betrachtet werden, wenn wir einen oder mehrere Controller haben, die für die Synchronisierung von Ressourcen in den Paaren „Git-Repository – Kubernetes-Cluster“ verantwortlich sind. Der Unterschied besteht darin, dass nicht jeder verwaltete Cluster unbedingt über einen eigenen separaten Controller verfügt. Git-k8s-Clusterpaare werden oft als CRDs (Custom Resource Definitions) definiert, die beschreiben können, wie der Controller die Synchronisierung durchführen soll. Innerhalb dieses Modells vergleichen Controller das im CRD angegebene Git-Repository mit den ebenfalls im CRD angegebenen Kubernetes-Cluster-Ressourcen und führen basierend auf den Ergebnissen des Vergleichs entsprechende Aktionen aus. Insbesondere wird dieses GitOps-Modell in ArgoCD verwendet.

GitOps auf der OpenShift-Plattform

Verwaltung der Multi-Cluster-Kubernetes-Infrastruktur

Mit der Verbreitung von Kubernetes und der wachsenden Beliebtheit von Multi-Cloud-Strategien und Edge Computing steigt auch die durchschnittliche Anzahl an OpenShift-Clustern pro Kunde.

Beim Einsatz von Edge Computing können beispielsweise Hunderte oder sogar Tausende Cluster eines Kunden bereitgestellt werden. Dadurch ist er gezwungen, mehrere unabhängige oder koordinierte OpenShift-Cluster in der Public Cloud und vor Ort zu verwalten.

In diesem Fall müssen viele Probleme gelöst werden, insbesondere:

• Kontrollieren Sie, dass sich die Cluster in einem identischen Zustand befinden (Konfigurationen, Überwachung, Speicher usw.)
• Erstellen (oder wiederherstellen) Sie Cluster basierend auf einem bekannten Status.
• Erstellen Sie neue Cluster basierend auf einem bekannten Status.
• Führen Sie Änderungen an mehreren OpenShift-Clustern aus.
• Machen Sie Änderungen über mehrere OpenShift-Cluster hinweg rückgängig.
• Verknüpfen Sie vorlagenbasierte Konfigurationen mit verschiedenen Umgebungen.

Anwendungskonfigurationen

Während ihres Lebenszyklus durchlaufen Anwendungen häufig eine Kette von Clustern (Entwicklung, Phase usw.), bevor sie in einem Produktionscluster landen. Darüber hinaus stellen Kunden aufgrund von Verfügbarkeits- und Skalierbarkeitsanforderungen häufig Anwendungen in mehreren lokalen Clustern oder mehreren Regionen einer öffentlichen Cloud-Plattform bereit.

Dabei sind folgende Aufgaben zu lösen:

• Stellen Sie sicher, dass Anwendungen (Binärdateien, Konfigurationen usw.) zwischen Clustern (Entwickler, Bühne usw.) verschoben werden.
• Führen Sie Änderungen an Anwendungen (Binärdateien, Konfigurationen usw.) in mehreren OpenShift-Clustern aus.
• Setzen Sie Änderungen an Anwendungen auf einen früheren bekannten Status zurück.

OpenShift GitOps-Anwendungsfälle

1. Änderungen aus dem Git-Repository übernehmen

Ein Clusteradministrator kann OpenShift-Clusterkonfigurationen in einem Git-Repository speichern und sie automatisch anwenden, um mühelos neue Cluster zu erstellen und sie in einen Zustand zu versetzen, der mit dem bekannten, im Git-Repository gespeicherten Zustand identisch ist.

2. Synchronisierung mit Secret Manager

Der Administrator profitiert außerdem von der Möglichkeit, geheime OpenShift-Objekte mit entsprechender Software wie Vault zu synchronisieren, um sie mit speziell dafür erstellten Tools zu verwalten.

3. Kontrolle von Driftkonfigurationen

Der Admin wird nur dann dafür sein, wenn OpenShift GitOps selbst Abweichungen zwischen realen Konfigurationen und denen im Repository erkennt und warnt, sodass er schnell auf Abweichungen reagieren kann.

4. Benachrichtigungen über Konfigurationsdrift

Sie sind dann nützlich, wenn der Administrator schnell über Fälle von Konfigurationsdrift informiert werden möchte, um schnell selbst geeignete Maßnahmen ergreifen zu können.

5. Manuelle Synchronisierung der Konfigurationen beim Driften

Ermöglicht dem Administrator, den OpenShift-Cluster im Falle einer Konfigurationsabweichung mit dem Git-Repository zu synchronisieren, um den Cluster schnell in einen zuvor bekannten Zustand zurückzusetzen.

6.Automatische Synchronisierung der Konfigurationen beim Driften

Der Administrator kann den OpenShift-Cluster auch so konfigurieren, dass er sich automatisch mit dem Repository synchronisiert, wenn eine Abweichung erkannt wird, sodass die Clusterkonfiguration immer mit den Konfigurationen in Git übereinstimmt.

7. Mehrere Cluster – ein Repository

Der Administrator kann Konfigurationen mehrerer verschiedener OpenShift-Cluster in einem Git-Repository speichern und sie bei Bedarf gezielt anwenden.

8. Hierarchie der Clusterkonfigurationen (Vererbung)

Der Administrator kann eine Hierarchie von Clusterkonfigurationen im Repository festlegen (Stufe, Produkt, App-Portfolio usw. mit Vererbung). Mit anderen Worten: Es kann bestimmt werden, ob Konfigurationen auf einen oder mehrere Cluster angewendet werden sollen.

Wenn ein Administrator beispielsweise die Hierarchie „Produktionscluster (prod) → System X-Cluster → Produktionscluster von System X“ im Git-Repository festlegt, wird eine Kombination der folgenden Konfigurationen auf die Produktionscluster von System X angewendet:

• Konfigurationen, die allen Produktionsclustern gemeinsam sind.
• Konfigurationen für den System X-Cluster.
• Konfigurationen für den X-System-Produktionscluster.

9. Vorlagen und Konfigurationsüberschreibungen

Der Administrator kann einen Satz geerbter Konfigurationen und deren Werte überschreiben, um beispielsweise die Konfiguration für bestimmte Cluster, auf die sie angewendet werden, zu optimieren.

10. Selektives Einschließen und Ausschließen für Konfigurationen und Anwendungskonfigurationen

Der Administrator kann die Bedingungen für die Anwendung oder Nichtanwendung bestimmter Konfigurationen auf Cluster mit bestimmten Merkmalen festlegen.

11. Vorlagenunterstützung

Entwickler profitieren von der Möglichkeit, auszuwählen, wie Anwendungsressourcen definiert werden (Helm Chart, reines Kubernetes Yaml usw.), um für jede spezifische Anwendung das am besten geeignete Format zu verwenden.

GitOps-Tools auf der OpenShift-Plattform

ArgoCD

ArgoCD implementiert das External Resource Reconcile-Modell und bietet eine zentralisierte Benutzeroberfläche für die Orchestrierung von Eins-zu-vielen-Beziehungen zwischen Clustern und Git-Repositorys. Zu den Nachteilen dieses Programms gehört die Unfähigkeit, Anwendungen zu verwalten, wenn ArgoCD nicht funktioniert.

Offiziellen Website

Fluss

Flux implementiert ein On-Cluster Resource Reconcile-Modell und daher gibt es keine zentralisierte Verwaltung des Definitions-Repositorys, was eine Schwachstelle darstellt. Andererseits bleibt gerade aufgrund der fehlenden Zentralisierung die Möglichkeit zur Verwaltung von Anwendungen auch bei Ausfall eines Clusters erhalten.

Offiziellen Website

ArgoCD auf OpenShift installieren

ArgoCD bietet eine hervorragende Befehlszeilenschnittstelle und Webkonsole, daher gehen wir hier nicht auf Flux und andere Alternativen ein.

Um ArgoCD auf der OpenShift 4-Plattform bereitzustellen, führen Sie als Cluster-Administrator die folgenden Schritte aus:

Bereitstellung von ArgoCD-Komponenten auf 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 des ArgoCD-Servers, sodass er von OpenShift Route gesehen werden kann

# 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

Bereitstellen des ArgoCD Cli-Tools

# 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

Ändern des ArgoCD Server-Administratorkennworts

# 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

Nachdem Sie diese Schritte ausgeführt haben, können Sie mit ArgoCD Server über die ArgoCD WebUI-Webkonsole oder das ArgoCD Cli-Befehlszeilentool arbeiten.
https://blog.openshift.com/is-it-too-late-to-integrate-gitops/

GitOps – Es ist nie zu spät

„Der Zug ist abgefahren“ – so sagt man über eine Situation, in der die Gelegenheit verpasst wird, etwas zu unternehmen. Im Fall von OpenShift entsteht durch den Wunsch, diese coole neue Plattform sofort nutzen zu können, oft genau diese Situation bei der Verwaltung und Wartung von Routen, Deployments und anderen OpenShift-Objekten. Aber wird die Chance immer komplett verpasst?

Fortsetzung der Artikelreihe zum Thema GitOps, heute zeigen wir Ihnen, wie Sie eine handgefertigte Anwendung und ihre Ressourcen in einen Prozess umwandeln, bei dem alles von GitOps-Tools verwaltet wird. Dazu stellen wir zunächst die httpd-Anwendung manuell bereit. Der Screenshot unten zeigt, wie wir einen Namespace, eine Bereitstellung und einen Dienst erstellen und diesen Dienst dann zur Verfügung stellen, um eine Route zu erstellen.

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

Wir haben also eine handgefertigte Anwendung. Jetzt muss es unter GitOps-Verwaltung ohne Verlust der Verfügbarkeit übertragen werden. Kurz gesagt, es macht Folgendes:

• Erstellen Sie ein Git-Repository für den Code.
• Wir exportieren unsere aktuellen Objekte und laden sie in das Git-Repository hoch.
• Auswahl und Bereitstellung von GitOps-Tools.
• Wir fügen unser Repository zu diesem Toolkit hinzu.
• Wir definieren die Anwendung in unserem GitOps-Toolkit.
• Wir führen einen Testlauf der Anwendung mit dem GitOps-Toolkit durch.
• Wir synchronisieren Objekte mit dem GitOps-Toolkit.
• Aktivieren Sie die Bereinigung und automatische Synchronisierung von Objekten.

Wie im vorigen erwähnt Artikel, in GitOps gibt es eine und nur eine Informationsquelle über alle Objekte in den Kubernetes-Clustern – das Git-Repository. Als Nächstes gehen wir davon aus, dass Ihre Organisation bereits ein Git-Repository verwendet. Es kann öffentlich oder privat sein, muss aber für Kubernetes-Cluster zugänglich sein. Dabei kann es sich um dasselbe Repository wie für den Anwendungscode oder um ein separates Repository handeln, das speziell für Bereitstellungen erstellt wurde. Es wird empfohlen, strenge Berechtigungen im Repository zu haben, da Geheimnisse, Routen und andere sicherheitsrelevante Dinge dort gespeichert werden.

In unserem Beispiel erstellen wir ein neues öffentliches Repository auf GitHub. Sie können es beliebig nennen, wir verwenden den Namen Blogpost.

Wenn die YAML-Objektdateien nicht lokal oder in Git gespeichert wurden, müssen Sie die Binärdateien oc oder kubectl verwenden. Im Screenshot unten fordern wir YAML für unseren Namespace, unsere Bereitstellung, unseren Service und unsere Route an. Zuvor haben wir das neu erstellte Repository geklont und eine CD darin erstellt.

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

Bearbeiten wir nun die Datei „deployment.yaml“, um das Feld zu entfernen, das Argo CD nicht synchronisieren kann.

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

Außerdem muss die Route geändert werden. Wir legen zunächst eine mehrzeilige Variable fest und ersetzen dann ingress: null durch den Inhalt dieser Variablen.

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

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

Wir haben die Dateien also aussortiert und müssen sie nur noch im Git-Repository speichern. Danach wird dieses Repository zur einzigen Informationsquelle und alle manuellen Änderungen an Objekten sollten strengstens untersagt werden.

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

Weiter gehen wir davon aus, dass Sie ArgoCD bereits bereitgestellt haben (wie das geht – siehe oben). Post). Daher fügen wir der Argo-CD das von uns erstellte Repository hinzu, das den Anwendungscode aus unserem Beispiel enthält. Stellen Sie einfach sicher, dass Sie genau das Repository angeben, das Sie zuvor erstellt haben.

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

Jetzt erstellen wir die Anwendung. Die Anwendung legt Werte fest, damit das GitOps-Toolkit versteht, welches Repository und welche Pfade verwendet werden sollen, welches OpenShift zum Verwalten von Objekten benötigt wird, welcher spezifische Zweig des Repositorys benötigt wird und ob Ressourcen automatisch synchronisiert werden sollen.

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

Sobald eine Anwendung auf der Argo-CD angegeben ist, beginnt das Toolkit damit, bereits bereitgestellte Objekte anhand der Definitionen im Repository zu überprüfen. In unserem Beispiel sind die automatische Synchronisierung und Bereinigung deaktiviert, sodass sich die Elemente noch nicht ändern. Bitte beachten Sie, dass unsere Anwendung in der Argo CD-Schnittstelle den Status „Nicht synchron“ hat, da ArgoCD kein Label bereitstellt.
Aus diesem Grund werden die Objekte nicht erneut bereitgestellt, wenn wir etwas später mit der Synchronisierung beginnen.

Führen wir nun einen Testlauf durch, um sicherzustellen, dass unsere Dateien keine Fehler enthalten.

argocd app sync simple-app --dry-run

Wenn keine Fehler vorliegen, können Sie mit der Synchronisierung fortfahren.

argocd app sync simple-app

Nachdem wir den Befehl argocd get für unsere Anwendung ausgeführt haben, sollten wir sehen, dass sich der Anwendungsstatus in „Gesund“ oder „Synchronisiert“ geändert hat. Dies bedeutet, dass alle Ressourcen im Git-Repository nun den bereits bereitgestellten Ressourcen entsprechen.

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

Jetzt können Sie die automatische Synchronisierung und Bereinigung aktivieren, um sicherzustellen, dass nichts manuell erstellt wird und dass jedes Mal, wenn ein Objekt erstellt oder im Repository aktualisiert wird, eine Bereitstellung erfolgt.

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

Wir haben also erfolgreich eine Anwendung unter GitOps-Kontrolle gebracht, die GitOps zunächst in keiner Weise nutzte.

Source: habr.com