Magento Blue Green Deployments mit Containern ohne Downtime

1. Warum generisches Blue-Green bei Magento nicht reicht

Ein klassisches Blue-Green-Deployment geht davon aus, dass zwei identische Umgebungen parallel laufen und der Load Balancer den Traffic mit einem einzigen Schalter von der alten auf die neue Version umleitet. Bei einer zustandslosen API funktioniert das ohne größere Komplikationen. Bei Magento kommen jedoch mehrere Zustände hinzu, die beim Farbwechsel synchron gehalten werden müssen: Suchindizes, Cache-Einträge, Sessions, Warenkörbe und die Datenbankstruktur selbst.

Wer ein Blue-Green-Deployment für Magento naiv umsetzt und einfach zwei Container-Versionen gegen dieselbe Datenbank laufen lässt, riskiert, dass die neue Version mit veralteten Indizes arbeitet oder die alte Version durch eine bereits migrierte Datenbankstruktur bricht. Das Resultat sind kaputte Produktseiten, falsche Preise im Suchindex oder abgebrochene Checkouts, gerade während des kritischen Wechselfensters.

Dieser Artikel beschreibt, wie ein Magento Blue-Green-Deployment mit Containern die Besonderheiten von Indexern, Cache und Datenbank berücksichtigt, sodass der Wechsel zwischen den Farben tatsächlich unterbrechungsfrei abläuft, statt nur auf dem Papier ohne Downtime zu sein.

2. Zwei parallele Stacks: Blue und Green im Container-Setup

Die Grundstruktur eines Blue-Green-Deployments für Magento besteht aus zwei vollständig lauffähigen Container-Stacks, die sich nur durch ihre Code-Version unterscheiden, aber dieselbe Datenbank und denselben Redis-Cluster nutzen. Diese geteilte Datenschicht ist der entscheidende Unterschied zu generischen Blue-Green-Setups: Magento kann nicht einfach zwei getrennte Datenbanken pflegen, ohne Bestellungen, Kunden und Warenkörbe zu duplizieren oder zu verlieren.

Jeder Stack, ob Blue oder Green, bekommt einen eigenen PHP-FPM-Container, einen eigenen Nginx-Container und eigene Volumes für Static Content und generierten Code. Die geteilten Dienste, Datenbank, Redis und OpenSearch, bleiben über beide Farben hinweg bestehen und werden nicht dupliziert. Diese Aufteilung stellt sicher, dass ein Blue-Green-Deployment für Magento nur den Anwendungscode wechselt, während der Datenzustand konsistent bleibt.

# docker-compose.blue-green.yml — shared data layer, two app stacks
services:
  magento-blue:
    image: registry.mironsoft.de/magento-shop:${BLUE_TAG}
    environment:
      DEPLOY_COLOR: blue
      DB_HOST: mysql
      REDIS_HOST: redis
      OPENSEARCH_HOST: opensearch
    volumes:
      - static_blue:/var/www/html/pub/static
      - generated_blue:/var/www/html/generated
    networks: [backend]

  magento-green:
    image: registry.mironsoft.de/magento-shop:${GREEN_TAG}
    environment:
      DEPLOY_COLOR: green
      DB_HOST: mysql
      REDIS_HOST: redis
      OPENSEARCH_HOST: opensearch
    volumes:
      - static_green:/var/www/html/pub/static
      - generated_green:/var/www/html/generated
    networks: [backend]

  mysql:
    image: mysql:8.0
    networks: [backend]

  redis:
    image: redis:7-alpine
    networks: [backend]

  opensearch:
    image: opensearchproject/opensearch:2
    networks: [backend]

volumes:
  static_blue:
  static_green:
  generated_blue:
  generated_green:

networks:
  backend:

3. Static Content und DI Compile pro Farbe vorbereiten

Bevor eine Farbe im Blue-Green-Deployment live geschaltet wird, müssen setup:di:compile und setup:static-content:deploy vollständig auf dieser Farbe durchlaufen sein. Das passiert im Idealfall bereits während des Container-Builds, nicht erst nach dem Start des Containers, damit der erste Request auf der neuen Farbe nicht in einen langsamen On-the-fly-Compile läuft. Diese Vorbereitung ist bei Magento aufwändiger als bei den meisten anderen Applikationen, weil generierter Code und kompilierte Static Files direkt von der jeweiligen Codebasis abhängen.

Wichtig für ein sauberes Blue-Green-Deployment bei Magento: Static Content und generierter Code dürfen niemals zwischen Blue und Green geteilt werden, selbst wenn die Datenbank geteilt wird. Ein gemeinsames Static-Content-Volume würde dazu führen, dass die alte Farbe plötzlich neue, inkompatible JavaScript-Bundles ausliefert, bevor der eigentliche Switch überhaupt stattgefunden hat.

#!/usr/bin/env bash
# prepare-green.sh — build and warm up the inactive color before the switch
set -euo pipefail

