Test Kitchen driver/provisioner for lightning faster Chef Infra cookbook testing with Docker
This Test Kitchen plugin provides a driver, transport, and provisioner for rapid cookbook testing and container development using Docker and Chef Infra Client.
kitchen-dokken is fast. Really fast.
Test Kitchen itself has four components: Drivers, Transports, Provisioners, and Verifiers. Drivers are responsible for creating a system on local hypervisors or a cloud. Transports such as ssh or winrm are responsible for connecting to these hosts. Provisioners are responsible for provisioning the hosts to the desired state using scripts or configuration management tools. The final component is the verifier which is responsible for verifying the system state matches the desired state.
Unlike all other Test Kitchen drivers, kitchen-dokken handles all the tasks of the driver, transport, and provisioner itself. This approach requires a narrow focus of just Chef Infra cookbook testing, but provides ultra-fast testing times. Docker containers have a fast creation and start time, and dokken uses the official Chef Infra Client containers instead of spending the time to download and install the client. These design decisions result in tests that run in seconds instead of minutes and don't require high bandwidth Internet connections.
As stated above kitchen-dokken is purpose-built for speed and it achieves this by narrowing the testing scope to just Chef Infra cookbook testing. Other drivers like kitchen-vagrant or kitchen-docker are general-purpose drivers that can be used with any of the Kitchen provisioners such as kitchen-puppet or kitchen-ansible. Also, keep in mind that testing with containers is not a perfect analog to a full-blown system. The dokken-images containers are designed to be similar to a standard OS install, but they do not perfectly match those installs and may need additional packages to work properly. If you're looking for a perfect analog to your production systems, without the additional work of package installation, then consider a driver such as kitchen-vagrant. If you're willing to potentially invest in a bit of package troubleshooting in exchange for faster feedback cycles then kitchen-dokken is for you.
A sample kitchen-dokken
--- driver: name: dokken chef_version: latest # or 16 or 16.0 or 16.0.300 or current
transport: name: dokken
provisioner: name: dokken
verifier: name: inspec
laptop:~/src/chef-cookbooks/hello_dokken$ kitchen list Instance Driver Provisioner Verifier Transport Last Action Last Error
laptop:~/src/chef-cookbooks/hello_dokken$ docker ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
laptop:~/src/chef-cookbooks/hello_dokken$ docker images REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
laptop:~/src/chef-cookbooks/hello_dokken$ kitchen create -----> Starting Kitchen (v1.15.0) -----> Creating ... Creating local sandbox at /Users/someara/.dokken/sandbox/6e1b03ab46-default-centos-7 Building work image.. Finished creating (0m21.04s). -----> Kitchen is finished. (0m21.95s)
kitchen createphase of the kitchen run pulls (if missing) the
chef/chefimage from the Docker hub, then creates a volume container named
chef-. This makes
/opt/chefavailable for mounting by other containers.
When talking to a local Docker host (over a socket), the driver creates and bind mounts a sandbox directory to
/opt/kitchen. This prevents us from having to "upload" the test data.
When talking to a remote Docker host (tcp://somewhere.else), dokken starts a container named
-data. It makes
/opt/verifieravailable for mounting by the runner. The data container is the "trick" to the whole thing. It comes with rsync, runs an openssh daemon, and uses an insecure, authorized_key ala Vagrant. This is later used to upload cookbook test data.
/tmpdirectory is avoided, due to the popularity of
tmpfsclobbering by inits.
Finally, the driver pulls the image specified by the suite's platform section and creates a runner container named
-. This container bind-mounts the volumes from
-data, giving access to Chef and the test data. By default, the
pid_one_commandof the runner container is a script that sleeps in a loop, letting us
execour provisioner in the next phase. It can be overridden with init systems like Upstart and systemd, for testing recipes with service resources as needed.
laptop:~/src/chef-cookbooks/hello_dokken$ docker ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 3489588d4470 6e1b03ab46-default-centos-7:latest "sh -c 'trap exit ..." About a minute ago Up About a minute 6e1b03ab46-default-centos-7 f678882b1575 chef/chef:current "true" About a minute ago Created chef-current
laptop:~/src/chef-cookbooks/hello_dokken$ docker images REPOSITORY TAG IMAGE ID CREATED SIZE 6e1b03ab46-default-centos-7 latest 2ea1040b9c10 About a minute ago 192 MB chef/chef current 01ec788610e2 6 days ago 124 MB centos 7 67591570dd29 7 weeks ago 192 MB
laptop:~/src/chef-cookbooks/hello_dokken$ time kitchen converge -----> Starting Kitchen (v1.15.0) -----> Converging ... Creating local sandbox in /Users/someara/.dokken/sandbox/6e1b03ab46-default-centos-7 Preparing dna.json Preparing current project directory as a cookbook Removing non-cookbook files before transfer Preparing validation.pem Preparing client.rb Starting Chef Infra Client, version 16.10.8 Creating a new client identity for default-centos-7 using the validator key. resolving cookbooks for run list: ["hello_dokken::default"] Synchronizing Cookbooks: - hello_dokken (0.1.0) Installing Cookbook Gems: Compiling Cookbooks... Converging 1 resources Recipe: hello_dokken::default * file[/hello] action create - create new file /hello - update content in file /hello from none to 2d6944 --- /hello 2017-02-08 04:23:01.780659287 +0000 +++ /.chef-hello20170208-41-105f1ha 2017-02-08 04:23:01.780659287 +0000 @@ -1 +1,2 @@ +hello\n - change mode from '' to '0644' - change owner from '' to 'root' - change group from '' to 'root'
Running handlers: Running handlers complete Chef Client finished, 1/1 resources updated in 01 seconds Finished converging (0m2.61s). -----> Kitchen is finished. (0m3.46s)
real 0m3.887s user 0m1.080s sys 0m0.210s
kitchen-convergephase of the kitchen run uses the provisioner to upload cookbooks through the data container, then execs
chef-clientin the runner container. It does NOT install Chef Infra Client, as it has already been mounted by the driver. The transport then commits the runner container, creating an image that only contains the changes made by Chef.
laptop:~/src/chef-cookbooks/hello_dokken$ docker ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES c153dfd8e53d e9fa5d3a0d0e "sh -c 'trap exit 0 S" 9 minutes ago Up 9 minutes default-centos-7 32c42fba4a8c someara/kitchen-cache:latest "/usr/sbin/sshd -D -p" 9 minutes ago Up 9 minutes 0.0.0.0:32846->22/tcp default-centos-7-data 7e327add6bf2 chef/chef:12.5.1 "true" 17 minutes ago Created chef-12.5.1
laptop:~/src/chef-cookbooks/hello_dokken$ docker images REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE default-centos-7 latest ec1d208d77cd 8 minutes ago 172.3 MB someara/kitchen-cache latest abbdb063dff1 2 weeks ago 300.8 MB chef/chef 12.5.1 86245605bbe3 4 weeks ago 168.1 MB centos 7 e9fa5d3a0d0e 6 weeks ago 172.3 MB
laptop:~/src/chef-cookbooks/hello_dokken$ docker diff default-centos-7 A /hello C /opt A /opt/chef A /opt/kitchen C /run A /run/mount A /run/mount/utab C /tmp C /var/lib/rpm/.dbenv.lock C /var/lib/rpm/__db.001 C /var/lib/rpm/__db.002 C /var/lib/rpm/__db.003
laptop:~/src/chef-cookbooks/hello_dokken$ time kitchen verify -----> Starting Kitchen (v1.15.0) -----> Setting up ... Finished setting up (0m0.00s). -----> Verifying ... Loaded
File /hello ✔ should be file ✔ should be mode 420 ✔ should be owned by "root" ✔ should be grouped into "root"
Test Summary: 4 successful, 0 failures, 0 skipped Finished verifying (0m0.80s). -----> Kitchen is finished. (0m1.99s)
real 0m2.695s user 0m1.310s sys 0m0.365s
kitchen-verifyphase uses the transport to run acceptance tests, verifying image state.
laptop:~/src/chef-cookbooks/hello_dokken$ docker ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 84def4c49ce3 6e1b03ab46-default-centos-7:latest "sh -c 'trap exit ..." 6 minutes ago Up 6 minutes 6e1b03ab46-default-centos-7 f678882b1575 chef/chef:current "true" 9 minutes ago Created chef-current
laptop:~/src/chef-cookbooks/hello_dokken$ docker images REPOSITORY TAG IMAGE ID CREATED SIZE 6e1b03ab46-default-centos-7 latest fec1a50470ed 6 minutes ago 192 MB chef/chef current 01ec788610e2 6 days ago 124 MB centos 7 67591570dd29 7 weeks ago 192 MB
laptop:~/src/chef-cookbooks/hello_dokken$ kitchen destroy -----> Starting Kitchen (v1.15.0) -----> Destroying ... Deleting local sandbox at /Users/someara/.dokken/sandbox/6e1b03ab46-default-centos-7 Finished destroying (0m0.83s). -----> Kitchen is finished. (0m1.81s)
laptop:~/src/chef-cookbooks/hello_dokken$ docker ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES f678882b1575 chef/chef:current "true" 10 minutes ago Created chef-current
laptop:~/src/chef-cookbooks/hello_dokken$ docker images REPOSITORY TAG IMAGE ID CREATED SIZE chef/chef current 01ec788610e2 6 days ago 124 MB centos 7 67591570dd29 7 weeks ago 192 MB
Due to the nature of Docker, a handful of considerations need to be addressed.
A complete example of a non-trivial
kitchen.ymlis found in the
dockercookbook, at https://github.com/chef-cookbooks/docker/blob/master/kitchen.yml
The Distros (debian, centos, etc) will typically manage an official image on the Docker Hub. They are really pushing the boundaries of minimalist images, well beyond what is typically laid to disk as part of a "base installation".
Very often, an image will come with a package manager, GNU coreutils, and that's about it. This can differ greatly from what is found in typical Vagrant and IaaS images.
Because of this, it is often necessary to "cheat" and install prerequisites into the image before running Chef, Serverspec, or your own programs.
To help with this, the Dokken driver provides an
intermediate_instructionsdirective. Here is an example from
platforms: - name: debian-7 driver: image: debian:7 intermediate_instructions: - RUN /usr/bin/apt-get update - RUN /usr/bin/apt-get install -y apt-transport-https net-tools
If present, an intermediate image is built, using a Dockerfile rendered from lines provided. Any valid instruction will work, including
VOLUMES, etc. Knowledge of Docker is assumed.
This should be used as little as possible.
A possible use case is running kitchen behind a MITM proxy If you did read the link, it's scary yes, but a reality in many corporate networks where any HTTPS connection is intercepted, when done right (morally) the proxy uses an internal Certificate Authority (CA) which is not trusted by most programs.
It's always a problem to get things accessing TLS secured servers through this kind of proxy when working in a container and here is how you can do it for Chef specifically.
entrypointyou can overcome the problem in dokken in this way:
driver: name: dokken chef_version: 16 entrypoint: /bin/entrypoint intermediate_instructions: - RUN /usr/bin/openssl s_client -showcerts -verify 5 -connect free.fr:443 > /usr/local/share/ca-certificates/ca.crt && update-ca-certificates - RUN echo "#!/bin/bash -ex\ncat /usr/local/share/ca-certificates/ca.crt >> /opt/chef/embedded/ssl/certs/cacert.pem\nexec \"\[email protected]\"\n" >> /bin/entrypoint && chmod +x /bin/entrypoint
The code above does call a site (here free.fr, my french ISP :)) with openssl s_client and does an ugly awk parsing to extract the root CA from the chain and write it in
/usr/local/share/ca-certificate/ca.crtand then update system certs (which makes curl, wget, and other system calls works with the proxy)
The second RUN creates an entrypoint for the container which will add the cert to Chef CA bundle and then exec whatever is passed as
pid_one_command(see next paragraph, it does match CMD in dockerfile), this ensures once the container is created with chef volume and data volume mounted, the Chef's CA bundle accept your proxy certificate.
Caveat: multiple suites running will add the cert to the chef container each time and consume a significant amount of disk space over time. In CI systems you'll want to regularly prune containers to avoid this problem.
Docker containers are process oriented rather than machine oriented. This makes life interesting when testing things not necessarily destined to run in Docker. Specifically, Chef Infra recipes that utilize the
serviceresource present a problem. To overcome this, we run the container in a way that mimics a machine.
As mentioned previously, we use an infinite loop to keep the container process from exiting. This allows us to do multiple
kitchen loginoperations without needing to commit a layer and start a new container. This is fine until we need to start testing recipes that use the
'sh -c "trap exit 0 SIGTERM; while :; do sleep 1; done"'
If you need to use the service resource to drive Upstart or systemd, you'll need to specify the path to init. Here are more examples from
platforms: - name: centos-7 driver: image: centos:7 privileged: true pid_one_command: /usr/lib/systemd/systemd volumes: - /sys/fs/cgroup:/sys/fs/cgroup:ro # required by systemd
You can combine
yaml - name: ubuntu-12.04 driver: image: ubuntu-upstart:12.04 pid_one_command: /sbin/init intermediate_instructions: - RUN /usr/bin/apt-get update - RUN /usr/bin/apt-get install apt-transport-https
IF you are running a Docker daemon with user namespace remapping enabled you'll get errors running dokken with privileged containers.
To mitigate this, add the following to your driver definition:
yaml platforms: - name: centos-7 driver: image: centos:7 privileged: true userns_host: true
This will disable user namespaces for the running container.
On Debian/Ubuntu systems, all files downloaded via it's package manager (
apt) are stored at
/var/cache/apt/archives/. Therefore one may save the downloads on a different volume and therefore save time. One may even use one's own apt cache folder to save even more time.
On some versions of Ubuntu (16.04 at least), the container deletes all the downloads upon every run of
apt-get update, so that must be disabled
aptCaching on Ubuntu 16.04 ```yaml --- driver: name: dokken volumes: # saves the apt archieves outside of the container - /var/cache/apt/archives/:/var/cache/apt/archives/
platforms: - name: ubuntu-16.04 driver: image: dokken/ubuntu-16.04 pidonecommand: /bin/systemd intermediate_instructions: # prevent APT from deleting the APT folder - RUN rm /etc/apt/apt.conf.d/docker-clean ```
When chef converges
/opt/kitchen/with the chef and test kitchen data required to converge. By default this directory is cleared out at the end of every run. One of the subdirectories of
/opt/kitchen/is the chef cache directory. For cookbooks that download significant amounts of data from the network, i.e. many
remote_filecalls, this can make subsequent converges unnecessarily slow. If you would like the chef cache to be preserved between converges add
clean_dokken_sandbox: falseto the provisioner section of
kitchen.yml. The default value is true.
provisioner: name: dokken clean_dokken_sandbox: false
intermediate_instructionsdirective is a fine hack around the minimalist image issue, it remains exactly that: A hack. If you work on a lot of cookbooks you will find yourself copying around boilerplate to get things working. Also, it's slow. Running
apt-get updateand installing iproute2 all the time is a huge bummer.
To solve this, we maintain the dokken-images collection of fat images that you can find pushed to Docker Hub. The package list aims to make sure things like ohai function in a reasonable way and doing a
kitchen loginyields a useful environment for debugging. They're hosted on the Docker cloud and are rebuilt every day to keep the package metadata fresh.
To use them, simply prefix a distro with "dokken/" in the
imagename. Unfortunately, you'll still have to specify
pid_one_command(for the time being).
- name: ubuntu-16.04 driver: image: dokken/ubuntu-16.04 pid_one_command: /bin/systemd run_list: - recipe[whatever::recipe]
If you have your own mirror of Docker Hub, or you are using a registry other than Docker Hub, you can tell Dokken to always pull from a different registry by setting
driver: docker_registry: docker.sample.com
If you do this, it must have access to the dokken images for the platforms you want to test as well as the
centosimage that is used for the dynamic testing image.
When starting a container with an init system, it will often mount a tmpfs into
/tmp. When this happens, it is necessary to specify a
root_pathfor the verifier if using traditional Bats or Serverspec. This is due to Docker bind mounting the kitchen data before running init. This is not necessary when using Inspec.
verifier: root_path: '/opt/verifier' sudo: false
Chef publishes all functioning builds to the Docker Hub, including those from the "current" channel. If you wish to use pre-release versions of Chef, set your
chef_versionvalue to "current". If you need to test older versions of
chef-clientthat are not available on docker hub as
chef/chef, you can overwrite
chef_imageunder the driver context to a custom image name such as
It is possible to pass several extra configs to configure the chef binary and options, for example to use older versions that do not have the "-z" switch or to get some debug logging.
provisioner: chef_binary: /opt/chef/bin/chef-solo chef_options: "" chef_log_level: debug chef_output_format: minimal profile_ruby: true
To test a locally built image without pulling it first, one can disable pulling of platform images, which will avoid pulling images that already exist locally.
driver: name: dokken pull_platform_image: false
To skip the pulling of the Chef Docker image unless it doesn't exist locally:
driver: name: dokken pull_chef_image: false
Containers that supply a no-op binary which returns a successful exit status can be tested without requiring Chef Infra to actually converge.
verifier: name: inspec
By default the memory limit of the containers you run is unbound (or limited by the Docker client on OSX). If however you need to constrain the container memory allocation you can set a memory limit in bytes on the driver:
driver: name: dokken memory_limit: 2147483648 # 2GB
We already had a thing that drives Docker, why did you make this instead of modifying that?
kitchen-dockerdriver ends up baking SSH, Chef, and the kitchen data into the image. This does not. To make this work, I had to create a Driver, a Transport, and a Provisioner that blur the traditional duties of each. The current Docker driver can be used with Puppet, Ansible, CFEngine provisioners. This requires Chef.
See "Kitchen-Docker or Kitchen-Dokken? Using Test Kitchen and Docker for fast cookbook testing" for a more detailed comparison.
Right now there is no
kitchen publishmechanism. See this issue.
You can, however, do it manually.
cd my_cookbook ; kitchen verify suite_name docker stop suite_name docker tag suite_name:latest my.computers.biz:5043/something/whatever docker push my.computers.biz:5043/something/whatever kitchen destroy