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. Cheers, Dang On 10/17/12 9:17 AM, "Ranjib Dey" <
">
> 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 best ranjib On Wed, Oct 17, 2012 at 8:41 PM, Nguyen, Dang
<
" target="_blank">
> wrote:
|
Archive powered by MHonArc 2.6.16.