Projekt anfragen
Nahaufnahme von farbig hervorgehobenem Programmcode auf einem Monitor

GitOps · Argo CD · Kubernetes

GitOps mit Argo CD einführen und automatisieren

Der Zustand Ihrer Cluster liegt in Git, Argo CD gleicht ihn ab, und Freigabe wie Rückrollen laufen über Pull Requests statt über Zugangsdaten in der CI.

Projekt anfragen Zur Promotion-Prozedur

Autor: Ibrahim Yesilay, Gründer und Geschäftsführer Stand:

01Ausgangslage

Wenn kubectl apply der Release-Prozess ist

Für Platform-Teams, die mehrere Anwendungen, Umgebungen oder Cluster einheitlich ausliefern wollen. Diese Seite ergänzt die DevOps-Beratung, die den Weg vom Commit bis zum Manifest-Repository beschreibt, um die zweite Hälfte: Aufbau und Betrieb des GitOps-Repositories und der Argo-CD-Konfiguration. Zur Pipeline davor: CI/CD-Pipelines.

  • Auslieferung per kubectl apply oder Pipeline-Skript direkt in den Cluster, mit Cluster-Zugangsdaten in der CI.
  • Test und Produktion weichen voneinander ab, ohne dass jemand es nachvollziehen kann.
  • Ein neuer Cluster bedeutet Wochen manueller Konfiguration.
  • Rückrollen ist Spezialwissen einzelner Personen.
Person skizziert einen Projektablauf mit Marker auf einem Whiteboard

02Ergebnisse

Was nach dem Projekt in Git und im Cluster steht

  • Zielbild und Repository-Strategie

    Anwendungs-Repositories und Manifest-Repositories getrennt; Entscheidung über die Struktur anhand des Layouts weiter unten.

  • Argo-CD-Betrieb

    Installation, Hochverfügbarkeit nach Bedarf, Anbindung an Ihre Identität, Rechtekonzept (RBAC) je Team und Umgebung.

  • Anwendungsdefinition

    Helm oder Kustomize je Anwendung; Applications werden per ApplicationSet generiert.

  • Promotion und Freigabe

    Ein definiertes Verfahren, wie ein Stand von Umgebung zu Umgebung wandert.

  • Rollback und Drift

    Rücknahme per Revert; geregelter Umgang mit Abweichungen im Cluster.

  • Secrets

    Geheimnisse nicht im Klartext im Repository; Anbindung an einen Secret-Mechanismus nach Ihrem Standard.

  • Dokumentation und Einweisung

    Runbooks und eine Einweisung für Ihr Team.

03Repository-Layout

Ein Manifest-Repository, aus dem ApplicationSets die Applications erzeugen

Laut Argo-CD-Dokumentation fügt der ApplicationSet-Controller eine ApplicationSet-Ressource hinzu, die aus einer Vorlage Argo-CD-Applications erzeugt; das hilft bei vielen Clustern, Monorepos und Self-Service auf Mandanten-Clustern. Ein typisches Layout:

gitops/
  apps/
    shop/
      base/                  # gemeinsame Manifeste oder Helm-Chart
      overlays/
        staging/             # Kustomize-Overlay: Replikas, Hostnamen
        prod/
    billing/
      ...
  clusters/
    staging-eu/              # welche Apps laufen auf diesem Cluster
    prod-eu/
  platform/                  # Ingress, Zertifikate, Monitoring: Plattformteam
  applicationsets/
    apps.yaml                # erzeugt je App und Umgebung eine Application

04ApplicationSet

Welcher Generator für welchen Zuschnitt

Die dokumentierten Generatoren sind List, Cluster, Git, OCI und Matrix. Die Zuordnung ist unsere Empfehlung, nicht die einzige Möglichkeit.

Zuordnung der ApplicationSet-Generatoren zu Einsatzfällen
GeneratorEinsatz
Git„Je Verzeichnis eine Application“: neue App-Ordner erzeugen automatisch eine Application.
Cluster„Auf jedem registrierten Cluster“: Plattform-Bausteine, die überall laufen sollen.
MatrixKombination, zum Beispiel jede App auf jedem Cluster einer Umgebungsklasse.
ListNur für kleine, feste Fälle; er skaliert nicht mit neuen Teams.

Die Argo-CD-Dokumentation weist darauf hin, die Sicherheitsfolgen von ApplicationSets vor dem Einsatz zu bewerten, besonders bei Self-Service. Wir legen deshalb fest, welche Projekte, Namespaces und Quellen ein Team über seine ApplicationSets ansprechen darf.

05

Der Cluster zieht den Zustand, die Pipeline braucht keinen Zugang

Der Pull Request im Manifest-Repository erhöht den Image-Digest; Argo CD im Management-Cluster gleicht Soll und Ist mit Staging und Produktion ab, und die Rechte sind je Team und Umgebung begrenzt.

