Chapter 5: Infrastructure Management for Enterprises with AWX

It is clear that Ansible is an incredibly powerful and versatile automation tool, lending itself well to managing an entire estate of servers and network devices. Mundane, repetitive tasks can be made repeatable and straightforward, saving a great deal of time! Obviously, this is of great benefit in a corporate environment. However, this power comes at a price. If everyone has their own copy of Ansible on their own machines, how do you know who ran what playbook, and when? How do you ensure that all playbooks are correctly stored and version-controlled? Furthermore, how do you prevent the proliferation of superuser-level access credentials across your organization, while benefiting from the power of Ansible?

The answer to these questions comes in the form of AWX, an open-source enterprise management system for Ansible. AWX is the open-source, upstream version of the commercial Ansible Tower software available from...

Technical requirements

To follow the examples presented in this chapter, you will need a Linux machine running Ansible 4.3 or newer. Almost any flavor of Linux should do; for those interested in specifics, all the code presented in this chapter was tested on Ubuntu Server 20.04 LTS unless stated otherwise, and on Ansible 4.3. The example code that accompanies this chapter can be downloaded from GitHub at this URL: https://github.com/PacktPublishing/Mastering-Ansible-Fourth-Edition/tree/main/Chapter05.

Check out the following video to see the Code in Action video from Packt: https://bit.ly/3ndx73Q

Getting AWX up and running

Before we get stuck into installing AWX, it is worth briefly exploring what AWX is, and what it isn't. AWX is a tool to be employed alongside Ansible. It does not duplicate or replicate, in any way, the features of Ansible. Indeed, when Ansible playbooks are run from AWX, the ansible-playbook executable is being called behind the scenes. AWX should be considered a complementary tool that adds the following benefits, on which many enterprises depend:

• Rich role-based access control (RBAC)
• Integration with centralized login services (for example, LDAP or AD)
• Secure credential management
• Auditability
• Accountability
• Lower barrier to entry for new operators
• Improved management of playbook version control
• Fully featured API

Most of the AWX code runs in a set of Linux containers. However, the standard installation method has changed since the last edition of the book, and...

Integrating AWX with your first playbook

There is a basic four-stage process involved in getting a playbook to run from AWX. Once you understand this, it paves the way for more advanced usage and fuller integration in an enterprise environment. In this part of the chapter, we will master these four stages in order to get to the point where we can run our first simple playbook, and this will give us the building blocks to move forward with AWX in confidence. The four stages are as follows:

1. Define a project.
2. Define an inventory.
3. Define credentials.
4. Define a template.

The first three stages can be performed in any order, but the template mentioned in the final stage pulls together the three previously created facets. Therefore, it must be defined last. Also, note that there does not need to be a one-to-one relationship between these items. Several templates can be created from one project. This is also the case for inventories and credentials.

Before...

Going beyond the basics

We have now covered the basics necessary to run your first playbook from AWX – the basics required for most Ansible automation within this environment. Of course, we can't possibly cover all the advanced features AWX has to offer in a single chapter. In this section, we will therefore highlight a few of the more advanced facets to explore if you wish to learn more about AWX.

Role-based access control (RBAC)

So far, we have only looked at using AWX from the perspective of the built-in admin user. Of course, one of AWX's enterprise-level features is RBAC. This is achieved by the use of users and teams. A team is basically a group of users, and users can be a member of one or more teams.

Both users and teams can be created manually in the AWX user interface, or through integration with an external directory service, such as LDAP or Active Directory. In the case of directory...

Summary

That concludes our whistle-stop tour of AWX. In this chapter, we showed that AWX is straightforward to install and configure once you know the core four-step process involved. We also showed how to build on this process with features such as surveys, notifications, and workflows.

You learned that AWX is straightforward to install (in fact, it installs with Ansible!), and how to add SSL encryption to it. You then gained an understanding of how the platform works, and how to go from a fresh install to building out projects, inventories, credentials, and templates to run Ansible jobs. You learned that there are many additional features that build on this. These were covered in the final part of this chapter in order to help you build a robust enterprise management system for Ansible.

In the next chapter, we will return to the Ansible language and look at the benefits of the Jinja2 templating system.

Questions

1. AWX runs either in standalone Docker containers or Kubernetes.

   a) True

   b) False

2. AWX provides which of the following to enterprises looking to manage their automation processes?

   a) A web UI

   b) A feature-complete API

   c) Source control integration

   d) All of the above

3. AWX directly supports the secure management of credentials for automation.

   a) True

   b) False

4. AWX provides a graphical development environment for creating and testing Ansible playbooks.

   a) True

   b) False

5. AWX can schedule unattended jobs to run.

   a) True

   b) False

6. In AWX, the pre-configured parameter set for an ansible-playbook run is known as what?

   a) Job Configuration

   b) Ansible Template

   c) Job Template

   d) Ansible Run

7. AWX can have its configuration divided between different parts of a business through the creation of which of the following?

   a) Teams

   b) Organizations

   c) Deploying a second AWX server

   d) Groups

8. In AWX, it is possible to tell which of the following?

   a) When a playbook was run

   b) Who ran the...