* Change behavior to behaviour
- use existing fact to get hash setting rather than shell task
- fix code highlighting syntax in playbooks_variables.rst
* Re-wrote intro section; this entire topic needs a clean-up/rewrite.
While automation exists to make it easier to make things repeatable, all of your systems are likely not exactly alike.
While automation exists to make it easier to make things repeatable, all systems are not exactly alike; some may require configuration that is slightly different from others. In some instances, the observed behavior or state of one system might influence how you configure other systems. For example, you might need to find out the IP address of a system and use it as a configuration value on another system.
On some systems you may want to set some behavior or configuration that is slightly different from others.
Ansible uses *variables* to help deal with differences between systems.
Also, some of the observed behavior or state
To understand variables you'll also want to read :doc:`playbooks_conditionals` and :doc:`playbooks_loops`.
of remote systems might need to influence how you configure those systems. (Such as you might need to find out the IP
address of a system and even use it as a configuration value on another system).
You might have some templates for configuration files that are mostly the same, but slightly different based on those variables.
Variables in Ansible are how we deal with differences between systems.
To understand variables you'll also want to dig into :doc:`playbooks_conditionals` and :doc:`playbooks_loops`.
Useful things like the **group_by** module
Useful things like the **group_by** module
and the ``when`` conditional can also be used with variables, and to help manage differences between systems.
and the ``when`` conditional can also be used with variables, and to help manage differences between systems.
It's highly recommended that you consult the ansible-examples github repository to see a lot of examples of variables put to use.
The ansible-examples github repository contains many examples of how variables are used in Ansible.
For advice on best practices, refer to :ref:`best_practices_for_variables_and_vaults` in the *Best Practices* chapter.
For advice on best practices, refer to :ref:`best_practices_for_variables_and_vaults` in the *Best Practices* chapter.
@ -449,7 +441,7 @@ Local Facts (Facts.d)
As discussed in the playbooks chapter, Ansible facts are a way of getting data about remote systems for use in playbook variables.
As discussed in the playbooks chapter, Ansible facts are a way of getting data about remote systems for use in playbook variables.
Usually these are discovered automatically by the **setup** module in Ansible. Users can also write custom facts modules, as described in the API guide. However, what if you want to have a simple way to provide system or user provided data for use in Ansible variables, without writing a fact module?
Usually these are discovered automatically by the ``setup`` module in Ansible. Users can also write custom facts modules, as described in the API guide. However, what if you want to have a simple way to provide system or user provided data for use in Ansible variables, without writing a fact module?
"Facts.d" is one mechanism for users to control some aspect of how their systems are managed.
"Facts.d" is one mechanism for users to control some aspect of how their systems are managed.
@ -873,10 +865,10 @@ Basically, anything that goes into "role defaults" (the defaults folder inside t
..note:: Within any section, redefining a var will overwrite the previous instance.
..note:: Within any section, redefining a var will overwrite the previous instance.
If multiple groups have the same variable, the last one loaded wins.
If multiple groups have the same variable, the last one loaded wins.
If you define a variable twice in a play's vars: section, the 2nd one wins.
If you define a variable twice in a play's ``vars:`` section, the second one wins.
..note::the previous describes the default config `hash_behavior=replace`, switch to 'merge' to only partially overwrite.
..note::The previous describes the default config ``hash_behaviour=replace``, switch to ``merge`` to only partially overwrite.
..note:: Group loading follows parent/child relationships. Groups of the same 'patent/child' level are then merged following alphabetical order.
..note:: Group loading follows parent/child relationships. Groups of the same 'patent/child' level are then merged following alphabetical order.
This last one can be superceeded by the user via `ansible_group_priority`, which defaults to 0 for all groups.
This last one can be superceeded by the user via ``ansible_group_priority``, which defaults to 0 for all groups.
Another important thing to consider (for all versions) is that connection variables override config, command line and play/role/task specific options and keywords. For example::
Another important thing to consider (for all versions) is that connection variables override config, command line and play/role/task specific options and keywords. For example::
@ -1005,7 +997,7 @@ This can often be used for things that might apply to some hosts multiple times.
myname: John
myname: John
In this example, the same role was invoked multiple times. It's quite likely there was
In this example, the same role was invoked multiple times. It's quite likely there was
no default for 'name' supplied at all. Ansible can warn you when variables aren't defined -- it's the default behavior in fact.
no default for ``name`` supplied at all. Ansible can warn you when variables aren't defined -- it's the default behavior in fact.
There are a few other things that go on with roles.
There are a few other things that go on with roles.
Sam Doran
7 years ago
committed by