wr0ngway / rubber

A capistrano/rails plugin that makes it easy to deploy/manage/scale to EC2

Home | Edit | New

Quick Start

You can follow these steps to create a demo app on a single instance

Create a simple rails project

rails rubbertest
cd rubbertest
./script/generate scaffold post title:string body:text

Install rubber

First install the gem:

sudo gem install rubber # or wr0ngway-rubber to get the gem from github

Then vulcanize your project, for rails this is via the vulcanize generator:

./script/generate vulcanize complete_passenger_mysql

For non-rails projects, there is a convenience script bundled with the gem:

vulcanize complete_passenger_mysql

The complete_passenger_mysql generator gives you a deployment setup which includes passenger, apache, haproxy, mysql (automatic master/slave replication if you create other instances in the mysql_slave role) monit and munin.

Configure rubber

Edit config/rubber/rubber.yml. To do a simple demo, you need real values for these keys:

  • cloud_providers → aws → access_key
  • cloud_providers → aws → secret_access_key
  • cloud_providers → aws → account
  • cloud_providers → aws → key_name
  • cloud_providers → aws → key_file

See the FAQ if having connection issues.

For a real app, you should go through all the settings in rubber.yml as well as the settings in rubber-MODULE.yml which contains settings specific to each MODULE (apache, passenger, etc.)

Create, bootstrap, then deploy to instance

Use the convenience task which creates a single instance with all needed roles. This is also very useful for environments other than production so that each developer can create their own complete staging instance to test on:

cap rubber:create_staging
# Hit enter at prompts to accept the defaults

Or do the entire process manually:

cap rubber:create
cap rubber:bootstrap
cap deploy

Then you should be able to browse to http://production.foo.com – rubber maps aliases to instances in the /etc/hosts file by default, so you don’t need your own domain for the demo, however with your own domain you can map aliases to IPs using a dns provider like nettica/zerigo. Note that rubber:bootstrap should be idempotent, so feel free to run it multiple times in the event of a failure like a timeout getting gems from rubyforge.

Create a separate staging environment

Want each developer to have their own custom staging instance on demand? Easy, just:

cp config/environments/production.rb config/environments/myenv.rb
RUBBER_ENV=myenv cap rubber:create_staging

If you accepted the defaults, you should now be able to browse to http://myenv.foo.com By default, these instances are isolated from each other with AWS security groups, so even if you have some hardcoded addresses in your production config, your production servers will be safe.

Create an admin server

If you want to be able to check on server statistics (munin) or hit the monit/haproxy web admin UIs, edit rubber.yml to set web_tools_user/password, then:

ALIAS=tools ROLES=web_tools cap rubber:create
cap rubber:bootstrap
cap deploy

Now you can hit http://tools.foo.com:8080 to see stats on all the servers in your cluster. Note that clusters are isolated by RUBBER_ENV/RAILS_ENV, so don’t expect to see your staging server’s data in your production server’s web admin. If you only want a single production instance, you can add the web_tools role when creating that production instance. As an additional benefit, monit and munin are configured to automatically send email to admin_email (rubber.yml) whenever anything interesting happens (restart of services, too much machine load, not enough disk space, etc).

To add another app server to an existing deployment

The roles in the default templates can scale horizontally by default, so scaling up to handle increased app server load is as simple as:

ALIAS=app02 ROLES=app cap rubber:create
cap rubber:bootstrap
cap deploy

For a more complex production setup

Since the roles in the default templates are horizontally scalable by default, you can break those roles out onto whatever instances makes sense for your deployment, and scale them all independently:

ALIAS=web01 ROLES=web cap rubber:create
ALIAS=app01 ROLES=app cap rubber:create
ALIAS=app02 ROLES=app cap rubber:create
ALIAS=db01 ROLES=db:primary=true cap rubber:create # this is the mysql master
ALIAS=tools ROLES=web_tools cap rubber:create
cap rubber:bootstrap
cap deploy
# add a mysql slave too
ALIAS=db02 ROLES=db cap rubber:create
cap rubber:bootstrap
cap deploy

Note the separate instances for mysql masters and slaves – rubber automatically sets up replication for any new slave that gets created, though I leave it up to your application code to determine how to load balance.

Last edited by wr0ngway, Tue Oct 06 16:12:58 -0700 2009
Home | Edit | New
Versions: