Learn Ansible - Ad-Hoc Commands for Daily Operations

#Introduction

After episode 3, where we covered how to manage inventory — from INI and YAML formats, host grouping, host patterns, to dynamic inventory — in this episode we will put that inventory to use for real work: Ad-Hoc Commands.

Ad-hoc commands are Ansible's fastest and most concise mode. If you're the type who prefers to "ask first rather than write", ad-hoc is the answer: just one line of command, and dozens of servers respond instantly. In daily operations, this kind of moment happens very often — for example, at 2 AM there's an alert that a server's disk is full, and you just need to check 40 servers at once without writing a playbook.

But keep in mind: ad-hoc is not a substitute for playbooks. It's a pocket knife — fast for one-off tasks, but not the tool for repetitive work that needs to be documented. At the end of this episode, we'll see when to move on to playbooks.

#Main Discussion

#What Is an Ad-Hoc Command?

Simply put, an ad-hoc command is an Ansible command run directly from the terminal without a playbook file. It uses the inventory you prepared in episode 3, then executes a single module against the targeted hosts.

#Basic Ad-Hoc Command Syntax

The basic structure of an ad-hoc command is:

ansible <host-pattern> -m <module_name> -a "<module_args>"

Let's break down each part:

• <host-pattern> — the target servers, exactly like the host patterns we covered in episode 3 (all, webservers, webservers:&staging, and so on).
• -m <module_name> — specifies the module to use. Modules are the "weapon" that determines what Ansible does on the target servers.
• -a "<module_args>" — module arguments, containing module-specific parameters.

There are also common flags you will use very often:

The simplest example: testing the connection to all hosts in the inventory.

ansible all -i inventory.yml -m ansible.builtin.ping

web-01.prod.example.com | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python3"
    },
    "changed": false,
    "ping": "pong"
}
db-01.prod.example.com | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python3"
    },
    "changed": false,
    "ping": "pong"
}

Each host answers pong — meaning the SSH connection, authentication, and Python interpreter all work. Notice the output is in JSON, because that's the standard format for Ansible module execution results.

#Favorite Ad-Hoc Modules for Daily Operations

There's a set of modules you'll almost certainly use every day. Let's go through them one by one.

#Ping & System Status Modules

Besides ansible.builtin.ping, which we already tried above, another module you must know is ansible.builtin.setup — the module that gathers facts (system information) from every host.

ansible all -i inventory.yml -m ansible.builtin.setup -a "filter=ansible_distribution*"

web-01.prod.example.com | SUCCESS => {
    "ansible_facts": {
        "ansible_distribution": "Ubuntu",
        "ansible_distribution_file_parsed": true,
        "ansible_distribution_major_version": "24",
        "ansible_distribution_release": "noble",
        "ansible_distribution_version": "24.04",
        "discovered_interpreter_python": "/usr/bin/python3"
    },
    "changed": false
}

Without filter, the setup output is very long (containing CPU, RAM, all network interfaces, mounts, and more) — that's normal, because this module collects everything. The filter parameter helps narrow down the output when you only need a specific part.

#Command vs Shell vs Raw

These are the trio of modules most often misunderstood. All three execute commands, but in different ways:

Real examples of all three:

ansible all -i inventory.yml -m ansible.builtin.command -a "uptime"

ansible all -i inventory.yml -m ansible.builtin.shell -a "uptime | awk '{print \$3, \$4}'"

ansible all -i inventory.yml -m ansible.builtin.raw -a "uname -a"

#File & Directory Modules

To create directories, touch files, or set permissions, use ansible.builtin.file:

ansible all -i inventory.yml -b -m ansible.builtin.file -a "path=/var/www/blog state=directory owner=deploy group=www-data mode=0755"

The state argument determines the desired result:

To push a file from the control node to the target servers, use ansible.builtin.copy:

ansible all -i inventory.yml -b -m ansible.builtin.copy -a "src=/etc/nginx/sites-available/blog.conf dest=/etc/nginx/sites-available/blog.conf owner=root group=root mode=0644"

This scenario is very useful when you want to distribute the same configuration file to many servers at once.

#Package Management Modules

Installing, updating, or removing packages is the most common daily task. The module depends on the distro: ansible.builtin.apt for Debian/Ubuntu, ansible.builtin.dnf for RHEL/Rocky/Alma, and ansible.builtin.yum for older RHEL.

