Unixmonkey.net

Pushing your app to the real world with Rails can be a very daunting task to someone who is used to just uploading flat html or php files.

If you’ve never dealt with Apache, mod_rewrite, or proxy servers, prepare to spend a lot of time hammering out a solution. Worried about performance, or your need to scale out at a later date? Pick a solution that won’t leave you wondering if your site will be able to take a spike in traffic.

For Rails, there are lots of deployment strategies, some are tuned for compatibility with shared hosting (fastcgi), and some are built for speed and minimum configuration (Litespeed Nginx and Lighttpd), and some are built to leverage the strength and flexibility of stable and established server software (Apache+Mongrel).

If you want to scale, you’re going to need a load balancing proxy. The choices here are pound, pen, and apache’s mod_proxy_balancer.

An abundance of choice is a double-edged sword. Competition is good in any arena, but it makes it very hard for someone who hasn’t tried them all to choose one.

I’ve chosen to setup my Rails server using the Apache+Mongrel+mod_proxy_balancer combination.

For the operating system, I’ve chosen the newest Ubuntu 7.10 (Gusty) server. Ubuntu uses the Debian-style apt package management, but with more current packages than Debian stable, and is the current cool kid on the block for Linux systems. I have been using Ubuntu for years and can attest to its stability and cutting edge (but not bleeding edge) packages.

I’ve gone through and built a Rails server by hand before, but poorly documenting what I had done, and not securing it properly. When I stumbled upon Slicehost’s server setup articles, I knew I had found exactly what I needed to build a server configured like a pro, and all the documentation I should have written in the first place.

Here is the step-by-step setup for a production Rails server. I’ve tested this setup and can vouch for its awesomeness. I encourage you to make some changes specific to your setup where appropriate. You should be able to skip unneccesary stuff like php and virtual hosts if you don’t need them.

Ubunty Setup – part 1
Ubunty Setup – part 2
Myql and Rails
Apache and PHP
Apache Virtual Hosts
Vhosts and permissions
Apache Vhosts, Rails and Mongrels
Mongrel Clustering
Subversion intro
Setting up svnserve
Securing svnserve with ssh
Setting up Capistrano
Setting up Piston to manage plugins

As you can see, most of these are from Slicehost’s documentation articles. They also detail setup for several other major linux distributions and other deployment strategies like nginx. Major props to slicehost for putting such excellent documentation together.

Twas the morning before Christmas, and all through the office, not a creature was stirring, but me and my mouse. The code was checked in to the repo with care, in hopes a new feature soon would be there.

I sit in my sweater and hear the keys tap. I’m thinking of taking a stare-at-the-screen nap. When out in the server room there arose such a clatter. I jumped from my desk to see what was the matter. Away to the NOC I flew like a flash. Tore open the door and stroked my mustache.

The LEDs in the rack set the room all aglow, and gave a luster of blue and red, don’t you know? When what to my bloodshot eyes should appear, but a shower of sparks shooting out from the rear.

Out popped a fat man who ran out plenty quick, I knew in a moment it must be saint Nick. You bastard! I cried, and I called for my crew. Now, Mike!, Now Matt!, Now Jeremy!, Matt and Chicago Matt too! To the top of the building! Climb up that side wall! And get that fat jerk before his deer dash away all!

When we got to the top we had missed him by seconds, and the feeling in my gut was very much unpleasant. Back down in the server room the hard drives had been pulled, the tapes were all strewn out, and it was starting to flood.

That bastard had blown some metal filings in the air intake, then the power went out and it was all I could take. I went down to the bar and ordered a brew, then ordered 10 whiskeys and downed them all too.

When I came back to the office and threw up on the floor. The boss handed my my last paycheck and kicked me out the door. I got a new offer the very next day, making much more than double the pay. Thank you Santa, for this Christmas-time gift. Next year I’m definitely leaving you a tip.

If you tried to update rubygems today like me, its possible you got hit with a nasty error message running gem after the successful update to rubygems-1.0.1.

root@localhost ~:#gem -v
/usr/bin/gem:23: uninitialized constant Gem::GemRunner (NameError)

gem_runner needs loading, so lets fix that by adding a require at the top of/usr/local/lib/site-ruby/1.8/rubygems.rb

...
require 'rubygems/rubygems_version'
require 'rubygems/defaults'
require 'rubygems/gem_runner' ## add this line
require 'thread'
...

There we go, now lets try:

root@localhost ~:# gem -v
1.0.1

Hooray! Working rubygems!

Update:

I found this is due to a problem with just the apt packages, and re-downloading and installing the tar.gz from rubyforge will also solve the problem.

During my recent adventure of setting up a production server for my rails applications, I stumbled upon some strange behavior where if I typed in a non-existent route or caused rails to barf all over itself, it would still show me a debug stack trace instead of the 400.html or 500.html living in /public

I uncommented the ENV[‘RAILS_ENV’] ||= ‘production’ line in /config/environment.rb, and the behavior persisted. I created a controller and view to echo out the environment, and did confirm that the app is running in production mode.

Googling only led to minor success where it was alluded in 1 or 2 posts that rails might think it is still running locally.

I started to eye my Apache mod_proxy_balancer + mongrel_cluster arrangement, where the cluster is set to spawn instances on 127.0.0.1 (localhost). After changing that local address to the outside facing address (192.168.x.x) and accessing it at that address in my vhost conf. Things were working as expected.

Now why would rails act this way? Searching the Rails API led me to the rescue_action and rescue_action_in_public methods, which led me to the local_request? method of determining which of the previous methods get called.

Great, now I’ve found the culprit. The code looks like the below:

# from rescue_action
if consider_all_requests_local || local_request?
  rescue_action_locally(exception)
 else
  rescue_action_in_public(exception)
end
 
#local_request?
def local_request?
  request.remote_addr == LOCALHOST and request.remote_ip == LOCALHOST
end

An easy fix is to drop a method that overrides this in application.rb

def local_request?
  return false if RAILS_ENV == 'production'
end

So, if you are having trouble making your app behave like its in production mode, give it a little spanking and remind it not to trust strangers with its debug trace.