Getting Started with Ansible Ad-Hoc Commands

If you’ve ever needed to run the same command across 10, 50, or even 500 servers, you know how quickly it becomes tedious. This is exactly where Ansible ad-hoc commands shine—they let you execute quick tasks without the overhead of writing a full playbook.

Think of ad-hoc commands as your “one-liner automation toolkit.” They’re fast, direct, and perfect for tasks you don’t plan to reuse.

What Are Ansible Ad-Hoc Commands?

Ansible ad-hoc commands are simple, one-time commands executed via the CLI to perform actions on remote hosts. Unlike playbooks, they don’t require YAML files. You just run a command and get results immediately.

They’re especially useful for:

• Quick checks (uptime, disk usage)
• Restarting services
• Managing files
• Running shell commands across multiple machines

A First Look: Running Your First Command

Here’s a basic example that pings all hosts in your inventory:

1ansible all -m ping

Let’s break it down:

• all: target group (from your inventory)
• -m ping: module being used

This doesn’t send ICMP packets—it checks if Ansible can connect and authenticate.

Targeting Specific Hosts

You’re not limited to “all.” You can target groups or individual hosts:

1ansible webservers -m ping

1ansible db01.example.com -m ping

This flexibility makes ad-hoc commands powerful for controlled operations.

Running Shell Commands Across Servers

One of the most common use cases is executing shell commands:

1ansible all -m shell -a "uptime"

Or checking disk usage:

1ansible all -m shell -a "df -h"

Here’s where things get interesting—Ansible runs these commands in parallel across all targeted machines.

Shell vs Command Module

You’ll often see both used. There’s a subtle difference:

• command: safer, no shell processing
• shell: allows pipes, redirects, and shell features

Example with command module:

1ansible all -m command -a "uptime"

Managing Services in Seconds

Need to restart a service everywhere? No problem:

1ansible webservers -m service -a "name=nginx state=restarted"

This is far cleaner than SSH-ing into each machine manually.

Working with Files

Ad-hoc commands can also manage files efficiently.

Copy a file to remote servers:

1ansible all -m copy -a "src=/local/file.txt dest=/remote/file.txt"

Ensure a file exists with specific permissions:

1ansible all -m file -a "path=/tmp/demo.txt state=touch mode=0644"

Using Inventory and Authentication

Ansible relies on an inventory file to know where to run commands. A simple inventory might look like:

1[webservers]
2web1.example.com
3web2.example.com
4
5[db]
6db1.example.com

You can specify it explicitly:

1ansible webservers -i inventory.ini -m ping

And pass a user if needed:

1ansible all -u ubuntu -m ping

A Common Mistake Developers Make

It’s tempting to overuse ad-hoc commands for everything. But once a task becomes repeatable or complex, switching to a playbook is the better move.

Ad-hoc commands are best when:

• You need speed over structure
• The task is simple and one-off
• You’re debugging or inspecting systems

If you find yourself copy-pasting the same command repeatedly, it’s time to write a playbook.

Performance and Parallelism

By default, Ansible executes tasks in parallel using forks (usually 5). You can increase this:

1ansible all -m ping -f 20

This is useful when working with large infrastructures, but be cautious—too many parallel connections can overwhelm your network or hosts.

Quick Real-World Scenario

Imagine a production issue where you need to check memory usage across all app servers immediately:

1ansible app_servers -m shell -a "free -m"

Within seconds, you have visibility across your entire fleet. No scripts, no manual SSH sessions.

When to Use Ad-Hoc Commands vs Playbooks

There’s a natural progression when working with Ansible:

• Ad-hoc commands: quick, disposable tasks
• Playbooks: repeatable, structured automation

A good rule of thumb: if you care about consistency, auditing, or reuse—use a playbook.

Wrapping It Up

Ansible ad-hoc commands are one of the fastest ways to automate routine tasks across multiple servers. They require almost no setup beyond inventory and access, and they provide immediate value for developers and operators alike.

Start with simple commands like ping and uptime, then gradually explore modules like service, copy, and file. Once your tasks grow in complexity, you’ll naturally transition into playbooks—but ad-hoc commands will always remain your go-to tool for quick wins.