Testing Ansible Roles With KitchenCI

If you are doing any work in the DevOps space you have probably heard about Ansible. Ansible, currently is the fastest growing configuration management and orchestration tool on the market right now. As infrastructure teams move toward infrastructure development teams these teams need to start thinking like standard development teams. As infrastructure development teams start writing Ansible code it should follow a CI/CD path similar to how feature development teams follow a CI/CD process, a process which leverages pull requests, functional testing, and code promotion.

What is KitchenCI? Kitchen provides a test harness to execute infrastructure code on one or more platforms in isolation. KitchenCI has been integrated with Ansible with the Kitchen-Ansible Gem found on Github. Kitchen will enable users to not only test Ansible roles but it really is a huge enabler when it comes to rapid role development, since changes to roles can be quickly tested against a running virtual machine.

Kitchen is leveraged with 5 basic commands.

  • kitchen create – This creates the virtual machine
  • kitchen converge – This executes the Ansible role against the virtual machine
  • kitchen verify – This runs the test suite inspec or serverspec
  • kitchen destroy – This destroys the virtual machine

For the purposes of this blog I will discuss ServerSpec which is a functional test tool which enables infrastructure developers to write RSpec tests for checking your servers are configured correctly.

Serverspec tests your servers’ actual state by executing command locally, via SSH, via WinRM, via Docker API and so on. So you don’t need to install any agent softwares on your servers and can use any configuration management tools, Puppet, Ansible, CFEngine, Itamae and so on.

In the simple example below we have a test which is checking that the Apache Web Server is installed and listening on port 80:

require ‘spec_helper’

describe package(‘httpd’), :if => os[:family] == ‘redhat’ do
it { should be_installed }

describe package(‘apache2’), :if => os[:family] == ‘ubuntu’ do
it { should be_installed }

describe service(‘httpd’), :if => os[:family] == ‘redhat’ do
it { should be_enabled }
it { should be_running }

describe service(‘apache2’), :if => os[:family] == ‘ubuntu’ do
it { should be_enabled }
it { should be_running }

describe service(‘org.apache.httpd’), :if => os[:family] == ‘darwin’ do
it { should be_enabled }
it { should be_running }

describe port(80) do
it { should be_listening }

Rapid Ansible Role Development
The integration of ServerSpec, KitchenCI, and Ansible can be quite complex so to make this process easier and so you don’t have to read 20 blog posts about how to get this all working.

First you will need to install CookieCutter which is a python module that creates projects (in this case Ansible roles) from protect templates.

I have setup a CookieCutter repo here:



  • Follows Ansible best practices
  • Follows Ansible Galaxy best practices
  • Only Creates the necessary files and folders
  • Blazing fast creation, forget about file creation and focus in actions
  • Lint checks (Ansible-lint, yamllint)
  • Test infrastructure already implemented (Test-kitchen, kitchen-ansible, kitchen-vagrant, ServerSpec + kitchen-verifier-serverspec)
  • Test your roles against multiple platforms using the power of Docker or Vagrant
  • The life cycle of each platform is automatically managed by Test-kitchen
  • Your roles can be verified with ServerSpec


  • Install cookiecutter: pip install cookiecutter
  • cookiecutter https://github.com/XENTAURS/cookiecutter-ansible-role.git
  • It will ask you questions about the structure of your role like tasks names, handlers names, and default variables. You can jump to the next question by entering an empty string.
  • kitchen create – Will Create Your VM or Docker Container
  • kitchen converge – Will Execute Your Ansible Playbook
  • kitchen verify – Will Execute Your ServerSpec Tests
  • kitchen destroy – Will Destroy Your Kitchen Environment

Add a Comment

Your email address will not be published. Required fields are marked *