Infrastructre & Hardware

Running Ad Hoc commands from Ansible Automation Controller (Ansible Automation Platform)

Introduction

The automation controller (formerly known as Ansible Tower) is the control plane for the Ansible Automation Platform. The automation controller includes the WebUI, Role Based Access Control (RBAC), automation job templates, workflows, continuous integration and continuous delivery (CI/CD), credential management and many other features.

The automation jobs are executed using the job templates or workflow templates created by the administrators (or the user with Admin access) of the automation controller. The job templates are configured with a specific Ansible playbook, inventory, credentials and other configurations. The following image shows a job template OS Patching(RHEL) configured with ansible-os-patching-linux/site.yaml as playbook.

What are Ad Hoc commands in Ansible?

An Ad Hoc command in Ansible is a command which users execute using the ansible command line utility from an Ansible control node to accomplish a specific operation on one or more managed nodes. Users need to pass all required information while executing the Ansible ad hoc command and the pattern is as follows.

$ ansible [pattern] -m [module] -a "[module options]"

Some of the Ansible ad hoc commands are given below for example.

# Check the uptime of node1
$ ansible node1 -m shell -a "uptime"

# Copy file to the target host group webservers
$ ansible webservers -m ansible.builtin.copy -a "src=index.html dest=/var/www/html/index.html"

# Remove a package from dbservers
$ ansible dbservers -m ansible.builtin.yum -a "name=vim state=absent"

Please note, since this is an imperative method of executing automated tasks, Ansible ad hoc commands are not reusable but users can use them very easily and quickly.

Running Ad Hoc commands from Automation Controller

From the Ansible control node, users can easily execute the ad hoc commands as we seen earlier and in this section, we will learn how to execute similar ad hoc commands from an Ansible automation controller WebUI.

By default, we can use only a few modules to execute ad hoc commands from the automation controller as follows. But

[
  "command",
  "shell",
  "yum",
  "apt",
  "apt_key",
  "apt_repository",
  "apt_rpm",
  "service",
  "group",
  "user",
  "mount",
  "ping",
  "selinux",
  "setup",
  "win_ping",
  "win_service",
  "win_updates",
  "win_group",
  "win_user"
]

This is controlled by the configuration in the automation controller Settings -> Jobs settings – > Ansible Modules Allowed for Ad Hoc Jobs as shown below. It is possible to add or remove the supported module list under this field.

Execute the ad hoc command on managed nodes

It is possible to execute the ad hoc commands for a group of hosts or for an individual host. In the following example, the ad hoc command will be executed for a host group rhel8 (We have a managed node virtualbox-rhel8-generic under the host group).

1. Open Inventories

2. Open the inventory where your manage host (or group) is residing

3. Select the Groups tab (or Hosts tab if you want to execute on hosts)

4. Select the host group(s) and click on the Run Command button as follows

5. The Run command window will open and ask for details such as module name, arguments and other options as follows.

Let us use shell module and execute multiple commands (the argument field) uptime; whoami; uname -r for collecting some system information.

It is possible to pass arguments similar to ansible ad hoc commands such as extra variables, fork, privilege escalation and so on. In this case, we leave them as default and click the Next button.

6. Select the appropriate execution environment (we use the Default execution environment) and click the Next button.

7. Now select the credential to access the managed node to execute the command and click the Next button.

8. Verify the details in the preview screen and click the Launch button.

9. Automation controller will launch the job and job details will be displayed on the screen automatically. The success (or fail) status with output will be visible on the console as follows.

Refer to the automation controller documentation to learn more about ad hoc commands.

Running Ad Hoc commands using Ansible Navigator

If you are not using Ansible Controller or Ansible Automation Platform, but you want to test the ad hoc commands inside the container images, then you can use the ansible-navigator utility as follows.

Make sure you have the inventory and host variables configured

[dnsserver]
windns ansible_host=192.168.57.137

[dnsserver:vars]
ansible_user= "[email protected]"
ansible_password= "mycomplexpassword"
ansible_port= "5985"
ansible_connection= "winrm"
ansible_winrm_transport= "kerberos"
ansible_winrm_server_cert_validation= ignore

Execute the ad hoc command (eg: win_ping) as follows.

$  ansible-navigator exec --eei=localhost/win_ee:1.0 -- ansible dnsserver -m win_ping
windns | SUCCESS => {
    "changed": false,
    "ping": "pong"
}

You can use any container image and test ad hoc commands using ansible-navigator. In the previous examples, I have used my custom execution environment container image (localhost/win_ee:1.0) with Kerberos enabled to access a Windows machine using Active Directory login.

Disclaimer:

The views expressed and the content shared in all published articles on this website are solely those of the respective authors, and they do not necessarily reflect the views of the author’s employer or the techbeatly platform. We strive to ensure the accuracy and validity of the content published on our website. However, we cannot guarantee the absolute correctness or completeness of the information provided. It is the responsibility of the readers and users of this website to verify the accuracy and appropriateness of any information or opinions expressed within the articles. If you come across any content that you believe to be incorrect or invalid, please contact us immediately so that we can address the issue promptly.

Tags: aap · ad hoc command · Ansible · ansible automation controller · ansible command · ansible playbook · Ansible Tower · ansible training

Comments