* Due to the takeover of freenode we're moving to a different irc network. * Our channels updated to point at the same channel name on libera.chat * Some links went to webchat.freenode.net. At this time, libera.chat doesn't point you to an official webchat client so I changed these to https://libera.chat. (kiwi irc does work with libera.chat so that could be another option). * In general, I used the name irc.libera.net for link names and https://libera.chat for link targets. This is because the irc service is hosted on irc.libera.chat but the project web server is hosted on libera.chat. (This appears to also be true for freenode but we were using http://irc.freenode.net which doesn't seem to work. Oops). * Removed http://irc.freenode.net from the linkcheck exceptions. linkcheck was actually correct to flag that as invalid (should have been http://frenode.net instead). * Looks like hte important people in #yaml are now in libera.chat * Link to where contributors should get help Add a link target and then link to where contributors should get support for developing groups of modules. * Update docs/docsite/rst/dev_guide/developing_modules_in_groups.rst Co-authored-by: Felix Fontein <felix@fontein.de> Co-authored-by: John R Barker <john@johnrbarker.com> Co-authored-by: Felix Fontein <felix@fontein.de>
6.4 KiB
Lookup Plugins
Lookup plugins are an Ansible-specific extension to the Jinja2
templating language. You can use lookup plugins to access data from
outside sources (files, databases, key/value stores, APIs, and other
services) within your playbooks. Like all templating <playbooks_templating>
, lookups
execute and are evaluated on the Ansible control machine. Ansible makes
the data returned by a lookup plugin available using the standard
templating system. You can use lookup plugins to load variables or
templates with information from external sources.
Note
- Lookups are executed with a working directory relative to the role
or play, as opposed to local tasks, which are executed relative the
executed script. - Pass wantlist=True
to lookups to use in
Jinja2 template "for" loops. - By default, lookup return values are
marked as unsafe for security reasons. If you trust the outside source
your lookup accesses, pass allow_unsafe=True
to allow
Jinja2 templates to evaluate lookup values.
Warning
- Some lookups pass arguments to a shell. When using variables from a remote/untrusted source, use the |quote filter to ensure safe usage.
Enabling lookup plugins
Ansible enables all lookup plugins it can find. You can activate a
custom lookup by either dropping it into a lookup_plugins
directory adjacent to your play, inside the plugins/lookup/
directory of a collection you have installed, inside a standalone role,
or in one of the lookup directory sources configured in ansible.cfg <ansible_configuration_settings>
.
Using lookup plugins
You can use lookup plugins anywhere you can use templating in
Ansible: in a play, in variables file, or in a Jinja2 template for the
template <template_module>
module.
vars:
file_contents: "{{ lookup('file', 'path/to/file.txt') }}"
Lookups are an integral part of loops. Wherever you see
with_
, the part after the underscore is the name of a
lookup. For this reason, most lookups output lists and take lists as
input; for example, with_items
uses the items <items_lookup>
lookup:
tasks:
- name: count to 3
debug: msg={{ item }}
with_items: [1, 2, 3]
You can combine lookups with filters <playbooks_filters>
, tests <playbooks_tests>
and even each other to do some complex data generation and manipulation.
For example:
tasks:
- name: valid but useless and over complicated chained lookups and filters
debug: msg="find the answer here:\n{{ lookup('url', 'https://google.com/search/?q=' + item|urlencode)|join(' ') }}"
with_nested:
- "{{ lookup('consul_kv', 'bcs/' + lookup('file', '/the/question') + ', host=localhost, port=2000')|shuffle }}"
- "{{ lookup('sequence', 'end=42 start=2 step=2')|map('log', 4)|list) }}"
- ['a', 'c', 'd', 'c']
2.6
You can control how errors behave in all lookup plugins by setting
errors
to ignore
, warn
, or
strict
. The default setting is strict
, which
causes the task to fail if the lookup returns an error. For example:
To ignore lookup errors:
- name: if this file does not exist, I do not care .. file plugin itself warns anyway ...
debug: msg="{{ lookup('file', '/nosuchfile', errors='ignore') }}"
[WARNING]: Unable to find '/nosuchfile' in expected paths (use -vvvvv to see paths)
ok: [localhost] => {
"msg": ""
}
To get a warning instead of a failure:
- name: if this file does not exist, let me know, but continue
debug: msg="{{ lookup('file', '/nosuchfile', errors='warn') }}"
[WARNING]: Unable to find '/nosuchfile' in expected paths (use -vvvvv to see paths)
[WARNING]: An unhandled exception occurred while running the lookup plugin 'file'. Error was a <class 'ansible.errors.AnsibleError'>, original message: could not locate file in lookup: /nosuchfile
ok: [localhost] => {
"msg": ""
}
To get a fatal error (the default):
- name: if this file does not exist, FAIL (this is the default)
debug: msg="{{ lookup('file', '/nosuchfile', errors='strict') }}"
[WARNING]: Unable to find '/nosuchfile' in expected paths (use -vvvvv to see paths)
fatal: [localhost]: FAILED! => {"msg": "An unhandled exception occurred while running the lookup plugin 'file'. Error was a <class 'ansible.errors.AnsibleError'>, original message: could not locate file in lookup: /nosuchfile"}
Forcing lookups to return lists: query
and
wantlist=True
2.5
In Ansible 2.5, a new Jinja2 function called query
was
added for invoking lookup plugins. The difference between
lookup
and query
is largely that
query
will always return a list. The default behavior of
lookup
is to return a string of comma separated values.
lookup
can be explicitly configured to return a list using
wantlist=True
.
This feature provides an easier and more consistent interface for
interacting with the new loop
keyword, while maintaining
backwards compatibility with other uses of lookup
.
The following examples are equivalent:
lookup('dict', dict_variable, wantlist=True)
query('dict', dict_variable)
As demonstrated above, the behavior of wantlist=True
is
implicit when using query
.
Additionally, q
was introduced as a shortform of
query
:
q('dict', dict_variable)
Plugin list
You can use ansible-doc -t lookup -l
to see the list of
available plugins. Use
ansible-doc -t lookup <plugin name>
to see specific
documents and examples.
about_playbooks
-
An introduction to playbooks
inventory_plugins
-
Ansible inventory plugins
callback_plugins
-
Ansible callback plugins
playbooks_filters
-
Jinja2 filter plugins
playbooks_tests
-
Jinja2 test plugins
playbooks_lookups
-
Jinja2 lookup plugins
- User Mailing List
-
Have a question? Stop by the google group!
- irc.libera.chat
-
#ansible IRC chat channel