GitOps-Ablauf mit Argo CD Das Anwendungs-Repository erhöht per Pull Request den Image-Digest im Manifest-Repository. Argo CD mit ApplicationSet-Controller gleicht den Soll-Zustand mit den Clustern staging-eu und prod-eu ab. Anwendungs-Repo Manifest-Repo Argo CD Cluster staging-eu Cluster prod-eu RBAC Build, Image-Digest apps/ clusters/ platform/ (Management-Cluster) ApplicationSet-Controller Team A darf apps/shop in staging syncen gleicht Soll/Ist ab gleicht Soll/Ist ab PR erhöhtImage-Digest Pull-Modell Schematische Darstellung, Argo CD gleicht Soll (Git) und Ist (Cluster) ab
GitOps-Ablauf mit Argo CD Das Anwendungs-Repository erhöht per Pull Request den Image-Digest im Manifest-Repository. Argo CD mit ApplicationSet-Controller gleicht den Soll-Zustand mit den Clustern staging-eu und prod-eu ab. Anwendungs-Repo Manifest-Repo Argo CD Clusterstaging-eu Clusterprod-eu RBAC Build, Image-Digest apps/ clusters/ platform/ (Management-Cluster) ApplicationSet-Controller gleicht Soll/Ist ab gleicht Soll/Ist ab Team A darf apps/shop in staging syncen PR erhöht Image-Digest Pull-Modell Schematische Darstellung, Argo CD gleichtSoll (Git) und Ist (Cluster) ab

06Promotion

Derselbe Digest von Staging nach Produktion

Das Artefakt, das in Staging getestet wurde, geht nach Produktion; es wird nicht neu gebaut.

  1. 01

    Image bauen und ablegen

    Ergebnis: Digest

    Die CI-Pipeline baut und prüft ein Image und legt es per Digest ab (CI/CD-Pipelines).

  2. 02

    Staging per Pull Request

    Ein automatischer Pull Request trägt den Digest im Overlay staging ein; nach dem Merge synchronisiert Argo CD den Staging-Cluster.

  3. 03

    Prüfung gegen Staging

    Automatische Prüfungen laufen gegen Staging; ihr Ergebnis ist Voraussetzung für die Promotion.

  4. 04

    Produktion per zweitem Pull Request

    Ein zweiter Pull Request überträgt denselben Digest in prod; die verantwortliche Rolle gibt frei (Vier-Augen-Prinzip nach Ihrem Modell).

  5. 05

    Sync und Rückrollen

    Rollback: Revert

    Nach dem Merge synchronisiert Argo CD Produktion. Rückrollen ist ein Revert des Pull Requests.

07Sicherheit

Zugriff, Zugangsdaten und was nicht zu diesem Projekt gehört

  • Keine Cluster-Zugangsdaten in der CI

    Pipelines brauchen keinen Zugang zum Cluster, der Cluster zieht den Zustand aus Git.

  • Minimale Rechte

    Zugriff auf Argo CD nach dem Prinzip der minimalen Rechte, angebunden an Ihre Identitätsverwaltung. Wir arbeiten in Ihren Repositories und Clustern, zeitlich und rollenbasiert begrenzt.

  • Eigener Umfang

    Cluster-Härtung und Supply-Chain-Prüfung gehören nicht zu diesem Projekt; dafür gibt es Cloud Security.

08Vorbereitung

Angaben zu Clustern, Pipelines und Freigaben vor dem ersten Argo-CD-Sync

  • Liste der Anwendungen und Umgebungen
  • Die Cluster: Anzahl, Plattform, Betreiber
  • Das Git-System (GitLab, GitHub)
  • Vorhandene Pipelines für Build und Test
  • Ihr Freigabemodell je Umgebung
  • Die Identitätsverwaltung für den Zugriff auf Argo CD
  • Eine benannte verantwortliche Person für das GitOps-Repository

09Einordnung

Für welche Umgebungen sich GitOps mit Argo CD lohnt

Das passt

  • Mehrere Anwendungen, Umgebungen oder Cluster sollen einheitlich ausgeliefert werden.
  • Ein Team übernimmt die Verantwortung für das Manifest-Repository.

Das ist ein anderer Weg

  • Sie betreiben keine Kubernetes-Umgebung; dann ist GitOps mit Argo CD nicht der passende Weg.
  • Sie haben einen Cluster und eine Anwendung; der Aufwand für Layout und Promotion lohnt sich meist nicht.
  • Niemand will das Manifest-Repository verantworten. Dann bieten wir den Betrieb an: Managed DevOps.
  • Sie suchen eine ganze Entwicklerplattform für viele Teams: Platform Engineering.

10

Davor, daneben und darüber

Beschreiben Sie Ihre Cluster, Umgebungen und den heutigen Auslieferungsweg

Den Aufwand bestimmen Zahl der Anwendungen, Umgebungen und Cluster, vorhandene Pipelines, Freigabe- und Sicherheitsanforderungen, Secret-Handling und der Anteil von Beratung, Umsetzung und Betrieb.

Projekt anfragen