12 GitOps im Projekt einführen - Schritt für Schritt

Die Einführung von GitOps in produktive Umgebungen erfordert einen durchdachten, risikoarmen Ansatz. Dieser Leitfaden beschreibt eine bewährte Strategie zur störungsfreien Migration bestehender Deployments zu GitOps-Praktiken.

12.1 Grundprinzipien der störungsfreien Einführung

12.1.1 Beobachten vor Handeln

12.1.2 Inkrementelle Adoption

12.1.3 Vertrauen durch Transparenz

12.2 Erste Phase: Bestandsaufnahme und Vorbereitung

12.2.1 Current State Assessment

Inventarisierung bestehender Deployments:

# Alle Deployments erfassen
kubectl get deployments --all-namespaces -o wide

# Aktuelle Konfigurationsquellen identifizieren
kubectl get deployments -o jsonpath='{.items[*].metadata.annotations}' | grep -E "(helm|kustomize|ci|pipeline)"

# Manuelle Änderungen aufspüren
kubectl get events --sort-by=.metadata.creationTimestamp | grep -E "(kubectl|manual)"

Repository-Audit:

12.2.2 ArgoCD Installation im Observer-Modus

# ArgoCD mit restriktiven Einstellungen
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: legacy-app-observer
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/your-org/k8s-manifests
    targetRevision: main
    path: apps/legacy-app
  destination:
    server: https://kubernetes.default.svc
    namespace: legacy-app
  syncPolicy:
    # WICHTIG: Kein automatisches Sync!
    syncOptions:
    - CreateNamespace=false
    - ApplyOutOfSyncOnly=false
    - Validate=true
    - DryRun=true  # Nur Validierung, keine Änderungen

12.2.3 Drift-Baseline etablieren

# ArgoCD CLI für Drift-Analyse
argocd app get legacy-app-observer --show-params
argocd app diff legacy-app-observer

# Regelmäßige Drift-Reports
cat > drift-monitor.sh << 'EOF'
#!/bin/bash
echo "$(date): Drift Report" >> drift-log.txt
argocd app list --output wide | grep OutOfSync >> drift-log.txt
echo "---" >> drift-log.txt
EOF

# Cron Job für tägliche Drift-Überwachung
0 8 * * * /opt/scripts/drift-monitor.sh

12.3 Zweite Phase: Pilotprojekt etablieren

12.3.1 Pilotanwendung auswählen

Auswahlkriterien:

Anti-Pattern vermeiden:

12.3.2 Git-Repository strukturieren

# Repository-Struktur für Pilotprojekt
mkdir -p pilot-gitops/{apps,environments,argocd}

# Pilot App Struktur
pilot-gitops/
├── apps/
   └── pilot-app/
       ├── base/
       │   ├── deployment.yaml
       │   ├── service.yaml
       │   └── kustomization.yaml
       └── overlays/
           ├── staging/
           └── production/
├── environments/
   ├── staging/
   │   └── pilot-app.yaml
   └── production/
       └── pilot-app.yaml
└── argocd/
    └── applications/
        ├── pilot-staging.yaml
        └── pilot-production.yaml

12.3.3 Parallel-Deployment für Validation

# Staging-Environment als ArgoCD-Test
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: pilot-app-staging
  namespace: argocd
spec:
  project: pilot-project
  source:
    repoURL: https://github.com/your-org/pilot-gitops
    targetRevision: main
    path: environments/staging
  destination:
    server: https://kubernetes.default.svc
    namespace: pilot-staging
  syncPolicy:
    automated:
      prune: false    # Zunächst konservativ
      selfHeal: false # Manueller Sync erforderlich
    syncOptions:
    - CreateNamespace=true
    - ApplyOutOfSyncOnly=true

12.4 Dritte Phase: Kontrollierte Synchronisation

12.4.1 Manual Sync Workflow

Vorbereitung:

# Pre-Sync Validation
argocd app diff pilot-app-staging
argocd app sync pilot-app-staging --dry-run

# Sync mit Überwachung
argocd app sync pilot-app-staging --prune=false

Post-Sync Verification:

# Application Health Check
argocd app get pilot-app-staging
kubectl get pods -n pilot-staging
kubectl get events -n pilot-staging --sort-by=.metadata.creationTimestamp

12.4.2 Drift Response Procedures

Standard Operating Procedures (SOP):

12.4.2.1 Drift Detection Response

# 1. Drift-Ursache analysieren
kubectl describe deployment pilot-app -n pilot-staging
kubectl get events -n pilot-staging | grep pilot-app

# 2. Entscheidungsmatrix anwenden
if [ "$DRIFT_TYPE" == "emergency" ]; then
    echo "Emergency drift - temporary accept"
    # Dokumentation für spätere Git-Update
elif [ "$DRIFT_TYPE" == "operational" ]; then
    echo "Operational drift - evaluate for formalization"
else
    echo "Unauthorized drift - initiate correction"
    argocd app sync pilot-app-staging
fi

12.4.2.2 Formalization Workflow

# Bei wertvollen manuellen Änderungen
git checkout -b formalize-drift-$(date +%Y%m%d)
# Manuelle Änderung ins Git übertragen
kubectl get deployment pilot-app -n pilot-staging -o yaml > apps/pilot-app/base/deployment.yaml
git add apps/pilot-app/base/deployment.yaml
git commit -m "Formalize production adjustment: increase memory limits"
git push origin formalize-drift-$(date +%Y%m%d)
# Pull Request für Review

12.4.3 Readiness Gates definieren

Kriterien für Automatic Sync:

# Upgrade zu Automatic Sync
syncPolicy:
  automated:
    prune: true
    selfHeal: true
  syncOptions:
  - CreateNamespace=true
  - PrunePropagationPolicy=foreground

12.5 Vierte Phase: Skalierung und Governance

12.5.1 Multi-Application Management

# ApplicationSet für skalierte Einführung
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: production-apps
  namespace: argocd
spec:
  generators:
  - git:
      repoURL: https://github.com/your-org/production-gitops
      revision: HEAD
      directories:
      - path: apps/*
  template:
    metadata:
      name: '{{path.basename}}'
    spec:
      project: production
      source:
        repoURL: https://github.com/your-org/production-gitops
        targetRevision: HEAD
        path: '{{path}}'
      destination:
        server: https://kubernetes.default.svc
        namespace: '{{path.basename}}'
      syncPolicy:
        automated:
          prune: true
          selfHeal: true

12.5.2 AppProject für Governance

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: production
  namespace: argocd
spec:
  description: Production Applications
  sourceRepos:
  - 'https://github.com/your-org/production-gitops'
  destinations:
  - namespace: 'app-*'
    server: https://kubernetes.default.svc
  clusterResourceWhitelist:
  - group: ''
    kind: Namespace
  namespaceResourceWhitelist:
  - group: 'apps'
    kind: Deployment
  - group: ''
    kind: Service
  - group: 'networking.k8s.io'
    kind: Ingress
  roles:
  - name: developers
    policies:
    - p, proj:production:developers, applications, get, production/*, allow
    - p, proj:production:developers, applications, sync, production/*, allow
    groups:
    - your-org:developers
  - name: operators
    policies:
    - p, proj:production:operators, applications, *, production/*, allow
    groups:
    - your-org:platform-team

12.6 Fünfte Phase: Advanced Patterns

12.6.1 Progressive Rollout Strategy

# Canary-Deployment Integration
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: progressive-app
spec:
  replicas: 10
  strategy:
    canary:
      steps:
      - setWeight: 10
      - pause: {duration: 30s}
      - setWeight: 50
      - pause: {duration: 2m}
      analysis:
        templates:
        - templateName: success-rate
        args:
        - name: service-name
          value: progressive-app
  selector:
    matchLabels:
      app: progressive-app
  template:
    metadata:
      labels:
        app: progressive-app
    spec:
      containers:
      - name: app
        image: nginx:1.20

12.6.2 Multi-Cluster Management

# Cluster-spezifische Applications
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: multi-cluster-apps
spec:
  generators:
  - clusters: {}
  template:
    metadata:
      name: '{{name}}-guestbook'
    spec:
      project: multi-cluster
      source:
        repoURL: https://github.com/your-org/apps
        targetRevision: HEAD
        path: apps/guestbook
      destination:
        server: '{{server}}'
        namespace: guestbook

12.7 Risk Management und Rollback-Strategien

12.7.1 Automated Rollback Triggers

# ArgoCD mit Health-Check Integration
spec:
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    retry:
      limit: 3
      backoff:
        duration: 5s
        factor: 2
        maxDuration: 3m

12.7.2 Manual Intervention Procedures

# Emergency Procedures
cat > emergency-rollback.sh << 'EOF'
#!/bin/bash
APP_NAME=$1
PREVIOUS_REVISION=$2

echo "EMERGENCY ROLLBACK for $APP_NAME to revision $PREVIOUS_REVISION"
argocd app history $APP_NAME
argocd app rollback $APP_NAME $PREVIOUS_REVISION
kubectl rollout status deployment/$APP_NAME -n $(argocd app get $APP_NAME -o json | jq -r '.spec.destination.namespace')
EOF

chmod +x emergency-rollback.sh

12.8 Change Management Integration

12.8.1 Team Training Requirements

Curriculum für Development Teams:

  1. GitOps-Prinzipien und Workflow
  2. ArgoCD Web-UI Navigation
  3. Git-basierte Änderungsprozesse
  4. Troubleshooting und Drift Response
  5. Emergency Procedures

Curriculum für Operations Teams:

  1. ArgoCD Administration
  2. Application und Project Management
  3. Multi-Cluster Configuration
  4. Monitoring und Alerting Setup
  5. Disaster Recovery Procedures

12.8.2 Communication Strategy

Stakeholder Mapping:

12.9 Monitoring und Success Metrics

12.9.1 Key Performance Indicators

# GitOps Adoption Metrics
gitops_applications_total
gitops_sync_success_rate
gitops_drift_detection_frequency
gitops_manual_interventions_total
gitops_deployment_frequency
gitops_lead_time_for_changes
gitops_mean_time_to_recovery

12.9.2 Dashboard-Integration

# Grafana Dashboard Query Examples
- expr: |
    sum(argocd_app_info{sync_status="Synced"}) / sum(argocd_app_info) * 100
  legendFormat: "Sync Success Rate %"

- expr: |
    increase(argocd_app_sync_total{phase="Succeeded"}[24h])
  legendFormat: "Successful Deployments per Day"

- expr: |
    sum by (name) (argocd_app_info{sync_status="OutOfSync"})
  legendFormat: "Applications with Drift"

12.10 Erfolgsfaktoren

Kritische Erfolgsfaktoren:

  1. Gradueller Ansatz: Keine Big-Bang-Migration
  2. Team-Mitnahme: Frühe Einbindung und Training
  3. Monitoring-First: Beobachtung vor Automatisierung
  4. Risk Mitigation: Rollback-Strategien und Emergency Procedures
  5. Continuous Learning: Regelmäßige Retrospektiven und Prozessverbesserung

Häufige Fallstricke vermeiden:

Die erfolgreiche GitOps-Einführung ist kein technisches, sondern ein organisatorisches Transformation-Projekt. Der Schlüssel liegt in der systematischen, risikoarmen Herangehensweise mit kontinuierlicher Team-Einbindung und transparenter Kommunikation über Fortschritte und Herausforderungen.