ansible all -i inventory.yml -b -m ansible.builtin.apt -a "name=nginx state=present update_cache=yes"

ansible all -i inventory.yml -b -m ansible.builtin.dnf -a "name=nginx state=present"

The state values for package modules:

#Service Management Modules

Manage services (start, stop, restart) with ansible.builtin.systemd_service for modern systems that use systemd:

ansible web -i inventory.yml -b -m ansible.builtin.systemd_service -a "name=nginx state=restarted"

The state parameter for service modules: started, stopped, restarted, reloaded. The enabled: true/false parameter controls whether the service starts automatically at boot.

#Practical Daily Operation Scenarios

Now let's combine everything into scenarios that genuinely happen in the field.

1. Check uptime across all servers

At night, the ops team wants to make sure no server has recently rebooted on its own:

ansible all -i inventory.yml -m ansible.builtin.command -a "uptime"

web-01.prod.example.com | SUCCESS | rc=0 >>
 11:24:35 up 42 days,  3:12,  1 user,  load average: 0.31, 0.45, 0.52
web-02.prod.example.com | SUCCESS | rc=0 >>
 11:24:35 up 3 min,  1 user,  load average: 1.10, 1.00, 0.90
db-01.prod.example.com | SUCCESS | rc=0 >>
 11:24:35 up 42 days,  3:12,  1 user,  load average: 0.10, 0.12, 0.11

Notice web-02 has only been up for 3 minutes — a signal that something is wrong on that server. With a single command, you've found an anomaly that needs investigating. Compare that with having to ssh into 3 servers one by one.

2. Rolling reboot

When there's a kernel update or a config change that requires a restart, do a rolling reboot. Although you could use command: reboot, there's a better dedicated module: ansible.builtin.reboot. This module performs the reboot, then waits for the host to come back online and SSH to be ready — so you know exactly when it's safe to move on to the next server.

ansible 'webservers:!web-01.prod.example.com' -i inventory.yml -b -m ansible.builtin.reboot

web-02.prod.example.com | CHANGED => {
    "changed": true,
    "elapsed": 42,
    "rebooted": true
}

3. Emergency SSH key push

A new team member needs access to all servers right now. The ansible.builtin.authorized_key module handles it safely — the key is added to authorized_keys without touching any other file:

ansible all -i inventory.yml -b -m ansible.builtin.authorized_key \
  -a "user=deploy state=present key='{{ lookup(\"file\", \"/home/budi/.ssh/id_ed25519.pub\") }}'"

#Getting to Know --check Mode (Dry Run)

Before running a command that modifies the system (like installing packages or restarting services), it's highly recommended to try --check mode first. This mode makes Ansible not actually change anything on the target — it only calculates and reports what would happen.

ansible all -i inventory.yml -b -m ansible.builtin.apt -a "name=nginx state=present" --check

web-01.prod.example.com | SUCCESS => {
    "changed": false,
    "msg": "OK"
}
db-01.prod.example.com | SUCCESS => {
    "changed": true,
    "msg": "If state is 'present', package 'nginx' would be installed"
}

Notice two things:

• Hosts that already have nginx installed report changed: false — nothing will change.
• Hosts that don't have it yet report changed: true with the message "would be installed" — Ansible tells you the changes it would make without actually making them.

#Common Mistakes in Using Ad-Hoc Commands

#Conclusion

In episode 4, we learned that ad-hoc commands are Ansible's pocket knife for daily operations. You now know the ansible <pattern> -m <module> -a "<args>" syntax, mastered favorite modules like ping, setup, file, copy, apt/dnf, systemd_service, and understand when to use command, shell, or raw. We also practiced real scenarios — checking uptime, rolling reboot, and emergency SSH key push — plus --check mode as a safety belt.

However, there's one fundamental limitation of ad-hoc: it is undocumented and not automatically idempotent. The command you ran at 2 AM can't easily be replayed by another teammate.

In episode 5, we will overcome this limitation by learning Writing Your First Playbook & Playbook Structure — turning ad-hoc commands into YAML files that can be run repeatedly, documented, and produce readable OK, CHANGED, and FAILED statuses that anyone can read. Keep your enthusiasm up!