capistrano, puppet, and chef
TRANSCRIPT
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!