Ansible Variables

Ansible Variables | Ansible Automation

 

Ansible inventory variable

 

Ansible Variables

In the world of automation, Ansible has emerged as a popular choice for managing and configuring systems. One of the key features that sets Ansible apart is its ability to work with variables. Variables in Ansible enable users to define and store values that can be used throughout the playbook, making it a powerful tool for automation.

Variables in Ansible can be defined in a variety of ways. They can be set globally, at the playbook level, or even at the task level. This flexibility allows users to customize their automation process based on their needs.

One everyday use case for variables is storing configuration values specific to different environments. For example, you have a playbook that deploys a web application. Using variables, you can define the database connection string, the server IP address, and other environment-specific values separately for development, staging, and production environments. This makes reusing the same playbook easy across different environments without modifying the code.

Another powerful feature of variables in Ansible is their ability to be dynamically generated. This means that you can use calculated or fetched variables instead of hardcoding values at runtime. For example, the “lookup” plugin can read values from external sources like files or databases and assign them to variables. This makes your automation process more dynamic and adaptable.

 

Highlights: Ansible Variables

  • The Process of Decoupling

For your automation journey, you want to be as flexible as possible. For this reason, within the Ansible architecture, we have a process known as decoupling. Here, we are separating site-specific code from static code. Anything specific to a server or managed device, such as an IP address, can be replaced with ansible variables. As a best practice, always aim to have playbooks to be flexible, and if you want to share with someone else, all you need to change is the variables.

  • Variable Locations

As you know, variables are defined in several places. Each place you define the variables, such as the inventory with the ansible inventory variable or play header, will have an order of precedence. The most common place is for the Ansible set variables task. When you have Ansible set variables in the task, Ansible also allows setting variables directly in a task using the set_fact module. We will look at Ansible set variables in a task in a moment.

So, for an Ansible architecture with more extensive playbooks, remember the best place to hold your variables and not keep your playbooks site-specific. With Ansible, you can execute tasks and playbooks on multiple systems with a single command.

  • Ansible Tower

With Ansible Tower, you can have very complex automation requirements with the push of a button. Every site will have variations, and Ansible uses variables to manage system differences. To represent the variations among those systems, you can create variables with standard YAML syntax, including lists and dictionaries. 

 

Before you proceed, you may find the following posts helpful:

  1. Ansible Architecture
  2. Security Automation
  3. Network Configuration Automation
  4. Software Defined Perimeter Solutions
  5. Security Automation

 



Ansible Variables Preference

Key Ansible Variables Discussion points:


  • Ansible architecture and decoupling.

  • Defining Ansible variables.

  • Example: Ansible set variables in task.

  • Facts and variables.

  • Inventorty variables.

  • Conditionals and loops.

 

  • A key point: Video on Ansible inventory and its use of Ansible inventory variable.

This video will discuss Ansible automation and the Ansible inventory used to list the target hosts. In addition, the inventory can have a particular Ansible inventory variable known as behavioral variables that can tune how you connect to the managed assets.

 

The Ansible Inventory | Ansible Automation
Prev 1 of 1 Next
Prev 1 of 1 Next

Back to basics with Ansible Variables

Ansible is open-source automation and orchestration software that can automate most of your operations with IT infrastructure components, including servers, storage, networks, and application platforms. Ansible is one of the most popular automation tools in the IT world and has strong community support with more than 5,000 contributors worldwide. With Ansible, we have the use of variables. 

Ansible uses variables to manage differences between systems. With Ansible, you can execute tasks and playbooks on multiple systems with a single command. To represent the variations among those systems, you can create variables with standard YAML syntax, including lists and dictionaries.

 

Defining Ansible Variables
Diagram: Ansible variables.

 

Defining Ansible Variables | Ansible Set Variables in Task

  • A key point: Ansible set variables in task

Ansible is not a full-fledged programming language. However, it does have several programming language components. One of the most significant of these is variable substitution. The most straightforward way to define variables is to put a vars section in your playbook with the names and values of variables.

Here, we can have Ansible set variables in task. The following will list the various ways you can set variables in Ansible. Keep in mind when doing so, we have an order of preference.

There are several places where you can define your variables. You can define these variables in your playbooks, inventory, reusable files or roles, or at the command line. During a playbook run, you can create variables by registering a task’s return value or value as a new variable.

When defining variables in multiple places, those variables have variable precedence. After creating variables, you can use those variables in module arguments, such as conditional “when” clauses, templates, and loops. All of these are potent constructs to have in your automation toolbox.

 

   Ansible Variables 

Definition

Vars: Section

Set_fact module


Vars_files

Vars_promt

Task Variables

At runtime  

 

Highlighting Ansible set variables in task

  • Define variables: Vars: Section.

If you are starting your automation journey, the simplest way to define variables is to put a vars section in your playbook with the names and values of variables. This allows you to define several configuration-related variables. So, to define variables in plays, include a vars: section in the header of the play where the variables are needed.

Variables defined in plays are only valid within that specific play and don’t have playbook scope. So if you need a variable in a different play, you must define it again. It may be inconvenient to you and difficult to manage across extensive playbooks with multiple teams working on playbook development.

 

  • Define variables: Set_fact Module.

We also have the set_fact module. The set_fact is a module used anywhere in a play to set variables. Any variable set this way applies as a fact to the host in which it is set. The set_fact relates the variable to the host used in the play.

Here, you can dynamically set variables based on the result of any task in the playbook. So set_fact is dynamically defining variables. Keep in mind that setting variables this way will have a playbook scope.

 

  • Define variables: Vars_files

You can also put variables into one or more files using the section called vars_files. This lets you put variables in a file instead of directly in the playbook. What I like most about setting variables this way is that it allows you to separate variables that contain sensitive information. When you define variables in reusable variable files, the sensitive variables are separated from playbooks.

This separation enables you to store your playbooks in, for example, source control software and even share the playbooks without the risk of exposing passwords or other sensitive and personal data. So, when you put variables in files, they are referenced in the playbook using vars_files.

Use the var_files: to specify a list of files that include variables you want to include. This is convenient when you want to manage the variables independent of the place using them and is helpful for security purposes.

 

  • Define variables: Vars_Promt

So here, we can use vars_promt in the play header to prompt users for a variable value. This has a playbook scope. By default, the variable is flagged as private, so the user does not see anything while entering the variable. We can if we have set private to no here. 

 

  • Define variables: Defining variables at runtime.  

When you run your playbook, you can define variables by passing variables at the command line using the –extra-vars (or -e) argument. 

 

  • Define variables: Task Variables.

Task variables are made from data discovered while executing tasks or in the fact-gathering phase of a play. These variables are host-specific and are added to the host’s host vars. Variables of this type can be discovered via gather_facts and fact modules, populated from task return data via the register task key, or defined directly by a task using the set_fact or add_host modules. 

 

  • A key point: Video on Ansible Job Templates

In this product demonstration, we will go through the key components of Ansible Tower and its use of Job Templates. We will look at the different Job Template parameters that you can use to form an automation job that you can deploy to your managed assets.

 

Ansible Tower Job Template
Prev 1 of 1 Next
Prev 1 of 1 Next

 

Facts / Variables

  • Ansible Fact: System Variables

Ansible facts are a type of variable. You don’t define Ansible facts; they are discovered. Facts are system variables that contain information about the managed system. Each playbook starts with an implicit task to gather facts. This can also be disabled in the playhead. Gathering facts takes time, so if you are not going to use it, we can disable it.

We can also gather facts manually by using the setup modules. All of the facts are stored in one big variable called ansible_facts. However, within the variable, we have the second-tier variables. All of the facts are categorized into different variables. These facts are variables, and you can use the facts in conditionals and when statements. 

 

    • Speeding up Fact Gathering

Fact collection can be slow as you may work against many hosts you can use and set up a fact cache. If fact-caching is enabled, Ansible will store facts in a cache for the first time; it connects to the host. This is added to your Ansible.cfg with the “fact_caching_timeout” value. So if your playbook does not reference any ansible facts, you can turn off fact-gathering for that play. Here we use the “gather_facts” clause in the play and the Ansible.cfg.

 

Ansible Inventory Variable

Ansible Variables are a key component of Automation, and they allow for dynamic play content and reusable plays across different sets of an inventory. Variable data, such as specific details on how to connect to a particular host in your inventory, can be included, along with an inventory, in various ways.

While Ansible can discover data about a system during the setup phase, not all data can be discovered. We can define data with the inventory that will expand what Ansible has been to discover.

 

Ansible variables: The Ansible inventory variables

    • Host and group variables

In inventory, you can store variable values related to a specific host or group. This allows you to add variables directly to the hosts and groups in your main inventory file. Adding more managed nodes to your Ansible inventory will likely allow you to store variables in separate host and group variable files.

    • [host_var and group_var]

Ansible looks for host variable files in a directory called host_vars and group variable files in a directory called group_vars. Remember that Ansible expects these directories to be in either the directory that contains your playbooks or the directory adjacent to your inventory file. You can break things out even further if you want to go further. Ansible lets us define, for example, group_vars/production as a directory instead of a file. 

 

Behavior inventory variables

Behavioral inventory parameters allow you to describe your machines with additional parameters in your inventory file. Such as the ansible_connection parameter may be helpful. By default, Ansible supports multiple means of transport, which Ansible uses to connect to the managed host. Here is a list of some expected behavior inventory variables and the behaviors they intend to modify:

    1. ansible_host: This is the DNS name or the Docker container name that Ansible will initiate a connection to.
    2. ansible_port: This specifies the port number that Ansible will use to connect to the inventory host if it is not the default value 22.
    3. ansible_user: This specifies the username Ansible will use to connect with the inventory host, regardless of the connection type.
Ansible Automation Best Practices
Diagram: Ansible automation best practices. Ansible inventory variables.

 

  • A key point: Ansible inventory scalability

You can use the inventory to put host and group variables if you don’t have many hosts. However, as your environment gets larger, managing variables in the inventory will become more challenging. In this case, you need to find a more scalable approach to keep track of your host and group variables.

Even though Ansible variables can hold Booleans, strings, lists, and dictionaries, you can specify only Booleans and strings in an inventory file. Therefore, we have a more scalable approach to keeping track of host and group variables: you can create a separate variable file for each host and group. You can create a separate variable file for each host and group. Ansible expects these variable files to be in YAML format. This allows you to break the inventory into multiple files.

 

Summary: Ways to define ansible variables in playbooks

There are different ways that variables can be determined.

 

Defining Ansible Variables

  • You can define variables in the play header using the vars: sections

  • Also, the play header uses include vars_files

  • Using the set_fact modules in a place

  • Also, in the command line with the -e key-value

  • As inventory variables

  • Using vars_promp to request values from the user while running the playbook

  • Also, the Facts are discovered variables. They contain system properties.

 

Highlighting Ansible conditionals

In a playbook, you may want to execute different tasks depending on the value of a fact, a variable, or the result of a previous task. You may wish to the value of some variables to depend on the value of other variables. You can do all of these things with conditionals. Ansible uses Jinja2 tests and filters in conditionals. Basic conditionals are used with the when clause.

The most straightforward conditional statement applies to a single task. Create the Task, then add a when the statement that applies a test. Ansible evaluates the test for all hosts when running the Task or playbook. For example, if you are installing MySQL on multiple machines, some of which have SELinux enabled, you might have a task to configure SELinux to allow MySQL to run.

You would only want that Task to run on machines with SELinux enabled: Sometimes, you want to execute or skip a task based on facts. With conditionals based on facts: You can install a specific package only when the operating system is a particular version. You can skip configuring a firewall on hosts with internal IP addresses. You can perform cleanup tasks only when a filesystem is getting full.

 

  • A key point: Video on Ansible Automation

In this tutorial, we are going to discuss Ansible Automation. In particular, Ansible Engine is run from the CLI. We will discuss the challenging landscape forcing us to move to automation. While introducing Ansible playbooks and the other Ansible main components

 

Ansible Automation Explained
Prev 1 of 1 Next
Prev 1 of 1 Next

 

Ansible conditionals and When Clause

You can also create conditionals based on variables defined in the playbooks or inventory. So, we have playbook variables, registered variables, and facts that can all be used in conditions and ensure that tasks only run if specific conditions are true. 

 

Handlers and When Statement

There are several ways Ansible can be configured for conditional task execution. We have, for example, Handlers for conditional task execution. It is used when a task has changed something. Then we have a very powerful When statement. The When statement allows you to run tasks when specific conditions are true. You can also use the Register in combination with When statements.

Automation Tutorial
Diagram: Automation tutorial.

 

Using Handlers for conditional task execution

A handler is a task only executed when triggered by a task that has changed something. Handler is executed after all tasks in a play, so you need to organize the contents of your playbook accordingly. If any task fails after the Task called the handler, the handlers are not executed. We can use the “force-handler: to change this.

Keep in mind that handlers are operational when something has changed. We have a force handler that allows you to force the handler to be started even if subsequent tasks are failing. Simply put, a handler is a particular type of Task that is called only if something changes. 

 

  • Handlers in Pre and Post tasks

Each task section in a playbook is handled separately; any handler notified in pre_tasks, tasks, or post_tasks is executed at the end of each section. As a result, it is possible to execute one handler several times in one play.

 

Using Blocks

Blocks create logical groups of tasks. Blocks also offer ways to handle task errors, similar to exception handling in many programming languages. Blocks can also be used in error conditional handling. So you have to use a block to define the main Task to run and then rescue to define tasks that run if tasks defined in the block fail. You can use “Always to Define” tasks that will run regardless of the success or failure of the Block and Rescue.

 

  • A keynote: Ansible loops

What happens, however, if you have a single task but need to run it against a list of data, for example, creating several user accounts, directories, or something more complex? Like any programming language, loops in Ansible provide an easier way of executing repetitive tasks using fewer lines of code in a playbook.

Examples of commonly used loops include changing ownership of several files and directories with the file module, creating multiple users with the user module, and repeating a polling step until a certain result is reached.

 

  • A final point: Managing failures with the Fail Module

Ansible looks at the exit status of a task to determine whether it has failed. When any task fails, Ansible aborts the rest of the playbook on that host and continues with the next host. We can change this with a few solutions. For example, we can use ignore_errors in a task to ignore failure—force_handlers to force a handler that has been triggered to run even if another task fails.

But remember, there needs to be a change. We can also use these Failed_When, which allows you to specify what to look for in command output to recognize a failure. You may have a playbook used to clean up resources, and you want the playbook to ignore every error, keep going on till the end, and then fail if there are errors. In this case, when using the fail module, the failing Task must have Ignore Errors set to yes.

 

To summarize, Ansible variables are a powerful tool for automation. They allow users to define and store values that can be used throughout the playbook, making it easy to customize and adapt automation processes. Whether storing configuration values, dynamically generating variables, or working with complex data structures, Ansible variables provide the flexibility and power needed for efficient automation.

 

Ansible inventory variable