Test Ansible roles with Molecule

One of the advantages of the Configuration Management Tool Ansible is the easy-to-read-and-write code in YAML. This includes the possibility to test the code in an easy way.

Depending on the scope of the written roles, direct execution on the development device is not recommended. Likewise, tests of newly written code should not be executed on the production environment. Therefore, a test system is recommended.

One of Ansible’s best practices is to structure related tasks into roles and keep them parameterizable. This allows the code to be reused in an uncomplicated manner. To test the functionality and autonomy of a role, the “Ansible Molecule” developed by the Ansible Core Team can be used. The role is executed by default on a locally running docker container. Alternatively, the test can be run in a vagrant box or at various cloud providers.

Molecule is mostly based on Ansible. Accordingly, the provider-specific modules supplied with Ansible are also used to provision the test instances.

Example:

In order to test an existing role with Ansible, a scenario must be created first:

molecule init scenario -r my-role-name

molecule/default/ contains the primary configuration file molecule.yml, which may look like this:

dependency:
  name: galaxy
  options:
    role-file: requirements.yaml
driver:
  name: docker
lint:
  name: yamllint
platforms:
  - name: c6
    image: centos:6
  - name: c7
    image: centos:7
  - name: d10
    image: debian:10
provisioner:
  name: ansible
  lint:
    name: ansible-lint
verifier:
  name: testinfra
  lint:
    name: flake8

Molecule also checks dependencies that must be present before execution. By default, ansible-galaxy is used. You can specify requirements.yml, which lists the required Ansible Galaxy roles. If you need specific Python packages on the Ansible Host for the modules and plugins you use, you can install them using the “shell” Dependency Manager.

To follow best practices, Molecule checks the code with ansible-lint and yamllint before executing.

In the configuration file, it is possible to specify different platforms for testing— for example a docker container with CentOS 7 and Debian 10 as base. Platform-independent code is also one of Ansible’s best practices. Docker is the default provider. Therefore, a docker file is available as a jinja2 template. This can be extended at will.

To verify changes after executing the role, the TestInfra Framework can be used to write test cases.

After initialization, the previously specified platforms can be created using molecule create. The creation of test resources can be verified using molecule list.

To perform the roll now, a molecule converge is sufficient.

If the test cases are not yet 100% automated, it is possible to log in [–host ] to one of the test instances using molecule login and thus manually check the results.

After a successful run, the created instances can be switched off or deleted using molecule destroy.

The complete workflow described above can be executed with the command molecule test.

Like Ansible itself, the entry hurdle for Molecule is relatively low. At the same time, complex applications can be covered by the plug-in structure’s high configurability.