Paul Dowman

I’ve been working hard on EC2 on Rails, version 0.9.5 is now available. Since my last post here there have been some major changes:

Capistrano tasks

There is now a rubygem available that provides Capistrano tasks to manage the instance. There are tasks to set the server’s timezone, install packages and rubygems, backup, restore, create and delete the database, set the MySQL root password, and more. To use these in your Rails project type:

> sudo gem install ec2onrails

Put Capfile in the root of your rails folder, and put deploy.rb in the config folder.

Then, from the root of your project type:

> cap ec2onrails:setup

This automatically sets your server’s timezone, installs any custom rubygems and Ubuntu packages, and creates your database for you. You can now deploy your rails app as you normally would:

> cap deploy:migrations

Another useful task for testing is:

> cap ec2onrails:restore_db_and_deploy

This recreates the database, restores data from an S3 bucket (specified in your deploy.rb), and deploys the app. I use this to prepare a staging server with the current production data and current production version of the app. After running this task I have an exact copy of my production server. I then deploy the latest version to this server before deploying it to production. This is a good way to be really sure your production deployment won’t fail (especially your migrations).

To see a list of all available Capistrano tasks:

> cap -T

New Ubuntu version

It’s now built with Ubuntu 7.10 “Gutsy”.

Support for new instance types

There are both i386 and x86_64 versions available to support the new EC2 instance types. So you can now use large and extra-large instances.

Multiple instances

The earlier versions only worked if your rails app was running on a single server. That was lame! Now you can have multiple instances using any combination of these roles: web server, app server, primary database. I’m working on adding a MySQL slave role and eventually a Memcache role.

For full instructions and details see the project web site.

I have released an update to FieldHints. This version fixes a bug with refreshing a FieldHints-enabled form field using AJAX.

Just a couple of announcements about my Ruby on Rails server image for EC2:

New version

There is a new server image with some minor changes and bug fixes. For details see the change log. I’ll keep the old image around for a while.

Mailing lists

I have created two Google groups, one for announcements only (new versions, etc.), and one for general discussion.

Ongoing work

I’m working on a build script so the image can be built from source. Then I will provide access to a subversion repository with the source. Some people have expressed an interest in contributing, which I’m really happy about! If you want to get involved, please join the mailing list!

You know those grey “hints”, or example entries, that web form fields sometimes have in them? The ones that disappear when you click into the field? I have written a JavaScript library to add those to your forms with just one line of HTML.

Check it out.

Need to set up a Ruby on Rails server? So do I, and chances are you need almost the same configuration as me. As of this writing 1845 people have bookmarked Coda Hale’s excellent guide to setting up Mongrel + Apache on del.icio.us. The article has 187 comments. Why should so many people each have to do the same thing?

The answer is a Rails server virtual appliance, and I’ve made one for Amazon’s EC2 hosting service.

A server is no longer a physical thing, and EC2 takes it one step further: they completely separate the concept of server images and instances. An image is like a snapshot of a server hard drive, stored in an unchangeable state in their S3 data storage service. An instance is a running server that was booted from a copy of this image. But the instance is transient; changes to it’s own working copy of the image don’t affect the original image that it was booted from, and because of this multiple server instances can be started from the same image. (Hence the “elastic” property, new instances can be created on demand, your server pool can grow and shrink dynamically.)

Now even the OS can be configured and tested once, and then simply deployed as part of the application. So how is that different from any of the third-party libraries and frameworks that we use as part of our applications? I assemble applications out of many pieces of third-party software. All of it is continually improved by other people, none of it requires painstaking building or configuration, and the OS can be used the same way.

So I’m going to continue working on my Ruby on Rails EC2 server image with the goal that you will be able to simply deploy your Rails app directly to it with Capistrano with little or no configuration.

Try it out, and tell me what you think!