Want to level up your Ansible knowledge? Explore our tutorials and step-by-step guides written by Ansible experts. Learn Ansible best practices and solutions to the most difficult problems.

Ansible Guides and Tutorials | Spacelift Blog

Author title

Spacelift + ServiceNow = Self-Service IaC Without the Learning Curve

Title category

Get all the latest content on Infrastructure as Code, DevOps, Spacelift features & news directly to your inbox!

Level up your IaC knowledge. Stay up to date with educational devops guides & news in infrastructure as code, cloud & more!

Managing Infrastructure at Scale | Spacelift Blog

Product

Why Spacelift

How it Works

Spacelift platform

Terraform

Ansible

OpenTofu

See all integrations

Integrations

vs Terraform Cloud

vs Terraform Enterprise

vs Atlantis

vs Generic CI/CD

Compare

Register now

introducing-saturnhead-ai-blog-image

Introducing Saturnhead AI Blog Image

Introducing Saturnhead AI

Solutions

Scale your infrastructure safely and efficiently with an end-to-end workflow

productivity

Productivity

productivity-2

IaC at Scale

Standardize and control infrastructure provisioning and configuration

cicd

CICD

cicd-2

Infrastructure Governance

Implement and automate secure, collaborative workflows

team

Team

team-2

Collaboration

Make it easy for developers to provision and configure with a single workflow

speed-2

Speed

speed-3

Developer Velocity

By Initiative

CI/CD for Infrastructure

Drift Detection

Achieve Terraform at Scale

OpenTofu Migration

By Use Case

Request a meeting

Enjoy an action-packed day at AWS Summit London 2024, where the latest in cloud innovation comes to life.

ebook-pic

Practitioner’s Guide to Scaling IaC

Check out the Practitioner's Guide to Scaling IaC

Docs

Pricing

Resources

Learn more about Spacelift and infrastructure best practices

blog

Blog

blog-2

partners

Partners

partners-2

events

Events

events-2

eBooks, webinars, cheat sheets and tools to get you started

cheatsheets

Cheatsheets

cheatsheets-3

Resource Library

users

Users

users-2

Case Studies

Essential content and resources to help you achieve IaC excellence

chat-3

media guide

chat-hover

media guide hover

Mission Guides

539-infra-automation-report-1

539.infra automation report

The Infrastructure Automation Report, 2025

About Us

Contact Us

Accessibility

About

cheatsheets-2

Test

See more

Test webinar name

How it works

Open Tofu

Kubernetes

388-terraform-yamlencode

terraform yamlencode

Using Terraform YAML Functions: Yamldecode & Yamlencode

applepodcasts

spotify

missionctrl

Welcome to missionCTRL, a show dedicated to exploring the frontiers of modern DevOps. Listen (or watch) as we sit down with the practitioners who are pushing the boundaries of development

Ioannis Moustakis

Flavius Dinu

This blog post deep dives into Ansible Variables, which allow us to parametrize different Ansible components. Variables store values for reuse inside an Ansible project. 
If you are still learning how to use Ansible, you might also find the introductory <a href="https://spacelift.io/blog/ansible-tutorial" target="_blank" rel="noopener">Ansible Tutorial</a> or <a href="https://spacelift.io/blog/ansible-playbooks" target="_blank" rel="noopener">Working with Ansible Playbooks</a> blog posts helpful. You can find this article&#8217;s code on this <a href="https://github.com/spacelift-io-blog-posts/Blog-Technical-Content/tree/master/ansible-variables" target="_blank" rel="nofollow noopener">repository</a> if you wish to follow along.
What we will cover:
<ol>
<li><a href="https://spacelift.io/blog/ansible-variables#what-are-ansible-variables">What are Ansible variables?</a></li>
<li><a href="https://spacelift.io/blog/ansible-variables#variable-naming-rules">Variable naming rules</a></li>
<li><a href="https://spacelift.io/blog/ansible-variables#types-of-variables-in-ansible">Types of variables in Ansible</a></li>
<li><a href="https://spacelift.io/blog/ansible-variables#simple-variables">Simple variables</a></li>
<li><a href="https://spacelift.io/blog/ansible-variables#list-dictionary--nested-variables">List, dictionary &amp; nested variables</a></li>
<li><a href="https://spacelift.io/blog/ansible-variables#special-variables">Special variables</a></li>
<li><a href="https://spacelift.io/blog/ansible-variables#registering-variables">Registering variables</a></li>
<li><a href="https://spacelift.io/blog/ansible-variables#environment-variables">Environment variables</a></li>
<li><a href="https://spacelift.io/blog/ansible-variables#how-to-share-and-reuse-ansible-variables">How to share and reuse Ansible variables?</a></li>
<li><a href="https://spacelift.io/blog/ansible-variables#variable-scope">Variable scope</a></li>
<li><a href="https://spacelift.io/blog/ansible-variables#where-to-set-ansible-variables">Where to set Ansible variables?</a></li>
<li><a href="https://spacelift.io/blog/ansible-variables#variables-precedence">Variables precedence</a></li>
<li><a href="https://spacelift.io/blog/ansible-variables#best-practices-for-managing-ansible-variables">Best practices for managing Ansible variables</a></li>
</ol>

<dfn>Ansible variables</dfn> are dynamic values used within Ansible playbooks and roles to enable customization, flexibility, and reusability of configurations. They are very similar to variables in programming languages, helping you manage complex tasks more efficiently by allowing the same playbook or role to be applied across different environments, systems, or contexts without the need for hardcoding specific information.
<h3>Why are variables useful in Ansible?</h3>
The use of variables simplifies the management of dynamic values throughout an Ansible project and can potentially reduce the number of human errors. We have a convenient way to handle variations and differences between different environments and systems with variables. 
Another advantage of variables in Ansible is that we have the flexibility to define them in multiple places with different precedence according to our use case. We can also register new variables in our playbooks by using the returned value of a task.

Ansible has a strict set of rules to create valid variable names. Variable names can contain only letters, numbers, and underscores and must start with a letter or underscore. Some strings are reserved for other purposes and aren’t valid variable names, such as <a href="https://docs.python.org/3/reference/lexical_analysis.html#keywords" target="_blank" rel="nofollow noopener">Python Keywords</a> or <a href="https://docs.ansible.com/ansible/latest/reference_appendices/playbooks_keywords.html#playbook-keywords" target="_blank" rel="nofollow noopener">Playbook Keywords</a>.
Apart from these, as for every programming language and configuration language, the variable names should be short and meaningful, because otherwise, you will have a hard time with debugging them, especially in a complex playbook.
Good variable names:
<ul>
<li style="font-weight: 400;" aria-level="1">web_server_port</li>
<li style="font-weight: 400;" aria-level="1">db_connection_timeout</li>
<li style="font-weight: 400;" aria-level="1">ssh_private_key</li>
<li style="font-weight: 400;" aria-level="1">max_attempts_retry</li>
</ul>
All of the above variable names make sense and are very easy to understand, even without seeing them used in the code.
Bad variable names:
<ul>
<li style="font-weight: 400;" aria-level="1">my_var – even though it is valid, you don’t understand what this is doing without seeing it in the code</li>
<li style="font-weight: 400;" aria-level="1">tm@p%$2 – this contains special characters, so it is invalid</li>
<li style="font-weight: 400;" aria-level="1">1var – this starts with a number, so it is invalid</li>
</ul>

Variables in Ansible can come from different sources and can be used in playbooks, roles, inventory files, and even within modules. 
Here are the variable types you may encounter while using Ansible:
<ul>
<li>Playbook variables – These variables are used to pass values into playbooks and roles and can be defined inline in playbooks or included in external files.</li>
<li>Task variables – These variables are specific to individual tasks within a playbook. These can override other variable types for the scope of the task in which they are defined.</li>
<li>Host variables – Specific to hosts, these variables are defined in the inventory or loaded from external files or scripts and can be used to set attributes that differ between hosts.</li>
<li>Group variables – Similar to host variables but used for a group of hosts and are defined in the inventory or separate files in the group_vars directory.</li>
<li>Inventory variables – These variables are defined in the inventory file itself and can be applied at different levels (host, group, all groups).</li>
<li>Fact variables – Gathered by Ansible from the target machines, facts are a rich set of variables (including IP addresses, operating system, disk space, etc.) that represent the current state of the system and are automatically discovered by Ansible.</li>
<li>Role variables – Defined within a role, these variables are usually part of the role&#8217;s default variables (defaults/main.yaml file) or variables intended to be set by the role user (vars/main.yaml file) and are used to enable reusable and configurable roles.</li>
<li>Extra variables – Passed to Ansible at runtime using the -e or &#8211;extra-vars command-line option. They have the highest precedence and can be used to override other variables or to pass data that might change between executions.</li>
<li>Magic variables – Special variables such as hostvars, group_names, groups, inventory_hostname, and ansible_playbook_python, provide information about the execution context and allow access to inventory data programmatically.</li>
<li>Environment variables –  Used within Ansible playbooks to access environment variables from the system running the playbook or from remote systems.</li>
</ul>

The simplest use case of variables is to define a variable name with a single value using standard <a href="https://spacelift.io/blog/yaml" target="_blank" rel="noopener">YAML syntax</a>. Although this pattern can be used in many places, we will show an example in a playbook for simplicity.

In the above example, after the vars block, we define the variable username, and assign the value bob. Later, to reference the value in the task, we use <a href="https://docs.ansible.com/ansible/latest/user_guide/playbooks_templating.html" target="_blank" rel="nofollow noopener">Jinja2 syntax</a> like this &#8220;{{ username }}&#8221; 
If a variable&#8217;s value starts with curly braces, <a href="https://docs.ansible.com/ansible/latest/user_guide/playbooks_variables.html#when-to-quote-variables-a-yaml-gotcha" target="_blank" rel="nofollow noopener">we must quote the whole expression</a> to allow YAML to interpret the syntax correctly.

There are many other options to define more complex variables like lists, dictionaries, and nested structures. To create a variable with multiple values, we can use YAML lists syntax:

To reference a specific value from the list we must select the correct field. For example, to access the third value v3:

Another useful option is to store key-value pairs in variables as dictionaries. For example:

Similarly, to reference the third field from the dictionary, use the bracket or dot notation:

Note that the bracket notation is preferred as you might encounter problems using the dot notation in special cases.
Sometimes, we have to create or use nested variable structures. For example, facts are nested data structures. We have to use a bracket or dot notation to reference nested variables.

Ansible special variables are a set of predefined variables that contain information about the system data, inventory, or execution context inside an Ansible playbook or role. These include magic variables, connection variables, and facts. The names of these variables are reserved. 
<h3>Magic variables</h3>
<a href="https://docs.ansible.com/ansible/latest/reference_appendices/special_variables.html#magic-variables" target="_blank" rel="nofollow noopener">Magic variables</a> are automatically created by Ansible and cannot be changed by a user. These variables will always reflect the internal state of Ansible, so they can be used only as they are.

In the above playbook, we are defining a playbook that uses the inventory_hostname magic variable. We are using this variable to get the name of the host on which Ansible runs and print a message with it as shown below.

Apart from inventory_hostname, some other essential magic variables are:
<ul>
<li style="font-weight: 400;" aria-level="1">hostvars → leveraged for getting information about other hosts in the inventory, including any variables that are associated with them. 
</li>
<li style="font-weight: 400;" aria-level="1">play_hosts → lists all the hosts that are targeted by the current play.</li>
<li style="font-weight: 400;" aria-level="1">group_names → contains a list of groups names to which the current host belongs in the inventory.</li>
<li style="font-weight: 400;" aria-level="1">groups → key/value pair of all the groups in the inventory with all the hosts that belong to each group.</li>
</ul>
<h3>Ansible facts</h3>
<a href="https://docs.ansible.com/ansible/latest/reference_appendices/special_variables.html#facts" target="_blank" rel="nofollow noopener">Ansible facts</a> are leveraged for getting system and hardware facts gathered about the current host during playbook execution. This data is often utilized for creating dynamic inventories, templating, or making decisions based on host-specific attributes. The gathered facts can be accessed using the ansible_facts variable, allowing you to reference specific information like the operating system, IP address, or CPU architecture.
To collect facts about a specific host, you can run the following command:

Also, you can add the <code>gather_facts: yes</code> option to your playbook to ensure facts are collected after executing tasks.
With Ansible facts, you have the option to filter for specific facts like os or even the IP address. This can be done with:

<h4>What is the difference between variables and facts in Ansible?</h4>
Variables are defined by the user, whereas facts are discovered directly from the target machines. While variables are used for playbook and role customization, facts provide insight into the current state of the target machines based on real-time system information. Variables can be modified and even overridden in various parts of playbooks and roles and even on the run-time, while facts are considered to be read-only system snapshots.
<h3>Connection variables</h3>
<a href="https://docs.ansible.com/ansible/latest/reference_appendices/special_variables.html#connection-variables" target="_blank" rel="nofollow noopener">Connection variables</a> are used to define how the machine that runs Ansible connects to remote hosts during the execution of tasks and playbooks. These variables provide flexibility in managing various connection types, authentication methods, and host-specific configurations.

In the above example, we are using the connection variable, to show the connection type on a run as shown below:

During our plays, we might find it handy to utilize the output of a task as a variable that we can use in the following tasks. We can use the keyword register to create our own custom variables from task output.

In the above example, we register the output of the command find /etc/hosts, and we showcase how we can use the variable in the next task by printing its value.

image3-12

Registering Variables

A powerful pattern is to combine registered variables with conditionals to create tasks that will only be executed when certain custom conditions are true.

Here, we registered in the variable hosts_contents the contents of /etc/hosts file, and we execute the second task only if the file contains the word localhost.

image2-14

Registered Variables localhost

Since registered variables are stored in memory, it’s not possible to use them in future plays, and they are only available for the current playbook run.

<ul>
<li><a href="https://spacelift.io/blog/using-terraform-and-ansible-together" target="_blank" rel="noopener">Using Terraform &amp; Ansible together</a></li>
<li><a href="https://spacelift.io/blog/ansible-use-cases" target="_blank" rel="noopener">7 Ansible use cases for management &amp; automation</a></li>
<li><a href="https://spacelift.io/blog/ansible-best-practices" target="_blank" rel="noopener"><span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;44 Ansible Best Practices to Follow [Tips &amp; Tricks]&quot;}" data-sheets-userformat="{&quot;2&quot;:513,&quot;3&quot;:{&quot;1&quot;:0},&quot;12&quot;:0}">44 Ansible best practices to follow</a></li>
</ul>

Environment variables are a powerful way to influence the behavior of playbooks and tasks by passing external values into the Ansible runtime environment. These can be system environment variables available where Ansible is executed or on the managed nodes.
You should be cautious when using environment variables for sensitive data, as their values might be <a href="https://spacelift.io/blog/ansible-debug" target="_blank" rel="noopener">logged or exposed in debugging output,</a> and relying on them will affect the overall portability and reusability of your playbook. Setting environment variables within tasks or plays will override those of the same name in the system environment for the duration of the task or play execution.

When we want to reuse and share variables, we can leverage YAML anchors and aliases. They provide us with great flexibility in handling shared variables and help us reduce the repetition of data. Learn more in our <a href="https://spacelift.io/blog/yaml" target="_blank" rel="noopener">Complete YAML Guide</a>.
Anchors are defined with &amp;, and then referenced with an alias denoted with *. Let’s go and check a hands-on example in a playbook.

Here, since some options are shared between users, instead of rewriting the same values, we share the common ones with the anchor &amp;user_info. For every subsequent user declaration, we use the alias *user_info to avoid repeating ourselves as much as possible.
The values for state and create_home are the same for all the users, while name and groups are replaced using the merge operator &lt;&lt;. 
Similarly, we reuse the user_groups declaration in the definition of the user_info anchor. This way, we don&#8217;t have to type the same groups again for user_2 while we still have the flexibility to override the groups, as we do for user_3. 
The result is that user_1 and user_2 are added to groups devs and support, while user_3 is added only to the support group.

image4-11

Share variables with YAML anchors and aliases

Ansible provides many options on setting variables, and the ultimate decision on where to set them lies with us based on the scope we would like them to have. Conceptually, there are three main options available for scoping variables. 
First, we have the global scope where the values are set for all hosts. This can be defined by the Ansible configuration, environment variables, and command line. 
We set values for a particular host or group of hosts using the host scope. For example, there is an option to define some variables per host in the inventory file.
Lastly, we have the play scope, where values are set for all hosts in the context of a play. An example would be the vars section we have seen in previous examples in each playbook.

Variables can be defined with Ansible in many different places. There are options to set variables in playbooks, roles, inventory, var files, and command line. Let’s go and explore some of these options. 
<h3>1. Vars block</h3>
As we have previously seen, the most straightforward way is to define variables in a play with the vars section.

<h3>2. Inventory files</h3>
Another option is to define variables in the inventory file. We can set variables per host or set shared variables for groups. This example defines a different ansible user to connect for each host as a host variable and the same HTTP port for all web servers as a group variable.

To better organize our variables, we could gather them in separate host and group variables files. In the same directory where we keep our <a href="https://spacelift.io/blog/ansible-variables" target="_blank" rel="noopener">Ansible inventory</a> or playbook files, we can create two folders named group_vars and host_vars that would contain our variable files. For example:

<h3>3. Custom var files</h3>
Variables can also be set in custom var files. Let’s check an example that uses variables from an external file and the group_vars and host_vars directories.

The vars/variables.yml file:

The group_vars/webservers file:

The host_vars/host1 file:

The host_vars/host2 file:

The inventory file contains a group named webservers that includes our two hosts, host1 and host2:

If we run this playbook, we notice the same value is used in both hosts for the group variable http_port but a different one for the host variable app_version.

image1-14

Variable setting options & precedence

A good use case for having separate variables files is that you can keep in them sensitive values without storing them in playbooks or source control systems.
Occasionally we might find it helpful to define or override variables at runtime by passing them at the command line with &#8211;extra-vars or &#8211;e argument. For example:

Since variables can be set in multiple places, Ansible applies variable precedence to select the variable value according to some hierarchy. The general rule is that variables defined with a more explicit scope have higher priority.
For example, role defaults are overridden by mostly every other option. Variables are also flattened to each host before each play, so all group and hosts variables are merged. Host variables have higher priority than group variables. 
Explicit variable definitions like the vars directory or an include_vars task override variables from the inventory. Finally, extra vars defined at runtime always win precedence. For a complete list of options and their hierarchy, look at the official documentation <a href="https://docs.ansible.com/ansible/latest/user_guide/playbooks_variables.html#understanding-variable-precedence" target="_blank" rel="nofollow noopener">Understanding variable precedence</a>.

Since Ansible provides a plethora of options to define variables, it might be a bit confusing to figure out the best way and place to set them. Let’s go and check some common &amp; best practices around setting variables that might help us better organize our Ansible projects.
<ul>
<li style="font-weight: 400;" aria-level="1">Always give descriptive and clear names to your variables. Taking a moment to properly think about how to name variables always pays off long-term.</li>
<li style="font-weight: 400;" aria-level="1">If there are default values for common variables, set them in group_vars/all</li>
<li style="font-weight: 400;" aria-level="1">Prefer setting group and host vars in group_vars and host_vars directories instead of in the inventory file.</li>
<li style="font-weight: 400;" aria-level="1">If variables related to geography or behavior are tied to a specific group, prefer to set them as group variables.</li>
<li style="font-weight: 400;" aria-level="1">If you are using roles, always set default role variables in roles/your_role/defaults/main.yml</li>
<li style="font-weight: 400;" aria-level="1">When you call roles, pass variables that you wish to override as parameters to make your plays easier to read.</li>
</ul>

<ul>
<li style="font-weight: 400;" aria-level="1">You can always use &#8211;extra-vars or &#8211;e to override every other option.</li>
<li style="font-weight: 400;" aria-level="1">Don’t store sensitive variables in your source code repository in plain text. You can leverage <a href="https://spacelift.io/blog/ansible-vault#encrypting-sensitive-info-with-ansible-vault" target="_blank" rel="noopener">Ansible Vault</a> in these cases.</li>
</ul>
In general, try to keep variable usage as simple as possible. You don’t have to use all the existing options and spread variables definition all over the place because that makes debugging your Ansible projects difficult. Try to find a structure that suits your needs best and stick to it! 
To learn more, check out the <a href="https://spacelift.io/blog/ansible-best-practices" target="_blank" rel="noopener">44 Ansible Best Practices to Follow</a>.

<a href="https://spacelift.io/" target="_blank" rel="noopener">Spacelift</a>’s vibrant ecosystem and excellent GitOps flow can greatly assist you in managing and orchestrating Ansible. By introducing Spacelift on top of Ansible, you can easily create custom workflows based on pull requests and apply any necessary compliance checks for your organization.
With Spacelift, you get:
<ul>
<li aria-level="1">Better playbook automation – Manage the execution of Ansible playbooks from one central location.</li>
<li aria-level="1">Inventory observability – View all Ansible-managed hosts and related playbooks, with clear visual indicators showing the success or failure of recent runs.</li>
<li aria-level="1">Playbook run insights – Audit Ansible playbook run results with detailed insights to pinpoint problems and simplify troubleshooting.</li>
<li aria-level="1"><a href="https://docs.spacelift.io/concepts/policy" target="_blank" rel="noopener">Policies</a> – Control what kind of resources engineers can create, what parameters they can have, how many approvals you need for a run, what kind of task you execute, what happens when a pull request is open, and where to send your notifications</li>
<li aria-level="1"><a href="https://docs.spacelift.io/concepts/stack/stack-dependencies.html" target="_blank" rel="noopener">Stack dependencies</a> – Build multi-infrastructure automation workflows with dependencies, having the ability to build a workflow that, for example, generates your EC2 instances using Terraform and combines it with Ansible to configure them</li>
<li aria-level="1">Self-service infrastructure via <a href="https://docs.spacelift.io/concepts/blueprint.html" target="_blank" rel="noopener">Blueprints</a>, or Spacelift’s <a href="https://docs.spacelift.io/integrations/kubernetes/operator.html" target="_blank" rel="noopener">Kubernetes operator</a> – Enable your developers to do what matters – developing application code while not sacrificing control</li>
<li aria-level="1">Creature comforts such as <a href="https://docs.spacelift.io/concepts/configuration/context.html" target="_blank" rel="noopener">contexts</a> (reusable containers for your environment variables, files, and hooks), and the ability to run arbitrary code</li>
<li aria-level="1"><a href="https://docs.spacelift.io/concepts/stack/drift-detection.html" target="_blank" rel="noopener">Drift detection</a> and optional remediation</li>
</ul>
If you want to learn more about using Spacelift with Ansible, check our <a href="https://docs.spacelift.io/vendors/ansible/" target="_blank" rel="noopener">documentation</a>, read our <a href="https://spacelift.io/blog/introducing-spacelifts-latest-ansible-functionality" target="_blank" rel="noopener">Ansible guide</a>, or <a href="https://spacelift.io/schedule-demo" target="_blank" rel="noopener">book a demo with one of our engineers</a>.
Would you like to see this in action – or just want a tl;dr? Check out this video I put together showing you Spacelift’s new Ansible functionality:

yt-video-player-ansible-v2

In this article, we deep-dived into Ansible Variables and saw how we can define and use them in playbooks. Moreover, we explored different options for sharing, setting, and referencing them, along with some guidelines and best practices to make our Ansible journey easier.
Thank you for reading, and I hope you enjoyed this “Ansible Variables” article as much as I did.

Managing large-scale playbook execution is hard. Spacelift enables you to automate Ansible playbook execution with visibility and control over resources, and seamlessly link provisioning and configuration workflows.

Terraform vs. Ansible : Key Differences and Comparison of Tools

Ansible Playbooks: Complete Guide with Examples

Ansible Modules - How To Use Them Efficiently (Examples)

How to work with Ansible variables in playbooks, inventories & command line, and where to set them. Special and environment types explained.

62-ansible-variables

Ansible variables

Ansible Variables: How to Use Different Types of Ansible Variables (Examples) 

Manage and orchestrate Ansible with Spacelift’s vibrant ecosystem and excellent GitOps flow. Create powerful custom workflows combining multiple IaC tools.

Ioannis is a Cloud Architect with a background in DevOps &amp; Site Reliability Engineering interested in Cloud Infrastructure, Automation, CI/CD Pipelines &amp; Containerization. In his free time, he curates a personal blog at <a href="https://devopsmadness.com" rel="noopener nofollow">devopsmadness.com</a> and <a href="https://moustakisioannis.medium.com" rel="noopener nofollow">moustakisioannis.medium.com</a>. Opinions expressed are solely his own.

In this article, we are exploring Ansible Playbooks, which are basically blueprints for automation actions. Playbooks allow us to define a recipe with all the steps we would like to automate in a repeatable, simple, and consistent manner. 
We will cover:
<ol>
<li><a href="https://spacelift.io/blog/ansible-playbooks#what-is-an-ansible-playbook">What is an Ansible playbook?</a></li>
<li><a href="https://spacelift.io/blog/ansible-playbooks#what-is-the-structure-of-an-ansible-playbook">What is the structure of an Ansible playbook?</a></li>
<li><a href="https://spacelift.io/blog/ansible-playbooks#how-to-write-an-ansible-playbook">How to write an Ansible playbook?</a></li>
<li><a href="https://spacelift.io/blog/ansible-playbooks#how-to-run-ansible-playbooks">How to run Ansible playbooks?</a></li>
<li><a href="https://spacelift.io/blog/ansible-playbooks#ansible-playbook-example">Ansible playbook example</a></li>
<li><a href="https://spacelift.io/blog/ansible-playbooks#using-variables-in-playbooks">Using variables in playbooks</a></li>
<li><a href="https://spacelift.io/blog/ansible-playbooks#handling-sensitive-data-in-playbooks">Handling sensitive data in playbooks</a></li>
<li><a href="https://spacelift.io/blog/ansible-playbooks#triggering-tasks-on-change-with-handlers">Triggering tasks on change with handlers</a></li>
<li><a href="https://spacelift.io/blog/ansible-playbooks#using-conditional-tasks-in-playbooks">Using conditional tasks in playbooks</a></li>
<li><a href="https://spacelift.io/blog/ansible-playbooks#how-to-use-loops-in-ansible-playbooks">How to use loops in Ansible playbooks</a></li>
<li><a href="https://spacelift.io/blog/ansible-playbooks#how-to-run-multiple-playbooks-in-ansible">How to run multiple playbooks in Ansible</a></li>
<li><a href="https://spacelift.io/blog/ansible-playbooks#ansible-playbooks-tips-and-tricks">Ansible playbooks tips and tricks</a></li>
</ol>
If you are entirely new to Ansible, check out this introductory <a href="https://spacelift.io/blog/ansible-tutorial" target="_blank" rel="noopener">Ansible Tutorial</a> first.

<dfn>Ansible playbooks</dfn> are one of the basic components of Ansible as they record and execute Ansible&#8217;s configuration. Generally, a playbook is the primary way to automate a set of tasks that we would like to perform on a remote machine. 
They help our automation efforts by gathering all the resources necessary to orchestrate ordered processes or avoid repeating manual actions. Playbooks can be reused and shared between persons, and they are designed to be human-friendly and easy to write in YAML.
<h3>What is the difference between a playbook and a role in Ansible?</h3>
Ansible playbooks are broader in scope and capable of orchestrating multiple plays and roles across different hosts and groups, while roles are more focused components, targeting specific tasks and configurations. 
When it comes to how to use them, playbooks execute the automation, while roles are used to structure and package the automation in a reusable form.

