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.
Related
I have a node app that runs once a day. It runs successfully with scheduler and is set up as a worker. The issue is Heroku keeps restarting the worker on successful exit which is the build process. Is there a way to turn off these crash messages and restarts for successful exits? They quickly fill my log files.
I fixed this issue by not having a worker at all. I just run scheduler with an npm run build && npm run prod script. Also keeps dyno costs really low.
I'm setting up CI/CD which includes TeamCity as build server.
I have set up 3 build steps:
npm install,
node server.js,
node run_tests.js
My server.js file runs a REST API via EXPRESS --> which I realized blocks TeamCity in running step #3...which I now understand why...(because everything is run by the same "window" when TeamCity executes it - because it doesn't not exit again...but keeps listening as expected of an API).
How do I run the API, call it and test/confirm it works, shut it down again and then continue with the next step...?
Solved!
Start the app/API via PM2
Execute tests which uses the API
Stop the app/API via PM2
:-)
I have a sailsjs app on AWS EC2, which I have been running till now using forever. I have two adantages using forever:
1) Perpetuality: I can use the CLI forever start app.js or forever restart app.js and then app starts running and keeps on running till I stop it with the command forever stop app.js. So, the app does not stop even when I close my terminal. The process keeps on running.
2) Runtime Log: I have a .forever directory that has a log file, while on real time records the server logs, and when I check the log using tail -f file_name.log, I get to see run time logs.
However there is a disadvantage: Every time I upload a new/modified server file, I have to restart the app manually. To get rid of this, I am switching from forever to nodemon.
From the documentation provided by Nodemon, I cant figure out how can I replicate the two advantages, as mentioned above, from Nodemon too. Will be a great help if anyone can guide me on how to start my nodejs app using nodemon so that it can keep running even after closing the terminal on my side, and how to watch runtime log of server.
Just my two cents.
I use nodemon daily while developing and I dont think its something you want to use in place of something like forever. Nodemon is used when developing, the software will detect when there has been a file change and restart the server but for deployment it should not be considered.
There is no need to change either because forever has this use case handled with the --w or --watchDirectory comand that will watch for file changes(It can be found here on their readme).
I'm fairly new with node.js platform.
I'm working on deploying a node.js app to production in windows sever.
Currently I'm using forever for my production server, and pm2 for development server(just to see how different process managers work.)
What I noticed is my app is down after a while (normally couple days).
I think it might be because my user session which runs the process is closed.
Can you share with me the "correct" deployment steps?
The steps I take to deploy are:
1. Run node cmd as administrator
2. Go to site root
3. Run forever start server.js or pm2 start server.js
Thanks in advance.
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