Testing the roles and conditions of the chef

I'm new to Chef and use Test Kitchen to check the correctness of my cookbooks, which works great. Now I am trying to ensure that the attributes specific to the environment are correct on the production nodes before the chef starts. They will be defined in the role.

For example, I can have recipes that converge using the Vagrant field with the dev settings, which checks the cooking. I want to check that this is the role of node. I think I want these tests to be a source of truth that describes my environment. Looking at the documentation for the test kitchen, it goes beyond its capabilities.

Is my assumption correct? Is there a better approach for testing a cookbook before the first chef is launched at node production to make sure it has the correct settings?

+7
tdd testing chef test-kitchen
source share
3 answers

I happily discovered that chef_zero uses the "test / integration" directory as the chef repository.

Just create your roles in

  • Test / Integration / Roles

Example

Chef's standard cookbook.

β”œβ”€β”€ 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 execution list is configured to use the role

Recipes /default.rb

 file "/opt/helloworld.txt" do content "#{node['demo']['greeting']}" end 

attributes /default.rb

 default['demo']['greeting'] = "hello world" 

Notes:

  • Cookbook will not compile without using 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 validates content specified by role attribute

Test / integration / roles / demo.json

 { "name": "demo", "default_attributes": { "demo": { "greeting": "this came from my role" } }, "run_list": [ "recipe[demo]" ] } 
+8
source share

When approaching attribute validation, part of the test kitchen you should use is ChefSpec.

You can define the complete list in the specification file and make sure that the processed files are correct.

Here is some of the Chefspec documentation here .


Another way to do this is to have a cookbook, instead of using the role on the chef’s server, you define the attributes that you want to define in the attribute file and make the cookbook dependent on what the runlist role will be.

This cookbook recipe for this role would have include_recipe only a reference to the recipe that you would set in the execution list.

The main advantage here is that you can include your specifications in this cookbook regardless of the recommended cookbooks.

+1
source share

You can set both roles and environments in your .kitchen.yml, so you can of course test this in a test kitchen.

 .... provisioner: role_path: path/to/your/role/files client_rb: environment: your_environment ..... 

However, I personally prefer to use cookbooks. If you have a fixed set of environments, like us, then you can also use simple conditional expressions in the attributes files of your role cookbook to configure attributes based on the environment. Thus, you have one cookbook that defines the entire configuration of your node by packing other cookbooks and setting variables. With this setting, it is very easy to set up kitchen tests that confirm an accurate production system.

+1
source share

All Articles