Deploy variables in Playbook

Ansible also allows you to put variables into one or more files, using a section called vars_files.

Let’s say we wanted to take the preceding example and put the variables in a file named nginx.yml instead of putting them right in the playbook. We would replace the vars section with a vars_files that looks like this:

vars_files:
- nginx.yml

The nginx.yml file would look like:

key_file: /etc/nginx/ssl/nginx.key
cert_file: /etc/nginx/ssl/nginx.cr

 

View the values of Variables

We can use debug module to output the value of the variable. It works like this:
- debug: var=myvarname

The value of a variable set using the register clause is always a dictionary, but the specific keys of the dictionary are different, depending on the module that was invoked.

The simplest way to find out what a module returns is to register a variable and then output that variable with the debug module.

The output:

1. The changed key is present in the return value of all Ansible modules, and Ansible uses it to determine whether a state change has occurred. For the command
and shell module, this will always be set to true unless overridden with the changed_when clause.
2. The cmd key contains the invoked command as a list of strings.
3. The rc key contains the return code. If it is non-zero, Ansible will assume the task failed to execute.
4. The stderr key contains any text written to standard error, as a single string.

Sometimes it’s useful to do something with the output of a failed task. However, if the task fails, then Ansible will stop executing tasks for the failed host. We can use the ignore_errors: True clause to let ansible keep on working.

Access Dictionary keys

If a variable contains a dictionary, then you can access the keys of the dictionary using either a dot (.) or a subscript ([]).

all of the following are equivalent:
ansible_eth1[‘ipv4’][‘address’] ansible_eth1[‘ipv4’].address
ansible_eth1.ipv4[‘address’] ansible_eth1.ipv4.address

Facts

Before Ansible runs a playbook, Ansible gathers facts, it connects to the host and queries the host for all kinds of details about the host: CPU architecture, operating system, IP addresses, memory info, disk info, and more.  This information is stored in variables that are called facts .

Ansible get the facts by using of a special module called the setup module. You don’t need to call this module in your playbooks because Ansible does that automatically when it gathers facts.

setup module supports a filter parameter that lets you filter by fact name.

For example: $ ansible web -m setup -a 'filter=ansible_eth*'

Local Facts

Ansible also provides an additional mechanism for associating facts with a host. You can place one or more files on the host machine in the /etc/ansible/facts.d directory.

Ansible will recognize the file if it’s:

• In .ini format
• In JSON format
• An executable that takes no arguments and outputs JSON on standard out

 

Variables

 

Built-in Variables

 

 

Parameter	Description
hostvars	A dict whose keys are Ansible host names and values are dicts that map variable names to values
inventory_hostname	Name of the current host as known by Ansible
group_names	A list of all groups that the current host is a member of
groups	A dict whose keys are Ansible group names and values are a list of hostnames that are members of the group. Includes all and ungrouped groups: {“all”: […], “web”: […], “ungrou ped”: […]}
play_hosts	A list of inventory hostnames that are active in the current play
ansible_version	A dict with Ansible version info: {“full”: 1.8.2″, “major”: 1, “minor”: 8, “revision”: 2, “string”: “1.8.2”}

 

Variables set by passing -e var=value to ansible-playbook have the highest precedence.

For example, in greet.yml:

- name: pass a message on the command line
  hosts: localhost
  vars:
    greeting: "you didn't specify a message"
  tasks:
    - name: output a message
      debug: msg="{{ greeting }}" 

If you want to put a space in the variable, you’ll need two use quotes like this:

$ ansible-playbook greet.yml -e 'greeting="hi there"'

The basic rules of precedence are:
1. (Highest) ansible-playbook -e var=value
2. Everything else not mentioned in this list
3. On a host or group, either defined in inventory file or YAML file
4. Facts
5. In defaults/main.yml of a role.