kodefoo - Home

Conference time again

2007-05-10T18:21:00Z

Yes, it’s that time of year again and Kodefoo will be heading off to both XTech 2007 and Reboot 9.0. We’ll be taking on some session charing duties and we’re also running the lightning talks session (think 20:20) at XTech this year. The sessions we’ll be involved in are :

Time	Room	Session
2007-05-16 16:00	Amphitheatre A	Nabaztag and the Emergence of the Internet of Things Rafi Haladjian (Violet)
2007-05-16 16:45	Amphitheatre A	Pipelines: Plumbing for the next web Ian Forrester (BBC)
2007-05-17 11:00	Amphitheatre C	Making Massive Datasets Universally Accessible and Useful Jon Trowbridge (Google, Inc.)
2007-05-17 11:45	Amphitheatre C	Aware and Loca: Letting others know where you are John Evans (HIIT)
2007-05-18 09:00	Grand Palais	The implications of OpenID Simon Willison (-)
2007-05-18 09:45	Grand Palais	Open AIM as it relates to you Thomas Crenshaw (AIM/AOL)

I can’t wait for these sessions, so I’d highly recommend attending if you can. If you’re in Paris and fancy meeting up then let us know !

Picture Perfect

2007-03-27T09:43:00Z

We’ve recently packaged up some software we created some time ago as our first product. Announcing ‘MMSAbility’. It allows you to easily accept MMS/Picture messages into your product-set by providing a (MMS) vendor-neutral interface for picture message parsing.

So if you’re interested in using picture messages to create community in your products, then get in touch.

Take a REST with Rails

2007-02-19T00:43:00Z

As my talk for our local Ruby User Group meetup , I’ve prepared a presentation about the new RESTful features in Rails 1.2. It covers changes to routing, generators and gives a quick overview of the REST architectural style, where it originated and how it applies to Rails. To demonstrate these concepts, a RESTful blog is created. This blog is then used as part of a final example that uses ActiveResource to consume RESTful resources.

Download “Take a REST with Rails” (odp) (pdf)

Download the sample code blog.tar.gz and slurpr.tar.gz

Download “Take a REST with Rails” (odp) (pdf)

Download the sample code blog.tar.gz and slurpr.tar.gz

Post-Talk update

I was pleased with the talk and there were some interesting questions at the end so I thought I’d compile a set of ‘more complete’ answers and document them here …

1. Does the number of routes increase from using the restful approach ?

It depends largely if you originally relied on the default controller/action/id model or if you try and create more intuitive routes. I think the REST approach provides a more intuitive URI structure, so if you prefer this model then I think the size of your routing file will be reduced by using the REST approach. See here for more interesting stats on this subject.

2. Which elements of simply_restful have been integrated into Rails 1.2 ?

My original answer wasn’t quite correct as I was confused by the map.resources nested block invocation. As part of the integration into the rails core the functionality of map.resources was modified to include this nested block form. So the answer is map.resources (with modifications), generators and route helpers. For more information see here.

3. How does Rails manage the fact that all browsers don’t support all the HTTP methods required (specifically PUT/DELETE) ?

With a hack ! Using the form_for helper with one of the new route helpers will cause a hidden field ‘_method’ to be added with the ‘real’ action specified whilst the form itself will use POST to submit. Rails then checks the _method variable and actually performs the request routing using the HTTP method specified in _method.

4. What about service discovery ?

I thought that WSDL could be used for service discovery and it turns out that this is true, at least as far as WSDL 2.0 is concerned !. This is more of a REST question than a REST on Rails question and I think the (quickest) explanation I could find was :

What’s the alternative to WSDL ? There was a proposal for a Web Resource Definition Language, sortof a RESTful WSDL. http://www.prescod.net/rest/wrdl/wrdl.html . That seems somewhat moribund. Potentially, the answer could be WSDL 2.0, which would leverage the REST-friendly features of SOAP 1.2. There doesn’t seem to be much demand among customers of WSDL 2.0 for this, however, so the working group hasn’t gotten around to working on this yet. More generally, I think the REST people would say that if you have the URI of a RESTful service and the schemas of the representations being transferred, you don’t need WSDL, since the basic actions and message exchange patterns are assumed to be those baked into HTTP. (from a comment on Adam Bosworth.)

I really enjoyed the debate and questions from the evening, although I’ll probably run through a few more practice sessions before I try and code in front of a room of 20 people again :)

Deploying Rails on Ubuntu Dapper

2007-02-18T23:42:00Z

Deploying Rails on Ubuntu Dapper can be a tricky proposition, with the typical solution using Apache as a proxy to Mongrel. This article demonstrates how to setup Apache2.2 (including Dapper .deb packages) with Mongrel utilizing the mod_proxy_balancer module for Apache.

Ubuntu is fast becoming the distribution of choice for many people, having the ease of deployment and solid package management system that you would expect from a Debian based distribution and also benefits from a fast release cycle that results in up to date versions of many popular packages. In particular, Ubuntu ‘Dapper’ is the first Ubuntu release to provide long term support (6 years from release) and has achieved a healthy level of security and stability (in no small part due to it’s Debian roots).

Currently, the most popular Rails deployment stack is Linux, Apache 2.2, Mongrel and MySQL. This can present a problem when attempting to install with Ubuntu Dapper as Apache 2.0 is the only available Apache package within the official Dapper repositories. There is always the option to compile a version of Apache from source (which certainly has some benefits) however all the benefits of using a package management system are lost when taking this approach.

The Mongrel based deployment stack

Mongrel is (currently) the preferred application server for deploying Rails in a commercial environment. There are other solutions e.g. mod_fcgid or lighttpd, however these have become less popular due to instability or lack of support.

The preferred configuration involves using Apache as a proxy server, that sends Rails requests to Mongrel whilst serving requests for static content itself e.g. images or CSS. Apache is very good at serving static content whereas Mongrel excels at serving Ruby, thus each server performs tasks it is suited to. The diagram below demonstrates this architecture :

Why so many Mongrels ?

Mongrel is a Web server (and HTTP library) for Ruby applications. It’s capable of running applications developed using the Ruby on Rails, Nitro and Camping frameworks. Unfortunately, the Rails framework isn’t thread-safe. This results in a Mongrel instance having to handle HTTP requests serially. This is obviously a problem for a site with a constant stream of traffic, as Mongrel wouldn’t be able to process concurrent requests.

The answer to this problem is to run many instances of Mongrel on different ports and proxy requests to them. This can be achieved in a number of ways, but the most popular is to use Apache 2.2 with mod_proxy_balancer (as shown in the diagram above). This does mean there is a configuration overhead in determining the optimum number of running Mongrel instances for your application (which will be examined later). Managing a large number of Mongrel instances is a time consuming exercise and is made easier by mongrel_cluster. mongrel_cluster is a set of scripts that allows easy management of Mongrel instances (across many Rails applications) via the init system.

Installing Ruby, Rails and MySQL

These are the meat and bones of our system, and are easily installed using a combination of the apt and Ruby gems package management systems :

NOTE: You will need to have enabled the Universe repository to obtain some of these packages.


sudo apt-get install ruby ri rdoc mysql-server libmysql-ruby 
sudo wget http://rubyforge.org/frs/download.php/17190/rubygems-0.9.2.tgz
tar -xvzf rubygems-0.9.2.tgz
cd rubygems-0.9.2
sudo ruby setup.rb
sudo gem install rails --include-dependencies

You can try creating a test Rails application by running :


rails railsapp

This should create a directory called ‘railsapp’ with the standard Rails application skeleton.

Installing Mongrel

You’ll need both Ruby and some build packages for Mongrel to be installed on your system :


sudo apt-get install build-essential ruby1.8-dev ruby1.8

You can then install Mongrel as a Ruby Gem (this should install all Ruby dependencies automagically) :


sudo gem install mongrel

Test your Mongrel install by running Mongrel in the root of a Rails application. If all is ok, you should be able to browse to your rails application at http://localhost:3000 :


cd rails_app/
mongrel_rails start -d
mongrel_rails stop

Installing mongrel_cluster

Once you have a successful Mongrel install, you can install mongrel cluster enabling you to manage your Mongrel instances.


sudo gem install mongrel_cluster

Installing Apache 2.2

Kodefoo have prepared a set of Apache 2.2 packages (for the i386 architecture). These packages have been backported from Ubuntu Feisty to Ubuntu Dapper. The packages are used for commercial hosting of Rails applications on Ubuntu Dapper by Kodefoo. The packages provided include mod_php and mod_perl for running LAMP stacks in addition to a Rails environment. The packages are provided in an apt repository to ease the install and update process. A package update process runs on a daily basis, checking to see if new packages have been released, if new packages have been made available for Feisty then these are backported for Dapper and added to the apt repository.

Before using this repository you must agree to the Terms Of Use . If you are unable to agree to this then do not use this repository.

Add the following line to your /etc/apt/sources.list

deb http://packages.kodefoo.com/ dapper main

Import the kodefoo repository GPG key into your apt repository keyring :


wget http://packages.kodefoo.com/release.asc
sudo apt-key add release.asc

Update the package indexes and install Apache 2.2 :


sudo apt-get update
sudo apt-get install apache2 apache2.2-common apache2-mpm-prefork apache2-utils

Configuring Apache 2.2, Mongrel and mongrel_cluster

There is a very good mongrel_cluster configuration guide available at the Mongrel site. It’s recommended you follow the guide there to configure your mongrel_cluster instances.

For the purposes of configuring Apache 2.2, it is assumed the mongrel_cluster has been configured to run three Mongrel instances starting at port 8000 (so there will be Mongrel instances listening for HTTP requests on ports 8000, 8001 and 8002). The example below should be adjusted appropriately if your configuration differs.

The following virtual host file proxies Rails requests to your local Mongrel instances (invoked via mongrel_cluster) but allows Apache to serve the static content.


<VirtualHost *>
   ServerName www.yourserver.com

   DocumentRoot /var/www/railsapp/public/

   <Directory "/var/www/railsapp/public">
     Options FollowSymLinks
     AllowOverride None
     Order allow,deny
     Allow from all
   </Directory>

   ErrorLog logs/railsapp_errors_log
   CustomLog logs/railsapp_log combined

   # this not only blocks access to .svn directories, but makes it appear
   # as though they aren't even there, not just that they are forbidden
   <DirectoryMatch "^/.*/\.svn/">
     ErrorDocument 403 /404.html
     Order allow,deny
     Deny from all
     Satisfy All
   </DirectoryMatch>

   <Proxy *>
    Order allow,deny
    Allow from all
   </Proxy>

   <Proxy balancer://mongrel_cluster>
     BalancerMember http://127.0.0.1:8000
     BalancerMember http://127.0.0.1:8001
     BalancerMember http://127.0.0.1:8002
   </Proxy>

   # This passes through remote_user to mongrel
   RewriteEngine On
   RewriteCond %{LA-U:REMOTE_USER} (.+)
   RewriteRule . - [E=RU:%1]
   RequestHeader add X-Forwarded-User %{RU}e

   # Now standard rewrite rules
   RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} -d
   RewriteRule ^(.+[^/])$ $1/ [R]

   RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} \.php
   RewriteRule ^(.*)$ $1 [QSA,L]

   RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f
   RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME}/index.html -f
   RewriteRule ^(.*)$ $1/index.html [QSA,L]

   RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f
   RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME}/index.php -f
   RewriteRule ^(.*)$ $1/index.php [QSA,L]

   RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} -d
   RewriteRule ^(.*)[^/]$ $1/ [QSA,L]

   RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f
   RewriteRule ^/(.*)$ balancer://mongrelcluster%{REQUEST_URI} [P,QSA,L]

</VirtualHost>

This file can be saved in /etc/apache2/sites-enabled/yoursite and enabled with :


sudo a2ensite

The configuration can be tested using :


sudo apache2ctl -t

Providing there were no errors, the installation and configuration should now be complete. When Apache is restarted, the Rails application will be served by Apache and Mongrel. If you have configured mongrel_cluster as an init script then Apache and Mongrel can be restarted using :


sudo /etc/init.d/mongrel_cluster restart && sudo /etc/init.d/apache2 restart

Performance tuning hints and tips

There are a number of areas that can be tuned for performance using this architecture. Typical considerations include :

The number of Mongrel instances, configured per Rails application served. There is no ‘magic’ number, however Kodefoo typically find a minimum of four instances is required. To perform individual application tuning look at How Many Mongrel Instances Should I Run ?
The default Apache 2.2 configuration can be improved (some suggestions here and here) and using one of the newer Apache MPM models can certainly help
The use of memcached can also help in moving load away from the database layer to a memory cached distributed layer. This can be useful for scaling large sites with high traffic levels, some pointers can be found here

We’ll be publishing a performance tuning article in the near future, so check back soon.

Attribution

Articles consulted whilst writing this article :