SlideShare a Scribd company logo

Capistrano, Puppet, and Chef

•Download as KEY, PDF•
•
David Benjamin
David Benjamin

These tools relate to automating application deployment and configuration management. Capistrano was an early tool for automating application deployment through Ruby scripts without needing scripts on production servers. Puppet and Chef are tools for configuration management that define server configurations in code and work to ensure servers match those definitions. Puppet uses a declarative domain-specific language while Chef uses extended Ruby scripts. Both aim to provide repeatable, consistent server configurations across environments.

1 of 41
Downloaded 272 times
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!)
Capistrano www.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!

More Related Content

Capistrano, Puppet, and Chef

  • 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.
  • 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?
  • 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.
  • 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!