Automating App Deployments and Config Management

1. Capistrano, Puppet,
and Chef
Automating App Deployment & Config Management

2. These tools have to do with
• Application Deployment
• Configuration Management
These are different.
Discuss.

3. In the beginning there was
scp : application deployment
ssh : configuration management
before things got complicated

4. Let's talk about
Application Deployment

5. simplest application deployment
1. scp app to production box.
2. Restart server. (optional)
3. Profit!

6. But there are always complications, like
“unpack app into a particular directory”
“scrub lock files or workspace directories”
“run database upgrade/tweak scripts”

7. 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!)

8. Capistrano
www.capify.org
Introduced around 2006
by Jamis Buck of 37Signals
written in Ruby, initally for Rails projects.

9. 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.

10. 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.

11. Simple "capfile" example

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

13. 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

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

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

16. 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)

17. OK

18. Let's talk about
Configuration Management

19. 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...

20. 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).

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

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

23. 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?

24. Puppet
http://www.puppetlabs.com
written in Ruby, evolved from cfengine

25. "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."

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

27. 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]

28. Simple example of a Puppet class
class ntp {
package { "ntp":
ensure => installed
}
service { "ntp":
ensure => running,
}
}

29. 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.)

30. 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.

31. 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.

32. Chef
http://www.opscode.com/chef/
written in ruby, evolved from Puppet

33. 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)

34. You start with an empty machine
install enough stuff to run chef-client (ruby,
chef)
and then run...chef-client

35. 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.

36. Chef vs Puppet
(This appears to be a big debate, like we
need that)

37. “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.

38. 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.

39. 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!

40. Questions?

41. Thanks!