1
votes

My company has been making a significant investment in Chef. We've built up a respectable library of cookbooks to automate our infrastructure. We've purposefully ignored Chef Server and the problem of cookbook sharing because we wanted to get some critical mass in our cookbooks first in order to drive how we solve that. Now we are there and we're exploring options. We already have a large investment in Artifactory and we're happily using it to store pretty much everything that comes out of our CI system across Windows/.NET and Java using nuget, ivy, maven, npm and bower repositories in Artifactory. I've been reading up on SO on this topic:

Managing custom cookbooks in a chef repo

What do Berkshelf-api and Chef Supermarket do differently than traditional artifact repositories?

And I'm struggling to see the point of Chef Server as a cookbook repo when we already have a general purpose artifact server in Artfiactory. The model that fits best into our current environment would be to publish cookbooks to Artifactory from our Jenkins jobs and use Berkshelf to pull them down from there as needed. From my reading it appears Berkshelf would be able to talk to Artifactory as a source, but I've yet to find details on how to do that. Every package manager we've encountered so far has some way to point it at Artifactory so I'm assuming there is doable.

Can anyone share any guidance on how best to approach this? Can anyone provide any details on if berkshelf can do this happily?

1
Long but still unclear, are you switching from chef_solo to chef-server way of doing things ? - Tensibai
Not sure what you mean by "chef_solo to chef-server way of doing things" exactly. We have been focused entirely on creating recipes and running them with chef-client+localmode/chef-solo. We have them in svn/git, and we pull and run them on machines where we want to. We're hesitant on throwing up a chef server because it's unclear what it actually does for us. It would be strange for us to stand up a chef server to act as a repo for cookbooks only when 90% of our technical artifacts reside in Artifactory. Using Chef Server to run the cookbooks on our nodes isn't of much value to us - kellyb
My main question is berkshelf be pointed at artifactory - kellyb
Well, quite broad but to answer on Berkshelf sources: they is berkshelf API server (included in supermarket, planned to be included in chef-server 12), path, and git/github sources. It's open source, if you need a specific plugin for artificatory you can write your own. If you have no need of search accross nodes to define peers/entries in some nodes, you can avoid using a chef-server. - Tensibai

1 Answers

5
votes

Most people using chef today deploy straight from their source code repositories. Since you're already using Artifactory you understand the importance of keeping an explicit record of your release at a point in time. A release artifact repository creates a healthy division between the act of building your software and deploying it onto a target system.

Using a dedicated instance of chef server (to store released cookbook versions) is just an option. It's an approach that happens to play nice with Berkself-api and allows you to continue to use Berkshelf as the tool to upload cookbooks into target chef servers.

There is nothing stopping you from using artifactory. You'll need to create an archive that contains your cookbook and all its dependencies, the berkshelf "package" does that.

berks package mycookbooks.tar.gz
mvn deploy:deploy-file \
    -Durl=$REPO_URL \
    -DrepositoryId=$REPO_ID \
    -DgroupId=org.myorg \
    -DartifactId=mycookbooks \
    -Dversion=1.2.3  \
    -Dpackaging=tar.gz \
    -Dfile=mycookbooks.tar.gz

The tarball can be used as part of your current chef-solo process or could optionally be used to populate a target chef server:

curl https://myrepo/org/myorg/1.2.3/mycookbooks-1.2.3.tar.gz
tar zxvf mycookbooks-1.2.3.tar.gz
knife cookbooks upload --all --environment my-prod-env

The "environment" option will set the cookbook version constraints on a chef environment, useful if you want to be certain which versions are applied at run-time.