Ansible Playbook Basics: A Beginner’s Guide (2025)

Introduction

As a network engineer, you have to deal with a lot of tasks. Maybe you manage one server. Perhaps you manage one hundred servers. You need to install software. You need to update the files. You need to start and stop services. Doing this all manually is slow. It is boring. And it is easy to make mistakes. What if you miss a server? What if you type the wrong command? This is a common problem. And there is a simple, powerful solution. It’s called Ansible. And if you really want to level up, taking an Ansible and Terraform course is a great way to master both configuration management and infrastructure provisioning in one go.

At the heart of Ansible is a simple idea: the playbook. This guide will teach you everything about Ansible playbook. We will start with the basics. We will walk through simple ansible playbook examples. Then, we will explore advanced features. You do not need to be a coding expert. You just need to be tired of doing the same tasks over and over again. This guide is for you. By the end, you will understand playbooks. You will be ready to automate your work.

Before we talk about Ansible playbook, let’s talk about Ansible itself.

What is Ansible?

Think of Ansible as a very smart assistant. You give this assistant a list of instructions. It then goes to all your computers, or servers, and follows those instructions perfectly—every single time.

What makes Ansible special?

• It’s Simple: Ansible uses a language called YAML. YAML is easy to read. It looks like a bulleted list. You do not write complex code. You just list what you want to be done.
• It’s Agentless: This is a big deal. You do not need to install special software on the servers you want to manage. Many other tools require an “agent” program to be running on every machine.
• It’s Powerful: Don’t let the simplicity fool you. Ansible can manage huge, complex systems. It can configure servers, deploy applications, and manage cloud services. It can do almost any task a system administrator does.

Ansible gives you speed and consistency. It turns your manual work into a repeatable process. You write the instructions once. Ansible does the work forever. The tool that holds these instructions is the playbook.

So, what is Ansible playbook? Let’s us understand it in detail.

What is Ansible Playbook?

Ansible Playbook is a YAML file that automates IT tasks. It contains a list of tasks for Ansible to run. Playbooks are idempotent and human-readable, making infrastructure automation simple and efficient.

That’s it. It is the core of Ansible. Think of it like a recipe for cooking. A recipe has a list of ingredients and a list of steps.

• The ingredients are your servers.
• The steps are the tasks you want to perform.

A playbook is written in YAML. YAML stands for “YAML Ain’t Markup Language.” YAML is a data serialization language. It’s a way to write data that is easy for both humans and computers to read. It uses indentation (spaces) to show structure. It does not use brackets or complicated symbols.

Ansible Playbook Structure

Let’s look at a very simple idea of a playbook. It won’t work just yet, but it shows the structure.

# This is a comment. It starts with a #.

- name: My first playbook
  hosts: web_servers
  tasks:
    - name: Make sure the apache web server is installed
      apt:
        name: apache2
        state: present

This looks simple, right? Let understand what these terms mean and how they can be distinguished.

• – (dash): A dash at the start of a line typically marks the beginning of a new item or ‘play’
• name: This is only a description for you. It informs you of what this play or even task should accomplish. It’s best never to omit names.
• hosts: This tells Ansible where to run the tasks. In this case, it’s a group of servers we have named web_servers.
• tasks: This is the list of actions to perform.
• apt: This is an Ansible module. A module is a tool that does a specific job. The apt module is for managing software on Debian or Ubuntu Linux.
• name: apache2 and state: present: These are parameters for the apt module. We are telling the module we want the package named apache2. In technical terms, we’re specifying that the apache2 package should be present—meaning installed—on all machines listed under the web_servers group.

Let us now understand the core elements of playbook in Ansible.

The Building Blocks of a Ansible Playbook

Every playbook in Ansible is made of a few key parts. Understanding these parts is the key to writing your own playbooks.

Inventory: Your List of Servers

Before you can run a playbook, Ansible needs to know about your servers. Where are they? What are their IP addresses or hostnames? This information goes into a file called an inventory.

An inventory file is usually a simple text file. It can look like this:

[web_servers]
192.168.1.10
server1.example.com

[database_servers]
192.168.1.20
db.example.com

Let us understand the above code.

Two groups are created:

• `web_servers`
• `database_servers`

When you specify `hosts: web_servers` in your playbook, Ansible targets the following:

• 192.168.1.10
• server1.example.com

For running a playbook on every server:

• Use `hosts: all`- Ansible executes tasks across your entire inventory

Plays: The Main Goal

A playbook is a list of plays. Each play is a set of tasks that runs against a specific group of hosts. A simple playbook might have only one play. A more complex playbook could have many plays.

