mirror of
https://github.com/ansible-collections/community.general.git
synced 2024-09-14 20:13:21 +02:00
Clean up variable examples to say "$x" is still fine for a reference.
This commit is contained in:
parent
1365f0d6ab
commit
1b5dd3f15b
1 changed files with 8 additions and 8 deletions
|
@ -155,19 +155,19 @@ These variables can be used later in the playbook like this::
|
||||||
|
|
||||||
$varname or ${varname} or {{ varname }}
|
$varname or ${varname} or {{ varname }}
|
||||||
|
|
||||||
If you ever want to do anything complex, {{ varname }} is best, as it uses the Jinja2 templating engine. It is a good idea to get
|
If you ever want to do anything complex like uppercasing a string, {{ varname }} is best, as it uses the Jinja2 templating engine. It is a good idea to get in the habit of using this form most of the time when the output is to be a string.
|
||||||
in the habit of using this form.
|
|
||||||
|
|
||||||
To learn more about Jinja2, you can optionally see the `Jinja2 docs <http://jinja.pocoo.org/docs/>`_ - though remember that Jinja2 loops and conditionals are only for 'templates' in Ansible, in playbooks, ansible has the 'when' and 'with' keywords for conditionals and loops.
|
If just referencing the value of another simple variable though, it's fine to say $x or ${x}. This is common for when a datastructure has a member that is the value of another datastructure.
|
||||||
|
|
||||||
|
To learn more about Jinja2, you can optionally see the `Jinja2 docs <http://jinja.pocoo.org/docs/>`_ - though remember that Jinja2 loops and conditionals are only for 'templates' in Ansible, in playbooks, ansible has the 'when' and 'with' keywords for conditionals and loops.
|
||||||
|
|
||||||
If there are discovered variables about the system, called 'facts', these variables bubble up back into the
|
If there are discovered variables about the system, called 'facts', these variables bubble up back into the
|
||||||
playbook, and can be used on each system just like explicitly set variables. Ansible provides several
|
playbook, and can be used on each system just like explicitly set variables. Ansible provides several
|
||||||
of these, prefixed with 'ansible', and are documented under 'setup' in the module documentation. Additionally,
|
of these, prefixed with 'ansible', and are documented under 'setup' in the module documentation. Additionally,
|
||||||
facts can be gathered by ohai and facter if they are installed. Facter variables are prefixed with ``facter_`` and Ohai
|
facts can be gathered by ohai and facter if they are installed. Facter variables are prefixed with ``facter_`` and Ohai variables are prefixed with ``ohai_``. These add extra dependencies and are only there for ease of users
|
||||||
variables are prefixed with ``ohai_``.
|
porting over from those other configuration systems.
|
||||||
|
|
||||||
So for instance, if I wanted
|
How about an example. If I wanted to write the hostname into the /etc/motd file, I could say::
|
||||||
to write the hostname into the /etc/motd file, I could say::
|
|
||||||
|
|
||||||
- name: write the motd
|
- name: write the motd
|
||||||
action: template src=/srv/templates/motd.j2 dest=/etc/motd
|
action: template src=/srv/templates/motd.j2 dest=/etc/motd
|
||||||
|
@ -176,7 +176,7 @@ And in /srv/templates/motd.j2::
|
||||||
|
|
||||||
You are logged into {{ facter_hostname }}
|
You are logged into {{ facter_hostname }}
|
||||||
|
|
||||||
But we're getting ahead of ourselves. Let's talk about tasks.
|
But we're getting ahead of ourselves, as that just showed a task in a playbook. Let's talk about tasks.
|
||||||
|
|
||||||
Tasks list
|
Tasks list
|
||||||
++++++++++
|
++++++++++
|
||||||
|
|
Loading…
Reference in a new issue