COLOR="green"
IMAGE_TAG="${1:?Usage: prepare-green.sh <image-tag>}"

echo "[INFO] Building ${COLOR} stack with tag ${IMAGE_TAG}"
docker compose -f docker-compose.blue-green.yml build "magento-${COLOR}"

echo "[INFO] Running DI compile and static content deploy inside ${COLOR}"
docker compose -f docker-compose.blue-green.yml run --rm "magento-${COLOR}" \
  bin/magento setup:di:compile

docker compose -f docker-compose.blue-green.yml run --rm "magento-${COLOR}" \
  bin/magento setup:static-content:deploy -f de_DE en_US

echo "[OK] ${COLOR} stack ready for reindex and health checks"

4. Indexer-Strategie: Reindex auf der inaktiven Farbe

Magento-Indexer laufen entweder im Modus Update on Save oder Update by Schedule. Für ein Blue-Green-Deployment ist Update by Schedule fast immer die richtige Wahl, weil der Reindex dann über den Cron der aktuell aktiven Farbe läuft, während die inaktive Farbe vorbereitet wird. Der kritische Punkt: Der volle Reindex muss auf der neuen Farbe abgeschlossen sein, bevor sie Traffic erhält, sonst liefert sie beim ersten Request veraltete Preise, Lagerbestände oder Suchergebnisse aus.

Da Indexer und Suchindex in OpenSearch geteilt zwischen Blue und Green liegen, kann ein laufender Reindex während des Blue-Green-Deployments für Magento theoretisch beide Farben gleichzeitig betreffen. Deshalb sollte der Reindex erst gestartet werden, wenn der neue Code bereits vollständig deployed, aber noch nicht live geschaltet ist, und der Indexer-Status vor dem Switch explizit auf ready geprüft werden, nicht nur auf Anzahl der Jobs gleich null.

#!/usr/bin/env bash
# reindex-and-verify.sh — reindex on the inactive color, verify before switch
set -euo pipefail

COLOR="green"

echo "[INFO] Reindexing all indexers on ${COLOR}"
docker compose -f docker-compose.blue-green.yml exec "magento-${COLOR}" \
  bin/magento indexer:reindex

STATUS=$(docker compose -f docker-compose.blue-green.yml exec -T "magento-${COLOR}" \
  bin/magento indexer:status | grep -c "Ready" || true)

TOTAL_INDEXERS=$(docker compose -f docker-compose.blue-green.yml exec -T "magento-${COLOR}" \
  bin/magento indexer:status | grep -c "Indexer:" || true)

if [[ "$STATUS" -ne "$TOTAL_INDEXERS" ]]; then
  echo "[ERROR] Not all indexers are ready on ${COLOR}: ${STATUS}/${TOTAL_INDEXERS}" >&2
  exit 1
fi

echo "[OK] All ${TOTAL_INDEXERS} indexers ready on ${COLOR}"

5. Datenbank-Migrationen abwärtskompatibel gestalten

Da Blue und Green dieselbe Datenbank nutzen, muss jede Schema-Änderung in einem Magento Blue-Green-Deployment so gestaltet sein, dass sowohl der alte als auch der neue Code während der Übergangsphase mit derselben Datenbankstruktur funktioniert. Eine Spalte zu löschen, die der alte Code noch liest, würde die alte Farbe sofort mit einem Datenbankfehler abstürzen lassen, obwohl sie technisch noch aktiv ist.

Die bewährte Praxis für Schema-Änderungen in einem Blue-Green-Deployment für Magento ist ein zweistufiges Vorgehen über zwei Releases: Im ersten Release wird eine neue Spalte nur hinzugefügt, nie eine bestehende entfernt oder umbenannt. Erst im übernächsten Release, wenn sicher ist, dass keine alte Farbe mehr auf die alte Struktur angewiesen ist, wird die veraltete Spalte entfernt. Diese additive Migrationsstrategie ist der Kernunterschied zwischen einem Blue-Green-Deployment, das nur auf dem Papier funktioniert, und einem, das in der Produktion tatsächlich ohne Ausfall bleibt.

6. Cache- und Session-Warmup vor dem Switch

Ein kaltgestarteter Magento-Container beantwortet die ersten Requests spürbar langsamer, weil Konfigurations-Cache, Layout-Cache und Block-HTML-Cache erst gefüllt werden müssen. Für ein Blue-Green-Deployment bedeutet das: Bevor die neue Farbe Traffic bekommt, sollte ein Warmup-Skript die wichtigsten Kategorie- und Produktseiten sowie die Startseite aufrufen, damit der Full Page Cache in Varnish oder im eingebauten Magento-Cache bereits gefüllt ist.

Sessions bleiben bei einem korrekt konfigurierten Blue-Green-Deployment für Magento unberührt vom Farbwechsel, solange Redis als Session-Storage zentral und geteilt zwischen beiden Farben konfiguriert ist. Ein Kunde mit aktivem Warenkorb merkt vom Wechsel der Anwendungsfarbe im Idealfall nichts, weil seine Session-ID weiterhin gültig ist und lediglich vom neuen PHP-FPM-Container statt vom alten bedient wird.

7. Health Checks und Readiness Gates für den Farbwechsel

Der Traffic-Switch in einem Blue-Green-Deployment darf erst erfolgen, wenn ein automatisierter Health Check die neue Farbe als vollständig bereit meldet. Ein einfacher HTTP-200-Check auf die Startseite reicht dafür nicht aus, weil Magento auch mit unvollständig kompiliertem Code oder halbfertigem Reindex eine Seite mit Status 200 ausliefern kann. Ein aussagekräftiger Health-Check-Endpunkt prüft stattdessen gezielt Datenbankverbindung, Redis-Erreichbarkeit, OpenSearch-Status und Indexer-Zustand.

Erst wenn dieser mehrstufige Health Check grün ist, gilt die inaktive Farbe als bereit für den Switch. Dieses Readiness Gate ist der Unterschied zwischen einem Blue-Green-Deployment für Magento, das automatisiert und sicher abläuft, und einem, bei dem jemand manuell und unter Zeitdruck entscheidet, ob der Wechsel schon sicher ist.

#!/usr/bin/env bash
# health-gate.sh — readiness gate before switching traffic
set -euo pipefail

COLOR="green"
BASE_URL="http://magento-${COLOR}:8080"

check_endpoint() {
  local path="$1"
  local expected="$2"
  local response
  response=$(curl -s -o /dev/null -w "%{http_code}" "${BASE_URL}${path}")
  [[ "$response" == "$expected" ]] || { echo "[FAIL] ${path} returned ${response}"; return 1; }
}

echo "[INFO] Running readiness checks for ${COLOR}"
check_endpoint "/health/db" "200"
check_endpoint "/health/redis" "200"
check_endpoint "/health/opensearch" "200"
check_endpoint "/health/indexer" "200"

echo "[OK] ${COLOR} passed all readiness checks, safe to switch traffic"

8. Traffic-Switch am Reverse Proxy

Der eigentliche Traffic-Switch bei einem Blue-Green-Deployment für Magento passiert am Reverse Proxy, nicht in Magento selbst. Bei Traefik geschieht das über das Umschreiben eines Docker-Labels, das definiert, welcher Service für die Produktions-Domain zuständig ist, gefolgt von einem Reload der Proxy-Konfiguration. Bei Nginx wird stattdessen die Upstream-Definition ausgetauscht und ein nginx -s reload ausgeführt, das laufende Verbindungen nicht unterbricht.

Nach dem Switch bleibt die alte Farbe für eine definierte Zeitspanne, häufig 15 bis 30 Minuten, als Rollback-Ziel erreichbar, aber ohne Produktions-Traffic. Erst wenn Monitoring und Fehlerraten der neuen Farbe stabil sind, wird die alte Farbe heruntergefahren oder für das nächste Blue-Green-Deployment als neue inaktive Farbe wiederverwendet.

9. Blue-Green vs. Rolling Deployment bei Magento im Vergleich

Neben Blue-Green existieren weitere Deployment-Strategien für Magento, die je nach Team-Größe und Infrastruktur unterschiedlich gut passen. Die folgende Tabelle stellt die wichtigsten Unterschiede gegenüber.

Für Magento-Shops mit hohem Umsatz pro Stunde überwiegt bei einem Blue-Green-Deployment der Vorteil des sofortigen Rollbacks den höheren Ressourcenbedarf während des Switch-Fensters. Für kleinere Shops mit engem Infrastruktur-Budget ist ein Rolling Deployment mit denselben Indexer- und Migrationsregeln oft die pragmatischere Wahl.

10. Zusammenfassung

Ein funktionierendes Blue-Green-Deployment für Magento unterscheidet sich deutlich von einem generischen Blue-Green-Setup für zustandslose Anwendungen. Indexer müssen auf der inaktiven Farbe vollständig durchgelaufen sein, bevor Traffic wechselt, Static Content und generierter Code dürfen nie geteilt werden, und Datenbank-Migrationen müssen über mindestens zwei Releases hinweg additiv und abwärtskompatibel bleiben, weil beide Farben dieselbe Datenbank nutzen.

Ein mehrstufiger Health Check, der Datenbank, Redis, OpenSearch und Indexer-Status prüft, ist das Readiness Gate, das entscheidet, wann der Farbwechsel tatsächlich sicher ist. Mit dieser Kombination aus geteilter Datenschicht, additiven Migrationen und automatisierten Readiness-Prüfungen wird ein Blue-Green-Deployment bei Magento zu einer verlässlichen, wiederholbaren Routine statt zu einem riskanten Sonderereignis.

11. FAQ: Magento Blue Green Deployments mit Containern