Argo CD Argo CD

Deine erste Anwendung mit einem deklarativen Manifest deployen

Richte Argo CD mit einer Application-Ressource auf ein Git-Repository aus und sieh dem Sync zu.

12 min Anfänger

Argo CD wird wie alles andere im Cluster mit Kubernetes-Ressourcen konfiguriert. Die zentrale heißt Application: Sie sagt „nimm die Manifeste unter diesem Pfad in diesem Repository und halte sie auf diesem Cluster und in diesem Namespace angewendet“. Diese Anleitung erstellt ein kleines Konfigurations-Repository, registriert es mit einer Application und ändert anschließend Git, um den Sync zu beobachten. Sie setzt voraus, dass Argo CD installiert ist und du dich anmelden kannst (siehe die vorherige Anleitung).

Ein Konfigurations-Repository vorbereiten

Erstelle ein Git-Repository (bei einem beliebigen Host, den Argo CD erreichen kann) mit diesem Aufbau:

webapp-config/
├── application.yaml      # die Argo CD Application, einmal von Hand angewendet
└── dev/
    ├── deployment.yaml
    └── service.yaml

dev/deployment.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: webapp
spec:
  replicas: 2
  selector:
    matchLabels:
      app: webapp
  template:
    metadata:
      labels:
        app: webapp
    spec:
      containers:
        - name: webapp
          image: nginx:1.25
          ports:
            - containerPort: 80

dev/service.yaml:

apiVersion: v1
kind: Service
metadata:
  name: webapp
spec:
  selector:
    app: webapp
  ports:
    - port: 80
      targetPort: 80

Die Manifeste lassen den Namespace bewusst weg. Argo CD wendet sie in dem Ziel-Namespace an, den du als Nächstes konfigurierst. Lege application.yaml außerhalb des synchronisierten Pfads (dev/) ab, damit die Anwendung nicht versucht, ihre eigene Definition zu verwalten. Ist das Repository privat, füge zuerst in der Oberfläche unter Settings → Repositories die Zugangsdaten hinzu.

Das Application-Manifest schreiben

application.yaml:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: webapp-dev
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/your-org/webapp-config.git
    targetRevision: HEAD
    path: dev
  destination:
    server: https://kubernetes.default.svc
    namespace: webapp
  syncPolicy:
    syncOptions:
      - CreateNamespace=true
    automated:
      prune: true
      selfHeal: true

Die wichtigen Teile:

  • source ist der Ort, an dem der Soll-Zustand liegt: das Repository, die verfolgte Revision (HEAD folgt dem Standard-Branch) und der Ordner darin.
  • destination ist der Ort, an dem er angewendet wird. https://kubernetes.default.svc bedeutet „der Cluster, in dem Argo CD selbst läuft“. Um einen externen Cluster zu verwalten, registrierst du ihn und verwendest stattdessen seine API-Server-Adresse.
  • project: default ordnet die Anwendung dem eingebauten Projekt von Argo CD zu. Projekte gruppieren Anwendungen und beschränken, was sie deployen dürfen.
  • syncPolicy aktiviert den automatischen Sync und erstellt den Namespace, falls er nicht existiert. Was prune und selfHeal bewirken, behandelt eine eigene Anleitung. Prüfe die apiVersion gegen die aktuelle Dokumentation, denn das ist das Feld, das sich zwischen Releases am ehesten ändert.

Die Anwendung registrieren

Committe und pushe das Repository und wende das Manifest dann einmal auf den Cluster an:

kubectl apply -f application.yaml

Im Idealfall ist das das letzte Mal, dass du kubectl apply für diese Anwendung ausführst. Von hier an laufen Änderungen über Git.

Den Ressourcenbaum erkunden

Öffne die Oberfläche. Die Anwendung webapp-dev erscheint und wechselt innerhalb weniger Sekunden zu Synced und Healthy. Öffne sie, um den Ressourcenbaum zu sehen: den Service, das Deployment, das darunterliegende ReplicaSet und zwei Pods. Wenn du eine Ressource auswählst, siehst du ihr Live-Manifest, ihre Events und (bei Pods) ihre Logs – oft schneller, als ins Terminal zu wechseln. Bestätige es auch vom Cluster aus:

kubectl get all -n webapp

Git ändern und den Sync beobachten

Bearbeite dev/deployment.yaml in deinem Repository, ändere den Image-Tag auf nginx:1.26 und committe auf den verfolgten Branch. Argo CD fragt Repositories standardmäßig alle drei Minuten ab. Warte also entweder, oder klicke bei der Anwendung auf Refresh, damit sie sofort prüft. Die Anwendung zeigt kurz OutOfSync, dann wird ein neues ReplicaSet ausgerollt. Prüfe, dass die Änderung angekommen ist:

kubectl get deploy webapp -n webapp \
  -o jsonpath='{.spec.template.spec.containers[0].image}'; echo

Das ist der ganze Kreislauf: Git bearbeiten, Argo CD bringt den Cluster auf diesen Stand. Die nächste Anleitung behandelt, wie du dieses Verhalten steuerst.

Beliebte Anleitungen