In this lesson, you will explore the concept of variables in Ansible playbooks. Variables in Ansible are essential for creating flexible and reusable playbooks. They allow you to manage and use data that can change over time or across environments, such as user names, server addresses, or configuration settings. By the end of this lesson, you'll understand how to define, use, and manage variables within your playbooks.

Understanding Variables in Ansible

Variables in Ansible are similar to variables in programming languages; they are placeholders or references to data. The data can vary based on the context, environment, or conditions under which a playbook runs. Using variables makes your playbooks less static and more dynamic, enabling them to be used in various situations without changing the playbook code.

Variables can be defined in several places:

Defining Variables in a Playbook

To define a variable in a playbook, you can include a vars section. Let's look at an example:

---
- hosts: all
  vars:
    file_path: /tmp/sample_file_{{ ansible_hostname }}.txt
  tasks:
    - name: Create an empty file
      file:
        path: "{{ file_path }}"
        state: touch

In this example:

Execute the Playbook

Now let's run the playbook using the ansible-playbook command:

ansible-playbook first_playbook.yml

Here is the output:

Now that this is complete, let's run another Ad-hoc command to check and see if our files were created. This time, instead of running the shell module, let's use the find module. As always, let's review the documentation before attempting to use the module:

ansible-doc find

We can use the path and patterns parameters to find out file. After reviewing these in the help, close that with q then execute the command below:

ansible all -m find -a "path=/tmp patterns=sample_file*"

This will return a much longer and more detailed output since this module is designed to do that. Right away in the path field, I can see our files have been created on each node as I scroll up through the output:

Variable Precedence

It's important to know that Ansible has a well-defined hierarchy (precedence) for variables. For instance, a variable defined in a playbook can be overridden by the same variable defined in the inventory or passed at runtime. Understanding this hierarchy helps in managing complex playbooks and avoiding unexpected behaviors.

Defining Variables in Inventory Files

Let's move the variable file_path from our playbook to the inventory file and apply it to the webservers group. This change means that any playbook targeting the webservers group will have access to this variable.

nano ~/code/inventory

Modify the webservers group by adding the vars section:

webservers:
  hosts:
    managed-node-1:
      ansible_host: 192.168.1.200
    managed-node-2:
      ansible_host: 192.168.1.201
  vars:
    file_path: /tmp/inventory_file_{{ ansible_hostname }}.txt

Here, we've changed the value of file_path to point to a different file, demonstrating how you can adjust variables to suit different scenarios.

If we execute the playbook, it will appear as though everything ran correctly:

ansible-playbook first_playbook.yml

But if we ls the /tmp directory, we will see the variable in our playbook was used, not the variable in our inventory. This is because the variables in our Playbook take precedence over the variables in our Inventory.

In this use case, it makes more sense to leave the variables at the playbook level since we applying variables to only the webservers group, but our playbook affects all hosts. To make this work, let's change the hosts to webservers, and remove the vars from our playbook.

nano ~/code/first_playbook.yml

Change the playbook to the following:

---
- hosts: webservers
  tasks:
    - name: Create an empty file
      file:
        path: "{{ file_path }}"
        state: touch

Server Academy Members Only

Sorry, this lesson is only available to Server Academy Full Access members. Become a Full-Access Member now and you’ll get instant access to all of our courses.

Sign In Get Instant Access