This page summarizes the different "kinds" of Chef that are available.

Introduction

Let's suppose that you / your research want to try out Opscode Chef for configuring some of your systems; e.g. your shiny new NeCTAR virtuals, or something running on hardware in your centre / department / faculty's machine room.  Your next question is deciding which flavour of Chef to use.

Open Source versus Enterprise Chef

Opscode offers two main alternatives:

  • Open Source Chef is the "free" (as in beer) flavour.  Costs no cash ... if you want. But it doesn't have all of the bells and whistles, and you need to look after everything yourself.
  • Enterprise Chef is the "paid for" version.  It comes in two forms:
    • Hosted Chef, where your cookbooks, databags, roles and node definitions are stored securely in a Chef server provisioned by Opscode. 
    • Private Chef, where you host the Enterprise Chef infrastructure on your own kit.

You can also get Enterprise Chef for free for up to 5 nodes (i.e. servers or virtuals) without any support as a sweetener.

If you run Open Source Chef or Private Chef, you need to deal with provisioning of the Chef Server infrastructure yourself.  That means a host or virtual machine to run the "Chef Server", management of user accounts, backups of the server state, secure storage / version management of your cookbooks and so on.  There's a substantial learning curve, and there's a risk of getting into serious problems if you screw up.

I'm working on a "chef-server" cookbook to address this ...

On the other hand, Opscode charge a significant amount ($120 US per month) for their base level service.  This could be a significant cost for an individual researcher or small research group.

If (hypothetically) a large organization (like the University of Queensland or NeCTAR) were to negotiate a large-scale license, they could make use of Enterprise Chef's support for "multi-tenancy" to allow departments / groups / individuals to manage their own nodes in a secure an autonomous fashion, using Chef Server infrastructure that was provisioned and run centrally.

Chef Server versus Chef Solo

With Chef Server, the model is that your configuration cookbooks and the other configuration information for a number of "nodes" is stored in a server, and individual nodes then automatically fetch the information they need to do their configuration.  You (the administrator) can then remotely initiate configuration / reconfiguration for individual nodes, or sets of nodes.

If you cannot justify using Enterprise Chef (e.g. hosted) and you don't have IT staff to set up and run a Chef Server for you, there is a low-end alternative.  Instead of using a Chef Server, you "manually" maintain a copy of the configuration information on each managed system.  (For example, you could put the information into a public or private "git" repository, create a "clone" in the local file system, and use "git pull" to keep it up-to-date.)  For each system you would create a "node.json" file containing the node specification.  To run the recipes, you would run the "chef-solo" command with the "node.js" as an argument in the directory containing the chef configurations.

If you are managing just individual machines / virtuals, this works reasonably well.  For a large number of machines, the process of keeping lots of copies of the configurations in step could be a burden.  (Though you could probably write some wrapper scripts ...)

Vanilla Chef versus Berkshelf

This choices is about the way that you manage your "chef-repo"; i.e. the place where you develop your cookbooks.

The "vanilla Chef" approach is model that is described in the Opscode Chef documentation and supported by the (standard) "knife" tool.  This gives you a "chef-repo" in which you have a copy of all of the cookbooks that you use under version control.  The recommended organization is to install copies of external cookbooks into the "cookbooks" directory, and keep your own "site specific" cookbooks in your "site-cookbooks" directory.  The "knife" tool supports this model via the "knife cookbook site" subcommand.

There are problems with the "vanilla" Chef model:

  • The "knife cookbook site" command only understands the Opscode Community Cookbooks site.  (You need a 3rd-party plugin to allow you to install from Github ...)
  • It makes it difficult to share your changes to installed cookbooks.
  • It makes it difficult to share cookbooks you develop as "site-specific".
  • It hard-wires your development-time cookbook dependency resolutions.
The alternative to "vanilla" Chef is to use a "Berkshelf".  Instead of putting the dependent cookbooks into version control, you create a "Berksfile" which specifies where to look for dependencies.  Then you use the "berks" command to fetch and install the dependencies, based on the cookbook version constraints specified in the Berksfile and the cookbooks' respective "metadata.rb" files.
(My conclusion is that the Berkshelf approach is superior, modulo that Chef Solo / workstation setup is a bit more involved, and the Berkshelf documentation is not up to scratch in some areas.)