Please read for an updated status on RailsCasts:
Learn more or hide this
GitHub User: rmoriz
It would be interesting to see other options covered in the future.
can finally help to replace ImageMagick…
What do you do if your chef-server vm crashes and you need to provision new app servers to keep your main business running? ... exactly.
So either you have a redundant chef-server setup OR you'll get into trouble. It's just a matter of time.
Trading in a SPOF-less environment for convenience is a very, very bad DevOps guide.
Even large chef users (e.g. Engine Yard) tend to use chef-solo and their own services to replicate/push cookbooks.
Chef-Server adds a runtime dependency and needs it's own complex replication/failover strategy. If you rely on (a hosted) chef-server and it goes down, you can't reconfigure existing or launch new servers. A big no-go imho.
Sure, for a couple of unimportant VMs it's awesome to play and get a feeling with. But if your setup grows, you really don't want to have implicit configuration (like every 30mins with chef-client) and go with an explicit/push-style configuration.
After you read the wiki at http://wiki.opscode.com/ to understand the basic commands and architecture of chef and maybe some of the available opensource chef cookbooks you probably want to check footcritic:
It's a quite new project that analyzes cookbook code regarding the best/common practice of writing chef cookbooks.
E.g. I see Ryan uses the (old) Ruby-symbol syntax to access node data. As far as I remember this was deprecated in favour of the typical 'string'-keys syntax: http://acrmp.github.com/foodcritic/#FC001
I hope, some day, the opscode guys will also provide an "official" tool that makes life with chef-solo easier without having to use 3rd party tools...
Until that, you may want to check: