Rolling Updates im Docker Swarm ohne Downtime

1. Was ein Rolling Update im Swarm Modus konkret macht

Ein Rolling Update ersetzt die Container eines Services schrittweise durch eine neue Version, statt alle Instanzen gleichzeitig zu stoppen und neu zu starten. Docker Swarm steuert diesen Prozess über die im Service definierte Update Strategie: Ein konfigurierbarer Batch von Containern wird beendet, durch neue Instanzen mit dem aktualisierten Image ersetzt, und erst nach einer Wartezeit wird der nächste Batch angefasst. Während dieses Prozesses bleiben die verbleibenden, noch nicht aktualisierten Container weiterhin erreichbar und bedienen Anfragen.

Der entscheidende Vorteil eines Rolling Updates gegenüber einem kompletten Neustart aller Container ist die kontinuierliche Verfügbarkeit des Services während des gesamten Deployments. Für einen Online Shop mit mehreren Replikaten bedeutet das: Während zwei von vier Containern gerade aktualisiert werden, bedienen die anderen beiden weiterhin Kundenanfragen. Erst wenn alle Batches erfolgreich durchlaufen sind, gilt das Rolling Update als abgeschlossen, und die Anwendung läuft vollständig auf der neuen Version.

2. Die update_config Sektion im Detail

Die Steuerung eines Rolling Updates erfolgt über die update_config Sektion im deploy Block der Compose Datei. Der Parameter parallelism legt fest, wie viele Container gleichzeitig in einem Batch aktualisiert werden. Ein Wert von 1 aktualisiert Container nacheinander und ist am sichersten, aber auch am langsamsten. Ein höherer Wert beschleunigt das Update, erhöht aber das Risiko, dass ein fehlerhaftes Image mehrere Instanzen gleichzeitig betrifft, bevor der Fehler bemerkt wird.

Der Parameter delay definiert die Wartezeit zwischen zwei Batches und gibt neuen Containern Zeit, vollständig hochzufahren und ihre Healthchecks zu bestehen, bevor der nächste Batch gestartet wird. Eine zu kurze Verzögerung kann dazu führen, dass mehrere Batches parallel laufen, obwohl der vorherige noch nicht stabil ist. Für Anwendungen mit langsamem Start, etwa PHP Anwendungen mit OPcache Warmup, sollte delay großzügig genug gewählt werden, um dem neuen Container ausreichend Zeit zu geben.

# docker-compose.prod.yml — rolling update configuration
version: "3.9"

services:
  api:
    image: registry.example.com/shop-api:1.5.0
    networks:
      - backend
    deploy:
      replicas: 6
      update_config:
        parallelism: 2        # update 2 containers at a time
        delay: 15s             # wait 15s between batches
        order: start-first     # start new container before stopping old one
        failure_action: rollback
        monitor: 30s            # observe new container for 30s before continuing
        max_failure_ratio: 0.2  # tolerate up to 20% failed tasks per batch
      rollback_config:
        parallelism: 2
        delay: 10s
        order: stop-first

networks:
  backend:
    driver: overlay

3. Healthchecks als Voraussetzung für sichere Updates

Ohne einen konfigurierten Healthcheck kann Docker Swarm nicht zuverlässig erkennen, ob ein neu gestarteter Container tatsächlich funktionsfähig ist. Ein Container, der zwar läuft, aber intern abstürzt, weil eine Datenbankverbindung fehlschlägt, wird ohne Healthcheck trotzdem als erfolgreich gewertet, solange der Hauptprozess weiterläuft. Für ein zuverlässiges Rolling Update ist ein Healthcheck deshalb keine Kür, sondern die Grundvoraussetzung, damit Docker den tatsächlichen Anwendungszustand statt nur den Prozessstatus beurteilen kann.

Ein guter Healthcheck prüft nicht nur, ob ein Prozess läuft, sondern ob die Anwendung tatsächlich Anfragen korrekt beantworten kann, etwa über einen dedizierten /health Endpunkt, der Datenbankverbindung und kritische Abhängigkeiten prüft. Der start_period Parameter gibt dem Container Zeit für den initialen Start, bevor fehlgeschlagene Healthchecks als kritisch gewertet werden, was besonders bei Anwendungen mit längerer Boot Zeit wichtig ist, um falsche Alarme während des normalen Hochfahrens zu vermeiden.

# Healthcheck configuration inside the Dockerfile or compose file
services:
  api:
    image: registry.example.com/shop-api:1.5.0
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8080/health"]
      interval: 10s
      timeout: 5s
      retries: 3
      start_period: 20s   # grace period during application boot

4. Automatisches Rollback bei fehlgeschlagenen Updates

Der Parameter failure_action: rollback in der update_config aktiviert ein automatisches Rollback, sobald der Anteil fehlgeschlagener Tasks während eines Rolling Updates den in max_failure_ratio definierten Schwellenwert überschreitet. Docker Swarm beendet in diesem Fall das laufende Update sofort und stellt die vorherige, funktionierende Version wieder her, ohne dass ein Mensch manuell eingreifen muss. Diese Automatisierung ist besonders wertvoll außerhalb der Bürozeiten, wenn ein CI Pipeline Deployment fehlschlägt und niemand sofort reagieren kann.

Der monitor Parameter legt fest, wie lange ein neu gestarteter Container nach dem Update beobachtet wird, bevor er als endgültig stabil gilt. Stürzt ein Container innerhalb dieser Beobachtungszeit ab, wertet Docker Swarm den Batch als fehlgeschlagen und zählt ihn gegen max_failure_ratio. Diese Kombination aus Monitoring Zeitraum und Fehlerquote gibt Teams die Kontrolle darüber, wie tolerant oder streng das Rolling Update auf einzelne Probleme reagiert, ohne bei jedem kleinen Ausreißer sofort das gesamte Deployment abzubrechen.

# Trigger a rolling update by changing the image tag
docker service update --image registry.example.com/shop-api:1.5.0 shop_api

# Manually trigger a rollback to the previous version if needed
docker service rollback shop_api

# Check whether the last update completed or rolled back
docker service inspect shop_api --format '{{.UpdateStatus.State}}'

5. Update Order: start first gegen stop first

Der Parameter order bestimmt, ob ein neuer Container vor dem Stoppen des alten gestartet wird (start-first) oder ob der alte Container zuerst gestoppt wird, bevor der neue startet (stop-first, der Standardwert). start-first maximiert die Verfügbarkeit während des Rolling Updates, weil kurzzeitig mehr Container laufen als die konfigurierte Replika Anzahl, verlangt aber, dass die Anwendung mit zwei parallel laufenden Versionen umgehen kann, etwa bei Datenbankschemas, die noch nicht final migriert sind.

Für die meisten zustandslosen Web Anwendungen ist start-first die bessere Wahl, weil es Downtime durch Kapazitätsengpässe während des Updates vermeidet. stop-first eignet sich dagegen für Services mit begrenzten Ressourcen, bei denen nicht genug Kapazität für parallel laufende alte und neue Versionen vorhanden ist, etwa bei Services mit exklusivem Zugriff auf einen einzelnen externen Port ohne Routing Mesh Unterstützung.

6. Rolling Updates bei Datenbank Migrationen

Ein Rolling Update wird deutlich komplexer, wenn ein Deployment eine Datenbankschema Änderung enthält. Während des Updates laufen kurzzeitig sowohl die alte als auch die neue Anwendungsversion parallel, beide greifen aber auf dieselbe Datenbank zu. Eine Migration, die eine Spalte umbenennt oder löscht, bricht die alte Anwendungsversion, solange sie noch aktiv ist. Der bewährte Ansatz teilt Schema Änderungen in mehrere, abwärtskompatible Schritte auf, statt eine einzige, brechende Migration mit dem Anwendungscode zu koppeln.

Praktisch bedeutet das: Eine neue Spalte wird zuerst hinzugefügt und optional befüllt, in einem zweiten Deployment nutzt der Anwendungscode die neue Spalte, und erst in einem dritten, späteren Deployment wird die alte Spalte entfernt, nachdem sichergestellt ist, dass keine alte Anwendungsversion mehr darauf zugreift. Dieses Muster, oft als Expand Contract Pattern bezeichnet, macht Rolling Updates auch bei Datenbankänderungen sicher, verlangt aber Disziplin bei der Aufteilung von Migrationen in kompatible Zwischenschritte.

7. Rollout live beobachten und verifizieren

Während ein Rolling Update läuft, liefert docker service ps eine Live Übersicht über alle Tasks, inklusive neu gestarteter und beendeter alter Instanzen. Die Spalte CURRENT STATE zeigt den Fortschritt jedes einzelnen Tasks, von Starting über Running bis zu Shutdown für die abgelösten alten Container. Diese Übersicht ist der zuverlässigste Weg, um in Echtzeit zu verfolgen, ob das Update planmäßig voranschreitet oder an einer bestimmten Stelle hängen bleibt.

docker service inspect --format '{{.UpdateStatus.State}}' liefert einen kompakten Statuswert wie updating, completed oder rollback_completed, der sich hervorragend für automatisierte Prüfungen in CI Pipelines eignet. Ein Deployment Skript kann diesen Wert in einer Schleife abfragen und erst dann als erfolgreich melden, wenn der Status completed erreicht ist, statt blind davon auszugehen, dass ein Rolling Update sofort nach dem Absetzen des Befehls fertig ist.

# Poll update status until it completes or fails, useful in CI pipelines
until [ "$(docker service inspect shop_api --format '{{.UpdateStatus.State}}')" = "completed" ]; do
  state=$(docker service inspect shop_api --format '{{.UpdateStatus.State}}')
  if [ "$state" = "rollback_completed" ]; then
    echo "Update failed and rolled back" >&2
    exit 1
  fi
  sleep 3
done
echo "Rolling update completed successfully"

8. Typische Stolperfallen bei Rolling Updates

Der häufigste Fehler ist das komplette Fehlen eines Healthchecks, wodurch Docker Swarm einen abstürzenden Container als erfolgreich gestartet betrachtet, solange der Prozess technisch noch läuft. Ohne Healthcheck kann ein Rolling Update theoretisch erfolgreich abgeschlossen werden, obwohl die neue Version in Wahrheit fehlerhaft ist und keine echten Anfragen beantwortet. Diese Lücke bleibt oft unbemerkt, bis Nutzer Fehler melden, weil die Docker CLI selbst keinen Alarm auslöst.

Ein zweiter häufiger Fehler ist eine zu kurze delay Zeit in Kombination mit langsam startenden Anwendungen. Startet die Anwendung zehn Sekunden, aber delay ist auf fünf Sekunden gesetzt, beginnt der nächste Batch, bevor der vorherige tatsächlich stabil läuft, was zu kaskadierenden Fehlern führen kann, wenn ein zugrunde liegendes Problem alle neuen Container gleichermaßen betrifft. Die Kombination aus großzügigem delay, korrektem start_period im Healthcheck und aktiviertem automatischem Rollback deckt die meisten dieser Fälle zuverlässig ab.

9. Update Strategien im direkten Vergleich

Die folgende Tabelle vergleicht die wichtigsten Konfigurationsoptionen für Rolling Updates und ihre Auswirkung auf Geschwindigkeit und Sicherheit des Deployments.

In der Praxis bewährt sich eine Kombination aus moderater Parallelität, start-first Order für zustandslose Services und aktiviertem automatischem Rollback als solide Grundeinstellung, die für die meisten Anwendungen ohne weitere Anpassung funktioniert.

10. Zusammenfassung

Rolling Updates im Docker Swarm ermöglichen kontinuierliche Verfügbarkeit während Deployments, vorausgesetzt Parallelität, Delay, Healthchecks und Rollback Regeln sind korrekt konfiguriert. Die update_config Sektion steuert, wie viele Container gleichzeitig aktualisiert werden und wie lange zwischen Batches gewartet wird, während failure_action: rollback automatisch die vorherige Version wiederherstellt, sobald zu viele Tasks fehlschlagen.

Ein aussagekräftiger Healthcheck ist die Grundvoraussetzung dafür, dass Docker Swarm den tatsächlichen Anwendungszustand statt nur den Prozessstatus beurteilt. In Kombination mit dem Expand Contract Pattern für Datenbankmigrationen und einer durchdachten Update Order lassen sich Rolling Updates auch für komplexere Anwendungen sicher und ohne spürbaren Ausfall automatisieren.

11. FAQ: Rolling Updates im Docker Swarm