capistrano, puppet, and chef

Capistrano, Puppet, and Chef

Automating App Deployment & Config Management

These tools have to do with

• Application Deployment

• Configuration Management

These are different.

Discuss.

In the beginning there was

scp : application deployment

ssh : configuration management

before things got complicated

Let's talk about

Application Deployment

simplest application deployment

1. scp app to production box.

2. Restart server. (optional)

3. Profit!

But there are always complications, like

“unpack app into a particular directory”

“scrub lock files or workspace directories”

“run database upgrade/tweak scripts”

These additional bits were usually done

a) by hand (ssh)

b) with deploy scripts living on the servers

c) or not done at all (oops!)

Capistranowww.capify.org

Introduced around 2006 by Jamis Buck of 37Signals

written in Ruby, initally for Rails projects.

Mainly because ruby on rails, particularly in production settings, had to use a ruby server called "mongrel" which was fast, but an absolute pain to restart. PAIN.

Simplest Explanation

• Lets you to write scripts that say "ssh onto this machine and do this thing."

• You don't have to have magic scripts living on your servers, they can be source.

• You can start being clever, and programming your deployment actions.

Simple "capfile" example

Simple "capfile" with "roles", you get the idea

Nice things Capistrano introduced:

Automate deploys with ONE set of files

The files DON’T have to live on the production server

The language (Ruby) allows some abstraction and finesse not available in blunt force shell scripting

Now the application deployment step can be coded and tested like the rest of the project.

And the deployment scripts can be strengthened, we all happy. Example:

Unfortunately, Capistrano's future looks a little uncertain (in 2011). The project page redirects to a github page, which points to stale documentation. It seems widely used, but not well supported.

May be a bit like CruiseControl (the early awesome build server) the tool may have hit its "use by" date.

Not sure what the successor is. Vlad The Deployer? (http://rubyhitsquad.com/Vlad_the_Deployer.html)

OK

Let's talk about

Configuration Management

This is where, on a new machine, you make sure

your apache's got mods

your ruby's got gems

your php's got pears

your java's got...version

All those things you remember, or forget, and then...

This happens a lot:

One person knows how all the servers get configured. One awesome person.

or

Each server gets set up differently depending on who set them up. Awesomeness not a requirement. Medication helps.

and

Server setups are build by hand (ssh, ssh, ssh) from memory (or checklists written on forearms).

This (sort of ) worked a little OK when servers were physical, so setting them up was a special magic ceremony.

But when servers became virtual, the magic wore off, and the underlying dumbness shone through.

Even for small projects, why can't we have:

• Configurations defined in source.

• Repeatable, consistent configs through test, stage, & production.

• Smart configurations that, say, enforce version levels and don't forget libraries.

Why?

Puppet

http://www.puppetlabs.com

written in Ruby, evolved from cfengine

"Puppet is typically (but not always) used in a client/server formation, with all of your clients talking to one or more central servers. Each client contacts the server periodically (every half hour, by default), downloads the latest configuration, and makes sure it is in sync with that configuration. Once done, the client can send a report back to the server indicating if anything needed to change."

The server is called the "Puppet Master". Creepy, but cool.

idempotent |ˈīdemˌpōtənt| Mathematics

adjective

denoting an element of a set that is unchanged in value when multiplied or otherwise operated on by itself.

noun

an element of this type.

ORIGIN late 19th cent.: from Latin idem ‘same’ + potent 1 .

The term can also be used to describe an initialisation subroutine that is arranged to perform some critical action exactly once, even if the routine is called several times.

[ Jargon File]

Simple example of a Puppet class

class ntp { package { "ntp": ensure => installed } service { "ntp": ensure => running, }}

Simple example of a node description

node myserver { include ntp}

This instructs puppet to make sure ntp is installed and running on "myserver"

(I left out the definition of "ntp" as a "resource". A big part of the Puppet DSL is a rich ability to define resources, their files, locations, permissions, just about everything about them.)

Puppet manifests are declarative, as opposed to imperative.

The DSL is not Ruby, as you're not writing scripts, you're writing definitions.

Install order is determined through dependencies.

And being idempotent, the puppet master will make sure the systems match the definitions.

This is kind of cool, in that you can implement changes across machines automatically just by updating the manifext in the puppet master.

Kind of scary, kind of cool.

Chef

http://www.opscode.com/chef/

written in ruby, evolved from Puppet

Chef is built around a chef server, which contains

• deployment scripts (called cookbooks and recipes)

• config instructions for machines (called nodes)

• security details for all (pem pem pem)

You start with an empty machine

install enough stuff to run chef-client (ruby, chef)

and then run...chef-client

As with Puppet, it is idempotent, so you can re-run it again and again to confirm or update config.

Chef recipes are imperitive, as opposed to declarative.

The DSL is extended Ruby, so you can write scripts, as well as definitions.

Install order is determined through script order, no dependency checking.

Chef vs Puppet

(This appears to be a big debate, like we need that)

“Chef vs. Puppet”

"Declarative" vs "Imperative"... oh, shoot me now.

(IMHO) Devs like Chef, because they can script it

(IMHO) Ops like Puppet, because its a set of rules

Both sides claim the other is "too complicated".

Go figure.

What next?

There are a number of other tools in the space:

App Deploy: Capistrano, ControlTier, Fabric, Func, mCollective

SysConfig: Bcfg2, Chef, Puppet, cfengine, Smart Frog

Cloud/VM: Xen, Ixc, openVZ, Eucalyptus, KVM

OS Install: Kickstart, Jumpstart, Cobbler, OpenQRM, xCAT

Hard for them to get momentum & critical mass?

We may get further definition, hopefully simplification.

Summing up

Application Deployment.

Configuration Management

Its nice to know these can be described in code, checked into source code control, tested, and then deployed.

I mean it is really nice!

Questions?

Thanks!