I read some Docker and Node.js Best Practices articles, e.g. https://github.com/nodejs/docker-node/blob/main/docs/BestPractices.md or 10 best practices to containerize Node.js web applications with Docker or Dockerfile good practices for Node and NPM. All these article were written or updated at least in 2021, I don't list the articles written before 2021 but there quite some.
They are all against CMD ["npm", "run", "start"]. The main reason is npm will swallow the exit signals such as SIGTERM and SIGINT, so the graceful shutdown code in my node app won't run.
I guess it was the case for the old npm (although I didn't test it), but I have tested node14+npm6 and node16+npm8 and I can verify that npm6/8 do NOT swallow those events and my graceful shutdown code is run. Not sure if that was because npm fixed it.
So the only problem remains is there is 1 more process, npm, to run, i.e. NPM run as PID 1. Some articles said the problem with that is "PID 1 will not respond to SIGINT" but as I have verified that is not the case.
Many articles (e.g. this nodejs doc) suggest just CMD [ "node", "server.js" ] but also in https://github.com/nodejs/docker-node/blob/main/docs/BestPractices.md#handling-kernel-signals said "Node.js process running as PID 1 will not respond to SIGINT (CTRL-C) and similar signals.", i.e. nodejs own documents contradict themselves (but I do see nodejs as PID 1 responds to SIGINT)
So I am confused with the problem with CMD ["npm", "run", "start"] or CMD [ "node", "server.js" ]
For my app there is 1 more consideration, my npm scripts has pre hook to make the app run correctly, I have prestart npm script to make npm start work. So currently I just use CMD ["npm", "run", "start"] but I am confused with the "best practice" of how to start my node app in docker.
--- update ---
I found this closed issue for npm lifecycle: propagate SIGTERM to child
So they did fix it but the latest comment in that issue was in 2017, which said "Yes, this isn’t working, at least with bash; npm runs its lifecycle processes in a shell, and bash doesn’t forward SIGTERM to its children."
I realize I only tested that on my mac and on our CentOS server, and the alpine based docker. It may also because I use exec form, not shell form in CMD so I got the exit signal.
Graceful shutdown with Node.js and Kubernetes said their alpine image didn't get SIGTERM using npm start, while I test on alpine3.15 and I can get.
To work around the swallow of SIGINT and SIGTERM, I do this:
CMD [ "bash", "-c", "npm run db:migrate && node ./dist/server/index.js" ]
where npm run db:migrate && node ./dist/server/index.js was the content of my npm start
Related
I attempted to use the command Heroku pg:psql to connect to my database addon in heroku but got a response below
--> Connecting to postgresql-regular-61345
unrecognized win32 error code: 123could not find a "psql" to execute
unrecognized win32 error code: 123could not find a "psql" to execute
psql: fatal: could not find own program executable
! psql exited with code 1
After using the heroku logs --tail command i got the following errors
sh: 1: nodemon: not found
Process exited with status 127
State changed from starting to crashed
I can also see all processes stopping with SIGTERM and the process exiting with status 143
Resolution steps I have taken
Verified that the environment variables have the path for installed postgress14 on my PC
Added a procfile to the root file in my backend code and spcified "web: node matthewfaceappback/server.js in the file"
Changed my set port to a variable port using process.env.PORT || 3000
Set all environment variable including my database url(set by default) on config variable in heroku
Verified there is a start up script
Updated all my packages using "npm update". after doing this i started expereincing the issue of processes stopping with SIGTERM and the process exiting with status 143
I moved nodemon from devDependencies to dependencies. nodemon version is 2.0.15
In package.json i inputed an engines parameter using the version of node in my case
{"engines": {
"node": "14.17.4"
}}
I restarted heroku using "heroku restart"
Below are links to the screenshots of the error
https://www.dropbox.com/s/5bdbyi9e99lbxhu/pic1.PNG?dl=0
https://www.dropbox.com/s/41euniaes5q68c9/pic2.PNG?dl=0
https://www.dropbox.com/s/50oqzbwmwrqogax/pic3.PNG?dl=0
Put nodemon back in the devDependencies and add it as a second node script in package.json:
"scripts": {
"start": "node matthewfaceappback/server.js",
"dev": "nodemon matthewfaceappback/server.js"
},
These two errors are completely unrelated.
The database connection error
The first issue, which I believe is the one you actually care about at the moment based on the title of the question, indicates that the Heroku CLI can't find a PostgreSQL client on your local machine.
The documentation makes the following recommendation
Set up Postgres on Windows
Install Postgres on Windows by using the Windows installer.
Remember to update your PATH environment variable to add the bin directory of your Postgres installation. The directory is similar to: C:\Program Files\PostgreSQL\<VERSION>\bin. Commands like heroku pg:psql depend on the PATH and do not work if the PATH is incorrect.
If you haven't already installed Postgres locally, do so. (This is a good idea anyway as you should be developing locally and you'll probably need a database.)
Then make sure to add its bin/ directory to your PATH environment variable.
The Nodemon error
The second issue is because you are trying to use nodemon in production. Heroku strips development dependencies out of Node.js applications after building them, which normally makes sense. Nodemon is a development tool, not something that should be used for production hosting.
Depending on the contents of your package.json, this might be as simple as changing your start script from nodemon some-script.js to node some-script.js. Alternatively, you can add a Procfile with the command you actually want to run on Heroku:
web: node some-script.js
See also Need help deploying a RESTful API created with MongoDB Atlas and Express
Recently I made a simple API server using node.js+express. And the script below is a part of my package.json file I use to run with npm commands.
"scripts": {
...
"release": "cross-env NODE_ENV=production MODE=release node server/app.js",
}
After I starts the server with npm run release, I can see multiple processes such as below are running on my Linux server.
/bin/sh /api/node_modules/.bin/cross-env NODE_ENV=development MODE=test node server/app.js
node /api/node_modules/.bin/../cross-env/bin/cross-env.js NODE_ENV=development MODE=test node server/app.js
node server/app.js
I read a related documentation here, but I don't understand what actually happens in background.
What is the order of creating processes? npm => /bin/sh => node /api/.. => node server/app.js ?
What does each process do? All three processes are necessary to run my server?
If I wants to kill the server with pid, which process id should I use?
What is the order of creating processes? npm => /bin/sh => node /api/.. => node server/app.js ?
What does each process do? All three processes are necessary to run my server?
Well, the flow is like this:
NPM is spawned (you run it) inside your shell, npm itself runs with NPX in order to set the local path.
Your npm script spawns a process from a package called cross-env for cross-OS environment variable setting.
That process in turn spawns Node.js (after setting the environment variables)
That's why you see 3 processes. After your server itself run - only the actual server process is needed to run the server.
If I wants to kill the server with pid, which process id should I use?
This one: node server/app.js - since that's your actual server, the others are just "utility processes" (one for the npm script you ran and the other for the environment variables").
It's worth mentioning that in general - servers are run inside containers or other orchestrators/managers that have built-in logic for restarting/killing the process. Typically the orchestrator sends SIGTERM to the process.
I am trying to have a nodejs application start automatically on system boot. Basically all I need is to run the command node /dir/app.
I am using openwrt on an Arduino Yun. And have tried a couple things.
On the openwrt website it said I can do this. https://wiki.openwrt.org/inbox/procd-init-scripts :
#!/bin/sh /etc/rc.common
USE_PROCD=1
start_service() {
procd_open_instance
procd_set_param command node ///www/www-blink.js
procd_close_instance
}
I have also tried changing the dir to /www/www-blink.js not ///
However i'm not sure what i'm doing wrong as nothing comes up when I try run it with /etc/init.d/node-app start I am obviously writing the code wrong but i'm not sure what it should exactly look like.
The other thing I have tried is the node modules forever and forever-service.
I downloaded them on my computer using npm install -g forever and forever-service aswell. I transfered them to usr/lib/node_modules on my arduino yun. However when I try to use and forever(-service) commands it says
-ash: forever: not found
I have tried a couple other things, however nothing has worked. Any help would be greatly appreciated.
-- I also need to be able to start my express script with npm start not node app but I guess the first thing is getting it to work at all.
you can put the starting command (node /dir/app &)in the /etc/rc.local script. This will start your nodejs application automatically on system boot.
OpenWRT procd has a "respawn" parameter, which will restart a service that exits or crashes.
# respawn automatically if something died, be careful if you have an
# alternative process supervisor if process dies sooner than respawn_threshold,
# it is considered crashed and after 5 retries the service is stopped
procd_set_param respawn ${respawn_threshold:-3600} ${respawn_timeout:-5} ${respawn_retry:-5}
So, you cold just add:
procd_set_param respawn 60 5 5
or something like that to your OpenWRT procd initscript. This 60 5 5 means it will wait 5s between respawns (middle parameter), and if it respanws more than 5 times (last parameter) in 60s (first parameter), it will disable the service ("restart loop" detected).
Refer to this page for more information:
https://openwrt.org/docs/guide-developer/procd-init-scripts
You need to execute your node application like a Linux Service.
Upstart is perfect for this task
Upstart is an event-based replacement for the /sbin/init daemon which handles starting of tasks and services during boot, stopping them during shutdown and supervising them while the system is running.
If you have an app like this (for example):
// app.js
var express = require('express')
var app = express()
var port = process.env.PORT
app.get('/', function(req, res) {
res.send('Hello world!')
})
app.listen(port)
With a package.json like this:
{
"name": "my-awesome-app",
"version": "1.0.0",
"dependencies": {
"express": "^4.13.3"
},
"scripts": {
"start": "node app.js"
}
}
We create a upstart configuration file called myAwesomeApp.conf with the following code:
start on runlevel [2345]
stop on runlevel [!2345]
respawn
respawn limit 10 5
setuid ubuntu
chdir /opt/myAwesomeApp.conf
env PORT=3000
exec npm start
To finish, put your application (app.js and package.json) in the /opt/myAwesomeApp.conf and copy the configuration file myAwesomeApp.conf in /etc/init/
This is all, now you just need to run service myAwesomeApp start to run your node application as a service
I've never used procd before, but it likely needs the full path to node (e.g., /usr/bin/node). You'd need to make the line something like procd_set_param command /usr/bin/node /www/www-blink.js, assuming the file you want to run is /www/www-blink.js. You can locate node by running which node or type -a node.
Previously, I started my production node app via:
NODE_ENV=production forever start index.js
However, per the suggestions in this question, I'd like to start node with --nouse-idle-notification. I also found this article about setting --max-old-space-size, etc. Unfortunately, nobody I ask can seem to figure out how to tell if the flag is actually accepted by node, so I'm not sure how to tell if my forever syntax is correct.
Furthermore, I can't get forever to accept both arguments...
Eg, if I use this
NODE_ENV=production forever start --max-old-space-size=8192 --nouse-idle-notification index.js
I get the "forever usage information", as if I had tried to start forever without passing a .js file to run (eg, just typing "forever"). If I put the flags before the "start" command, it seems to start, but again I'm not sure how to tell if the flags were accepted...
Can someone please help me with the correct syntax?
You need to pass -c parameter:
forever start -c "node --max-old-space-size=8192 --nouse-idle-notification" index.js
If you list the processes, you'll see the flags are honoured.
forever list
Unless you really love forever for some other reason, try mon.
It's super easy to pass flags because you can specify the exact command:
mon "node --max-old-space-size=8192 --nouse-idle-notification --expose-gc server.js" -d
It monitors only a node process. If you want to monitor a group of processes like forever does, install mongroup, its a bash script that manages mon.
This will save you some RAM, specially if you're monitoring a lot of node processes (I think forever launches one additional node process for every process you want to monitor).
quick tip: last time I checked, TJ Holowaychuk's branch of mon was not working well under linux (I guess he only tested on Mac), but this one works and its the one I'm using right now. EDIT: Actually 2 days ago the issue was closed and the main branch should now be working.
You could try:
forever start --max-old-space-size=8192 --nouse-idle-notification -c "NODE_ENV=production node" index.js
A web app I am writing in JavaScript using node.js. I use Foreman, but I don't want to manually restart the server every time I change my code. Can I tell Foreman to reload the entire web app before handling an HTTP request (i.e. restart the node process)?
Here's an adjusted version of Pendlepants solution. Foreman looks for an .env file to read environment variables. Rather than adding a wrapper, you can just have Foreman switch what command it uses to start things up:
In .env:
WEB=node app.js
In dev.env:
WEB=supervisor app.js
In your Procfile:
web: $WEB
By default, Foreman will read from .env (in Production), but in DEV just run this:
foreman start -e dev.env
You can use rerun for this purpose
You might implement just 2 commands for this:
gem install rerun
rerun foreman start
Then rerun will automatically restart process after any change in your files.
If you use nodemon
, you can do
nodemon --exec "foreman start"
The problem isn't with Foreman so much as it's with how node doesn't reload code on new requests. The solution is to use an npm package like supervisor along with an environment wrapper for Foreman.
First, install supervisor:
npm install -g supervisor
Then, write a wrapper shell script that Foreman can call:
if [ "$NODE_ENV" == "production" ]; then
node /path/to/app.js
else
supervisor /path/to/app.js
fi
Set the wrapper script's permissions to executable by running chmod a+x /path/to/wrapper_script.sh
Lastly, update foreman to use the wrapper script. So in your Procfile:
web: /path/to/wrapper_script.sh
Now when you run Foreman and your node app isn't running in production, it should reload on every request.
I feel like Peter Ehrlich's comment on the original question deserves to be an answer on its own. I think a different Procfile for local/dev is definitely the best solution: https://stackoverflow.com/a/10790514/133720
You don't even need to install anything new if you use node-dev.
Your .env file loaded from Procfile:
NODECMD=node-dev
Your Procfile:
web: $NODECMD app/server.js
Your foreman command
foreman start -e dev.env -p 9786
And in your production env (heroku) set an environment variable:
NODECMD=node