Freitag 17:00 Uhr, dringende Bereitstellung: „pm2 restart api“. Dreißig Sekunden lang zeigt das externe Probe 502s an, der Support ist untergetaucht und ein Partner startet seine Webhooks in einer Schleife neu. Am Montagmorgen hat jemand „pm2 reload api“ im Cluster-Modus getestet: gleiche Version, gleicher Code – und die Probe hat keine Unterbrechungen festgestellt.
PM2 ist nicht nur ein Daemon „für die Ausführung von Node.js“. Es handelt sich um einen Prozess-Orchestrator mit präziser Neustartsemantik. Das verwirrende Neustarten und Neuladen in der Produktion bedeutet, dass man sich jedes Mal, wenn man es online stellt, freiwillig für einen Mikroschnitt entscheidet.
Ecosystem.config.js: die Basis einer sauberen Bereitstellung
Eine versionierte Datei „ecosystem.config.js“ verhindert, dass Ad-hoc-Befehle beim nächsten Start vergessen werden. Hier ist eine Startkonfiguration für eine Node.js-API in der Produktion:
„Javascript module.exports = { Apps: [{ Name: 'api', Skript: './dist/server.js', Instanzen: 'max', exec_mode: 'cluster', wait_ready: wahr, listen_timeout: 10000, kill_timeout: 5000, max_memory_restart: '600M', env_produktion: { NODE_ENV: 'Produktion', VERSAND: 3000, }, }], };
Wenn Sie „wait_ready: true“ aktivieren, sollte die Anwendung ihre Verfügbarkeit mit „process.send('ready“) melden, sobald der HTTP-Server bereit ist, Datenverkehr zu empfangen. Der Parameter „kill_timeout“ definiert die Zeit, die Workern zur Verfügung steht, um laufende Anforderungen abzuschließen, bevor ein erzwungenes Herunterfahren erfolgt.
> Ein zu kurzes „kill_timeout“ verwandelt ein ordnungsgemäßes Neuladen in einen getarnten Neustart.
## Ordentliches Herunterfahren: Was PM2 nicht für Sie tun kann
PM2 kann warten – aber nur, wenn Ihr Code weiß, wie er sauber beendet wird. Ohne einen SIGINT- oder SIGTERM-Manager sehen Neuladen und Neustart gleich aus: Verbindungen werden mitten in der Verarbeitung unterbrochen.
„Javascript
process.on('SIGINT', () => {
server.close(() => process.exit(0));
setTimeout(() => process.exit(1), 8000).unref();
});
Denken Sie auch daran, den Datenbankverbindungspool zu schließen, die Protokollpuffer zu leeren und die Warteschlangenkonsumenten zu stoppen. Für WebSockets gibt es zwei Optionen: Clients benachrichtigen, dass sie die Verbindung wiederherstellen müssen, oder aktive Verbindungen vor dem Herunterfahren entladen.
Empfohlener Bereitstellungsworkflow
Eine nahtlose Bereitstellung folgt normalerweise dieser Reihenfolge:
- Rufen Sie die Version ab (Git Pull oder Atomic Symlink Toggle).
- Installieren Sie Abhängigkeiten mit „npm ci --produktion“.
- Führen Sie „pm2 reload Ecosystem.config.js --env Production --update-env“ aus.
- Speichern Sie die Konfiguration mit „pm2 save“, damit sie einen Serverneustart übersteht.
- Führen Sie einen Rauchtest auf dem Gesundheitsendpunkt durch.
Für ein Rollback verweisen Sie den Symlink erneut auf das vorherige Artefakt und starten einen Neuladevorgang. Vermeiden Sie „pm2 delete“ gefolgt von einem Start, außer während der ersten Installation: Sie verlieren den Verlauf der Metriken und Neustarts.
Nginx vor PM2: Rollenverteilung
In der Produktion beendet Nginx TLS und leitet dynamischen Datenverkehr an PM2 weiter:
„Nginx Proxy_Pass http://127.0.0.1:3000; Proxy_http_version 1.1;
Richten Sie die Nginx-Timeouts („proxy_read_timeout“, „proxy_connect_timeout“) an PM2 „kill_timeout“ aus. Informationen zu WebSockets finden Sie in unserem Leitfaden zu [Echtzeit mit WebSocket](/de/blog/websocket-realtime/).
Konfigurieren Sie auf einem VPS „pm2 Startup Systemd“ mit einem Nicht-Root-Benutzer. Bemessen Sie den Arbeitsspeicher basierend auf der Anzahl der Worker und dem maximalen Speicherverbrauch pro Instanz. Bei einem PaaS vom Typ Heroku verwaltet die Plattform oft den Prozesslebenszyklus: PM2 bleibt besonders relevant beim Selbsthosting auf VPS oder Bare Metal.
## Der Gipfel: PM2 verbirgt die Abwesenheit von Graceful – bis zum Nachladen
:::Höhepunkt
**Das Ausführen von „pm2 start“ in der Produktion ohne einen SIGTERM-Handler ist ein falsches Gefühl von Robustheit: Neustart und Neuladen machen dasselbe.** PM2 ersetzt keinen Code, der weiß, wie er beendet werden muss – es gibt ihm nur Zeit dafür, wenn Sie ihn vor Freitagabend schreiben und testen.
:::
Testen Sie vor jeder Zusammenführung in die Produktion SIGINT und SIGTERM lokal und führen Sie dann beim Staging einen Neuladevorgang durch. Es ist der Unterschied zwischen einer unsichtbaren Bereitstellung und einer halben Minute 502, gemessen von Ihren Kunden.
## Entscheide dich und gehe ohne blinden Fleck voran
Innerhalb eines halben Tages können Sie Ihre Node.js-Bereitstellungen sichern:
1. **Gehen Sie in den Cluster-Modus**, wenn Ihre HTTP-API zustandslos ist, und ersetzen Sie „restart“ durch „reload“ in allen Ihren Bereitstellungsskripts.
2. **Implementieren und testen** SIGINT/SIGTERM-Handler – Serverschließung, Datenbankpool, Warteschlangenkonsumenten.
3. **Version** einer vollständigen „ecosystem.config.js“ mit Produktionsumgebungsvariablen und Speicherbeschränkungen.
4. **Setzen Sie nginx** vor PM2 für TLS, statische Dateien und Ratenbegrenzung.
5. **Überwachen** Sie die Anzahl der Neustarts und die Latenz der Ereignisschleife, um Speicherlecks zu erkennen, bevor sie einen automatischen Neustart auslösen.
Weitere Informationen zu Node.js-Speicherlecks finden Sie unter [Node.js-Speicherleck](/de/blog/nodejs-memory-leak/). Um Hosts zu vergleichen, die für die VPS-Bereitstellung geeignet sind, durchsuchen Sie unser [Verzeichnis](/de/verzeichnis/).
## Häufig gestellte Fragen
### Unterschied zwischen PM2-Neustart und PM2-Neuladen?
Der Neustart stoppt plötzlich und startet dann neu – garantiertes Herunterfahren. reload sendet ein ordnungsgemäßes Herunterfahren, wartet auf den Abschluss der aktuellen Anforderungen und startet dann die Worker nacheinander im Cluster-Modus neu. In der Produktion ist Neuladen die Standardauswahl.
### Wann sollte der Cluster-Modus verwendet werden?
Immer wenn eine zustandslose HTTP-Anwendung mehrere CPU-Kerne nutzen muss. Beschränken Sie sich auf einen Arbeiter pro Kern. Fügen Sie für WebSockets eine persistente Sitzung oder einen Redis-Adapter hinzu, der von den Workern gemeinsam genutzt wird.
### Reicht PM2 ohne Nginx?
Es ist möglich, aber Nginx wird dennoch für TLS-Verschlüsselung, statische Dateibereitstellung und Missbrauchsschutz empfohlen. PM2 überwacht den Anwendungsport. Nginx übernimmt den öffentlichen Reverse-Proxy.
### Wie verwalte ich Umgebungsvariablen in der Bereitstellung?
Zentralisieren Sie die Konfiguration in einer versionierten „ecosystem.config.js“ und verwenden Sie „--update-env“ beim Neuladen. Geheimnisse bleiben außerhalb von Git – Datei auf dem Server oder im dedizierten Tresor.
---
PM2 in der Produktion wird mit ordnungsgemäßem Herunterfahren neu geladen – nicht neu gestartet, solange Benutzer noch verbunden sind.