Day 61 of 90 Days of DevOps Challenge: Ansible Playbook, Ad-Hoc commands

Vaishnavi DVaishnavi D
4 min read

On Day 60, I explored the Ansible architecture in depth and set up a complete control-and-managed-node environment on Amazon Linux. I covered all essential components like the control node, managed nodes, inventory files, modules, and plugins. That setup prepared me to start automating tasks using Ansible.

Today was all about getting hands-on with Ansible through ad-hoc commands and understanding the foundation of playbooks, the core of repeatable automation in Ansible

Ansible Ad-Hoc Commands

Ad-hoc commands are one-liners used to perform quick tasks on remote machines using Ansible modules without creating a YAML playbook.

Syntax:

ansible [pattern] -m [module] -a "[module-options]"
  • [pattern]: all, a group name (e.g., webservers), or a specific host

  • -m: specifies the module to use

  • -a: specifies arguments for the module

Common Modules & Examples

1. ping

Check connectivity between control node and managed hosts.

ansible all -m ping

2. shell

Run shell commands on remote machines.

ansible all -m shell -a "uptime"
ansible webservers -m shell -a "df -h"

3. yum / apt

Install packages on managed nodes.

For Amazon Linux / RHEL / CentOS:

ansible all -m yum -a "name=git state=present"
ansible webservers -m yum -a "name=httpd state=latest"

For Ubuntu/Debian (use apt):

ansible all -m apt -a "name=nginx state=present update_cache=yes"

4. service

Start, stop, or restart services.

ansible all -m service -a "name=httpd state=started"
ansible dbservers -m service -a "name=mysql state=restarted"

5. copy

Copy files to remote machines.

ansible all -m copy -a "src=/home/ansible/test.txt dest=/tmp/test.txt"

Bonus: Useful Flags

  • -u ansible: specify remote user

  • --become: run with sudo

  • -i inventory: specify inventory file

ansible all -i /etc/ansible/hosts -u ansible --become -m shell -a "uptime"

When to Use Ad-Hoc Commands:

  • Quickly test connectivity

  • Install small utilities

  • Restart a failing service

  • Run diagnostic commands

  • Copy or clean up temporary files

What is an Ansible Playbook?

An Ansible Playbook is a YAML file that defines a series of tasks to automate configuration, application deployment, or orchestration across your infrastructure.

While ad-hoc commands are good for one-time tasks, playbooks are meant for repeatable, consistent, and idempotent automation.

Key Features

  • Written in YAML (Yet Another Markup Language) human-readable and easy to write

  • Declarative — you define the desired state, not the step-by-step process

  • Idempotent — running the same playbook multiple times won't change the system if it's already in the desired state

Basic Structure of a Playbook

---
- name: Install and start Apache
  hosts: webservers
  become: true  # Run as sudo
  tasks:
    - name: Install Apache
      yum:
        name: httpd
        state: present

    - name: Start Apache Service
      service:
        name: httpd
        state: started
        enabled: true

Breakdown:

  • - name: Description of the play

  • hosts: The group of managed nodes from your inventory

  • become: true: Use sudo privileges

  • tasks: A list of operations to perform

Common Use Cases

  • Installing software packages (e.g., NGINX, MySQL)

  • Configuring system services

  • Creating files, copying templates

  • Managing users and groups

  • Deploying applications

  • Rolling updates with zero downtime

Benefits of Using Playbooks

FeatureBenefit
ReusabilityCan be version-controlled and reused across teams
ConsistencyAvoids configuration drift across environments
ScalabilityRun against hundreds of nodes with one command
VisibilityEach task has a human-readable name and status
IntegrationEasily plugs into CI/CD pipelines

Running a Playbook

ansible-playbook site.yml

Add options:

ansible-playbook -i inventory.ini -u ansible --become playbook.yml

Final Thoughts

Today was a practical leap forward in my Ansible journey. I now know how to:

  • Run ad-hoc commands to troubleshoot or execute quick tasks

  • Understand and write playbooks for reusable, production-ready automation

As I move forward, I’ll begin creating custom playbooks for common use cases, role-based playbook structures, and begin automating end-to-end deployment flows.

Stay tuned for Day 62, where I’ll dive deeper into Ansible Playbooks, covering variables, handlers, and conditional logic to make them even more dynamic and powerful.

0
Subscribe to my newsletter

Read articles from Vaishnavi D directly inside your inbox. Subscribe to the newsletter, and don't miss out.

Written by

Vaishnavi D
Vaishnavi D