Ansible Variables

Variables are used in Ansible to oversee contrasts between frameworks. With the help of Ansible, you can run tasks and playbooks on various frameworks in a solitary order. To demonstrate the varieties among those various systems, you can make variables with standard YAML language structure, including records and word references. You can characterize these variables inside your playbooks, in your stock or inventory, in reusable documents or roles, or at the order or command line. Besides, you can also make variables during a playbook run by enrolling the return worth or estimations of a task as another variable.

After you make variables, either by characterizing them in a record, passing them at the order line, or enrolling the return worth or estimations of an assignment as another variable, you can utilize those variables in module contentions, in restrictive "when" statements, in templates, and in loops. The ansible-models GitHub vault contains numerous instances of utilizing variables in Ansible.

When you comprehend the ideas and models on this page, you will find out Ansible facts, which are variables that you recover from far-off frameworks.

Making valid variable names

Every string is not a valid Ansible variable name. A variable name can just incorporate letters, numbers, and underscores. Keywords from python and playbooks are not valid variable names. A variable name can't start with a number.

Variable names can start with an underscore. In many programming dialects, variables that start with an underscore are private. This isn't accurate in Ansible. Variables that start with an underscore are dealt with precisely equivalent to some other variable. Try not to depend on this show for protection or security.

This table gives instances of valid and invalid variable names:

Legitimate variable names	Not legitimate
foo	*foo, keywords from python like async and lambda
foo_env	Keywords from playbooks like environment
foo_port	foo-port, foo port, foo.port
foo7, _foo	7foo, 15

Straightforward variables

Straightforward variables consolidate a variable name with a solitary worth. You can utilize this syntax (and the syntax for records and dictionary references demonstrated as follows) in an assortment of spots. For insights concerning setting variables in stock, in playbooks, in reusable documents, in roles, or at the order line.

Characterizing straightforward variables

You can characterize a straightforward variable utilizing standard YAML syntax. For instance:

remote_install_path:/opt/my_app_config

Referring to basic variables

After you characterize a variable, use Jinja2 syntax for reference. Jinja2 variables utilize two curly braces. For instance, the articulation My amp goes to {{ max_amp_value }} shows the essential type of variable replacement. You can utilize Jinja2 syntax in playbooks. For instance:

template: src=foo.cfg.j2 dest= {{ remote_install_path }}/foo.cfg

In this model, the variable characterizes the area of a document, which can fluctuate starting with one framework then onto the next.

List variables

A list variable connects with a variable name with various properties. The various qualities or properties can be put away as an organized list or in square sections [ ], isolated with commas.

Characterizing variables as lists

You can characterize variables with various qualities utilizing YAML lists. For instance:

region:

- northeast

- southeast

- Midwest

-northwest

-southwest

Enlisting variables

You can make variables from the yield of an Ansible assignment with the task keyword register. You can utilize enlisted variables in any later assignments in your play. For instance:

- hosts: web_servers

tasks:

- shell:/usr/container/foo

ignore_errors: True

- shell:/usr/container/bar

when: foo_result.rc == 5

For additional instances of utilizing enlisted variables in conditions on later tasks. Enlisted variables might be straightforward variables, list variables, dictionary variables, or complex settled information structures. The documentation for every module incorporates a RETURN area depicting the return esteems for that module. To check the qualities of a specific task, execute your playbook using - v.

Enlisted variables are put away in memory. You can't store enlisted variables for use in future plays. Enlisted variables are just substantial on the host for the remainder of the current playbook run.

Variable priority: Where would it be a good idea for me to put a variable?

You can put various variables with similar names in a wide range of spots. At the point when you do this, Ansible loads each conceivable variable it discovers, at that point picks the variable to apply dependent on variable priority. As such, the various variables will nullify each other in a specific request.

Understanding variable priority

Ansible applies variable priority, and you may have utilization for it. Here is the request for priority from least to most noteworthy (the last recorded factors supersede every single other variable):

order line esteems (for instance, - u my_user, these are not considered as variables)

role defaults (characterized in role/defaults/main.yml) 1

inventory file or content gathering vars 2

inventory group_vars/every one of the 3

playbook group_vars/every one of the 3

inventory group_vars/* 3

playbook group_vars/* 3 # Here the number behind the statement

shows the priority order within them.

inventory file or content host vars 2

inventory host_vars/* 3

playbook host_vars/* 3

host facts/stored set_facts 4

play vars

play vars_prompt

play vars_files

role vars (characterized in role/vars/main.yml)

block vars (just for tasks in block)

task vars (just for the task)

include_vars

set_facts/enrolled vars

role (and include_role) params

incorporate params

additional vars (for instance, - e "user=my_user”) (always win priority)

All in all, Ansible offers priority to variables that were characterized more recently, more effectively, and with a more explicit degree. Variables in the defaults organizer inside a role are effectively abrogated. Anything inside the vars catalog of the role represents the past forms of that variable in the namespace. Host or potentially inventory variables supersede role defaults, yet express incorporates, for example, the vars catalog or an include_vars task abrogate inventory variables.

Scoping Variables

You can choose where to set a variable dependent on the extension you need that incentive to have. Ansible focuses on three primary extensions:

Global: It is accumulated by config, command line, and the climate variables.

Play: every play and the contained structures, vars passages (vars; vars_files; vars_prompt), role defaults and vars.

Host: factors straightforwardly related to a host, similar to stock, include_vars, realities or enrolled task yields

Rather than stressing over factor priority, we urge you to consider how effectively or how frequently you need to supersede a variable when choosing where to set it. In the event that you don't know what different factors are characterized, and you need a specific worth, use - extra-vars (- e) to supersede every other variable.`