Roland Moriz's Profile

It would be interesting to see other options covered in the future.
Maybe:

https://github.com/jcupitt/ruby-vips
https://github.com/eltiare/carrierwave-vips

can finally help to replace ImageMagick…

Srsly?

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.

Nice episode!

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:

http://acrmp.github.com/foodcritic/

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:

https://github.com/matschaffer/knife-solo
or:
https://github.com/tobami/littlechef