I have a RoR/Heroku app. Right now, my deploy process consists of checking in git, then running "git push heroku master". Problem is, this introduces a lag of about 10 seconds where my live site goes down before coming back up. This causes existing visitors on the site to get frustrated and leave, if they happen to notice it.
So what is the best practice way to avoid that?
git push heroku master
I read about setting up a "staging" environment, but would that help avoid this? I'd still have to run a git push heroku master, wouldn't I?
Heroku has a Labs feature that will pre-boot new dynos before shifting load from old dynos to new dynos. This way, new dynos will be fired up and ready when they start receiving requests and your users will see no delay when you update your app. Here's how to enable pre-boot:
heroku labs:enable -a myapp preboot
Related
For historical reasons Heroku is where are reporting database is located, which is a direct copy of production from Linode.
I currently run commands locally every day to copy the Linode database from Linode server to local drive and then push it to Heroku. I need to automate this somehow so it runs 'somewhere' every day - but where?
I know about cron jobs etc and also that you can run workers on Heroku, but I really don't know what is the best/recommended way to go about this and would like to see what others recommend.
I tried googling but cannot seem to find anything that points me in the right direction - the results are always heroku to heroku copying! Perhaps someone on here knows of some tools/services that might help automate this task?
I think the easiest thing is to setup a worker dyno on heroku and use their "Heroku Scheduler" to setup a background task. It's incredibly easy and well documented. You would make a rake task in your lib/tasks folder and then call it via the heroku scheduler using their api on your account dash. Docs can be found here: https://devcenter.heroku.com/articles/scheduler#defining-tasks
I am expecting a large increase in traffic tomorrow(press, etc) to my website. I want to be able to manage the traffic without it going down. I know that I have to add dyno's and the cost is not too prohibitive because it is only temporary to keep the queue down.
I am using New Relic Add-On to Monitor
This post is really helpful: https://serverfault.com/questions/394602/how-to-prepare-for-a-huge-spike-in-traffic-for-launching-a-website-hosted-on-her
However after reading that post and pouring over heroku docs I have not been able to figure out how I actually do this...
What command can I run or from what interface can I spin up a new dyno to handle the added web traffic? Then, with what command do I run or from what interface do I eliminate that extra dyno when the traffic has return to normal levels?
Heroku talk about a bunch of different types of dyno's etc but I have no idea which one I am supposed to use and then how to actually spin up a new one.
Heroku has an platform-api gem that will be useful for you in this case. First add the gem to your Gemfile and install it.
gem platform-api
Once installed, setup the heroku client, preferably in an initializer
$heroku = PlatformAPI.connect(ENV['HEROKU_API_KEY', default_headers: {'Accept' => 'application/vnd.heroku+json; version=3'})
You can find how to get an Heroku API KEY here
Now, to the scaling part. I'm guessing you have some internal metrics to decide when to scale (by process count, request count, etc). The below command will scale up the number of dynos you require,
$heroku.formation.update(APP_NAME, PROCESS_NAME, {quantity: DYNO_COUNT})
This will scale the app's specified process to X number of dynos whenever required.
You can use the same command to scale down your number of dynos. Also, below command will help you get the number of dynos currently provisioned for a particular process
info = $heroku.formation.info(APP_NAME, PROCESS_NAME)
info['quantity']
To get the number of ALL dynos provisioned to your app, use
$heroku.app.info(APP_NAME)
EDIT:
In case you prefer it to do manually, then you can do this in the heroku's dashboard itself. Or if you prefer command line, install heroku toolbelt and below is the command for scaling the app.
heroku ps:scale process_name=dyno_count -a app_name
To get the list of dynos provisioned
heroku ps -a app_name
As described here, Heroku logs metrics for your dynos every ~20 seconds.
source=web.1 dyno=heroku.2808254.d97d0ea7-cf3d-411b-b453-d2943a50b456 sample#load_avg_1m=2.46 sample#load_avg_5m=1.06 sample#load_avg_15m=0.99
source=web.1 dyno=heroku.2808254.d97d0ea7-cf3d-411b-b453-d2943a50b456 sample#memory_total=21.00MB sample#memory_rss=21.22MB sample#memory_cache=0.00MB sample#memory_swap=0.00MB sample#memory_pgpgin=348836pages sample#memory_pgpgout=343403pages
These pile up quickly and distract from the log view, especially when they are every 20 seconds and there are 10+ dynos for a small web app.
Is it possible to change the frequency at which these are logged? Something like once per minute would cut the quantity down by a factor of 3 and would still be sufficient for my app's needs.
Thanks!
Edit: Heroku does provide a way of filter out certain types of logs while tailing, so in theory I could get rid of them entirely by excluding the system logs. But if there are other valuable things in the system logs, the question of how to specifically reduce (not filter out) these metrics still stands.
We had a similar problem and decided to just turn off the runtime-metrics logging altogether.
You can check to see if it's enabled with:
$ heroku labs -a you-app-name
=== App Features (your-app-name)
[+] log-runtime-metrics Emit dyno resource usage information into app logs
and remove it with
heroku labs:disable log-runtime-metrics -a your-app-name
heroku restart -a your-app-name
I've got some background jobs that run for a long time (hours).
If I deploy my app while those background jobs are running, will the dynos those jobs are attached to get restarted (thus killing the jobs)?
More specifically, those background jobs deal with downloading large files to /tmp...meaning if that dyno got restarted, it would interrupt the download.
Dyno's are restarted when you deploy, yes.
More importantly though, if you are downloading to /tmp then a deployment would create a new slug with an empty /tmp so anything downloaded would no longer exist.
Dynos are restarted on deployment.
They are also cycled once a day by Heroku automatically. Dynos can be restarted whenever it stops responding, or stopped and moved to another network location, all automatically. And as John mentioned, it will be a new instance, so all your previous downloaded files will be deleted.
You can look at some cases here - https://devcenter.heroku.com/articles/dynos#the-dyno-manager
Best practice on Heroku would be, not to have any writable files on the Dynos.
So right now I have an implementation of delayed_job that works perfectly on my local development environment. In order to start the worker on my machine, I just run rake jobs:work and it works perfectly.
To get delayed_job to work on heroku, I've been using pretty much the same command: heroku run rake jobs:work. This solution works, without me having to pay anything for worker costs to Heroku, but I have to keep my command prompt window open or else the delayed_job worker stops when I close it. Is there a command to permanently keep this delayed_job worker working even when I close the command window? Or is there another better way to go about this?
I recommend the workless gem to run delayed jobs on heroku. I use this now - it works perfectly for me, zero hassle and at zero cost.
I have also used hirefireapp which gives a much finer degree of control on scaling workers. This costs, but costs less than a single heroku worker (over a month). I don't use this now, but have used it, and it worked very well.
Add
worker: rake jobs:work
to your Procfile.
EDIT:
Even if you run it from your console you 'buy' worker dyno but Heroku has per second biling. So you don't pay because you have 750h free, and month in worst case has 744h, so you have free 6h for your extra dynos, scheduler tasks and so on.
I haven't tried it personally yet, but you might find nohup useful. It allows your process to run even though you have closed your terminal window. Link: http://linux.101hacks.com/unix/nohup-command/
Using heroku console to get workers onto the jobs will only create create a temporary dyno for the job. To keep the jobs running without cli, you need to put the command into the Procfile as #Lucaksz suggested.
After deployment, you also need to scale the dyno formation, as heroku need to know how many dyno should be put onto the process type like this:
heroku ps:scale worker=1
More details can be read here https://devcenter.heroku.com/articles/scaling