In my local node server , it fails on any uncaught exception and has to be manually restarted. So local was run using either forever or pm2.
But my development server is AWS Elastic Beanstalk with Node.Js environment .Though it logs uncaught exceptions and throws it , it never terminates.Even if it terminates , it starts automatically.
So is there a need for PM2 or Forever to keep node.js running for ever in AWS Elastic Beanstalk environment.
My 2 cents:
There are many advantages for PM2 over EBS:
with PM2 you can control and manage many applications (processes) with different platforms (JS, Ruby, ...).
Where in EBS you can deploy only one application at a time to an EBS.
PM2 gives you direct control over all running process, where you can reload/restart/stop one process and keep other intact.
EBS can fix only few problems for you, like restart on crash, or limit memory leaks. But PM2 gives you control over many other problems (graceful reload, 0 latency reload, ...)
Now, I might be a little bit wrong about the full functionalities of EBS, and it might be providing more
Here is a tutorial on how to use PM2 in EBS:
http://pm2.keymetrics.io/docs/tutorials/use-pm2-with-aws-elastic-beanstalk/
Hope it helps!
Related
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?
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.
I set up a AWS Ubuntu instance running a http-server using node.js
I was wondering if its possible to log out of my remote server while persistently keeping the http-server on.
This is a pretty good tutorial that deals with keeping a node.js server running, and amongst other things, deals with running it in the background.
http://blog.nodejitsu.com/keep-a-nodejs-server-up-with-forever/
Forever is a nice option (as suggested above).
Though, I recommend using AWS' Elastic Beanstalk over EC2 (that's the service you are using now, if I got it right), it provides you an easy interface to deploy you web-server with no ssh interference and keeps it alive at all times after deployment, and also gives you some other load balancing and auto scaling features with minimum effort.
You could also use pm2 for this. Besides keeping your http-server online it also gives you the possibility to do load balancing and other tasks.
Run
npm install pm2 -g
on your server and start your app with
pm2 start app.js
As marekful points out, logging out of your Ubuntu server will not have any effect on your http-server.
I have deployed a Bitnami AMI of NodeJS on an AWS micro instance. After starting my node app, everything works fine.
After some time without any activity, the app which is attached to port :3000, seems to shut down. When this happens on refreshing the page my browser gives the message:
Network Error (tcp_error)
A communication error occurred: "Connection refused"
The Web Server may be down, too busy, or experiencing other problems preventing it from responding to requests. You may wish to try again at a later time.
The AWS console shows the instance is still running and the Bitnami build still responds with the standard message on port 80.
Forever (https://github.com/nodejitsu/forever) is also a useful tool for this kind of thing, and it gives you a little more control than nohup or screen.
As we discussed in comments, the problem was binding the node process to SSH session.
You can use nohup or screen to launch the node process in an instance not bound to session.
I suggest using screen because the function of returning to launched instance is essential for maintenance/updating.
Related: How to run process as background and never die
Related: Command-Line Interface tool to run node as a service
Besides configuring an EC2-instance you can also use the PaaS-solution of AWS, namely Elastic Beanstalk. They have also support for Node.js and it's super easy to deploy your apps using this service.
I have a NodeJS instance running with Amazon Elastic Beanstalk. I would like to know if the instance will automatically restart if nodejs crash the server ?
Do I have to use foreverjs ?
Thank you
TLDR - Use foreverjs.
So there are two types of restarts. One is where the code throws an exception and stops node. The OS is still running. In this case, from the OS perspective, node decided to exit. None of it's business. This is where foreverjs plays a role - it'll watch node and restart it if it ever stops due to an exception/error etc.
The second type of restart is a machine reboot. This is something that you might want to do if there is a kernel panic etc. AWS will not automatically reboot; it won't do anything that your desktop would do. You're going to have to reboot it (but really - try and debug it before having it serve production traffic again). I've run a fair number of servers and this isn't a common issue. The best way to deal with this is to have redundancy and have other servers step in if one fails in such a stark manner.
I want to deploy node.js app which depends on redis. Both processes will run on the same VPS. There are plenty of examples on how to daemonize and monitor node and I've also found some uncommented configuration for redis. How do I put it together? Can I just combine these two snippets in one monitrc file?
You could use Supervisord to orchestrate the launch of Redis and your NodeJS apps (use the priority parameter to start Redis before your apps). Supervisord will automatically restart your NodeJS app if they crash.
You can then setup monit over it to be alerted when something wrong happens and to restart your NodeJS processes if they use too much memory/cpu or if they are not accessible anymore from a specific port.