DEV Community: Shehar Yar Khan

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

Shehar Yar Khan — Sun, 20 Apr 2025 17:48:09 +0000

Hands-on with Playbooks – Practice Makes Pro! 🧪⚙️

Welcome to Part 3.5 of our DevOps journey! You’ve made it through playbooks, modules, tasks, and YAML—amazing progress. Now, it’s time to put all that knowledge to the test. This part is all about exercises—small but practical tasks you can try out in your local lab setup (remember, the Docker-based one we created earlier).

Ready? Let’s go 💪

📝 Exercise 1: Ping Only Web Servers 🔍

Let’s say you have a group of web servers you want to check for connectivity.

Update your inventory file to include a new group [web] with node1 and node2.
Write a playbook that pings only the web group.

Why it matters: In the real world, you often target specific server roles (e.g., only web or database servers) instead of your entire fleet.

💡 Hint: Use hosts: web in your playbook.

📝 Exercise 2: Install Developer Tools 🧰

You want to prepare your managed nodes for software development. Create a playbook that:

Updates the APT cache
Installs curl, git, and vim

Why it matters: Prepping dev environments is a common Ansible use case.

📝 Exercise 3: Set Up a Demo User 👤

Imagine onboarding a new team member. Create a playbook that:

Adds a new user named demo
Creates their home directory
Ensures correct ownership and permissions

💡 Use the user and file modules

Why it matters: User provisioning is a classic and practical automation task.

🧪 Exercise 4: Create Multiple Directories Using a Loop 🔁

Push yourself a bit—create a playbook that sets up the following directories under /home/devuser/:

logs
configs
backups

Goal: Use a loop to avoid repeating the same task.

💡 Look into loop: or with_items: syntax. This one’s slightly ahead of what we’ve covered, so feel free to experiment or look it up!

🚀 Bonus Project: Provision a Simple NodeJS App 🧑‍🍳

Let’s simulate a real-world deployment! Create a playbook that:

Installs nodejs and npm
Clones a GitHub repo containing a Node.js app
Installs app dependencies
Sets up a systemd service to run the app
Ensures the app is running and reachable

💡 Example project: Node.js Todo App – it’s simple, beginner-friendly, and a great candidate for automation!

Why this matters: Deploying an app is one of the best ways to test real-world automation skills. You’ll get a taste of web server setup, dependency management, service configuration, and remote code deployment—all in one go! Of course, there's a lot more to deployment than this, but it feels like a good start.

📬 Wrap-Up

These exercises are meant to reinforce everything we've covered so far—from inventory management to writing clean, effective playbooks. Try them out, tweak them, break them (safely), and most importantly: have fun!

When you're ready, we'll jump into Part 4 where we talk about variables, handlers, and conditional logic—aka making your playbooks smarter.

🚀 Keep going. You’re doing great!

Got stuck? Check the Ansible docs or drop your question in the comments section of any blog post. Let's learn together! 🙌

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

Shehar Yar Khan — Sun, 20 Apr 2025 08:07:25 +0000

Writing Your First Playbook + Understanding YAML ✍️📘

Up to now, I’ve been flexing my Ansible muscles with ad-hoc commands. Handy for quick fixes, but let’s be honest—typing them over and over? Not ideal. This is where playbooks step in to save the day. Think of them like scripts: reusable, organized, and a lot more powerful. If ad-hoc commands are like Post-it notes, playbooks are your bullet journal. 🗂️

📖 What is a Playbook?

A playbook is a YAML file that tells Ansible what to do. It’s a list of plays, and each play targets a group of hosts and runs a series of tasks on them. Whether you’re installing packages, creating users, or spinning up services—playbooks are how you automate it.

If you're familiar with pubspec.yaml from Flutter or any YAML-based config (like GitHub Actions), this will feel comfortably familiar. 💡

A basic playbook contains:

Name – A human-friendly label 🏷️
Hosts – The machines you want to affect 🧑‍💻
Tasks – The step-by-step jobs for Ansible to run ✅

🔧 Using `ansible.cfg` to Simplify Things ⚙️

One of the first things I did when starting out was to simplify my workflow. Typing -i inventory and setting the key file every time gets old fast. Let’s fix that.

Create an ansible.cfg file in your project folder with the following:

[defaults]
inventory = ./inventory
private_key_file = ./ansible

Now you don’t need to add -i inventory or --private-key to every command—Ansible will automatically know where to look. 🔍 It’s one of those tiny wins that make your life way easier.

🏁 First Playbook: Ping All Nodes 🛎️

Let’s ease into playbooks with a classic: the ping. This checks if our managed nodes are reachable.

Create a file named ping-nodes.yml:

- name: Ping all nodes
  hosts: all
  tasks:
    - name: Check connectivity
      ansible.builtin.ping:

Run it with:

ansible-playbook ping-nodes.yml

Simple, right? 🎉 You’ve just written and executed your first Ansible playbook!

🛠 Second Playbook: Perform Multiple Tasks 🧰

Let’s get a little fancier. I wanted to try something a bit more involved—so I created a playbook that updates the system, installs a package, and creates a directory. Here’s how you can do it too.

Create multi-task.yml:

- name: Multi-task playbook
  hosts: all
  become: true
  tasks:
    - name: Update APT cache
      apt:
        update_cache: yes

    - name: Install curl
      apt:
        name: curl
        state: present

    - name: Create a directory
      file:
        path: /home/devuser/mydir
        state: directory
        mode: '0755'
        owner: devuser
        group: devuser

What this playbook does:

🌀 Updates the package index
📦 Installs curl if it's not already installed
📁 Creates a directory at /home/devuser/mydir

To run it:

ansible-playbook multi-task.yml --ask-become-pass

What’s that flag? ❓

become: true: Tells Ansible to run the tasks with elevated privileges (like sudo)
--ask-become-pass: Prompts you to enter the password for privilege escalation 🔐

Pro tip: I always like to include --ask-become-pass for these early setups—it keeps things secure and makes sure you’re aware when privilege escalation is in play.

📦 Explore Other Modules 🧭

We’ve only scratched the surface. Here are some modules we used—and where you can learn more:

🟢 Ping: Test connectivity
📦 APT: Manage packages on Debian-based systems
📁 File: Create/remove files and directories

Whenever I'm unsure what a module can do—or what options it supports—the documentation is my go-to. Don’t hesitate to explore and experiment. 🧑‍🏫

⚠ Common Pitfalls 🪤

YAML indentation: Always use spaces (not tabs), and make sure things are aligned properly
Forgetting become: true: Some actions (like installing packages) need elevated privileges. If they silently fail, this is likely why 😅
Over-engineering too early: Start simple. Grow later. 🌱

💡 Try dry runs with --check to preview what will happen:

ansible-playbook multi-task.yml --check

⏭ What’s Next? 🚀

With basic playbooks under your belt, the doors to automation are officially open. You can now replicate tasks, share them, version them—welcome to scalable DevOps! 🤖

In the next part, we’ll look at variables, conditionals, and handlers—making your playbooks even more powerful and dynamic.

Stay tuned. It only gets better from here ✨

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

Shehar Yar Khan — Tue, 15 Apr 2025 19:45:41 +0000

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:

Module	What it does	Docs
`ping`	Tests connection + checks Python	🔗
`command`	Runs simple shell commands	🔗
`apt`	Installs/removes packages (Debian/Ubuntu)	🔗
`service`	Starts, stops, or restarts services	🔗

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 🚀

A Beginner’s DevOps Journey: Starting with Ansible (Part 1)

Shehar Yar Khan — Sat, 12 Apr 2025 18:24:27 +0000

"This is the first post in my series on learning Ansible from scratch as part of my transition into DevOps. If you're looking to get hands-on with automation, you're in the right place."

🧭 Why I Started Learning Ansible

I’ve been seriously considering a career shift into DevOps.

