AllGoodBits.org

Tool configuration

Edit/Verify .kitchen.yml

Change the provisioner to chef_zero because in constrast to Chef-Solo, Zero means that you don't have to special-case recipes/tests that use search. You'll want to verify that the list of platforms is correct. This is also the file where we specify the chef 'run list' and later might override the cookbook's default attributes for the purposes of testing, but more on that later. For now, we'll just use:

---
driver:
  name: vagrant

provisioner:
  name: chef_zero
  environments_path: test/environments
  client_rb:
    environment: kitchen

platforms:
  - name: ubuntu-12.04

suites:
  - name: default
    run_list:
      - recipe[mini-httpd::default]
    attributes:

If you want to be able to customize the VM that kitchen/vagrant makes for testing, you can make modifications to the 'driver' section, for example, specifying the hostname and forwarding ports from host to guest looks like:

---
driver:
  name: vagrant
  vm_hostname: 'mhv1.dev1.example.com'
  network:
  # Allow access to a web server which is useful when troubleshooting
  - - forwarded_port
    - guest: 80
      host: 8088
      auto_correct: true

Edit README.md

Berkshelf creates an example README.md; change it to document your cookbook: what it does, attributes you can pass and generally how to use it.

Edit/Verify metadata.rb

Verify that the Berkshelf-created boilerplate in here is good. This is also where you record any cookbooks that this cookbook depends upon and their version restrictions.

Edit/Verify Berksfile

If you need to tell berkshelf from where it should fetch dependencies.

cookbook 'openstack-common', github: 'stackforge/cookbook-openstack-common', branch: 'stable/grizzly'
cookbook 'ntp-wrapper', git: 'ssh://git@github.com:my-github-org/agb-ntp.git'

And if you do, you'll want to run berks install or berks update from your cookbook directory.

Edit/Verify test/environments/kitchen.json

This file allows kitchen access to "dummy" environment data, so that tests can be performed with chef-zero which doesn't have access to environment data that is in the real Chef Server.

{
  "name": "kitchen",
  "default_attributes": {
    "AZ": {
      "name": "kitchen",
      "mcps": [
        "localhost"
      ],
      "ops": [ "mc-tech-ops@cisco.com"
      ]
    }
  },
  "json_class": "Chef::Environment",
  "description": "AZ specific data for the kitchen AZ",
  "cookbook_versions": {
    },
  "chef_type": "environment"
}

Edit/Verify recipes/default.rb

This is where you write the code that actually makes something happen. At last!

package 'mini-httpd' do
  action :install
end
cookbook_file 'mini-httpd_conf' do
  source 'mini-httpd.conf'
  path '/etc/mini-httpd.conf'
  action :create
  mode 0644
  owner 'root'
  group 'root'
  notifies :restart, 'service[mini-httpd]'
end
cookbook_file 'mini-httpd' do
  source 'mini-httpd'
  path '/etc/default/mini-httpd'
  action :create
  mode 0644
  owner 'root'
  group 'root'
  notifies :restart, 'service[mini-httpd]'
end
service 'mini-httpd' do
  action [ :enable, :start ]
  supports :restart => true
end

The cookbook_file resource declared by cookbook_file 'mini-httpd_conf' takes its contents from the COOKBOOK_NAME/files/default sub-directory, the filename is specified by the source attribute. Not really: it searches a series of paths for a filename that matches the source attribute: files/<platform>-<version>/, files/<platform>/, files/default/, for example: files/ubuntu-12.04/, files/ubuntu, files/default. The analogous equivalent is also true for the sources of template resources and integration tests.

In our case, the contents of mini-httpd/files/default/mini-httpd.conf should be:

port=8080
user=nobody
nochroot
data_dir=/usr/share/mini-httpd/html
logfile=/var/log/mini-httpd.log
pidfile=/var/run/mini-httpd.pid

And the contents of mini-httpd/files/default/mini-httpd should be:

START=1
DAEMON_OPTS="-C /etc/mini-httpd.conf"

As we get more sophisticated, using attributes to allow variable configuration, we will remove this resource in favour of a template resource that, by default, will create the same configuration file with the same contents, but allow for alternative values for the mini-httpd directives.

At this point, you might commit your work to git.

mini-httpd $ git add files/
mini-httpd $ git commit -m'configure package, file, service for mini-httpd' -a

Extras

• Most kitchen subcommands can be run with concurrency greater than zero, specify with -c N
• Most kitchen subcommands can be given parameters to limit which instances will be affected, either by a list of instances or a regex: e.g. kitchen converge ubuntu
• You can set the logging level for your kitchen commands with -l [debug | info | warn | error | fatal]

Rubocop

rubocop will syntax-check and style-check your code based on the Ruby Style Guide. If you use -a, it will auto-correct where it can.

rubocop --show-cops

will show to which rules our check is subjected.

Foodcritic

Foodcritic is a style-checking tool for Chef cookbooks, hand it one or more paths to cookbook(s). We're hoping for a single blank line of output.

knife

If, from within the cookbook directory, you run:

mini-httpd $ knife cookbook test mini-httpd -o ..

knife will run a ruby syntax check against all files that end in .rb and .erb (respecting .chefignore).

Serverspec

Create a directory for the Serverspec tests, then we can start to make tests in test/integration/default/serverspec/localhost/mini-httpd_spec.rb:

require 'serverspec'
set :backend, :exec

describe 'mini-httpd service' do
  it 'should be running and enabled' do
    expect(service 'mini-httpd').to be_running
    expect(service 'mini-httpd').to be_enabled
  end

  it 'should be listening on port 8080' do
    expect(port(8080)).to be_listening
  end
end

For details about what types are available see the serverspec documentation about its resource types.

NOTE Files that contain serverspec tests must be named to match /_spec.rb$/ or test kitchen will not use them.

If you are just modifying your tests, you can accelerate your test-kitchen workflow by separating the steps:

• kitchen create
• kitchen converge
• kitchen setup
• kitchen verify

If you do this, you can edit your tests and just run kitchen verify, avoiding the delay of the previous steps.

BATS

Bats, the Bourne-Again shell Test System.

Create a directory for the bats tests and add a file <cookbook_name>/test/integration/default/bats/<cookbook_name>.bats:

match() {
  local p=$1 v
  shift  for v
    do [[ $v = $p ]] && return
  done
return 1
}

@test "mini-httpd is listening to port 8080" {
  run nmap -sT -p8080 localhost
  match "80/tcp open  http" "${lines[@]}"
}
@test "Server accepts HTTP requests" {
  echo "GET / HTTP/1.1" | nc localhost 8080
}

This brings up another requirement to ensure that certain packages are available during testing, whether or not they're installed for real. Create a file <cookbook_name>/test/integration/default/bats/prepare_recipe.rb

%w{ nc nmap }.each { |pkg| package pkg }