We at Telestax use Ansible for server orchestration. The repository is monolithic, designed in a way to have each micro service delegated to a role. Gradually the repository has been beefed up with different microservices(roles) and supporting common roles.

Now you can imagine the problems for a repo which is managed by multiple people, at times by multiple teams with different understanding, contributing at the same time. Multiple code merges can become impossible to manage. But the good news is it’s a common software engineering problem which is already solved.

For a while we were the busy cavemen until it was evident we needed to have Continuous Integration for our ansible repository.

I want to focus this post on Why instead of How. There is a ton of information on implementation details. Some links in the references can help you get started as well. I hope after the end of this post you will be able to evaluate if your ansible repo requires a CI pipeline or not.

Why we implemented CI for ansible

Test breaking changes for existing roles. Imagine a scenario you make a change in a role used by all microservices. You need to make sure none of the microservice breaks. One way to test is to run all ansible playbooks for all microservices manually and make sure everything is alright. Its not hard to imagine that it is not possible if the roles and commits increase even slightly in count and frequency. Automated Testing and post deployment verification

Ansible is good at notifying you for failing tasks but sometimes you need to have post deployment sanity checks which maybe aimed at application layer. For example your playbook ran without any error but it failed to bring the application up. You can catch this by simple asserts in testinfra test cases. A tool for anyone to quickly verify their changes

There maybe different level of expertise in your organisation for a given technology. A CI pipeline can facilitate in that regard as everyone can have a go at the code and verify their changes. It helps eliminating silos in the organisation. Improved uptime and SLAs

It is important to ensure the quality of the code as it evolves and new features are added. With a flexible framework where you can quickly add service validation tests, it pays back massively in service uptime and SLAs. Pre-requisite for Continuous Delivery

Ingredients of Ansible CI pipeline

Git Ansible Repository(bitbucket, github etc) Ansible Molecule compatible roles Jenkins

The Recipe

The ingredients can have different flavours for example you can use vagrant, vm-box, gcp or aws to run the CI pipeline. At the heart of this pipeline is the jenkins file which ties up all together. So let’s take a look at the general flow of the pipeline

The Flow

Enough with the fluff show me the code

Ansible_ci_pipeline.jenkinsfile

Conclusion

After setting up this jenkins pipeline you will have a CI pipeline for your ansible project. It will run all the roles using infrastructure created by molecule create command. Optionally you can move towards continuous delivery when this pipeline verifies all the roles.

References