3 Grundlagen von GitOps

3.1 Die vier Säulen von GitOps

GitOps revolutioniert die Art, wie wir Infrastruktur und Anwendungen verwalten. Das Konzept basiert auf vier fundamentalen Prinzipien, die zusammen ein robustes und nachvollziehbares System schaffen:

Prinzip Beschreibung Nutzen
1. Deklarativ Vollständige Beschreibung des gewünschten Systemzustands durch Konfigurationsdateien Keine imperativen Schritte nötig, klare Zieldefinition
2. Versioniert & Unveränderlich Alle Systemzustände in Git gespeichert, einmal committet = dauerhaft nachverfolgbar Vollständige Historie, keine nachträglichen Änderungen
3. Automatisch angewendet Genehmigte Änderungen werden automatisch auf das Zielsystem übertragen Eliminiert manuelle Fehlerquellen
4. Kontinuierlich überwacht Software-Agenten vergleichen Ist- mit Soll-Zustand und korrigieren Abweichungen Selbstheilende Systeme, Drift-Erkennung

3.1.1 Konkrete Vorteile im Überblick

Die Anwendung dieser Prinzipien bringt handfeste Verbesserungen:

3.2 Single Source of Truth: Git als zentrale Wahrheitsquelle

Stellen Sie sich vor, drei Entwickler arbeiten parallel an verschiedenen Umgebungen. Ohne zentrale Koordination entstehen schnell inkonsistente Zustände:

Szenario ohne GitOps: - Entwickler A ändert etwas in Umgebung 1 - Entwickler B führt ein Update in Umgebung 2 durch - Umgebung 3 bleibt unverändert

Ergebnis: Nach wenigen Wochen existieren drei völlig unterschiedliche Umgebungen

Mit GitOps wird Git zur autoritären Quelle. Alle Änderungen müssen durch das Repository gehen und sind automatisch dokumentiert. Die praktische Umsetzung erfolgt durch strukturierte Repository-Ordner:

/environments
├── development/
├── staging/
└── production/

Jede Umgebung enthält spezifische Konfigurationsdateien nach einheitlicher Struktur.

3.3 Deklarativ vs. Imperativ: Der entscheidende Unterschied

Der Unterschied zwischen deklarativer und imperativer Konfiguration ist das Herzstück von GitOps:

Aspekt Imperativ Deklarativ
Beschreibt Wie etwas gemacht wird (Schritte) Was das Endergebnis sein soll (Zustand)
Wiederholbarkeit Funktioniert nur beim ersten Mal Beliebig oft ausführbar
Fehlerbehandlung Komplex, muss explizit programmiert werden Automatisch durch Systemvergleich
Verständlichkeit Erfordert Ablaufverständnis Zielsystem ist direkt erkennbar

3.3.1 Praktisches Beispiel

Imperativer Ansatz:

kubectl create namespace myapp
kubectl create deployment myapp --image=myapp:v1.0
kubectl scale deployment myapp --replicas=3
kubectl expose deployment myapp --port=80

Problem: Schlägt beim zweiten Durchlauf fehl, da Namespace bereits existiert

Deklarativer Ansatz:

apiVersion: v1
kind: Namespace
metadata:
  name: myapp
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
  namespace: myapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: myapp:v1.0
        ports:
        - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: myapp
  namespace: myapp
spec:
  selector:
    app: myapp
  ports:
  - port: 80
    targetPort: 8080
  type: ClusterIP

Diese YAML-Definitionen sind idempotent - sie können beliebig oft angewendet werden, ohne Seiteneffekte zu verursachen.

3.4 GitOps-Workflow und -Architektur

Die GitOps-Architektur folgt einem eleganten Pull-Prinzip, bei dem das Zielsystem aktiv Änderungen aus Git abholt:

3.4.1 Typischer Workflow im Detail

  1. Änderungsantrag: Entwickler erstellt Pull Request für Konfigurationsänderung
  2. Review-Prozess: Code Review und Genehmigung durch das Team
  3. Automatische Erkennung: GitOps-Agent (z.B. Argo CD, Flux) überwacht Repository
  4. Zustandsvergleich: Agent vergleicht gewünschten mit aktuellem Systemzustand
  5. Synchronisation: Notwendige Änderungen werden automatisch angewendet
  6. Überwachung: Kontinuierliche Überwachung mit automatischem Rollback bei Fehlern

3.5 GitOps vs. Traditionelle Deployment-Methoden

Die Unterschiede zwischen GitOps und traditionellen CI/CD-Ansätzen sind fundamental:

Merkmal Traditionelle CI/CD GitOps
Architektur Push-Modell Pull-Modell
Verbindungen Pipeline → Umgebungen Umgebungen → Git
Credentials Zentral in Pipeline Lokal in Umgebung
Konfigurationsdrift Manuell toleriert Automatisch erkannt & korrigiert
Rollbacks Separate Skripte nötig Einfache Git-Operationen
Auditierbarkeit Nachgelagerte Dokumentation Automatisch durch Git-Historie

3.5.1 Sicherheitsvorteile

Das Pull-Modell von GitOps bietet entscheidende Sicherheitsvorteile:

3.5.2 Vereinfachte Fehlerbehandlung

Während traditionelle Pipelines explizit für verschiedene Fehlerzustände programmiert werden müssen, reagiert GitOps elegant:

GitOps transformiert Deployment-Prozesse von fehleranfälligen, manuellen Abläufen zu selbstheilenden, nachvollziehbaren Systemen. Der Schlüssel liegt im Vertrauen auf Git als Single Source of Truth und die Kraft deklarativer Konfiguration.