prepforcareers.com

A Comprehensive Guide to Ansible Playbooks for Beginners

If you are just starting with Ansible, you have probably heard two terms again and again: Ansible ad hoc commands and Ansible Playbooks.

You may even be wondering:

“If I can run an Ansible command directly from the terminal, why do I need a Playbook?”

That’s a very good question.

In this beginner-friendly guide, we will understand what Ansible Playbooks are, why we need them, how YAML works, how an Ansible Playbook is structured, and finally, we will create our first working Playbook.

By the end of this article, you should have a clear understanding of the basic concepts behind Ansible Playbooks and be ready to start writing your own.

Agenda

In this article, we will cover:

  • Introduction to Ansible
  • Introduction to Ansible Playbooks
  • YAML — What, Why & Syntax
  • Breaking an Ansible Playbook into Parts
  • Your First Ansible Playbook

Let’s start from the basics.

Introduction to Ansible

Ansible is an open-source IT automation tool used to automate and manage systems and applications.

It is commonly used for:

  • Configuration management
  • Application deployment
  • Infrastructure automation
  • Orchestration

Instead of manually connecting to multiple servers and performing the same tasks again and again, Ansible allows you to automate those tasks from a central machine called the control node.

For example, imagine that you have 20 servers and you need to install Nginx on all of them.

Without automation, you might have to connect to each server and run the required commands manually.

With Ansible, you can describe what you want to happen and let Ansible perform the work across your managed servers.

This is one of the reasons Ansible is widely used in DevOps environments.

Ansible Documentation

Introduction to Ansible Playbooks

Now comes the question that almost every beginner asks when learning Ansible:

“Why do we need Playbooks? We already have Ansible ad hoc commands!”

And honestly, you’re right.

Ansible ad hoc commands are useful.

For example, if you want to install Nginx quickly, you can use an ad hoc command to perform that task directly.

Ad hoc commands are particularly useful for quick, one-time tasks. Ansible’s documentation also describes them as a good choice for tasks that you repeat rarely.

So, if one command can do the job, why bother creating a Playbook?

Let’s understand this with a simple example.

Imagine You Have Five Servers

Suppose you have five web servers and you install Nginx on all of them using an ad hoc command.

Everything works perfectly. A few days later, your manager says: “We have added five more servers. Please install Nginx on those servers as well.”

You add the new servers to your inventory. Now you can run the same ad hoc command again. No big problem.

But then your manager says: “Now install Git, configure Nginx, create a website directory, copy some files, start the service, and make sure everything is configured correctly.”

Now you have several commands to run.

And what happens if you need to perform the exact same setup next week on another 10 servers? Are you going to remember every command and run them one by one again?

That’s where Playbooks become useful.

BUT Your Colleague Has a Better Idea

Imagine your colleague comes to you and says:

“Why are you typing all those commands again? Put the tasks/commands into a book(playbook) once. Next time, just run the book(Playbook).”

And honestly…

That’s a pretty good idea.

Instead of repeatedly typing commands, you define the desired tasks in a YAML file.

For example:

Install Nginx
      ↓
Create configuration
      ↓
Copy website files
      ↓
Start Nginx

You can save those instructions in a Playbook and run them whenever you need them.

Ansible’s official documentation describes Playbooks as automation blueprints that can define configuration, deployment, and orchestration tasks.

So, think of it this way:

Ad hoc command → Great for quick, one-off tasks

Playbook → Great for repeatable, organized, multi-step automation

And that’s why a Playbook is not your enemy. It is your friend.

YAML — What, Why & Syntax

Before writing an Ansible Playbook, there is one thing you need to understand: YAML.

Ansible Playbooks are written in YAML because YAML is designed to be relatively easy for humans to read and write.

What Is YAML?

YAML stands for: YAML Ain’t Markup Language. It is a human-readable data serialization language commonly used for configuration files.

You will see YAML in many modern technologies, including:

  • Ansible
  • Kubernetes
  • Docker Compose
  • CI/CD tools
  • Cloud configuration

For Ansible, YAML is the language we use to describe our automation.

Basic YAML Syntax

You don’t need to become a YAML expert before learning Ansible, so don’t worry. You only need to understand some basic rules.

1. YAML Is Case-Sensitive

These are different:

name: nginx
Name: nginx

So make sure you use the correct capitalization.

2. --- Marks the Beginning of a YAML Document

You will commonly see this at the beginning of Ansible Playbooks:

---

It indicates the beginning of a YAML document.

The ... marker can indicate the end of a YAML document, but it is optional and you generally won’t need it in a normal Ansible Playbook.

3. Comments Start With #

Comments are ignored by Ansible.

# This is a comment
name: Install Nginx

Comments are useful when you want to explain what a particular part of your Playbook does.

4. Indentation Is Important

This is one of the most important YAML rules. YAML uses indentation to represent structure.

For example:

- name: Install Nginx
  package:
     name: nginx
     state: present

Notice that name and state under package are indented. Incorrect indentation can cause YAML parsing errors, so be consistent with spaces.

Never use random indentation just because the code looks visually correct.

Breaking an Ansible Playbook Into Parts

Now that you understand the basic YAML syntax, let’s finally look at an Ansible Playbook.

Here is a simple example:

---
- name: Set up Nginx
  hosts: webservers
  become: true
  tasks:
    - name: Install Nginx
      ansible.builtin.apt:
        name: nginx
        state: present

Don’t worry if this looks confusing.

Let’s break it down piece by piece.

---

This is the YAML document-start marker. It isn’t an Ansible task. It simply marks the beginning of the YAML document.

- name: Set up Nginx

This defines the name of the play. The name is mainly used to make the Playbook easier for humans to understand.

You could write:

- name: Install Web Server

or:

- name: Configure Production Web Server

A good name should describe what the play is intended to accomplish.

hosts: webservers

This tells Ansible which hosts should receive this play ( your target server ).

Here, webservers is an inventory group. If your inventory contains a group called webservers, Ansible will execute this play against the hosts belonging to that group.

Think of it as: “Ansible, run this play on the machines in the webservers group.”

become: true

Some tasks require elevated privileges. Installing system packages such as Nginx normally requires administrative privileges.

become: true tells Ansible to use privilege escalation for the play. On Linux systems, this commonly means using sudo to perform tasks with elevated privileges.

It does not simply mean that Ansible permanently becomes the root user.

tasks:

This is where we define the actual work that Ansible should perform.

For example:

Install Nginx
Create a file
Copy a configuration
Start a service
Create a user

Each individual operation is called a task. Tasks are executed in the order they appear in the Playbook.

- name: Install Nginx

This is the name of the task.

Again, the name is primarily for humans. When Ansible runs the Playbook, this name helps you understand what Ansible is currently doing.

ansible.builtin.apt:

This is an Ansible module. Modules are the units of code that Ansible uses to perform operations on managed nodes.

In this example, we’re using the built-in apt module to manage packages on Debian/Ubuntu-based systems. The ansible.builtin part identifies the module as coming from Ansible’s built-in collection.

Ansible has many modules for different purposes, such as managing:

You can explore the available modules in the official Ansible documentation.

Ansible Module Documentation

Module Parameters

Under the module, we provide the information it needs:

name: nginx
state: present

Here:

name: nginx

means we want to manage the Nginx package.

And:

state: present

means we want Nginx to be installed.

So this task is essentially telling Ansible: “Make sure Nginx is installed on the target server.“

Understanding the Structure

Now we can look at the Playbook as a hierarchy. This is one of the most important concepts to understand.

A Playbook can contain one or more plays ( from — to … end ).

A Play contains one or more tasks ( hosts name, become, name ).

A Task calls an Ansible module ( those tasks which we want to perform to the targeted servers like installing nginx, copying file, installing git ).

This structure is the foundation of Ansible Playbooks.

Your First Ansible Playbook

Okay, enough theory. Let’s actually create something.

For our first Playbook, we’ll create a small web-server setup.

Our goal is simple:

  1. Install Nginx
  2. Create a simple webpage
  3. Make sure Nginx is running

You will need a target server that is already configured in your Ansible inventory under the group webserver.

Now create a file such as:

first-playbook.yml

And add:

---
- name: Set up a simple web server
  hosts: webserver
  become: true

  tasks:

    - name: Install Nginx
      ansible.builtin.apt:
        name: nginx
        state: present
        update_cache: true

    - name: Create a simple webpage
      ansible.builtin.copy:
        content: |
          <html>
            <body>
              <h1>Hello from PrepForCareers!</h1>
              <p>This page was created using my first Ansible Playbook.</p>
            </body>
          </html>
        dest: /var/www/html/index.html

    - name: Make sure Nginx is running
      ansible.builtin.service:
        name: nginx
        state: started
        enabled: true

Now let’s understand what this Playbook does.

Task 1 — Install Nginx

- name: Install Nginx
  ansible.builtin.apt:
    name: nginx
    state: present
    update_cache: true

Ansible checks the target server and makes sure Nginx is installed.

The update_cache: true option tells the apt module to update the package cache before installing the package.

Task 2 — Create a Webpage

- name: Create a simple webpage
  ansible.builtin.copy:

The copy module creates the index.html file on the target server.

The HTML content is provided directly inside the Playbook.

So you don’t need to manually SSH into the server and create the webpage yourself.

Task 3 — Start Nginx

- name: Make sure Nginx is running
  ansible.builtin.service:
    name: nginx
    state: started
    enabled: true

This makes sure the Nginx service is running.

The enabled: true option also configures Nginx to start automatically when the server boots.

Run Your First Playbook

Once your inventory is ready and your Playbook is saved, run:

ansible-playbook -i inventory first-playbook.yml

Ansible will connect to the target server and execute the tasks in order. You should see output showing the Playbook, tasks, and their results.

If everything completes successfully, congratulations!

You have just created and run your first Ansible Playbook.

If your target server has a public IP address and allows HTTP traffic, open its IP address in your browser:

http://YOUR_SERVER_IP

You should see:

Hello from PrepForCareers!
This page was created using my first Ansible Playbook.

That’s the power of automation. You described what you wanted in a Playbook, and Ansible performed the work on the server for you.

One Last Thing Before You Go

You might be thinking:

“So should I completely stop using ad hoc commands now?”

No!

Ad hoc commands still have their place. If you need to perform a quick task that you don’t expect to repeat, an ad hoc command can be the fastest option.

But when your automation becomes:

  • Repetitive
  • Multi-step
  • Reusable
  • More complex
  • Something you want to keep in version control

a Playbook becomes a much better choice.

And this is only the beginning. In the next articles, we’ll go deeper into the world of Ansible and learn about things such as variables, conditionals, loops, handlers, templates, roles, Ansible Vault, and more.

If you are completely new to Ansible and want to understand its architecture and core components first, check out our Ansible Architecture Explained guide.

Until then…

Grab a coffee and enjoy learning!

Leave a Reply

Your email address will not be published. Required fields are marked *

prepforcareers.com

Our platform focuses on providing carefully prepared IT interview MCQs with clear answers and easy explanations. Each question is designed to help you strengthen your fundamentals and improve your confidence before facing real interviews.

Recent