Let’s Deploy with ayedo, Teil 2: ArgoCD GitOps, Monitoring, Observability

TL;DR

• GitOps mit ArgoCD verankert den gewünschten Zustand Ihrer Anwendungen und Infrastruktur in Git und macht Deployments damit reproduzierbar, auditierbar und automatisierbar.
• Im gemeinsamen Workflow von GitLab, Harbor, ArgoCD und Kubernetes übernehmen Pipelines das Bauen, Testen und Signieren, während ArgoCD die kontrollierte Auslieferung in verschiedene Umgebungen steuert.
• ArgoCD ApplicationSets erlauben skalierbares Multi-Environment-Deployment nach einheitlichen Standards – mit klaren Guardrails, wählbarem Automatisierungsgrad und sauberen Rollbacks.
• Monitoring & Observability mit VictoriaMetrics (Metriken), VictoriaLogs (Logs) und Grafana liefern die technische Grundlage, um Compliance-Anforderungen an Verfügbarkeit, Nachvollziehbarkeit und Incident-Handling belastbar zu erfüllen.
• ayedo integriert diesen gesamten GitOps- und Observability-Stack zu einer konsistenten Plattform, die Deployment-Automatisierung mit Compliance-Guardrails verbindet – inklusive einsatzfertiger ArgoCD-Templates und Dashboards.

---

GitOps mit ArgoCD: Steuerzentrale für den Plattform-Zustand

Was GitOps in der Praxis bedeutet

GitOps ist kein weiteres Modewort, sondern ein strukturierender Ansatz:
Der gewünschte Systemzustand – Deployments, Konfiguration, Policies – liegt versioniert in Git. Automatisierte Controller gleichen fortlaufend ab, ob der tatsächliche Zustand im Cluster diesem Zielbild entspricht, und korrigieren Abweichungen.

Für Sie als Verantwortliche:r bedeutet das:

• Jede Änderung beginnt mit einem Commit oder Merge Request.
• Reviews und Freigaben passieren auf Git-Ebene, nicht ad hoc im Cluster.
• Der tatsächliche Zustand Ihrer Kubernetes-Cluster ist jederzeit aus Git rekonstruierbar.

Auf der ayedo Plattform übernimmt ArgoCD die Rolle dieses Controllers. Es beobachtet Git-Repositories und sorgt dafür, dass definierte Anwendungen in den Ziel-Clustern dem im Repository beschriebenen Zustand entsprechen.

ArgoCD Applications vs. ApplicationSets

Im Kern arbeitet ArgoCD mit „Applications“ – einer Zuordnung aus:

• Quelldefinition (z. B. ein Helm-Chart oder ein Verzeichnis im Git-Repo),
• Ziel-Cluster und Namespace,
• und optional Environment-spezifischen Werten.

Für einen modernen Plattformbetrieb mit mehreren Umgebungen und Clustern reicht eine einzelne Application aber selten aus. Hier kommen ApplicationSets ins Spiel:

• ApplicationSets generieren viele einzelne Applications nach einem gemeinsamen Muster.
• Quellen können z. B.:
  • eine Liste von Umgebungen,
  • eine Cluster-Registry,
  • oder ein Verzeichnisbaum im Git-Repo sein.
• Sie definieren einmal das Deployment-Muster, und ArgoCD erstellt automatisch für jede Umgebung oder jeden Cluster eine eigene Application.

Das reduziert Wiederholung, verhindert Copy-Paste-Drift und sorgt dafür, dass Ihre Standards konsistent in allen Umgebungen eingehalten werden.

Automatischer Sync vs. manuelle Freigabe

ArgoCD unterstützt zwei wesentliche Betriebsmodi:

1. Automatisierter Sync (auto-sync)

   • Änderungen in Git werden nach definierten Regeln automatisch in den Ziel-Cluster ausgerollt.
   • Gut geeignet für:
     • nicht-kritische Umgebungen (z. B. Dev, Test),
     • standardisierte Infrastrukturkomponenten mit hohem Automatisierungsgrad.

2. Manuelle Freigabe (manual sync)

   • ArgoCD erkennt Abweichungen zwischen Git und Cluster, rollt diese aber erst aus, wenn jemand aktiv den Sync auslöst.
   • Besonders passend für:
     • produktive oder regulierte Umgebungen,
     • Changes mit erhöhtem Risiko oder Impact,
     • Anwendungsfälle, in denen ein 4-Augen-Prinzip umgesetzt werden soll.

Auf der ayedo Plattform kombinieren wir diese Modi oft:
Vor-Produktiv-Umgebungen werden automatisiert aktualisiert, während Production erst nach erfolgreichem Durchlauf der vorgelagerten Umgebungen und expliziter Freigabe synchronisiert wird. So bleiben Sie handlungsfähig, ohne in manuellem Kleinarbeit zu ersticken.

Gezielte Rollbacks ohne Chaos

Ein unterschätzter Vorteil von GitOps: Rollbacks werden wieder zu einem strukturierten Prozess.

Mit ArgoCD heißt ein Rollback meist:

• Zurücksetzen auf eine bekannte Chart-Version oder einen früheren Commit in Git.
• ArgoCD synchronisiert den Cluster dann auf diesen definierten Zustand.

Statt „hotfixen“ direkt im Cluster behalten Sie:

• Historie und Kontext der Änderung,
• Nachvollziehbarkeit für Audits,
• und eine klare Linie zwischen Anlass (Ticket/MR) und technischem Change.

---

Der Deployment-Workflow: Von GitLab über Harbor zu ArgoCD und Kubernetes

CI erzeugt Artefakte, GitOps liefert sie aus

Im ersten Teil des Workflows entsteht das Artefakt:
In GitLab laufen Tests, Security-Scans und Image-Builds. Am Ende stehen mindestens zwei Ergebnisse:

• ein signiertes Container-Image in Harbor,
• ein versioniertes Helm-Chart – ebenfalls in Harbor oder im Git-Repo.

Gleichzeitig werden die Deploymentspezifikationen (z. B. Helm-Values pro Umgebung) im Git-Repository aktualisiert. Diese Kombination ist entscheidend:

• Image & Chart: Was technisch ausgerollt wird.
• Git-Config: Wo, mit welchen Parametern und in welcher Umgebung es ausgerollt wird.

ArgoCD als „Pull“-Mechanismus

Sobald neue Versionen bereitstehen, muss nichts aktiv „gepusht“ werden. Stattdessen:

1. ArgoCD erkennt die Änderung im Git-Repo (oder in der Chart-Version).
2. Je nach Konfiguration:
   • synchronisiert es automatisch, oder
   • markiert es die Application als „out of sync“ und wartet auf Freigabe.
3. Der Cluster wird in den neuen Zielzustand überführt.

Diese „Pull“-Architektur ist besonders interessant für Compliance:

• Es gibt keinen verdeckten direkten Zugriff der Pipeline auf produktive Cluster.
• Zugänge und Berechtigungen sind in ArgoCD konzentriert und können dort sauber kontrolliert und auditiert werden.
• Reviews bleiben im gewohnten GitLab-Workflow verankert.

---

Guardrails im GitOps-Flow

Policies als integraler Teil des Deployments

Guardrails sind keine nachträgliche Härte, sondern Teil des Designprinzips:
Auf der ayedo Plattform werden Deployments entlang der gesamten Kette geprüft:

• In GitLab-Pipelines (vor dem Push des Charts):
  • Linting und Policy-Checks zu Ressourcenlimits, Security-Konfiguration, Netzwerkregeln.
• Im Git-Repository:
  • Standards für Ordnerstruktur, Naming, Environments.
• In der GitOps-Schicht:
  • ArgoCD-Projects definieren, welche Cluster und Namespaces von welchen Teams beschrieben werden dürfen.
  • Optionale Integrationen mit Policy-Engines, die manifestbasierte Regeln durchsetzen.

Praktisch bedeutet das:
Eine nicht-konforme Ressourcenanforderung (z. B. fehlende Limits) wird im Idealfall schon in der Pipeline blockiert, bevor ArgoCD sie überhaupt sehen kann. Sollte doch eine Policy-Verletzung bis zur GitOps-Schicht durchrutschen, kann der Sync dort automatisch verhindert und gemeldet werden.

---

Multi-Environment-Deployments mit ArgoCD ApplicationSets

Typischer Aufbau: Dev, Staging, Production

Viele Organisationen fahren heute mit mindestens drei Umgebungen:

• Dev: hohe Änderungsfrequenz, kurze Feedbackzyklen,
• Staging/Pre-Prod: produktionsnahe Tests, Releases „unter Realbedingungen“,
• Production: hochverfügbar, regulatorisch relevant, stark kontrolliert.

Ohne ApplicationSets endet das oft in drei nahezu identischen, aber voneinander abdriftenden ArgoCD-Applications. Das skaliert schlecht.

ApplicationSets als Musterbibliothek

Mit ApplicationSets definieren Sie ein Deployment-Muster einmal:

• Quelle: Ihr Chart in Harbor oder ein Pfad im Git-Repo.
• Parameter: z. B. Environment-Name, Ziel-Cluster, Namespaces, Werte-Dateien.
• Policy: Auto-Sync für Dev, manuelle Freigabe für Prod, abgestufte Ressourcenlimits.

ArgoCD generiert daraus automatisch:

• eine Application pro Umgebung,
• optional pro Region oder Mandanten.

Der Vorteil liegt weniger in der Technik als im Effekt auf Ihre Organisation:

• Änderungen an der Deployment-Logik erfolgen einheitlich und zentral.
• Neue Umgebungen lassen sich strukturiert hinzufügen, ohne Copy-Paste.
• Standards – z. B. „jede produktive Application muss Ressourcenlimits und Health-Checks haben“ – werden tatsächlich durchgesetzt.

Governance-Modell: Wo wird genehmigt?

In einem gut aufgesetzten GitOps-Modell greifen mehrere Ebenen ineinander:

• GitLab Merge Requests:
  Fachlich-technisches Review des Codes und der Deploymentspezifikation.
• ArgoCD Projects und Sync-Policies:
  Technische Guardrails, welche Teams wohin deployen dürfen.
• ApplicationSets:
  Sicherstellen, dass alle Umgebungen nach denselben Regeln bespielt werden.

So lässt sich z. B. umsetzen, dass:

• Feature-Branches automatisch in temporäre Dev-Umgebungen deployt werden,
• Staging nach Merge und automatisierten Tests folgt,
• Production erst nach manueller Freigabe im ArgoCD-UI oder via kontrolliertem Pipeline-Schritt synchronisiert wird.

---

Monitoring & Observability: Metriken, Logs, Dashboards, Alerts

Deployment-Automatisierung ist nur so gut wie die Fähigkeit, ihre Auswirkungen zu beobachten. Gerade regulatorische Anforderungen an Verfügbarkeit, Incident-Reaktion und Nachvollziehbarkeit (etwa unter NIS2, das am 18.10.2024 vollständig in nationales Recht umgesetzt sein muss) verlangen hier eine belastbare Basis.

VictoriaMetrics: Metrik-Backbone

VictoriaMetrics übernimmt auf der ayedo Plattform die Rolle des hochskalierbaren Metrik-Speichers:

• Infrastrukturmetriken:
  Cluster- und Node-Status, Ressourcenverbrauch von Pods, Nodes, Storage.
• Anwendungsmetriken:
  Latenzen, Fehlerraten, Request-Raten, Business-KPIs, wenn die Anwendung sie bereitstellt.
• Plattformmetriken:
  Zustand von ArgoCD, Ingress-Controllern, Service-Meshes, Datenbanken.

Diese Metriken bilden die Grundlage für:

• Service-Level-Indikatoren (SLIs) und Service-Level-Objectives (SLOs),
• Kapazitätsplanung und Kostenkontrolle,
• Früherkennung von Performance-Problemen.

VictoriaLogs: Strukturierte Logs statt Blackbox

Logs sind für Audits und Incident-Analysen mindestens so relevant wie Metriken. VictoriaLogs sammelt und indexiert:

• Anwendungslogs (z. B. aus Containern in Kubernetes),
• Infrastruktur-Logs (z. B. aus Ingress, Controllern, Systemdiensten),
• Sicherheitsrelevante Events (z. B. Policy-Verletzungen, fehlgeschlagene Syncs in ArgoCD).

Im Zusammenspiel mit Metriken wird dadurch möglich:

• Korrelieren von Peaks in Fehlerraten (Metrik) mit konkreten Exceptions (Log),
• Nachvollziehen, welche Version einer Anwendung zum Zeitpunkt eines Incidents aktiv war,
• Bereitstellen eines revisionssicheren Audit-Trails der Systemaktivitäten.

Grafana: Gemeinsame Sicht auf den Systemzustand

Grafana bildet die sichtbare Schicht über Metriken und Logs:

• Standard-Dashboards für:
  • Cluster-Zustand,
  • ArgoCD-Health und Sync-Status,
  • zentrale Infrastrukturkomponenten.
• Team-spezifische Dashboards für:
  • einzelne Anwendungen,
  • Business-Prozesse,
  • Compliance-relevante Kennzahlen (z. B. Verfügbarkeits-SLOs).

Wichtig ist hier nicht nur die Technik, sondern das Zusammenspiel in Ihrem Team:

• Operations- und Entwicklungsteams arbeiten auf einer gemeinsamen Datenbasis.
• Verantwortliche sehen nicht nur „es ist kaputt“, sondern können schnell einordnen:
  • Ist ein neues Release die Ursache?
  • Liegt ein Infrastrukturproblem vor?
  • Wurden die Compliance-Guardrails verletzt oder haben sie korrekt eingegriffen?

Alerting: Von der Metrik zur Handlung

Auf Basis von VictoriaMetrics und VictoriaLogs können Sie Alarme definieren, die zu Ihrer Organisation passen:

• Technische Alarme:
  Fehlerquoten, Auslastung, Pod-Restarts, Sync-Fehler in ArgoCD.
• Geschäftsrelevante Alarme:
  Ausfall bestimmter Services, Überschreitung von Antwortzeiten, SLA-Verletzungen.
• Compliance-orientierte Alarme:
  Unerwartete Konfigurationsänderungen, wiederholte Policy-Verletzungen, ungewöhnliche Zugriffsmuster.

Die Integration in vorhandene Kanäle (z. B. Slack, E-Mail, Ticketsystem, On-Call-Lösungen) ist dabei ebenso wichtig wie die Schwellenwerte selbst. Eine gut kalibrierte Alerting-Strategie ist essenziell, um Überwachung nicht in Alarm-Müdigkeit enden zu lassen.

---

Häufige Fragen

Wie unterscheidet sich GitOps mit ArgoCD von „klassischem“ CI/CD?

Im klassischen Modell „schiebt“ die CI/CD-Pipeline direkt in den Ziel-Cluster. Die Pipeline besitzt damit Cluster-Zugriffsrechte und ist gleichzeitig Build-, Test- und Delivery-Instanz.

Im GitOps-Modell:

• Git bleibt die einzige Source of Truth.
• CI erstellt und veröffentlicht Artefakte und aktualisiert Konfigurationen in Git.
• ArgoCD „zieht“ diese Konfiguration und liefert sie aus.

Das führt zu:

• klarer Trennung von Build/Test und Delivery,
• geringerer Angriffsfläche (keine direkten Cluster-Zugriffe aus der Pipeline),
• besserer Auditierbarkeit von Änderungen.

Wie viel Automatisierung ist in regulierten Umgebungen sinnvoll?

Die meisten regulierten Organisationen fahren gut mit einem abgestuften Modell:

• Hohe Automatisierung für Dev und Test:
  • Entwickler:innen erhalten schnelles Feedback.
  • Neue Features durchlaufen automatisch alle Checks.
• Teil-automatisierte Staging-Umgebungen:
  • Automatisierte Deployments nach erfolgreicher Pipeline.
  • Manuelle Gateways für bestimmte, riskantere Änderungen möglich.
• Stark kontrollierte Produktion:
  • Sync nur nach expliziter Freigabe.
  • 4-Augen- oder Mehr-Augen-Prinzip auf GitLab-Ebene.
  • Strikte Guardrails bezüglich Ressourcen, Security und Konnektivität.

ArgoCD und ApplicationSets unterstützen diese Staffelung technisch – die eigentliche Kunst liegt darin, ein Governance-Modell zu definieren, das zu Ihrer Organisation und den jeweiligen Gesetzen bzw. Standards (z. B. NIS2, DORA) passt.

Wie unterstützt ayedo konkret bei GitOps und Observability?

ayedo stellt die Bausteine nicht nur bereit, sondern integriert sie zu einer konsistenten Plattform:

• Vorintegrierte Tools:
  • GitLab, Harbor, ArgoCD, Grafana sowie Metrik- und Log-Backends.
• Vorkonfigurierte Guardrails:
  • Policies, Helm-Standards, ArgoCD-Projects, RBAC-Modelle.
• Einsatzfertige Templates:
  • ApplicationSets für Multi-Environment-Deployments,
  • Dashboards für Cluster- und Application-Monitoring,
  • Baseline-Alerts, die sich an gängigen Best Practices und regulatorischen Anforderungen orientieren.

So können Teams GitOps und Observability mit deutlich reduzierter Einführungszeit nutzen und sich auf fachliche Themen konzentrieren.

Weitere Fragen? Siehe unsere FAQ

---

Von der Theorie zur Umsetzung

GitOps mit ArgoCD und ein konsistenter Observability-Stack sind keine Selbstzwecke. Sie bilden die Grundlage dafür, dass moderne, verteilte Anwendungen zuverlässig, nachvollziehbar und regelkonform betrieben werden können – gerade in einem europäischen Kontext, in dem Verfügbarkeit, Datenschutz und Resilienz zunehmend reguliert werden.

Mit der ayedo Plattform stellen wir diese Bausteine kuratiert und integriert bereit:

• Der Workflow von GitLab über Harbor zu ArgoCD und Ihren Kubernetes-Clustern ist technisch durchgängig und organisatorisch anschlussfähig gestaltet.
• ApplicationSets, Guardrails und abgestufte Sync-Strategien unterstützen Ihre Governance-Modelle, statt sie zu behindern.
• Monitoring und Observability mit VictoriaMetrics, VictoriaLogs und Grafana sind so integriert, dass Deployments und Betriebszustand zusammen gedacht werden können – inklusive Dashboards und Alerts, die sich an regulatorische Vorgaben anlehnen lassen.

Wenn Sie diesen Ansatz in Ihrer eigenen Organisation nutzen möchten, ohne alle Details von Grund auf selbst zu gestalten, unterstützen wir Sie mit praxiserprobten Referenzarchitekturen und einsatzfertigen Vorlagen – unter anderem einem strukturierten ArgoCD-Setup für Multi-Environment-Deployments.

Den Einstieg erleichtern wir mit einem konkreten, anpassbaren ArgoCD-Beispiel für Ihre Umgebung: ArgoCD Template