Zero-Downtime Deployment (Unterbrechungsfreie Bereitstellung)

1. Konzeptüberblick und systemische Problematik

Das primitive Aktualisieren von Diensten durch Neustart des Prozesses (systemctl restart app oder docker restart container) führt zu technischer Downtime. Während der 5–30 Sekunden, in denen der neue Prozess die Laufzeitumgebung initialisiert, sich mit Datenbanken verbindet und JIT-Code kompiliert:

• Alle aktuellen aktiven HTTP-Anfragen werden mitten in der Datenübertragung abgebrochen.
• Der Load Balancer oder Reverse Proxy liefert Benutzern Fehlermeldungen wie 502 Bad Gateway oder 504 Gateway Timeout.
• Benutzertransaktionen (Zahlungen, Statusspeicherung, LLM-Generierung) verbleiben in einem halbzerstörten Zustand.

Zero-Downtime Deployment (Unterbrechungsfreie Bereitstellung) eliminiert Downtime durch die Orchestrierung des Prozesslebenszyklus. Die neue Version der Anwendung wird parallel zur alten gestartet. Der Traffic wird erst umgeschaltet, nachdem die neue Instanz erfolgreich auf Health Check-Proben geantwortet hat und die alte Instanz alle begonnenen Operationen im Modus Graceful Shutdown korrekt abgeschlossen hat.

Фаза 1: Активна версія v1.0
[Клієнти] ---> [Reverse Proxy / Nginx] ---> [Container v1.0 (Active)]

Фаза 2: Запуск v1.1 та Healthcheck
[Клієнти] ---> [Reverse Proxy / Nginx] ---> [Container v1.0 (Active)]
                                             [Container v1.1 (Starting... /healthz: 200 OK)]

Фаза 3: Перемикання трафіку та Graceful Shutdown v1.0
[Клієнти] ---> [Reverse Proxy / Nginx] ---> [Container v1.1 (Active)]
                                       \---> [Container v1.0 (Finishing active requests... SIGTERM)]

Фаза 4: Завершення (v1.0 вимкнено)
[Клієнти] ---> [Reverse Proxy / Nginx] ---> [Container v1.1 (Active)]

2. Architektonische Taxonomie und mentales Modell

Strategien für unterbrechungsfreie Updates:

1. Blue/Green Deployment:
   • Vollständige Verdopplung der Infrastrukturschicht.
   • Sofortiges atomares Umschalten des Traffics auf Ebene von Nginx, Traefik oder DNS/ALB.
   • Höchste Zuverlässigkeit, einfachster Rollback, erfordert jedoch doppelte Reserve an Arbeitsspeicher und Host-Ressourcen.
2. Rolling Update (Schrittweises rollierendes Update):
   • Container werden nacheinander einzeln oder in Gruppen aktualisiert.
   • Konstante Cluster-Kapazität wird beibehalten (z. B. mindestens 3 aktive Replikate von 4).
   • Ressourceneinsparung bei Hardware, Standardverfahren in Kubernetes und Docker Swarm.
3. Canary Release (Kanari-Bereitstellung):
   • Die neue Version erhält einen festen Mikro-Prozentsatz des echten Traffics (z. B. 2–5 %) oder Benutzer einer bestimmten internen Gruppe.
   • Systemmetriken (Error Rate, Latency) werden überwacht. Wenn keine Anomalien festgestellt werden, wird der Traffic-Anteil schrittweise auf 100 % erhöht.

3. Technisches Pipeline und interne Mechanik

Implementierung von Graceful Shutdown in Node.js / TypeScript

Der Prozess muss die Betriebssystem-Signale SIGTERM und SIGINT korrekt abfangen:

import express from "express";
import http from "http";

const app = express();
let isShuttingDown = false;

// Healthcheck ендпоінт для оркестратора
app.get("/healthz", (req, res) => {
  if (isShuttingDown) {
    // Сигнал балансувальнику не направляти сюди нові запити
    return res.status(503).json({ status: "shutting_down" });
  }
  return res.status(200).json({ status: "healthy" });
});

const server = http.createServer(app);
server.listen(3000);

// Перехоплення сигналу завершення від Docker / systemd
process.on("SIGTERM", () => {
  console.log("SIGTERM received. Starting graceful shutdown...");
  isShuttingDown = true;

  // 1. Припиняємо прийом нових HTTP-з'єднань
  server.close(async () => {
    console.log("Closed all remaining HTTP connections.");

    try {
      // 2. Закриваємо пули з'єднань з базами даних та Redis
      await dbPool.end();
      await redisClient.quit();
      console.log("Infrastructure connections closed. Exiting process.");
      process.exit(0);
    } catch (err) {
      console.error("Error during teardown:", err);
      process.exit(1);
    }
  });

  // 3. Запобіжник (Fail-safe): примусове завершення при зависанні сокетів
  setTimeout(() => {
    console.error("Forced termination: active connections timed out.");
    process.exit(1);
  }, 20000); // 20 секунд ліміту
});

Docker Compose Healthcheck-Konfiguration

Um das Traffic-Umschalten durch den Orchestrator sicherzustellen, wird der Parameter für die Integritätsprüfung konfiguriert:

services:
  api:
    image: my-company/api:v1.2.0
    restart: always
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:3000/healthz"]
      interval: 5s
      timeout: 3s
      retries: 3
      start_period: 10s
    stop_grace_period: 30s # Час на виконання Graceful Shutdown

4. Praktische Engineering-Szenarien in der Produktion

01. Bereitstellung über Coolify ohne Traffic-Unterbrechung

Die Plattform Coolify nutzt den integrierten Reverse Proxy Traefik. Beim Drücken von Deploy baut sie ein neues Docker-Image, startet einen neuen Container auf einem zufälligen Port, fragt dessen Healthcheck-Endpunkt ab und stellt erst nach Bestätigung der Betriebsbereitschaft die Traefik-Routing-Tabelle „on the fly“ um, bevor sie das Signal SIGTERM an die alte Replik sendet.

02. Nginx Hot Configuration Reload (nginx -s reload)

Beim Aktualisieren von SSL-Zertifikaten oder Hinzufügen neuer Upstream-Konfigurationen startet der Master-Prozess von Nginx einen neuen Satz Worker-Prozesse mit der neuen Konfiguration. Die alten Worker nehmen keine neuen Verbindungen mehr an, schließen die Übertragung aktiver Dateien für aktuelle Clients ab und liquidieren sich erst danach selbst, ohne dass ein einziges Paket verworfen wird.

03. Datenbank-Migrationsbereitstellung ohne Tabellensperren in PostgreSQL

Beim Hinzufügen von Indizes zu großen Tabellen (Millionen Zeilen) sperrt das standardmäßige CREATE INDEX die Tabelle für Schreibzugriffe (EXCLUSIVE LOCK), was zum Hängen der Abfrage-Warteschlange führt. Ingenieure nutzen die Option CREATE INDEX CONCURRENTLY, die den Index im Hintergrund ohne Blockierung paralleler Lese- und Schreiboperationen aufbaut.

5. Fallstricke, häufige Fehler und Sicherheit

1. Fehlender stop_grace_period in Docker: Standardmäßig gewährt Docker dem Container nur 10 Sekunden zur Verarbeitung von SIGTERM, bevor es das tödliche SIGKILL sendet (sofortiges Beenden des Prozesses). Wenn eine lange Anfrage an ein LLM oder ein Zahlungs-Webhook 12 Sekunden dauert, wird die Operation mit Datenbeschädigung abgebrochen. Erhöhen Sie das Limit auf 30–60 Sekunden.
2. Versionsinkompatibilität von Code und Datenbank: Der Versuch, eine Tabellenspalte umzubenennen (ALTER TABLE users RENAME COLUMN email TO contact_email), bricht sofort die alte Codeversion, die während des Deployments parallel läuft. Wenden Sie stets das Expand-and-Contract-Pattern in zwei separaten Releases an.
3. Falsch-positive Health Check-Endpunkte: Wenn der Endpunkt /healthz die Verfügbarkeit aller externen Drittanbieter-APIs prüft (z. B. OpenAI oder Twitter API) und diese vorübergehend verlangsamt sind, betrachtet der Orchestrator den eigenen Dienst als tot und gerät in eine endlose Restart-Schleife (CrashLoopBackOff / Healthcheck Storm), wodurch ein funktionierendes Produktionssystem zerstört wird. Die Liveness-Probe sollte ausschließlich den lokalen Prozess prüfen.