With two days of AnsibleFest instead of one this time around, we had 100% more time to talk about Ansible things !

I got to attend great sessions, learn a bunch of things, chat and exchange war stories about Ansible, ARA, Zuul, Tower and many other things.

It was awesome and I wanted to take the time to share a bit about some of the great Ansible community projects that were featured during the event.

At one point during the keynotes, the Ansible community lead, Robyn Bergeron, talked about the community around Ansible with this slide:

Ansible Community Projects

It’s possible this was the first time you were hearing about these projects. Let me tell you about how awesome they are.

ansible-lint and molecule

Before AnsibleFest, Ansible announced their intention to adopt the ansible-lint and Molecule projects as part of a commitment to improve Ansible Galaxy.

ansible-lint helps you write consistent Ansible code for your roles and playbooks while adhering to best practices. I think the first project I really started using ansible-lint on was on WeIRDO, a CI framework, as far back as 2015 !

It’s simple and it just works:

$ ansible-lint examples/example.yml
[ANSIBLE0004] Git checkouts must contain explicit version
examples/example.yml:15
Task/Handler: git check

[ANSIBLE0002] Trailing whitespace
examples/example.yml:35
    with_items: 

[ANSIBLE0006] git used in place of git module
examples/example.yml:24
Task/Handler: executing git through command

Molecule provides a simple framework for easily and repetedly testing your roles and playbooks against different environments and operating systems. There was a great talk last year about it by Elana Hashman from Rackspace: Infrastructure Testing with Molecule.

I haven’t had the chance to try Molecule yet but here’s what it looks like in practice on Asciinema:

Zuul

Zuul drives continuous integration, delivery, and deployment systems with a focus on project gating and interrelated projects.

The recordings aren’t available yet but there were two sessions about Zuul at AnsibleFest last week:

Zuul eventually replaced Jenkins for the OpenStack community and if you’re curious why, you can read more about that story in a short interview on the SuperUser blog.

Zuul is awesome and let me try to give you a (long) elevator pitch of some of my favorite Zuul features:

  • By design, Zuul is meant to gate patches against your projects. Zuul will not merge a patch to your project until all the required jobs are green.
  • Your jobs in Zuul are written as Ansible roles and playbooks, letting you re-use your existing deployment code and leverage thousands of built-in Ansible modules and plugins natively out of the box.
  • Zuul takes care of providing you with an Ansible inventory for your jobs by abstracting the logic of creating and destroying single-use virtualized or containerized environments.
  • Every project managed by Zuul is independant and can manage their own jobs, inventories and pipeline configuration in tree.
  • When evaluating a change or a pull request, Zuul will speculatively load and run the new configuration coming from the change. This means you can create a new job and iterate on it until it works without even merging any code or commits.
  • Horizontally scalable for the vast majority of it’s workloads, Zuul is highly available and is designed to consume multiple clouds and regions concurrently with the expectation that they will eventually fail.
  • Zuul provides an implementation of ARA Records Ansible for providing host and task granular results and metrics through an intuitive reporting web interface.

If you’d like to learn more about how Zuul works and what it does, I like to recommend the following two presentations by core developers of the project:

You can chat with the Zuul users and developers on IRC or on mailing lists.

ARA Records Ansible

ARA Records Ansible playbook runs and makes the recorded data available and intuitive for users and systems.

I created ARA a little over two years ago to make it easy for Ansible users to understand and troubleshoot what occurred during their playbook runs.

In a nutshell, ARA provides a native Ansible callback plugin which saves everything to a local or remote database. It then provides a command line interface as well as a web interface to query that database and provide detailed metrics and reporting for your Ansible playbooks.

ARA is notably implemented in Zuul and is used for reporting on more than a million playbooks every month for the OpenStack community. You can find the ARA source code mirrored on GitHub.

If you’ve never seen an ARA report before, I’ve recorded a live demonstration of the web interface a while back which is still accurate:


The upcoming major release, ARA 1.0, is all but a complete rewrite and has been more than a year in the making. 1.0 will feature a brand new REST API which will let users query and integrate their Ansible execution data in their tools and workflows.

The to-do list for 1.0 is shrinking and I’m really excited that we’re getting to a point where people can start using it for testing purposes. If you’d like to test 1.0 or contribute to ARA, please reach out to me on IRC, Slack or Twitter!