[chef] Berkshelf with chef-repo: am I doing it right?


Chronological Thread 
  • From: Kevin Yank < >
  • To:
  • Subject: [chef] Berkshelf with chef-repo: am I doing it right?
  • Date: Fri, 29 Nov 2013 14:27:43 +1100

Hi all,

Although I’m used to maintaining a standard chef-repo for my organisation’s 
cookbooks and their dependencies, I’ve decided to adopt Berkshelf because it 
makes it easier to track “unofficial” cookbooks, and forks of “official” 
cookbooks that have tweaks or fixes that I need.

Although I have it pretty much working for me, I have the niggling sense that 
I’m not doing it quite right. And all of the documentation and guidance I 
have found online seems to assume you are using Berkshelf to manage the 
dependencies of a cookbook you are working on in isolation. I have found 
almost nothing in the way of guidance on how to use it in the context of a 
chef-repo.

Here’s what I’ve done:

1) Delete from my chef-repo all third-party cookbooks that I am simply using, 
not maintaining for my organisation.
2) Create a Berksfile in the root of my chef-repo, and list all of the 
cookbooks I have just deleted from my chef-repo.
3) ‘berks install’ to install them as Berkshelf-managed cookbooks.
4) ‘berks upload’ to upload all of the Berkshelf-managed cookbooks to my Chef 
Server.

While this works, it seems a little ungainly. Depending on whether I am 
uploading a berkshelf-managed cookbook or one of my own application’s 
cookbooks, I need to upload it to my Chef Server by different means (‘berks 
upload’ or ‘knife cookbook upload’).

Is this how others are using Berkshelf with a chef-repo, or have I missed 
something?

I get the sense many Berkshelf devotees choose to do without a chef-repo 
entirely, and instead maintain just a cookbook for their application. And 
while this may work fine for a chef-solo based workflow, I don’t see how you 
could do without node roles, environments, and data bags if you’re managing 
clusters of servers with Chef Server as I am.

Any guidance, pointers or thoughts appreciated.

--
Kevin Yank
Chief Technology Officer, Avalanche Technology Group
http://avalanche.com.au/

ph: +61 4 2241 0083


Attachment: smime.p7s
Description: S/MIME cryptographic signature




Archive powered by MHonArc 2.6.16.

§