Is it necessary to give 'worker' information in Procfile? If yes then what it is actually? I have already added web: node server/server.js detail in the Procfile.
Procfile is a mechanism for declaring what commands are run by your application’s dynos on the Heroku platform.
From Process Types and the Procfile, which is a good introduction, but basically you use the Procfile to tell Heroku how to run various pieces of your app. The part to the left of the colon on each line is the process type; the part on the right is the command to run to start that process.
Process types can be anything, although web is special, as Heroku will route HTTP requests to processes started with the web name. Other processes, such as background workers, can be named anything, and you can use the Heroku toolbelt to start or stop those processes by referring to its name.
So, in short, worker is not necessary, unless you want to run some other process in the background by controlling process with the heroku ps command.
You would only need a 'worker' entry in your Procfile if you plan on using some sort of background job system (i.e. queuing long running tasks for later). Heroku has more information here:
https://devcenter.heroku.com/articles/procfile
I was following Udemy course regarding nestjs and aws Elastic Beanstalk to deploy however it keeps failing to deploy until I created Procfile with following:
web: npm install && npm run-script build && npm run-script start:prod
Related
I have a React SPA which runs in Azure Web Apps, Node stack (Node 16 LTS), via the startup command:
pm2 serve /home/site/wwwroot --no-daemon --spa
I would like to add a response header (specifically, a Content-Security-Policy header) for every outgoing request.
Things I have tried:
adding a .htaccess file
adding a web.config file
looking for an evironment setting, or way to configure either pm2, or node
I don't have any node code to change (so I can't add headers there), and doing it in React feels "too late" - I think it's something that node on the server, or Azure needs to do.
My nuclear option is to wrap Front Door around it and do it there, but I'm hoping there is way to achieve this without that.
In App Service Linux, React application can be started with PM2, npm start or custom command.
The container automatically starts your app with PM2 when one of the common Node.js files is found in your project:
Also Note that Starting from Node 14 LTS, the container doesn't automatically start your app with PM2. To start your app with PM2, set the startup command to pm2 start <.js-file-or-PM2-file> --no-daemon.
Be sure to use the --no-daemon argument because PM2 needs to run in the foreground for the container to work properly.
Reference: https://learn.microsoft.com/en-us/azure/app-service/configure-language-nodejs?pivots=platform-linux
I have an ec2 instances that is running a node application. I am thinking of doing a container implementation using docker. The pm2 is running two application one is the actual node application (express and pug) and a cronjob using agenda. Is it a good idea to put my applications in one container?
I am not yet familiar with the pros and cons of this and I read that docker is already a process manager. How will the pm2 fit in all of this once I implement it. Or should I just ditch docker and run the applications in the native linux of my ec2.
You have a couple of questions, I try to answer them below:
1. Is it a good idea to put my applications in one container?
It depends, there are many cases why you would like to run the same container doing multiple things. But it really depends on the CPU/RAM/Memory usage of the job. And how often does it run?
Anyway from experience I can say if I run a cronjob from the same container, I would always use a worker approach for this using either NodeJS cores worker_threads or cluster module. Because you do not want that a cronjob impacts the behavior of the main thread. I have an example of running 2 applications on multiple threads in the following repo.
2. should I just ditch docker and run the applications in the native linux of my ec2
Docker and PM2 are 2 really different things. Docker is basically to containerize your entire Node app, so it is much easier to ship it. PM2 is a process manager for node and makes sure your app is up and comes with some nice metrics and logs UI on PM2 metrics. You can definitely use the 2 together, as PM2 makes also sure your app will start up after it crashes.
However, if you use pm2 you have to use the pm2-runtime when using docker. Example Dockerfile:
FROM node:16.9.0
WORKDIR /home/usr/app
COPY . .
RUN npm ci && npm run build
# default command is starting the server
CMD ["npx", "pm2-runtime", "npm", "--", "start"]
I am running a web service on a reasonably standard MERN stack on a Ubuntu server. I am not overly familiar with web deployment or web programming but I have found myself with this project.
The web service has a pretty extensive list of instructions on how to deploy the service, but it has no instructions on how to undeploy / redeploy it. In addition, it was the sellers of the service's code that deployed it on our server.
I have made some minor changes to the code (fixing spelling, removing / adding functionality) and I cannot seem to work out how to safely undeploy or redeploy the service.
The list of instructions for deployment is, essentially:
yarn
yarn build
yarn start:prod
pm2 start dist/main.js
Doing this as-is while the old service is running obviously doesn't work as the port that I am trying to relaunch on is being watched. Stopping the pm2 process allowed me to redeploy using the above method but has now caused a 502 Gateway error when I relaunch the process.
What is the safe method to undeploy and / or redeploy a service using this tech stack?
You first may want to have a look around on your ubuntu server.
PM2 is like a service manager. To get a list of running services, run this command.
pm2 ls
A typical output:
Typically when you install an update, you just need to restart them.
pm2 restart <service-name>
e.g. pm2 restart cache in my example
Every time I deploy code to Heroku, it automatically looks to run the start script in package.json (NodeJS)
My app is set to run on a timer / scheduler and as such does not need to be run by Heroku when deployed.
How do I disable this behaviour?
you should create a One-Off Dynos whith a Heroku Scheduler add-on.
Since node is basically a single process, when something goes terribly wrong, the whole application dies.
I now have a couple of apps built on express and I am using some manual methods to prevent extended downtimes ( process.on('uncaughtException') and a custom heartbeat monitor ).
Any suggestions from the community?
Best-practices? Frameworks?
Thanks!
A
Use something like forever
or use supervisor.
Just npm link and then sudo supervisor server.js.
These types of libraries also support hot reloading. There are some which you use from the command line and they run node services as sub processes for you. There are others which expect you to write your code to reload itself.
Ideally what you want to move towards a full blown load balancer which is failure safe. If a single node proccess in your load balancer crashes you want it to be quietly restarted and all the connections and data rescued.
Personally I would recommend supervisor for development (It's written by isaacs!) and a full blown load balancer (either nginx or node) for your real production server.
Of course your already running multiple node server processes in parallel because you care about scaling across multiple cores right ;)
Use forever.
"A simple CLI tool for ensuring that a given script runs continuously (i.e. forever)"
Just install it with npm
npm install forever
and type
forever start app.js
Try to look at forever module.
If you're using Ubuntu you can use upstart (which is installed by default).
$ cat /etc/init/my_app.conf
description "my_app"
author "me"
start on (local-filesystems and net-device-up IFACE=eth0) stop on
shutdown
respawn
exec sh -c "env NODE_ENV=production node /path/myapp/app.js >> /var/log/node.log 2>&1"
"respawn" mean that the app will be restarted if it dies.
To start the app
start my_app
For other commands
man initctl
I'll strongly recommend forever too. I used it yesterday and its a breeze:
Install npm install forever
Start your app forever start myapp.js
Check if its working forever list
Try killing your app :
ps
Get your myapp.js pid and run kill <pid
run forever list and you'll see it's running again
You can try using Fugue, a library for node.js similar to Spark or Unicorn:
https://github.com/pgte/fugue
Fugue can manage any node.js server type, not just web servers, and it's set up and configured as a node.js script, not a CLI command, so normal node.js build & deployment toolchains can use it.