Unixmonkey.net

We all know mongrel is the bees knees when it comes to serving Rails or Merb apps, even if its creator had a meltdown.

But there is a new kid on the block named thin that claims to run Rails apps almost twice as fast as mongrel. Check the graph.

A simple ‘gem install thin’ and going into your rails app and issuing ‘thin start’ is enough to get you shedding weight.

This is definitely something I’ll be playing with for the next few days.

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.

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.

Today I got an email from heroku.com to beta test their rails hosting. Its pretty cool as it provides a web interface to setting up and editing your ruby on rails applications.

Within seconds of my getting the email, I had logged in and created a new rails app. Heroku automatically added a database.yml file pre-populated with the correct database connection info.

I wanted to see if I could get mephisto running quickly, as my host for unixmonkey.net had gone down last week and shows no sign of returning. I opened their interactive rake terminal and ran db:schema:load and db:bootstrap and my app was instantly available to me to log in and start configuring.

Everything was working fine for several hours while I was setting up to make my first huge post, but them I went to check it out at 6pm, it was down with a 500 error (ngnix), even the main heroku.com was down with a “zero sized reply”. But I checked again 2 hours or so later, and it was back up.

This is hands-down the easiest deployment I’ve ever seen. Either start with a fresh rails app, or import yours as a gzipped tar file. The only downsides so far:

* There is is a 10mb limit per app, so you can’t freeze rails in your vendor directory.
* There is a bandwidth limit I hit almost immediately after making my app public, and you can’t admin your site at all when overlimit, best you can do is export a dump of your app.
* Your app is always running in development mode. (production and other are planned for later release).

All these are likely just part of growing pains, and will be addressed eventually.

I sent an email to their support staff and my questions were addressed within hours, even late on a Saturday. You can tell its a labor of love.

Sign up for the beta. Its really cool.