A Beginner’s DevOps Journey – Starting with Ansible (Part 2)

Understanding the Basics + Running Your First Ad-Hoc Commands

After writing Part 1, I rolled up my sleeves and built a local lab using Docker containers. No virtual machines. No AWS. No billing surprises. Just a lightweight setup running entirely on my laptop. If you want to try the same, I wrote a quick guide here:

👉 Build a Local Ansible Lab with Docker – No VMs Needed

Of course, you can spin up EC2 instances or VMs if you prefer. The point is: get a few machines talking to each other. Once that's set up, the real fun begins.

This post is about that very first step — the “aha!” moment when you run your first Ansible command and something actually happens on a remote machine.

Here’s what we’re covering:

• How Ansible connects and talks to your nodes
• What ad-hoc commands are and why they’re useful
• A few real commands to run and see results instantly

No YAML, no playbooks — not yet. Just enough to build confidence and get comfortable.

Let’s get started.

🧠 A Few Basics Before We Get Hands-On

Before we jump into typing Ansible commands like pros, let’s take a minute to peek under the hood — just enough to understand what’s actually happening when you run something.

🧱 The Control Node

I’m using my laptop as the control node. This is where Ansible lives. Think of it as the “brain” of the operation — issuing instructions to other machines, or in my case, containers.

🐳 The Managed Nodes (a.k.a. Docker Containers)

I spun up three Ubuntu containers on a custom Docker network named ansible. No deep reason for the number three — I just wanted a small playground with a few machines to manage.

📄 Creating an Inventory File

Now let’s teach Ansible where to find our nodes — and how to connect to them.

I created a file named inventory (but you can name it anything):

touch inventory

And filled it like this:

[nodes]
node1 ansible_host=localhost ansible_port=2221 ansible_user=devuser
node2 ansible_host=localhost ansible_port=2222 ansible_user=devuser
node3 ansible_host=localhost ansible_port=2223 ansible_user=devuser

Since we’re forwarding ports through localhost, this setup works perfectly.

🧩 Say Hello to Modules — The Real MVPs

Ad-hoc commands only work because of modules. These are the tools Ansible uses under the hood to get things done.

Think of them like little assistants — each with a specialty.

Here are a few you’ll use all the time:

Bookmark these — you’ll thank yourself later.

🚀 Let’s Run Some Ad-Hoc Commands

Everything’s prepped. Inventory? ✅
Containers running? ✅
SSH working? ✅

Let’s make Ansible do something.

✅ 1. Can We Even Talk to the Nodes?

Before you do anything fancy with Ansible, you need to know: Can it even reach the nodes?

ansible -i inventory all -m ping

Expected output:

node1 | SUCCESS => { "ping": "pong" }
node2 | SUCCESS => { "ping": "pong" }
node3 | SUCCESS => { "ping": "pong" }

What’s actually happening here?

Ansible is connecting to each node over SSH using the credentials you provided. Once it connects, it runs a tiny Python script on the other side. If everything goes smoothly, you get that sweet "pong" back.

📡 It’s a functional ping — not just "is the host alive?" but "can Ansible do its thing over SSH and is Python ready to go?"

This is your green light — your official “we’re in business” signal.

💬 2. Run a Basic Shell Command

Now that Ansible can reach your nodes, let’s start telling them what to do. The command module is the simplest way to do that.

Want to know how long each container’s been running?

ansible -i inventory all -m command -a "uptime"

Need a quick view of disk usage?

ansible -i inventory all -m command -a "df -h"

You’re not running these commands on your machine — you’re telling Ansible:

“Go log into each container, run this command, and tell me what they say.”

📦 3. Installing a Package

Let’s say you need a tool like curl on all your nodes. Rather than SSHing into each one and manually installing it, you let Ansible handle it for you:

ansible -i inventory all -m apt -a "name=curl state=present update_cache=true"

If you get a permission denied error, no worries — escalate privileges with:

ansible -i inventory all -m apt -a "name=curl state=present update_cache=true" -b -K

What’s really cool here is that Ansible isn’t blindly running apt install curl. It first checks: Is curl already installed? Is the package cache fresh?

Only if needed, it’ll install the package. That’s idempotence — and it’s a core part of what makes Ansible feel like automation rather than scripting.

🔐 Notice how we only added sudo escalation (-b) when we had to? That’s intentional. Ansible encourages a “least privilege” mindset — do what you can as a normal user, and elevate only when it’s necessary.

🧽 4. Removing a Package

And when it’s time to clean up?

ansible -i inventory all -m apt -a "name=curl state=absent" -b -K

Same logic as before — Ansible checks the current state, and if the package is present, it removes it. That’s the automation magic: you describe the state you want, and Ansible makes it so.

😌 When Should You Use Ad-Hoc Commands?

From what I’ve gathered so far, ad-hoc commands are amazing for:

• Quick testing
• Troubleshooting
• Exploring modules
• Doing “just one thing” on the fly

But if you’re doing something over and over — or want consistency across machines — you’ll want to write a playbook.

We’ll do that next.

🧠 Recap Time

You’ve done a lot in a short time. Here’s what you’ve accomplished:

✅ Set up a control node + managed nodes using Docker
✅ Wrote your first inventory file
✅ Used key Ansible modules
✅ Ran real tasks using privilege escalation

You didn’t even touch a playbook — and look how far you’ve come.

🚀 Coming Up Next…

In Part 3, we’ll move from one-off commands to proper automation. That means:

• Writing your first playbook
• Getting comfy with YAML
• Running repeatable tasks across all your nodes

Got questions? Stuck on something? I’m learning this stuff too, so feel free to drop a comment — I’ll either answer it or figure it out right beside you 🚀