When we run a playbook from AWX, what we're actually doing is running a template. Hence, to do this interactively, we will navigate our way back to the Templates screen, which should present a list of available templates. Note that when you are employing role-based access control, you can only see the templates (and inventories and other configuration items) that you have permission to see—if you don't have permission, it is invisible. This helps make AWX more manageable when using it across different teams.
We are using an administrator account, so we can see everything. To launch our newly created template, follow these instructions:
- Click on the rocket ship icon on the right of the template name, as shown in the following screenshot, which shows our newly created Templates with the option to execute it highlighted:
When you do this, the screen automatically reloads and you will see details of the run on your screen. Don't worry if you navigate away from this—you can always find it again later by clicking on Jobs on the left-hand menu bar. Since we have defined this job, it fails in the first instance. Luckily, the Jobs pane shows you all of the same details and output that you would get when you run Ansible from the command line, only in AWX, it is archived in the database so that you can always go back to it at a later date or so that another user can analyze it simply by logging into AWX (assuming they have the required permissions).
- Looking at the job output, we can see the problem is some kind of permissions issue, and a screenshot showing what this might look like is shown for your reference:
Taking a look at the playbook source code on GitHub, we can see that the original author hardcoded the use of the root user account for this playbook (note the remote_user: root statements in site.yml). Normally, you wouldn't do this—it is generally better practice to get Ansible to log in using an unprivileged account, and then to use sudo as required by putting the become: true statement in the play headers (we'll see this in action later in this book).
- To work around this, for now, we'll simply allow root logins over SSH on our CentOS 7 server, and then modify the credential in AWX to be for the root account. Note that you could also define a new credential and change the credential linked to the template—either are acceptable solutions. Once you have changed the credential, run the template again—this time, the output should look somewhat different, as we can see in the following screenshot, which is showing now a successful run of the playbook:
As we can see from the preceding screenshot, we have a successful playbook run, along with all of the relevant details about which user launched it, which revision on GitHub was used, which credentials were used, which inventory, and so on. Scrolling down this pane gives the output from ansible-playbook that we saw in the error screenshot previously; if we wish to, we can further analyze the playbook run to see whether there were any warnings, what was changed, and so on. Hence, with AWX we really achieve a nice simple user interface to Ansible, which integrates all of the good practices that should be present when automating Linux in an enterprise environment such as security, auditability, and centralized control of Ansible (and indeed playbook code through source control integration).
We have seen how AWX can assist us with running tasks manually—but what if we want a truly hands-off approach to task automation? We will explore scheduling tasks in the next section of this chapter.