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 umgesetzt werden. Ein interaktives Handbuch zu diesem Thema ist verfügbar. unter diesem Link.

Kurz gesagt, GitOps ist eine Reihe praktischer Methoden zur Verwendung von Git-Pull-Requests zur Verwaltung von Infrastruktur- und Anwendungs-Konfigurationen. Im Rahmen von GitOps wird das Git-Repository als einzige Quelle des Systemstatus betrachtet, wobei alle Änderungen dieses Status vollständig nachverfolgt und geprüft werden können.

Die Idee der Nachverfolgbarkeit von Änderungen in GitOps ist keineswegs neu; dieser Ansatz wird bereits seit langem und praktisch überall in der Arbeit mit Quellcode von Anwendungen angewandt. GitOps implementiert einfach ähnliche Funktionen (Review-Checks, Pull-Requests, Tags usw.), wenn es um die Verwaltung von Infrastruktur- und Anwendungs-Konfigurationen geht, und bietet ähnliche Vorteile wie bei der Verwaltung von Quellcode.

Für GitOps gibt es keine akademische Definition oder einen festgelegten Regelkatalog, sondern lediglich eine Reihe von Prinzipien, auf denen diese Praxis basiert:

• Die deklarative Beschreibung des Systems wird in einem Git-Repository gespeichert (Konfigurationen, Monitoring usw.).
• Änderungen des Status werden über Pull-Requests durchgeführt.
• Der Status der laufenden Systeme wird gemäß den Daten im Repository mit Hilfe von Git-Push-Requests angepasst.

Prinzipien von GitOps

• Die Definitionen von Systemen werden als Quellcode beschrieben.

Die Konfigurationen der Systeme werden als Code betrachtet, sodass sie im Git-Repository gespeichert und automatisch versioniert werden können, das als einzige Quelle der Wahrheit dient. Dieser Ansatz ermöglicht es, Änderungen in den Systemen einfach auszurollen (Rollout) und zurückzurollen (Rollback).

• Der gewünschte Zustand und die Konfiguration der Systeme werden in Git festgelegt und versioniert.

Durch das Speichern und Versionieren des gewünschten Systemzustands in Git erhalten wir die Möglichkeit, Änderungen in den Systemen und Anwendungen einfach auszurollen und zurückzurollen. Außerdem können wir die Git-Sicherheitsmechanismen zur Kontrolle des Codebesitzes und zur Bestätigung seiner Authentizität nutzen.

• Änderungen in den Konfigurationen können automatisch über Pull-Requests angewendet werden.

Mit Hilfe von Git-Pull-Requests können wir einfach verwalten, wie Änderungen an den Konfigurationen im Repository angewendet werden. Zum Beispiel können sie zur Überprüfung an andere Teammitglieder weitergegeben oder durch CI-Tests geleitet werden.

Dabei müssen keine Administratorrechte nach Belieben verteilt werden. Um Änderungen an der Konfiguration zu committen, benötigen die Benutzer lediglich die entsprechenden Berechtigungen im Git-Repository, in dem diese Konfigurationen gespeichert sind.

• Behebung des Problems des unkontrollierten Driftens von Konfigurationen

Wenn der gewünschte Zustand des Systems im Git-Repository gespeichert ist, müssen wir nur noch eine Software finden, die sicherstellt, dass der aktuelle Zustand des Systems mit dem gewünschten Zustand übereinstimmt. Andernfalls sollte diese Software – je nach Einstellung – entweder die Abweichung eigenständig beheben oder uns über das Driften der Konfigurationen informieren.

GitOps-Modelle für OpenShift

On-Cluster Resource Reconciller

Nach diesem Modell gibt es im Cluster einen Controller, der dafür verantwortlich ist, die Kubernetes-Ressourcen (YAML-Dateien) im Git-Repository mit den tatsächlichen Ressourcen des Clusters zu vergleichen. Bei Erkennung von Abweichungen sendet der Controller Benachrichtigungen aus und ergreift möglicherweise Maßnahmen zur Behebung der Differenzen. Dieses GitOps-Modell wird in Anthos Config Management und Weaveworks Flux verwendet.

External Resource Reconciler (Push)

