Kargo verbindet CI-Tools mit ArgoCD – so gelingt GitOps effizient

Die größte Herausforderung in GitOps-Projekten? Wer aktualisiert eigentlich das Git-Repository?

ArgoCD überprüft kontinuierlich den Kubernetes-Cluster und passt die Infrastruktur an den gewünschten Zustand an, der in Git definiert ist. Doch wer sorgt dafür, dass neue Container-Images oder Helm-Charts in die Manifest-Dateien eingetragen werden? Traditionell übernimmt dies die CI-Pipeline – doch diese Lösung führt oft zu unübersichtlichen Abhängigkeiten und starrer Architektur.

Genau hier setzt Kargo an, ein Werkzeug des ArgoCD-Hintergrundteams Akuity. Es fungiert als Brücke zwischen der Bereitstellung von Artefakten in einem Container-Registry und der Aktualisierung der GitOps-Manifeste. Die Kernidee: Automatisierung, die sich um die „Promotion“ von Software-Ständen durch verschiedene Umgebungen kümmert – ohne dass die CI-Pipeline sich mit Kubernetes-Konfigurationen beschäftigen muss.

Warum GitOps ohne Kargo an Grenzen stößt

In einer typischen GitOps-Umgebung existieren zwei zentrale Repositories:

• Anwendungs-Repository: Entwickler schreiben hier den Quellcode und die CI-Pipeline.
• GitOps-Repository: Enthält die Kubernetes-Manifeste, die ArgoCD zur Bereitstellung nutzt.

Der klassische Workflow sieht so aus:

• Die CI-Pipeline baut ein Container-Image, testet es und überträgt es in ein Registry.
• Anschließend muss die CI-Pipeline das GitOps-Repository aktualisieren, indem sie beispielsweise die Image-Tag in einer YAML-Datei anpasst.
• ArgoCD erkennt die Änderung im GitOps-Repository und synchronisiert den Cluster.

Doch dieser Ansatz hat entscheidende Nachteile:

• Starre Kopplung: Jede Anwendung muss ihre CI-Pipeline an die Struktur des GitOps-Repositories anpassen. Änderungen an Kustomize-Overlays oder Umgebungsdefinitionen erfordern Anpassungen in allen CI-Konfigurationen.
• Verwaltungsaufwand: Teams, die neue Umgebungen oder Promotionspfade einführen, müssen in jedem Repository die .gitlab-ci.yml oder ähnliche Dateien bearbeiten.
• Fehlende Standardisierung: Jede Anwendung definiert ihre eigene Logik zur Aktualisierung der Manifeste – eine Herausforderung für die Wartung.

Wie Kargo die Lücke schließt

Kargo wurde speziell dafür entwickelt, die Lücke zwischen der Bereitstellung von Artefakten und der Aktualisierung der GitOps-Manifeste zu schließen. Es übernimmt die Rolle des „Promotion-Controllers“ und arbeitet nahtlos mit ArgoCD zusammen – ohne dieses zu ersetzen.

Die Architektur von Kargo basiert auf vier zentralen Konzepten:

1. Warehouses: Die Wächter der Artefakte

Ein Warehouse überwacht Container-Registries und andere Quellen (z. B. Helm-Charts oder Git-Commits) auf neue Artefakte. Sobald ein neues Image oder eine neue Chart-Version verfügbar ist, erstellt es eine Freight-Einheit. Diese Freight fungiert als Container für alle relevanten Versionen einer Anwendung und ihrer Abhängigkeiten.

2. Freight: Die Reise durch die Umgebungen

Freight ist kein physisches Artefakt, sondern eine Metadaten-Struktur, die alle Informationen zu den zu fördernden Artefakten enthält. Sie durchläuft die definierten Stages (z. B. Entwicklung, Staging, Produktion) und wird dabei schrittweise aktualisiert.

3. Stages: Die Promotions-Pipeline

Jede Stage entspricht einer Umgebung und definiert, wohin Freight gefördert wird. Kargo unterstützt sowohl automatische als auch manuelle Promotions. Beispielsweise kann eine neue Version zunächst automatisch in die Entwicklungs-Umgebung gefördert werden, während die Förderung in die Produktionsumgebung manuell bestätigt werden muss.

4. PromotionTasks: Standardisierte Aktionen

Hier liegt der Schlüssel zur Flexibilität: PromotionTasks definieren die konkreten Schritte, die beim Fördern von Freight in eine Stage ausgeführt werden müssen. Kargo bietet zwei Typen:

• ClusterPromotionTasks: Werden clusterweit definiert und können von allen Projekten genutzt werden. Ideal für wiederkehrende Aufgaben wie das Aktualisieren von Image-Tags oder Helm-Chart-Versionen.
• PromotionTasks: Projekt-spezifische Workflows, die individuelle Logik erfordern (z. B. Datenbank-Migrationen vor der Promotion).

Ein typischer Kargo-Workflow

Der Prozess beginnt mit der CI-Pipeline, die ein neues Container-Image erstellt und in ein Registry (beispielsweise AWS ECR) überträgt. Kargo übernimmt ab hier:

1. Das Warehouse erkennt das neue Image und erstellt eine Freight-Einheit.
2. Die Freight wird in die dev-Stage gefördert. Ein ClusterPromotionTask klont das GitOps-Repository, aktualisiert die Image-Tag in der entsprechenden YAML-Datei und überträgt die Änderungen per Commit.
3. ArgoCD erkennt die Änderung im GitOps-Repository und synchronisiert den Cluster.
4. Für die Förderung in die prod-Stage wird die Freight manuell über die Kargo-Benutzeroberfläche bestätigt. Der gleiche ClusterPromotionTask wird erneut ausgeführt – diesmal für die Produktionsumgebung.

Beispiel: ClusterPromotionTask für Image-Updates

Ein ClusterPromotionTask zur Aktualisierung von Image-Tags könnte wie folgt aussehen:

apiVersion: kargo.akuity.io/v1alpha1
kind: ClusterPromotionTask
metadata:
  name: cluster-promote-image-git
spec:
  vars:
    - name: branch
      value: main
    - name: repoURL
      value: git@gitlab.com:mein-team/gitops-repo.git
    - name: yamlFilename
      value: deployment.yaml
    - name: envPath
      value: overlays/production
  steps:
    - uses: git-clone
      config:
        repoURL: ${{ vars.repoURL }}
        checkout:
          branch: ${{ vars.branch }}
        create: true
        path: ./out-image
    - uses: yaml-update
      as: update-image
      config:
        path: ./out-image/${{ vars.envPath }}/${{ vars.yamlFilename }}
        updates:
          - key: spec.image.tag
            value: ${{ quote(imageFrom(vars.image).Tag) }}
    - uses: git-commit
      as: commit
      config:
        path: ./out-image
        message: "Update image to version ${{ imageFrom(vars.image).Tag }}"
    - uses: git-push
      config:
        path: ./out-image

Dieser Task ist wiederverwendbar und nutzt Variablen, um sich an verschiedene Umgebungen anzupassen. Die grundlegende Logik bleibt gleich – nur die Pfade und Dateinamen werden angepasst.

Vorteile auf einen Blick

• Entkopplung der CI-Pipeline: Die CI muss sich nicht mehr um GitOps-Manifeste kümmern. Sie überträgt nur noch das Artefakt in das Registry.
• Standardisierung: ClusterPromotionTasks definieren die Promotion-Logik zentral und machen sie für alle Projekte verfügbar.
• Flexibilität: Manuelle Promotions ermöglichen kontrollierte Freigaben in Produktivumgebungen.
• Transparenz: Die Kargo-Benutzeroberfläche bietet einen klaren Überblick über den Fortschritt der Promotion durch die verschiedenen Stages.

Fazit: GitOps vereinfachen mit Kargo

Kargo zeigt, wie GitOps-Workflows durch gezielte Automatisierung effizienter und wartbarer gestaltet werden können. Es übernimmt die Verantwortung für die Lücke zwischen der Bereitstellung von Artefakten und der Aktualisierung der GitOps-Manifeste – ohne die Flexibilität oder Kontrolle einzuschränken.

Für Teams, die ArgoCD nutzen und nach einer Lösung suchen, um die Promotionslogik zu zentralisieren und zu standardisieren, ist Kargo eine überzeugende Ergänzung. Die Integration ist unkompliziert, und die Dokumentation bietet klare Anleitungen für die Einrichtung. Die Zukunft von GitOps könnte damit noch stärker in Richtung Modularität und Standardisierung gehen – und Kargo ist ein Schritt in diese Richtung.

Wer bisher mit den Herausforderungen der GitOps-Promotion kämpft, sollte Kargo einmal ausprobieren – es könnte die fehlende Komponente sein, um den Workflow zu perfektionieren.