How to auto-restart rabbitmq after crashing - node.js

I experienced some crash for rabbitmq on my Linux server. To restart it, I execute the following command:
systemctl restart rabbitmq-server.service
The server restarts correctly.
Another problem is that I have to restart all the Node applications that were connected to rabbitmq before crashing.
Here are my questions:
Is there a way to automatically restart rabbitmq when crashing?
How to make my Node applications automatically reconnect to rabbitmq?
Thanks very much for your help!
Thierry

So to answer your first question , the best way to handle it is run the RabbitMQ cluster on docker and have the container restart mode set to always so in case if a node goes down for some reason the container will stop and the docker deamon will spawn a new container for it , if you can use K8s then it is even better.
For our second question the general pattern that we follow in Client applications is to have a reconnect logic which is triggered whenever there is an IO Exception and the reconnect attempt is continued for configured number of times with some wait added in between each attempt. There is no automatic way to do this and has to be handled as part of my client app.

Related

Node Backend stay running in GPC Compute Engine

I'm newbie using GCP and his Compute Engine Service. I've deploy a Linux Ubuntu Image an it's running like a charm, but I have a issue running Node JS backend.
Let me explain it better:
I'm connecting using Web Browser SSH terminal or GCloud Shell ssh, and it way works running node app.js my backend starts working. But after a time, the sessions stop and my backend service stop working as well. At this time every time when I need to work have to re-activate the service each time.
How could I do for this service works in background and not depends that my ssh terminal are opened?
Thanks a lot in advance.
What actually happen is you are starting your nodejs application using an client which is parent process. So if after sometime the connection is lost of some xyz seconds the parent process dies killing your node application. Now what you can do is use screen. On ubuntu you would do something like this.
sudo apt-get install screen
after successful install run the screen command. Now you will be thrown a brand new terminal. Here you can run your nodejs code which will never die. Since screen runs your application in background. More information here
A good solution could be to use a startup script. To insert a startup script into your already created instance you need to go to this link [1]. When you have your startup script inserted in the metadata field you just need to restart your Instance and then should work perfectly without depending of the ssh session.
[1] https://cloud.google.com/compute/docs/startupscript#startupscriptrunninginstances
I've created this npm package, to make your node app run as a service on your linux machine. Please try it out.
It creates a systemctl service on your machine and runs it as a background service.

nodejs for background process, not a http server

Im new to nodejs, i am looking for a way to create a nodejs process that can run in the background. All the example I can find is to create a node http server. I don't need to listen for any web request i just need to startup a process and have it listen to a message queue.
NodeJS has enough API to be used for versatile tasks, not just HTTP Servers. You have two problems to solve:
Run Node process continuously. So, you'd need some equivalent of http.listen() so the process just don't exit. Whatever you intent to do, you'd probably need Node waiting for some external events.
Run node as a daemon or service. There are plenty of modules to help, foreman, pm2. You can make this process auto-start by using upstart on linux machines and node-window for windows.

NodeJs not staying live in aws

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.

Does AWS EB instance automatically restart when crashed?

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.

Run at startup and monitor redis and node.js processes

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.

Resources