Librarian-Chef vs. Berkshelf


High Level

At a high level, Berkshelf allows you to manage your cookbooks as first-class citizens. In other words, given a Berkshelf workflow, your cookbooks will live in their own repositories (instead of one monolithic chef repo). You can easily clone-down, edit, upload, and test individual cookbooks.

Compare & Contrast

How does this differ from your previous workflow? The easiest way to think about it is that librian-chef commands work in the context of your chef-repo, whereas berks commands work in the context of your entire system.

Before Berkshelf:

With librarian-chef, all of your cookbooks lived in your central chef-repo. You used knife cookbook upload <cookbook> to upload your cookbooks, which looked for directories named the same as the cookbook you were trying to upload. The knife command looked only in the directories specified by your cookbook_path in your .chef/knife.rb file. Your Cheffile was used in conjunction with librarian-chef to manage any cookbooks that didn’t live in your chef-repo. This presented one of the major annoyances with Chef: since librarian-chef managed these cookbooks and the directories in which they lived, the workflow for editing them was tedious and hackish.

It went something like this…

There are ways to make the above process shorter such as scripting steps 2, 3, 7, and 8 as well as saving steps 9 and 10 until you are totall done working. And, to be fair, librarian-chef served the very important purpose at one time. However, the process of editing stuff you don’t own is still tedious and less than ideal.

Enter Berkshelf…

Berkshelf is wonderful because it simplifies the process, removes clutter, and allows cookbook development to be treated like real application development. With Berkshelf, you will still have a central chef-repo, which you will still use to manage your roles, environments, data-bags, and configs, which you will still manage using the knife command. Since you are using hosted-chef (in this example at least), you can still use the knife command to look at your cookbook list or see which versions have been uploaded.

The main difference is that you will now use berks to update and upload the cookbooks specified in your Berksfile. The beautiful thing is that each cookbook repo has its own Berksfile! What does this mean? It means that each cookbook ensures the presence and up-to-date-ness of its own dependencies on the chef-server, so your main chef-repo doesn’t have to know or care. The only cookbooks that then need to be in your chef-repo’s Berksfile are those that are depended on by your roles but not explicitly in any of your other cookbooks.

The new workflow is now uniform for all cookbooks and looks something like this:

Using Berkshelf

Other than the above workflow, there isn’t much you need to know about using Berkshelf. There are only a few useful commands:

Other Stuff