Blue-Green und Rolling Deployments mit Docker-Containern verstehen

1. Was Deployment-Strategien wirklich bedeuten

Eine Deployment-Strategie entscheidet darüber, wie der Übergang von einer laufenden Software-Version zur nächsten stattfindet – ohne dass Nutzer diesen Übergang als Fehler oder Ausfall wahrnehmen. Im Container-Kontext bedeutet das konkret: Welche Container laufen wann, wie lange laufen alte und neue Version parallel, und unter welchen Bedingungen übernimmt der neue Stand vollständig den Traffic? Diese Fragen sind nicht akademisch. Sie bestimmen, ob ein Deployment um 14 Uhr an einem Mittwoch eine Routinetätigkeit ist oder ein geplanter Wartungsausfall mit Eskalationskette.

Docker und Container-Orchestrierung haben Blue-Green Deployments und Rolling Deployments erheblich vereinfacht. Das Starten eines neuen Containers neben einem laufenden dauert Sekunden. Die schwierige Frage ist nicht mehr das Starten des neuen Containers, sondern das kontrollierte Umschalten des eingehenden Traffics, die Behandlung aktiver Sessions und der zuverlässige Rollback-Pfad im Fehlerfall. Alle drei Aspekte erfordern eine bewusste Strategie, die vor dem Deployment-Skript steht – nicht danach.

Die beiden wichtigsten Strategien im Container-Umfeld sind Blue-Green und Rolling. Sie unterscheiden sich fundamental in ihrem Ressourcenbedarf, dem Risikoprofil während des Deployments und der Komplexität der Rollback-Mechanismen. Keiner der beiden Ansätze ist universell besser – die richtige Wahl hängt von der Architektur der Anwendung, dem Umgang mit persistenten Sessions und dem verfügbaren Infrastrukturbudget ab.

2. Blue-Green Deployment: Konzept und Mechanismus

Beim Blue-Green Deployment existieren zu jedem Zeitpunkt zwei vollständig ausgestattete Umgebungen: die aktive Produktionsumgebung (Blue) und die neue Version (Green), die parallel hochgefahren wird. Solange Green noch nicht live ist, empfängt sie keinen echten Traffic. Erst wenn alle Health-Checks für Green bestanden sind, wird das Routing atomisch umgeschaltet: der Load-Balancer oder Reverse-Proxy schickt alle neuen Requests an Green, Blue empfängt keinen Traffic mehr. Blue bleibt zunächst weiter laufen, um bei Problemen sofort als Rollback-Ziel zur Verfügung zu stehen.

Der entscheidende Vorteil dieses Blue-Green-Ansatzes ist die Atomarität des Umschaltvorgangs. Es gibt keinen Moment, in dem alte und neue Code-Version gleichzeitig Requests bearbeiten. Das vermeidet eine ganze Klasse von Problemen: inkonsistente API-Antworten während einer gemischten Rollout-Phase, Race-Conditions bei parallelen Datenbankoperationen verschiedener Code-Versionen und schwer reproduzierbare Fehler, die nur bei bestimmten Version-Mix-Verhältnissen auftreten. Für Anwendungen mit strikten Konsistenzanforderungen ist Blue-Green deshalb oft die bessere Wahl gegenüber Rolling.

Der Nachteil liegt im Ressourcenbedarf: Während des Deployments laufen zwei vollständige Stacks parallel. Bei großen Deployments – mehrere Services, viele Container-Instanzen – bedeutet das für kurze Zeit doppelten Speicherbedarf und doppelte CPU-Last. In Cloud-Umgebungen mit dynamischer Skalierung ist das akzeptabel; auf fester Hardware muss die Kapazitätsplanung Blue-Green Deployments explizit berücksichtigen.

# blue-green-deploy.sh — Atomic blue-green switch with Traefik label routing
set -euo pipefail

SERVICE="webapp"
REGISTRY="registry.example.com"
IMAGE_TAG="${1:?Usage: $0 <image-tag>}"

# Detect current active slot
CURRENT_SLOT=$(docker inspect "${SERVICE}-blue" \
  --format '{ {index .Config.Labels "deployment.slot"} }' 2>/dev/null || echo "green")
NEW_SLOT=$([ "$CURRENT_SLOT" = "blue" ] && echo "green" || echo "blue")

echo "[INFO] Deploying $IMAGE_TAG to slot: $NEW_SLOT (replacing $CURRENT_SLOT)"

# Pull new image before starting (fail fast on registry issues)
docker pull "${REGISTRY}/${SERVICE}:${IMAGE_TAG}"

# Start new slot — no traffic yet (weight=0 label)
docker run -d \
  --name "${SERVICE}-${NEW_SLOT}" \
  --label "traefik.enable=true" \
  --label "traefik.http.routers.${SERVICE}.rule=Host(\`app.example.com\`)" \
  --label "traefik.http.services.${SERVICE}-${NEW_SLOT}.loadbalancer.weight=0" \
  --label "deployment.slot=${NEW_SLOT}" \
  "${REGISTRY}/${SERVICE}:${IMAGE_TAG}"

# Wait for health check to pass (max 120 seconds)
for i in $(seq 1 24); do
  STATUS=$(docker inspect "${SERVICE}-${NEW_SLOT}" --format '{ {.State.Health.Status} }')
  [ "$STATUS" = "healthy" ] && break
  echo "[WAIT] Health status: $STATUS ($((i*5))s elapsed)"
  sleep 5
  if [ "$i" -eq 24 ]; then
    echo "[ERROR] Health check timeout — rolling back"
    docker rm -f "${SERVICE}-${NEW_SLOT}"
    exit 1
  fi
done

# Atomic traffic switch: enable new, disable old
docker update --label-add "traefik.http.services.${SERVICE}-${NEW_SLOT}.loadbalancer.weight=100" \
  "${SERVICE}-${NEW_SLOT}"
docker update --label-add "traefik.http.services.${SERVICE}-${CURRENT_SLOT}.loadbalancer.weight=0" \
  "${SERVICE}-${CURRENT_SLOT}"

echo "[OK] Traffic switched to $NEW_SLOT — old slot $CURRENT_SLOT kept for rollback"

3. Rolling Deployment: schrittweise Ablösung

Ein Rolling Deployment ersetzt Instanzen einer Anwendung nacheinander, ohne die gesamte Kapazität gleichzeitig zu tauschen. Bei fünf laufenden Instanzen eines Services wird zunächst eine gestoppt, durch die neue Version ersetzt und als healthy bestätigt, bevor die nächste Instanz abgelöst wird. Zu keinem Zeitpunkt laufen weniger Instanzen als eine festgelegte Minimalanzahl – typischerweise 50–75% der Zielkapazität. Das bedeutet: Während des Rolling Deployments bedienen alte und neue Version gleichzeitig Traffic.

Dieser Gleichzeitigkeitsaspekt ist sowohl Stärke als auch Schwäche. Stärke, weil der Ressourcenbedarf deutlich geringer ist als bei Blue-Green: Es werden nie mehr Container benötigt als im Normalbetrieb plus eine Instanz im Übergang. Schwäche, weil die Anwendung so designed sein muss, dass verschiedene Versionen problemlos parallel betrieben werden können – eine Anforderung, die bei nicht-rückwärtskompatiblen API-Änderungen oder Datenbankmigrationen schnell zur Herausforderung wird. Rolling Deployments erfordern deshalb besondere Disziplin beim Schema-Design: jede Änderung muss von der alten Version interpretierbar sein.

Docker Swarm und Kubernetes haben Rolling Deployments als nativen Mechanismus eingebaut. Mit Docker Compose lässt sich das Prinzip durch gestaffeltes Neustarten mehrerer Profile oder durch explizites Skalieren und Entfernen einzelner Container nachbauen. Die maximale Parallelität des Rollouts und die minimale Verfügbarkeit während des Deployments sind die beiden zentralen Konfigurationsparameter jedes Rolling Deployments und müssen auf das tatsächliche Traffic-Niveau und die Response-Time-Anforderungen der Anwendung abgestimmt sein.

4. Routing mit Traefik: Labels und Weight-Splitting

Traefik eignet sich besonders gut für Blue-Green und Rolling Deployments, weil das Routing vollständig über Docker-Container-Labels konfiguriert wird und Konfigurationsänderungen ohne Traefik-Neustart wirksam werden. Das zentrale Konzept ist das Weight-Splitting: Mehrere Backend-Services erhalten unterschiedliche Gewichte, und Traefik verteilt den Traffic proportional. Ein Weight von 100 für Green und 0 für Blue entspricht einem vollständigen Blue-Green-Switch ohne Downtime.

Für schrittweises Canary-Releasing – eine Zwischenform zwischen reinem Blue-Green und Rolling Deployment – können Gewichte stufenweise verschoben werden: zunächst 90/10 zwischen Old und New, dann 70/30, 50/50 und schließlich 0/100. Bei jedem Schritt werden Fehlerrate, Latenz und wichtige Business-Metriken der neuen Version geprüft, bevor der nächste Schritt vollzogen wird. Dieses Pattern erfordert Automatisierung – manuelles Anpassen von Labels während eines Live-Deployments ist fehleranfällig und langsam.

# traefik-weight-shift.sh — Gradually shift traffic between blue and green
# Usage: ./traefik-weight-shift.sh <service> <green-weight> (blue gets remainder)
set -euo pipefail

SERVICE="${1:?Service name required}"
GREEN_WEIGHT="${2:?Green weight (0-100) required}"
BLUE_WEIGHT=$((100 - GREEN_WEIGHT))

# Update Traefik weights via Docker label update (takes effect immediately)
docker service update \
  --label-add "traefik.http.services.${SERVICE}-green.loadbalancer.weight=${GREEN_WEIGHT}" \
  "${SERVICE}_green"

docker service update \
  --label-add "traefik.http.services.${SERVICE}-blue.loadbalancer.weight=${BLUE_WEIGHT}" \
  "${SERVICE}_blue"

echo "[OK] Traffic split: green=${GREEN_WEIGHT}% blue=${BLUE_WEIGHT}%"

# Monitor error rate for 60 seconds before returning
echo "[MONITOR] Watching error rate for 60s..."
for i in $(seq 1 12); do
  # Query Traefik metrics endpoint for 5xx rate
  ERROR_RATE=$(curl -sf http://traefik:8080/metrics \
    | grep "traefik_service_requests_total.*code=\"5" \
    | awk '{sum+=$2} END {print sum+0}')
  echo "[${i}] 5xx count: ${ERROR_RATE}"
  sleep 5
done

5. Health-Checks als Deployment-Gate

Ein Blue-Green oder Rolling Deployment ohne zuverlässige Health-Checks ist ein Deployment, das Fehler in die Produktion trägt ohne es zu merken. Der HEALTHCHECK-Befehl im Dockerfile definiert, wann ein Container als betriebsbereit gilt – aber der wichtigere Aspekt ist, was genau geprüft wird. Ein einfaches curl localhost/ping, das HTTP 200 zurückgibt, prüft nicht, ob die Datenbankverbindung besteht, ob alle notwendigen Konfigurationsparameter geladen wurden oder ob externe Abhängigkeiten erreichbar sind. Ein guter Health-Check für Deployment-Gates prüft all das.

Das Timing-Parameter-Trio aus interval, timeout und retries bestimmt, wie lange das Deployment-System auf einen healthy-Status wartet. Zu aggressive Timeouts führen zu Fehlalarmen bei langsamen Startprozessen; zu laxe Timeouts verzögern die Erkennung echter Fehler und verlängern den Deployment-Vorgang unnötig. Für PHP-Anwendungen mit Opcache-Warmup oder Magento mit DI-Initialisierung sind 30–60 Sekunden für den ersten Health-Check realistisch. Wichtig: Der Health-Check-Endpoint selbst darf keine Seiteneffekte haben und muss auch unter Last schnell antworten, sonst schlägt er unter Traffic fehl.

6. Rollback-Strategien bei fehlgeschlagenem Deployment

Ein Blue-Green Deployment hat den schnellsten Rollback-Pfad aller Strategien: Den Traffic zurück auf Blue umschalten dauert Millisekunden, weil Blue nie gestoppt wurde. Dieses sofortige Rollback ist der Hauptgrund, warum Teams mit hoher Release-Frequenz und strengen SLA-Anforderungen Blue-Green bevorzugen. Die Kosten der parallel laufenden Umgebung sind damit die Versicherungsprämie für ein garantiert schnelles Recovery.

Beim Rolling Deployment ist der Rollback aufwändiger: Jede bereits ersetzte Instanz muss wieder auf die alte Version zurückgerollt werden. Das geschieht nach demselben gestaffelten Muster wie das ursprüngliche Deployment, kostet also Zeit und erhöht die Risikodauer. In der Praxis wird deshalb oft ein Hybrid gewählt: Rolling für regelmäßige kleine Updates, bei denen Rollbacks selten sind, und Blue-Green für große Releases mit signifikanten Änderungen, bei denen das Rollback-Risiko höher ist. Entscheidend ist, dass der Rollback-Pfad vorher getestet und dokumentiert ist – nicht erst im Ernstfall ausprobiert wird.

Eine oft übersehene Rollback-Dimension ist die Datenbank: Wenn das Deployment eine Datenbankmigrationen enthält, bestimmt diese, ob ein Rollback des Applikations-Codes ohne Datenbankrollback funktioniert. Additive Migrationen (neue Spalten, neue Tabellen) erlauben Rollbacks; destruktive Migrationen (Spalten löschen, umbenennen) tun das nicht. Das Expand-Contract-Pattern für Datenbankmigrationen ist deshalb die notwendige Ergänzung zu Blue-Green und Rolling Deployments.

# rollback.sh — Instant blue-green rollback to previous slot
set -euo pipefail

SERVICE="webapp"

# Identify which slot is currently active (receiving traffic)
ACTIVE_SLOT=$(docker inspect "${SERVICE}-blue" \
  --format '{ {index .Config.Labels "traefik.http.services.'${SERVICE}'-blue.loadbalancer.weight"} }')

if [ "$ACTIVE_SLOT" = "100" ]; then
  ROLLBACK_TO="green"
  ROLLBACK_FROM="blue"
else
  ROLLBACK_TO="blue"
  ROLLBACK_FROM="green"
fi

echo "[ROLLBACK] Switching traffic from $ROLLBACK_FROM back to $ROLLBACK_TO"

# Atomic rollback: restore old slot weight, remove new slot weight
docker update \
  --label-add "traefik.http.services.${SERVICE}-${ROLLBACK_TO}.loadbalancer.weight=100" \
  "${SERVICE}-${ROLLBACK_TO}"

docker update \
  --label-add "traefik.http.services.${SERVICE}-${ROLLBACK_FROM}.loadbalancer.weight=0" \
  "${SERVICE}-${ROLLBACK_FROM}"

echo "[OK] Rollback complete — $ROLLBACK_TO is now active"
echo "[INFO] Remove failed slot: docker rm -f ${SERVICE}-${ROLLBACK_FROM}"

7. Datenbankmigrationen bei Zero-Downtime-Releases

Datenbankmigrationen sind die häufigste Ursache dafür, dass Blue-Green Deployments scheitern oder Downtime verursachen, obwohl das Ziel Zero-Downtime war. Das Problem: Die neue Applikationsversion erwartet ein Schema, das noch nicht existiert; oder die alte Version läuft während des Deployments weiter und kann mit dem neuen Schema nichts anfangen. Beides führt zu Fehlern. Das Expand-Contract-Pattern löst das durch drei Phasen: Expand (additive Schema-Änderung, kompatibel mit altem Code), Deploy (neuer Code mit neuem und altem Schema funktionsfähig), Contract (alte Schema-Elemente nach vollständigem Deployment entfernen).

In der Praxis bedeutet das: Eine Spalte wird nie direkt umbenannt, sondern es wird eine neue Spalte mit dem neuen Namen hinzugefügt, der Code liest beide und schreibt in beide, dann wird die alte Spalte in einem späteren Release entfernt. Dieser Aufwand ist real, aber er ist der Preis für echtes Zero-Downtime-Deployment ohne Session-Unterbrechungen. Wer Migrationen und Blue-Green Deployments kombinieren will, muss den Migrationsprozess als eigenständigen Schritt vor dem Container-Switch einplanen und sicherstellen, dass der Migrations-Container nur einmal läuft – nicht bei jedem Container-Start.

8. Deployment-Monitoring: wann ist ein Release stabil?

Das Ende des Blue-Green oder Rolling Deployments ist nicht der Moment, in dem der letzte Container healthy meldet. Ein Release gilt erst dann als stabil, wenn die Fehlerrate, die Response-Zeit und die wichtigsten Business-Metriken über einen definierten Beobachtungszeitraum – typischerweise 5 bis 15 Minuten nach vollständigem Traffic-Switch – innerhalb der erwarteten Grenzen bleiben. Deployment-Monitoring ist damit kein Logging-Problem, sondern ein Observability-Problem: ohne Metriken fehlt das Signal, das den Unterschied zwischen einem gesunden und einem defekten Release erkennbar macht.

Für automatisierte Blue-Green Deployments in CI/CD-Pipelines bedeutet das: Das Deployment-Skript endet nicht mit dem Traffic-Switch, sondern mit einer Stabilisierungsphase, in der die Metriken beobachtet werden und ein automatischer Rollback ausgelöst wird, wenn die Error-Rate einen Schwellenwert überschreitet. Prometheus-Metriken, Traefik-Zugriffslog-Aggregation und APM-Daten bilden zusammen ein sinnvolles Signal für diese Entscheidung. Ohne diese Automatisierung ist das Deployment nur dann wirklich automatisch, wenn alles gut läuft – aber nicht in dem Moment, in dem es darauf ankommt.

9. Blue-Green vs. Rolling: direkter Vergleich

Beide Strategien haben ihren Platz. Die Entscheidung zwischen Blue-Green Deployment und Rolling Deployment hängt von Anwendungsarchitektur, Ressourcen und Risikobereitschaft ab.

In der Praxis beginnen viele Teams mit Rolling Deployments, weil sie weniger Infrastruktur erfordern und einfacher zu debuggen sind. Mit wachsender Release-Frequenz und steigenden SLA-Anforderungen wechseln sie zu Blue-Green für kritische Services und behalten Rolling für weniger kritische Hintergrundprozesse. Beide Strategien profitieren von denselben Grundlagen: gute Health-Checks, klare Metriken und ein getesteter Rollback-Prozess.

10. Zusammenfassung

Blue-Green und Rolling Deployments sind die zwei wichtigsten Strategien für Zero-Downtime-Releases im Container-Umfeld. Blue-Green schaltet Traffic atomar um und bietet sofortigen Rollback, erfordert aber doppelte Kapazität während des Deployments. Rolling ersetzt Instanzen schrittweise mit minimalem Mehrressourcenbedarf, erlaubt aber temporäre Version-Koexistenz. Beide erfordern zuverlässige Health-Checks als Deployment-Gate und klare Metriken zur Stabilitätsbewertung nach dem Release.

Die Wahl der richtigen Deployment-Strategie ist nicht die schwierigste Entscheidung – die schwierigste ist die konsequente Implementierung aller Voraussetzungen: Health-Checks, die wirklich den Zustand der Anwendung prüfen; Datenbankmigrationen nach dem Expand-Contract-Pattern; Monitoring mit automatischen Rollback-Triggern; und ein Deployment-Prozess, der regelmäßig getestet wird, bevor er im Notfall gebraucht wird. Mit diesen Grundlagen wird jedes Deployment zur planbaren Routine.

11. FAQ: Blue-Green und Rolling Deployments mit Docker