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.
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:
sourceist der Ort, an dem der Soll-Zustand liegt: das Repository, die verfolgte Revision (HEADfolgt dem Standard-Branch) und der Ordner darin.destinationist der Ort, an dem er angewendet wird.https://kubernetes.default.svcbedeutet „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: defaultordnet die Anwendung dem eingebauten Projekt von Argo CD zu. Projekte gruppieren Anwendungen und beschränken, was sie deployen dürfen.syncPolicyaktiviert den automatischen Sync und erstellt den Namespace, falls er nicht existiert. WaspruneundselfHealbewirken, behandelt eine eigene Anleitung. Prüfe dieapiVersiongegen 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
-
Push vs. Pull: Wie Argo CD auf Kubernetes ausliefert Warum pull-basierte, Git-gesteuerte Auslieferung verändert, wie du Cluster deployst, absicherst und wiederherstellst. -
Multi-Cluster mit Argo CD konfigurieren Deployments über mehrere Cluster hinweg verwalten. -
Sync-Verhalten steuern: Auto-Sync, Prune, Self-Heal und Rollback Entscheide, wann Argo CD Änderungen anwendet, was es löscht und wie du ein fehlerhaftes Deployment rückgängig machst.