Mit ArgoCD Hollywood-reif ins Deployment

Autor: Matthäus Heer

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

Klare Separierung von CI (via Pipelines) und CD (via GitOps) in CI/CD.
Synchronisierung der deklarativen Konfiguration in Richtung Runtime (meist Kubernetes), egal ob die Änderung der Konfiguration durch einen Entwickler oder eine Pipeline ausgelöst wurde.
Real-time Visibilität vom Cluster Status und der laufenden Applikationen.
Git repository wird zur Single Source of Truth.
Höhere Qualität durch Code Reviews der Applikationskonfiguration.
Einfaches, bekanntes und allseits beliebtes Interface: git.
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).
Versionierung im git log (history) und einfaches Rollback durch Auschecken eines commits.
Das Auditing von Änderungen an der Konfiguration ist nativ mit der git commit history gelöst.
Einfaches disaster recovery, da komplette Konfiguration deklarativ ist.
Erhöhte Sicherheit, da der GitOps Agent (ArgoCD) innerhalb des Clusters läuft und keine Credentials nach außen gegeben werden müssen.

In der Realität könnte das dann wie folgt aussehen:

Beim imperativen, Schritt-für-Schritt-basierten Ansatz wird eine Konfiguration eines fiktiven Deployments auf einem Kubernetes Cluster durch das Ausführen mehrerer Shell Commands (kubectl) erreicht. Anders sieht es beim deklarativen Ansatz aus, wo die Zielkonfiguration in Form eines Kubernetes yaml Manifests beschrieben wird. Es ist dann an ArgoCD, diese Zielkonfiguration auf dem Cluster zu applizieren.

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. Außerdem wird er gleichermaßen auf Inputs reagieren, welche über das Web UI oder das CLI eingegeben werden. ArgoCD kann auch Ressourcen managen, welche auf Drittclustern laufen.

Mit diesem Wissen können wir den Kreis des deklarativen Ansatzes nun mittels einer ArgoCD Application Konfiguration schließen. Diese schnappt sich das Kubernetes Manifest aus einem git repository und synchronisiert dieses mit dem Kubernetes Cluster.

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.

https://argo-cd.readthedocs.io/en/stable/

Die wichtigsten Konzepte von ArgoCD

Application

Eine ArgoCD Application definiert eine Source und ein Target. Die Source ist beispielsweise eine Gruppe von Kubernetes Ressourcen oder ein Helm chart (package), hinterlegt als yaml files in einem git repository. Das Target ist ein Namespace auf einem bestimmten Kubernetes cluster, häufig der Cluster, wo ArgoCD selbst drauf läuft.

Health Status

Beschreibt, ob die Applikation einwandfrei funktioniert und beispielsweise auf Requests antworten kann. Der default health check ist abhängig vom Typ der Kubernetes Resource. Es werden aber auch custom Implementationen unterstützt.

Refresh

Mit einem refresh wird der aktuelle Stand aus dem git repository abgefragt. Stimmt dieser nicht mit dem Stand des Clusters überein, wechselt die Applikation in einen out-of-sync Status. Merke: Per Default wird ein refresh alle 3 Minuten ausgeführt.

Sync

Ein sync appliziert Änderungen auf einem Cluster. Beispiel: Skalierung von 5 auf 10 Pods aufgrund einer Konfigurationsanspassung im git repository.

Auto-sync

Ist auto-sync für eine Applikation aktiviert, werden Applikationen, welche aufgrund eines refreshs (manuell, time-triggered oder via webhook) out-of-sync sind, direkt und ohne manuelle Bestätigung auf dem Cluster angepasst.

Self-heal

Self-heal ist nur möglich, wenn auto-sync aktiviert ist. Ist self-heal aktiv, werden manuelle Änderungen am Cluster von ArgoCD überwacht und direkt überschrieben, so dass der definierte Stand vom git repository wieder hergestellt wird. Dies verhindert Konfigurationsdrift.

Prune

Ist prune aktiv, werden Resourcen (bsp. Pods), welche noch auf dem Cluster leben, aber nicht mehr durch eine ArgoCD Applikation gesteuert werden, von ArgoCD gelöscht. Diese Option ist mächtig, sollte aber auch mit der nötigen Vorsicht genossen werden.

Project

Logische Gruppierung von Applications innerhalb ArgoCD für Access Management und Policy Enforcements.

Mein Fazit

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.

Über mich

«I learned very early the difference between knowing the name of something and knowing something.» Richard P. Feynman

Matthäus Heer