Ansible best practices, private git repos and ansible-galaxy

Our experience on tweaking the Ansible's default role structure using git!

Ansible roles and private git repos

Ansible is a python tool that automates the management of an IT infrastructure. It is easy to learn but rushing to use it with a limited knowledge of its best practices (roles) leads to not reusable code. To quote the documentation about roles: “You absolutely should be using roles. Roles are great. Use roles. Roles! Did we say that enough? Roles are great.”.

So, writing reusable ansible roles is not easy but it's a task worth doing. This post will walk you through the construction of an ansible role scaffold supported by private git repos.

Install Ansible and git

Be sure to have git and Ansible installed. You should at least be working with ansible==2.3.0. Install Ansible in a virtualenv using pip to keep this environment clean.

$ pip install virtualenv
$ virtualenv myproject
$ . myproject/bin/activate
$ (myproject) pip install Ansible==2.3.0

Create an Ansible role

The first step

The first step in creating a role is creating its directory structure. Use the init command of ansible-galaxy, which comes bundled with Ansible, to initialize the base structure of a new role, saving time (and increase reproducibility) on creating the various directories.

What if you don't use Github?

Keep in mind that Ansible relies on Github, therefore the test files created by ansible-galaxy init command are meant to run CI (Continuous Integration) tests on Travis. But we work with GitLab! Our CI files are called .gitlab-ci.yml files and have a different syntax compared to Travis files. So, how can one leverage the ansible-galaxy command when he/she is not testing on Travis?

Write your own role scaffold

Starting from ansible==2.3.0 the ansible-galaxy command supports creating roles using a different role skeleton:

ansible-galaxy init --role-skeleton biodec.template/ -p . biodec.role_name

biodec.template is git project that we have developed during this year. It is an Ansible role scaffold to work and test things on GitLab. The main difference with respect to the default scaffold is the test file: .gitlab-ci.yml:

    image: buildpack-deps:stretch
       - apt-get update -y && apt-get install -y python python-dev python-pip
       - pip install -r requirements.txt
       - echo localhost > inventory
       - ansible-playbook -i inventory test.yml --connection=local -v

Advantages of our scaffold

We found convenient to use our own scaffold for a series of reasons besides testing on GitLab rather than on Travis:

  • write your own README (and licence);
  • write a custom dependency file that will gather roles from various sources (including another private git repository);
  • write a requirements file for pip that will keep Ansible's version fixed (a missing feature in ansible-galaxy which encourages you to work always with the latest version).


When developing Ansible code:

  • write/use roles!
  • write roles using standard tools like ansible-galaxy init
  • you can tweak the role skeleton if you want to and still adhere to Ansible's best practices
  • you can build your private Ansible Galaxy privately, on a self-hosted GitLab platform

A talk on this subject

We presented a talk at PyCon 8 this year talking about this subject. Feel free to download the slides if you like it.

archiviato sotto: , , , , , ,