Blue Green Deployment für Symfony Anwendungen ohne Ausfallzeit

1. Was Blue Green Deployment für Symfony konkret bedeutet

Blue Green Deployment ist eine Deployment-Strategie, bei der zwei vollständig identische Produktionsumgebungen parallel existieren, üblicherweise Blue und Green genannt. Zu jedem Zeitpunkt bedient nur eine der beiden Umgebungen echten Nutzer-Traffic, während die andere entweder inaktiv ist oder gerade die neue Anwendungsversion erhält. Der Wechsel zwischen beiden Umgebungen geschieht durch eine einzige Konfigurationsänderung am Load Balancer, nicht durch das schrittweise Austauschen einzelner Server.

Der entscheidende Unterschied zu einem klassischen Rolling Update liegt in der Atomarität des Wechsels. Bei einem Rolling Update laufen für eine gewisse Zeit alte und neue Version gleichzeitig auf verschiedenen Servern, was bei inkompatiblen Änderungen zu Inkonsistenzen führen kann. Bei Blue Green Deployment bedient zu jedem Zeitpunkt entweder die komplett alte oder die komplett neue Version den gesamten Traffic, niemals eine Mischung aus beiden. Das vereinfacht das Testen erheblich, weil die neue Version in der inaktiven Umgebung vollständig unter Produktionsbedingungen geprüft werden kann, bevor auch nur ein einziger echter Nutzer sie zu Gesicht bekommt.

Für eine Symfony-Anwendung bedeutet Blue Green Deployment konkret: zwei vollständige Sets an Anwendungsservern, die sich denselben Cache, dieselbe Session-Infrastruktur und dieselbe Datenbank teilen, aber unterschiedliche Codeversionen ausführen können. Die eigentliche Herausforderung liegt nicht im Kopieren der Server, sondern in der sauberen Behandlung der gemeinsam genutzten, zustandsbehafteten Ressourcen, die in den folgenden Abschnitten im Detail behandelt werden.

2. Zwei identische Umgebungen: Blue und Green aufbauen

Die Grundvoraussetzung für funktionierendes Blue Green Deployment ist echte Identität zwischen beiden Umgebungen: gleiche PHP-Version, gleiche Extensions, gleiche Server-Ressourcen, gleiche Netzwerkkonfiguration. Jede Abweichung zwischen Blue und Green untergräbt das Versprechen, dass ein erfolgreicher Test in der inaktiven Umgebung tatsächlich das Verhalten in Produktion vorhersagt. In der Praxis erreicht man diese Identität am zuverlässigsten über Infrastructure as Code, bei der beide Umgebungen aus derselben Terraform- oder Ansible-Definition entstehen, parametrisiert nur über den Umgebungsnamen.

Ein häufiger Fehler ist, Blue als die dauerhaft produktive Umgebung zu behandeln und Green nur sporadisch für Deployments hochzufahren. Das führt dazu, dass Green im Laufe der Zeit unbemerkt von Blue abdriftet, etwa durch manuell installierte Sicherheitsupdates, die nur auf einer Seite eingespielt wurden. Robustes Blue Green Deployment behandelt beide Umgebungen als gleichwertig und rotiert bei jedem Release die Rolle von aktiv und inaktiv, sodass Drift durch fehlende Symmetrie schnell auffällt.

#!/usr/bin/env bash
# provision-environment.sh — build the inactive environment identically
# to the currently active one, using the same infrastructure definition
set -euo pipefail

TARGET_ENV="${1:?Usage: provision-environment.sh <blue|green>}"
RELEASE_TAG="${2:?Usage: provision-environment.sh <env> <release-tag>}"

echo "[INFO] Provisioning ${TARGET_ENV} with release ${RELEASE_TAG}"

terraform -chdir="infra/${TARGET_ENV}" apply \
  -var="release_tag=${RELEASE_TAG}" \
  -var="environment=${TARGET_ENV}" \
  -auto-approve

