View on GitHub

ansible

Ansible Lab exercises

Workshop Exercise - Inventories, credentials and ad hoc commands

Table of Contents

Objective

Explore and understand the lab environment. This exercise will cover

Guide

Examine an Inventory

The first thing we need is an inventory of your managed hosts. This is the equivalent of an inventory file in Ansible Engine. There is a lot more to it (like dynamic inventories) but let’s start with the basics.

There will be one inventory, the Workshop Inventory. Click the Workshop Inventory then click the Hosts button

The inventory information at ~/inventory/inventory.ini was pre-loaded into the Ansible Tower Inventory as part of the provisioning process.

$ cat ~/inventory/inventory.ini
[all:vars]
ansible_user=user
ansible_ssh_pass=PASSWORD
ansible_port=22

[web]
node1 ansible_host=22.33.44.55
node2 ansible_host=33.44.55.66
node3 ansible_host=44.55.66.77

[control]
ansible ansible_host=11.22.33.44

Warning

In your inventory the IP addresses will be different.

Examine Machine Credentials

Now we will examine the credentials to access our managed hosts from Tower. As part of the provisioning process for this Ansible Workshop the Workshop Credential has already been setup.

In the RESOURCES menu choose Credentials. Now click on the Workshop Credential.

Note the following information:

Parameter Value
Credential Type Machine- Machine credentials define ssh and user-level privilege escalation access for playbooks. They are used when submitting jobs to run playbooks on a remote host.
username ec2-user which matches our command-line Ansible inventory username for the other linux nodes
SSH PRIVATE KEY ENCRYPTED - take note that you can't actually examine the SSH private key once someone hands it over to Ansible Tower

Run Ad Hoc commands

It is possible to run run ad hoc commands from Ansible Tower as well.


The simple ping module doesn’t need options. For other modules you need to supply the command to run as an argument. Try the command module to find the userid of the executing user using an ad hoc command.

Parameter Value
MODULE command
ARGUMENTS id

Tip

After choosing the module to run, Tower will provide a link to the docs page for the module when clicking the question mark next to “Arguments”. This is handy, give it a try.


How about trying to get some secret information from the system? Try to print out /etc/shadow.

Parameter Value
MODULE command
ARGUMENTS cat /etc/shadow

Warning

Expect an error!

Oops, the last one didn’t went well, all red.

Re-run the last ad hoc command but this time tick the ENABLE PRIVILEGE ESCALATION box.

As you see, this time it worked. For tasks that have to run as root you need to escalate the privileges. This is the same as the become: yes used in your Ansible Playbooks.

Challenge Lab: Ad Hoc Commands

Okay, a small challenge: Run an ad hoc to make sure the package “tmux” is installed on all hosts. If unsure, consult the documentation either via the web UI as shown above or by running [ansible@tower ~]$ ansible-doc yum on your Tower control host.

Warning

Solution below!

Parameter Value
yum command
ARGUMENTS name=tmux
ENABLE PRIVILEGE ESCALATION

Tip

The yellow output of the command indicates Ansible has actually done something (here it needed to install the package). If you run the ad hoc command a second time, the output will be green and inform you that the package was already installed. So yellow in Ansible doesn’t mean “be careful”…​ ;-).


Navigation
Previous Exercise - Next Exercise

Click here to return to the Ansible for Red Hat Enterprise Linux Workshop