ansible-blog_automated-webhooks-series

If your organization has adopted DevOps culture, you're probably practicing some form of Infrastructures-as-Code (IaC) to manage and provision servers, storage, applications and networking using human-readable, and machine-consumable definitions and automation tools such as Ansible. It's also likely that Git is an essential in your DevOps toolchain, not only for the development of applications and services, but also in managing your infrastructure definitions.

With the release of Red Hat Ansible Tower v3.6, part of the Red Hat Ansible Automation Platform, we introduced Automation Webhooks that helps enable easier and more intuitive Git-centric workflows natively. 

In this post we'll explore how you can make use of Automation Webhooks, but first let's look at IaC for some context and how this feature can be used to your organization's benefit.

 

Understanding Infrastructures-as-Code

Infrastructure-as-Code (IaC) is managing and provisioning computing resources through human-readable machine-consumable definition files, rather than physical hardware configuration or interactive configuration tools. It is considered one of the essential practices of DevOps along with continuous integration (CI), continuous delivery (CD), observability amongst others to automate development and operations processes and create a faster release cycle with higher quality. Treating infrastructure like it’s code and subjecting it to the same workflows, IaC provides the measurable benefits of cost reduction, faster time to market and remediation of the risk of costly errors and security vulnerabilities.

Ansible is a prime example of a tool that enables organizations to apply IaC techniques to their DevOps workflow. You’re probably here reading this blog post because you are using Ansible and using IaC techniques whether you realize it or not.

As an Ansible user you define the desired state of your infrastructure -- servers, cloud resources, networking -- as playbooks and roles that are expressed in YAML. This state, along with inventory and variables, is parsed by the Ansible engine and mapped to powerful abstractions (modules) that do the work of reconciling the present state to the declared desired state, whatever that may entail. Need to roll out a new service or adjust your existing infrastructure? Make a change to the Ansible content, commit it and apply it. Ansible only does what it has to, even if that means doing nothing because your infrastructure is in the state that is desired.

 

Assembling an IaC Ansible Pipeline

If you are treating your infrastructure as code then you have them in some sort of source control system. These days, when it comes to source control, we’re talking about Git, the distributed source control system that has become the defacto standard in the space.

With Git for source control and Ansible to manage the state of your infrastructure, what’s missing is how to automate what’s in a repo and getting Ansible to apply to your infrastructure.

A common architectural pattern that we've seen in our user base looks something like this diagram.

Tim blog 1

DevOps teams do work on their Ansible content and commit it to a Git repo. Those commits are picked up by a CI/CD tool, typically Jenkins, that makes a call out to the  Ansible Tower RESTful API to launch an associated playbook or workflow.

This is an effective way of implementing a git-centric continuous deployment pipeline using Ansible. Once setup, DevOps engineers do all of their work in Git using the toolchain and workflows they’re already using. The CI tool picks up the changes and tells Ansible to do it’s thing.

This is good, but not intuitive and a bit convoluted.  We thought we could do better.

 

Introducing Automation Webhooks

On the Red Hat Ansible team, we’ve been listening to customers, observing their usage and saw the benefits of these patterns to productivity and overall quality. We also thought we could provide a better user experience to git-centric deployment pipelines, one that was more straight-forward and easier to implement and manage. That's why last fall, Automation Webhooks were introduced to Ansible Tower v3.6, part of the Ansible Automation Platform.

These Automation Webhooks allow you to link a Git repository and Ansible automation natively. Once a repo link is setup, Ansible catches events (commits) from the Git system (GitHub, GitHub Enterprise, GitLab) and uses them to automatically trigger automation jobs to update projects, inventories, and perform deployments, all without requiring yet another tool such as Jenkins.

Tim blog 2

The benefits of having to use and manage the configuration of one less tool is clear. With these new capabilities, there is no need for an additional CI tool such as Jenkins to monitor repos and launch automation jobs when changes occur. There is no need to sync job parameters, manage user access and monitor activity across systems. Less moving parts means there are less things that could break and less risk of credentials leaking or your CI system being exploited to deploy things to production.

Let’s step through how you can put Automation Webhooks to work for you.

 

Setting Up Your First Ansible Automation Webhook

Let’s dive into setting up your first Automation Webhook with Ansible Tower.

First you will want to provide a GitHub or GitLab personal access token (PAT) as a credential to use in Ansible Tower to send status updates back to the webhook service. (See Credential Types in the Ansible Tower documentation to create one.) While this step is optional, we recommend you take the time to set up this credential. It’s a one time step that you can use with multiple Job or Workflow Templates you enable to receive webhooks.

Identify some automation that you’d want to run when a change happens to a given Git repository.  Automation Webhooks are enabled and managed from Job or Workflow Templates in Ansible Tower. In this tutorial, we’ll be using a Job Template, so if you don’t have one setup for it already you’ll need to do that now.

To enable an Automation Webhook for your Job Template, scroll down to the “Options” section and tick the “Enable Webhook” box. When you enable a webhook, other related fields display, prompting for additional information to setup the webhook source.

Screen Shot 2020-02-24 at 11.12.47 AM

Select the Git service to listen for webhooks. Currently only GitHub and GitLab are supported by Ansible Tower with others under consideration. 

Then, optionally, select the personal access token (PAT) as the credential to use for sending status updates back to the webhook service. Remember, before you can select it, the credential must already exist so if you skipped over this step, you’ll need to stop and do that now.

With a Git service and PAT selected, the Ansible Tower UI will automatically populate a couple of additional fields for you. A URL for the webhook service to POST requests  and a generated shared secret key to be used by the webhook service to sign payloads sent to Ansible Tower. The “Webhook Key” field has a refresh icon button to its right so you can click to generate a different secret key when needed.

Tim blog 4

Now with this unique webhook URL and secret key, go to your Git service and register the webhook on the repository you want Ansible Tower to accept webhooks. For more information on setting up webhooks for a supported service, see Working with Webhooks in the Ansible Tower documentation. Keep an eye out for Part 2 of this blog series that will demonstrate using webhooks to deploy changes to Windows IIS.

With that, you’re ready to give your webhook a try. Both GitHub and GitLab provide a way in their respective UIs to test that your webhook has been properly configured and is functional. Make a change to your repo’s content, push it to the Git repo and watch Ansible Tower take over in your dashboard.

Automation Webhooks are not just limited to Job templates. You can also enable them on your Workflow Templates. The UI and steps to do that are the same.

We think this is a much more intuitive and straightforward way to enable Git-centric workflows and all their benefits when using Ansible. Now anything you can do with Ansible Playbooks and Ansible Tower workflows can be run automatically with any commit to a Git repository.

 

Conclusion

So there you have it. Ansible Automation Webhooks provide native support of Git-centric workflows that are more intuitive and removes the need for an additional CI/CD tool such as Jenkins to monitor Git repos and launch automation jobs. We think you’re going to find this new capability really useful for unlocking even more benefit with Ansible and these types of workflow.

In a future blog post I will be showing you how you can use Ansible Tower and Automation Webhooks to implement GitOps pipelines that you can apply, not only to your Kubernetes clusters, but other “traditional” IT infrastructure like cloud services and networking hardware.