Automatisierungsgehilfen: GitOps-Tools im Vergleich

Johannes Schnatterer

Technical Lead

Philipp Markiewka

Software Entwickler

Wer von klassischen CI/CD-Umgebungen auf GitOps umsteigen will, muss sich für eines von zahlreichen Werkzeugen entscheiden. Doch nicht immer erschließen sich Funktionsumfang und Eignung auf den ersten Blick. Eine Bestimmungshilfe.

Der Begriff GitOps setzt sich zusammen aus dem Namen der Versionsverwaltung Git und der Abkürzung Ops für Operations, den IT-Betrieb. Die Idee zu diesem zusätzlichen Tool im DevOps-Werkzeugkasten entstammt dem Kubernetes-Umfeld und verspricht eine neue Stufe der IT-Automatisierung. Wie der Continuous-Delivery-Ansatz setzt GitOps darauf, alle Informationen in der Sourcecodeverwaltung zu pflegen. Der Unterschied ist jedoch, dass die Deployment-Umgebung ihren Zustand kontinuierlich aus Git synchronisiert und nicht der CI-Server das Ausrollen übernimmt. Die Konfiguration muss im Git also versioniert sein. Da diese wie Code behandelt wird, spricht man von „Infrastructure as Code“.

Kein Wunder, dass mittlerweile eine wachsende Zahl an GitOps-Werkzeugen zur Wahl steht. Doch welchen Funktionsumfang bieten diese, reicht ein einziges aus und ist damit „alles“ automatisierbar? Diese und ähnliche Fragen beantwortet dieser Artikel anhand konkreter Beispiele. Er erarbeitet Auswahlkriterien und illustriert diese durch einen Vergleich der bekannten GitOps-Werkzeuge ArgoCD und Flux v2.

Unübersichtlicher Markt

Eine Übersicht über die am Markt verfügbaren GitOps-Werkzeuge ist nicht so trivial, wie es zunächst klingt. Das liegt zum einen daran, dass um den Begriff ein gewisser Hype besteht und Produktanbieter sich sehr gerne mit der Bezeichnung GitOps schmücken. Zum anderen ist es schwer, den Begriff eindeutig zu definieren, und er kommt auf unterschiedlichen Ebenen des Stacks (von der physischen Infrastruktur bis zur laufenden Anwendung in der Cloud) mit unterschiedlichem Reifegrad zum Einsatz. Hier werden wahrscheinlich die GitOps-Prinzipien des OpenGitOps-Projekts der Cloud-native Computing Foundation (CNCF) mehr Klarheit bringen. Der Artikel „Finger weg“ in der iX 4/2021 widmet sich dem Thema ausführlicher.

Websites wie die von Weaveworks gestartete awesome-gitops oder die von INNOQ-Mitarbeitern bereitgestellte gitops.tech geben einen ersten Überblick über verfügbare Tools. Wie ein genauerer Blick zeigt, erfüllen die gelisteten Werkzeuge unterschiedlichste Aufgaben bei der Implementierung von GitOps und natürlich heben sie sich auch in Verbreitung, Reifegrad und Aktivität voneinander ab. Aus den diversen Anwendungsfällen extrahiert dieser Artikel drei Kategorien: Werkzeuge für Kubernetes, ergänzende Werkzeuge und infrastrukturnahe Werkzeuge. Zusätzlich fasst jeweils eine Tabelle die Werkzeuge und ihre Eigenschaften zusammen. Für eine bessere Einschätzung von Verbreitung, Reifegrad und Aktivität enthalten die Tabellen außerdem verschiedene Git- und GitHub-basierte Metriken (Stand Februar 2021).

Werkzeuge für Kubernetes

Bei GitOps-Werkzeugen kommt als Erstes meist das Thema Operatoren für Kubernetes auf. Generell ist ein Operator – oft auch „Custom Controller“ genannt – eine Anwendung, die im Kubernetes-Cluster läuft und dort Betriebsaufgaben automatisiert (siehe Abbildung 1). Dieses Operator-Pattern dient auch zum Implementieren von GitOps. Im GitOps-Operator läuft die Abstimmungsschleife (Reconciliation Loop), die den deklarativ in Git-Repositorys beschriebenen Zielzustand mit dem Istzustand des Clusters synchronisiert. Bei Unterschieden (etwa durch einen neuen Commit im Git) kümmert sich der Operator um eine Konvergenz zum Zielzustand, indem er Kubernetes-Ressourcen auf den API-Server anwendet. Erfahrungsgemäß bedarf es für einen effizienten Betrieb über die Kernfunktion hinaus weiterer Features. Dazu gehören Observability, ein Command Line Interface (CLI) oder ein User Interface (UI). Mehr dazu später im Kasten „Kriterien zur Auswahl des passenden Werkzeugs“ (siehe Ende des Artikels).

Tabelle 1

Der Blog Post von Weaveworks, der 2017 den Begriff GitOps prägte, nennt auch den ersten GitOps-Operator: Flux. Mittlerweile wurde dieser als Flux v2 komplett neu geschrieben. Das dazugehörige Projekt entwickelt außer Flux und Flux v2 noch weitere Komponenten. Weaveworks hat das Projekt mittlerweile an die CNCF übergeben. Dort steht es mittlerweile im dritten und damit höchsten Reifegrad: Graduated.

Eine Alternative zu Flux bietet ArgoCD. Es gehört zum ebenfalls bei der CNCF beheimateten Projekt Argo, das dort im dritten Reifegrad geführt wird (Graduated), also dem gleichen wie Flux. Ein umfangreicher Vergleich der beiden GitOps-Operatoren findet sich später im Artikel.

Ein neuerer Mitbewerber ist das von Rancher entwickelte Fleet. Dessen Besonderheit ist das explizite Ziel, nicht nur einen, sondern eine Flotte von Clustern verwalten zu können. Ähnlich jung und mit noch breiterem Fokus ist PipeCD. Es verspricht wie Fleet das Verwalten mehrerer Kubernetes-Cluster und bietet zusätzlich ein UI. Darüber hinaus kann es mit Terraform und einigen Services der großen Cloud-Anbieter umgehen.

GitOps kombiniert mit CI

Ebenfalls einen breiteren Fokus – aber mit anderem Schwerpunkt – bietet Jenkins X. Anders als der Name vermuten lässt, unterscheidet es sich stark vom bekannten Jenkins-Server. Es ist kein monolithisches Werkzeug, sondern besteht aus verschiedenen Komponenten wie Tekton zum Ausführen von Pipelines und Kaniko zum Bauen von Images. Das Herz von Jenkins X ist das CLI “jx”.

Insgesamt ist Jenkins X mächtiger als ArgoCD und Flux und dadurch schwerer in bestehende Prozesse zu integrieren. Dafür bietet es einen deutlich größeren Funktionsumfang. Es nimmt dem Benutzer viele Entscheidungen ab, verringert dadurch aber auch die Flexibilität. Jenkins X ist ein vollständiges Continuous-Integration- und Continuous-Delivery-Paket (CI/CD). Im Gegensatz dazu benötigen die reinen GitOps-Operatoren für viele Anwendungsfälle einen zusätzlichen CI-Server, der etwa Tests automatisiert sowie Images baut und in der Registry bereitstellt.

Irgendwo zwischen einem reinen GitOps-Operator und einem vollständigen CI/CD-Ansatz positioniert sich werf (gestartet als dapp, Anfang 2019 in werf umbenannt). Wie ein Operator kann es Kubernetes-Ressourcen aus Git auf einen Cluster anwenden. Allerdings läuft es außerhalb der Cluster. Damit erfüllt es nicht das häufig mit GitOps in Verbindung gebrachte Pull-Prinzip, bei dem der Cluster selbst seinen Sollzustand aus dem Git zieht. Dafür kann werf, anders als ArgoCD und Flux, auch Images bauen. Ein in Kubernetes laufender Operator ist (Stand Version v1.2) in Planung.

Abbildung 1

GitOps liebt Operatoren

Ein zentraler Punkt von GitOps ist die vollständige deklarative Beschreibung des Zustandes in Git. Beim Umstellen des imperativen, klassischen CI/CD – mittlerweile zur Abgrenzung zu GitOps mancherorts als CI-Ops bezeichnet – kommen einige Fragen auf. Wie lassen sich etwa Templating-Werkzeuge wie Helm oder Kustomize weiterverwenden, die bisher der CI-Server ausgeführt hat?

Die Antwort darauf lautet meist: durch weitere Operatoren. Diese erweitern den Kubernetes-API-Server um sogenannte Custom Resource Definitions (CRDs) und lauschen dann auf Änderungen an den zugehörigen Custom Resources (CRs). In diesen CRs ist der gewünschte Zustand deklarativ beschreibbar, was perfekt zu GitOps passt.

Flux bringt etwa Helm- und Kustomize-Operatoren mit, die eine deklarative Beschreibung von Helm Releases und Kustomizations via CR erlauben. Wird eine solche CR – typischerweise vom GitOps-Operator – auf den Cluster angewendet, übernimmt der Helm- oder Kustomize-Operator das Templating oder Overlay. Alternativ zum Operator kann man das Ergebnis des Templating (beispielsweise durch eine CI-Pipeline) ins Git schreiben. Vorteile sind der geringere Aufwand für die Infrastruktur und mehr Transparenz im Git-Repository. Dem stehen umfassende und schwerer wartbare YAML-Beschreibungen im Git entgegen.

Durch das Speichern des gesamten Zustands in Git landen unweigerlich auch Secrets dort. Unverschlüsselt bieten diese dort jedoch eine große Angriffsfläche. Aber auch auf die Frage, wie sich die Ver- und Entschlüsselung mit GitOps kombinieren lässt, lautet die Antwort: durch weitere Operatoren.

Komponenten für bessere Sicherheit

Eine Option, die einfach mit GitOps zusammen funktioniert, ist der Operator Sealed Secrets von Bitnami. Der verwaltet das Schlüsselmaterial im Cluster selbst. Für die Verschlüsselung existiert ein CLI, das eine Verbindung zum Cluster benötigt.

Deutlich mehr Optionen – zulasten einer aufwendigeren Konfiguration – bietet das von Mozilla entwickelte SOPS. Hier kann das Schlüsselmaterial aus den Key-Management-Systemen (KMS) der großen Cloud-Anbieter, einem eigenen HashiCorp Vault oder aus selbst verwalteten PGP-Schlüsseln kommen. SOPS selbst enthält zwar keinen Operator, es gibt aber verschiedene Varianten, es mit GitOps zu verwenden. Flux v2 bietet native Unterstützung. Außerdem gibt es das Plug-in helm secrets, das sich mit manueller Konfiguration auch in ArgoCD verwenden lässt. Auch steht ein Operator sops-secrets von einem Drittanbieter bereit.

Einen Kompromiss zwischen Sealed Secrets und SOPS kann Kamus darstellen. Es entstand speziell für den Anwendungsfall GitOps und liefert einen Operator mit. Der kann das Schlüsselmaterial entweder selbst verwalten oder von den KMS der Cloud-Anbieter beziehen. Eine weitere Besonderheit ist, dass Kamus Secrets direkt für eine Applikation verschlüsselt. Sie werden dann von der Anwendung selbst oder einem Init-Container entschlüsselt. Dadurch liegt das Secret nie unverschlüsselt im API-Server und im Idealfall auch nicht in einer Umgebungsvariable im Container vor.

Verwendet man ohnehin ein externes KMS, gibt es noch weitere Optionen, wie den ursprünglich von GoDaddy gestarteten Operator kubernetes-external-secrets und den externalsecret-operator von Container Solutions. Wer HashiCorp Vault einsetzt, hat zudem die Option auf den Operator Vault Secrets. Der funktioniert ähnlich dem Sealed Secrets Operator, ruft aber statt der Verwaltung von eigenem Schlüsselmaterial die Secrets aus Vault ab. Einen Überblick über die Verbreitung von Tools zum Secrets Management bietet der Technology Radar der CNCF vom Januar 2021.

Tabelle 2

Weitere Anwendungsfälle für ergänzende GitOps-Operatoren sind die Realisierung von Deployment-Strategien wie Canary Releases, A/B-Tests und Blue/Green Deployments – mittlerweile zusammengefasst unter dem Begriff „Progressive Delivery“. Hierfür reichen die Mittel der meisten GitOps-Operatoren nicht aus. Als Lösung bietet sich flagger an. Das von Weaveworks initiierte Tool wird mittlerweile als Teil des Flux-Projekts weiterentwickelt. Auch im Argo-Projekt findet sich ein Operator für diesen Anwendungsfall: Argo Rollouts. Beide bieten CRs zum Realisieren der Progressive-Delivery-Strategien im Zusammenspiel mit diversen Ingress-Controllern und Service Meshes.

GitOps - Continuous Operations

Lernen Sie alles zur Einführung von GitOps bis hin zur Umsetzung mit Kubernetes in unserer Schulung.

Zur Schulung

Infrastrukturnahe Werkzeuge

