Ein Beispiel für den Einsatz von GitOps zur Bereitstellung einer modernen Anwendungs­entwicklungs­plattform

Die Bausteine für die deklarative Clusterkonfiguration sind die folgenden:

Helm-Charts: Diese sind wie ein Paketmanager für Kubernetes-Anwendungen, die als ein Satz von Kubernetes-Ressourcen beschrieben werden.

Kustomize: Es verwaltet verschiedene Varianten Ihrer Anwendungskonfiguration, ohne die ursprünglichen YAML-Dateien zu verändern.

ArgoCD-Instanzen: Dies ist eine Anwendung, die kontinuierliche Bereitstellungen auf dem Cluster verwaltet. Um eine Eskalation der Privilegien zu vermeiden, wurden zwei ArgoCD-Instanzen eingerichtet. Eine dieser Instanzen wird für die Konfiguration des Clusters verwendet.

Das „App of Apps“-Pattern: Eine übergeordnete Anwendung setzt mehrere untergeordnete Anwendungen ein.

ArgoCD-Applications: Dies sind Kubernetes-Ressourcen, die die Quelle (Git-Repository) und das Ziel (Zielcluster) für die automatische Bereitstellung Ihrer Anwendungen definieren.

ArgoCD ApplicationSets: Dies sind ArgoCD-Ressourcen für die automatische Generierung von ArgoCD-Anwendungen auf der Grundlage von Vorlagen und Quellen wie Git-Repositories, Clusterlisten usw.
Die Helm-charts werden als Formen (Quadrate, Dreiecke, etc.) dargestellt, die bestimmte Teile des Clusters mit bestimmten Parametern konfigurieren. Diese Parameter können je nach der Umgebung, in der sie installiert werden müssen, angepasst oder gepatcht werden. Dies geschieht durch die Verwendung von Overlays (kustomize), um bestimmte Basiskonfigurationen auf diese Zielumgebungen zu übertragen.

Dabei kann es sich beispielsweise um verschiedene Cluster-Umgebungen handeln, die eine Test-, eine Entwicklungs- oder eine Produktivumgebung darstellen, wenn diese vollständig isoliert werden sollen. Unten sehen Sie eine vereinfachte Darstellung dieses Konzepts, die drei verschiedene Umgebungen zeigt, die auf der Grundlage der Basiskonfigurationen unterschiedlich konfiguriert sind (farblich gekennzeichnet). Die Basiskonfigurationen enthalten wiederum verschiedene Kubernetes-Ressourcen, die mit Helm- oder ArgoCD-Anwendungen konfiguriert werden. Stell dir die Overlays wie Pizzabeläge vor. Ihre Basiskonfiguration ist wie ein Pizzaboden und verschiedene Beläge definieren die endgültige Art Ihrer Pizza. Eine Margherita wird andere Beläge haben als eine Napolitana. In ähnlicher Weise unterscheiden sich auch die Parameter, die in den Zielumgebungen gepatcht werden müssen. Daher kannst du den Code für die Konfiguration verschiedener Umgebungen wiederverwenden.

Zu den Aufgaben der Clusterkonfiguration gehört auch die Schaffung von Namensräumen im Cluster für Anwendungsteams, die wir Tenant Onboarding nennen. Stell dir diese Bereiche wie Kabinen in einem Co-Working Space vor, in denen du arbeiten und andere Dienste wie die Speisekammer oder den Aufenthaltsraum nutzen kannst, die von anderen Mitarbeitern mitbenutzt werden. In ähnlicher Weise erhalten die Tenants ihren eigenen Namensraum und nutzen die Worker Nodes oder die Tektin/ArgoCD-Instanz, die für die Erstellung und Bereitstellung ihrer Anwendungen verwendet werden, gemeinsam mit anderen Tenants. Dies wiederum ermöglicht Selbstbedienungsfunktionen für Ihre Entwicklungsteams. Der Arbeitsablauf könnte wie folgt aussehen:

Das Anwendungsteam erstellt eine Pull-Anfrage, um sich selbst einzubinden, indem es Informationen (Parameter) zur Verfügung stellt, die es betreffen, wie die AD-Gruppe, zu der sein Team gehört, die Anzahl und Namen der verschiedenen benötigten Umgebungen, das Repo für den Quellcode seiner Anwendung und Kubernetes-Anwendungsmanifeste, die seine CI/CD-Pipeline definieren.

Nach dem Hinzufügen einer Tenant-Parameterdatei zum Git-Repo, die wie folgt aussehen könnte: