5 ms·
A very common mistake I see (though not related to image size perse) when running Node apps is to do CMD ["npm", "run", "start"]. This is first memory wasteful,
by nodesocket 5y ago
A very common mistake I see (though not related to image size perse) when running Node apps is to do CMD ["npm", "run", "start"]. This is first memory wasteful, as npm is running as the parent process and forking node to run the main script. Also, the bigger problem is that the npm process does not send signals down to its child thus SIGINT and SIGTERM are not passed from npm into node which means your server may not be gracefully closing connections.
- arnaudsm 5y agoWhat do you recommend instead?
- nodesocket 5y agoJust invoke your script: CMD ["/usr/local/bin/node", "server.js"]
- TameAntelope 5y agopm2 is good for some things.
- nodesocket 5y agopm2 is great when running on servers, but using pm2 in containers feels wrong and again wasteful. Just invoke your script. If it crashes, fine Kubernetes or Docker handles that. Logs, handled by k8s. Monitoring I use DataDog.
- chousuke 5y agoWhat's the point of pm2? Every time I've seen it it's just been part of a messy misconfigured system and whatever it's actually doing could've been accomplished entirely with a tiny systemd unit running node directly.
- TameAntelope 5y agoFrom their site, I’m on mobile so the paste is a little rough. BEHAVIOR CONFIGURATION SOURCE MAP SUPPORT CONTAINER INTEGRATION WATCH & RELOAD LOG MANAGEMENT MONITORING MODULE SYSTEM MAX MEMORY RELOAD CLUSTER MODE HOT RELOAD DEVELOPMENT WORKFLOW STARTUP SCRIPTS DEPLOYMENT WORKFLOW PAAS COMPATIBLE KEYMETRICS MONITORING API
- speedgoose 5y agoYou shouldn’t use pm2 in software containers. That makes things more complex and not standard.
- jwdunne 5y agoCan echo this. A colleague’s node container was maxing out CPU and just removing PM2 and running node directly solved the problem. That was easier than debugging why PM2 was having such a hard time. To be fair, it was a straight up conversion of an old VM in vagrant and Docker was looked at as a one to one replacement before learning otherwise.
- TameAntelope 5y agoIt gives you a bunch of stuff you don’t get running the script directly, and costs nothing, so why wouldn’t I opt for that? They even have an explicit, “run in container” mode.
- unmole 5y ago> This is first memory wasteful, as npm is running as the parent process and forking node to run the main script. With Linux's CoW semantics, wouldn't the child share pages with the parent?
- nodesocket 5y agoIf I exec into a container that runs npm and run top you’ll see npm (parent) using res memory and the node process (child) itself using memory. I’m pretty sure the npm memory is just wasted.
- latchkey 5y ago> CMD ["npm", "run", "start"] Probably not the best searchfoo, but confirmed... https://github.com/search?q=%22CMD+%5B%22npm%22%2C+%22run%22%2C+%22start%22%5D%22+language%3ADockerfile&type=Code&l=Dockerfile&l= https://github.com/search?q=%22CMD+%5B%22npm%22%2C+%22run%22...
- encryptluks2 5y ago
- 0des 5y agoHow dare you
- dedoussis 5y agoTo avoid any potential issue with signal propagation a good practice is to always use a lightweight init system such as dumb-init [1]. One could assume that the node process would register signal handlers for all possible signals, but I prefer to not have to make this assumption and use an init system instead. [1] https://github.com/Yelp/dumb-init https://github.com/Yelp/dumb-init
- AtNightWeCode 5y agoThat is funny. I would assume we don’t even have NPM installed on the final Docker images. Some people simply don’t know what they are doing.
- afiori 5y agodoes this applies also to npx or yarn?
- wereHamster 5y agoYes.