Managing Enterprise Automation with Red Hat Ansible Automation Platform

Webhooks help you automate workflows that involve multiple applications and components.

As an example of one way that webhooks can help automate workflows, the following diagram illustrates a common Continuous Integration (CI) workflow that might be used to perform tasks for the devices managed by Ansible.

Figure 8.3: Common CI workflow

In this example, the operations team is in charge of providing automation content that performs tasks on the Ansible-managed hosts. When the developers' team pushes a change to the Git content repository, the Jenkins CI tool captures this event. The event signals Jenkins to use the API on automation controller to automatically launch a job template that updates its copy of the project and runs on the managed hosts.

The following diagram shows another approach that uses webhooks:

Figure 8.4: Continuous integration workflow using webhooks

By using webhooks, you simplify the workflow. In this case, when a developer pushes something to the Git content repository, automation controller gets notified directly by a webhook. Automation controller then launches a job template that updates its copy of the project and runs on the managed hosts.

Therefore, one major benefit is that you can use webhooks to trigger actions on automation controller without the need to maintain and manage an additional Continuous Integration (CI) tool such as Jenkins.

To configure a project to update a job template to launch automatically when automation controller is notified by a webhook, you must configure the project and job template to meet certain requirements:

The following example outlines one way to do this for notifications from a GitLab repository. It enables a webhook listener for an existing job template that is already configured to run without prompting and that uses a project that is configured with Update Revision on Launch selected.

Figure 8.5: Configuring a job template webhook on automation controller

Before any user can configure webhooks on your GitLab server, an administrator of the server must allow them to be used.

If this has not been done, you need to log in to your GitLab server as a user that has an admin role. Navigate to Admin Area → Settings → Network → Outbound requests. Make sure that the automation controller to which you want to send webhook notifications is listed under Local IP addresses and domain names that hooks and services may access.

The result should appear similar to the following:

Figure 8.6: Enabling GitLab to permit webhook notifications to an automation controller

If this requirement is correctly configured, a regular user can create webhooks for their Git projects.

For this use case, you use a webhook for a job template specifying a branch from the Source Control Branch field. When you push new content for the given branch, the job template starts performing Ansible tasks on the inventory that you set up for that job template.

For example, suppose you want to test a Git repository for a development environment before going to production. In that case, you can create a development branch for the repository, configure the job template to use this branch, and associate the inventory with the development hosts. When you add a commit to the development branch, the webhook launches the job template for the development hosts.

After you verify that the development branch of your automation is working correctly, you can merge your changes to the production branch, and even use the same webhook mechanism to automatically launch a job template that runs for managed hosts in your production inventory.

Configuration as code is a technique that uses a version control repository to describe the desired state of your configuration.

You can use configuration as code methods in conjunction with Ansible Content Collections and Ansible Playbooks to manage the configuration of your Red Hat Ansible Automation Platform systems in a version control system. This is similar in principle to the concept of Infrastructure as Code, and has similar benefits.

For example, you could implement configuration as code to automatically reconfigure and help you maintain your Ansible Automation Platform servers. You set up files and Ansible Playbooks in a Git repository that define and apply the desired configuration for your automation infrastructure.

You can accomplish this by combining webhooks with playbooks that use the ansible.controller Ansible Content Collection. Using this Ansible Content Collection, you can configure most of the objects in automation controller (such as job templates, projects, inventories, and so on), using Git as a single source of truth.

To illustrate how this might work, imagine that you have a Git repository that contains an Ansible Playbook named add-users.yml that adds users to your automation controller.

That playbook contains the following play:

---
- name: Add user
  hosts: workstation
  gather_facts: False
  tasks:
    - name: Add user in controller
      ansible.controller.user:
        controller_host: "{{ controller_auth['host'] }}"
        controller_username: "{{ controller_auth['username'] }}"
        controller_password: "{{ controller_auth['password'] }}"
        validate_certs: False
        username: "{{ item['username'] }}"
        first_name: "{{ item['first_name'] }}"
        last_name: "{{ item['last_name'] }}"
        email: "{{ item['email'] }}"
        password: "{{ item['password'] }}"
        update_secrets: "{{ item['update_secrets'] | default(False) }}" 
        is_superuser: "{{ item['is_superuser'] | default('False') }}" 
        is_system_auditor: "{{ item['is_system_auditor'] | default('False') }}" 
        state: present
      loop: "{{ system_users['users'] }}"
      loop_control:
        label: "Adding user: {{ item['username'] }}"

The preceding play ensures that users exist on automation controller by looping over a list of users, and information about those users, stored in the system_users['users'] variable.

For example, to update that information without changing the Ansible Playbook, that variable is set in the project’s host_vars/workstation/users_teams.yml file. This could be written as follows:

---
system_users:
  users:
    - username: patrick
      first_name: Patrick
      last_name: Star
      email: patrick@lab.example.com
      password: redhat123
      update_secrets: False
      is_superuser: False
      is_system_auditor: False
      user_roles:
        - role: member
          user: patrick
          organization: Default
...output omitted...

You modify the users_teams.yml host variable file to update the list of users that should exist on automation controller, including appropriate information about what user type and team memberships each user should have.

Then, the following steps occur when you commit and push to the Git repository:

The webhook message contains information about who pushed the change, to what branch, what files were modified, and so on. The content of the message is available to your plays through the tower_webhook_payload variable. The following figure shows an excerpt of the payload that automation controller receives from the GitLab webhook:

Figure 8.8: Selected content from a GitLab webhook notification

You can also combine the ability to trigger a job template based on a given Git branch with this configuration as code technique to link different configuration states to different environments, such as development, test, and production.

To summarize some benefits of storing and managing your Ansible Automation Platform configuration as code: