The best - and sometimes the worst - thing about Chef is its thriving ecosystem. There appear to be cookbooks for just about everything, including one just for installing emacs. And there are lots of tools, lots of instructions, and blog posts about using the tools. So many in fact that it is sometimes hard to sort out what is what - especially as many of them are focused on showing you an example project rather than talking about broad concepts. I have picked up a number of useful tidbits but it’s been a little tough to integrate everything.
So, let me start with what I think I want. I want to use chef to set up my Linode VPS. Before I make changes to the server, I would like to run the same recipes locally on a Vagrant VM and run some integration tests to check that I am going to get what I intend. Eventually I may want to add unit tests for my custom cookbooks but for now, I want to just focus on ‘outside in’ testing which, in this situation, seems to me to be integration tests. This blog post, Getting Started Writing Chef Cookbooks the Berkshelf Way, Part 3, appears to do what I want to do, so let’s give that a try.
I was originally going to manage everything using chef solo because I thought that would be easier. But it turns out that chef and all the tooling around it are optimized for using chef server to manage lots of nodes, so chef server is actually the easier option - especially since Opscode has a free tier for managing up to five nodes.
When I created my Linode VM with knife-linode I did it all on the command line - no files. So that means that while I have a node named ‘linode’ on my hosted chef and my Linode VPS is set up as a client of that node, I don’t have any files and no git repository keeping track of anything. So let’s see if I can construct something to connect to that node on https://manage.opscode.com/. So I stared with the chef gemset I had previously set up and upgraded (chef 11.10.0, kitchen-vagrant 0.14.0, test-kitchen 1.1.1).
kitchen init created the .kitchen.yml file which is used to
configure my test kithcet setup. I added the port forwarding I will
need once I have a web server running on my VM. It is configured to
spin up a Vagrant VM with the Opscode Ubuntu 12.04 provisionless VM
and then use chef_omnibus to install the latest version of chef and
provision with chef_solo. I am not sure whether I should be using
chef_solo (so I can test out my cookbooks before they get uploaded to
Opscode) or if I should change that configuration to point to the
linode node on my chef server.
First server spec
So based on the example I worked through from the TDD book, and some
other blog posts,
I created a spec file in
I think this should indicate to test kitchen that I want it to use
serverspec to check that I have installed emacs on the VM. Right now,
I don’t have a spec_helper file; according to the Getting Started
section, I get one by doing
serverspec-init. But I am a little
unclear about where to put it. The serverspec docs
indicate I should have the directory a directory structure like:
But the blog post I am following, shows a directory structure of:
And I need a spec_helper.rb.
serverspec-init will generate one:
But the spec_helper file in the blog post is:
I am going to try a combination. I moved my emacs_spec.rb into
spec/localhost/ and then renamed the spec directory to
serverspec. I left the includes of the SpecInfra::Helper modules but
removed the sudo stuff and replaced it with the check_os stuff from
the blog post. So now I have:
Yeah!!! now my
kitchen converge boots, tries to converge (but I have
nothing in my runlist) and then runs the test.