Theo Schlossnagle: “I don’t care what you use: puppet, chef, bcfg2, cfengine – choose one and automate your configuration.” (Theo’s presentation was a highlight, check out the slides here.)
Allspaw and Hammond from Flickr: “If there’s only one thing you do, automate your infrastructure.”
There were lots of Puppet users at the conference, and Luke Kaines gave a good talk on it.
Interested in a Chef intro? Watch the video of Adam and Ezra’s talk:
From the Chef BoF:
- If you’re just doing application deployment of a typical webapp then running chef-solo on deploy might be just fine for you (it is for the Remix team).
- Ezra points out that he has a chef subproject on git that even strips out cap – chef-deploy (vs cap sudo’ing out to chef).
- Adam gave a good explanation of the Chef run model.
- It’s important to understand the basics of what’s going on behind the scenes – otherwise you’ll shell out right in the middle of your Chef scripts and be surprised by the run order.
- In short, all your Chef Resource statements are evaluated in a first pass. Then they’re executed.
- This gives Chef the opportunity to evaluate what’s to be done and optimize. Adam noted that included recipes are only executed once (analogous to ruby require’s)
- Adam also mentioned something kind of cool – if I have this right – Resource statements return the associated Resource object. And when you refer to the Resource the same way twice, you’re getting back the same Resource instance. So your included Recipes (for example) each have the opportunity to decorate a Resource defined earlier – if, say, it ought to be configured differently based on a combination of what else is getting installed on the box. Nice.
About the Author
