
Ansible: One role to rule them all
- Blog
I am a long time Ansible user and contributor (since 2012) and I have been struggling with a decent setup for a multi-environment case. I have been designing and re-designing a lot, until I came up with this design. And what a coincidence, a customer wanted a setup that was exactly this. So this concept is a real world setup, working in a production environment.
Did I get your attention? Read after the break, but take your time. It is a long read.
The setup is (really) easy. At least, that is what I think. It is, in fact, just one repository in Git that has control over all Ansible roles used in the complete environment. This role is called setup.
The setup repository contains a couple of things:
- The Ansible configuration
- The complete inventory split into the different environments
- All needed variables per environment, functionality or per host
- Small playbooks to run per environment
- Task lists that contain all tasks needed to get things done
- The roles.yml, containing all the roles we build our self
- All (small) scripts to make things tick
The inventory
When looking at the inventory directory a little closer, there are a couple of files per environment. For instance, the dev environment contains three files mysql, wiki and zz_groups.
The mysql file contains the dev_mysql group, which contains all the hosts that are responsible for running MySQL in the development environment.
[dev_mysql] db01.dev.example.net
And similar the wiki file contains all machines that run the Wiki software in the development environment.
[dev_wiki] wiki.dev.example.net
But the biggest trick in the dev environment are the files called zz_groups. These contain the dev group, with all the child groups.
[dev:children] dev_mysql dev_wiki
The reason this file is called zz_groups is because of the parsing order of Ansible. When the Ansible inventory is a directory, Ansible collects all files in the directory and processes them in alphabetical order. But: A group can only be used as a child if it is already defined. So the definition of the dev group, containing all children should come last, hence the name zz_groups.
In the top-level of the inventory there is a zz_groups file as well, containing:
[mysql:children] dev_mysql tst_mysql acc_mysql prd_mysql [wiki:children] dev_wiki tst_wiki acc_wiki prd_wiki
This way you can run Ansible for the group wiki, mysql or the subgroups dev or dev_mysql, giving very fine-grained control over the set of hosts involved in the run.

The variables
For the variables the standard setup is used. Variables are defined per group, but we use a directory per group, instead of a file. All files in such a group directory are merged together by Ansible, ensuring all variables are available. The only reason to split it into separate files is for maintainability, every item has its file, e.g. inventory/group_vars/dev/mysql_users:
--- # Users for geerlingguy.mysql role mysql_users: - name: "{{ nagios_mysql_user }}" host: 'monitoring.%.example.net' password: "{{ nagios_mysql_password }}" priv: "mysql.*:SELECT" - name: localweb-admin host: '192.168.0.%' password: !vault | $ANSIBLE_VAULT;1.1;AES256 6234356232393063..........20190205145533373636643939303 3963313531613334..........20120223141787333235656464345 6435646338386130..........20121124133632266326161353133 3335646439303032..........33232303864356138656436643738 6232 priv: '*.*:SELECT/*.*:CREATE VIEW/*.*:INSERT'
Of course all defaults are in the all group directory, because all hosts in the inventory are automatically member of the all group.

The roles
When the inventory and the variables are in place, all the involved roles are need to be setup. Every role should have a branch for each environment, so a dev branch for the dev environment and so on. And all needed roles should be defined in the roles.yml file, like so:
- src: https://github.com/one-role/apache.git scm: git version: master name: apache
The version: tag should be present, but the value is ignored, it will be replaced by the refresh script with the branch that is currently being checked out.
Putting it all together
Once all the hosts, variables, roles and roles-files are in place, the next thing to do is to roll it onto the Ansible control-node.
The order is:
$ ssh root@ansible.example.net # cd /etc # mv ansible ansible.org # git clone https://git.example.net/one-role/setup ansible # cd ansible # ./refresh -f
Of course, after the initial checkout, the only command needed is the refresh command. This will ensure all environments are filled with the correct information.
Now run Ansible through ansible_run for the selected environment and watch the magic happen.

Where to get it
You can get the framework from the Github “One Role” repositories.
Do read the docs in the docs repository to get more familiar with the concept.
I presented this concept in the Ansible Room at CfgMgmtCamp on February 5th in Ghent, Belgium and the slide deck is available at SpeakerDeck