PM2 in productie: start Node.js opnieuw zonder verzoeken te knippen

Vrijdag 17.00 uur, urgente inzet: pm2 restart api. Dertig seconden lang geeft de externe sonde 502's weer, de steun wordt ondergedompeld en een partner herstart zijn webhooks in een lus. Maandagochtend testte iemand pm2 reload api in clustermodus: dezelfde versie, dezelfde code – en de test detecteerde geen enkele onderbreking.

PM2 is niet alleen een daemon “die Node.js moet uitvoeren”. Het is een procesorkestrator met nauwkeurige herstartsemantiek. Het verwarren van herstarten en herladen in de productie betekent dat je elke keer dat je het online zet, vrijwillig een micro-cut kiest.

ecosysteem.config.js: de basis van een schone implementatie

Een ecosystem.config.js-bestand met versiebeheer voorkomt dat ad-hocopdrachten worden vergeten bij de volgende start. Hier is een startconfiguratie voor een Node.js API in productie:

module.exports = {

  apps: [{

    naam: 'api',

    script: './dist/server.js',

    instanties: 'max',

    exec_mode: 'cluster',

    wait_ready: waar,

    luister_timeout: 10000,

    kill_timeout: 5000,

    max_memory_restart: '600M',

    env_productie: {

      NODE_ENV: 'productie',

      VERZENDING: 3000,

    },

  }],

};

Als u wait_ready: true inschakelt, moet de applicatie de beschikbaarheid ervan rapporteren met process.send('ready') zodra de HTTP-server klaar is om verkeer te ontvangen. De parameter kill_timeout definieert de tijd die werknemers hebben om lopende aanvragen te voltooien voordat ze geforceerd worden afgesloten.

Een kill_timeout die te kort is, verandert een sierlijke herlaadbeurt in een verkapte herstart.

Sierlijke afsluiting: wat PM2 niet voor u zal doen

PM2 kan wachten, maar alleen als uw code weet hoe hij netjes moet afsluiten. Zonder een SIGINT- of SIGTERM-manager zien herladen en opnieuw opstarten er hetzelfde uit: verbindingen worden midden in de verwerking verbroken.

process.on('SIGINT', () => {

  server.close(() => proces.exit(0));

  setTimeout(() => proces.exit(1), 8000).unref();

});

Vergeet ook niet om de databaseverbindingspool te sluiten, de logbuffers leeg te maken en de wachtrijconsumenten te stoppen. Voor WebSockets zijn er twee opties: clients op de hoogte stellen dat ze opnieuw verbinding moeten maken, of actieve verbindingen verbreken voordat ze worden afgesloten.

Aanbevolen implementatieworkflow

Een naadloze implementatie volgt doorgaans deze volgorde:

1. Haal de release op (Git pull of atomic symlink toggle).
2. Installeer afhankelijkheden met npm ci --production.
3. Voer pm2 reload ecosystem.config.js --env production --update-env uit.
4. Sla de configuratie op met pm2 save zodat deze een herstart van de server overleeft.
5. Voer een rooktest uit op het gezondheidseindpunt.

Voor een rollback verwijst u de symlink naar het vorige artefact en start u het opnieuw laden. Vermijd pm2 delete gevolgd door een start, behalve tijdens de eerste installatie: u verliest de geschiedenis van de statistieken en het opnieuw opstarten.

Nginx voor PM2: rolverdeling

In productie beëindigt nginx TLS en stuurt dynamisch verkeer door naar PM2:

proxy_pass http://127.0.0.1:3000;

proxy_http_versie 1.1;

Lijn de nginx-time-outs (proxy_read_timeout, proxy_connect_timeout) uit met de PM2 kill_timeout. Voor WebSockets raadpleegt u onze handleiding voor realtime met WebSocket.

Op een VPS configureer je pm2 startup systemd met een niet-rootgebruiker. Grootte van het RAM-geheugen op basis van het aantal werkrollen en het maximale geheugengebruik per exemplaar. Op een PaaS van het Heroku-type beheert het platform vaak de proceslevenscyclus: PM2 blijft vooral relevant bij zelfhosting op VPS of bare metal.

De top: PM2 verbergt de afwezigheid van sierlijk — tot herladen

Test SIGINT en SIGTERM vóór elke samenvoeging in productie lokaal en voer vervolgens een herlaadbeurt uit tijdens de staging. Dat is het verschil tussen een onzichtbare implementatie en een halve minuut 502's gemeten door uw klanten.

Beslis en ga vooruit zonder blinde vlek

Gedurende een halve dag kunt u uw Node.js-implementaties beveiligen:

1. Ga naar de clustermodus als uw HTTP API staatloos is, en vervang restart door reload in al uw implementatiescripts.
2. Implementeren en testen SIGINT/SIGTERM-handlers: serversluiting, databasepool, wachtrijconsumenten.
3. Versie een compleet ecosystem.config.js met productieomgevingsvariabelen en geheugenlimieten.
4. Zet nginx vóór PM2 voor TLS, statische bestanden en snelheidsbeperking.
5. Bewaak het aantal herstarts en de latentie van de gebeurtenislus om geheugenlekken te detecteren voordat deze een automatische herstart activeren.

Voor meer informatie over geheugenlekken in Node.js, zie Node.js memory lek. Om hosts te vergelijken die geschikt zijn voor VPS-implementatie, bladert u door onze overzicht.

Veelgestelde vragen

Verschil pm2 herstarten en pm2 herladen?

opnieuw opstarten stopt plotseling en start vervolgens opnieuw op - gegarandeerde uitschakeling. reload zorgt voor een correcte afsluiting, wacht tot de huidige verzoeken zijn voltooid en start vervolgens de werkrollen één voor één opnieuw op in de clustermodus. In productie is herladen de standaardkeuze.

Wanneer clustermodus gebruiken?

Wanneer een staatloze HTTP-applicatie meerdere CPU-kernen moet gebruiken. Beperk jezelf tot één werker per kern. Voeg voor WebSockets een permanente sessie of Redis-adapter toe die wordt gedeeld tussen werknemers.

Is PM2 genoeg zonder nginx?

Het is mogelijk, maar nginx wordt nog steeds aanbevolen voor TLS-codering, statische bestandsweergave en bescherming tegen misbruik. PM2 luistert naar de applicatiepoort; nginx doet de publieke reverse proxy.

Hoe beheer ik env-variabelen tijdens de implementatie?

Centraliseer de configuratie in een ecosystem.config.js met versiebeheer en gebruik --update-env bij het herladen. Geheimen blijven buiten Git: bestanden op de server of speciale kluis.

PM2 in productie wordt opnieuw geladen met een correcte afsluiting - niet opnieuw opstarten terwijl gebruikers nog steeds verbonden zijn.