Advanced kitchen configuration

We’re always defining kitchen configurations in a single file, but what happens, when we have configuration, which are only interesting for us or sensitive data?

Environment changes for kitchen

In a cookbook, the main .kitchen.yml file defines the basic configuration of the kitchen environment with suites, the driver, which will be used, and some other things.

But: What happens, if only you are using a different driver? Lets say kitchen-ec2 for running kitchen against AWS? Will you change the .kitchen.yml file? Will you push those changes into your git? > NO!!! Don’t do this!

More kitchen configurations, or what?

I know, it’s a bit hidden in the documentation, but: have you ever heard about the .kitchen.local.yml or .kitchen.global.yml?

If not or if you’ve already heard about it, but don’t know how they’re being used or how to work with them in a best practice way, just move on reading. If you’re already working with them, you should stop here, as it won’t be any news to you.

General usage of .kitchen.local.yml and .kitchen.global.yml

Both files are doing the same, what the .kitchen.yml file does. But it’s overriding it’s content. It is overwriting the specified section like driver, provisioner or suites. The .kitchen.local.yml overrides the .kitchen.yml and the .kitchen.global.yml overrides the local and main file.

In a mathematical way: .kitchen.yml < .kitchen.local.yml < .kitchen.global.yml

How to use them in a bit more detail

Let’s assume, our .kitchen.yml file looks like

---
driver:
  name: vagrant

provisioner:
  name: chef_zero
  always_update_cookbooks: true

verifier:
  name: inspec

platforms:
  - name: ubuntu-16.04
  - name: centos-7

suites:
  - name: default
    run_list:
      - recipe[kitchen_test::default]
    verifier:
      inspec_tests:
        - test/integration/default
    attributes:

And we want to change the driver name. As mentioned before, we should not change the .kitchen.yml file. So we’re creating a .kitchen.local.yml file

---
driver:
  name: ec2

This only overrides the driver section, everything else is still the same.

Another example: We only want to add ubuntu-18.04 in the platform section

---
platforms:
  - name: ubuntu-16.04
  - name: ubuntu-18.04
  - name: centos-7

As you see there is not only ubuntu-18.04 as an additional platform name. We have to add the whole platforms section. Otherwise it would use the defaults, if there is one defined.

If a section is missing, you can also add this section only to your .kitchen.local.yml.

A bit more background informations

The .kitchen.yml and .kitchen.local.yml file is always in the cookbooks root directory. So be aware of, you don’t commit the .kitchen.local.yml file into any repository, as it only contains your own changes, which might not be interesting for other people or could contain sensitive data.

The .kitchen.global.yml file can be found in the ~/.kitchen/ directory. This file will be searched always, but if it does not exist, you can just ignore it. Normally, the usage of a .kitchen.local.yml file is enough.

Is it possible to define different paths for those files?

Yes, definately. You can use the following environment variables to change it.

KITCHEN_GLOBAL_YAML=/path/to/your/global/config.yml
KITCHEN_YAML=/path/to/your/project/.kitchen.yml
KITCHEN_LOCAL_YAML=/path/to/your/local/.kitchen.local.yml

Please be aware of changing environment variables. If you forget to change it back, troubleshooting of anything will be quite hard. So the best way is to use the default paths for all files.

Conclusion

• when overriding any section, we have to copy over the whole part and not only additional things
• add .kitchen.local.yml to your .gitignore
• using environment variables to change paths to kitchen configuration could bring up failures