For example, you could have one play to set up your web servers. Then, a second play to set up your database servers.

- name: Configure web servers
  hosts: web_servers
  tasks:
    # Tasks for web servers go here...

- name: Configure database servers
  hosts: database_servers
  tasks:
    # Tasks for database servers go here...

The three dashes (—) at the top of a YAML file are a good practice. They signal the start of the document.

Tasks: The Actions to Perform

Tasks are the heart of the playbook. Each task is a single action. You should have one task for each thing you want to do.

• Want to install a package? That’s one task.
• Want to copy a file? That’s another task.
• Want to start a service? That’s a third task.

Each task calls an Ansible module.

Modules: The Tools in Your Toolbox

Ansible comes with thousands of modules. Ansible module is a pre-written script that does a specific job. You don’t have to write the code to install software. You just use the module for it.

Here are some common and useful modules:

Package Management:

• apt: For Debian/Ubuntu systems.
• yum or dnf: For Red Hat/CentOS/Fedora systems.
• win_chocolatey: For installing software on Windows.

File Management:

• copy: Copies a file from your computer to the server.
• template: Copies a file, but lets you use variables. This is great for configuration files.
• file: Creates files or directories, or changes their permissions.

Service Management:

• service or systemd: Starts, stops, or restarts services on Linux.
• win_service: Manages services on Windows.

Command Execution:

• command: Runs a simple command.
• shell: Runs a command in a shell, allowing pipes and redirection.

You can find a module for almost anything. There are modules for managing cloud providers like AWS and Azure, for network devices, for databases, and much more.

Handlers: Tasks That Run on Notice

Sometimes, you only want a task to run when something else changes. The most common example is restarting a service.

Let’s assume you update your configuration file using the copy module while managing web servers. Simply copying the new file does not automatically apply the changes. It’s mandatory to restart the server. But, restarting the server whenever playbook execution takes place.

This is what handlers are for. A handler is a special kind of task. It only runs when it is notified by another task.

Here is how it works:

- name: Web server setup
  hosts: web_servers
  tasks:
    - name: Copy the apache config file
      copy:
        src: files/apache.conf
        dest: /etc/apache2/apache2.conf
      notify: Restart apache

  handlers:
    - name: Restart apache
      service:
        name: apache2
        state: restarted

Look at the notify: Restart apache line. This line connects the task to the handler.

1. Ansible hits the “Copy the apache config file” task.
2. It then checks if the apache.conf on the server matches your local copy.
3. If there’s a difference, it copies the updated file over, then flags that it needs to trigger the “Restart apache” handler. Pretty straightforward.
4. If the file is the same, it does nothing. It does not notify the handler.
5. After all the regular tasks in the play are finished, Ansible runs any handlers that were notified.

This is very efficient. It ensures you only restart services when you absolutely need to.

Let us now move on to next section where we will discuss different ansible playbook examples.

Ansible Playbook Example: Let’s Write a Real Playbook

Theory is good. Practice is better. Let’s write a complete playbook from start to finish.

Here we will write a playbook that installs and starts the Nginx web server on a group of servers.

Step 1: The Prerequisites

Before we start, you need a few things:

1. Ansible Installed: You need Ansible on your main computer (the “control node”). You do not need it on the servers you are managing.
2. A Server to Manage: You need at least one server that you can connect to via SSH. It may be a cloud server or a virtual machine on your computer. In this case, we will take an example of a Linux server with an apt package manager (such as Ubuntu).
3. SSH Access: You need to log in to your server with your control node without a password, via SSH keys. It is the standard method through which automated tools are connected.

Step 2: Create Your Project Directory

It’s good practice to keep your Ansible projects organized. Let’s create a folder.

mkdir ansible-nginx-project
cd ansible-nginx-project

Step 3: Create the Inventory File

Inside this folder, create a file named inventory. Put the IP address or hostname of your server in it.

File: inventory
Ini, TOML
[webservers]
192.168.1.50  # Replace with your server's actual IP address

We created a group called webservers.

Step 4: Create the Playbook File

Now, create the main file. Let’s call it install_nginx.yml. The .yml or .yaml extension is standard for YAML files.

File: install_nginx.yml
- name: Install and start Nginx
  hosts: webservers
  become: yes
  tasks:
    - name: Install nginx package
      apt:
        name: nginx
        state: latest
        update_cache: yes
    - name: Ensure nginx service is running
      service:
        name: nginx
        state: started
        enabled: yes

Let’s look at this playbook closely.

