ContributorsMost Chef users store the .kitchen.yml file in source control along with their cookbooks so that other users can also use it to verify their own work. Having the .kitchen.yml file readily available can help you add and verify features more quickly, or move to newer platforms.
But you might notice two problems with this approach.
- Not all users use the same Test Kitchen driver. For example, one user might be using the EC2 driver and another user might be using Hyper-V.
- The
.kitchen.yml file can contain sensitive information such as passwords and access credentials. If you share your cookbook on Chef Supermarket or on GitHub, you might not want to share this information.
Here are some recommended ways you can manage your Test Kitchen configuration files so that they are available to others, but also protect access credentials and other sensitive information.
The option you choose depends on your preferences and what's easiest for others. You can document what others need to do to use your configuration in your cookbook's README.
You can find examples of these methods on Chef Supermarket.
1. Provide a configuration for the Vagrant driver
Most Chef cookbooks provide configuration for at least the Vagrant Test Kitchen driver because the Vagrant driver uses free software and doesn't require passwords or other sensitive information to run.
2. Use dynamic configuration
It's also common to use dynamic configuration. For example, you can create a file named .kitchen.local.yml, which you do not check into source control, that overrides the default configuration with your specific details. The .gitignore file that's generated when you run the chef generate cookbook command automatically excludes .kitchen.local.yml from source control management.
Consider this example configuration that uses the Amazon EC2 Test Kitchen driver.
Editor: ~/learn-chef/cookbooks/example_cookbook/.kitchen.yml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
| ---
driver:
name: ec2
aws_ssh_key_id: learnchef
region: us-west-2
availability_zone: a
subnet_id: subnet-eacb348f
instance_type: m1.small
image_id: ami-c3b3b1f3
security_group_ids: ['sg-2d3b3b48']
retryable_tries: 120
provisioner:
name: chef_zero
transport:
ssh_key: C:\Users\LearnChef\.ssh\learnchef.pem
verifier:
name: inspec
platforms:
- name: windows-2012r2
suites:
- name: default
run_list:
- recipe[example_cookbook::default]
attributes: |
Notice a few potential issues with this configuration. The configuration mentions details that are specific to the user's AWS account, including the user's:
- SSH key name
- region and availability zone
- subnet ID
- security group ID
- AMI ID
These details are not transferrable to users who work with a different AWS account. It's also not clear which details need to be modified in order to run the cookbook.
You can move all of the information that's specific to your AWS account to .kitchen.local.yml, like this.
Editor: ~/learn-chef/cookbooks/example_cookbook/.kitchen.local.yml
1
2
3
4
5
6
7
8
9
10
11
| ---
driver:
aws_ssh_key_id: learnchef
region: us-west-2
availability_zone: a
subnet_id: subnet-eacb348f
image_id: ami-c3b3b1f3
security_group_ids: ['sg-2d3b3b48']
transport:
ssh_key: C:\Users\LearnChef\.ssh\learnchef.pem |
Your .kitchen.yml file now contains only the general configuration settings.
Editor: ~/learn-chef/cookbooks/example_cookbook/.kitchen.yml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
| ---
driver:
name: ec2
instance_type: m1.small
retryable_tries: 120
provisioner:
name: chef_zero
verifier:
name: inspec
platforms:
- name: windows-2012r2
suites:
- name: default
run_list:
- recipe[example_cookbook::default]
attributes: |
Users would be required to create their own .kitchen.local.yml file that contains their settings. The cookbook's README should explain which settings are needed.
3. Use environment variables
Alternatively, you can be more explicit about the required settings by using environment variables. .kitchen.yml can contain Embedded Ruby (ERB) templates. Using this method, your .kitchen.yml file might look like this (here, a .kitchen.local.yml file is not required.)
Editor: ~/learn-chef/cookbooks/example_cookbook/.kitchen.yml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
| ---
driver:
name: ec2
aws_ssh_key_id: <%= ENV['AWS_SSH_KEY_ID'] %>
region: <%= ENV['AWS_REGION'] %>
availability_zone: <%= ENV['AWS_AZ'] %>
subnet_id: <%= ENV['AWS_SUBNET_ID'] %>
instance_type: m1.small
image_id: <%= ENV['AWS_AMI_ID'] %>
security_group_ids: <%= ENV['AWS_SECURITY_GROUP_IDS'] %>
retryable_tries: 120
provisioner:
name: chef_zero
verifier:
name: inspec
transport:
ssh_key: <%= ENV['AWS_SSH_KEY_PATH'] %>
platforms:
- name: windows-2012r2
suites:
- name: default
run_list:
- recipe[example_cookbook::default]
attributes: |
Users are required to set these environment variables before running Test Kitchen. The advantage here is that it's clear which settings are required.
4. Provide multiple configuration files
Another common option is to provide the Vagrant configuration in .kitchen.yml and other configurations in separate files.
For example, you might provide a configuration that runs in the cloud in a file named .kitchen.cloud.yml. This enables you to provide a standard configuration that runs on Vagrant and an option to test your configuration on one or more cloud providers.
To run the cloud configuration, you would set the KITCHEN_YAML=.kitchen.cloud.yml environment variable. Here's an example of how to run kitchen converge using the cloud configuration on a Linux or macOS workstation.
Terminal: ~/learn-chef/cookbooks/example_cookbook
$ | KITCHEN_YAML=.kitchen.cloud.yml kitchen converge
|
