GitOps mit ArgoCD

Die Blogserie wird in drei Hauptthemen aufgeteilt:

1. Was ist ArgoCD und häufige ArgoCD Patterns
2. ArgoCD Security
   
3. Environment Propagation

Dieser Blogbeitrag ist bewusst kein weiteres Tutorial über Argo CD und dessen Funktionalitäten. Der Fokus liegt auf dem täglichen Einsatz von ArgoCD und allgemeine GitOps Konzepte und Probleme. Falls du an einem tieferen Einblick in das ArgoCD Tool selbst interessiert bist, würde sich das ArgoCD Basic Training von unserer Partnerfirma Acend sehr gut als Grundlage eignen.

Was ist GitOps

Seit Jahrzehnten existiert in der Softwareentwicklung das Konzept von Continous Integration und Continuous Development (CI/CD). Applikationscode wird geschrieben, eingecheckt, getestet und zusammengefügt . Währenddessen werden durch CI/CD Tools wie GitLab CI, GitHub Actions oder auch Jenkins entsprechende Applikations-Artefakte automatisch gebaut. Heutzutage handelt es sich bei solchen Artefakten meist um Container-Images, die in eine Container-Registry wie DockerHub gepusht werden.

Während Kunden inmitten dieses Prozesses stehen taucht oft die Frage auf, wie man Container-Images vollautomatisiert auf die Container-Plattform bringt respektive wie das andere Unternehmen lösen. Unsere Antwort, meist die Gleiche: Häufig machen es zu Beginn alle gleich. Sie basteln sich eine eigene Lösung auf Basis eines CI Tools und schreiben tausende Zeilen an schlecht test- und wartbaren Bash-scripts, mit denen sie Applikationen deployen. Illustriert sieht das Ganze dann folgendermassen aus:

Wir können an dieser Stelle aber Entwarnung geben. Es existieren nämlich eindeutig bessere und standardisierte Möglichkeiten, wie Applikationen vollautomatisch deployed werden können.

Eine dieser Möglichkeiten ist beispielsweise GitOps. GitOps basiert auf der Idee, Git in der selben Weise für Applikations-Deployments und Konfiguration zu verwenden, wie das in der Softwareentwicklung gemacht wird. Jegliche Änderungen an einer Applikation oder Konfiguration sind in einem Git-Repository beschrieben. Sie unterliegen dem Versionskontrollsystem und werden automatisch mit dem Live-Environment synchronisiert.

GitOps basiert auf folgenden vier Grundprinzipien:

• Deklarative Konfiguration
• Versionskontrolliert und unveränderbar
  Durch die Verwendung von Git sind alle Änderungen nachverfolgbar und unveränderbar. Das bedeutet, dass ein Git Repository die sogenannte „Single Source Of Truth“ ist.
• Automatische Synchronisation
  Änderungen an den Konfigurationen haben automatisch ein neues Deployment zur folge. Das GitOps Tool prüft das Repository periodisch auf Änderungen und wendet diese gegen den Cluster an.
• Kontinuierliche Synchronisation
  GitOps synchronisiert laufend den im Repository abgebildete State gegen den Live-State im Cluster.

Und das Beste daran: GitOps basiert und erweitert bewährte Arbeitsmethoden

• Git Workflow: Es wird derselbe Mechanismus verwendet, den die meisten Software Entwickler bereits kennen und aktiv verwenden. Jede Änderung an der Applikation oder der Konfiguration ist in Git als Änderung sichtbar. Somit existiert für jede Änderung ein kompletter Audit Trail, indem sichtbar ist, wer was geändert hat. Allfällige Rollbacks sind somit einfach und effizient zu managen.
• CI Pipeline: Mit dem GitOps-Ansatz entsteht eine saubere Trennung von Continous Integration Systemen wie Gitlab oder Github und den Continuous Deployment Tools wie ArgoCD. Softwareentwickler kennen dieses Konzept möglicherweise auch unter den Namen „Loose Coupling and Strong Cohesion“ oder „Seperation Of Concerns“.
• Infrastructure As Code
• Tracking and Observability

Hinweis: Dieser Blogbeitrag fokussiert sich auf die Installation von Applikationen mittels ArgoCD Operator in bereits existierende Cluster. Methoden und Muster, wie ArgoCD in einem Cluster deployed wird (z.B. Central Hub / Cluster Scoped / Application Scoped) sind nicht Bestandteil dieses Beitrags.

Tools

Momentan existieren mehrere Tools, mit denen sich das GitOps Konzept umsetzen lässt. Dieser Blogbeitrag konzentriert sich auf ArgoCD und die Erfahrung, die wir mit diesem Tool gesammelt haben.

ArgoCD

Argo CD ist zur Zeit wohl das am meist verbreitete GitOps Tool. Es bietet Features wie manuelle oder vollautomatische GitOps-Deployments, ein Command Line Interface sowie eine Web UI zum verwalten und monitoren von Deployments. Die GitOps-Deployments werden durch ArgoCD Kubernetes CRDs gesteuert und sind somit auch selbst komplett deklarativ. Weiter erkennt ArgoCD automatisch Configuration-Drifts und hat die Möglichkeit eines Self-Heal Modus‘. Darüber hinaus verfügt es auch über einige Security Features wie beispielsweise RBAC und unterstütz das Single Sign On (SSO) verschiedener Provider.

ArgoCD Muster (Pattern)

In unserer täglichen Arbeit haben sich gewisse Muster ergeben, welche die Arbeit mit ArgoCD stark vereinfachen.

