Mit ArgoCD Hollywood-reif ins Deployment

Mit einem git commit ein Kubernetes Deployment auslösen. Zu jeder Zeit wissen, welche Software-Komponente wo und mit was für einer Konfiguration deployed ist. Real-time Informationen, in was für einem Zustand sich meine Applikation befindet. Rollbacks und Disaster Recovery mit einem einfachen git checkout. Applikationen, welche «sich selbst heilen». 

Was sich wie ein kitschiger Blockbuster über das Entwickler-Dasein eines Cloud-native Engineers anhört, wird mit ArgoCD Realität.

Containerisierte Applikationen, welche mit einem Cloud-native Ansatz für ein Kubernetes-Umfeld entwickelt wurden, ermöglichen ein hohes Mass an Automatisierung und Skalierbarkeit. 

Bezahlt wird üblicherweise mit der für Softwareentwickler so gefürchteten Währung: Komplexität. Da dessen Wechselkurs in die den Verantwortlichen geläufigeren Währungen meist eher echte statt Freudentränen auslöst, bedarf es Lösungen, diese Komplexität zu bändigen. ArgoCD to the rescue. «Argo was…?»

Verirrt man sich auf die Website von ArgoCD, wird man mit folgender Definition belohnt:

Das bedarf einer Erklärung.

Traditional Operations

Das Entwicklerteam erstellt Software und übergibt diese dann an ein QA bzw. operatives Team, welches die Applikationen auf der Runtime installiert, testet und betreibt. 

Glücklicherweise ist diese veraltete und ineffiziente Art der Softwareentwicklung nicht mehr weit verbreitet. Dies liegt unter anderem an den modernen Möglichkeiten der Automatisierung durch Pipelines, CI/CD Tooling und der Containerisierung.

DevOps

DevOps, also die Verschmelzung von Aufgaben der Entwicklung und dem Operativen in einem einzigen Team, hat sich zum De-facto-Standard etabliert und ist heutzutage weit verbreitet. 

Es ermöglicht schnellere Iterationen durch Feedback-Loops in der Softwareentwicklung und beim Ausrollen der Applikationen, stellt aber auch höhere Ansprüche an die Entwicklerteams. Diese müssen sich nun zusätzlich mit klassischen operationellen Themen auseinandersetzen. Dazu gehören beispielsweise CI (Continuous Integration)/CD (Continuous Delivery), Testautomatisierung und Runtime Management.

GitOps

GitOps verfolgt einen deklarativen Ansatz für den Continuous Delivery-Teil von CI/CD. Das bedeutet, dass alle Applikationskonfigurationen mittels dem allseits geliebten Versionierungstool git in einem git repository hinterlegt sind. Git ist damit das primäre und gleichzeitig auch einzige Interface, mit dem Entwickler ihre Deployments konfigurieren. 

Da im Vergleich zu imperativen CD-Pipelines kein zusätzliches Tooling die Deployments der Software übernimmt, brauchen wir eine Komponente, welche das für uns übernimmt. Die Crux ist nun, dass diese Komponente (Spoiler: das ist ArgoCD!) unsere Konfiguration aus dem git repository in unsere Runtime-Umgebung synchronisiert und git somit zur Single Source of Truth wird. 

ArgoCD versucht also, den in git konfigurierten Zustand auf dem Cluster herzustellen. Wie es diesen Zustand erreicht, ist für uns Entwickler sekundär. Obwohl GitOps eine breit einsetzbare Methodologie darstellt, hat sich der Ansatz vor allem im Gebiet von Kubernetes durchgesetzt. 

So funktioniert GitOps mit ArgoCD

Git fungiert als Single Source of Truth und einziges Interface für das Entwicklerteam. Ein GitOps agent (in unserem Fall ArgoCD) synchronisiert den deklarativ konfigurierten Zustand laufend auf ein oder mehrere Kubernetes Cluster.

Die Vorteile vom deklarativen («Was will ich für einen finalen Zustand?») GitOps-Ansatz gegenüber imperativen («Wie komme ich Schritt für Schritt zu einem gedachten, finalen Zustand?») Deployment-Pipelines

