Ansible | test | Molecule | libvirt | post worker

Accelerate your development cycles and release with confidence

Wherever I was crossing Ansible in my professional life, people using it have always faced the same challenges. While everyone wants a responsive setup that gives a reliable, reproducible and flexible way to rollout configuration and software installation across a server (or VM) fleet, the reality is that it is often a combination of tasks, roles, and playbooks. becomes an interconnected collection. It’s hard to ensure high quality and keep it clean and simple.

What I have experienced is mostly the following situations:

• writing tasks “blindly” and then applying them to the hosts; iterating until everything runs without errors
• making small changes to playbooks or roles, then applying them to hosts, and then forgetting to git them
• Testing your Ansible roles on existing, configured hosts, and forgetting required dependencies for newly installed hosts
• Creating and running playbooks with multiple roles, but never testing roles independently and reusing variables in roles or global variables, makes it difficult or nearly impossible to run individual roles and then run for each role With tags fixes it.
• Running playbooks manually and on-demand. Due to configuration drift on the hosts, for example, due to missing git.

Flexibility is great, and being able to react rapidly is a key element of success nowadays. Without some basic separation and guidelines, however, a responsive repository can quickly become a monolith of a technical department. I went there.

One of the most important things is to write separate, reusable roles. Even if you don’t intend to share them within your company, it helps to focus on the purpose of that specific role. As in the world of microservices, you don’t want one role to be responsible for many things. A separate repo for a role also allows you to develop and test it separately to ensure a high quality standard.

• One repository per role, test independently
• One or more repositories for the playbook, in terms of roles

Before You Reinvent the Wheel — Check Out ansible-galaxy For public, open source roles that best suit your needs.

In your playbook repository, you can easily reference the roles a requirements.yml Files and also roles pulled from git:

# ansible-galaxy install -r requirements.yml
roles:
- name: geerlingguy.docker
version: 4.2.4
- name: https://github.com/MyOrganization/repo_name.git
type: git
version: master

Just as developers ensure quality in their software projects through Git with pipelines, run tests, and build artifacts, DevOps – or GitOps – is used to ensure high quality, reproducible, and automated deployment mechanisms. can use the same principles.

The central philosophy here is to validate the results of your work, usually “code”, on a defined, reproducible environment, to ensure that it also works for your colleagues and that the results are reliable and repeatable. Once you have verified the reproducible results, you are ready to automate the rollout to ensure a consistent state across your server fleet or to detect configuration drift.

Molecule allows you to test your responsive role against multiple instances that are setup for testing. While Molecule can spin up Docker containers for you, it focuses on running and testing ansible roles, not on provisioning instances to run tests. To make it extremely easy to integrate into Molecule, I recently published an Ansible role that you can use with Molecule to easily define and provision the instances you need for tests, whether it’s Linux (Fedora, Ubuntu, etc.) or Windows (via libvirt).

For the following examples, you need:

• a Linux host with Docker Established
• sudo privilege
• python library molecule molecule-docker

This DrPsychick/ansible-testing Role works great for my use cases and I hope it can serve you well. If your use case is different or needs adjustment, please contribute to the role by creating issues and opening a pull-request.

It only takes five minutes to do this hands-on “tutorial.” When you are done, you have your first Linux Ansible role to be tested with Molecule. a complete molecule test It takes about 30 seconds to run on two instances with an empty role.

1. Create a Role

Create a new, empty role with molecule,

molecule init role demo.testrolecd testrole

Role and namespace limitations:

namespace: https://galaxy.ansible.com/docs/contributing/namespaces.html#galaxy-namespace-limitations
role: https://galaxy.ansible.com/docs/contributing/creating_role.html#role-names

If you have an existing role, you can start the molecule default scenario with the following command:

# creates and populates ./molecule/default/
molecule init scenario default

2. Get the Molecule Example from GitHub

Download Example Files (https://github.com/Drpsychick/ansible-testing/tree/master/docs/molecule/default) From DrPsychick/ansible-testing For your role:

for f in create destroy molecule requirements vars; do 
curl -o molecule/default/$f.yml "https://raw.githubusercontent.com/DrPsychick/ansible-testing/master/docs/molecule/default/$f.yml"; 
done

Before running it, you may want to adjust molecule/default/vars.yml And molecule/default/molecule.yml for your needs that allows you to configure DrPsychick/ansible-testing Create roles and define the container instances you want to test on.

vars.yml,

# a temporary directory that will be deleted with 'destroy'
work_dir: "/tmp/ansible-demo.testrole-default"
containers:
- name: ubuntu2204
os: ubuntu
dockerfile: Dockerfile_Ubuntu
files:
- "entrypoint.sh"
args:
VERSION: 22.04

Make sure the container names match platforms In molecule.yml,

[...]
platforms:
- name: ubuntu2204
[...]

3. Play the Molecule on its Role

As you are probably logged in as a user, when you run Molecule for the first time you may get this error:

fatal: [localhost]: FAILED! => {"changed": false, "module_stderr": "sudo: a password is required\n", "module_stdout": "", "msg": "MODULE FAILURE\nSee stdout/stderr for the exact error", "rc": 1}

that’s because ansible-testing The role ensures that all prerequisites are installed. solve it by running sudo echo And then run the molecule again.

# create instances (with DrPsychick/ansible-testing)
# this will take a while the first time, as it builds 
# the docker images.
# Once built, creating instances takes only seconds.
molecule create# list instances or check systemd status
docker ps
docker exec -it ubuntu2204 systemctl status# run your role on the instances
molecule converge
molecule idempotence

4. Develop Your Role

Now you can hack and apply your role. For one or several operating systems or flavors. rerun molecule converge As often as necessary to verify that your tasks are doing what they should. Before ending things, make sure a molecule test Also succeeds without any problems, as it ensures that your role works on the newly installed instance.

It’s also important that you make sure your role is nullable – which means when you run it a second time to make sure it doesn’t report any changes. Why is this so important? When you automate Ansible runs later, you want to define the target state for one system, and you want all systems to have the same configuration state.

For example, to detect configuration drift (the host’s configuration deviates from the desired state), you can run an Ansible playbook --check mode to see if any changes will be made. This is only possible if your role is written in a way that is useless (and .) --check Safe).

you can use molecule/default/prepare.yml To create your own examples for your role, if you need to establish specific prerequisites such as other roles. and you can use molecule/default/verify.yml Finally run the tasks to verify that the configuration or installation of your role is working as expected.

5. Run Molecules in Your Pipeline

Now that you have your Molecule scenario setup and configured, your role developed and tested, it is time to ensure consistent high quality by running Molecule tests in your pipeline.

Since there are many different Ci/Cd solutions out there, I will just mention the requirements for running the molecule right away (which are already mentioned above)

• Python3 ansible ansible-lint docker molecule molecule-docker
• Possibility to run privileged docker containers in the pipeline (possibly with docker-in-docker, docker:dind,

Open issues for feature requests, to point out bugs, or just to show your interest and share that you’re working on a specific issue or case.

It’s simple to adjust the role to your needs and use your local version:

1. Fork the project on GitHub
2. Watch the fork on your Linux box
3. Symlink the forks to their roles in the molecule landscape (ie molecule/default ,
4. Comment about role in requirements.yml and delete local copy

now all molecule The commands in your roles directory will use your local fork.

Here is the detailed description: https://github.com/Drpsychick/ansible-testing#contributing,

Thank you for your time and interest!