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


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 playhosts
: The group of managed nodes from your inventorybecome: true
: Use sudo privilegestasks
: 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
Feature | Benefit |
Reusability | Can be version-controlled and reused across teams |
Consistency | Avoids configuration drift across environments |
Scalability | Run against hundreds of nodes with one command |
Visibility | Each task has a human-readable name and status |
Integration | Easily 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.
Subscribe to my newsletter
Read articles from Vaishnavi D directly inside your inbox. Subscribe to the newsletter, and don't miss out.
Written by
