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:
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
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 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:
- Using Zuul CI/CD system to test Ansible Networking content by Paul Belanger and Ricardo Carrillo Cruz from Red Hat
- The Build is Never Broken by Clint Byrum from GoDaddy
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.
The code that was in my pull request. @ZuulCI speculatively loaded the configuration in the patch and ran the job as configured. The job is an @Ansible playbook running ansible-lint inside an ephemeral @CentOS virtual machine in AWS that will be destroyed once the job has ended. pic.twitter.com/iR3xBVEx9R— ☁David Moreau-Simard (@dmsimard) August 24, 2018
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.
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!