node-clusterprocess

Wrapper around Node.js' cluster module for zero-downtime deployment of Node.js Apps. By entrecode.

What is this and what does it do?

This module supports node's clustering to utilize multi-core systems. It can be used by basically any Node.js Application to enable zero-downtime deployments.

Usage

server.js:

require('node-clusterprocess').run('app.js', 'myApp');

This should be a separate Node.js script, and it should be specified as main executable in your project's package.json. When you start your Application, you will call node server.js from now on instead of node app.js.

Zero-Downtime Reloading

You can trigger zero-downtime reloads of your application by sending HUP:

kill -hup <pid>

… where <pid> should be the PID of the cluster process. Alternatively, you can use

pkill -hup -x myApp_cp

… where myApp_cp is the title of the cluster process (consisting of your provided processName and the suffix _cp).

API

ClusterProcess offers the following methods:

run(executable[, processName][, options])

executable is the path of your main script that should be executed as worker. A relative path is resolved against your project root (the directory containing node_modules), so pass an absolute path (e.g. path.resolve(__dirname, 'app.js')) if the worker does not live there.

processName is optional. If omitted, the process name is taken from your package.json title property. It will be used as process title. It should not be too long according to the Node.js Documentation. Note that the master process will be called processName_cp and the worker processes should be named processName-w by your code.

options is optional:

• killTimeout: milliseconds a worker gets after SIGTERM to finish its work before it is killed with SIGKILL. Defaults to the environment variable NODE_CLUSTER_KILL_TIMEOUT, otherwise 10000. Keep it below the grace period of your container runtime (Kubernetes: terminationGracePeriodSeconds), so the worker is not killed from outside first.
• onStop: function (may return a Promise) called on SIGTERM once all workers have exited, e.g. to flush telemetry. The master exits with code 0 afterwards. Without onStop the master exits on its own once all workers are gone.

Graceful shutdown

On SIGTERM the master sends SIGTERM to all workers and waits for them. A worker that should finish running work (open requests, queue messages) has to handle SIGTERM itself (see handleSignals) and exit once it is done.

setLogger(loggingInstance)

ClusterProcess uses console logging by default for nicer logging to stdout/console (with timestamps and colors). You can overwrite this with another (e.g. global) logging instance using this method. The logging class is required to provide methods log, info, warn and error.

handleSignals(cleanFunc = noop)

ClusterProcess can handle signals SIGHUP, SIGINT, and SIGTERM. An cleanFunc must be provided and ClusterProcess will call this function on receiving signals.

ClusterProcess' methods are chainable, so you can set a logger, call handleSignals(), and call run() in one line.

Changelog

2.2.0

• configurable kill timeout for stopping workers: killTimeout option or NODE_CLUSTER_KILL_TIMEOUT (default stays 10s)
• onStop option, called on SIGTERM once all workers have exited
• a worker restart scheduled after a crash no longer forks a new worker if the master was stopped meanwhile

2.1.0

• support for esm modules

2.0.0

• removed timeout and exit from handleSignals, parent modul must exit in their cleanup callback

1.1.0

• changed stop behavior when receiving SIGTERM, will send SIGINT to worker, after 10 seconds will send SIGTERM

1.0.2

• fix handling of term signal

1.0.1

• use logger instance instead of console logging

1.0.0

• initial public release of node-clusterprocess