Der Begriff GitOps kam im Kontext von Anwendungs-Deployments in Kubernetes auf. Für diesen Fall sind diese Werkzeuge gut einsetzbar. Sie sind allerdings nicht darauf beschränkt. So lassen sich GitOps-Operatoren auch für das Ausrollen von Kubernetes-Clustern verwenden. Ein Szenario ist die Nutzung der Kubernetes Cluster API – gestartet als kube-deploy, 2018 in Cluster API (CAPI) umbenannt. Dies lässt sich wie folgt umsetzen: In einem Managementcluster läuft ein GitOps-Operator, der die durch die CAPI definierten CRs aus Git auf den Cluster anwendet. Ein ebenfalls im Cluster laufender Infrastructure-Provider liest diese CRs und wendet sie auf einen Zielcluster an.

Sobald dieser Cluster steht, stellt sich die Frage, wie man dort Anwendungen ausrollt. Flux und ArgoCD können dazu direkt auf den API-Server zugreifen. Bei anderen Operatoren wie Fleet und PipeCD ist die Architektur speziell für diesen Fall entworfen. Sie bringen je eine Komponente für den Management- und den Zielcluster mit: Bei Fleet verbindet sich ein Manager-Operator mit den Agent-Operatoren, bei PipeCD eine Control Plane mit Daemons. Dies erfordert also keinen Zugriff auf den API-Server von außen.

Über das Erstellen von Kubernetes-Clustern hinaus entstehen auch zunehmend Möglichkeiten, verschiedene Infrastructure-as-Code-Werkzeuge (IaC) wie Terraform mit GitOps zu nutzen. Wie erwähnt bietet PipeCD Unterstützung für Terraform. Von offizieller Seite bietet dessen Hersteller HashiCorp mittlerweile auch einen Terraform Kubernetes Operator an. Der benötigt allerdings Zugang zur HashiCorps Terraform Cloud. Alternativ gibt es Operatoren von Drittanbietern, die ohne Terraform Cloud auskommen, etwa der von Rancher. Allerdings befindet sich der im Alphastadium.

Eine weiter verbreitete Alternative für GitOps mit Terraform ist Atlantis: Beim Erzeugen eines Pull Requests erstellt es auf Basis der darin enthaltenen Terraform-Dateien im Git-Repository den Terraform-Plan und fügt diesen dem Pull Request als Kommentar hinzu. Nach dem Merge wendet es den Terraform-Plan an. Atlantis ist kompatibel mit verschiedenen Git-Anbietern. Es lässt sich flexibel hosten: als Binary, als Docker-Image und als Helm Chart für Kubernetes. Damit ist es eines der wenigen Werkzeuge, das auch für GitOps ohne Kubernetes interessant ist. Ebenfalls unabhängig von Kubernetes ist Ansible Tower (und damit dessen Open-Source-Upstream AWX). Red Hat sieht den Funktionsumfang als vergleichbar mit einem GitOps-Operator an.

Tabelle 3

Das Beispiel Atlantis steht gewissermaßen sinnbildlich für GitOps außerhalb von Kubernetes. Ohne eine Plattform wie Kubernetes, in der sich ein Operator betreiben lässt, ist das Pull-Prinzip von GitOps schwieriger umsetzbar. Was bleibt, ist oft das Thema „Operations by Pull Request“. Das Erstellen, Ändern oder Mergen von Pull Requests stößt allerdings auch bei CI-Ops eine CI/CD-Pipeline an. Da stellt sich die Frage, ob also der Einsatz von Pull Requests für den Betrieb ausreicht, um als GitOps bezeichnet zu werden. Die Abgrenzung wird hier schwieriger. Tatsächlich bezeichnet Atlantis sich selbst nicht als GitOps-Werkzeug. Es gibt aber andere Beispiele wie die Terraform-Alternative Pulumi. Es arbeitet zusammen mit CI-Werkzeugen wie GitHub Actions und GitLab CI und kann auf den zugehörigen Plattformen Pull Requests kommentieren. Pulumi bezeichnet dies als GitOps.

Abschließend darf bei einer Auflistung der infrastrukturnahen GitOps-Werkzeuge eines nicht fehlen: das ebenfalls von Weaveworks gestartete Ignite. Es bietet die Möglichkeit, virtuelle Maschinen (VMs) per GitOps zu verwalten. Dazu läuft auf dem physischen Host ein Daemon, der VMs entsprechend einer Beschreibung in einem Git-Repository starten und stoppen kann. Als Virtualisierer dient das ursprünglich von AWS gestartete Firecracker.

So viel und doch zu wenig

Ironischerweise gibt es trotz der Fülle an Werkzeugen Anwendungsfälle, die noch nicht mit GitOps automatisierbar sind. Bei infrastrukturnahen GitOps-Werkzeugen ist die Auswahl deutlich kleiner als bei denen für Kubernetes. Je weiter man sich der physischen Infrastruktur annähert, desto geringer wird die Unterstützung durch entsprechende Tools. Beispiele aus dem Betrieb, die sich so noch nicht per GitOps erledigen lassen, sind das Starten physischer Maschinen, etwa via Preboot Execution Environment (PXE), oder das Firmware-Upgrade in Geräten wie Switches.

Doch auch bei den ergänzenden Operatoren lassen sich noch nicht alle Anwendungsfälle im Betrieb vollständig mit GitOps automatisieren. Ein Beispiel ist der Horizontal Pod Autoscaler in Kubernetes. Um mit GitOps kompatibel zu sein, müsste dieser die Änderung der Anzahl von Replicas in ein Git-Repository schreiben, statt sie direkt an den API-Server zu senden.

Ein weiteres, noch aufwendigeres Beispiel ist der Themenkomplex Persistenz, Backup, Restore und Disaster Recovery. Das Erstellen von Backups ist zwar mit Operatoren wie Velero zuverlässig automatisierbar. Das Wiederherstellen erfordert allerdings einen manuellen Eingriff. Auf den im GitOps-Repository beschriebenen Zustand kann zwar zurückgerollt werden, aber das stellt den durch den Backup-Operator gespeicherten Zustand nicht wieder her. Umgekehrt setzt das manuelle Wiederherstellen mittels Backup-Operator den Zustand im GitOps-Repository nicht zurück.

Trotz der Tool-Fülle gibt es also noch Lücken im Funktionsumfang der GitOps-Werkzeugkette. Bei der derzeitigen Entwicklungsdynamik ist hier Zuversicht angebracht, dass sich diese in absehbarer Zeit schließen werden. Generell basieren viele der verfügbaren GitOps-Werkzeuge auf Kubernetes. Selbst für das Aufsetzen der Cluster oder anderer Infrastruktur wird ein Kubernetes-Cluster benötigt. Wer GitOps ohne Kubernetes umsetzen will, betritt wenig ausgetretene Pfade.

Aus dieser Tool-Menge gilt es nun das richtige für die eigenen Anforderungen zu finden. Die Entscheidung hängt dabei stark vom Anwendungsfall ab, der Kasten „Kriterien zur Auswahl des passenden Werkzeugs“ (siehe Ende des Artikels) zeigt, worauf man achten sollte.

Operatoren im Vergleich: ArgoCD versus Flux v2

Ein Beispiel kann die im Kasten aufgezählten Kriterien wesentlich besser veranschaulichen. Da liegt es nahe, die beiden bekanntesten GitOps-Operatoren ArgoCD und Flux v2 miteinander zu vergleichen. Beide Projekte unterliegen einer dynamischen Weiterentwicklung, sodass der hier vorliegende Vergleich nur eine Momentaufnahme sein kann.

Für einen ersten Überblick über Gemeinsamkeiten und Unterschiede lohnt sich ein Blick auf die Featurelisten.
Folgende Fähigkeiten bringen sowohl Flux v2 als auch ArgoCD mit:

• RBAC;
• Multi-Tenancy;
• Observability (Health Status, Notifications, Metriken);
• CLI für Automatisierung und CI-Integration;
• Start der Synchronisation per Webhook;
• Aufruf von Webhooks bei Events (ArgoCD: Hooks, Flux: Notifcations);
• Rollback/Roll-anywhere zu bestimmten Commits im Git-Repository;
• Unterstützung für Helm und Kustomize;
• Multi-Cluster-Unterstützung;
• Ausführung der Container als unprivilegierter User;
• Security Context konfigurierbar.

Funktionen nur in ArgoCD:

• Unterstützung für Ksonnet und Jsonnet und weitere per Plug-in-Mechanismus;
• Weboberfläche zur Administration und Überwachung von Applikationen in Echtzeit;
• SSO-Integrationen für UI und CLI.

Funktionen nur in Flux v2:

• Definition von Abhängigkeiten in Helm- und Kustomize-Applikationen;
• Unterstützung von SOPS;
• automatisches Update der Image-Version im Git-Repository;
• Authentifizierung des CLI per Kubeconfig.

Installation und Konfiguration

ArgoCD lässt sich entweder über einfache Kubernetes-Ressourcen installieren und anschließend patchen oder über ein konfigurierbares Helm Chart ausrollen. Alle gängigen Einstellungen sind vorhanden, etwa Ingress und Service-Accounts. Es können zudem Repositorys, Projekte, Applikationen und verschiedene SSO-Integrationen für das Deployment vorkonfiguriert werden. Auch die RBAC-Konfiguration ist umfangreich. Richtlinien, Rollen und Gruppen lassen sich selbst definieren.

Eine weitere Variante der Installation bietet der zusätzliche ArgoCD-Operator. Dieser erlaubt die Konfiguration und Installation der eigentlichen ArgoCD-Komponenten per CRD. Nicht dokumentiert ist, wie man ArgoCD selbst per GitOps konfiguriert. Dies ist zwar denkbar, beispielsweise mittels des ArgoCD-Operators. Ob dies zuverlässig funktioniert und vor allem auch im Fehlerfall einen weiteren Betrieb per GitOps ermöglicht, bleibt herauszufinden.

Das Ausrollen der Flux-v2-Operatoren erfolgt primär über das CLI. Darüber lassen sich aber auch alle erforderlichen Kubernetes-Ressourcen generieren und anschließend auf den Cluster ausbringen. Es gibt derzeit zwar kein Helm Chart, was die gängigen Ausbringungsmechanismen einschränkt, aber dafür gibt es mittlerweile die Möglichkeit Flux v2 per Terraform zu installieren. Bei der ersten Installation richtet Flux ein Git-Repository ein. Ab diesem Punkt kann man auch den Operator mit GitOps konfigurieren. Das CLI ist umfangreich und erlaubt die Steuerung aller Aspekte des Flux-v2-Portfolios. Man kann damit alle Flux-v2-spezifischen Ressourcen erzeugen, löschen, lesen, starten und stoppen. Damit eignet sich Flux v2 besonders gut für Scripting. Das mag zwar zunächst widersprüchlich zu GitOps erscheinen, aber in der Praxis findet häufig ein schrittweiser Umstieg statt. Hierbei kann das Erzeugen von Ressourcen, die dann in ein Git-Repository eingecheckt werden, über das CLI erfolgen. So lässt sich GitOps in bestehende CI/CD-Prozesse integrieren.

Konfiguration der Applikationen

ArgoCD bildet den Sollzustand intern durch Projekte und Applikationen ab. In Projekten lassen sich Repositorys, Cluster und Berechtigungen festlegen. Einem Projekt kann man wiederum beliebig viele Applikationen zuweisen, die Zugriff auf die Cluster und Repositorys des Projekts erhalten. Diese Applikationen und Projekte speichert ArgoCD als CRs im Cluster. In einer Applikation finden sich dann das Repository und der Pfad zu einem Deployment. Zudem kann man dort Konfigurationen für Helm, Kustomize et cetera in deklarativer Form beschreiben. Dieses über die Applikation definierte Deployment wendet ArgoCD dann auf den Cluster an. ArgoCD speichert Helm-Releases allerdings nicht als solche im Cluster, sondern wandelt sie mittels helm template in einfache Kubernetes-Ressourcen um und wendet diese auf den Cluster an. Im Gegensatz zu Flux lassen sich die Helm-Releases also nicht per helm ls aufrufen und es gibt keine Historie der Releases im Cluster.

Die Definition aller relevanten Elemente erfolgt über CRDs, womit diese selbst per GitOps konfigurierbar sind. Konkret bedeutet das, dass man die als CR definierten Projekte, Applikationen et cetera in einem eigenen Git-Repository pflegen kann.

Abbildung 2

Bei Flux v2 bilden die Repositorys die zentrale Stelle. Sie dienen sowohl dem Deployment von Workloads als auch der Konfiguration von Flux selbst. Als Workloads kann Flux Kubernetes-Ressourcen, Helm Release CRs und Kustomize CRs ausrollen. Die Helm Release CRD und Kustomize CRD bieten zudem alle bekannten Funktionen dieser Werkzeuge in deskriptiver Form an. Da auch die Git-Repositorys als CR definiert sind, lassen sie sich ebenfalls über GitOps verwalten.