Dieses Modell kann als eine Variante des vorherigen angesehen werden, bei dem 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 in jedem verwalteten Cluster nicht unbedingt ein eigener Controller vorhanden sein muss. Die Paare „Git – k8s-Cluster“ werden häufig als CRD-Beschreibungen (benutzerdefinierte Ressourcendefinition) definiert, in denen beschrieben werden kann, wie der Controller die Synchronisierung durchführen soll. Im Rahmen dieses Modells vergleichen die Controller das im CRD angegebene Git-Repository mit den im CRD definierten Ressourcen des Kubernetes-Clusters und führen entsprechend der Ergebnisse des Vergleichs die erforderlichen Aktionen durch. Insbesondere wird ein solches GitOps-Modell in ArgoCD verwendet.

GitOps auf der OpenShift-Plattform

Verwaltung einer Multi-Cluster-Kubernetes-Infrastruktur

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

Zum Beispiel können beim Einsatz von Edge-Computing die Cluster eines Kunden in Hunderten und sogar Tausenden bereitgestellt werden. Infolgedessen ist er gezwungen, mehrere unabhängige oder abgestimmte OpenShift-Cluster in der Public Cloud und vor Ort zu verwalten.

Dabei müssen eine Vielzahl von Problemen gelöst werden, insbesondere:

• Überwachen, dass die Cluster sich im identischen Zustand befinden (Konfigurationen, Monitoring, Speicher usw.).
• Cluster basierend auf einem bekannten Zustand neu erstellen (oder wiederherstellen).
• Neue Cluster basierend auf einem bekannten Zustand erstellen.
• Änderungen auf mehreren OpenShift-Clustern anwenden.
• Änderungen auf mehreren OpenShift-Clustern zurücksetzen.
• Template-basierte Konfigurationen mit verschiedenen Umgebungen verknüpfen.

Anwendungskonfigurationen

Im Laufe ihres Lebenszyklus durchlaufen Anwendungen häufig eine Kette von Clustern (Dev, Stage usw.), bevor sie im Produktionscluster ankommen. Darüber hinaus stellen Kunden aufgrund der Anforderungen an Verfügbarkeit und Skalierbarkeit häufig Anwendungen gleichzeitig auf mehreren On-Premise-Clustern oder in mehreren Regionen der Public Cloud-Plattform bereit.

Dabei müssen folgende Aufgaben gelöst werden:

• Den Austausch von Anwendungen (Binaries, Konfigurationen usw.) zwischen Clustern (Dev, Stage usw.) sicherstellen.
• Änderungen in Anwendungen (Binaries, Konfigurationen usw.) auf mehreren OpenShift-Clustern anwenden.
• Änderungen in Anwendungen auf den Stand des vorherigen bekannten Zustands zurücksetzen.

Nutzungsszenarien von OpenShift GitOps

1. Anwenden von Änderungen aus einem Git-Repository

Der Cluster-Administrator kann die Konfigurationen des OpenShift-Clusters in einem Git-Repository speichern und automatisch anwenden, um ohne großen Aufwand neue Cluster zu erstellen und sie in einen Zustand zu versetzen, der dem bekannten Zustand entspricht, der im Git-Repository gespeichert ist.

2. Synchronisierung mit dem Secret Manager

Der Administrator wird auch die Möglichkeit zu schätzen wissen, die Secret-Objekte von OpenShift mit entsprechender Software wie Vault zu synchronisieren, um sie mit speziell dafür entwickelten Tools zu verwalten.

3. Kontrolle des Driftens von Konfigurationen

Der Admin wird es begrüßen, wenn OpenShift GitOps selbst Abweichungen zwischen den tatsächlichen Konfigurationen und den im Repository festgelegten erkennt und darauf hinweist, um schnell auf Drift reagieren zu können.

4. Benachrichtigungen über Konfigurationsdrift

Sind nützlich, wenn der Administrator schnell über Fälle von Konfigurationsdrift informiert werden möchte, um schnell selbst entsprechende Maßnahmen zu ergreifen.

5. Manuelle Synchronisation von Konfigurationen bei Drift

Ermöglicht es dem Administrator, einen OpenShift-Cluster im Falle von Konfigurationsdrift mit dem Git-Repository zu synchronisieren, um den Cluster schnell in den vorherigen bekannten Zustand zurückzuversetzen.

6. Automatische Synchronisation von Konfigurationen bei Drift

Der Administrator kann den OpenShift-Cluster so konfigurieren, dass er bei Feststellung von Drift automatisch mit dem Repository synchronisiert wird, sodass die Clusterkonfiguration immer mit den Konfigurationen in Git übereinstimmt.

7. Mehrere Cluster – ein Repository

Der Administrator kann die Konfigurationen mehrerer verschiedener OpenShift-Cluster in einem einzigen Git-Repository speichern und nach Bedarf selektiv anwenden.

8. Hierarchie der Clusterkonfigurationen (Vererbung)

Der Administrator kann eine Hierarchie von Clusterkonfigurationen im Repository festlegen (Staging, Produktion, Anwendungsportfolio usw. mit Vererbung). Mit anderen Worten, er kann festlegen, wie die Konfigurationen auf einen oder mehrere Cluster angewendet werden sollen.

Zum Beispiel, wenn der Administrator im Git-Repository eine Hierarchie für "Produktionscluster (prod) → Cluster des Systems X → Produktionscluster des Systems X" festlegt, dann wird für die Produktionscluster des Systems X die Vereinheitlichung der folgenden Konfigurationen angewandt:

• Konfigurationen, die für alle Produktionscluster gemeinsam sind.
• Konfigurationen für den Cluster des Systems X.
• Konfigurationen für den Produktionscluster des Systems X.

9. Vorlagen und Überschreibungen von Konfigurationen

Der Administrator kann eine Reihe von geerbten Konfigurationen und deren Werten überschreiben, um die Konfiguration für bestimmte Cluster besser anzupassen, auf die sie angewendet werden.

10. Selektive Includes und Excludes für Konfigurationen, Anwendungs-Konfigurationen

Der Administrator kann Bedingungen festlegen, unter denen bestimmte Konfigurationen auf Cluster mit bestimmten Merkmalen angewendet oder nicht angewendet werden.

11. Unterstützung für Vorlagen

Entwickler werden die Möglichkeit schätzen, wie die Ressourcen der Anwendung definiert werden (Helm Chart, reines Kubernetes-YAML usw.), um das am besten geeignete Format für jede spezifische Anwendung zu verwenden.

GitOps-Tools auf der OpenShift-Plattform

ArgoCD

ArgoCD implementiert das Modell External Resource Reconcile und bietet eine zentralisierte Benutzeroberfläche zur Orchestrierung von Beziehungen zwischen Clustern und Git-Repositories im „One-to-Many“-Schema. Zu den Nachteilen dieses Programms gehört die Unfähigkeit, Anwendungen zu verwalten, wenn ArgoCD nicht funktioniert.

Offizielle Webseite

Flux

Flux implementiert das Modell On-Cluster Resource Reconcile, und infolgedessen gibt es hier kein zentrales Management von Definitionsrepositories, was eine Schwachstelle darstellt. Auf der anderen Seite bleibt aufgrund des Fehlens von Zentralisierung die Möglichkeit bestehen, Anwendungen auch bei einem Ausfall eines Clusters zu verwalten.

Offizielle Webseite

Installation von ArgoCD auf OpenShift

ArgoCD bietet eine hervorragende Befehlszeilenschnittstelle und eine Webkonsole, daher werden wir hier Flux und andere Alternativen nicht betrachten.

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

Bereitstellung der 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}')

Anpassung des ArgoCD-Servers, damit er vom OpenShift-Routing erkannt wird

# 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

Bereitstellung 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 Admin-Passworts für den ArgoCD-Server

# 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

Nach Abschluss dieser Schritte kann mit dem ArgoCD-Server über die ArgoCD WebUI oder das ArgoCD Cli-Tool gearbeitet werden.
https://blog.openshift.com/is-it-too-late-to-integrate-gitops/

GitOps – Es ist nie zu spät

„Der Zug ist abgefahren“ – so spricht man über eine Situation, in der die Möglichkeit, etwas zu tun, verpasst wurde. Im Falle von OpenShift führt das Verlangen, sofort mit dieser neuen coolen Plattform zu beginnen, oft zu genau einer solchen Situation bei der Verwaltung und Wartung von Routen, Deployments und anderen OpenShift-Objekten. Ist die Chance immer endgültig vertan?

Fortsetzung der Artikelreihe über GitOps, heute zeigen wir, wie man eine manuell erstellte Anwendung und ihre Ressourcen in einen Prozess umwandelt, in dem alles vom GitOps-Toolset verwaltet wird. Dazu werden wir zunächst die Anwendung httpd manuell bereitstellen. Auf dem Screenshot unten ist zu sehen, wie wir einen Namespace, ein Deployment und einen Service erstellen und dann diesen Service exponieren, 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

