Sign in through GitHub

RailsCasts Pro episodes are now free!

Learn more or hide this

Roland Moriz's Profile

GitHub User: rmoriz


Comments by Roland Moriz


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.


Nice episode!

After you read the wiki at 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:

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: