I deploy around 10-20 times a day. Doing this requires zero downtime deploys. I do this right now with unicorn and signals. I’m looking to move to Torquebox, but I’d need the ability to do seamless deploys. Searching the PDF for “downtime” only had one mention about Kirk/Jetty. It would be fantastic to show how torquebox can support zero downtime deploys (hopefully both rails and the services).
TorqueBox supports hot deployment, which loads a new version of the application without bring the Torquebox server down. The mechanism i describe in the book uses this, and there is a more detailed discussion on the underlying mechanism for it: http://torquebox.org/documentation/current/deployment.html
I’ve read the docs and am unclear on whether they’re describing a “zero downtime deploy”.
Kirk is very specific in their description: > Deploy new versions of your rack application without losing a single request.
Is this something torquebox does naturally? Or are their specific steps that should be taken to handle it w/ a load balancer?
No, “hot deployment” is not the same as “zero-downtime”. So when redeploying a torquebox app, there is a window in which requests can be missed. But because only the app has to start up and not the server (unlike traditional Ruby servers) the gap is small.
mod_cluster will handle this if you are running it with multiple torquebox instances (that in the Clustering chapter).
I didn’t see an explicit mention in the clustering chapter about hot deployment or zero-downtime. Did I miss it?
No, it’s not mentioned in detail. Here’s a blog post a wrote on the subject:
so when using mod_cluster, it sounds like if a request is dropped by a torquebox instance redeploying, we’ll be gauranteed that it will be retried on one of the other instances, right? But how do we make sure that the other instance isn’t also re-deploying and not ready to process requests? In the book it describes doing
torquebox deploy in the root of an app that has two torquebox instances running it on the same machine, and it says that both torquebox instances will pick up the new deployment since they are on the same file system. Or does
torquebox deploy deploy to the instances one-by-one automatically? What about domain mode, maybe there is a good way to do staggered redeployments to acheive zero-downtime with that? (Loved the book by the way so useful I can’t even begin to tell you how much I appreciate it:)
yeshow do we make sure that the other instance isn’t also re-deploying and not ready to process requests?
if both instances are down, the request will be lost. you must stager the redeploy of multiple instances.does
torquebox deploydeploy to the instances one-by-one automatically?
no. this command only works on a local filesystem. so the redeploy of multiple instances in the book is only by virtue of them sharing a filesystem. this is not a normal scenario in the real world. Instead, you would run torquebox deploy on each server and stager them.What about domain mode, maybe there is a good way to do staggered redeployments to acheive zero-downtime with that?
Yes, this is the advanced way to achieve much more complex architectures and deployment strategies, but it requires much more discussion. All of the underlying technology for this is provided by the JBoss platform, so it would be valuable to research that.
Cool, thanks for the quick answer! one more question though: regarding the blog post you mentioned earlier in the thread with more detail on how to acheive zero-downtime in torquebox http://deployingjruby.blogspot.com/2012/05/zero-downtime-deploys-with-jruby.html, For the last technique described where you redploy the new version of an app to a different web context while keeping the old one running: will torquebox still realize that its the same app and re-use the Infinispan cache? will it still run only one instance of each singleton jobs & services, or will there be a brief period where both the old and new versions will be running?
It will not recognize them as the same app. So you will have duplicate jobs and such. True zero-downtime deploy is a complicated beast.