UI

ArgoCD bringt eine Weboberfläche für Administration und Monitoring der Applikationen mit. Da GitOps ein asynchrones Verfahren ist, erhält man bei Änderungen an Deployments kein sofortiges Feedback. Abhilfe schaffen hier die mitgelieferten Notification-Mechanismen (siehe Abschnitt Observability). Sie geben Rückmeldung über verschiedene Kanäle wie Chat oder E-Mail. Zusätzlich bietet ArgoCD über das UI die Möglichkeit, die Deployments auch in Echtzeit zu beobachten (siehe Abbildung 2). Wenn Teile des Deployments fehlschlagen, kann man diese über das UI identifizieren und Fehlermeldungen und Logs einsehen.

Damit kann ein Entwickler – ganz ohne Zugriff auf den Cluster – seine Deployments analysieren und Fehler korrigieren. Für die Authentifizierung gibt es Schnittstellen zu gängigen Protokollen wie LDAP und OIDC. Benutzer können mit konfigurierbaren Rollen und Gruppen Zugriff auf die Projekte und Applikationen bekommen, für die sie auch zuständig sind. Für Flux v2 arbeiten die Entwickler gerade an einer Weboberfläche. Die befindet sich aber noch in einem experimentellen Zustand.

CLI

Mit dem CLI von ArgoCD lassen sich alle relevanten Funktionen bedienen. Nutzer können sowohl Objekte wie Applikationen oder Projekte erzeugen und löschen als auch Zustände verändern, wie das Zurückrollen von Applikationen oder das Antriggern von Synchronisationen. Damit eignet sich das CLI für alle Arten von Automation und Integration in CI-Pipelines. Das CLI kommuniziert mit dem ArgoCD-Server, was ein Exponieren des Kubernetes-API-Servers unnötig macht.

Auch das CLI von Flux v2 deckt alle relevanten Funktionen ab. Zusätzlich bietet es die Möglichkeit, weitere Tenants auszurollen, was beim Automatisieren einer Multi-Tenancy-Umgebung Vorteile bringen kann. Das CLI kommuniziert direkt mit dem Kubernetes-API-Server, der also von außen erreichbar sein muss.

Autorisierung

ArgoCD setzt auf eine Organisation über Projekte und Applikationen. Einem Projekt lassen sich sowohl Applikationen, Git-Repositorys, Cluster und Berechtigungen (RBAC) als auch Allow- und Deny-Listen für Ressourcentypen zuweisen. Applikationen bieten dieselben Optionen zum Einschränken der Berechtigungen. Damit können Nutzer Berechtigungen sehr einfach und feingranular sowohl auf Projekt- als auch auf Applikationsebene vergeben.

Bei Flux v2 lassen sich derzeit nur die Operatoren, Helm-Releases und Kustomization CRs per RBAC einschränken. Darüber lassen sich einfache Kubernetes-Ressourcen wie ConfigMaps und Services nur durch die Berechtigungen des Operators regeln. Auf Projektebene dürfte das zum Vergeben projektspezifischer Berechtigungen mehrere Instanzen des Flux-Operators erfordern. Alternativ lässt sich der Zugriff auf die GitOps-Repositorys auch über eine CI-Pipeline realisieren, die dann nur den Push erlaubter Ressourcen in das GitOps-Repository zulässt.

Observability

Für die Benachrichtigung über den Zustand der Synchronisation zwischen Git und Cluster bringt ArgoCD die Komponente ArgoCD Notifications mit, ein mit dem ArgoCD-Deployment ausgeliefertes Benachrichtigungssystem. Ereignisse, die beim Ausrollen von Applikationen entstehen, lassen sich damit an diverse Kanäle weiterleiten. Derzeit beherrscht ArgoCD Notifications die Kanäle SMTP, Slack, Opsgenie, Grafana, Telegram und Webhooks.

Alternativ zu ArgoCD Notifications könnte man Argo Kube Notifier und Kube Watch einsetzen. Diese sind aber zusätzlich zu ArgoCD zu betreiben. Allerdings ist ArgoCD Notifications am besten auf ArgoCD zugeschnitten, bietet nützliche Trigger und Templates und lässt sich über das projekteigene Helm Chart installieren und konfigurieren.

