Five Questions: Testing Ansible Playbooks & Roles

August 11, 2017 by Chris Meyers

Next up in our #AskAnsible posts is Chris Meyers, our Senior Software Engineer.

Learn his take on five key questions we often get regarding testing Ansible Playbooks and roles.

1. Why should I test my Playbooks and roles?

Chris: Ansible Playbooks and roles should be treated like production code. Production code usually has unit tests, functional tests, and integration tests.

  • Unit testing Ansible is equivalent to unit testing SQL queries, you just normally don’t do it. Ansible unit testing belongs at the Python module level.
  • Function testing with Ansible would require a large amount of system state setup or mocking, and it just isn't realistic. 
  • Integration testing is the most useful. It ensures that your intent, expressed in English, is translated correctly to Ansible’s declarative language.
    • Ex: you want to set up a LAMP or MEAN stack. A simple integration test would be to issue an http request that you know exercises the database. The integration test would ensure that your setup is correct from end to end.
2. When should I start testing my Playbooks and roles?

Chris: You can start at any time! Tests can be added for new Playbooks or to existing Playbooks. Testing Ansible Playbooks and roles are accomplished by simply running a Playbook or role. Thus, most of the testing work is just creating a clean host each time. This testing methodology coupled with Ansible’s flexible inventory system and per-host variables results in very little to no code changes (i.e. Playbook yaml and role task files).

3. How do I test my Playbooks and roles?

Chris: You are already testing your Playbooks and roles just by running them! But that is only one configuration matrix or permutation. You need to start by writing down the configuration matrix that you want to support. For example, if I want my role to support install PostgresSQL 9.4 and 9.6 and CentOS 7 and Ubuntu 14.04 then my configuration matrix would look like the following:

Postgres Distribution
9.4 Centos7
9.4 Ubuntu 14.04
9.6 Centos7
9.6 Ubuntu 14.04

Now that we’ve pinned down the set of parameters our role supports we can clearly see that we need configurations to fully test our role.

We can represent each row in the configuration matrix as an inventory file. For example

[postgres]
ubuntu14

[postgres:vars]
pg_version=9.4

Or, since Ansible’s design makes it easy to run against multiple hosts, we can easily condense the test matrix down to two rows.

Postgres Distribution
9.4 Ubuntu 14.04, Centos7
9.6 Ubuntu 14.04, Centos7

[postgres]
ubuntu14
centos7

[postgres:vars]
pg_version=9.6

 

The final piece for rapid development/testing is the ability to quickly reset the state of the hosts you are testing against.


Remote Host

Advantages/Disadvantages

Cloud VM (OpenStack, ec2, gce, etc.)

+ Good if you already use them

- Takes time to spin up

Vagrant VM

+ Good if you already use them

- Heavy load on your laptop

+ Snapshotting can be very useful

+ No special “tricks” to get certain things to work

docker

+ No prior knowledge needed with the help of provision_docker

+ Very fast to “reset”

+ Very little system overhead

- Some special “tricks” to get them to run like a VM


For this I advise using docker. I’ve created a role called provision_docker that makes this process a little easier. Check out the Related Resources at the end of this post for more information.

4. What’s the benefit of testing my Playbooks and roles?

Chris: The benefits of testing Ansible Playbooks and roles are the same as the benefits of testing production code including:

    • Faster turnaround of outside contributors
    • Exercising less common code paths
    • Increased confidence
    • Early detection of Ansible version feature changes
    • Up-to-date example use cases for users for free 

5. Will Ansible Playbook and role testing into my current CI flow?

Chris: Yes! The big component to testing Ansible roles and Playbooks is standing up a fresh remote “host." You can accomplish this using your existing methods or you can leverage Ansible public cloud modules such as EC2 or GCE or use Ansible private cloud modules such as VMware or openstack; to spin up remote instances. Alternatively, you can leverage the power of contains through provision_docker to turn a single bare metal or VM into a provider of multiple Ansible hosts.

 

Need more?

Learn how to Provision docker on Github

Watch Chris talk about the Build Passing Badge on Galaxy 

Read about testing Roles with docker 

Watch Chris talk about Ansible Roles and Projects

If you have any comments or ideas for future interviews, feel free to tweet at @Ansible.

twitter-logo.png TWEET #ASKANSIBLE

Share:

Topics:
Ansible Automation Platform


 

Chris Meyers

Chris is a Principal Software Engineer, Ansible, contributing Red Hat Ansible Tower backend APIs. Outside of work Chris hones his skills as an amateur carpenter on his house. To learn more about those you can follow him on Twitter at @oldmanmeyers85.


rss-icon  RSS Feed