[typo] Deploying Ruby on Rails Applications

William Ross will at spanner.org
Thu Jul 17 04:10:19 EDT 2008


On 16 Jul 2008, at 14:38, Chet Farmer wrote:
>
> On Jul 16, 2008, at 6:10 AM, Scott Likens wrote:
>>>
>>> I'll certainly agree with that.  Getting mongrel working with  
>>> mod_proxy was essentially an exercise in Google and reading blogs.
>>
>> <snip>
>>> Yes.  And, frankly, Ruby + gems on most Linux distros is in such a  
>>> state that I end up maintaining my own Ruby install from source.   
>>> Given the pain of the recent security holes (for example), I find  
>>> that this is actually driving me to think I should can it and go  
>>> for the same suite of PHP apps as everyone else.
>>
>> I will agree with that, as Debian Etch currently has Ruby 1.8.4(2?  
>> i forget) with Rubygems 0.92.  However is that Ruby's problem? or  
>> the Linux distribution you chose?
>
> It's definitely Ruby's problem if PHP, Perl, Python, etc., are all  
> running fine out of the box.

I'd just like to put in a vote for not Ruby's problem here. I've never  
had any trouble deploying rails applications. I used to be a mod_perl  
hacker and that was much, much harder to set up and keep going.

The only difference, in my view, is that Rails isn't a commodity  
solution yet. You can't easily buy some Rails and you don't get an  
option on the Ubuntu disc to install a good starting Rails setup. A  
Rails app needs a port, I suppose, so you can't really run one unless  
you have your own box and it's really not something you should bother  
with if you just want your blog to be fashionably served.

If you have some reason to want Apache as your front end, you have to  
know how to proxy to another port. The documentation for that is here:

	http://httpd.apache.org/docs/2.2/mod/mod_proxy.html

and includes straightforward cut and paste configuration along with  
some very useful warnings. I don't know anything about mod_rails, but  
I suspect that unless you want to get fancy with the apache lifecycle,  
you don't need that much integration. Nginx is a much better front end  
anyway: fast and simple. There's an excellent cargo config here:

	http://brainspl.at/articles/2006/09/12/new-nginx-conf-with-rails-caching

and some thorough benchmarking here:

	http://blog.kovyrin.net/2006/08/28/ruby-performance-results/

I've found it perfectly straightforward to set up typo (or radiant, or  
mephisto: I have sites running on each) using mongrel_cluster,  
capistrano and an nginx front end. The only things I had to compile  
were nginx and sphinx. Everything else is apt-gettable (and I think  
now nginx is too). I use three application servers and one database  
server and deliver over 100,000 pages a day with typically about a  
quarter load. It scales well enough for me and it's over two years  
since the last boot. I certainly couldn't say that when I was  
desperately propping up 100MB apache processes.

> Here, you're defaulting back to a knee-jerk defense of what is  
> clearly your pet language. That has no place here. Compared to LAMP- 
> stack stuff, RoR applications are much harder to set up and deploy.  
> They require a totally different approach, and that approach is very  
> poorly documented. This isn't a controversial statement.


The documentation is fine. The only problem is that there is no single  
orthodox solution. I see that as a strength, but it does mean that  
some expertise is required to choose your recipe. You (Chet) are right  
in the sense that for the beginner, a working typo blog is probably  
not as easy to get to as a working php-based blog. For anyone who  
knows what they're doing there's really no difference and the rails  
model is much easier to maintain.

Most of this is general to rails so it's also worth mentioning that  
Frédéric is very diligent and responsive and the software is good. He  
deserves more appreciation, i think.

best,

will









>
>
> Here, you're defaulting back to a knee-jerk defense of what is  
> clearly your pet language. That has no place here. Compared to LAMP- 
> stack stuff, RoR applications are much harder to set up and deploy.  
> They require a totally different approach, and that approach is very  
> poorly documented. This isn't a controversial statement.
>
>
>
>
> ---
> "Don't let your mongoose get cold or dirty, or it will die."
> (Animals as Friends and How to Keep Them, by Shaw & Fisher, Dent 1939)
>
> _______________________________________________
> Typo-list mailing list
> Typo-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/typo-list



More information about the Typo-list mailing list