• hosts: webservers: We are targeting the group we defined in our inventory file.
• become: yes: This is important. To install software or manage services, you usually need to be the root user (or an administrator). become: yes tells Ansible to use privilege escalation (like sudo) to run the tasks.

Task 1: Install nginx package:

• We use the apt module.
• name: nginx: The package we want.
• state: latest: This ensures we have the latest version of Nginx installed. present would also work, but latest will update it if a newer version is available.
• update_cache: yes: This is like running sudo apt-get update before installing. It’s good practice.

Task 2: Ensure nginx service is running:

• We use the service module.
• name: nginx: The service we want to manage.
• state: started: We want to make sure the service is running.
• enabled: yes: This makes sure the Nginx service starts automatically if the server reboots.

Step 5: Run the Playbook

We are ready. Open your terminal in the ansible-nginx-project folder. Run the following command:

ansible-playbook -i inventory install_nginx.yml

You will see output on your screen. Ansible will tell you what it is doing.

The output shows each task.

• ok: The task ran successfully and did not need to make a change. “Gathering Facts” is an automatic first step where Ansible learns about the server.
• changed: The task ran successfully and made a change. In our case, we installed Nginx and started the service.
• failed: The task failed. Hopefully, you see failed=0

Now, if you open a web browser and go to your server’s IP address (http://192.168.1.50), you should see the “Welcome to nginx!” page. Success!

Advanced Ansible Playbook Features

Once you master the basics, you can start using more advanced features. These features make your playbooks more flexible and powerful.

Variables: Making Playbooks Reusable

Imagine you want to use the same playbook for two different projects. In one project, you need to install apache2. In another, you need to install nginx. You could copy and paste the playbook, but that’s not efficient.

This is where variables come in. A variable is a placeholder for a value. You can define the value of a variable in different places.

Let’s change our playbook to use a variable for the package name.

- name: Install a web server
  hosts: webservers
  become: yes
  vars:
    web_package: nginx
  tasks:
    - name: Install web package
      apt:
        name: "{{ web_package }}"
        state: latest

Here, we created a vars section and defined a variable named web_package. After that, during the task, we also called it {{ web_package }} in the task. The variables are used in double curly braces: {{ }}.

And now, when you prefer to install Apache, you simply modify a single line: web_package: apache2. The other parts of the playbook remain unchanged. This significantly simplifies the reuse of your playbooks.

Loops: Doing the Same Task Many Times

What if you need to install five different software packages? Or create ten user accounts? You could write five or ten separate tasks. Or, you could use a loop.

A loop allows you to execute the same activity repeatedly with different inputs.

Suppose we need to install nginx, git, and vim. We shall be able to do it by means of a loop.

- name: Install common packages
  hosts: all
  become: yes
  tasks:
    - name: Install a list of packages
      apt:
        name: "{{ item }}"
        state: present
      loop:
        - nginx
        - git
        - vim

The loop keyword takes a list of items. Ansible will run the task once for each item in the list. The first time, {{ item }} will be nginx. The second time, it will be git. The third time, it will be vim.

Loops save you a lot of typing and make your playbooks cleaner.

Frequently Asked Questions

Q1. What is a playbook in Ansible?

An Ansible playbook is just a YAML text file. Here, YAML is a data serialization language. It contains a list of tasks. Ansible executes these tasks on remote servers.

Q2. What is the difference between ansible and ansible playbook?

The `ansible` command runs single, simple tasks. In contrast, the `ansible-playbook` command runs a whole script of many ordered tasks, making complex automation simple and repeatable.

Q3. What is ansible playbook and role?

A playbook is your automation script in the form of a list of what to do. A role is a pre-packaged mechanism to combine playbooks, files, and variables in such a way that they can be reused.

Q4. How to write a playbook in Ansible?

You write a playbook in a simple YAML file. First, you define the hosts to manage. Then, you list the tasks you want to run using Ansible modules.

Conclusion

Ansible playbook can seem a little strange at first. But they are built on simple ideas. They are designed to be read by people. They turn complex processes into simple, repeatable lists.

In this blog, we learned that Ansible is a powerful assistant that can do that work for you. We discovered that the playbook in Ansible is the instruction manual you give to Ansible. We broke down the playbook into its key parts: plays, hosts, tasks, modules, and handlers. We explored variables, loops, and conditionals to make our playbooks more innovative and more flexible.

Your journey with automation is just beginning. The best way to learn is to do. Start small. Try to write a playbook for a simple task. Install a piece of software. Copy a configuration file. Create a user account.