ansible-playbook -i "inventory/${TARGET_ENV}.ini" deploy.yml \
  --extra-vars "release_tag=${RELEASE_TAG}"

echo "[OK] ${TARGET_ENV} provisioned and ready for smoke tests"

3. Traffic Switching am Load Balancer oder Reverse Proxy

Der eigentliche Umschaltmoment bei Blue Green Deployment findet am Load Balancer oder Reverse Proxy statt, nicht in der Anwendung selbst. Nginx, HAProxy oder ein Cloud-Load-Balancer bekommen eine neue Upstream-Konfiguration, die statt auf Blue nun auf Green zeigt, oder umgekehrt. Dieser Schritt sollte in unter einer Sekunde abgeschlossen sein und darf keine bestehenden Verbindungen abrupt trennen, weshalb ein Graceful Reload statt eines harten Neustarts des Proxys notwendig ist.

Bei DNS-basiertem Blue Green Deployment ist zusätzlich die TTL des DNS-Eintrags zu beachten. Eine TTL von einer Stunde bedeutet, dass manche Clients bis zu einer Stunde lang weiterhin die alte Umgebung ansprechen, selbst nachdem der DNS-Eintrag geändert wurde. Für echtes Zero-Downtime-Umschalten ist deshalb ein Layer-7-Proxy mit sofortiger Konfigurationsänderung dem DNS-Wechsel klar vorzuziehen, da der Proxy die Umschaltung ohne Cache-Verzögerung auf Client-Seite durchführt.

# /etc/nginx/conf.d/symfony-upstream.conf
# The active environment is selected via a single upstream block.
# Switching blue/green means reloading this file with the new target.

upstream symfony_active {
    server 10.0.1.10:9000 max_fails=2 fail_timeout=10s; # green environment
    # server 10.0.2.10:9000 max_fails=2 fail_timeout=10s; # blue environment
}

server {
    listen 443 ssl http2;
    server_name app.mironsoft.de;

    location / {
        fastcgi_pass symfony_active;
        include fastcgi_params;
    }
}

# switch-traffic.sh reloads nginx after rewriting the upstream target:
# nginx -t && nginx -s reload

4. Die Datenbank Herausforderung bei Blue Green Deployment

Die Datenbank ist der Punkt, an dem sich Blue Green Deployment von einem reinen Infrastrukturthema zu einem echten Anwendungsdesign-Problem wandelt. Beide Umgebungen greifen üblicherweise auf dieselbe Datenbank zu, was bedeutet, dass das Datenbankschema gleichzeitig sowohl mit der alten als auch mit der neuen Anwendungsversion kompatibel sein muss. Eine Migration, die eine Spalte umbenennt oder löscht, bricht sofort die alte Version, solange diese noch parallel läuft.

Die Lösung ist das Expand-Contract-Muster: Neue Spalten werden zusätzlich zu bestehenden hinzugefügt, niemals bestehende Spalten sofort entfernt. Beide Anwendungsversionen können die neue Spalte ignorieren oder nutzen, je nach Codestand. Erst in einem späteren, separaten Deployment, nachdem die alte Version endgültig außer Betrieb ist, werden die nicht mehr benötigten Spalten entfernt. Für Blue Green Deployment mit Symfony und Doctrine bedeutet das, jede Schema-Änderung in mindestens zwei getrennte, abwärtskompatible Migrationsschritte aufzuteilen, statt sie in einem einzigen Schritt durchzuführen.

5. Sessions und Cache zwischen Blue und Green teilen

Würde jede Umgebung ihren eigenen, lokalen Session-Speicher verwenden, gingen bei jedem Umschalten alle aktiven Nutzersitzungen verloren, weil Green die Sessions von Blue nicht kennt. Für nahtloses Blue Green Deployment müssen Sessions deshalb in einem externen, von beiden Umgebungen gemeinsam genutzten Store liegen, typischerweise Redis. Symfony unterstützt das nativ über den RedisSessionHandler, sodass ein Nutzer mitten in einem Checkout-Vorgang den Umschaltmoment gar nicht bemerkt.

Gleiches gilt für den Anwendungscache. Läuft der Symfony-Cache lokal auf dem Dateisystem jeder einzelnen Instanz, entstehen zwei getrennte, potenziell inkonsistente Cache-Zustände zwischen Blue und Green. Ein gemeinsamer Redis- oder Memcached-Cache stellt sicher, dass beide Umgebungen konsistente Daten sehen, unabhängig davon, welche Version des Codes gerade aktiv ist. Diese gemeinsame Infrastruktur ist neben der Datenbank die zweite tragende Säule, ohne die Blue Green Deployment in der Praxis nicht funktioniert.

# config/packages/framework.yaml — shared Redis session storage
# so a user session survives a blue/green traffic switch
framework:
  session:
    handler_id: 'redis://redis.internal.mironsoft.de:6379'
    cookie_secure: auto
    cookie_samesite: lax
    gc_maxlifetime: 3600

  cache:
    app: cache.adapter.redis
    default_redis_provider: 'redis://redis.internal.mironsoft.de:6379'

6. Asset Versionierung und Cache Invalidierung beim Switch

Statische Assets wie CSS- und JavaScript-Dateien werden bei Symfony üblicherweise mit einem Versions-Hash im Dateinamen versehen, sodass Browser-Caches automatisch invalidiert werden, wenn sich der Inhalt ändert. Bei Blue Green Deployment ist wichtig, dass sowohl die alte als auch die neue Version ihre jeweiligen Asset-Dateien gleichzeitig unter einer stabilen URL erreichbar halten, etwa über ein Content Delivery Network, das beide Versionsstände parallel ausliefert, statt alte Assets sofort zu löschen.

Ein Nutzer, der eine HTML-Seite von der alten Version geladen hat, kurz bevor umgeschaltet wurde, fordert danach weiterhin die alten Asset-Pfade an. Werden diese sofort gelöscht, sobald Green aktiv wird, erhält dieser Nutzer kaputte Stylesheets oder fehlerhaftes JavaScript. Für sauberes Blue Green Deployment sollten alte Assets deshalb für einen definierten Übergangszeitraum, meist mehrere Stunden, parallel zu den neuen Assets erreichbar bleiben, bevor sie endgültig entfernt werden.

#!/usr/bin/env bash
# publish-assets.sh — keep both blue and green asset versions available
# on the CDN during the transition window
set -euo pipefail

RELEASE_TAG="${1:?Usage: publish-assets.sh <release-tag>}"
CDN_BUCKET="s3://mironsoft-assets/releases"

aws s3 sync "public/build/" "${CDN_BUCKET}/${RELEASE_TAG}/" \
  --cache-control "public, max-age=31536000, immutable"

echo "[OK] Assets for ${RELEASE_TAG} published, previous releases remain live"
# Cleanup of releases older than 24h runs as a separate, scheduled job

7. Automatisierte Smoke Tests vor dem Umschalten

Der größte Vorteil von Blue Green Deployment geht verloren, wenn die inaktive Umgebung ungeprüft live geschaltet wird. Vor jedem Traffic-Switch sollte eine automatisierte Smoke-Test-Suite gegen die neue Umgebung laufen, die über einen internen Zugang erreichbar ist, ohne dass echter Nutzer-Traffic beteiligt ist. Diese Tests prüfen typischerweise kritische Pfade: Login, Checkout, zentrale API-Endpunkte und die Health-Check-Route.

Schlägt auch nur ein einziger Smoke-Test fehl, darf der Umschaltvorgang bei gut konfiguriertem Blue Green Deployment gar nicht erst starten. Diese Absicherung ist deutlich günstiger als ein Rollback nach einem fehlgeschlagenen Umschalten, weil noch kein einziger echter Nutzer betroffen war. Die Smoke-Test-Suite sollte deshalb Teil der CI-Pipeline sein und automatisch gegen die frisch provisionierte, inaktive Umgebung laufen, bevor der Switch überhaupt zur Ausführung freigegeben wird.

