Einführung in GitOps für OpenShift

Heute werden wir über die Prinzipien und Modelle von GitOps sprechen und wie diese Modelle auf der OpenShift-Plattform implementiert werden. Eine Online-Anleitung zu diesem Thema finden Sie hier .



Kurz gesagt, GitOps ist eine Sammlung praktischer Methoden zur Verwendung von Git-Pull-Anforderungen zum Verwalten von Infrastruktur- und Anwendungskonfigurationen. Das Git-Repository in GitOps wird als eine einzige Informationsquelle über den Systemstatus betrachtet. Alle Änderungen in diesem Status werden vollständig überwacht und überwacht.

Die Idee der Änderungsnachverfolgung in GitOps ist keineswegs neu, diese Methode wird seit langem fast überall bei der Arbeit mit Anwendungsquellcode verwendet. GitOps implementiert einfach ähnliche Funktionen (Überprüfungen, Pull-Anforderungen, Tags usw.) beim Verwalten von Infrastruktur- und Anwendungskonfigurationen und bietet ähnliche Vorteile wie im Fall der Quellcodeverwaltung.

Für GitOps gibt es keine akademische Definition oder genehmigte Regeln, sondern nur eine Reihe von Grundsätzen, auf denen diese Praxis basiert:

• Die deklarative Beschreibung des Systems wird im Git-Repository gespeichert (Konfiguration, Überwachung usw.).
• Statusänderungen werden über Pull-Anforderungen vorgenommen.
• Der Status laufender Systeme wird mithilfe von Git-Push-Anforderungen mit den Daten im Repository abgeglichen.

GitOps-Prinzipien

• Systemdefinitionen werden als Quellcode beschrieben.

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

• Gewünschter Status und Systemkonfiguration werden in Git festgelegt und versioniert

Indem wir den gewünschten Status der Systeme in Git speichern und versionieren, erhalten wir die Möglichkeit, Änderungen an Systemen und Anwendungen einfach rückgängig zu machen. Wir können auch die Sicherheitsmechanismen von Git verwenden, um den Besitz von Code zu kontrollieren und dessen Authentizität zu überprüfen.

• Konfigurationsänderungen können mithilfe von Pull-Anforderungen automatisch angewendet werden.

Mithilfe von Git-Pull-Anforderungen können wir einfach steuern, wie Änderungen an Konfigurationen im Repository angewendet werden. Sie können beispielsweise zur Überprüfung an andere Teammitglieder gesendet oder CI-Tests usw. durchlaufen werden.

Gleichzeitig müssen Sie nicht rechts und links Administratorberechtigungen erteilen. Zum Festschreiben von Konfigurationsänderungen verfügen Benutzer über ausreichende Berechtigungen im Git-Repository, in dem diese Konfigurationen gespeichert sind.

• Korrigieren Sie unkontrollierte Drift-Konfigurationen

Wenn der gewünschte Status des Systems im Git-Repository gespeichert ist, können wir nur Software finden, die steuert, dass der aktuelle Status des Systems dem gewünschten Status entspricht. Ist dies nicht der Fall, sollte diese Software - abhängig von den Einstellungen - die Diskrepanz entweder selbst beheben oder uns über die Konfigurationsabweichung informieren.

GitOps-Modelle für OpenShift

On-Cluster Resource Reconciller

Gemäß diesem Modell verfügt der Cluster über einen Controller, der für den Vergleich von Kubernetes-Ressourcen (YAML-Dateien) im Git-Repository mit realen Cluster-Ressourcen zuständig ist. Im Falle von Unstimmigkeiten sendet der Controller Benachrichtigungen und ergreift möglicherweise Maßnahmen, um Inkonsistenzen zu beseitigen. Dieses GitOps-Modell wird von Anthos Config Management und Weaveworks Flux verwendet.

Externer Ressourcenabgleich (Push)

Dieses Modell kann als Variation des vorherigen angesehen werden, wenn wir einen oder mehrere Controller haben, die für die paarweise Synchronisierung der Ressourcen verantwortlich sind. “Git-Repository - Kubernetes-Cluster”. Der Unterschied besteht darin, dass für jeden verwalteten Cluster kein separater Controller erforderlich ist. Git-k8s-Clusterpaare werden häufig als benutzerdefinierte CRDs für die Ressourcendefinition definiert, die beschreiben, wie der Controller die Synchronisation durchführen soll. Innerhalb dieses Modells vergleichen Controller das in CRD angegebene Git-Repository mit den Ressourcen des Kubernetes-Clusters, die ebenfalls in CRD definiert sind, und führen die entsprechenden Aktionen auf der Grundlage der Ergebnisse des Vergleichs aus. Insbesondere wird ein solches GitOps-Modell in ArgoCD verwendet.

GitOps auf der OpenShift-Plattform

Multicluster Kubernetes Infrastructure Administration

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

Wenn Sie beispielsweise Peripheriegeräte verwenden, können Cluster eines einzelnen Kunden in Hunderten oder sogar Tausenden bereitgestellt werden. Infolgedessen muss er mehrere unabhängige oder koordinierte OpenShift-Cluster in der öffentlichen Cloud und vor Ort verwalten.

Gleichzeitig müssen viele Probleme gelöst werden, insbesondere:

• Um zu kontrollieren, dass sich die Cluster in identischem Zustand befinden (Konfiguration, Überwachung, Speicherung usw.)
• Erstellen Sie Cluster gemäß einem bekannten Status neu (oder stellen Sie sie wieder her).
• Erstellen Sie neue Cluster nach einem bekannten Status.
• Änderungen in mehreren OpenShift-Clustern übernehmen.
• Machen Sie Änderungen an mehreren OpenShift-Clustern rückgängig.
• Verknüpfen Sie gemusterte Konfigurationen mit verschiedenen Umgebungen.

Anwendungskonfigurationen

Während ihres Lebenszyklus durchlaufen Anwendungen häufig eine Reihe von Clustern (dev, stage usw.), bevor sie in einen Produktionscluster gelangen. Aufgrund der Verfügbarkeits- und Skalierbarkeitsanforderungen stellen Kunden Anwendungen häufig in mehreren lokalen Clustern oder in mehreren Regionen einer öffentlichen Cloud-Plattform bereit.

In diesem Fall müssen folgende Aufgaben gelöst werden:

• Stellen Sie sicher, dass Anwendungen (Binaries, Configs usw.) zwischen Clustern (dev, stage usw.) verschoben werden.
• Führen Sie Änderungen an Anwendungen (Binärdateien, Konfigurationen usw.) in mehreren OpenShift-Clustern aus.
• Setzen Sie Änderungen in Anwendungen auf die Ebene des vorherigen bekannten Status zurück.

OpenShift GitOps-Nutzungsszenarien

1. Übernehmen Sie die Änderungen aus dem Git-Repository

Der Cluster-Administrator kann die OpenShift-Cluster-Konfigurationen im Git-Repository speichern und automatisch anwenden, um ohne zusätzlichen Aufwand neue Cluster zu erstellen und in einen Status zu versetzen, der mit dem im Git-Repository gespeicherten Status identisch ist.

2. Mit Secret Manager synchronisieren

Der Administrator wird es auch nützlich finden, geheime OpenShift-Objekte mit geeigneter Software wie Vault zu synchronisieren, um sie mit speziell dafür erstellten Tools zu verwalten.

3. Drift-Konfigurationen steuern

Der Administrator ist nur dann dafür, wenn OpenShift GitOps Abweichungen zwischen den tatsächlichen und den im Repository angegebenen Konfigurationen erkennt und warnt, sodass Sie schnell auf Abweichungen reagieren können.

4. Konfigurationsdrift-Benachrichtigungen

Dies ist praktisch, wenn der Administrator schnell Informationen zu Drift-Konfigurationen erhalten möchte, um selbst schnell geeignete Maßnahmen ergreifen zu können.

5. Manuelle Synchronisation der Konfigurationen beim Driften

Ermöglicht dem Administrator das Synchronisieren des OpenShift-Clusters mit dem Git-Repository im Falle von Drift-Konfigurationen, um den Cluster schnell in einen früheren bekannten Zustand zu versetzen.

6. Automatische Synchronisation von Drift-Konfigurationen

Der Administrator kann das OpenShift-Cluster auch so konfigurieren, dass es automatisch mit dem Repository synchronisiert wird, wenn eine Abweichung festgestellt 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 diese nach Bedarf selektiv anwenden.

8. Hierarchie der Cluster-Konfigurationen (Vererbung)

Der Administrator kann die Hierarchie der Cluster-Konfigurationen im Repository festlegen (Bühne, Produkt, App-Portfolio usw. mit Vererbung). Mit anderen Worten kann festgelegt werden, wie Konfigurationen angewendet werden sollen - auf einen oder mehrere Cluster.

Wenn der Administrator beispielsweise die Hierarchie "Produktionscluster (prod) → Cluster von System X → Produktionscluster von System X" im Git-Repository definiert, werden die folgenden Konfigurationen auf die Produktionscluster von System X angewendet:

• Konfigurationen, die allen Produktionsclustern gemeinsam sind.
• Konfigurationen für das Clustersystem X.
• Konfigurationen für den Produktionscluster von System X.

9. Muster und Konfigurationsüberschreibungen

Der Administrator kann die Menge der geerbten Konfigurationen und ihre 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 Anwendungskonfiguration

Der Administrator kann die Bedingungen für das Anwenden oder Nichtanwenden bestimmter Konfigurationen auf Cluster mit bestimmten Merkmalen festlegen.

11. Musterunterstützung

Entwickler werden es nützlich finden, auszuwählen, wie die Anwendungsressourcen bestimmt werden (Helm Chart, reines Kubernetes Yaml usw.), um das am besten geeignete Format für die jeweilige Anwendung zu verwenden.

GitOps-Tools auf der OpenShift-Plattform

Argocd

ArgoCD implementiert das External Resource Reconcile-Modell und bietet eine zentralisierte Benutzeroberfläche zum Orchestrieren von Beziehungen zwischen Clustern und Git-Repositorys in einer Eins-zu-Viele-Weise. Zu den Nachteilen dieses Programms gehört die Unfähigkeit, Anwendungen zu verwalten, während ArgoCD nicht funktioniert.

Offiziellen Website

Flussmittel

Flux implementiert das On-Cluster Resource Reconcile-Modell. Daher gibt es keine zentralisierte Verwaltung des Definitionsrepositorys, was eine Schwachstelle darstellt. Andererseits bleibt gerade wegen der fehlenden Zentralisierung die Fähigkeit zur Verwaltung von Anwendungen erhalten, selbst wenn ein Cluster ausfällt.

Offiziellen Website

Installieren Sie ArgoCD unter OpenShift

ArgoCD bietet eine hervorragende Befehlszeilenschnittstelle und eine Webkonsole. Daher werden Flux und andere Alternativen hier nicht berücksichtigt.

Gehen Sie wie folgt vor, um ArgoCD auf der OpenShift 4-Plattform bereitzustellen:

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

Verfeinerung des ArgoCD-Servers für OpenShift Route

 # 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 

Stellen Sie das ArgoCD Cli Tool bereit

 # 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 Sie das Administratorkennwort von 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 

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 abgereist“ - das sagen sie über die Situation, in der die Gelegenheit, etwas zu tun, verpasst wird. Im Falle von OpenShift führt der Wunsch, sofort mit der Nutzung dieser neuen coolen Plattform zu beginnen, häufig zu einer solchen Situation bei der Verwaltung und Pflege von Routen, Bereitstellungen und anderen OpenShift-Objekten. Aber wird die Chance immer komplett verpasst?

In einer Reihe von Artikeln über GitOps wird heute gezeigt, wie eine manuell erstellte Anwendung und ihre Ressourcen in einen bestimmten Prozess umgewandelt werden, in dem das GitOps-Toolkit alles steuert. Dazu stellen wir zuerst die httpd-Anwendung mit unseren Händen bereit. Der folgende Screenshot zeigt, wie wir einen Namespace, eine Bereitstellung und einen Dienst erstellen und dann bereitstellen, damit dieser Dienst eine Route erstellt.

 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 manuell erstellte Anwendung. Jetzt muss es unter der Kontrolle von GitOps ohne Verlust der Verfügbarkeit übertragen werden. Kurz gesagt:

• Erstellen Sie ein Git-Repository für den Code.
• Wir exportieren unsere aktuellen Objekte und laden sie in das Git-Repository.
• Wählen Sie das GitOps-Toolkit aus und stellen Sie es bereit.
• Fügen Sie diesem Toolkit unser Repository hinzu.
• Wir definieren die Anwendung in unserem GitOps-Toolkit.
• Führen Sie einen Testlauf der Anwendung mit dem GitOps-Toolkit durch.
• Wir synchronisieren Objekte mit dem GitOps-Toolkit.
• Wir schalten das Beschneiden und die automatische Synchronisation von Objekten ein.

Wie im vorherigen Artikel erwähnt , verfügt GitOps über eine einzige Informationsquelle zu allen Objekten in den Kubernetes-Clustern - das Git-Repository. Des Weiteren gehen wir davon aus, dass Ihre Organisation bereits ein Git-Repository verwendet. Es kann öffentlich oder privat sein, muss aber Kubernetes Clustern zur Verfügung stehen. Dies kann das gleiche Repository wie für Anwendungscode sein oder ein separates Repository, das speziell für die Bereitstellung erstellt wurde. Es wird empfohlen, dass Sie strikte Berechtigungen im Repository haben, da geheime Objekte, Routen und andere sicherheitsrelevante Dinge dort gespeichert werden.

In unserem Beispiel erstellen wir ein neues öffentliches Repository auf GitHub. Sie können es benennen, wie Sie möchten, wir verwenden den Namen Blogpost.

Wenn die YAML-Dateien der Objekte nicht lokal oder in Git gespeichert wurden, müssen Sie die Binärdateien oc oder kubectl verwenden. In der Abbildung unten fordern wir YAML für unseren Namespace, unsere Bereitstellung, unseren Service und unsere Route an. Davor haben wir das neu erstellte Repository geklont und sind mit dem Befehl cd dorthin gezogen.

 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 

Korrigieren Sie nun die Datei deployment.yaml, um ein Feld daraus zu entfernen, das von der Argo-CD nicht synchronisiert werden kann.

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

Außerdem müssen Sie die Route ändern. Wir werden zuerst die mehrzeilige Variable setzen und dann ingress: null durch den Inhalt dieser Variablen ersetzen.

 export ROUTE=" ingress:\\ - conditions:\\ - status: 'True'\\ type: Admitted" sed -i "s/ ingress: null/$ROUTE/g" route.yaml 

Nachdem die Dateien aussortiert wurden, müssen sie im Git-Repository gespeichert werden. Danach wird dieses Repository zur einzigen Informationsquelle, und manuelle Änderungen an Objekten sollten strengstens untersagt werden.

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

Weiter gehen wir davon aus, dass ArgoCD bereits für Sie implementiert ist (wie das geht, lesen Sie im vorherigen Beitrag ). 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 das genaue Repository angeben, das Sie zuvor erstellt haben.

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

Erstellen Sie nun die Anwendung. Die Anwendung legt die Werte so fest, dass das GitOps-Toolkit erkennt, welches Repository und welche Pfade verwendet werden sollen, welche OpenShift-Funktion zum Verwalten von Objekten erforderlich ist, welcher bestimmte Zweig des Repositorys erforderlich ist 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 

Nachdem die Anwendung auf der Argo-CD angegeben wurde, überprüft dieses Toolkit bereits implementierte Objekte auf Übereinstimmung mit den Definitionen im Repository. In unserem Beispiel sind die automatische Synchronisierung und Bereinigung deaktiviert, sodass sich die Elemente noch nicht ändern. Bitte beachten Sie, dass unsere Anwendung auf der Argo CD-Oberfläche den Status „Nicht synchronisiert“ hat, da ArgoCD kein Label-Label anbringt.
Aus diesem Grund wird die erneute Bereitstellung von Objekten nicht ausgeführt, wenn die Synchronisierung etwas später beginnt.

Führen Sie 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 Sie den Befehl argocd get für unsere Anwendung ausgeführt haben, sollten Sie feststellen, dass sich der Status der Anwendung in Fehlerfrei oder Synchronisiert geändert hat. Dies bedeutet, dass alle Ressourcen im Git-Repository jetzt 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 die Bereitstellung jedes Mal durchgeführt wird, wenn das Objekt im Repository erstellt oder aktualisiert wird.

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

Wir haben also erfolgreich eine Anwendung auf die Steuerung von GitOps übertragen, die GitOps anfangs in keiner Weise verwendet hat.