![[Howto] Introduction to Ansible variables](https://liquidat.files.wordpress.com/2016/01/ruhr-area-722817_1280.jpg?w=1200)
To become more flexible, Ansible offers the possibility to use variables in loops, but also to use information the target system provides.
Background
Ansible uses variables to enable more flexibility in playbooks and roles. They can be used to loop through a set of given values, access various information like the hostname of a system and replace certain strings in templates by system specific values. Variables are provided through the inventory, by variable files, overwritten on the command line and set in Tower.
But note that variable names have some restrictions in Ansible:
Variable names should be letters, numbers, and underscores. Variables should always start with a letter.
If the variable in question is a dictionary, a key/value pair, it can be referenced both by bracket and dot notation:
foo.bar foo['bar']
The question is however: how to use variables? And how to get them in the first place?
Variables and loops
Loops are arguably among the most common use cases of variables in general – the same is true for Ansible. While they are not using variables provided externally, I’d like to start with loops to give a first idea how to use them. To copy a set of files it is either possible to write a task for each file or to just loop through them:
tasks:
- name: copy files
copy: src={{ item }} dest=/tmp/{{ item }}
with_items:
- alha
- beta
This already shows simple basics: variables can be used in module arguments, and they are referenced via curly brackets {{ }}.
Variables and templates
More importantly, variables can be used to substitute keys in configuration files with system or run-time specific values. Imagine a file which containing the actual host name simply copied over from a central source to the clients. In case of one hundred machines there would be one hundred copies of the configuration file on the server, all almost identical except for the corresponding host name. That is a waste of time and space.
It’s better to have one copy of the configuration file, with a variable as place-maker instead of the host names – this is where templates come into play:
$ cat template.j2
My host name is {{ ansible_hostname }}.
The Ansible module to use templates and activate variable substitution is the template module:
tasks:
- name: copy template
template: src=template.j2 dest="/tmp/abcapp.conf"
When this task is run against a set of systems, the all get a file called abcapp.conf containing the individual host name of the given system.
This is again a simple example, but shows the basics: in templates variables are also referenced by {{ }}. Templates can become much more sophisticated, but I will try to cover that in another post.
Using variables in conditions
Variables can be used as conditions, thus ensuring that certain tasks are only run when for example on a given host the requested variable is set to a certain value:
tasks:
- name: install Apache on Solaris
pkg5: name=web/server/apache-24
when: ansible_os_family == "Solaris"
- name: install Apache on RHEL
yum: name=httpd
when: ansible_os_family == "RedHat"
In this case, the first task is only applied on Red Hat Enterprise Linux servers, while the second is only run on Solaris machines.
Getting variables from the system
Using variables is one thing, but they need to be defined first. I have covered so far some use cases of variables, but not where to get them.
Ansible already defines a rich set of variables, individual for each system: whenever Ansible is run on a system all facts and information about the system are gathered and set as a variable. The available variables can be output via the setup module:
$ ansible neon -m setup
neon | success >> {
"ansible_facts": {
"ansible_all_ipv4_addresses": [
"192.168.122.203"
],
"ansible_all_ipv6_addresses": [
"fe80::5054:ff:feba:9db3"
],
"ansible_architecture": "x86_64",
"ansible_bios_date": "04/01/2014",
...
All these variables can be used in templates, but also in the playbooks themselves as mentioned above in the conditions example. Roles can take advantage of these variables as well, of course.
Getting variables from the command line
Another way to define variables is to call Ansible playbooks with the option --extra-vars:
$ ansible-playbook --extra-vars "cli_var=production" system-setup.yml
The reference is again via the {{ }} brackets:
$ cat template.j2
environment: {{ cli_var }}.
Setting variables in playbooks
A more direct way is to define variables in playbooks directly, with the key vars:
... hosts: all vars: play_var: bar tasks: ...
This can be extended by including an actual yaml file containing variables:
... hosts: all include_vars: setupvariables.yml tasks: ...
Including further files with more variables comes in extremly handy when the variables for each system are kept in a system specific file, like $HOSTNAME.yml, because the included variable file can again be a variable:
...
hosts: all
include_vars: "{{ ansible_hostname }}.yml"
tasks:
...
In this case, the playbook reads in specific variables for each corresponding host – this way it is possible to set for example different virtual host names for Apache servers, or different backup systems in case of separated data centers.
Setting variables in the inventory
Sometimes it might make more sense to define specific variables in the already set up inventory:
[clients] helium intevent_var=helium_123 neon invent_var=bar
The inventory more or less treats any argument which is not Ansible specific as a host variable.
It is also possible to set variables for entire host groups:
[clients] helium neon [clients:vars] invent_var=group-foo
Setting variables in the inventory makes sense when different teams use the same set of Ansible roles and playbooks but have different machine setups which need specific treatment at each location.
Setting variables on a system: local facts
Variables can also be set by dumping specialized files onto the system: when Ansible accesses a remote system it checks for the directory /etc/ansible/facts.d and all files ending in .fact are read. The files can be of various formats – INI, JSON, or even executables which return JSON code. This offers the possibility to add even generic fact providers via scripting.
For example:
$ cat /etc/ansible/facts.d/variables.fact [system] foo=bar dim=dum
The variables can be displayed via the setup module:
$ ansible neon -m setup
...
"type": "loopback"
},
"ansible_local": {
"variables": {
"system": {
"dim": "dum",
"foo": "bar"
}
}
},
"ansible_machine": "x86_64",
...
Using the results of tasks: registered variables
The results of a task during a playbook run can also be stored inside a variable – together with conditionals this enables a playbook to react to the results of the given task with other tasks.
For example, given that an httpd service needs to run. If the service does not run, the entire server should be powered down immediately to ensure that no data corruption takes place. The corresponding playbook checks the httpd service, ignores errors but instead analyses the result and powers down the machine if the service cannot be started:
---
- name: register example
hosts: all
sudo: yes
tasks:
- name: start service
service: name=httpd state=started
ignore_errors: True
register: service_result
- name: shutdown
command: "shutdown -h +1m"
when: service_result | failed
Another example would be to trigger a function to remove the host from the loadbalancer. Or to check if the database is available and would otherwise immediately close down the front firewall.
Accessing variables of other hosts
Last but not least it might be interesting to access the variables (read: facts) of other hosts. This can of course only be done if the facts are actually available.
If this is given, the data can be accessed via the hostvars key. The value for the key is the name given in the inventory.
Groups from within the inventory can also be accessed. That makes it possible to loop through a list of hosts in a group and for example gather all IP addresses or host names or other data.
The following template first accesses the host name of the machine “tower” and afterwards collects all the epoch data of all machines:
Tower name is: {{ hostvars['tower']['ansible_hostname'] }}
The epochs of the clients are:
{% for host in groups['clients'] %}
- {{ hostvars[host]['ansible_date_time']['epoch'] }}
{% endfor %}
The code for the loop is actual line statement of the Jinja2 template engine. The engine also offers if statements and other common operations.
This comes in handy in simple cases like filling the /etc/hosts, but can also empower admins to for example fill in the data of a loadbalancer or a firewall configuration.
Conclusion
Varialbes are a very powerful feature within Ansible to enrich the functionality it provides. Together with templates and the Jinja2 template and language engine the possibilities are almost endless. And sooner or later every admin will leave the simple Ansible calls and playbooks behind and start diving into variables, templates, and loops through variables of other hosts. To make system automation even easier.
![[Howto] Adopting Ansible Galaxy roles for Solaris](https://liquidat.files.wordpress.com/2014/02/ansible_logo_round.png?w=700){kind=logo}
![[Howto] Managing Solaris 11 via Ansible](https://liquidat.files.wordpress.com/2015/12/tower-ansible-solaris.png?w=1200)
![[Howto] Accessing CloudForms updated REST API with Python](https://liquidat.files.wordpress.com/2015/08/volcanic-eruption-67668_1920.jpg?w=1200)
CloudForms comes with a REST API which was updated to version 2.0 in CloudForms 3.2. It covers substantially more functions compared to v1.0 and also offers feature parity with the old SOAP interface. This post holds a short introduction to calling the REST API via Python.
/home/liquidat 