Recently I have been spearheading a project at $WORK based on the configuration management tool Chef. It has been around for over a decade now so the ecosystem and associated tooling is pretty mature, which can sometimes be a double edged sword. Many of the rough edges and edge cases have been taken care of (yay!), but there is a long tail of best practices, tools, and internals that have changed over the years (noooo!). When ChefDK was introduced it lowered the starting friction quite a bit, and the new Chef Workstation is supposed to help even more but this is still a non-trivial problem.

What am I even looking at here?

Wrapper cookbooks? Vendored cookbooks? Custom resources? Chefspec? Inspec? Librarian? Berkshelf? LWRPs? Chef-zero? Chef-solo? Chef Automate? Just trying to find out which thing you should be using makes an already steep learning curve just a little bit steeper. Not to mention that the consistent culinary theme can make Google searches exasperating. I just want to automate some infrastructure over here!

It can be overwhelming looking at the ecosystem of tools and best practices and the landscape is evolving. “Up to date” is a moving target. Blog articles, paid learning platforms, and Stackoverflow entries don’t always reflect the state of the art with any project ten years old, and Chef is no different. That makes it difficult If you are like me and want to do things The Right Way© off the bat with the most up to date best practices, integrating the most productive tools into your workflow.

But if you do that you risk falling down a serious yak shaving rabbithole and stalling out the whole initiative.

So don’t.

When it really comes down to it just do the least amount of work necessary to get something out the door and keep the momentum going. Write simple recipes with chef resource primitives in repetition. Use an off the shelf supermarket cookbook and modify it just a little bit to get it to work for you. It’s all good as long as you are making progress.

Perfect is the enemy of good

Don’t get overwhelmed and overthink yourself into paralysis. As Voltaire said, “Perfect is the enemy of good”, so it really is okay to make something just good enough that it works.

You’re still learning, and that’s OK.

This is going to be difficult at times, and that’s OK.

The products of your initial forays into configuration management are going to feel simple and brittle, and that’s OK, too.

Once you’ve established some momentum and are more experienced in your journey with Chef, then revisit these early cookbooks and refactor them to use attributes instead of hard-coded values, or use custom resources for repeatable, flexible, and succinct recipes. As with anything else, with some consistent time and effort the advanced concepts will start to make sense and workflows will start to become second nature.

OK that’s great, but it’s 2018? Where do I actually start? (TL;DR)

The simplest way to use Chef is to write a cookbook, copy that cookbook to a cookbooks directory on the server you want to manage, install the chef client, and run the chef client in local mode against your cookbook with sudo chef-client --local-mode. BOOM! Congratulations you just did a thing!

Looked through the documentation and you’re not sure how to write a cookbook? Thankfully Chef (the company behind the product) has made available a gratis, constantly updated, modular learning management platform for the Chef ecosystem at Learn Chef Rally. Just starting and trying to find your feet? There’s a track for that. Deploying to AWS or Azure? Check. Looking to go in-depth in testing? Got your back.

Chef Rally does a pretty great job of guiding you through the sometimes muddled waters and shortening the time needed for you to get to a minimum viable product with Chef out the door.

I guess the moral of the story is this: sure the mountain looks tall, but instead of planning for a year on how to reach the summit just consistently put one foot in front of the other and you will make your way up before you know it.