I've always been fascinated by what happens after the code is written—how it gets deployed, how environments are configured, how systems scale without burning to the ground. The more I looked into it, the more I saw one common thread: automation.

That’s when I started noticing Ansible popping up everywhere:

On job listings
In blog posts
In DevOps courses

I kept seeing things like:

“If you're new to DevOps, start with Ansible.”

I don’t know if that’s a good advice or not—but here we are. And for me, it made sense. Ansible seemed like the perfect entry point:

Written in YAML, which is super readable (and I had experience with thanks to Flutter).
Agentless, so I didn’t have to install anything on remote machines.
Great for automating repetitive tasks, which is basically the DevOps way.

So I dove in. And instead of just taking notes, I decided to turn this into a public learning journey—a series of posts that document every step of the way, with examples, breakdowns, and lessons learned.

If you're also looking to get into DevOps but don't know where to start, this series might be just the thing to help you take that first step.

🧪 How I'm Learning

I’m learning by doing (and of-course, by going through some tutorials and documentation), in small, focused sessions.

Here’s what my setup looks like:

A Docker-based Ansible lab (I’ll walk you through this in the next post)
Short, real-world examples (like installing packages, managing users, etc.)
A “try it, break it, fix it” mindset

It’s hands-on, beginner-friendly, and focused on real progress over perfect understanding.

📚 What This Series Covers

Part	Title	What You'll Learn
1	Why I Started Learning Ansible	You are here!
2	Setting Up an Ansible Lab with Docker	Get a working lab in 5 minutes
3	Understanding Inventories & Hosts	Targeting machines with Ansible
4	Writing Your First Playbook	Automating tasks, one YAML at a time
5	Getting Modular with Roles	Reusing and organizing your playbooks
6	Using Variables, Loops & Conditionals	Making automation flexible and smart
7	Common Errors & How to Fix Them	Debugging and staying sane
8	A Small Project to Wrap It Up	Apply everything in a real use case

🧰 What You'll Need to Follow Along

Not much! Just:

A system with Docker installed (Mac, Windows, or Linux is fine)
Basic command line knowledge
Curiosity and patience (especially when YAML complains about indentation 😅)

🔜 What's Next?

In the next post, we’ll build a quick Ansible playground using Docker—no servers, no cloud accounts, no stress.

➡️ Part 2 is coming in a few days—follow me here on dev.to so you don't miss it!

Got questions? Drop them in the comments. And if you're also starting out with Ansible, let me know—I'd love to hear how your journey's going too!

🧪 Build a Local Ansible Lab with Docker (No VMs Needed)

Shehar Yar Khan — Wed, 09 Apr 2025 15:58:16 +0000

I recently put together a lightweight Ansible lab using Docker — and it’s been a super clean way to test playbooks without spinning up virtual machines or using the cloud.

Whether you're learning Ansible or just want a disposable playground, this setup gives you:

⚙️ What's Inside?

🐧 Three Ubuntu containers (managed nodes)
🔐 SSH enabled (user: root, password: root)
🐍 Python pre-installed for Ansible modules
🌐 Docker network named ansible
🎯 Port forwarding so you can SSH from your local machine

🚀 Why I Built This

I wanted a quick, minimal lab that would let me focus on learning Ansible without spending time managing VMs or cloud resources. With Docker Compose, I just run:

docker-compose up --build -d

…and I’m ready to automate.

🧪 Try It Out

Here’s what you need to do:

Clone the repo

   git clone https://github.com/sheharyar566/ansible-docker-lab.git
   cd ansible-docker-lab

Start the lab

   docker-compose up --build -d

SSH into a node

   ssh root@localhost -p 2221

Create an inventory file for Ansible and run:

   ansible -i inventory.ini all -m ping

🔗 Repo

👉 GitHub – Ansible Docker Lab

🌟 Found This Useful?

If this lab helped you out or saved you time, feel free to give the repo a star on GitHub! It’s a great way to show your support and help others find it too.

Happy automating! ⚙️