ArgoCD deployen: von der Helm-Installation bis zur ersten App

GitOps heißt: der gewünschte Zustand steht in Git, und ein Controller im Cluster sorgt dafür, dass die Wirklichkeit dem folgt. ArgoCD ist der verbreitetste dieser Controller. In diesem Artikel gehe ich den Weg einmal von vorne durch: Ich installiere ArgoCD per Helm, hole mir den ersten Zugang, melde mich an und zeige danach, worauf ich bei der Konfiguration und im Betrieb achte.

Installation per Helm

ArgoCD kommt als Helm-Chart, das ich in einen eigenen Namespace installiere. Für den Anfang lasse ich die Zusatzkomponenten weg, die man selten sofort braucht. Das hält die Installation überschaubar. Zuerst füge ich das Helm-Repository hinzu:

helm repo add argo https://argoproj.github.io/argo-helm

Danach installiere ich das Chart. Der Namespace wird dabei gleich mit angelegt, und über die --set-Flags schalte ich Dex, Notifications und ApplicationSet zunächst ab:

helm install argocd argo/argo-cd -n argocd --create-namespace \
  --set dex.enabled=false \
  --set notifications.enabled=false \
  --set applicationSet.enabled=false

Details zu diesem Kommando und seinen Optionen stehen in der Helm-Dokumentation zu helm install. Nach ein paar Minuten laufen die Pods (Controller, Repo-Server, Redis, Server). Ab jetzt ist ArgoCD bereit, Applications zu verwalten. Den kompletten Ablauf beschreibt auch das offizielle Getting-Started-Kapitel von ArgoCD.

Zugang und erster Login

Das Web-Interface liegt hinter dem argocd-server-Service. Für den ersten Blick genügt ein Port-Forward, im Betrieb setzt man es hinter den Reverse Proxy:

kubectl -n argocd port-forward svc/argocd-server 8080:80

Das Startpasswort für den admin steht in einem Secret, das das Chart anlegt:

kubectl -n argocd get secret argocd-initial-admin-secret \
  -o jsonpath='{.data.password}' | base64 -d

Danach begrüßt einen die Anmeldemaske, und nach dem Login die noch leere Applications-Übersicht, in der später jede verwaltete Anwendung als Kachel erscheint.

Konfiguration gehört in die Values

Ein Fehler, den man genau einmal macht: die ArgoCD-Konfiguration nach der Installation per kubectl edit an der laufenden Ressource zu ändern. Weil ArgoCD Helm-managed ist, überschreibt der nächste helm upgrade diese Änderung wieder. Alles, was bleiben soll (RBAC, OIDC, server.insecure für den TLS-Offload am Proxy), gehört in die Helm-Values und damit selbst nach Git. Wie ArgoCD sich deklarativ über Manifeste konfigurieren lässt, beschreibt die Doku zum Declarative Setup. ArgoCD verwaltet fremde Apps deklarativ, also verdient es, selbst deklarativ verwaltet zu werden.

Ehrlich: ArgoCD ist selbst ein Dienst

ArgoCD nimmt einem das manuelle Ausrollen ab, ist aber selbst eine Anwendung, die Pflege braucht: Updates, Zugriffsschutz, bei Bedarf Hochverfügbarkeit und eine Anbindung an Ihr Login (SSO). Für ein, zwei Deployments ist das mehr Overhead als Nutzen. Ab mehreren Umgebungen, in denen nachvollziehbar sein muss, wer wann was ausgerollt hat, zahlt es sich schnell aus.

Sie wollen Ausrollen und Rückrollen nachvollziehbar statt per Hand? Ich baue GitOps-Strecken, in denen der Soll-Zustand in Git steht und Änderungen als Freigabe laufen. Mehr unter IT-Automatisierung, das Erstgespräch ist unverbindlich.