It seems to be basic for you to answer but still I couldn't able to find out what is process.json file in Node.js and what it does, is that any file exists in Node.js ?
I went through one of the question on stackoverflow here in which process.json file is showing when installing npm modules.
Can you please answer me about the same that will be really helpful ?
process.json is used for PM2 module of Node.js which is a General Purpose Process Manager and a Production Runtime for Node.js apps with a built-in Load Balancer.
PM2 empowers process management workflow.
Key features of PM2 are:
Simple and efficient process management (start/stop/restart/delete/show/monit)
Keep your application ALWAYS ONLINE with auto restarts and init system script generation
Clusterize Node.js Applications without code change to increase performance and reliability
Hot Reload Node.js Applications without extra configuration
Starting an application in production mode can be done using this simple command
$ pm2 start app.js
To dive into more details for process.json, you can refer this
Related
I want to access node app terminal in production if there is a way, as in development we can access terminal to see activities, events and log messages, but in production(cPanel) i did not find such tool which i can use to view runtime error to solve any error in the code.
If you know any solution regard this problem, please answer me, i am looking very seriously at it.Thanks, any help will be appriciated
You're welcome 🙏🏼
Shared hosts do not have access to the terminal at all
You have to buy the virtual private server (VPS) so you can run your nodejs app and access terminal.
Use pm2 for production nodejs app.
npm i pm2 -g
PM2 is a production process manager for Node.js applications with a built-in load balancer. It allows you to keep applications alive forever, to reload them without downtime and to facilitate common system admin tasks.
I have been using forverjs for my server but for some reason the server stopped and the server didn't restart again. Is foreverjs reliable?
Should i use any other libs?
Found there are many libs like pm2, nodemon, upstart, systemd, nginx. Which one should ensure my application running all the time. also can these tools handle large loads of requests?
There are multiple questions within your question to analyze.
Is foreverjs reliable?
forever is a very popular package. As seen on GitHub, it has 75 contributors and 636 commits. This question is mainly opinion-based, but 9/10 (maybe 10/10) experienced developers would say it's reliable for it's purpose (I expand below).
Should i use any other libs?
Reliability is achieved through sturdy software design and not just packages you choose. I have used forever and pm2 production processes for years without any problems on their end. They include great features for reliability, such as attempting to restart your application if it crashes. Packages are not supposed to fix terminal bugs in your code.
Found there are many libs like pm2, nodemon, upstart, systemd, nginx.
Which one should ensure my application running all the time.
This can be found through reading their GitHub descriptions. I use nodemon for quickly testing code as it's written. For example, I start the nodemon process and it begins my Node.js process. When I edit my code and press save, the Node.js process is automatically stopped and restarted with the new code. nodemon should not be used alone for a long-running production server, since it will stop when you exit your shell. pm2 and forever are effective libraries and you can investigate upstart, systemd, and nginx if necessary.
Regarding #Kalana Demel's answer, I consider using forever to run nodemon as using forever in my explanation above.
how to ensure my application is reliable all the time
For an overall answer to your question, you should be writing tests to ensure your code is reliable. If you've written effective unit and integration tests, choosing a package to run the process will be trivial (and not related to reliability), since you should not expect it to crash.
nodemon is a good option, you can use a combination of forever and nodemon using,
forever start -c nodemon app.js
Also in my experience forever is very reliable, try
forever logs app.js
to see what exactly caused the error
pm2 is good option in these cases, I personally use pm2 in all my node.js servers, it provides alot of more important functionalities in comparison to others.
One of the best thing about it can be easily integrated with keymetrics/newrelic for analytics of the server.
Also pm2 will give you cpu/memory usage, you can even configure the restart limit and interval.
I am currently running an express server using the node js vanilla cluster setup as demonstrated over here:
http://rowanmanning.com/posts/node-cluster-and-express/
I'd like to move the server over to sails.js and I am wondering if anyone knows how to configure sails to support the node cluster (no proxies, just simple cluster).
TX,
Sean.
First thing - if You want to use sessions, You need to use session store. Otherwise session will be not shared between instances of Your app.
Then, The easiest way is to use something like PM2, which can be found here: https://github.com/Unitech/pm2
You dont need to do changes in Your app.js files - it should be written as standard non-clustered sails app. PM2 will do the job.
Just start the app with pm2 start app.js -i x where x is number of instances or use pm2 start app.js -i max which will start instances that are equal to numbers of processors, or processor threads.
PM2 is great and very stable, it has many features to run it smoothly in producation, however it has some flaws in development. If You will ever have a problem with "port already in use" after stopping or even deleting app that was using it - You will have to use pm2 kill which will kill ALL Your apps.
Other than that - its just great - with some additional monitoring tools.
You can use PM2 Library a create different instances like cluster.
For do it you have to use app.js file, like:
pm2 start app.js
If you want to run the max number of instances availables:
pm2 start app.js -i max
check the documentation for more: https://github.com/Unitech/pm2
I'm working through the StrongLoop's getting started instructions and created my sample app. Whilst the instructions tell me to use:
slc run .
to start my application, I noticed I can equally run my application with:
node app.js
and get the same result. Obviously by using the second approach I can integrated my StrongLoop application with tools such as forever.
So my question is, what extra benefits does slc run offer? Does it have functionalities such auto restart etc?
You can do more with slc than node app.js.
slc is a command line tool for StrongLoop, which has more features. If you just want to run the app, it doesn't matter much, but if you want to do more, you can.
Here's the documentation: http://docs.strongloop.com/display/SLC/StrongLoop+Controller
It doesn't have much features for development (such as auto restart and such), but it will help with managing servers and what not.
My favorite feature is scaling a node app using slc.
You can do "slc run . size 2". This will spin up 1 master and 1 worker process which is part of a single cluster. Now if my workload increases, and resources are low, which I know using strongOps monitoring (slc strongops) and I want to scale the app without having to stop the app and re-engineer, I can just do the following:
"slc clusterctl size 4". This will spin up 2 more worker processes and automatically attach them to the same application cluster at run-time. The master will auto distribute the workload now to the new processes.
This is built on top of node cluster module. But there is much more to it. Used cluster-store to store shared cluster state objects too.
Another feature is "slc debug". Launches Node Inspector and brings the application code in runtime context and helps me in debugging, load source maps and iterate through test runs.
Based on the latest release at the moment (v2.1.1), the main immediate benefit of running slc run instead of node app.js is you get a REPL at the same time (lib/run-reple.js#L150L24). Looks like all you have to do is have main set properly in package.json, since it uses Module._load().
If you run slc run app.js you get no benefit as far as I can tell: lib/commands/run.js#30.
Yay open source! https://github.com/strongloop/strong-cli
One of my favorite features is 'slc debug app.js' which brings up node-inspector for debugging . its nice CLI sugar. But of course you can totally run node and configure this manually.
I created a Linux init.d Daemon script which you can use to run your app with slc as service:
https://gist.github.com/gurdotan/23311a236fc65dc212da
Might be useful to some of you.
slc run
it can be only used for strong loop application
while node . or node [fileName]
can be used to execute any Nodejs file
I am a node.js developer. I use Amazon ec2 to deploy my node.js apps.
I want to have my node.js service running permanently - restarted if it fails for any reason.
I came across 2 tools . Forever and Upstart
Is there any advantages of using one over the other ?
Is there any other tool which is better ?
Upstart is a system service controller, similar to SysV Init and will start/stop/restart essentially any service registered for it, Node.js-based or not, and it will also automatically start services on system start for you. But Upstart is essentially specific to Ubuntu, and Upstart-specific services won't run on other Linux distros.
Upstart has a SysV Init compatibility layer that you could target,instead, to maintain as broad of a compatibility layer as possible.
Forever is a Node.js application that monitors and restarts other Node.js applications as needed, and as defined by its configuration JSON. Lots of options and fine-grained control over your service without the effort that would be needed to duplicate it in a custom SysV Init script. However, Forever isn't a system service, so if the server is restarted, you'll have to manually start your forever scripts again.
Beyond that, if all you need is something that will restart your script if/when it crashes, and you don't care about it starting automatically on system start, all you need is a bash script as simple as:
#!/bin/bash
while true
do
node ./myScript.js
done
Just to correct a misleading statement in the accepted answer...it is not true that upstart is an Ubuntu-only technology. See:
https://serverfault.com/questions/291546/centos-6-and-upstart
http://searchenterpriselinux.techtarget.com/tip/RHEL-6-ditches-System-V-init-for-Upstart-What-Linux-admins-need-to-know
http://en.wikipedia.org/wiki/Upstart#Adoption
With that, I think it is a much more compelling solution.