This might not work for you or any other use case but ours, anyway. When we started rolling out chef everywhere within the org, we were fortunate to include a process for being able to use community cookbooks while also giving us the ability to fork off those and customize them to our needs. We namespace our cookbook names to distinguish them from the community, whether they’re forked from the community or built from the ground up internally. For example, if the community cookbook is named apache and we customize it for our needs, the forked name would be prefixed with our own internal convention, such as “ours_apache”. If we develop our own apache cookbook that’s not forked from the community, it would still get the name “ours_apache”. So we end up with a bunch of our cookbooks with names like that. This lets us use either cookbook without any problems, so far. For auditing purposes (legal likes this part), this also allows us to draw the line where we used open source and where we developed something in-house.
On 10/17/12 9:17 AM, “Ranjib Dey” <email@example.com:firstname.lastname@example.org> wrote:
majority of the opscode cookbooks targets multiple platforms as well as re-uses other cookbooks hence the added complexity. In almost every cases you can come up with a simpler solution that is geared towards your specific need, given you understand that you might end up maintaining those cookbooks.
Initially (at least 2 year back) I used to maintain all our cookbooks , primarily because we run mostly centos/rel , and I didn’t like the some of the patterns enforced in the community cookbooks (like enforcing debian style site/mod management for apache in rel). Also this helped us keeping our cookbook repos slim and self contained.
Things started changing once the code base started getting bigger, we missed out a lot of neat community cookbooks that implements latest and greatest chef (as well as chef related tooling) features, the effort involved for refactoring steadily increased. And the frustrating part was most of those features were rapidly pouring in the community cookbooks. Not only that you can not use some other cookbook, just because of its dependency to another community cookbook (and you can not use that, as you have your own slim, trim, gym version ).
I think there are uses cases for both patterns (your own cookbooks vs community cookbooks + only a handful cookbooks that are unique to your infrastructure). If you are starting new with chef you might go with your very own set of cookbooks. To effectively use community cookbooks, you need incorporate certain other tooling as well (like librarian ). Also , you might end up maintaining your own fork of some cookbooks (temporarily). But if you can live with these pains, community cookbooks can be pretty rewarding. The initial learning curve is higher, but you end up maintaining much less code (and more importantly the relevant ones, that are unique to your infrastructure).
I belong to a service based company, so i’ll shamelessly say reusing and contributing back to the community cookbooks makes my life easier (though i have not been able to do this at all client places). But this might not be relevant to you
On Wed, Oct 17, 2012 at 8:41 PM, Nguyen, Dang <Dang.Nguyen@disney.commailto:Dang.Nguyen@disney.com> wrote:
My team uses the same methodology as John.
From: John Martinez
Sent: Wed, Oct 17, 2012 07:53 AM
Subject: [chef] Re: Cookbook Architecture
We do separate versions of cookbooks and define what versions to use
in environments. Package versions are node attributes.
So, the latter.
On Oct 17, 2012, at 7:48 AM, "email@example.com:firstname.lastname@example.org" <email@example.com:firstname.lastname@example.org> wrote:
We have come across this design pattern many times when building out our
cookbooks and can’t quite decide which makes the most sense. Do you write your
cookbook such that the latest version of the cookbook can install any version
of the application it is installing/configuring or do you create separate
versions of the cookbook for each version of the cookbook (i.e. each cookbook
version installs only one version of the software)? The Opscode cookbooks seem
to go with the first strategy but we have found we can make simpler cookbooks
by going with the second strategy.