6 Ruby on Rails Deployment Methods

A Critical Look

Various Deployment Methods

Image by Doug

Variety of Cloud Deployment choices

Each method has a tradeoff to be made

Let’s discuss 6 deployment methods

The Plain Vanilla AMI Method

Image by Allie

How it’s done

✓ Well-tested Amazon OpsWorks Standard recommendation.

✓ Each time a new node comes up fresh, it requires running all

Chef recipes.

✓ To automate this process, Cloud-init is used

Pros & Cons

Pros Cons

Requires no AMI management.

Straightforward,

Self-documenting

Updates and patches are applied very

quickly.

Bringing up new instances is extremely

slow, there are many moving parts, and

there’s a high risk of failure.

The Bake-Everything AMI Method

Image by Susy

How it’s done

✓ Proven to work at Amazon Video and Netflix.

✓ Runs all Chef recipes once, fetches the codebase and then bakes

and uses the AMI.

✓ Each change requires a new AMI and an ASG replacement within

the ELB, including code and environment changes.

Pros & Cons

Pros Cons

Fastest bringup

No installation

Low Error rates

Each code deployment requires baking

a new AMI.

Lot of Effort to avoid overheads

Harder to deploy hotfixes.

A Hybrid Method Using Chef to Handle

Complete Deployment

How it’s done

✓ Strikes a balance between the Plain Vanilla AMI and the Bake-

Everything AMI.

✓ An AMI is baked using Chef for configuration and environment, but

one can’t check the codebase or deploy the app.

✓ Chef does those once the node is brought up.

Pros & Cons

Pros Cons

Significantly faster than using a Plain

Vanilla AMI.

Ability to provide hotfixes is improved.

Chef dependence in production

A Hybrid Method Using Capistrano to Handle Code

Deployment

Img Src

How it’s done?

✓ Similar to the hybrid Chef deployment approach, but with code

deployed through Capistrano.

✓ Capistrano is a mature platform for deploying Rails code

✓ Fail-safe mechanisms and several other features make it better than

Chef.

Pros & Cons

Pros Cons

The same as for the Chef hybrid,

except that Capistrano is more mature

than Chef, especially in handling

repository failures.

Increased management overhead

Gap between environment and code is

wider

Managing the tools separately is

difficult.

The AMI-Bake and CRON-based Chef-client Method

How it’s done

✓ Allow auto-propagation of changes because each AMI runs chef-

client every N minutes.

✓ New AMIs are baked only for major changes.

✓ Provides continuous deployment

Pros & Cons

Pros Cons

Allows continuous code deployment. Prone to errors if Continuous

Integration is not stable.

Chef re-bootstraps aren’t reliable and

may fail.

The Cloud-Init and Docker Method

How it’s done

✓ Closer to a bake-everything solution while getting around bake-everything’s

biggest drawbacks.

✓ Allows AMIs to be baked once and rarely changes after that.

✓ Both the environment and the app code are contained inside an LXC

container, with each AMI consisting of one container.

✓ Upon code deployment, a new container is simply pushed, which provides

deployment-process flexibility.

Pros & Cons

Pros Cons

Docker helps with issues of

undocumented steps in image

creation.

Code and environment are tied

together.

Faster deployment

Docker is still in early phases of

development and suffers from some

growing pains, including a few bugs, a

limited tools ecosystem, some app

compatibility issues and a limited

feature set.