At 37signals, we've been running Apache 2.2 with HAProxy against monit-watched Mongrels for a few years. There are a lot of perfectly valid, solid answers from those questions. Which web server do you run in front? Do you go with Apache, nginx, or even lighttpd? Do you rely on the built-in proxies of the web server or do you go with something like HAProxy or Pound? How many mongrels do you run behind it? Do you run them under process supervision with monit or god? And for many good reasons: It's stable, it's versatile, it's fast.īut it's also a jungle of options. Today, Mongrel (and it's ilk of similar Ruby-based web servers such as Thin and Ebb) still the predominate deployment environment.
We could just use HTTP! So packs of Mongrels were thrown behind all sorts of proxies and load balancers. Then came Mongrel and the realization that we didn't need Yet Another Protocol to let application servers and web servers talk together. But the platform really hadn't seen active development for a very long time and while things worked, they did seem a bit creaky, and there was too much gotcha-voodoo that you had to get down to run it well. We used to do that for development mode as the entire stack would reload between each request. Heck, in the early days, you could even run Rails as CGI, if you didn't have a whole lot of load. I launched Basecamp on mod_ruby back when I just had 1 application and didn't care that I then couldn't run more without them stepping over each other. Rails has traveled many different roads to deployment over the past five years. (If you don't want to bother with the history lesson, just skip straight to the answer) Myth #1: Rails is hard to deploy (DHH) Myth #1: Rails is hard to deployīy David Heinemeier Hansson on November 13, 2008
0 kommentar(er)
