Bereitstellungsstrategien ohne Ausfallzeiten: Halten Sie Ihre Anwendung während Aktualisierungen am Laufen

Geplante Ausfallzeiten kosten Unternehmen durchschnittlich 5.600 US-Dollar pro Minute. Dennoch schalten 43 % der Unternehmen ihre Anwendungen während der Bereitstellung immer noch offline. Eine Bereitstellung ohne Ausfallzeiten ist kein Luxus, sondern eine Erwartung. Kunden, Suchmaschinen und Integrationspartner bestrafen alle Anwendungen, die offline gehen, auch nur kurzzeitig.

In diesem Leitfaden werden die drei wichtigsten Bereitstellungsstrategien ohne Ausfallzeiten, Datenbankmigrationstechniken zur Aufrechterhaltung der Betriebszeit und automatisierte Rollback-Mechanismen behandelt.

Wichtige Erkenntnisse

• Blau-Grün-Bereitstellung ist die sicherste Strategie: sofortiges Rollback durch Zurückschalten des Datenverkehrs auf die vorherige Version
• Datenbankmigrationen müssen abwärtskompatibel sein – die alte Anwendungsversion muss mit dem neuen Schema funktionieren – Gesundheitsprüfungen und Bereitschaftsprüfungen verhindern, dass Datenverkehr an Pods weitergeleitet wird, die nicht betriebsbereit sind
• Automatisiertes Rollback basierend auf der Überwachung der Fehlerrate reduziert die durchschnittliche Wiederherstellungszeit auf unter 2 Minuten

---

Strategievergleich

---

Blau-Grün-Bereitstellung

Architektur

Load Balancer
    |
    |--- [ACTIVE] Blue environment (v2.0.0) <-- receives 100% traffic
    |
    |--- [IDLE] Green environment (v2.1.0) <-- deployed, tested, waiting

Bei der Bereitstellung:

1. Stellen Sie v2.1.0 in der Leerlaufumgebung (grün) bereit
2. Führen Sie Rauchtests gegen Grün durch
3. Load Balancer auf Grün schalten
4. Blau wird inaktiv (verfügbar für sofortiges Rollback)

Implementierung mit Nginx

# /etc/nginx/conf.d/app.conf
upstream blue {
    server 10.0.1.10:3000;
    server 10.0.1.11:3000;
}

upstream green {
    server 10.0.2.10:3000;
    server 10.0.2.11:3000;
}

# Active environment - change this during deployment
map $host $active_upstream {
    default blue;  # Change to 'green' to switch
}

server {
    listen 443 ssl;
    server_name app.example.com;

    location / {
        proxy_pass http://$active_upstream;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

Bereitstellungsskript

#!/bin/bash
set -e

CURRENT=$(cat /etc/nginx/active-env)  # "blue" or "green"
TARGET=$( [ "$CURRENT" = "blue" ] && echo "green" || echo "blue" )

echo "Current: $CURRENT, deploying to: $TARGET"

# Deploy to inactive environment
ssh "deploy@$TARGET-1" "cd /opt/app && git pull && pnpm install --frozen-lockfile && pnpm build && pm2 restart all"
ssh "deploy@$TARGET-2" "cd /opt/app && git pull && pnpm install --frozen-lockfile && pnpm build && pm2 restart all"

# Wait for health checks
for i in 1 2; do
  echo "Checking $TARGET-$i health..."
  for attempt in $(seq 1 30); do
    if curl -sf "http://$TARGET-$i:3000/health" > /dev/null; then
      echo "$TARGET-$i is healthy"
      break
    fi
    sleep 2
  done
done

# Run smoke tests
pnpm test:smoke --base-url "http://$TARGET-1:3000"

# Switch traffic
sed -i "s/default $CURRENT/default $TARGET/" /etc/nginx/conf.d/app.conf
nginx -s reload
echo "$TARGET" > /etc/nginx/active-env

echo "Traffic switched to $TARGET. Rollback: change active-env back to $CURRENT"

---

Fortlaufendes Update

Rolling Updates ersetzen Instanzen inkrementell und stellen so sicher, dass immer etwas Kapazität verfügbar ist.

Kubernetes Rolling Update

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  replicas: 5
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1        # Create 1 extra pod during update
      maxUnavailable: 0   # Never reduce below desired replicas
  template:
    spec:
      containers:
        - name: api
          image: registry.example.com/api:v2.1.0
          readinessProbe:
            httpGet:
              path: /health
              port: 3001
            initialDelaySeconds: 5
            periodSeconds: 5
          livenessProbe:
            httpGet:
              path: /health
              port: 3001
            initialDelaySeconds: 15
            periodSeconds: 10

Der Rolling-Update-Prozess mit maxSurge: 1 und maxUnavailable: 0:

1. Erstellen Sie 1 neuen Pod mit v2.1.0 (insgesamt 6 Pods: 5 alte + 1 neue).
2. Warten Sie, bis die neue Pod-Bereitschaftsprüfung erfolgreich ist
3. 1 alten Pod beenden (5 Pods: 4 alte + 1 neuer)
4. Erstellen Sie einen weiteren neuen Pod (6 Pods: 4 alte + 2 neue).
5. Wiederholen Sie diesen Vorgang, bis alle Pods die Version 2.1.0 haben

---

Canary-Bereitstellung

Verkehrsaufteilung

# Istio VirtualService for canary routing
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: api-canary
spec:
  hosts:
    - api.example.com
  http:
    - route:
        - destination:
            host: api-stable
            port:
              number: 3001
          weight: 95
        - destination:
            host: api-canary
            port:
              number: 3001
          weight: 5

Progressiver Canary-Rollout

---

Datenbankmigrationen ohne Ausfallzeiten

Die größte Herausforderung bei der Bereitstellung ohne Ausfallzeiten sind Datenbankschemaänderungen. Die alte Anwendungsversion muss mit dem neuen Schema funktionieren und umgekehrt.

Das Expand-Contract-Muster

Phase 1: Erweitern (Schemaänderung bereitstellen)

-- Add new column (nullable, no default)
ALTER TABLE orders ADD COLUMN shipping_method VARCHAR(50);

Der alte Anwendungscode ignoriert die neue Spalte. Neuer Anwendungscode schreibt sowohl in alte als auch in neue Spalten.

Phase 2: Daten migrieren

-- Backfill existing data
UPDATE orders SET shipping_method = 'standard' WHERE shipping_method IS NULL;

Phase 3: Vertrag (Code bereitstellen, der ausschließlich die neue Spalte verwendet)

Nachdem alle Anwendungsinstanzen die neue Spalte verwenden:

-- Make column required
ALTER TABLE orders ALTER COLUMN shipping_method SET NOT NULL;
ALTER TABLE orders ALTER COLUMN shipping_method SET DEFAULT 'standard';

Gefährliche Migrationsmuster

---

Automatisiertes Rollback

Fehlerratenbasiertes Rollback

#!/bin/bash
# post-deploy-monitor.sh

DEPLOY_TIME=$(date +%s)
MONITOR_DURATION=300  # 5 minutes
ERROR_THRESHOLD=0.02  # 2%

while [ $(($(date +%s) - DEPLOY_TIME)) -lt $MONITOR_DURATION ]; do
  ERROR_RATE=$(curl -s "http://prometheus:9090/api/v1/query?query=rate(http_requests_total{status=~'5..'}[2m])/rate(http_requests_total[2m])" | jq -r '.data.result[0].value[1]')

  if (( $(echo "$ERROR_RATE > $ERROR_THRESHOLD" | bc -l) )); then
    echo "ERROR: Rate $ERROR_RATE exceeds threshold $ERROR_THRESHOLD"
    echo "Initiating rollback..."
    kubectl rollout undo deployment/api
    exit 1
  fi

  sleep 15
done

echo "Deployment healthy for $MONITOR_DURATION seconds"

---

Häufig gestellte Fragen

Mit welcher Strategie sollten wir beginnen?

Beginnen Sie mit der Blau-Grün-Bereitstellung. Es ist am einfachsten zu implementieren, bietet sofortiges Rollback und funktioniert mit jeder Anwendungsarchitektur. Rolling Updates eignen sich besser für Kubernetes-Umgebungen mit vielen Replikaten. Canary-Bereitstellungen sind für Anwendungen mit hohem Datenverkehr gedacht, bei denen Sie Änderungen vor der vollständigen Einführung mit echtem Datenverkehr validieren möchten.

Wie gehen wir mit lang andauernden Hintergrundjobs während der Bereitstellung um?

Verwenden Sie das ordnungsgemäße Herunterfahren. Wenn ein Pod ein Beendigungssignal empfängt, akzeptieren Sie keine neuen Jobs mehr, beenden Sie laufende Jobs (mit Zeitüberschreitung) und fahren Sie dann herunter. Konfigurieren Sie in Kubernetes terminationGracePeriodSeconds so, dass genügend Zeit für den Abschluss von Jobs bleibt. Für Jobs, die länger als die Kulanzfrist dauern, verwenden Sie eine Jobwarteschlange (Redis, RabbitMQ), die fehlgeschlagene Jobs für verbleibende Worker erneut ausführt.

Was ist mit WebSocket-Verbindungen während der Bereitstellung?

WebSocket-Verbindungen sind langlebig und müssen sorgfältig gehandhabt werden. Während eines fortlaufenden Updates bleiben bestehende Verbindungen auf dem alten Pod aktiv, bis der Pod beendet wird. Clients sollten eine automatische Wiederverbindungslogik implementieren. Bei Blau-Grün-Bereitstellungen schalten Sie neue Verbindungen auf die neue Umgebung um und lassen gleichzeitig zu, dass bestehende Verbindungen mit einer Zeitüberschreitung auf die alte Umgebung übertragen werden.

Wie testen wir Bereitstellungen ohne Ausfallzeiten?

Führen Sie während der Bereitstellung einen Auslastungstest durch. Verwenden Sie k6 oder ein ähnliches Tool, um kontinuierlichen Datenverkehr zu generieren, und lösen Sie dann eine Bereitstellung aus. Überprüfen Sie, ob während des Rollovers Fehler, erhöhte Latenz oder unterbrochene Verbindungen vorliegen. Einzelheiten zur Implementierung finden Sie in unserem Lasttest-Leitfaden.

---

Was als nächstes kommt

Eine Bereitstellung ohne Ausfallzeiten ist eine Voraussetzung für häufige und zuverlässige Releases. Kombinieren Sie es mit CI/CD-Automatisierung für die vollständige Bereitstellungspipeline und Überwachung für die Überprüfung nach der Bereitstellung.

Kontaktieren Sie ECOSIRE für Beratung zur Bereitstellungsstrategie oder erkunden Sie unseren DevOps-Leitfaden für die vollständige Infrastruktur-Roadmap.

---

Herausgegeben von ECOSIRE – hilft Unternehmen bei der Bereitstellung ohne Unterbrechung.