The first file we'll work with is our .kitchen.yml. This file determines how Test Kitchen performs the build. This YAML file provides us with the following:
- Driver: This is used for running the build in Docker as a privileged user starting with the init process. If you're unfamiliar with working with containers, we're setting it up this way to act more like a traditional VM, and less like a wrapper around an application.
- Provisioner: We're setting up Test Kitchen to use the Puppet provisioner with a local manifests and modules path in our build.
- Verifier: Use Inspec for testing.
- Platforms: We are going to configure our container to use the CentOS SystemD container. We're passing additional commands to ensure that SSH works properly, and that init scripts are available for our Jenkins run.
- Suites: This is used for describing each test suite we run. This first one is defined with jenkins.pp in our test directory, which is a simple include profile::jenkins, like we may see in an example.pp. Notice our pre-verify stage in this one, giving our Jenkins instance 30 seconds to finish coming up before we test:
---
driver:
name: docker
privileged: true
use_sudo: false
run_command: /usr/sbin/init
provisioner:
name: puppet_apply
# Not installing chef since inspec is used for testing
require_chef_for_busser: false
manifests_path: test
modules_path: test/modules
verifier:
name: inspec
platforms:
- name: centos
driver_config:
image: centos/systemd
platform: centos
run_command: /usr/sbin/init
privileged: true
provision_command:
- yum install -y initscripts
- sed -i 's/UsePAM yes/UsePAM no/g' /etc/ssh/sshd_config
- systemctl enable sshd.service
suites:
- name: default
provisioner:
manifest: jenkins.pp
lifecycle:
pre_verify:
- sleep 30
.kitchen.yml will work for us locally as well, allowing us to run tests and verify them before sending our code up to our remote repository. We can also use kitchen converge to build the machine and apply the code if we want to inspect the end-state on our local system.