Automating Deployments Using Ansible AWX & Jenkins

Sharing an office with a development team can be a challenge when you are a system administrator, you are always finding yourself doing “quick deploys” or logging into servers to take a look at configuration changes which “didn’t quite go as planned”.

As the team I work alongside currently have three projects in flight and each project is made up of three servers, development, staging and production, rather than carry on with giving the development team access to the servers or doing the deployments for them we decided it was time to make a few changes and automate their deployments.

The first thing we did was to sit down with the developers to document all of their different deployment processes and procedures – while each of the applications they are working on is being developed using the same framework there were slight differences in how each of the applications needed to be deployed.

Once we had the procedures documented we wrote an Ansible playbook which took everything we had learned and standardised them, we tried to make the tasks in the playbook as re-usable as possible, and everything, when it came to deploying and interacting with the code, was an option which could be toggled per project.

Now that we had a set of playbooks we discussed how best they could be executed, for the development and staging servers we decided that a webhook triggering an unattended deployment when the corresponding branch was updated the best option, for production we needed something which allowed named individuals to trigger a deployment quickly. The solution we came up with was to deploy Ansible AWX and Jenkins.

Jenkins was deployed to intercept the webhook from GitHub and then trigger the correct playbook run in Ansible AWX; this covered the unattended development and staging deployments meaning that developers were now in control of their deployments, all they needed to do was commit code to the required branch.

As you can see from the screen below, using Ansible AWX gave the development team an overview of the jobs which had been executed along with the status;

As Ansible AWX allows role-based access, this was also used as the tool which enabled people, such as the development manager, to manually trigger production deployments without having to have Ansible installed.

All of this means that the developers no longer need to login to any of the servers to action changes, and more importantly, the only time we have to get involved with a deployment is if there is an error flagged within Ansible AWX.