I’m repeating the rules here to avoid us having to flip back and forth:
- Variables loaded from YAML files mentioned in
vars_filesin a playbook.
varsas defined in the playbook.
- facts, whether built in or custom, or variables assigned from the
- variables passed to parameterized task include statements.
- Host variables from inventory.
- Group variables from inventory, in order of least specific group to most specific.
I’m finding it difficult to get this into a decent diagram, so take this with a pinch or two of salt, please. I’ve also omitted a few sources of variables for “clarity”:
The further down we get in the diagram, the higher the precedence, i.e. variables declared further down overwrite values defined above.
The documentation states:
if you want to set a default value for something you wish to override somewhere else, the best place to set such a default is in a group variable.
and I agree: I can then override a variable on a per-host basis by creating a
host_vars/hostname file for example. (See also Michael DeHaan’s comment below.)
In version 0.7 Ansible can store the output of a given command in a variable which I use later on in templates, say. The register keyword names the variable.
This playbook runs two commands: the first stores its output in a variable called myname,
and the second in a variable v. The result of whoami is a single string which is
made available to the template as variablename.
stdout. The result of jpprog.sh is a
JSON object represented as a string:
The template follows:
and the output is:
I thought extracting JSON from a command could be pretty useful and contributed a small patch earlier. Basically this is just a different way of obtaining facts: instead of writing a module we use register variables.