A playbook is composed of one or more plays to run in a specific order. A play is an ordered list of tasks to run against the desired group of hosts. 
Every task is associated with a module responsible for an action and its configuration parameters. Since most tasks are idempotent, we can safely rerun a playbook without any issues.
As discussed, Ansible playbooks are written in <a href="https://docs.ansible.com/ansible/latest/reference_appendices/YAMLSyntax.html#yaml-syntax" target="_blank" rel="nofollow noopener">YAML</a> using the standard extension .yml with minimal syntax. 
We must use spaces to align data elements that share the same hierarchy for indentation. Items that are children of other items must be indented more than their parents. There is no strict rule for the number of spaces used for indentation, but it&#8217;s pretty common to use two spaces while Tab characters are not allowed. 
Below is an example simple playbook with only two plays, each one having two tasks:

We define a descriptive name for each play according to its purpose on the top level. Then we represent the group of hosts on which the play will be executed, taken from the inventory. Finally, we define that these plays should be executed as the root user with the <a href="https://spacelift.io/blog/ansible-become" target="_blank" rel="noopener">become</a><a href="https://spacelift.io/blog/ansible-become" target="_blank" rel="noopener"> option</a> set to yes.
You can also define many other <a href="https://docs.ansible.com/ansible/latest/reference_appendices/playbooks_keywords.html" target="_blank" rel="nofollow noopener">Playbook Keywords</a> at different levels such as play, tasks, playbook to configure Ansible&#8217;s behavior. Even more, most of these can be set at runtime as command-line flags in the ansible configuration file, ansible.cfg, or the <a href="https://spacelift.io/blog/ansible-inventory" target="_blank" rel="noopener">inventory</a>. Check out the <a href="https://docs.ansible.com/ansible/latest/reference_appendices/general_precedence.html#general-precedence-rules" target="_blank" rel="nofollow noopener">precedence rules</a> to understand how Ansible behaves in these cases.
Next, we use the tasks parameter to define the list of tasks for each play. For each task, we define a clear and descriptive name. Every task leverages a module to perform a specific operation. 
For example, the first task of the first play uses the <a href="https://spacelift.io/blog/ansible-copy" target="_blank" rel="noopener">ansible.builtin.copy </a><a href="https://spacelift.io/blog/ansible-copy" target="_blank" rel="noopener">module</a>. Along with the module, we usually have to define some module arguments. For the second task of the first play, we use the module ansible.builtin.user that helps us manage user accounts. In this specific case, we configure the name of the user, the state of the user account, and its uid accordingly.

Writing an Ansible playbook involves creating a YAML file that specifies the hosts to configure and the tasks to perform on these hosts.
Usually, as a best practice, to specify your hosts, you need to define an <a href="https://spacelift.io/blog/ansible-inventory" target="_blank" rel="noopener">Ansible inventory file</a>. To make things simple, we will use localhost:

Next, let’s define a play file that will ping localhost:

To run this, we can use:

Things to take into consideration when you are writing an Ansible playbook:
<ul>
<li style="font-weight: 400;" aria-level="1">YAML is sensitive to indentation, typically requiring 2 spaces for each level of indentation</li>
<li style="font-weight: 400;" aria-level="1">Take advantage of variables in your playbooks to make them more dynamic and flexible. Variables can be defined in many places, including in the playbook itself, in inventory, in separate files, or even passed at the command line</li>
<li style="font-weight: 400;" aria-level="1">Use handlers – these are special tasks that only run when notified by another task. They are typically used to restart services when configurations change.</li>
<li style="font-weight: 400;" aria-level="1">Take advantage of templates – Ansible can use Jinja2 templates to dynamically generate files based on variables</li>
<li style="font-weight: 400;" aria-level="1">Use roles – For complex setups, consider organizing your tasks into roles. This helps keep your playbooks clean and makes your tasks more reusable</li>
</ul>

When we are running a playbook, Ansible executes each task in order, one at a time, for all the hosts that we selected. This default behavior could be adjusted according to different use cases using <a href="https://docs.ansible.com/ansible/latest/user_guide/playbooks_strategies.html#playbooks-strategies" target="_blank" rel="nofollow noopener">strategies</a>. 
If a task fails, Ansible stops the execution of the playbook to this specific host but continues to others that succeeded. During execution, Ansible displays some information about connection status, task names, execution status, and if any changes have been performed. 
At the end, Ansible provides a summary of the playbook&#8217;s execution along with failures and successes. Let&#8217;s see these in action by running the example playbook we saw earlier with the ansible-playbook command.

image1-13

Running a playbook

From the output, we notice the Play names, the Gathering Facts task, the Play tasks, and the Play Recap in the end. Since we didn&#8217;t define a databases hosts group, the second play of the playbook was skipped. 
We can use the &#8211;limit flag to limit the Playbook&#8217;s execution to specific hosts. For example:

Let’s write a more real example playbook. We will suppose that we have three EC2 servers in AWS that we want to configure as webservers. These web servers will be behind a public load balancer, so whenever we access the load balancer, we want to see an HTML page that responds with the different hostnames.
To do this, we will need to create an inventory and a playbook. The inventory will be similar to:

Under the [webservers] hosts, we’ve added the 3 ec2 instances, and to make things easier, we have defined one variable in the inventory file:
<ul>
<li style="font-weight: 400;" aria-level="1">ansible_ssh_private_key_file –  path to the private SSH key used to connect to the target machines</li>
</ul>
Now, let’s define a playbook that will install Nginx and create an index file that will be served from these web servers.

In the first part of the playbook, we will add a name to it, tell it on which hosts to run, and whether or not to become root. 
Next, we have defined a couple of pre_tasks to set the ssh user depending on the operating system:

Next, we will have two installations for Nginx, one when the os_family is Debian and the other one when the os family is Redhat.

After that, we need to create the index.html file:

In the end, we need to ensure that nginx is enabled and running:

This is how the playbook will look like in the end:

Read more: <a href="https://spacelift.io/blog/ansible-aws" target="_blank" rel="noopener">Using Ansible to Automate AWS [Tutorial]</a>

Variables are placeholders for values that you can reuse throughout a Playbook or other Ansible objects. They can only contain letters, numbers, and underscores and start with letters. 
Variables can be defined in Ansible in multiple levels, so look at <a href="https://docs.ansible.com/ansible/latest/user_guide/playbooks_variables.html#variable-precedence-where-should-i-put-a-variable" target="_blank" rel="nofollow noopener">variable precedence</a> to understand how they are applied. For example, we can set variables at the global scope for all hosts, at the host scope for a particular host, or at the play scope for a specific play. 
To set host and group variables, create the directories group_vars and host_vars. For example, to define group variables for the databases group, create the file group_vars/databases. Set common default variables in a group_vars/all file.
Even more, to define host variables for a specific host, create a file with the same name as the host under the hosts_vars directory.
To substitute any variables during runtime, use the -e flag. 
The most straightforward method to define variables is to use a vars block at the beginning of a play. They are defined using standard YAML syntax.

Another way is to define variables in external YAML files.

To use them in tasks, we have to reference them by placing their name inside double braces using the <a href="https://docs.ansible.com/ansible/latest/user_guide/playbooks_templating.html" target="_blank" rel="nofollow noopener">Jinja2 syntax</a>:

If a variable&#8217;s value starts with curly braces, <a href="https://docs.ansible.com/ansible/latest/user_guide/playbooks_variables.html#when-to-quote-variables-a-yaml-gotcha" target="_blank" rel="nofollow noopener">we must quote the whole expression</a> to allow YAML to interpret the syntax correctly. 
We can also define variables with multiple values as lists.

It&#8217;s also possible to reference individual values from a list. For example, to select the first value foo1:

Another possible option is to define variables using YAML dictionaries. For example:

Similarly, to get the first field from the dictionary:

To reference nested variables, we have to use a bracket or dot notation. For example, to get the example_name_2 value from this structure:

We can create variables using the register statement that captures the output of a command or task and then use them in other tasks.

<ul>
<li><a href="https://spacelift.io/blog/infrastructure-problems-that-spacelift-solves" target="_blank" rel="noopener"><span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;Common Infrastructure Challenges and How to Solve Them&quot;}" data-sheets-userformat="{&quot;2&quot;:513,&quot;3&quot;:{&quot;1&quot;:0},&quot;12&quot;:0}">Common infrastructure challenges and how to solve them</a></li>
<li><a href="https://spacelift.io/blog/ansible-best-practices" target="_blank" rel="noopener"><span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;44 Ansible Best Practices to Follow [Tips &amp; Tricks]&quot;}" data-sheets-userformat="{&quot;2&quot;:513,&quot;3&quot;:{&quot;1&quot;:0},&quot;12&quot;:0}">44 Ansible best practices to follow</a></li>
<li><a href="https://spacelift.io/blog/spacelift-ansible-integration-beta" target="_blank" rel="noopener">How to better manage Ansible and overcome challenges</a></li>
</ul>

What are Ansible playbooks? Learn how to structure, write, and run a playbook. See the practical examples.

How to Use Different Types of Ansible Variables (Examples)

Get the newsletter

Recent posts

Ansible Playbooks: Complete Guide with Examples

Ansible Tutorial for Beginners: Ultimate Playbook & Examples

Terraform vs. Ansible : Key Differences and Comparison of Tools