Deploying Node.js Server

Question

I wrote a Node.js application, I am looking to run it on one of our production machines. This seems like a fairly common request, but I cannot find an adequate solution. Are Node.js application deployment solutions installed?

The application is simple (<100 LOC), but it must be very efficient, reliable and can run continuously for many years without restarting. It will be launched on a large site with dozens of connections per second. (the application is not used as a web server, it only has a JSON API)

Here are the approaches that I reviewed, but I'm still not sure:

Using a framework (e.g. Express)

Since the application has to be high-performance and so simple, adding a frame-shaped bloat is what I want to avoid.

Starting a server using nohup

The main problem here is handling exceptions, we (obviously) do not want the whole server to crash due to an exception. As far as I understand, wrapping the entire application in a try {} catch {} loop will not help, because the Javascript interpreter remains in an unpredictable state after an exception. It is right?

Using something like Forever

I installed Forever on a FreeBSD machine and it was very bad. This led to the emergence of endless processes that could not be killed with Forever. I had to run kill -9 to get my machine back, and I'm not too sure about launching a production Forever application. It also seems that Upstart (a similar tool, but more general) will not work on FreeBSD.

Solution hosting (e.g. Heroku, Rackspace, Amazon EC2, etc.)

This is probably the easiest solution, but we already have serious equipment for the rest of our web servers. For financial reasons this does not make sense.

Is there really a definite solution? Did I miss something?

Answer 1

• You really should use a framework (I recommend something like Express, as it was tested for battle) if you do not want to deal with sessions, cookies, middleware, etc. by yourself. Express is really easy.
• Starting the server with nohup: you should not do this, just start it with the usual "node" command. In addition, Express transfers routes to try-catch, so your server will not be routed. However, if your server has a serious problem, you should not be afraid to restart it (in addition, if you have at least 2-3 processes, at least only one will die, so there will be at least 1-2 remaining ones, and user will win 'I feel something).
• For monitoring, I personally prefer something more at the OS level, such as Upstart and Monit .
• Hosting solution: since you already have your own serious hardware, you do not need to invest in something else. Just use load balancing (possibly nginx or node-http-proxy) for the proxy server.

Answer 2

See Hosting Node Applications .

In this tutorial, you can configure a server that can host node.js applications for server-side applications. Right now, node.js hosting options are reduced to starting Node daemon processes that communicate with the web server. Most web servers can proxy connections to another port, so you can use Apache or nginx to do this.

Answer 3

There are probably three questions.

Question 0: "Should I use a framework for my node application?"

Question 1: "How to start node servers on production machines?"

Question 2: "How to deploy node applications for production."

For Question 1, I really like Cluster (although the latest version of node has something like that built in so you can check this out). I had a good success with something like Monit / Upstart, to keep track of events at the OS level and to keep your servers in good condition. (This controlled N clusters of Ruby Thin servers, but the same thing.)

Depending on the traffic, you may want to start the cluster on several machines, and then put a load balancer in front of it. It depends on your traffic, how much time it will take to execute / how much time you block the event loop, and how many instances of processors / node you run on the machine.

The structure gives you better error handling and catches errors that might come from regular node.js applications. If you are doing this without a framework, be sure to read about error handling in node.js.

For Question 2 , I don't think the node community has a good deployment standard. You can try using the Ruby Capistrano tool (and here 's a blog post about deploying a cluster with Capinstrano ).

The bad thing about Capistrano is that it makes some assumptions that may be wrong (i.e. that you are deploying a Rails project), so you can end up fighting with a wireframe.

My overall deployment solution is a Python Fabric tool that gives you deployment tools and lets you do what you need to do.

Another deployment option is a “cloud” with things like Nodester : let them take care of it.

Answer 4

Try using pm2, this is a simple and intuitive CLI that installs through NPM. Just launch the application with PM2, and your application will be ready to process a ton of traffic.

Official link PM2

How to configure node js application to create using pm2

Answer 5

You can get better answers on ServerFault, but one user experience is described here using supervisord . You will need to use some kind of process observer to support the node process, and another general recommendation seems to somehow refer to proxy connections to the node process. I would probably vote for nginx (this way you can have nginx handle the logging, authentication, or any other higher level HTTP functions you need and not bake them in node somehow), but the above article mentions haproxy in the comments here and there that may be lighter. Your choice of reverse proxy will probably depend a lot on whether you need WebSocket support.

I am not sure if a “standard” workflow does not yet exist for node; it's not quite mature, like something like Rails, which has many ways to keep webapp working.

Answer 6

The guys at Cloudkick wrote a great solution for this. It was called Cast , http://cast-project.org/ .

Install the listing on your server and on your workstation. You start the agent-agent on the server and sign your workstation with an instance of the server instance. Then you can create “packages”, upload them to the server, create / update / destroy them, and also start / stop your instances. Cast will automatically restart your services if they fail. You can also remotely delete stdout / strerr, as well as get a list of running instances and PID # s and manage your instances / servers from your workstation (no SSHing required). Documents are a bit outdated, but the results are worth a bit of extra work. All interactions / commands exceed HTTPS and the RESTful API.

Prior to this, I did all the updates manually using SCP / SSH. We have a supervise . We did not look back.