Book Image

Demystifying Ansible Automation Platform

By : Sean Sullivan
Book Image

Demystifying Ansible Automation Platform

By: Sean Sullivan

Overview of this book

While you can use any automation software to simplify task automation, scaling automation to suit your growing business needs becomes difficult using only a command-line tool. Ansible Automation Platform standardizes how automation is deployed, initiated, delegated, and audited, and this comprehensive guide shows you how you can simplify and scale its management. The book starts by taking you through the ways to get Ansible Automation Platform installed, their pros and cons, and the initial configuration. You’ll learn about each object in the platform, how it interacts with other objects, as well as best practices for defining and managing objects to save time. You’ll see how to maintain the created pieces with infrastructure as code. As you advance, you’ll monitor workflows with CI/CD playbooks and understand how Ansible Automation Platform integrates with many other services such as GitLab and GitHub. By the end of this book, you’ll have worked through real-world examples to make the most of the platform while learning how to manipulate, manage, and deploy any playbook to Ansible Automation Platform.
Table of Contents (21 chapters)
1
Part 1: Getting Ansible Automation Platform Up and Running
6
Part 2: Configuring AAP
13
Part 3: Extending Ansible Tower

Maintaining an Automation controller and hub through infrastructure as code paired with CI/CD

Keeping projects and other objects updated in the AAP can be painful and burdensome without using automation. CI/CD automation is a great way to solve these problems. This section will focus on using tasks to solve this problem.

There are files that have been introduced, scattered throughout the previous chapters, that set the contents of both Automation hub and the Automation controller in configuration files. When referenced, these files can be used by the redhat_cop.controller_configuration roles to manage the Automation controller. These have been collected in the ch12/controller/configs folder.

There are two main reasons to trigger code for maintaining state: to test a pull request, or to update a project or a configuration change after a merge has occurred. While the latter maintains state, the first allows for testing and provides checks prior to a merge, as follows:

//controller...