#!/usr/bin/env bash
# smoke-test.sh — run critical path checks against the inactive environment
# before allowing the traffic switch to proceed
set -euo pipefail

TARGET_URL="${1:?Usage: smoke-test.sh <internal-url>}"
FAILURES=0

check() {
  local path="$1" expected="$2"
  local code
  code=$(curl -s -o /dev/null -w "%{http_code}" "${TARGET_URL}${path}")
  if [[ "$code" != "$expected" ]]; then
    echo "[FAIL] ${path} returned ${code}, expected ${expected}" >&2
    FAILURES=$((FAILURES + 1))
  else
    echo "[OK] ${path}"
  fi
}

check "/health/ready" "200"
check "/login" "200"
check "/api/v1/products?limit=1" "200"
check "/checkout" "200"

if (( FAILURES > 0 )); then
  echo "[ABORT] ${FAILURES} smoke test(s) failed — switch cancelled" >&2
  exit 1
fi

echo "[OK] All smoke tests passed — safe to switch traffic"

8. Rollback Strategie: sofort zurück zur alten Umgebung

Der praktische Hauptvorteil von Blue Green Deployment zeigt sich im Ernstfall: Ein Rollback bedeutet nicht das Zurückspielen von Code oder das erneute Deployen einer alten Version, sondern lediglich das Zurückschalten des Load Balancers auf die vorherige Umgebung, die währenddessen unverändert weiterlief. Dieser Rollback dauert genauso lange wie der ursprüngliche Switch, üblicherweise unter einer Sekunde, und ist damit um Größenordnungen schneller als ein klassisches Redeployment.

Wichtig ist, die alte Umgebung nach einem Switch nicht sofort herunterzufahren, sondern für einen definierten Beobachtungszeitraum, oft dreißig Minuten bis mehrere Stunden, aktiv im Standby zu belassen. Erst wenn Monitoring und Fehlerraten der neuen Umgebung über diesen Zeitraum stabil bleiben, wird die alte Umgebung tatsächlich freigegeben oder für das nächste Release wiederverwendet. Diese Standby-Phase ist der eigentliche Sicherheitsgewinn, den Blue Green Deployment gegenüber Deployment-Strategien ohne parallele zweite Umgebung bietet.

9. Blue Green Deployment im Vergleich zu Rolling Update und Canary

Die folgende Tabelle stellt Blue Green Deployment den beiden anderen verbreiteten Deployment-Strategien gegenüber.

Die höheren Infrastrukturkosten von Blue Green Deployment sind der Preis für den sofortigen Rollback und die Garantie, niemals zwei Versionen gleichzeitig unter echtem Traffic zu haben. Für Anwendungen mit hohem Risiko bei fehlerhaften Deployments, etwa im Checkout-Bereich eines Shops, überwiegt dieser Sicherheitsgewinn die zusätzlichen Kosten in den meisten Fällen deutlich.

10. Zusammenfassung

Blue Green Deployment für Symfony ersetzt den bangen Blick auf ein laufendes Rolling Update durch einen kontrollierten, sofort umkehrbaren Umschaltmoment. Zwei identische Umgebungen, eine gemeinsame Session- und Cache-Infrastruktur über Redis und ein Datenbankschema, das nach dem Expand-Contract-Muster wächst, bilden das technische Fundament. Der eigentliche Switch am Load Balancer dauert unter einer Sekunde und betrifft nie eine Mischung aus alter und neuer Version.

Automatisierte Smoke Tests vor dem Umschalten verhindern, dass ungetesteter Code überhaupt live geht, während eine Standby-Phase der alten Umgebung einen Rollback in derselben Geschwindigkeit wie den ursprünglichen Switch ermöglicht. Die höheren Infrastrukturkosten von Blue Green Deployment zahlen sich für Anwendungen mit hohem Risiko bei Deployment-Fehlern durch drastisch reduzierte Ausfallzeit und ein spürbar geringeres Sicherheitsgefühl bei jedem Release aus.

11. FAQ: Blue Green Deployment für Symfony