AAP overview

This book will mainly focus on the Ansible Automation controller, which is the largest part of AAP. Most of these components have upstream projects that they relate to and allow you to report issues, look at the code, and even contribute.

The platform is made up of the following parts:

• Automation controller (formerly Red Hat Ansible Tower)
• Automation execution environments
• Automation hub
• Automation services catalog
• Red Hat Insights for Red Hat AAP
• Ansible content tools

This chapter will provide a brief description of each of these parts and how they relate to the Automation controller. A model of these relationships can be seen in the following diagram:

Figure 1.1 – AAP relationship model

In the next section, we will provide an overview of AAP, as shown in the preceding diagram.

Automation controller (Red Hat Ansible Tower)

The Automation controller is the workhorse of AAP. It is the central place for users to run their Ansible automation. It provides a GUI, Role-Based Access Control (RBAC), and an API. It allows you to scale and schedule your automation, log events, link together playbooks in workflows, and much more. Later in this book, we will look at the functions of the controller in more detail.

Up until recently, the Automation controller was referred to as Ansible Tower until it was split to be the Automation controller and various execution environments. This removed the reliance on Python virtual environments and allowed the platform and the command line to use execution containers.

Note

This book will refer to the Ansible Automation controller, though 90% of the time, it will still apply to the older versions of Tower.

But what does the Automation controller have to do with Ansible? The short answer is that the controller runs Ansible. It provides an environment that allows jobs to be repeated in an idempotent fashion – in other words, a repeatable way that does not change the final state. It does so by storing inventories, credentials, jobs, and other related objects in a centralized place. Add in RBAC, credential management, logging, schedules, and notifications and you can execute Ansible so that it's more like a service, rather than a script.

The upstream version of the Automation controller is AWX. It can be found at https://galaxy.ansible.com/awx/awx. AWX is an unsupported version of the controller and was built to be installed inside a Kubernetes cluster of some kind. It is frequently updated, and upgrades between versions are not tested. Fixes are not backported to previous AWX versions as they are with the Automation controller and Tower. For these reasons, it's recommended for enterprise users to use the Automation controller.

The Automation controller will pull collections and roles from Ansible Galaxy or a configured Automation hub. It will also pull container images from an image repository or Automation hub if none are specified.

Automation execution environments

The Automation execution environments are something new that was introduced with AAP 2.0. Previously, Ansible Tower relied on Python virtual environments to execute everything. This was not portable and sometimes made development difficult. With the introduction of execution environments, Ansible can now be run inside portable containers called execution environments. These containers are built from base images provided by Ansible that can be customized. Details of that customization will be covered in Chapter 8, Creating Execution Environments.

Execution environments can be built using the ansible-builder CLI tool, which takes definition files to describe what to add to a base image. They then can be executed using the ansible-navigator CLI/TUI tool to execute local playbooks. These same containers can be used inside the Ansible controller to execute playbooks as well, decreasing the difference between executing something locally and on the controller.

Automation hub

The Automation hub is an on-premises deployment of Ansible Galaxy (https://galaxy.ansible.com/). It can host collections and container images. It can be configured to get certified collections from Red Hat's Content Collections of certified content that reside on their Automation hub at https://console.redhat.com/ansible/automation-hub, from the public Ansible Galaxy, or any valid collection that's been uploaded by an administrator. It is also a place for users to go to discover collections that have been created by other groups inside an organization. The upstream repository of the Automation hub is Galaxy_ng (https://github.com/ansible/galaxy_ng). It is based on pulp and has much of the same features as the Automation hub.

Collections have replaced roles in terms of a form of distributing content. They contain playbooks, roles, modules, and plugins. They should be used so that code can be reused across playbooks. Automation hub was built so that users could store and curate collections on-premises without resorting to storing tarballs in a Git repository or a direct connection to Ansible Galaxy.

When you're installing Automation hub, it is possible to set up an image repository as well to host execution environment container images. This is not present when you're using the OpenShift operator as it is assumed that if you have an OpenShift cluster, you should already have an image repository.

Automation services catalog

The Automation services catalog provides a frontend for users to run automation using a simplified GUI that is separate from the Ansible Automation controller. It allows for multiple controllers to be linked to it, and for users to order products that will launch jobs. It also allows users to approve jobs through the services catalog. It is an extension of the Automation controller. A good example of this service can be found at https://www.youtube.com/watch?v=Ry_ZW78XYc0.

Red Hat Insights for Red Hat AAP

Red Hat Insights provides a dashboard that contains health information and statistics about jobs and hosts. It can also calculate savings from automation to create reports. Go to the following website to access the Insights dashboard: https://console.redhat.com/ansible/ansible-dashboard.

This includes the following:

• Monitoring the Automation controller's cluster health
• Historical job success/failure over time
• An automation calculator to approximate time and money that's been saved by using automation

Ansible content tools

While not directly related to the Ansible controller, Ansible has tools that assist in creating and developing playbooks and execution environments. These include the CLI/TUI tool known as ansible-navigator, which allows users to run playbooks in an execution environment, the ansible-builder CLI tool, which can be used to create execution environments, and ansible-lint, a linter that you can use to check your code to make sure it follows best practices and conventions, as well as identifying errors in code.

Another tool is the Ansible VS Code Extension for Visual Studio Code at https://marketplace.visualstudio.com/items?itemName=redhat.ansible. This is an IDE extension for syntax highlighting, keywords, module names, and module options. While there are several code editors out there, including Visual Studio Code, Atom, and PyCharm, to name a few, the Ansible Visual Studio Code Extension is a great way to double-check your Ansible work.

That concludes our overview of AAP. Now, let's address how this book goes about interacting with the different parts of the platform.