module.exports = {
apps: [{
name: "my-node-app",
script: "./dist/server.js",
instances: "max",
exec_mode: "cluster",
env_production: {
NODE_ENV: "production",
PORT: 3000
},
max_memory_restart: "800M",
error_file: "./logs/err.log",
out_file: "./logs/out.log",
merge_logs: true,
kill_timeout: 3000,
listen_timeout: 8000
}]
};Mulți pornesc aplicațiile de Node în producție cu un simplu pm2 start server.js și speră să fie bine. Am făcut și eu asta acum vreo opt ani, până când log-urile mi-au umplut tot discul pe un VPS de 10 euro și mi-au blocat baza de date. Dacă vrei să dormi liniștit noaptea, ai nevoie de un fișier ecosystem.config.js bine pus la punct.
Cluster mode și Graceful Reload fără downtime
Implicit, Node rulează pe un singur thread. Dacă ai un server cu 4 nuclee, folosești doar 25% din capacitate. Cu instances: "max" și exec_mode: "cluster", PM2 îți pornește câte o instanță pentru fiecare nucleu și face load balancing între ele direct în rețea.
La un proiect cu 15k utilizatori activi pe zi, trecerea la cluster mode ne-a scăzut timpul de răspuns la API-uri cu aproape 40%. Partea cea mai mișto? Poți face deploy-uri fără downtime folosind pm2 reload în loc de pm2 restart. Reload-ul repornește procesele pe rând. În timp ce instanța 1 se oprește și se actualizează, instanțele 2, 3 și 4 preiau tot traficul.
Pentru ca asta să funcționeze corect, aplicația ta trebuie să asculte de semnalul SIGINT pe care PM2 îl trimite la oprire. Închizi conexiunile la baza de date, oprești serverul HTTP și abia apoi lași procesul să moară. Am adăugat kill_timeout: 3000 în config ca să oferim procesului 3 secunde pentru acest cleanup înainte de a fi oprit forțat.
Trade-off: Cluster mode merge excelent doar dacă aplicația e complet stateless. Dacă ții sesiuni în memorie sau folosești WebSocket-uri fără un adaptor de Redis care să sincronizeze instanțele, utilizatorii tăi vor fi deconectați constant când nimeresc pe alt thread.
Protecția la OOM (Out of Memory) și log-urile care cresc la infinit
Node are prostul obicei să mănânce memorie dacă ai un leak mic pe undeva. Am avut un caz cu o librărie de PDF-uri care uita să elibereze bufferul din memorie. Ca să nu ne moară tot serverul în weekend, am setat max_memory_restart: '800M'. Când o instanță trece de 800MB, PM2 îi dă restart automat și curat, iar restul instanțelor din cluster preiau traficul fără ca utilizatorii să observe ceva.
Pe lângă memorie, log-urile standard din PM2 cresc la infinit dacă nu le controlezi. Pentru asta, trebuie să instalezi modulul de logrotate direct în sistem rulând pm2 install pm2-logrotate. În fișierul de configurare doar specifici unde să scrie log-urile de eroare și cele de output și activezi merge_logs: true ca să nu ai fișiere separate pentru fiecare thread din cluster.
Cum arată fișierul de configurare
Mai jos ai un template curat, gata de pus în producție. Salvează-l ca ecosystem.config.js în rădăcina proiectului tău și pornește-l cu pm2 start ecosystem.config.js.
Configurarea asta ne-a salvat de zeci de intervenții manuale la ore nepotrivite. PM2 este excelent pentru setup-uri pe VPS-uri clasice unde vrei performanță maximă fără overhead-ul de Docker.
Voi cum gestionați aplicațiile de Node în producție? Mergeți pe PM2 sau ați trecut complet pe containere în Kubernetes?