ansible-role-test is a tool that uses docker containers to quickly create disposable boxes that can be provisioned by a test ansible playbook via ssh.

• docker
• python 2.7+, 3.x
• a host running systemd is highly recommended, see notice below

• Clone repository
• Optional: Activate your virtualenv or run make venv to create a local one
• Run make install
• Either run ansible-role-test or venv/bin/ansible-role-test

When using boot2docker or a linux distribution not running systemd, CentOS 7 might not start properly due to missing cgroups. The course of action in this case is to create manually the /sys/fs/cgroup/systemd folder either on your host (if running linux) or inside your boot2docker VM.

OSX:

boot2docker ssh
sudo mkdir /sys/fs/cgroup/systemd

Linux (without systemd):

sudo mkdir /sys/fs/cgroup/systemd

Instead of running make install, run make dev and use venv/bin/ansible-role-test.

Usage: ansible-role-test [OPTIONS] COMMAND [ARGS]...

  ansible-role-test is a docker based testing utility for ansible roles.

Options:
  --help  Show this message and exit.

Commands:
  init       Create the test folder with a default test...
  snapshots  Manipulate saved containers
  test       Run tests ROLE can be either be a local path,...

Creates a tests folder with a default main.yml file that looks like the one shown in the [Writing tests] section below.

Usage: ansible-role-test init [OPTIONS] [PATH]

  Create the test folder with a default test file

Options:
  -h, --help  Show this message and exit.

Usage: ansible-role-test test [OPTIONS] ROLE

  Run tests

  ROLE can be either be a local path, a git repository or an ansible-galaxy
  role name.

Options:
  -c, --config FILENAME           Config file to use for the tests
  --roles-path ROLES_PATH         Search path for non-galaxy roles that might
                                  be required as dependencies
  --library-path LIBRARY_PATH     Search path for custom ansible modules
  --plugins-action-path PLUGINS_ACTION_PATH
                                  Search path for custom action plugins
  --plugins-filter-path PLUGINS_FILTER_PATH
                                  Search path for custom filter plugins
  --plugins-lookup-path PLUGINS_LOOKUP_PATH
                                  Search path for custom lookup plugins
  -e, --extra-vars EXTRA_VARS     Set additional variables as key=value or
                                  YAML/JSON
  -l, --limit SUBSET              Limit selected hosts to a given pattern
  --skip-tags SKIP_TAGS           Only run plays and tasks whose tags do not
                                  match these values
  -t, --tags TAGS                 Only run plays and tasks tagged with these
                                  values
  -v                              Verbose mode (-vvv for more, -vvvv to enable
                                  connection debugging)
  --ansible-version ANSIBLE_VERSION
                                  The ansible version to use (either 1.8, 1.9
                                  or latest)
  --privileged                    Run test containers in privileged mode
                                  (dangerous)
  --cache                         Cache yum/apt folders on the host
  --save [failed|successful|all]  Save containers, can be either one of
                                  "failed", "successful" and "all"
  -h, --help                      Show this message and exit.

# Create a default test file and run it on a local role
ansible-role-test init /path/to/role
ansible-role-test test --save=failed /path/to/role
# Test a git repository
ansible-role-test test https://github.com/org/repo.git
# Test a branch on a git repository
ansible-role-test test https://github.com/org/repo.git#my-branch
# Test an ansible-galaxy role
ansible-role-test test user.role

Helper commands to inspect saved images generated by the test command.

Usage: ansible-role-test snapshots [OPTIONS] COMMAND [ARGS]...

  Manipulate saved containers

Options:
  -h, --help  Show this message and exit.

Commands:
  list   List all snapshots and whether they failed or...
  purge  Delete all snapshots
  rm     Remove a specific snapshot
  view   Display the output of the ansible play that...

List all snapshots currently saved in the local repository.

Example output:

ROLE NAME               CONTAINER           STATUS          DATE                    IMAGE NAME
aeriscloud.nodejs       centos-6            successful      2015-06-10T12:58:52     aeriscloud.nodejs.centos-6:successful-1433908732
aeriscloud.nodejs       centos-7            failed          2015-06-10T12:58:47     aeriscloud.nodejs.centos-7:failed-1433908727

Display the output of the ansible job that was run on this host.

Removes a stored snapshot by name, eg ansible-role-test snapshots rm aeriscloud.nodejs.centos-6:successful-1433908732

Deletes all stored snapshots.

Create a tests folder in your role, then in that folder create a yaml file that looks like that one:

---
# The name of your test
name: "My test name"
# The containers you will use for this test, you could for example spawn a debian
# centos, ubuntu, etc... and run the tests on "all" hosts
# If skipped, tests will be run on every containers available
#containers:
#  master1: 'centos:6'
#  slave1:
#    image: 'centos:7'
#    vars:
#      host_var1: foobar # defines host_var1 on this host on particular
#  slave2: 'centos:7'
#  slave3: 'debian:wheezy'
# You can also setup custom inventory groups to be declared in the inventory, if
# no containers are declared above, they will be merged with the default groups.
# For exemple the following declaration will create 2 groups, master and slaves.
#groups:
#  masters:
#  - master1
#  slaves:
#  - slave1
#  - slave2
#  - slave3
# This is your test playbook
playbook:
- hosts: all
# You should have your role called in roles, with the proper variables set, you
# can call the same role several times in a row but I'd rather recommend creating
# separate test files for each call to ensure that they run in a clean env
  roles:
# "@ROLE_NAME@" is a magic variable that will be replaced by the name of the role
# on your filesystem before running the tests
  - role: "@ROLE_NAME@"
    var1: something
    var2: something
# You should verify that your role executed properly here, using tasks
  tasks:
  - name: "Check that my-role did that thing properly"
    module: do-something

If desired, it is possible to use the --save option to save containers at the end of each test. Possible values for this option are failed, successful and all and will filters which containers to save. One useful use case is to save failed containers to inspect what file/package could be missing.

Containers are saved as art/{ROLE NAME}.{CONTAINER NAME} with the tag {STATUS}-{STAMP}.

Saved images can be found by running ansible-role-test snapshots list. It is possible to inspect the image by running:

$ docker run -t -i art/role-name.system:tag bash
[root@671165bdfcb0 /]#

Once done, one can removed failed containers by running docker rmi art/foo:tag or ansible-role-test snapshots rm art/foo:tag. A faster way to remove all the corresponding images is to run ansible-role-test snapshots purge.

Most of the time, your roles might depend on other local roles or plugins, in which case you can use the --role-path, --library-path, etc... flags to help ansible find those. In some cases though it might result in unwieldy commands due to the sheer amount of flags passed around. When that happens you can use a config file that follows this format to provide the proper information to ansible:

---
roles: ansible/roles
library: ansible/library
plugins:
  action: ansible/plugins/actions
  filter: ansible/plugins/filters

Then call ansible-role-test with the --config flag pointing to this file. The given paths are relative to the config file's location.

You can find them on the wizcorp user on the docker registry, they should be named ansible-<distro>:<version>.

They are also automatically separated in 3 groups centos, debian and ubuntu.

Please check aeriscloud@docker for the current list of available images.

If you wish to build all the images locally, you can run make docker.

• Any role that deals with kernel modules or raw hardware (eg. iptables or formatting disks) will run into issues while running in docker. iptables seems to work in privileged mode with no side effects but anything that does destructive operations should not be tested with privileged mode on.
• While the centos boxes are running systemd-container, debian and ubuntu boxes are not and as such calls to systemctl/initd might not behave the same way as a real system.

This is currently a work in progress, I am not responsible and shall not be held responsible in any manner if this tool causes loss of data, hardware faults, act of gods, invocation of old or ancient ones, elder gods and other horrors from the depths.