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.
KitchenCI
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
ServerSpec
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 }
enddescribe package(‘apache2’), :if => os[:family] == ‘ubuntu’ do
it { should be_installed }
enddescribe service(‘httpd’), :if => os[:family] == ‘redhat’ do
it { should be_enabled }
it { should be_running }
enddescribe service(‘apache2’), :if => os[:family] == ‘ubuntu’ do
it { should be_enabled }
it { should be_running }
enddescribe service(‘org.apache.httpd’), :if => os[:family] == ‘darwin’ do
it { should be_enabled }
it { should be_running }
enddescribe port(80) do
it { should be_listening }
end
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:
https://github.com/XENTAURS/cookiecutter-ansible-role
Features
- 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
Usage
- 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 Containerkitchen converge
– Will Execute Your Ansible Playbookkitchen verify
– Will Execute Your ServerSpec Testskitchen destroy
– Will Destroy Your Kitchen Environment
This is pretty cool, Brian. Reminds me of Magnum for Puppet. I’ve been pushing my new company here in Berlin to run our CM code through a CI/DC pipeline. It only took two outages due to misconfigured load balancers to convince them of the need! I’ll be adding this to the workflow.
Sweet! Glad you found it useful!!
Brian, wondering if you got chance to try molecule?
https://molecule.readthedocs.io/en/latest/
Regards Arun Sangal
I have not, but I did notice it supports cluster testing (although I did figure out how to do this with Kitchen for both Ansible and Chef)..