This book is built around defining CaC. What this means is that along with showing you how to define something in the GUI, a more Ansible approach will be presented. Ansible is a method of automation, and time and time again I have seen folks manually creating and setting their automation through manual processes. In that vein, this will serve as a guide to automating your automation through code.
The benefits of CaC are as follows:
- Standardized settings across multiple instances, such as development and production.
- Version control is inherent to storing your configuration in a Git repository.
- Easy to track changes and troubleshoot problems caused by a change.
- Ability to use CI/CD processes to keep deployments up to date and prevent drift.
A best practice is that you create a development environment to make changes, initial deployments, and run tests. Nothing ever runs perfectly the first time – it is through iteration that things improve, including your automation. Through the methods described here, using this method helps prevent drift and allows you to keep multiple instances of an Automation controller configured and synced, such as development and production, which should be a simple process.
There are three approaches you can take to managing the services as part of AAP: the manual approach and managing the configuration through Ansible modules or roles.
Introduction to the roles and modules that will be used in this book
Throughout this book, various roles and modules will be referred to that belong to collections. Collections are a grouping of modules, roles, and plugins that can be used in Ansible.
awx.awx, ansible.tower, and ansible.controller are module collections that can be used interchangeably. These are all built off of the same code base. Each is built to be used with their respective product – that is, AWX, Tower, and the Automation controller.
redhat_cop.controller_configuration is a role-based collection. This means that it is a set of roles that's been built to use one of the three aforementioned collections to take definitions of objects and push their configurations to the Automation controller/Tower/AWX.
The redhat_cop.ah_configuration collection is built to manage the Automation hub. It contains a combination of modules and roles that are designed to manage and push configuration to the hub. It is built on the code from both of the previous collections, but specifically is tailored to the Automation hub.
redhat_cop.ee_utilties is built to help build execution environments. Its role is to help migrate from Tower to the Automation controller and build execution environments from definition variables.
The last one we will mention is redhat_cop.aap_utilities. This is a collection that was built to help with installing a backup and restore of the Automation controller and other useful tools that don't belong with the other controller collections.
The manual approach
Nearly everything after the installer can be set manually through the GUI. This involves navigating to the object page, making a change, and saving it, which works fine if you are only managing a handful of things, or making one small change. For example, to create an organization using the Ansible controller web interface, follow these steps:
- Navigate to the Ansible controller web interface; for example,
https://10.0.0.1/.
- Log in using your username and password.
- On the home page in the left-hand section, select Organizations | Add.
- Fill in the name, description, and any other pertinent sections.
- Click Save.
The following screenshot shows an example of the page where you can add an organization:
Figure 1.2 – Create New Organization
This method can be repeated for all the objects in the Automation controller. Although it is prone to mistakes, it can be useful for making quick changes when you're testing before committing the changes to code.
Using Ansible to manage the configuration
The best method is using Ansible to automate and define your deployment. The Ansible team has created a collection of modules that you can use to interact with the Automation controller. Upstream, this is known as awx.awx, and the official collection is named ansible.controller. The code is roughly the same between the two, but the latter has gone through additional testing and is supported by Red Hat. ansible-galaxy will need to be used to install the collections. You can use either of the two commands to do so:
ansible-galaxy collection install awx.awx redhat_cop.controller_configuration
ansible-galaxy collection install -r requirements.yml
This file can be found in /ch01/requirements.yml in this book's GitHub repository: https://github.com/PacktPublishing/Demystifying-Ansible-Automation-Platform.
There is a module for each object in the Automation controller. For example, the following module is used to create an organization:
// create_organization_using_module.yml
---
- name: Create Organization
hosts: localhost
connection: local
gather_facts: false
collections:
- ansible.controller
tasks:
- name: Create Organization
ansible.controller.organization:
name: Satellite
controller_host: https://10.0.0.1
controller_username: admin
controller_password: password
validate_certs: false
...
These modules do the heavy lifting of finding object IDs and creating the related links between various objects. This especially simplifies the creation of an object such as a job template.
Alongside this collection of modules, consultants at Red Hat, and a few other people working with the Ansible Automation controller, came up with the redhat_cop.controller_configuration collection. A series of roles was created to wrap around either the awx.awx or ansible.controller collection, to make it easier to invoke the modules and define a controller instance, as well as several other collections to help manage other parts of AAP. This book will assume you are using one of these two collections in conjunction with the redhat_cop collections.
The basic idea of the controller configuration collection is to have a designated top-level variable to loop over and create each object in the controller. The following is an example of using the controller configuration collection:
// create_organization_using_role.yml
---
- name: Playbook to push organizations to controller
hosts: localhost
connection: local
vars:
controller_host: 10.0.0.1
controller_username: admin
controller_password: password
controller_validate_certs: false
controller_organizations:
- name: Satellite
- name: Default
collections:
- awx.awx
- redhat_cop.controller_configuration
roles:
- redhat_cop.controller_configuration.organizations
...
This allows you to define the objects as variables, invoke the roles, and have everything created in the controller. It is often easier to import a folder full of variable files, such as the following task:
// create_objects_using_role_include_files.yaml
---
- name: Playbook to push objects to controller
hosts: localhost
connection: local
collections:
- awx.awx
- redhat_cop.controller_configuration
pre_tasks:
- name: Include vars from configs directory
include_vars:
dir: ./configs
extensions: ["yml"]
roles:
- redhat_cop.controller_configuration.organizations
- redhat_cop.controller_configuration.projects
...
The included files define the organizations exactly like the previous task, but the projects are defined as follows:
configs/projects.yaml
---
controller_projects:
- name: Test Project
scm_type: git
scm_url: https://github.com/ansible/tower-example.git
scm_branch: master
scm_clean: true
description: Test Project 1
organization: Default
wait: true
update: true
- name: Test Project 2
scm_type: git
scm_url: https://github.com/ansible/ansible-examples.git
description: Test Project 2
organization: Default
...
Because the GUI, modules, and roles are all the same information in different forms, each section will contain details about creating the YAML definitions and how to use them.
Using these methods is the primary way to interact with AAP as a whole. The focus will be on CaC since it is the recommended way of interacting with the Automation services. Like most tasks in Ansible, it is one of many ways to do the same thing.
Execution environments and Ansible Navigator
A newer feature of Ansible is the addition of execution environments. These are prebuilt containers that are made to run Ansible playbooks. These replace using Python virtual environments as the standard way of using different versions of Python and Python packages. The Ansible controller takes advantage of these environments to scale and run job templates as well. They solve the issue of it works for me, maintaining different environments across all nodes, and other problems that arose from the previous solution. They also double as a simplified developmental version of the Automation controller for testing a job template when you're using the same container as the controller:
Figure 1.3 – Ansible Navigator inputs
ansible-navigator was built to replace ansible-playbook; it allows you to run playbooks in a container in the command line, similar to how jobs are run inside the controller. To install ansible-navigator, use the pip3 install 'ansible-navigator[ansible-core]' command on your desired machine. Afterward, you can run the demo.yml playbook in the ch01 folder:
//demo.yml
---
- name: Demo Playbook
hosts: localhost
gather_facts: false
tasks:
- debug:
msg: Hello world
...
To run this playbook in a container, use the ansible-navigator run demo.yml -m stdout command. It should output a Hello world message. Using the –ee or –eei option, the execution environment can be specified. This allows the user to use the same execution environment that was used in the controller for testing and development.
Additional Python libraries and collections can be added to an execution environment, which will be covered in Chapter 8, Creating Execution Environments. Additional information can also be found at https://ansible-builder.readthedocs.io/en/stable/.
United States
United Kingdom
India
Germany
France
Canada
Russia
Spain
Brazil
Australia
Argentina
Austria
Belgium
Bulgaria
Chile
Colombia
Cyprus
Czechia
Denmark
Ecuador
Egypt
Estonia
Finland
Greece
Hungary
Indonesia
Ireland
Italy
Japan
Latvia
Lithuania
Luxembourg
Malaysia
Malta
Mexico
Netherlands
New Zealand
Norway
Philippines
Poland
Portugal
Romania
Singapore
Slovakia
Slovenia
South Africa
South Korea
Sweden
Switzerland
Taiwan
Thailand
Turkey
Ukraine
