3 min read

Multi Node Setup with Test Kitchen

What’s test kitchen?

From Test Kitchen

It is designed to execute isolated code run in pristine environments ensuring that no prior state exists.

It hooks with Chef really well and provides integration testing for infrastructure code and is a great tool for developing runbooks as code. You can use it with Vagrant/EC2/Docker to provide the underlying ‘server environments’.

Why use it?

I returned to Nagios after many years and wanted to get it up and running locally. Times have changed since I last used Nagios, now we have things like Chef and Vagrant which help with rapid iterations and prototyping. Messed up the server, no worries, kill and re-create within a minute, all locally on my Macbook.

Virtual Machine snapshots can achieve some of these results, but it’s not the real deal :) For example if you need to test a certain script on a server booting for the first time, test-kitchen is a better tool.

The Setup

Here’s a chef cookbook to setup three separate virtual machines. The test-kitchen specific config lives in .kitchen.yml

  1. Nagios Server
  2. Candidate1 to be monitored
  3. Candidate2 to be monitored

I am able to simulate bad configuration, packet drops, server reboots and observe how Nagios reacts.

Usually you would get a list of servers to be monitored by querying Chef Server. By authoring your cookbook with proper attribute overrides you can enable local testing.

# set use_nodes_in_attrib true in .kitchen.yml

if node['use_nodes_in_attrib']
  nodes = node['list_of_nodes']
else
  nodes = search(:node, query)
end

Instances vs Nodes

Another common technique to simulate multiple nodes is by using instances. You could run two instances of memcache on the same node. This is really advantageous when you want to play and test the search capabilities of Chef Server, rather than test across separate OS installations.

Remote Nodes

When running chef_zero as a provisioner, test-kitchen lets you pre-load your local chef-server with real node data obtained from another chef server.

So say I have my production chef server which knows about all the nodes (IPaddresses and Ohai data). Now I want to run Nagios locally but have it work against production data.

First we get the data from our production chef server into our local test-kitchen repo

cd test/integration/nodes
h=<name of node on chef server>
knife node show $h -Fj > $h.json

Now kitchen converge will load this data into the local chef server and make it available to chef code executing in the VM. Of course you can configure your setup to actually talk to your production setup. But the whole point of having test-kitchen is to have local runs which are safely segregated from production.

Conclusion

Test Kitchen is great for infrastructure testing. With help from Vagrant and Virtualbox, it can setup separate virtual servers which can talk to each other using dedicated private IPs. This facilitates experimentation and integration testing of multiple servers.