1. Klare Separierung von CI (via Pipelines) und CD (via GitOps) in CI/CD.
2. Synchronisierung der deklarativen Konfiguration in Richtung Runtime (meist Kubernetes), egal ob die Änderung der Konfiguration durch einen Entwickler oder eine Pipeline ausgelöst wurde.
3. Real-time Visibilität vom Cluster Status und der laufenden Applikationen.
4. Git repository wird zur Single Source of Truth.
5. Höhere Qualität durch Code Reviews der Applikationskonfiguration.
6. Einfaches, bekanntes und allseits beliebtes Interface: git.
7. Manuelle Veränderung am Cluster können überschrieben werden («self-heal», mehr dazu später). Dadurch Eliminierung von Konfigurationsdrift (= was ich will und was wirklich ist).
8. Versionierung im git log (history) und einfaches Rollback durch Auschecken eines commits.
9. Das Auditing von Änderungen an der Konfiguration ist nativ mit der git commit history gelöst.
10. Einfaches disaster recovery, da komplette Konfiguration deklarativ ist.
11. Erhöhte Sicherheit, da der GitOps Agent (ArgoCD) innerhalb des Clusters läuft und keine Credentials nach aussen gegeben werden müssen.

Wie funktioniert ArgoCD?

Das Kernstück von ArgoCD ist der ArgoCD controller. Dieser läuft als klassische Kubernetes Ressource direkt im Cluster. ArgoCD kann u.a. bequem als Helm Chart installiert werden. 

Die Hauptaufgabe des Controllers ist es, Updates, welche Entwickler oder Pipelines auf das git repository commiten, abzuholen und die Änderungen auf dem Cluster zu applizieren. 

Ausserdem wird er gleichermassen auf Inputs reagieren, welche über das Web UI oder das CLI eingegeben werden. ArgoCD kann auch Ressourcen managen, welche auf Drittclustern laufen.

Das ArgoCD-Dashboard

ArgoCD kommt mit einem mächtigen Dashboard daher, auf welchem in Echtzeit alle durch ArgoCD überwachten Applikationen inkl. ihrem Health- und Sync-Status dargestellt werden. Es können Konfigurationen eingesehen, Logs angeschaut, Konfigurationsdrifts (Soll- vs Ist-Zustand) inspiziert und Synchronisierungen ausgelöst werden. 

Nebst dem UI stellt ArgoCD auch ein umfangreiches Command Line Interface (CLI), nämlich argocd zur Verfügung, und selbstverständlich kann jede Konfiguration, welche über das UI oder das CLI gemacht wird, auch ganz dem GitOps-Gedanken entsprechend «as-code» in git hinterlegt werden. 

Weiterhin ist schön, dass ArgoCD selber kein Backup benötigt. Es ist hauptsächlich stateless und speichert die Konfigurationen direkt im etcd (verteilte Datenbank) von Kubernetes selbst.

Mein Fazit zu ArgoCD

ArgoCD ist seit 2022 ein graduated project der Cloud Native Computing Foundation (CNCF) und erfreut sich einer hohen Beliebtheit, was sich in der weit verbreiteten Nutzung widerspiegelt. 

Dementsprechend ist ArgoCD auch zu 100% Open-Source, wobei auch Enterprise Offerings von Drittanbietern mit entsprechenden Supportleistungen existieren. 

Die Vorteile des GitOps Ansatzes bzw. des Einsatzes von ArgoCD gegenüber imperativen, schlimmstenfalls sogar manuellen Konfigurationen, überwiegen. 

Dies soll allerdings nicht über die Komplexität einer solchen Lösung hinwegtäuschen. Wenn beispielsweise bei der Synchronisierung eine bestimmte Ausführungsreihenfolge, wie bei Datenbankmigrationen, erforderlich ist, bietet ArgoCD Sync Waves und Hooks an. 

Auto-sync und pruning sind mächtige Features. Falsch eingesetzt, können sie aber eine Gefahr für die Produktionsumgebung werden. Staging und Multi-Cluster Setups können mit ArgoCD sehr elegant umgesetzt werden, müssen aber wohlüberlegt aufgesetzt werden. 

Es ist wichtig zu verstehen, dass dies inhärente Herausforderungen dynamischer, verteilter Systeme sind, die nicht spezifisch auf ArgoCD zurückzuführen sind. GitOps und ArgoCD bieten lediglich verständliche Antworten auf schwierige Fragen.

Last but not least sollte erwähnt werden, dass ArgoCD das freundlichste Logo aller CNCF Projekte hat.