Here are a couple of representative threads on the Chef Mailing Lists where people are diligently seeking advice about alternative ways to use Chef:
Should we use a single GitHub repository for Chef cookbooks? Or one GitHub repository per cookbook? Why choose one or the other approach in a give situation? What are the potential benefits and tradeoffs? Does anybody really know? Are we over-thinking this issue? Maybe we all should take a deep breath, tear our hair out, throw Chef under the bus and just write fu#king shell scripts!
Like many of the tools we use in DevOps, Chef is powerful and complex and there are multiple good-practice possibilities for how to use it. Many people have an opinion based on their experience, but it’s often challenging to get a clear delineation of what’s important and why. Too often, we discuss and discuss the same issues over and over-to the point where our brains seize up and we get nothing done.
What’s the point of flogging a topic to death when there’s no fundamental truth to be found? Just pick a direction and run with it. If it doesn’t work out (and it will probably need some tweaking anyhow regardless) you can reiterate on it later.
I realize that infrastructure code lives at a lower level and is sometimes more challenging to change (full-stack engineers, anyone?). But at the end of the day, there may be no right way and no wrong way to do something-often it’s a matter of choosing among tradeoffs. If the direction were clear, everybody would be doing it that way already.
Going back to Chef cookbooks and repositories: The Berkshelf Way suggests that you put each cookbook in its own GitHub repository and give every cookbook its own Berksfile. With this approach, which I tend to prefer, you avoid putting cookbooks in a central repository altogether (and you may not even need a centralized “Chef” repository.)
This approach has the benefit of enabling tools like Berkshelf to easily manage all cookbook dependencies for you. It also allows you to treat each cookbook as an individual piece of versioned software. However, if you go the route of one Git repo per cookbook, you can end up with hundreds of repos, and managers often don’t like that. That’s the tradeoff…
What amazes me is how what is actually a pretty simple choice/process can be debated to the point of causing hypertension. Why do we all (myself included!) seem to need some form of external validation about whether or not our chosen approach is “right”? If we can just remember that these debates wouldn’t even occur if there were an agreed “right way,” we could all relax a bit and make our decisions with confidence-provided one understands the tradeoffs and what makes sense in one’s specific environment.
If you’re up against a funky choice with Chef, Puppet or other automation tools, reach out to us. We help folks make these kinds of decisions every day. We’ve seen how the pros and cons play out and can save your internal team months of debate. We can’t guarantee that our way is “the right way.” But it will be a valid approach that will keep you moving forward.