DevOps-Git-Repositories

Das Verwenden von zwei verschiedenen Git-Repositories für die Konfiguration (OPS Repository) und den Sourcecode (Dev Repository) pro Applikation wird aus folgenden Gründen empfohlen:

• Klare Trennung von Applikations-Code und -Konfiguration. Denjenigen die mit dem Konzept der 12-Factor Apps vertraut sind, dürfte dieses Muster bekannt vorkommen.
• Bessere Audit Logs. Durch ein dediziertes OPS-Repository welches nur die Konfiguration enthält, kann einfach nachvollzogen werden, wer, was und wann an der Konfiguration geändert hat. Die Commit-History bleibt so übersichtlich und wird nicht durch Dev-Commits verunreinigt.
• Build only if necessary. Die DEV-Repository-Pipeline wird nur dann ausgeführt, wenn sich am Sourcecode etwas ändert. Hierbei ist keine Synchronisation durch ArgoCD notwendig. Umgekehrt wird ArgoCD nur dann getriggert, wenn sich etwas im OPS-Repositoy ändert. In diesem Fall wird die Build-Pipeline des DEV-Repositories nicht gestartet.
• Seperation Of Access. Durch die Trennung von Dev und Ops Repositories kann der Zugriff auf die entsprechenden Repos besser gesteuert werden, was das Risiko unbeabsichtigte Änderungen minimiert. Entwickler haben nur auf das DEV-Repository Zugriff, während dem Betreiber nur auf das OPS-Repository Zugriff haben.

DevOps-Infra-Repositories

Das DevOps-Repository Muster kann bei Bedarf mit dem sogenannten Infra-Repository erweitert werden. Dies würde es erlauben, eine noch striktere Trennung der Verantwortlichkeiten vorzunehmen. Das Dev- wie auch das Ops-Repository wird für einzelne Services verwendet, während dem das Infra Repository die Deployment-Resourcen für die Infratruktur und Projekt Komponenten verwendet.

• Klare Trennung von Services und Infrastruktur. Die Projekt-Erstellung sowie die Definitionen der Quota können sauber vom Service-Deployment getrennt werden.
• Seperation Of Access. Durch die Trennung der DevOps- und Infra-Repositories kann der Zugriff auf die entsprechenden Repositories besser gesteuert werden. Entwickler haben nur auf das DevOps-Repository Zugriff, während Infra-Leute exklusiv auf das Infra-Repository zugreifen können.

Hinweis zu Mono-Repos Viel zu häufig treffen wir auch sogenannte Mono-Repos in freier Wildbahn an. Mono-Repos sind Git-Repositories, die mehr als nur ein Projekt beinhalten. Solche Repositoriey bestehen beispielsweise aus Frontend und Backend. Wir raten davon ab, Mono-Repos zu verwenden, da die Nachteile weitaus grösser sind, als die Vorteile.

App Of Apps

Das App of Apps Muster beschreibt das Deployment mehrer Apps durch eine einzelne ArgoCD Application. App of Apps ermöglicht das Deployen meherer gebündelter Services. Hierfür wird eine soganannte Root- oder auch Parent-App genannte Argo CD Application deployt. Diese Root App zeigt auf ein Repository, das die sogenannten Child-Applications für die entsprechenden Services enthält.

Application-Set

ArgoCD Application-Set bietet die Möglichkeit, mehrere Argo CD Applikationen aus einer Resource-Definition zu erstellen. Besonders geeignet sind Application-Sets für Multi-Cluster / Multi-Environments sowie Multi-Tenant Deployments. Die Idee dahinter ist jene, dass die Application-Set als eine Art Template für Applikationen dient und den Konfigurationsaufwand für Multi-Environments reduziert.

• Deployen einer Applikation in verschiedenen Environments (z.B. Dev -> Test -> UAC -> Integration -> Production)
• Deployen einer Applikation für verschiedene Tenants

Helm Umbrella Chart

Der Helm Umbrella Chart folgt einem ähnlichen Prinzip wie dem des App of Apps. Beim Helm Umbrella Chart werden die Services jedoch nicht über eine ArgoCD App, sondern mit einem sogenannten Umbrella Helm Chart gebündelt. Dieses Chart hat die Besonderheit dass es selbst keine Templates enthält sondern nur Verweise auf die Helm Charts welche zusammen deployed werden. Diese Dependencies werden im Chart.yaml definiert.
Gegenüber dem App Of Apps Pattern hat diese Methode den Vorteil, dass die Services nur mit Helm gebündelt werden und somit auch ein lokales Deployment und Debugging möglich ist. Ausserdem bieten Helm Dependencies den Vorteil, dass eine sogenannte Version Range der Subcharts definiert werden kann. Dies ermöglicht es, die Version-Kompatiblität der einzlenen Bundle-Komponenten innerhalb des Helm Charts zu definieren.

Recap

Wir haben in diesem Teil die Grundprinzipien von GitOps kennengelernt. Zudem haben wir gesehen, welche Patterns es gibt, damit das Deployment so einfach und reibungslos wie möglich funktioniert. Dies alleine ermöglicht es uns bereits, unser Projekt so aufzusetzen und zu planen, damit der produktive Betrieb so einfach und fehlerfrei wie möglich abläuft.

Im nächsten Teil werden wir ArgoCD und Security näher anschauen, damit wir verstehen, wie wir unser GitOps-Konzept auch Security-technisch absichern können.