Zum Überwachen der Komponenten und der verwalteten Deployments exponiert ArgoCD zwei Sätze von Prometheus-Metriken: „Application Metrics“ für die Überwachung des Zustands der Synchronisierung und des Health-Zustands von Deployments sowie „API Server Metrics“ für das Überwachen der Requests und Responses an den API-Server. Darüber hinaus existieren vorgefertigte Grafana-Dashboards, die auf diesen Metriken aufbauen. Damit lässt sich sehr einfach ein Monitoring-Cockpit für das gesamte System realisieren.

Flux v2 bringt für die Observability bereits einen speziellen Controller mit, den Notification Controller. Die Konfiguration von Alerts und Notifications erfolgt dabei wie bei allen anderen Flux-Komponenten über entsprechende Custom Ressource Definitions. Über diese lassen sich Provider, also Kanäle wie Chats und Webhooks, Alert-Regeln und Empfänger einrichten. Die zugehörigen CRs können auch in einem Git-Repository gepflegt und über Flux v2 ausgebracht werden. Derzeit eignet sich der Notification Controller für die Kanäle Slack, Discord, Microsoft Teams, RocketChat, Google Chat, Webex, Sentry, Azure Event Hub und Generic Webhooks.

Zusätzlich gibt es die Möglichkeit, den Status an einen Git Commit anzuhängen. Dies ist bei folgenden Providern möglich: GitHub, GitLab, Bitbucket und Azure DevOps. Derzeit kann Flux v2 keinen Provider per SMTP-Protokoll anbinden, um so E-Mails zu verschicken.

Zum Überwachen der Controller und Deployments steht eine Reihe von Prometheus-Metriken und Grafana-Dashboards bereit (siehe Abbildung 3). Damit lässt sich zum einen die fehlerfreie Ausführung der Controller überwachen, etwa mit Statistiken zum CPU- und Speicherverbrauch. Zum anderen kann man die Zustände aller Flux-v2-CRDs, wie Helm Releases und Kustomizations überwachen. Über diesen Weg ist es dann auch wieder möglich, Alerts per E-Mail zu verschicken. Die Definition der Alert Rules kann dabei wahlweise im Grafana oder Prometheus Alertmanager erfolgen. Prometheus und Grafana lassen sich auch über das Flux-CLI installieren und konfigurieren. In einer Multi-Tenant-Umgebung kann man darüber das Ausbringen durch Skripte automatisieren.

Abbildung 3

Fazit

Sowohl Flux v2 als auch ArgoCD bieten viele Funktionen, die auch die jahrelange Praxiserfahrung mit GitOps widerspiegeln. Beide fokussieren sich stark auf die GitOps-Kernfunktionen, was sie gut in bereits vorhandene CI/CD-Infrastruktur integrierbar macht. Wer auf der grünen Wiese anfängt, muss sich diese jedoch getrennt aufbauen.

Insgesamt bietet ArgoCD mehr Möglichkeiten in der Konfiguration (beispielsweise bei der Autorisierung) und stellt eine grafische Oberfläche bereit. Dafür ist diese allerdings zu konfigurieren, zu betreiben und bietet mehr Angriffsfläche. Hier hängt es vom Anwendungsfall ab, ob ein UI überhaupt benötigt wird und so den höheren Aufwand rechtfertigt. Für Benutzer von OpenShift relativiert sich der Aufwand, da ArgoCD als OpenShift GitOps in die Plattform integriert ist.

Flux hat dafür kleinere Features, die es in ArgoCD nicht gibt, wie die Unterstützung für SOPS und das automatische Update bei neuen Image-Versionen. Noch liegt Flux v2 in einer Version 0.x vor. Allerdings versprechen die Autoren, die APIs stabil zu halten und sehen das Produkt daher für Bereit für die Produktion. Eine Möglichkeit, sich selbst einen Eindruck zu verschaffen, ArgoCD und Flux v2 ohne großen Aufwand auszuprobieren und in der Praxis zu vergleichen, bietet das von den Autoren initiierte Projekt <a rel=”noreferrer” target=”_blank” title=”Zum GitOps Playground gehen” href=https://github.com/cloudogu/gitops-playground”>GitOps Playground</a>.

Verschaffen Sie sich mit unserem eBook „GitOps – Vorteile und Prinzipien“ einen kompakten Überblick über die Chancen und Herausforderungen durch GitOps. Es bietet Ihnen eine fundierte Entscheidungsgrundlage bei der Frage, ob GitOps eine passende Lösung für die Herausforderungen in Ihrem Unternehmen ist.

Kostenloses eBook herunterladen