Zero-Downtime-Deployment von JavaScript-Diensten: So bringen Sie die Produktion nicht zum Absturz

Online Python-Trainer für Anfänger

Lernen Sie Python einfach ohne theoretische Überlastung. Lösen Sie praktische Aufgaben mit automatischer Überprüfung und schreiben Sie Code direkt im Browser.

Kurs starten

Zero-Downtime-Deployment: Warum ist es für Ihren JavaScript-Dienst kritisch?

\n\n

Stellen Sie sich vor: Freitagabend, Sie deployen eine neue Funktion auf Node.js – und eine Minute später flattern panische Nachrichten in den Support-Chat: „Die Seite ist down!“, „500 Fehler!“, „Daten sind weg!“ Kommt Ihnen das bekannt vor? Wenn Ihr JavaScript-Dienst während des Updates nicht mehr antwortet, verlieren Sie nicht nur Nutzer, sondern auch Geld und Ihren Ruf.

\n\n

Zero-Downtime-Deployment (ausfallfreies Deployment) ist ein Ansatz, bei dem die Codeaktualisierung für den Benutzer unbemerkt erfolgt. Alle Anfragen werden bearbeitet, Verbindungen werden nicht unterbrochen, und der neue Code wird nahtlos in Betrieb genommen. Für Node.js, wo alles auf Asynchronität und Ereignissen basiert, ist dies besonders wichtig: Eine einzige abrupte Unterbrechung kann zu Speicherlecks oder nicht behandelten Promises führen.

\n\n

In diesem Artikel zeige ich Ihnen, wie Sie ein nahtloses Deployment von JavaScript-Diensten in der Praxis einrichten. Wir werden drei funktionierende Strategien durchgehen – Rolling Update, Blue-Green Deployment und Graceful Shutdown – mit echten Codebeispielen. Los geht's!

\n\n

Strategie 1: Rolling Update – Aktualisierung ohne Unterbrechung

\n\n

Rolling Update (schrittweise Aktualisierung) ist die beliebteste Technik in der Node.js-Welt. Die Idee ist einfach: Sie haben mehrere Instanzen Ihrer Anwendung am Laufen und aktualisieren diese eine nach der anderen. Während eine neu startet, nehmen die anderen weiterhin Traffic an.

\n\n

Wie es in der Praxis funktioniert

Angenommen, Sie haben 4 Node.js-Prozesse, die über PM2 (einen beliebten Prozessmanager) laufen. Der Befehl pm2 reload app führt automatisch einen Rolling Restart durch: Er beendet einen Prozess nach dem anderen und startet den neuen Code. Damit dies jedoch fehlerfrei funktioniert, muss ein Graceful Shutdown korrekt konfiguriert sein (dazu später mehr).

\n\n

Beispiel für die PM2-Konfiguration für Zero-Downtime

Erstellen Sie eine Datei ecosystem.config.js im Projektstammverzeichnis:

\n\n

module.exports = {\n  apps: [{\n    name: 'my-javascript-service',\n    script: './server.js',\n    instances: 4,                // 4 Instanzen\n    exec_mode: 'cluster',       // Cluster-Modus\n    wait_ready: true,           // Auf ready-Signal warten\n    listen_timeout: 5000,       // Timeout für Bereitschaft\n    kill_timeout: 5000,         // Timeout für Beendigung\n    max_restarts: 10,\n    env: {\n      NODE_ENV: 'production'\n    }\n  }]\n};\n

\n\n

Fügen Sie im Server-Code (server.js) die Signalverarbeitung hinzu:

\n\n

const http = require('http');\nconst app = require('./app'); // Ihre Express/Koa-Anwendung\n\nconst server = http.createServer(app);\nconst PORT = process.env.PORT || 3000;\n\nserver.listen(PORT, () => {\n  console.log(`Server läuft auf Port ${PORT}`);\n  // PM2 signalisieren, dass der Prozess bereit ist\n  if (process.send) {\n    process.send('ready');\n  }\n});\n\n// Graceful Shutdown\nprocess.on('SIGINT', () => {\n  console.log('SIGINT empfangen, starte Graceful Shutdown...');\n  server.close(() => {\n    console.log('HTTP-Server geschlossen');\n    process.exit(0);\n  });\n});\n\nprocess.on('SIGTERM', () => {\n  console.log('SIGTERM empfangen, beende...');\n  server.close(() => {\n    console.log('HTTP-Server geschlossen');\n    process.exit(0);\n  });\n});\n

\n\n

Wenn Sie nun pm2 reload ecosystem.config.js ausführen, stoppt und startet PM2 die Instanzen nacheinander und wartet auf das ready-Signal. Die Benutzer bemerken den Wechsel nicht.

\n\n

Vor- und Nachteile von Rolling Update

+ Erfordert keine zusätzlichen Server oder Proxys.
+ Einfach über PM2 oder Kubernetes konfigurierbar.
- Enthält der neue Code einen kritischen Fehler, könnte eine „schlechte“ Instanz einige Anfragen verarbeiten.
- Erfordert eine sorgfältige Verwaltung des Zustands (Datenbanken, Cache).

\n\n