如何在Node.js中实现零停机时间重新部署

Question

What is the easiest way to achieve zero downtime for my Node.js application?

I have an app that requires the following steps for redeployment:

• npm install
• node_modules/.bin/bower install
• node_modules/.bin/gulp

The result of these operations is the ready-to-run application in the generated by the gulpfile.js directory named build . In this directory I have a currently-running instance of the same application (currently launched via forever like this -- forever start server.js ).

As far as I know, it is not possible to achieve zero downtime via forever module, so I decided to choose another way to do it.

I saw pm2 but I found it very complex tbh (prove me wrong if you don't feel the same).

I also saw naught but I can't even start my application via naught start server.js -- it doesn't even print anything in stdout / stderr.

I also saw up-time but I didn't get the idea -- how will it handle situation when I run gulp that should replace files in the directory where currently-running instance work at the moment?

Answer 1

Regarding of handling replaced files during build: if these files is used by Node.js app then all changes will be applied upon process restart (since these files are loaded into memory), browser frontend files could also be cached in application memory to achieve similar behavior (changes applied only upon restart or/and cache invalidation).

We're using pm2 in cluster mode.

pm2 start app.js -i

The above command starts app.js in cluster mode on all available CPU cores.

zero downtime restart:

pm2 gracefulReload all

this command restarts all processes sequentially, so if you have more than one process up and running there is always at least one process that servers requests during restart. If you have only one process of app.js you can start it in cluster mode and run pm2 scale app.js 2 (starts one more process) then pm2 gracefulReload all and then pm2 scale app.js 1 (removes previously started process).

Though I think app restarting is not main problem of zero downtime deployment, we've not managed to handle DB migrations, so full app shutdown is needed to apply DB changes. Also there could be an issue with browser frontend files when during deploy user obtained the new version of them, but AJAX request is processed by old version of server process, in this case sticky sessions and API versioning came to the rescue.