Best practices for a Cookbook workflow

Chef Infra (archive)
1

I am trying to get an idea on what the “best practices” are for a cookbook project’s structure and workflow.
I’d like to encapsulate them into a gem that will add tasks for that workflow into your cookbook’s Rakefile for you.

But first, I need to get a feel for what these “best practices” regarding the workflow truly are.

Here’s what I’ve got so far for what I’d consider best practices based on personal experience and some Googling:

  • Use foodcritic and rubocop for linting
  • Use rspec in combination with chefspec for unit testing
  • Use kitchen for integration testing
    • Does the community prefer a particular verifier? Busser? Inspec? Dokken? My thought is Dokken since it has greater chance to work in a CI environment.
  • One repo per cookbook
  • Upload to the server via a --freeze
  • Use Stove for deployment to server
    • I just discovered this in searching for best practices, so I’ll need to brush up on this.
  • Use a git tag for every push
  • Use chefdk’s installers; don’t install the individual gems via bundler
    • This one poses a problem to me that I haven’t really seen anybody solve. How do you ensure that all your devs are using the correct version of chefdk (and thus the correct version of all the gems that are in it)? Normally I would do this via the Gemfile. Is there a .chefdk.version file or something?

My thoughts on what a best practice CI flow looks like

which ruby # some check to ensure chefdk is being used; not sure what exactly
foodcritic
rubocop
rspec
kitchen verify # if possible in your CI tool
git tag VERSION -m "MESSAGE"
knife cookbook upload NAME --freeze
2

There is chef –version:

[nathanclemons@hawke ~ ] chef --version Chef Development Kit Version: 0.17.17 chef-client version: 12.13.37 delivery version: master (f68e5c5804cd7d8a76c69b926fbb261e1070751b) berks version: 4.3.5 kitchen version: 1.11.1 [nathanclemons@hawke ~ ]

Nathan Clemons
DevOps Engineer
Moxie Cloud Services (MCS)

O +1.425.467.5075
M +1.360.861.6291
E nclemons@gomoxie.com
W www.gomoxie.comhttp://www.gomoxie.com/

3
  • cookstyle should be preferred over straight rubocop

i’d also argue that users should focus on test-kitchen testing instead of chefspec and unit testing. if user’s aren’t software devs and don’t understand unit testing to begin with, chefspec testing tends to devolve into attempting to test chef. for simple recipes chefspec also just is duplicating the work and writing your resource collection twice. where chefspec is most useful is when you want to test a cookbook that does a lot of branching, particularly on platform and platform_family where you want to test that the resource collection looks correct for aix when you’re running on a mac and its difficult for you to spin up a real LPAR to test on.

kitchen-dokken is a good provisioner to use. note that its a little strange in certain conditions, and that docker images tend to be very minimal and you buy yourself a problem of having to install packages like ca-certifications and apt-transport-https just to get ssl working. the kitchen-vagrant plugin is going to have fewer hiccups.

for verifiers, we’re recommending kitchen-inspec, that’s where all the future development work is going.

i also don’t necessarily recommend using one-repo-per-cookbook. there is literally nothing wrong with one-big-chef-repo. it is also very easy to use with PolicyFile’s now (a straight up improvement over Berkshelf) since you can point the policyfile depsolver at your chef-repo and merge it with the supermarket universe without having to include a path override for every single cookbook. for a small site, with few admins, i would argue that is actually the best practice, and it also makes sense to use fewer numbers of cookbooks and more recipes. for a large site, with many admins, and CI/CD that becomes awful because you wind up with single monolithic cookbooks that everyone is editing, and CI/CD needs to test everything inside of them, so you want highly separated concerns along cookbook lines. but for my home cookbooks (which have one dev, no tests, and 3 servers under management) i’ve completely rejected the entire Berkshelf Way approach to cookbook management because the overhead of managing that many cookbooks and that many repos is literally a colossal waste of my time and offers me exactly nothing.