Spinning multiple nodes for a single cookbook

[Ryan Hass]

I have a cookbook which builds out a multi tier application, in which the database resides on a different node than the application server. I would like to be able to provide our devs the ability to simply do 'kitchen create' to get both parts up and talking to eachother on their workstations. With Vagrant this was a simple matter of creating multiple config.vm.define blocks, each with their respective run-list. How can I do this in test kitchen?

[Mischa Taylor]

Here's a technique I use to create a cluster of machines using rake create with Test Kitchen.  You can call the Test Kitchen Ruby objects directly to spin through a list of instance names...effectively extending Test Kitchen with some custom code of your own to do anything you want ;-)

I was playing around with this in an experimental cookbook to spin up an Enterprise Chef cluster with an Enterprise Chef Server along with some test nodes here: https://github.com/misheska/demo-chef

The key logic for extending Test Kitchen is in the Rakefile: https://github.com/misheska/demo-chef/blob/master/Rakefile  Here's an excerpt of the relevant code:

require 'kitchen' @instances = [] @config = Kitchen::Config.new @names = %w{ default-chef-server default-node1 default-node2} @names.each {|name| @instances << @config.instances.get(name) } task :create do   @instances.each {|i| i.create } end task :destroy do   @names.each {|name| @config.instances.get(name).destroy } end task :converge do   @names.each {|name| @config.instances.get(name).converge } end task :default do   @instances.each {|i| puts i.name } end

In the near future, you should be able to accomplish the same thing with chef-metal using the kitchen-metal driver (currently the pre-beta code lives here: https://github.com/doubt72/kitchen-metal ).  The main benefit to this approach is that your test code could potentially share the same config with your production code via a Policyfile (new feature coming in the ChefDK).  But right now they need to get some changes merged into Test Kitchen proper for everything to work.

That being said, the above approach using a Rakefile using Test Kitchen has served me just fine for quite some time now.

[Eric Krupnik]

I use the erb component of test kitchen in the .kitchen.yml file. It looks something like below. I set up boxes and then iterate. You will also see I append the minitest-handler recipe to make sure each node runs the tests I have in place (using minitest currently)

 

<%

boxes = [

  { :name => :node1, :run_list => '"recipe[cookbook::recipe_1]", "recipe[yummy::food]"' },

  { :name => :node2, :run_list => '"recipe[cookbook::recipe_2]"' }

]

%>

 

suites:

<% boxes.each do |opts| %>

- name: <%= opts[:name] %>

  provisioner:

    solo_rb:

      environment: LOCAL

  encrypted_data_bag_secret_key_path: "/path/to/secret"

  data_bags_path: "../../data_bags"

  roles_path: "../../roles"

  environments_path: "../../environments"

  run_list: [ <%= opts[:run_list] %>, "recipe[minitest-handler]" ]

  attributes:

    cloud:

      provider: "ec2"

<% end %>