I'm new to Chef and have been using Test Kitchen to test the validity of my cookbooks, which works great. Now I'm trying to ensure that environment-specific attributes are correct on production nodes prior to running Chef initially. These would be defined in a role.
For example, I may have recipes that converge using a Vagrant box with dev settings, which validates the cookbook. I want to be able to test that a production node's role. I think I want these tests as the source of truth describing my environment. Looking at Test Kitchen's documentation, this seems beyond its scope.
Is my assumption correct? Is there a better approach to test a cookbook before the first time Chef is run on a production node to ensure it has the correct settings?
I pleasantly discovered that chef_zero uses the "test/integration" directory as it's chef repository.
Just create your roles under
Example
Standard Chef cookbook layout.
├── attributes
│ └── default.rb
├── Berksfile
├── Berksfile.lock
├── chefignore
├── .kitchen.yml
├── metadata.rb
├── README.md
├── recipes
│ └── default.rb
└── test
└── integration
├── default
│ └── serverspec
│ ├── default_spec.rb
│ └── spec_helper.rb
└── roles
└── demo.json
.kitchen.yml
---
driver:
name: vagrant
provisioner:
name: chef_zero
platforms:
- name: ubuntu-14.04
suites:
- name: default
run_list:
- role[demo]
attributes:
Notes:
- Provisioner is chef_zero
- The runlist is configured to use a role
recipes/default.rb
file "/opt/helloworld.txt" do
content "#{node['demo']['greeting']}"
end
attributes/default.rb
default['demo']['greeting'] = "hello world"
Notes:
- Cookbook won't compile without a default
test/integration/default/serverspec/default_spec.rb
require 'spec_helper'
describe file('/opt/helloworld.txt') do
it { should be_file }
its(:content) { should match /this came from my role/ }
end
Notes:
- Integration test is looking for the content that is set by the role attribute
test/integration/roles/demo.json
{
"name": "demo",
"default_attributes": {
"demo": {
"greeting": "this came from my role"
}
},
"run_list": [
"recipe[demo]"
]
}
You can set both roles and environments in your .kitchen.yml, so you certainly can test this with test kitchen.
....
provisioner:
roles_path: path/to/your/role/files
client_rb:
environment: your_environment
.....
That said, I personally prefer to use role cookbooks. If you have a fixed set of environments, as we do, then you can also use simple conditionals in the attributes files of your role cookbook to adjust attributes based on environment too. That way, you have a single cookbook that defines the entire configuration of your node by wrapping other cookbooks and setting variables. With that setup, it is very easy to setup kitchen tests that validate the exact production system.
When coming to validating attributes the part of Test Kitchen your should be using is ChefSpec.
You can define a complete runlist in a spec file and ensure the rendered files are correct.
There's a part of Chefspec documentation about it here.
Another way to do this is to have a "role cookbook", instead of using a role on chef server, you define the attributes you wish to define in an attribute file and make this cookbook depends on what the role runlist would be.
This role cookbook recipe would have include_recipe
only referencing the recipe you would have set in the role runlist.
The main advantage here is that you can include your specs in this cookbook independently of the referenced cookbooks.