Ansible: common roles considered harmful

In may Ansible projects there is a role named common (or something like that). The kind of role you open with anxiety. Let’s see what are the issues with this role, and let’s talk about role granularity in Ansible.

The trash roles

This common role is usually a trash role. When people don’t know where to put some tasks, they end up in the common roles. I worked in many companies which used Ansible, and all had a common role. I contributed myself to a common role before killing it in my first Ansible project.

This role is usually unmaintainable, and performs various unrelated tasks.

Let’s take a fictional common role. This role will maybe:

  • Upgrade the packages of your Linux distribution.

  • Configure SSH keys in the machine.

  • Configure syslog.

  • Confighre DHCP.

With time, this role will grow. New tasks will end up into it, and it will become a "gloubi boulga" (untranslatable):

/alt="gloubi boulga"

Do you like eating gloubi boulga ?

This kind of role should be splitted into multiple roles, each role having a single responsability. For example, the common role previously described could be splitted into these roles:

  • debian

  • ssh

  • syslog

  • dhcp

It will be much easier to maintain the roles that way.

Role granularity

Actually, this is a granularity issue. I’m in favor of creating a lot of small Ansible roles, each role doing one thing and doing it well. I maintained hundreds of Ansible roles in various contexts, and writing small roles is the only solution to not create a mess.

Many people try to do too much in roles. Let’s take a Kafka role for example:

  • You use Collectd in your company. Should your role configure Collectd to monitor Kafka ? The answer is no. This would couple the role to Collectd, and you don’t want that (what if you change your monitoring tool ?).

  • Should your role configure Logstash/filebeat/syslog-ng/…​ for Kafka ? Again, probably not.

Roles should stay simple, and do only one thing.

Another example. You want to deploy Kubernetes with Ansible. In your opinion, what is the most maintainable and reusable between the roles:

  • common

  • master

  • worker

or:

  • kubelet

  • kube-proxy

  • kube-dns

  • ssh

  • etcd

  • calico

  • …​

In the second case, roles will be easier to maintain, deployments will also be easier and less error-prone.

You can also use playbooks

We tend to forgot playbooks, and use role for everything. It’s a mistake, playbook is the thing to use for some tasks.

For example, doing a rolling-upgrade of a cluster should be done in a playbook. Also, small tasks (like running a dist-upgrade on a Debian machine, or even creating an user) can be done in a playbook. You don’t have to use a role for everything.

Conclusion

Keep your roles simple, and your deployment will be simple.

Top of page