Blog ArgoCD in der Praxis: So gelingen automatisierte Deployments

Im letzten Artikel haben wir euch gezeigt, wie wir ArgoCD installieren und zum Deployment einer Helm-Anwendung in verschiedene Umgebungen nutzen können.

Was wir bisher noch nicht betrachtet haben: Wie können wir frische Container-Images automatisch ins Cluster deployen - ganz ohne manuelle Synchronisierung?

In diesem Artikel werfen wir einen Blick auf gängige Strategien zur CI/CD-Integration mit ArgoCD - inklusive Schritt-für-Schritt-Anleitung für den ArgoCD Image Updater.

Strategien zur Automatisierung

Ziel unseres Setups ist es, den gesamten Deploy-Prozess im Sinne von GitOps zu automatisieren: Unsere GitLab-Pipeline baut neue Container-Images und pusht sie in die GitLab Container Registry. ArgoCD wiederum sorgt dafür, dass neue Images zuverlässig ins Cluster ausgerollt werden. Hierzu gibt es drei verbreitete Ansätze:

Git-Commit aus der Pipeline

Die CI/CD-Pipeline aktualisiert den Image-Tag direkt in Git (in unserem Fall in die values.yaml File) und pusht diese Anpassung. ArgoCD erkennt die Änderung und deployt automatisch. Wir arbeiten hierbei vollständig Git-gesteuert und nachvollziehbar - allerdings sind Git-Zugriff und Commit-Rechte für die Pipeline notwendig. Und damit zusätzliche Konfigurationen.

ArgoCD Sync aus der Pipeline triggern

Der neue Image-Tag ist bereits im Git (z. B. durch dynamischen Tags wie latest, dev-*, o.ä.). Die Pipeline triggert nach dem Build ein Sync der ArgoCD Application per API oder CLI. Dieser Ansatz ist einfach und schnell umzusetzen. Allerdings: Da Änderungen ohne Git-Historie erfolgen, verletzten wir das GitOps-Prinzip.

Verwendung des ArgoCD Image Updaters

Der ArgoCD Image Updater, ein Controller im Cluster, prüft die Image Registry regelmäßig auf neue Tags. Findet er diese, aktualisiert er das Git-Repository entsprechend. Diese Änderungen wiederum werden von ArgoCD erkannt und entsprechend deployed. Ebenso ist es möglich, Deployments ohne Git-Änderungen anzustoßen. Welchen Ansatz man auch verfolgt, in beiden Fällen kommt man um umfangreicheres Setup nicht umhin.

Da wir uns in dieser Serie näher mit ArgoCD befassen möchten, wollen wir uns im Folgenden auf eine der spannendsten und zugleich praktischsten Funktionen konzentrieren: den ArgoCD Image Updater.

Er ermöglicht es uns, den Deployment-Prozess schlank und übersichtlich zu gestalten – ganz ohne aufwendige Pipeline-Commits oder externe Sync-Triggers. So bleibt die Integration in ArgoCD im Fokus und wir können tiefer in die Möglichkeiten dieses Controllers eintauchen.

Im nächsten Abschnitt sehen wir uns daher an, wie der Image Updater im Detail funktioniert und wie man ihn einrichtet.

Voraussetzungen

Falls ihr direkt mit ausprobieren möchtet, benötigt ihr das Setup aus unserem vorherigen ArgoCD Artikel inklusive:

• laufendem ArgoCD

• unseren Helmcharts in GitLab mit Pipeline und gepushten images in der GitLab Registry

Zur Vereinfachung beschränken wir uns im Folgenden auf die Verwendung unserer Application-YAMLs für Frontend und Backend. Dabei werden ApplicationSets und AppProject nicht berücksichtigt.

Anpassungen unserer bisherigen Konfigurationen

Um den ArgoCD Image Updater nutzen zu können, benötigen wir zunächst ein paar Anpassungen in unseren bisherigen Dateien:

values.yaml

In den jeweiligen values.yaml files ersetzen wir den image Tag durch einen Platzhalter wie folgt:

repository: <Registry link>
tag: "abc123"

In unseren Application Dateien fügen wir jeweils Annotationen ein, um dem Image Updater aufzuzeigen, was beobachtet werden soll. Die Dateien sehen daher folgendermaßen aus:

frontend.yaml

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: frontend-dev
  namespace: argocd
  annotations:
    argocd-image-updater.argoproj.io/image-list: frontend=<Registry Link>
    argocd-image-updater.argoproj.io/frontend.update-strategy: newest-build
    argocd-image-updater.argoproj.io/frontend.helm.image-tag: image.tag
    argocd-image-updater.argoproj.io/frontend.helm.image-name: image.repository
spec:
  project: default
  source:
    targetRevision: main
    repoURL: <Repository Link>
    path: <Pfad zum Helm Chart>
    helm:
      valueFiles:
        - values/dev.yaml
  destination:
    server: https://kubernetes.default.svc
    namespace: dev 
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

backend.yaml

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: backend-dev
  namespace: argocd
  annotations:
    argocd-image-updater.argoproj.io/image-list: backend=<Registry Link>
    argocd-image-updater.argoproj.io/backend.update-strategy: newest-build
    argocd-image-updater.argoproj.io/backend.helm.image-tag: image.tag
    argocd-image-updater.argoproj.io/backend.helm.image-name: image.repository
spec:
  project: default
  source:
    targetRevision: main
    repoURL: <Repository Link>
    path: <Pfad zum Helm Chart>
    helm:
      valueFiles:
        - values/dev.yaml
  destination:
    server: https://kubernetes.default.svc
    namespace: dev 
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

Unsere Applications in ArgoCD können wir nun aktualisieren mit:

kubectl apply -f frontend.yaml
kubectl apply -f backend.yaml

Erstellen eines Secrets für die Registry

Damit auch der Image Updater auf unsere GitLab Registry zugreifen kann, benötigt er entsprechende Zugriffsrechte. Hier kommt wieder ein GitLab Deploy Token ins Spiel.

Dieses wird in den Settings unseres GitLab Repositories unter "Repository" mit dem Scope "Read Registry" erstellt. Um es später für den Image Updater im Cluster zur Verfügung zu stellen, sind die folgenden Schritte notwendig:

1) Base64-Encoding der Credentials:

echo -n "<Name des Deploy Tokens>:<Name des Deploy Tokens>" | base64

2) Erstellen und Encoding der .dockerconfigjson Datei

Der im Terminal ausgegebene Wert aus Schritt 1 kann ebenso wie die weiteren notwendigen Werte in die Datei geschrieben werden:

{
  "auths": {
    "<Registry Link>": {
      "username": "<Name des Deploy Tokens>",
      "password": "<Name des Deploy Tokens>",
      "email": "REGISTRY_EMAIL",
      "auth": "Base64-Credentials"
    }
  }
}

Anschließend encoden wir die gesamte dockerconfigjson via

cat .dockerconfigjson | base64

3) Secret anlegen

Nun haben wir alles vorbereitet und können unser Kubernetes Secret anlegen:

apiVersion: v1
kind: Secret
type: kubernetes.io/dockerconfigjson
metadata:
  name: registry-credentials
  namespace: argocd
data:
  .dockerconfigjson: <der Output vom cat command aus Schritt 2>

Installieren des ArgoCD Image Updaters

Nachdem wir nun alle Vorbereitungen abgeschlossen haben, kann es losgehen: Wir installieren den ArgoCD Image Updater via

kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj-labs/argocd-image-updater/master/manifests/install.yaml

In unserem Cluster werden nun verschiedene Ressourcen angelegt, bspw. RBAC Ressourcen und ConfigMaps. Letztere sind für uns im folgenden Schritt besonders interessant.

Konfiguration des Image Updaters

Damit der Image Updater mit unserer Registry arbeiten kann, muss er das oben angelegte Secret kennen. Hierfür gibt es zwei verschiedene Ansätze:

1. Direkte Referenz in den Applications via Annotation:

argocd-image-updater.argoproj.io/backend.pull-secret: pullsecret:argocd/registry-credentials

1. Globale Referenz in der ConfigMap des Image Updaters

Der erste Ansatz eignet sich besonders dann, wenn mehrere Anwendungen mit unterschiedlichen Container Registries arbeiten – oder wenn bestimmte Anwendungen spezielle Zugangsdaten benötigen. Durch die direkte Referenz in der jeweiligen Application bleiben die Zugriffsrechte gezielt und granular konfigurierbar.

Variante 2 bietet sich vor allem dann an, wenn alle (oder zumindest die meisten) Anwendungen dieselbe Registry nutzen und mit denselben Zugangsdaten arbeiten können. Das vereinfacht die Konfiguration erheblich und ist daher in kleineren Setups oder homogenen Umgebungen vorteilhaft.

Für diesen Artikel nutzen wir den zweiten Ansatz - und aktualisieren die ConfigMap des Image Updaters. Dazu benötigen wir die folgende configmap.yaml Datei:

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-image-updater-config
  namespace: argocd
data:
  registries.conf: |
    registries:
      - name: GitLab Registry
        api_url: <Registry URL>
        prefix: <Registry URL ohne https>
        credentials: pullsecret:argocd/registry-credentials
        default: true
        insecure: false

Diese können wir mit kubectl deployen via:

kubectl apply -f configmap.yaml

und anschließend den Image Updater neu starten mit:

kubectl rollout restart deployment argocd-image-updater -n argocd

Damit aktualisieren wir die bereits vorhandene ConfigMap des Image Updaters - und sollten nun in den Logs keine Fehlermeldung mehr erhalten.

Um unser Setup zu testen, können wir nun unsere Pipeline laufen lassen, damit ein neues Image gebaut und in die Registry gepusht wird. Wichtig dabei: Solltet ihr bislang einen generischen Tag wie latest genutzt haben, so empfehlen wir, für diesen Test Run einen eindeutigen Tag zu verwenden, bspw. den den Short SHA des Commits ($CI_COMMIT_SHORT_SHA). So vermeiden wir mögliche Caching-Probleme oder unklare Nachvollziehbarkeit.

Nachdem unsere Pipeline durchgelaufen ist, können wir wieder einen Blick in unser Cluster werfen und sehen nach kurzer Wartezeit ein Deployment mit unserem neuen Image. Ganz ohne Deploy-Step in unserer Pipeline.

Optimierungsmöglichkeiten

Um den Einstieg so einfach wie möglich zu halten, haben wir uns auf ein zugegebenermaßen recht simples Setup konzentriert. Der Image Updater bietet uns jedoch verschiedenste Konfigurations-Möglichkeiten: Über Annotations bspw. können Tags gefiltert oder ausgeschlossen werden. Ebenso ist es möglich, via write-back-method: git Änderungen als Git-Commits ins Repository zurückzuschreiben oder Kustomize-Dateien zu aktualisieren (statt Helm values).

So können wir das Verhalten des Controllers an die eigene Struktur in unserem Repository anzupassen. Mehr Details zu Konfigurations-Möglichkeiten findet ihr in den ArgoCD Image Updater Docs.

Fazit

Der ArgoCD Image Updater ist ein starkes Werkzeug, um Continuous Deployment in GitOps-Setups zu realisieren – auch ohne schreibenden Zugriff auf Git. In Kombination mit CI/CD-Pipelines entsteht so ein sauberer, automatisierter Deployment-Flow, der für Entwicklungsteams spürbar weniger Aufwand bedeutet.