Ansible / Ansible Course / Automation / Cloud / Infrastructre & Hardware

Running Ansible Ad-Hoc commands

We have already  run few ad-hoc command to list down the hosts in earlier sections.

See all parts of  Automation with Ansible Guides here

ansible <hosts | all> -m <module> -a <arguments>

Let’s try few modules to run as ad-hoc commands. Below one is a sample command to execute ping module on those listed hosts.

[root@ansible-box ~]# ansible all -m ping -i mylist 
box2 | SUCCESS => {
    "changed": false, 
    "ping": "pong"
}
box1 | SUCCESS => {
    "changed": false, 
    "ping": "pong"
}

Another one to check host uptime and user id using command module.

[root@ansible-box ~]# ansible all -i mylist -m command -a "uptime"
box2 | SUCCESS | rc=0 >>
 07:15:49 up  1:12,  2 users,  load average: 0.00, 0.00, 0.00
box1 | SUCCESS | rc=0 >>
 07:15:49 up 15 min,  2 users,  load average: 0.00, 0.00, 0.00
[root@ansible-box ~]# ansible all -i mylist -m command -a "id"
box2 | SUCCESS | rc=0 >>
uid=0(root) gid=0(root) groups=0(root)
box1 | SUCCESS | rc=0 >>
uid=0(root) gid=0(root) groups=0(root)

Some more examples below.

Install/Remove Package

[root@ansible-box ~]# ansible webservers -i mylist -m yum -a "name=httpd state=present"
#Or 
[root@ansible-box ~]# ansible webservers -i mylist -m yum -a "name=httpd state=absent"

Install on Ubuntu using module apt

[root@ansible-box ~]# ansible -i mylist webservers -m apt -a "name=apache2 state=present"

Start and enable a service

[root@ansible-box ~]# ansible -i mylist dbservers -m service -a "name=httpd state=started enabled=yes"

As we discussed earlier, we must use -b to become privileged user to install items. Let’s say we are using devops user to login (remote_user), make sure devops has sudo access on the target machine.

[devops@node1 ~]$ sudo cat /etc/sudoers.d/devops
[sudo] password for devops:
devops ALL=(ALL) NOPASSWD: ALL

Let’s try one command module without switching as privileged user.

[devops@ansible-box dep-adhoc]$ ansible localhost -m command -a 'id'
localhost | SUCCESS | rc=0 >>
uid=1000(devops) gid=1000(devops) groups=1000(devops),10(wheel) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

You can see, the output shows devops user details.

Now we will try command module with switching to dbadmin user and see the different.

[devops@ansible-box dep-adhoc]$ ansible localhost -m command -a 'id' -u dbadmin
localhost | SUCCESS | rc=0 >>
uid=1002(dbadmin) gid=1002(dbadmin) groups=1002(dbadmin) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

Let’s try another command with copy module as using privileged user.

[devops@ansible-box dep-adhoc]$ ansible localhost -m copy -a 'content="Managed by Ansible\n" dest=/etc/motd' -u devops --become
localhost | SUCCESS => {
"changed": true,
"checksum": "4458b979ede3c332f8f2128385df4ba305e58c27",
"dest": "/etc/motd",
"gid": 0,
"group": "root",
"md5sum": "65a4290ee5559756ad04e558b0e0c4e3",
"mode": "0644",
"owner": "root",
"secontext": "system_u:object_r:etc_t:s0",
"size": 19,
"src": "/home/devops/.ansible/tmp/ansible-tmp-1523860264.94-170788199948146/source",
"state": "file",
"uid": 0
}

Another example using file module.

$ ansible webservers -m file -a "dest=/tmp/mytext.txt mode=600" 
# or 
$ ansible dbservers -m file -a "dest=/tmp/mytext.txt mode=755 owner=devops group=devops"

And, please note some of the important arguments or option you can use while running ansible ad-hoc commands.

-m MODULE_NAME, --module-name=MODULE_NAME  # module name to execute (default=command)
-a MODULE_ARGS, --args=MODULE_ARGS # module arguments 
-i INVENTORY, --inventory=INVENTORY # specify inventory host path or comma separated host list.
--list-hosts # outputs a list of matching hosts; does not execute
anything else
-b, --become # run operations with become
--become-method=BECOME_METHOD # privilege escalation method to use (default=sudo
--become-user=BECOME_USER   # run operations as this user

We will explain about playbooks in next session.

See all parts of  Automation with Ansible Guides here

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: Ansible · ansible ad-hoc · ansible command · Ansible Doc · ansible training · Automation · Cloud

Comments