Development environment with Vagrant and Chef

We have recently started implementing a proper CI-based build pipeline for continuous deployment scenario and decided to use Chef as our CM tool. We also use Vagrant for creating isolated local dev environments for our devs, since it allows a simple ‘vagrant up’ and the env just runs. Vagrant is supposed to support Chef Zero, which it does. However, that requires holding predownloaded cookbooks in a ‘cookbooks’ dir, meaning managing dependencies and their versions would be a huge pain without a “packet manager”.

What I would like to do is to use either a Policyfile or a Berksfile to manage the cookbook dependencies. Unfortunatelly, this does not work (or I am doing something wrong). First of all, I could not find a way to implement the Policyfile using Vagrant, even though the feature was released 2 years ago. The only thing that popped up was this. The Berkshelf way was more promising, because there is a ‘vagrant-berkshelf’ plugin for Vagrant, which does exactly what I want…but with a few hiccups. One of the issues is the dependency on ChefDK. The main one, however, is that it’s been sort of deprecated in favour of the TestKitchen.

So, TestKitchen, there’s been a lot of fuss about this neat tool. It supports both Policyfiles and Berkshelf, it has a Vagrant provider that runs the VM using Vagrant. So what is wrong? To my understanding Chef’s TestKitchen was intended for Cookbook developers, because it allows automated local Cookbook testing, etc. But what about other devs? For example if a dev only works on the project (app) itself, and not the infrastructure, why would the dev even need ChefDK? All the dev wants to do is download the source code for the app (web app in our case), which includes Vagrantfile in the root dir, then simply type ‘vagrant up’ (because VirtualBox and Vagrant are already installed on the machine) and start working!

Yes, it is possible to use the TestKitchen as a Vagrant wrapper (this guy says it’s fine). Instead of the ‘vagrant up’, the dev would type ‘kitchen converge’ and then start working. But that implies the dev already installed ChefDK, alongside the VirtualBox and Vagrant.

Is there any [good and modern] way of not using the TestKitchen as a development environment provider? Or is it not considered a bad practice? To me, it seems wierd that the dev has to install ChefDK if he wants to spin the dev env on his laptop. How do you have your dev environment set up?

You really don’t need ChefDK at the point of use for the cookbooks; you only need it at the point where you create and manage them.

You use berks vendor to put all your cookbooks (including all dependencies) into a single directory. All your developers really need is your Vagrant image with the chef-client and this one single directory.

Kevin Keane
Whom the IT Pros Call
The NetTech
http://www.4nettech.com
Our values: Privacy, Liberty, Justice
See https://www.4nettech.com/corp/the-nettech-values.html

Thanks kkeane! I think you’ve stirred me into the right direction. Wouldn’t we have too many copies of the cookbooks, though? A Chef Server (or Local Supermarket instead) holding all the necessary books for CI as well as multiple git repos with the Vagrantfile and basically almost identical set of cookbooks for the developers. (not identical, but there will be multiple copies of some cookbooks across repos)

berks vendor doesn’t really add more cookbooks to your environment - it just packages existing cookbooks.

berks vendor will put copies of all the cookbooks and their dependencies into a single directory. You should treat that as an opaque blob. Think of it as “compiler output”. It’s meant to be shipped, not manipulated further. If you make changes to a cookbook, you would make it on the source, and then re-run berks vendor to re-create the whole package.

Kevin Keane
Whom the IT Pros Call
The NetTech
http://www.4nettech.com
Our values: Privacy, Liberty, Justice
See https://www.4nettech.com/corp/the-nettech-values.html