Deploying a Rails Application to Amazon EC2 using Rubber: A Primer

If you’re inexperienced deploying Rails apps, or any apps for that matter, using EC2 for the first time can be rather daunting. All those acronyms! Elastic Block Store? Elastic IPs? WTF!? What happened to the hostnames, physical servers, and DNS configurations I know!?

So, naturally, you look for deployment help to get an instance running quickly. Rubber seems like a great candidate! Three commands, and it just works? Fantastic! Well, deployment is a rather difficult thing to automate, and providing a robust out of the box solution that fits everyone’s needs is rather difficult. In this case, the default
rubber vulcanize complete_passenger_postgresql
installs ALL KINDS of things that you probably don’t want for your tiny test app. There is even mention of the full stack being “pretty memory intensive” and requiring an m1.medium instance to be performant! Well gee, why do I need a MEDIUM instance costing $115/month ($0.16/hour X 24 X 30) for my staging app? That’s ridiculous!

Most people would probably give up on Rubber and just try installing the software manually — all those linux packages, apache, postgres, passenger, rails, dozens of gems. Sure, it’d be faster to get it up and running, and I would actually recommend this approach to beginners to learn the tech stack before turning to automation. Rubber is NOT A BEGINNER’S TOOL, and trying to use it without understanding what it does will be an exercise in extreme frustration (trust me).

So, a more sane baseline setup, for a simple deployment of a staging instance with rails/apache/passenger and your favorite database:

rubber vulcanize base
rubber vulcanize apache
rubber vulcanize passenger
rubber vulcanize postgresql (or mysql of course)

This avoids all the extraneous monitoring software good for production servers, but not so good for your staging instances. However, of course, isolating the bare configurations doesn’t guarantee that they’ll work well together, so there are a number of additional changes to make to the generated .rb deployment instructions and .yml configurations:

1. Leave the default scm deployment configuration as it is: trying to check out the source during initial deployment will likely fail, as the new instance will not yet have had a ssh keypair generated.
2. Figure out the various roles for your particular deployment. For a vanilla apache/passenger/postgres environment, mine looked like this: web,apache,app,passenger,db,postgresql,postgresql_master
3. Change rubber_passenger.yml to listen on the default web ports: 80, and 443 if you have SSL support.

Undoubtedly you will have other configuration tweaks to make, but that should cover the most important stuff. Ideally, someone should come up with a base_apache_passenger rubber template that includes the above tweaks. Good luck!