Ansible Playbooks – How I Learned to Automate Complete Tasks

 After getting comfortable with ad-hoc commands, I moved on to the most important part of Ansible — Playbooks.

This is where the real automation happens.
Ad-hoc commands are good for quick tasks, but playbooks allow me to write repeatable, structured, and complete automation scripts.

In this blog, I’ll explain playbooks in the simplest way possible, based on how I understood and practiced them.

---

⭐ What Are Ansible Playbooks? (In My Own Words)

Playbooks are YAML files where I define:

• what tasks I want to run

• on which servers

• in what order

• with what configurations

Playbooks allow me to automate full workflows like:

• installing packages

• configuring services

• deploying applications

• managing files

• creating users

• restarting services

For me, a playbook is basically:

“A step-by-step automation recipe written in YAML.”

---

⭐ Basic Structure of a Playbook

Here’s the structure I internalised:

- name: <description>
  hosts: <target_servers>
  become: <yes/no>
  tasks:
    - name: <task-1>
      module_name:
        option1: value
        option2: value

    - name: <task-2>
      module_name:
        option1: value

Important parts:

✔ hosts

The group or server names defined in my inventory.

✔ become

Whether I need sudo access (most tasks do).

✔ tasks

List of steps to automate.

---

⭐ My First Playbook (Simple Example)

This was the first playbook I created:

- name: Install and start nginx
  hosts: webservers
  become: yes
  tasks:
    - name: Install nginx package
      apt:
        name: nginx
        state: present

    - name: Start nginx service
      service:
        name: nginx
        state: started

Running it:

ansible-playbook -i inventory.ini nginx-setup.yml

Seeing nginx install and start automatically on all servers felt like real automation.

---

⭐ Understanding Each Part Better

1. Tasks

These are the individual steps inside the playbook.
Each task uses a module.

Example:

- name: Create a file
  file:
    path: /tmp/demo.txt
    state: touch

---

2. Handlers

Handlers run only when triggered by a task.

Example:

notify: restart nginx

Handler definition:

handlers:
  - name: restart nginx
    service:
      name: nginx
      state: restarted

I use handlers when updating config files or restarting services.

---

3. Variables

Variables make playbooks reusable and cleaner.

vars:
  pkg: nginx

tasks:
  - name: Install package
    apt:
      name: "{{ pkg }}"
      state: present

---

4. Loops

Useful when I want to perform a task multiple times.

- name: Install multiple packages
  apt:
    name: "{{ item }}"
    state: present
  loop:
    - git
    - curl
    - nginx

---

5. Conditions

Sometimes tasks should run only when a condition matches.

when: ansible_os_family == "Debian"

---

⭐ Another Practical Example I Used

A simple web server deployment:

- name: Deploy simple web page
  hosts: webservers
  become: yes

  tasks:
    - name: Install nginx
      apt:
        name: nginx
        state: present

    - name: Copy index.html
      copy:
        src: index.html
        dest: /var/www/html/index.html

    - name: Ensure nginx is running
      service:
        name: nginx
        state: started
        enabled: yes

This installs nginx, deploys a webpage, and ensures it stays running.
All automated with one command.

---

⭐ Why Playbooks Are the Heart of Ansible (My Realisation)

After working with multiple playbooks, I understood that:

✔ Playbooks bring consistency
✔ They are fully reusable
✔ They can automate complex workflows
✔ They make deployments error-free
✔ They are easy to read and modify
✔ They can be shared in teams for DevOps practices

Playbooks are the main reason companies use Ansible in real projects.

---

⭐ Final Thoughts

Learning Ansible playbooks gave me the confidence to automate full server setups.
Once I understood YAML structure and modules, writing playbooks became very smooth and enjoyable.

In the next blog, I will write about:

👉 Ansible Custom Inventory
(where I define servers in INI and YAML formats)