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.
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.
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.
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.
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 are those of the author and do not reflect the views of the author’s employer or techbeatly platform.
Gineesh Madapparambath
Gineesh Madapparambath is the founder of techbeatly and he is the author of the book - ๐๐ป๐๐ถ๐ฏ๐น๐ฒ ๐ณ๐ผ๐ฟ ๐ฅ๐ฒ๐ฎ๐น-๐๐ถ๐ณ๐ฒ ๐๐๐๐ผ๐บ๐ฎ๐๐ถ๐ผ๐ป.
He has worked as a Systems Engineer, Automation Specialist, and content author. His primary focus is on Ansible Automation, Containerisation (OpenShift & Kubernetes), and Infrastructure as Code (Terraform).
(aka Gini Gangadharan - iamgini.com)
This site uses Akismet to reduce spam. Learn how your comment data is processed.
Leave a Reply