[chef] RE: Re: Cookbook Management for Complex Infrastructure


Chronological Thread 
  • From: "Fouts, Chris" < >
  • To: " " < >
  • Subject: [chef] RE: Re: Cookbook Management for Complex Infrastructure
  • Date: Mon, 27 Jul 2015 19:31:09 +0000
  • Accept-language: en-US

Yes Berksfile == git repo per cookbook is NOT correct. The tool supports the 
"rel:" keyword, so I have this lines in my Berksfile

cookbook 'my_coobook1', git: 
' /monolithic-repo.git',
 rel: 'cookbooks/my_cookbook1'
cookbook 'my_coobook2', git: 
' /monolithic-repo.git',
 rel: 'cookbooks/my_cookbook2'

Chris

-----Original Message-----
From: Lamont Granquist 
[mailto:
 
Sent: Monday, July 27, 2015 2:10 PM
To: 

Subject: [chef] Re: Cookbook Management for Complex Infrastructure



On 07/20/2015 01:47 PM, Erik Ogan wrote:
> Berkshelf is the current, prescribed tool for managing cookbooks. 
> Berkshelf (appears to) require each cookbook in its own repository.

As others have posted this is not correct.

Berkshelf was created to make the one-git-repo-per-cookbook model work really 
well, and there was a lot of drum beating that went along with the creating 
of the tool, but you can also use Berkshelf in at least two other modes of 
operation:

1 git repo, Berksfiles-per-cookbook:  This setup has cookbooks that each have 
individual Berksfiles in them which look like one-git-repo-per-cookbook-style 
cookbooks, but all of the role/wrapper/custom cookbooks are checked into one 
monolithic git repo.

1 git repo, 1 Berksfile:  The setup just has a single monolithic Berksfile in 
the cookbooks directory of the monolithic git-repo, used to pull down all the 
community cookbooks and lock them all via Berksfile.lock.





Archive powered by MHonArc 2.6.16.

§