Why kitchen-cabinet?

UPDATE: (This update is a little late) there is now the ChefDK which pretty much does everything kitchen-cabinet did and more.

Last night I was at the San Diego DevOps meeting, and kitchen-cabinet came up. Some people were ‘skeptical’ about its usage. There are half a dozen or so tools that do the same sort of thing - meez, berks init, etc. Obviously its useful to use one of these tools - who can resist having to do less manual work! So what makes kitchen-cabinet specifically worth using?

I took a look at some of the other solutions out there before writing it, and I didn’t like what I saw. The code is often more complicated than it has to be, which makes it harder to maintain and update, and most of them don’t put any effort into providing a way to keeping existing cookbooks up to date. Besides that, none of the other tools set things up the way we like them.

So, I wrote kitchen-cabinet. Not only does it set things up with working configs that we use every day in our environment, but it does so using clean, concise, idiomatic ruby code.

cabinet does things like pull default values from your knife.rb if you don’t specify any of the optional flags. It will make or update the cookbook in your current directory if you do not specify a path. And perhaps the best part is that it uses erubis for all the config files - so they can be dynamic if need be! One of my main goals with kitchen-cabinet was to make it ‘future proof.’ There’s only one dynamic value in there right now, but there will be more to come.

TL;DR - It will make your life easier than the other tools.