Welcome to Introduction for Managing Ansible Infrastructure. This course will revolve around different ways of managing your Ansible architecture, including use of roles and managing your infrastructure as code.

In this final course, I will take what I've demonstrated in the previous courses, and bring it all together under Ansible Tower. I will introduce Ansible Galaxy, which adds the ability to utilize pre-packaged roles. I touched on this in the prior course with role dependencies. Lastly, I'll cover how Ansible integrates into a CI/CD environment.

Ansible Tower is an orchestration suite for your Ansible Infrastructure. Ansible Tower manages your inventories, playbooks, jobs, job scheduling, machine and cloud credentials, and user access control while providing a modern, web-based user interface along with both API and command line interfaces.

Unlike Ansible itself, Ansible Tower is not a community, open-source product, but instead a licensed product from Red Hat. This does not prevent us from using it, as Red Hat does provide a trial version that allows Tower to manage up to 10 nodes. This is fine for the purpose of this course and for the upcoming lab.

To install Ansible Tower, you must first create a trial license. Visit ansible.com/license for a Tower license. There are two types of licenses. For the purpose of this course, we'll use the Limited Features up to 10 Nodes license. Fill out the form, and a license will be sent in an email similar to the example shown here. Keep the license handy, as we'll need it after the Tower packages are installed.

I will be demonstrating Ansible Tower running under Ubuntu 14.04, so the installation will be specific to this version. Tower also has full support for Red Hat Enterprise Linux or CentOS, and additional installation documentation can be found on Ansible's website for these operating systems.

The only prerequisite for Ansible Tower is to have Ansible on the system. The provided link will work with Ubuntu 12.04 or 14.04. Start by fetching the installer from the provided link. With the package downloaded, I am now going to uncompress the tarball.

Next, I need to set the default username and passwords for Tower before installation. These can be found in the inventory file. And with escalated privileges, I can now run the setup script. As the setup runs, you'll notice the installation itself is a series of Ansible playbooks.

Since this is a demonstration environment, I'm going to grant the default Ansible Tower user awx sudo access. This is only for this demonstration, and it's recommended you manage local credentials with a dedicated user. I'll delve more into credentials later in this course.

With the installation completed and user configured, I can now start Ansible Tower and can access the web UI by visiting localhost in a web browser. You can ignore the security warning as this is a local demonstration. Using the password I set earlier, tower, I can log in using the admin username. As you can see, the first window after logging in is to accept the ULA and upload the license file.

Earlier, I created a license file and received an email with a copy of it as an attachment. The downloaded license file is uploaded here. Once accepted, I can now access the Ansible Tower user interface. It's worth noting that ports 80 and 443 need to be available to access the web-based user interface and the API, additionally, port 8080 should be open to allow live updates to the web UI.

Now that Ansible Tower is installed, running, and accessible, I'm going to get the sudoers role I wrote earlier running inside it, but before I get into that, let's briefly review the main workflow concepts of Ansible Tower. I've demonstrated the use of Ansible through playbooks and created roles based on those playbooks, I've also managed hosts, and groups of hosts, via Ansible's inventory system.

Ansible Tower breaks these components down slightly differently, and the jargon can get confusing throughout this portion of the course. Previously, I simply ran an Ansible role by passing an inventory and a playbook YAML file. In Tower, I need to start by creating a project. The project is where the source for your playbooks and roles is defined.

Next is the job template, the job template takes a project and configures where it runs, the starting playbook, and which credentials to run it with. When the project and job template are defined, I can then run the individual job. Each run of the job template will have a job assigned to it.

I mentioned assigning an inventory to a job template in the previous course. I talked about how inventories can be static inventories or dynamic, based on scripts. I went into detail regarding how hosts can be grouped and both groups and hosts can be parameterized. Inventories and towers is where this is all defined and configured, and the inventory object can contain multiple inventories and parameters. With these concepts and definitions in mind, let's add the sudoers role to Ansible Tower.

The first step is telling Ansible Tower where it will be running things. Ansible Tower provides an inventory system to manage this. All of the aspects of the Ansible inventory can be controlled through the inventory section of Tower. For this course, I will continue to use localhost.

I will create a new inventory by selecting inventories from the top of the UI and clicking the green add button. I'll name this local, enter a brief description, and leave the organization as default for now. I'm not going to set up any inventory parameters at this time, so I'll click save. Notice at the top of the page, local is specified as the path, and we have no groups or hosts listed.

As I mentioned earlier, for this example, there will only be the local host, so I'll click the green add host button, add the host name, and click save. I can scroll down now and see the host that I just created. If I click on the local in inventory/local/localhost, I can see now my host is part of the local inventory, and also clicking on inventories will now display my local inventory.

Dynamic inventories managed with scripts can be loaded and managed from the settings screen under inventory scripts, once a script is loaded into Ansible Tower, it is accessible as a valid inventory. As with the inventory interface, click on projects, and I'll click the green add button to bring me to the new project page, I'll set the name, and again a brief description, leaving the organization as default.

The last option on the screen is the SCM type. SCM is source code management, Tower supports Git, Mercurial, and Subversion, three very popular SCMs, lastly, it also supports manual, which is what I'm going to choose for this example. If I had chosen one of the actual SCMs, I would need to also supply a url, the SCM branch to pull from if necessary, and credentials to access the SCM of choice, and also choose how it manages the workspace.

Since I chose the manual option, it is now up to me to make sure my playbook is on the Tower server and up to date. When selecting manual from the pull-down, Ansible Tower should produce a warning stating that I currently have no playbooks on the host to choose from.

Now I will transfer that role to my Ansible Tower server, create a new subdirectory, and place it in that directory. Rename my role YAML to sudoers YAML and set permission so that everything is owned by owner and group awx:awx.

Now back in the user interface I will refresh the screen, and I'll re-enter my name and description. And I will choose manual again, and we will see that the option to choose our playbook directory is here with our playbook. It's worth noting that Ansible Tower will not display a playbook in the pull-down if the owner:group permissions are incorrect or if only a role and no master playbook exists. Click save to save this project.

To create a new credential, click on the settings icon, the small gear next to the user profile, select credentials, and click the green add button. I need to create credentials to run on the local system, they also require root access in the sudoers file, so I'll name my credential Local Root, and set the organization to default.

Now, the type of credential is where I can select what my target for my credentials are. As can be seen in the pull-down, there's quite a few options, many popular cloud options, as well as source control, network, and machine credentials.

Since I'm creating these for access to the local system, I'll select machine. The first username and password options are for SSH keys. I'll be dealing with local sudo access only, so I'll select sudo from the privilege escalation drop-down. This adds a new username field, which I'll set to the awx user, which has sudo access, and select save.

With the credentials now set, I can create the job template, so I'll start by selecting job templates from the top menu and clicking the green add button to create a new job template. I will now be presented with quite a few options, I'm running sudoers playbook, so I'll fill out the name and description accordingly. I'll leave it set to the local inventory, and the default project, there'll be more of these if there are more projects and inventories to choose from, but these are the only ones we have at the moment.

The playbook, we'll select the playbook we created earlier, and enable privilege escalation, and click save. And our job template was now created. Now there's a few other options on this menu, continuing now with the deployment of this sudoers job, it's time to run it. I'll click on the job template again, and click on the icon with the rocket to kick off the job.

I'm taken to a status page showing the current state of the running job, as the individual plays run, they will be listed in the tasks section, and the standard output will appear as well. Since my playbook just has the one play, it's the only one displayed. I have now successfully added my first playbook to Ansible Tower.

Introduction to Managing Ansible Infrastructure

About