Just moozing

Before you can check your notes, you must make them…

Creating ansible roles

leave a comment »

ansible-logoI have been working my way through Ansible and how to create roles. There are a lot of roles out there and with galaxy, they are easily accessible. This blog post is about my design decisions for the roles that I create.

I have decided on three basic rules

  1. They must be self-contained
  2. They must include a test
  3. They must be very specific in what they do


A lot of these thought are what programmers “just do”, and I find that the book “Building maintainable software” puts words on these things. Even though it is written with Java in mind, it applies to most programming languages, and, in my opinion, to provisioning also.

The key element here is testing. It is difficult from time to time to design good tests, and have a working environment that enables testing in an isolated manner, but it is a massive timesaver. I don’t do real TDD with Ansible (yet), but just like using unit test to specify what you want to program next – the same could be applied to ansible role development.

Btw, Ansible has some resources available related to testing, like here. And do follow best practice for directory layout.

In the following, I will go through my reasoning and how I implement it.


I compare Ansible roles to, what we would call “modules” in other programming languages. Best practice is to have independent modules with a minimum of external bindings. If you have complex bindings, isolating the roles and debugging becomes more difficult.

To me self-contained means:

- hosts: workstations

  - workstation-xfce4

This should work out of the box, with no other roles needed. Don’t forget sane default values.

I expect to hit a wall at some point, and that it will make sense to have role dependencies for some corner cases, but so far no. You could imagine some meta-role where it would be relevant.


 Include a test

My Ansible roles include a test directory with a Vagrantfile and whatever support files and playbooks are needed. This also serves as an example. It doesn’t replace a good readme file, but it supplements it well.

Using the test was how I noticed a change in behavior from Ansible version 1.9 to version 2.0 related to how handlers got included. This was a bug, and I would have chased it in my own code for a long time, if I had not had tests that worked 1-2 months earlier.

Vagrant is very powerful for this. The concept of an easy way to kill the machine and start over, makes development loops much shorter.


Being specific

Again, this is not new, if you have a programing background. The more elaborate you need to be in your explanations about what a module does, the worse.

If you want your server to do 10 things, you include 10 roles (+1 role for domain specific basic server configuration).

I like the idea of having separate virtual servers doing their own specific task in the network. It results in simple IDS rules, simple iptables rules and simple firewall rules when only very well-defined combinations of IP addresses and port numbers are allowed.


On the todo list

  • github and jenkins. Other projects use it…
  • Ansible modules
  • Ansible and libvirt for spinning up virtual machines. Vagrant works with the vagrant-libvirt module, but it gives an extra interface which is something annoying.
  • Ansible and windows. I probably need to look into powershell for this.

Written by moozing

August 4, 2016 at 12:00

Posted in Tech

Tagged with , , ,

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: