In our Getting Started with Ansible guide, we explained the basics of working with Ansible: how to set up an Ansible inventory, connect remotely to your other servers, and execute commands on them.

For example, you can run this command to check disk usage on specific servers.

While this works perfectly for individual commands, it is not really suitable for more complex tasks. Let's say you need to update the list of available packages, install Nginx, start it, and enable it to launch automatically.

Running these commands manually on multiple servers - over and over again - is inconvenient and simply time-consuming, especially if you have a large number of servers. Ansible Playbooks were created exactly for such cases.

A playbook is a script that outlines exactly what Ansible should do - such as installing packages, creating users, copying files, or restarting a service. It essentially functions as a straightforward list of tasks. As a result, a playbook is quick to read and easy to edit.

Here are some examples of tasks that you can run on multiple servers simultaneously with playbooks:

A playbook is a file written in the YAML format. YAML is a text-based format used for creating configuration files

A playbook usually consists of three main elements:

More information about Ansible concepts you can find here.

Ansible executes tasks in the order in which they are listed in a playbook. You can run the same playbook multiple times. Ansible automatically checks whether the requested changes have already been applied and does not re-run tasks that have previously been completed.

Before you continue and start creating your first playbook, make sure you have completed our previous guide:

Getting Started with Ansible

You should already have:

We will continue using the same example from the previous guide:

The inventory file inventory.ini in our example looks like this:

Replace the IP addresses and username (adminuser in our example) with your actual VPS details.

First, connect via SSH to your control node (server with Ansible).

Navigate to ansible-lab directory (created in the previous guide):

Check the files in the directory:

You should see the inventory file:

Also, check if Ansible can connect to your managed servers:

Both servers should return:

If everything is correct, you can now create your first playbook.

We will create playbook that performs these tasks:

Create a new playbook file:

Paste this content:

Save changes and exit.

Important: YAML is indentation-sensitive, so make sure all indentation in your playbook matches our example exactly.

Make sure to always use spaces instead of tab characters.

name acts as a kind of heading for a set of actions. It helps in understanding exactly what Ansible is doing.

You can choose any name that you want.

hosts specifies the servers on which tasks should be executed. In our example, this is the linux group, which includes both Ubuntu and Alma servers.

So this means that the tasks specified below will be executed on the servers in this group.

You can also specify other groups, such as ubuntu:

In this case, tasks specified in the playbook will be executed only on Ubuntu servers.

If you want to execute tasks only on Alma servers:

You can also specify all servers that you have in the inventory:

Sometimes you need root privileges to run specific operations.

The become: true allows you to run operations with sudo.

become in playbook equivalent to -b option in the commands from our previous guide.

tasks section contains the actions that Ansible should execute on managed hosts.

Every task has a name that describes it.

In our example, we have three tasks.

First task: Update APT cache and install Nginx (Ubuntu/Debian)

This task updates APT packages and intalls Nginx on Ubuntu and Debian servers.

The ansible.builtin.package allows you to select the appropriate package manager based on the operating system. In our case we use ansible.builtin.apt, which is the module used to manage software on Debian and Ubuntu. You can use it to update packages, install or uninstall programs, or check their status.

name: nginx - Specifies the package name to work with. In our case, it is Nginx. In simple words, this means that we will work with Nginx.

state: present - checks Nginx state on the managed servers. If Nginx is already installed, the playbook will not attempt to install it again.

update_cache: true - updates the list of available apt packages.

cache_valid_time: 3600 - updates the list of available apt packages if it is older than 3600 seconds (1 hour).

when - condition, when the task should be executed. In this case, the condition is ansible_facts['os_family'] == "Debian". This means, task will be executed only on Debian-based systems (including Ubuntu).

Second task: Update DNF cache and install Nginx (AlmaLinux/Rocky)

This task will install Nginx on AlmaLinux and Rocky Linux. The principle is similar to the previous task.

ansible.builtin.dnf specifies, that we will use DNF package manager.

All other parameters are the same. The difference is that we do not have cache_valid_time: 3600. We don’t need to check whether the package list is outdated, as DNF will check this itself.

Condition in when: is ansible_facts['os_family'] == "RedHat" because this task will be executed only on RedHat-based systems (AlmaLnux and Rocky Linux in our case).

Third task: Start and enable Nginx

This task will start Nginx and configure it to launch automatically after every reboot (enable).

ansible.builtin.service: module specifies that we will work with services.

name: is again nginx.

state: started checks, if Nginx service already started.

enabled: true configure Nginx to start automatically after server reboot.

If Nginx is already running and enabled to started automatically ar every boot, the task will leave it unchanged.

This task will run on both Debian and Redhat based systems, so we do not have condition when.

It is always good idea to check syntax before you run the playbook.

Run the following command:

If syntax is correct, you will see:

You can also run this command to check which servers will be affected by playbook:

You should see:

This will not change on your servers yet.

Now we can run our playbook.

Enter this command (-K is not needed if your user do not have password):

Ansible will execute the tasks on all managed servers.

You should see output similar to:

From the control node run this command:

You should see:

Both managed servers should provide the same output: active

Check if Nginx enabled to start automatically on every boot:

Both servers should return:

As mentioned previously, Ansible will not make any changes if the required settings are already applied. This principle is called idempotency.

Run the same playbook again:

This time, if nothing has changed on your managed servers, the output should look like this:

This time changed value will be:

This means that Ansible checked the server configuration and detected no need to reinstall, restart or enable Nginx again.

Now we will make a small change to see how Ansible detects differences in configuration.

For this example, we will modify the enable option.

Open the playbook:

Find this task:

Replace with this content:

Save the file.

Execute the playbook again:

Now Ansible will catch the mismatch between the Nginx startup config on the machine and the one in the playbook.

You should see:

So Ansible updated the service config on both servers. The enabled: false setting stops Nginx from starting automatically after a reboot.

However, we still have:

So the Nginx remains running.

To restore the original configuration, open your playbook again:

Change the content back to:

Save the file and then execute the playbook one more time:

Ansible again will detect the difference and enable automatic Nginx startup after every reboot.

Verify the result:

You should see:

This is one of the main advantages of Ansible playbooks. You edit a single file, run it again, and every server gets updated.

If you need to run playbook tasks only on specific servers, you can use the --limit option. This option will restrict tasks execution only to specific hosts that you select.

For example, you can run playbook only on Ubuntu servers:

Or only on AlmaLinux servers:

You can also specify an individual server:

In this case, Ansible will execute the playbook only on the ubuntu1 server.

ubuntu1 corresponds to the name you specified for a particular managed server in your inventory file.

This is useful when you want to test configuration changes on one server before applying them to the rest of your infrastructure.

If you are getting this error message:

This means Ansible could not read the playbook due to mistake in YAML format:

incorrect indentation, missing colons or other YAML formatting problems. Check your playbook file and make sure that everything is correct.

If you see:

It means Ansible cannot connect to the managed server.

In this case, make sure to test the SSH connection manually:

If the connection fails when you run this command, check SSH username, server IP address, SSH port, firewall settings, and authentication method.

You can also test connectivity by running this command:

If you receive an error related to sudo password, make sure you have sudo permissions.

Try running the playbook with his command

Ansible will prompt you for the sudo password.

If it still doesn’t work, log in to the managed server and test it there:

If everything is correct, the command should return:

Otherwise, your user doesn’t have sudo privileges.

Next error:

Usually means that particular server or group not found in the inventory file

For example, if your playbook contains:

Make sure that the linux group is also exists in inventory.ini file.

You can list all hosts from inventory file by running this command:

Make sure you are running the command inside the directory where the inventory file is located.

If Ansible can connect to the managed server but fails to install services, you should check if the package exists on your managed server system.

Run these commands:

Ubuntu:

AlmaLinux:

When working with Ansible playbooks, you often will need these commands:

In this guide, we learned how to properly create Ansible playbooks, verify their syntax, execute tasks on multiple managed servers, troubleshoot issues and make modifications to existing playbooks. In this example, we installed Nginx; however in the same way you can automate Apache, MariaDB, Docker, PHP, firewall and many other services installation and configuration.

For more information, you can refer to the official Ansible Playbooks documentation.