#373 Zero-Downtime Deployment pro
Here I show how to accomplish zero-downtime deployment using Unicorn. I also cover gotchas when working with migrations and how to put up a maintenance page when you do need to take down the site.
- Download:
- source code
- mp4
- m4v
- webm
- ogv
Thanks very much for this, Ryan - great timing considering the recent release of Phusion's new premium Passenger Enterprise product, which also allows for rolling restarts. It's good to learn that zero-downtime updates are also doable with 100% open source tools via Unicorn, albeit with increased memory requirements during restart.
Also thanks for including the bit about how to deploy a temporary site maintenance page - a very helpful tip!
Asset precompile can hinder zero downtime too, however it's relatively easy to fix too, if you use nginx:
and if you've done generating your public/assets, throw away public/oldassets, and move public/assets to its place!
Very good! I used to overlook asset precompiling.
Very good the part about maintenance! I loved heroku's simplicity of such tasks, however I didn't know it was this easy to accomplish about the same thing just with capistrano and a quick Nginx config.
Sometimes I am having with asset pipeline not get reloaded and the code itself.
It happend when I use this zero-downtime restart also regular restart.
To solve it I need to: cap unicorn:stop; sleep 10; cap unicorn:start
Has onyone encountered this?
I'm having a similar issue. unicorn:restart doesn't seem to be reloading the unicorn process at all. However nothing to do with the assets, the actual start time on the process doesn't change.
Same here. The USR2 signal or quit process isn't acting as expected...
Similar issue as well. Is there any fix for this as of right now?
I know this is old but since I've lost 12 hours, leaving it for future reference...
My restart went fine and new PIDS for unicorn where given... but if I deleted "old" release folder it would break (unicorn was still pointing there). I thought it has to do with symlinking the in the wrong moment, but it was more sinister...
The unicorne process points to the wrong Gemfile, it fails or something and dies silently. (Ok not silently, but I overlooked).
GemFile not found
Unicorn restart/upgrade doesn't work
Adding this to my unicorn.rb solved the issue
You can also set ENV variable when invoking form capistrano like this, or probably just using capistrano-unicorn gem would be enough!
*It's really important that after change you stop/start unicorn after first redeploy. After that the "before_exec" block will go in memory and wait for the next deploy!
Thanks Ryan for this episode. Yet to watch this. I would like to know whether this work with Ruby1.8.7?
For some strange reasons i keep getting
the task `unicorn:setup' does not exist
cap unicorn:setup unicorn:stop unicorn:startwhen i type in
Same here.
I'm a little confused about these line:
Wouldn't that set the
old_pid
variable to the filename of the unicorn.pid.oldpid file, and then compare that filename with the pid of the new server? For example, it would expand to:Or am I misunderstanding something?
Hi guys, It seems that Capistrano has in fact now removed the cap deploy:web:[action] tasks. Being that I'm very new to Capistrano, could anyone point me to some info on how to get that functionality back?
Seems to be fixed in the github master. Meanwhile just switch back to 2.13.4 or use the master.
Same happening to me. switched to 2.13.4 but it doesn't have the cap deploy:web:[action] tasks also.
They are available as a gem now:
https://github.com/tvdeyen/capistrano-maintenance
More Details on why the where removed and what went wrong:
https://github.com/capistrano/capistrano/commit/4ece7902d5
Why does this file https://github.com/railscasts/373-zero-downtime-deployment/blob/master/blog-after/config/recipes/templates/nginx_unicorn.erb contain this twice:
if (-f $document_root/system/maintenance.html) {
return 503;
}
error_page 503 @maintenance;
location @maintenance {
rewrite ^(.*)$ /system/maintenance.html last;
break;
}
I ran into this issue after 5 deployments where the new master process would report a
Gemfile not found (Bundler::GemfileNotFound)
error and quit. It turn's out that the new master process was using a environment variable settingBUNDLE_GEMFILE
which referred to a older release that has been cleaned up and no longer exists.The only way to fix this at the time was to stop and start the unicorn process which defeat's the purpose of zero downtime deployment. To prevent this from happening in your unicorn config template add this block
you do have to run unicorn:setup and maybe stop and start the service to make sure the new config setting is picked up.
hi, great! I am trying to figure out how to get the right syntax highlighting for unicorn_init.erb as shown in the screencast?
If you are using these recipes and get an error on
run %q{eval "$(rbenv init -)"}
You can just remove that line and replace the PATH line above with:
See:
Syntax error running rbenv init
and
Running rbenv from capistrano
Can you post the full unicorn init you are using?
Here is the configuration I've used: https://gist.github.com/brauliobo/11298486
If you need just staging server you could use https://teatro.io/