So, wir haben eine manuell eingerichtete Anwendung. Jetzt muss sie ohne Verlust der Verfügbarkeit unter das Management von GitOps übertragen werden. Kurz gesagt, so funktioniert es:

• Erstellen Sie ein Git-Repository für den Code.
• Wir exportieren unsere aktuellen Objekte und laden sie in das Git-Repository hoch.
• Wir wählen aus und implementieren das GitOps-Toolkit.
• Wir fügen unser Repository 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 die Objekte mit dem GitOps-Toolkit.
• Wir aktivieren das Pruning und die automatische Synchronisation der Objekte.

Wie bereits im vorherigen Artikel, gibt es in GitOps nur eine einzige Quelle für Informationen zu allen Objekten in den Kubernetes-Cluster(n) – das Git-Repository. Wir gehen davon aus, dass in Ihrer Organisation bereits ein Git-Repository verwendet wird. Es kann öffentlich oder privat sein, muss jedoch für die Kubernetes-Cluster zugänglich sein. Dies kann dasselbe Repository sein, das auch für den Anwendungscode genutzt wird, oder ein separates Repository, das speziell für Deployments erstellt wurde. Im Repository sind strenge Berechtigungen empfohlen, da dort sensible Objekte wie Secrets, Routen und andere sicherheitsrelevante Dinge gespeichert werden.

In unserem Beispiel erstellen wir ein neues öffentliches Repository auf GitHub. Wir können ihm beliebig einen Namen geben, wir verwenden den Namen blogpost.

Wenn die YAML-Dateien der Objekte nicht lokal oder in Git gespeichert waren, müssen wir auf die Binaries oc oder kubectl zugreifen. Im Screenshot unten fordern wir YAML für unseren Namensraum, das Deployment, den Service und die Route an. Zuvor haben wir das gerade erstellte Repository geklont und sind mit dem Befehl cd in es gewechselt.

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

Jetzt korrigieren wir die Datei deployment.yaml, um das Feld zu entfernen, das Argo CD nicht synchronisieren kann.

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

Außerdem müssen wir die Route ändern. Zuerst definieren wir eine mehrzeilige Variable 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

Nachdem wir uns um die Dateien gekümmert haben, bleibt nur noch, sie im Git-Repository zu speichern. Danach wird dieses Repository die einzige Informationsquelle, und alle manuellen Änderungen an den Objekten sollten strengstens untersagt werden.

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

Wir gehen davon aus, dass ArgoCD bereits bei Ihnen bereitgestellt ist (wie man das macht – siehe vorherige Post). Daher fügen wir das in Argo CD hinzu, was wir als Repository erstellt haben, das den Code der Anwendung aus unserem Beispiel enthält. Stellen Sie nur 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-Werkzeug versteht, welches Repository und welche Pfade verwendet werden sollen, welcher OpenShift zum Verwalten der Objekte benötigt wird und welcher spezifische Branch des Repositories erforderlich ist sowie ob eine automatische Synchronisation der Ressourcen stattfinden soll.

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

Nachdem die Anwendung in Argo CD festgelegt wurde, beginnt dieses Werkzeug, die bereits bereitgestellten Objekte auf Übereinstimmung mit den Definitionen im Repository zu überprüfen. In unserem Beispiel sind automatische Synchronisation und Bereinigung deaktiviert, sodass sich die Elemente vorerst nicht ändern. Beachten Sie, dass unsere Anwendung in der Argo CD-Oberfläche den Status „Out of Sync“ (Nicht synchronisiert) haben wird, da es kein Label gibt, das von ArgoCD gesetzt wird.
Aus diesem Grund wird bei der späteren Ausführung der Synchronisation das erneute Bereitstellen von Objekten nicht erfolgen.

Jetzt führen wir einen Testlauf durch, um sicherzustellen, dass in unseren Dateien keine Fehler vorhanden sind.

argocd app sync simple-app --dry-run

Wenn keine Fehler vorliegen, können wir zur Synchronisation übergehen.

argocd app sync simple-app

Nachdem wir den Befehl argocd get für unsere Anwendung ausgeführt haben, sollten wir sehen, dass der Status der Anwendung auf Healthy (Gesund) oder Synced (Synchronisiert) geändert wurde. Das bedeutet, dass alle Ressourcen im Git-Repository jetzt den Ressourcen entsprechen, die bereits bereitgestellt wurden.

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

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

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

Wir haben erfolgreich eine Anwendung unter GitOps verwaltet, die ursprünglich kein GitOps verwendet hat.

Quelle: habr.com