46b1a999c6
* Build documentation for Ansible-2.10 (formerly known as ACD). Builds plugin docs from collections whose source is on galaxy The new command downloads collections from galaxy, then finds the plugins inside of them to get the documentation for those plugins. * Update the python syntax checks * docs builds can now require python 3.6+. * Move plugin formatter code out to an external tool, antsibull-docs. Collection owners want to be able to extract docs for their own websites as well. * The jinja2 filters, tests, and other support code have moved to antsibull * Remove document_plugins as that has now been integrated into antsibull-docs * Cleanup and bugfix to other build script code: * The Commands class needed to have its metaclass set for abstractmethod to work correctly * Fix lint issues in some command plugins * Add the docs/docsite/rst/collections to .gitignore as everything in that directory will be generated so we don't want any of it saved in the git repository * gitignore the build dir and remove edit docs link on module pages * Add docs/rst/collections as a directory to remove on make clean * Split the collections docs from the main docs * remove version and edit on github * remove version banner for just collections * clarify examples need collection keyword defined * Remove references to plugin documentation locations that no longer exist. * Perhaps the pages in plugins/*.rst should be deprecated altogether and their content moved? * If not, perhaps we want to rephrase and link into the collection documentation? * Or perhaps we want to link to the plugins which are present in collections/ansible/builtin? * Remove PYTHONPATH from the build-ansible calls One of the design goals of the build-ansible.py script was for it to automatically set its library path to include the checkout of ansible and the library of code to implement itself. Because it automatically includes the checkout of ansible, we don't need to set PYTHONPATH in the Makefile any longer. * Create a command to only build ansible-base plugin docs * When building docs for devel, only build the ansible-base docs for now. This is because antsibull needs support for building a "devel tree" of docs. This can be changed once that is implemented * When building docs for the sanity tests, only build the ansible-base plugin docs for now. Those are the docs which are in this repo so that seems appropriate for now. * Docs: User guide overhaul, part 5 (#70307) (cherry picked from commitdb354c0300
) * Need to return any error code from running antsibull-docs (#70763) This way we fail early if there's a problem (cherry picked from commit1e3989c9f7
) Co-authored-by: Alicia Cozine <879121+acozine@users.noreply.github.com>
184 lines
8.2 KiB
ReStructuredText
184 lines
8.2 KiB
ReStructuredText
.. _inventory_plugins:
|
|
|
|
Inventory Plugins
|
|
=================
|
|
|
|
.. contents::
|
|
:local:
|
|
:depth: 2
|
|
|
|
Inventory plugins allow users to point at data sources to compile the inventory of hosts that Ansible uses to target tasks, either via the ``-i /path/to/file`` and/or ``-i 'host1, host2'`` command line parameters or from other configuration sources.
|
|
|
|
|
|
.. _enabling_inventory:
|
|
|
|
Enabling inventory plugins
|
|
--------------------------
|
|
|
|
Most inventory plugins shipped with Ansible are disabled by default and need to be whitelisted in your
|
|
:ref:`ansible.cfg <ansible_configuration_settings>` file in order to function. This is how the default whitelist looks in the
|
|
config file that ships with Ansible:
|
|
|
|
.. code-block:: ini
|
|
|
|
[inventory]
|
|
enable_plugins = host_list, script, auto, yaml, ini, toml
|
|
|
|
This list also establishes the order in which each plugin tries to parse an inventory source. Any plugins left out of the list will not be considered, so you can 'optimize' your inventory loading by minimizing it to what you actually use. For example:
|
|
|
|
.. code-block:: ini
|
|
|
|
[inventory]
|
|
enable_plugins = advanced_host_list, constructed, yaml
|
|
|
|
The ``auto`` inventory plugin can be used to automatically determines which inventory plugin to use for a YAML configuration file. It can also be used for inventory plugins in a collection.
|
|
|
|
To whitelist specific inventory plugins in a collection you need to use the fully qualified name:
|
|
|
|
.. code-block:: ini
|
|
|
|
[inventory]
|
|
enable_plugins = namespace.collection_name.inventory_plugin_name
|
|
|
|
|
|
.. _using_inventory:
|
|
|
|
Using inventory plugins
|
|
-----------------------
|
|
|
|
The only requirement for using an inventory plugin after it is enabled is to provide an inventory source to parse.
|
|
Ansible will try to use the list of enabled inventory plugins, in order, against each inventory source provided.
|
|
Once an inventory plugin succeeds at parsing a source, any remaining inventory plugins will be skipped for that source.
|
|
|
|
To start using an inventory plugin with a YAML configuration source, create a file with the accepted filename schema for the plugin in question, then add ``plugin: plugin_name``. Each plugin documents any naming restrictions. For example, the aws_ec2 inventory plugin has to end with ``aws_ec2.(yml|yaml)``
|
|
|
|
.. code-block:: yaml
|
|
|
|
# demo.aws_ec2.yml
|
|
plugin: aws_ec2
|
|
|
|
Or for the openstack plugin the file has to be called ``clouds.yml`` or ``openstack.(yml|yaml)``:
|
|
|
|
.. code-block:: yaml
|
|
|
|
# clouds.yml or openstack.(yml|yaml)
|
|
plugin: openstack
|
|
|
|
To use a plugin in a collection provide the fully qualified name:
|
|
|
|
.. code-block:: yaml
|
|
|
|
plugin: namespace.collection_name.inventory_plugin_name
|
|
|
|
The ``auto`` inventory plugin is enabled by default and works by using the ``plugin`` field to indicate the plugin that should attempt to parse it. You can configure the whitelist/precedence of inventory plugins used to parse source using the `ansible.cfg` ['inventory'] ``enable_plugins`` list. After enabling the plugin and providing any required options, you can view the populated inventory with ``ansible-inventory -i demo.aws_ec2.yml --graph``:
|
|
|
|
.. code-block:: text
|
|
|
|
@all:
|
|
|--@aws_ec2:
|
|
| |--ec2-12-345-678-901.compute-1.amazonaws.com
|
|
| |--ec2-98-765-432-10.compute-1.amazonaws.com
|
|
|--@ungrouped:
|
|
|
|
If you are using an inventory plugin in a playbook-adjacent collection and want to test your setup with ``ansible-inventory``, you will need to use the ``--playbook-dir`` flag.
|
|
|
|
You can set the default inventory path (via ``inventory`` in the `ansible.cfg` [defaults] section or the :envvar:`ANSIBLE_INVENTORY` environment variable) to your inventory source(s). Now running ``ansible-inventory --graph`` should yield the same output as when you passed your YAML configuration source(s) directly. You can add custom inventory plugins to your plugin path to use in the same way.
|
|
|
|
Your inventory source might be a directory of inventory configuration files. The constructed inventory plugin only operates on those hosts already in inventory, so you may want the constructed inventory configuration parsed at a particular point (such as last). Ansible parses the directory recursively, alphabetically. You cannot configure the parsing approach, so name your files to make it work predictably. Inventory plugins that extend constructed features directly can work around that restriction by adding constructed options in addition to the inventory plugin options. Otherwise, you can use ``-i`` with multiple sources to impose a specific order, e.g. ``-i demo.aws_ec2.yml -i clouds.yml -i constructed.yml``.
|
|
|
|
You can create dynamic groups using host variables with the constructed ``keyed_groups`` option. The option ``groups`` can also be used to create groups and ``compose`` creates and modifies host variables. Here is an aws_ec2 example utilizing constructed features:
|
|
|
|
.. code-block:: yaml
|
|
|
|
# demo.aws_ec2.yml
|
|
plugin: aws_ec2
|
|
regions:
|
|
- us-east-1
|
|
- us-east-2
|
|
keyed_groups:
|
|
# add hosts to tag_Name_value groups for each aws_ec2 host's tags.Name variable
|
|
- key: tags.Name
|
|
prefix: tag_Name_
|
|
separator: ""
|
|
groups:
|
|
# add hosts to the group development if any of the dictionary's keys or values is the word 'devel'
|
|
development: "'devel' in (tags|list)"
|
|
compose:
|
|
# set the ansible_host variable to connect with the private IP address without changing the hostname
|
|
ansible_host: private_ip_address
|
|
|
|
Now the output of ``ansible-inventory -i demo.aws_ec2.yml --graph``:
|
|
|
|
.. code-block:: text
|
|
|
|
@all:
|
|
|--@aws_ec2:
|
|
| |--ec2-12-345-678-901.compute-1.amazonaws.com
|
|
| |--ec2-98-765-432-10.compute-1.amazonaws.com
|
|
| |--...
|
|
|--@development:
|
|
| |--ec2-12-345-678-901.compute-1.amazonaws.com
|
|
| |--ec2-98-765-432-10.compute-1.amazonaws.com
|
|
|--@tag_Name_ECS_Instance:
|
|
| |--ec2-98-765-432-10.compute-1.amazonaws.com
|
|
|--@tag_Name_Test_Server:
|
|
| |--ec2-12-345-678-901.compute-1.amazonaws.com
|
|
|--@ungrouped
|
|
|
|
If a host does not have the variables in the configuration above (i.e. ``tags.Name``, ``tags``, ``private_ip_address``), the host will not be added to groups other than those that the inventory plugin creates and the ``ansible_host`` host variable will not be modified.
|
|
|
|
If an inventory plugin supports caching, you can enable and set caching options for an individual YAML configuration source or for multiple inventory sources using environment variables or Ansible configuration files. If you enable caching for an inventory plugin without providing inventory-specific caching options, the inventory plugin will use fact-caching options. Here is an example of enabling caching for an individual YAML configuration file:
|
|
|
|
.. code-block:: yaml
|
|
|
|
# demo.aws_ec2.yml
|
|
plugin: aws_ec2
|
|
cache: yes
|
|
cache_plugin: jsonfile
|
|
cache_timeout: 7200
|
|
cache_connection: /tmp/aws_inventory
|
|
cache_prefix: aws_ec2
|
|
|
|
Here is an example of setting inventory caching with some fact caching defaults for the cache plugin used and the timeout in an ``ansible.cfg`` file:
|
|
|
|
.. code-block:: ini
|
|
|
|
[defaults]
|
|
fact_caching = jsonfile
|
|
fact_caching_connection = /tmp/ansible_facts
|
|
cache_timeout = 3600
|
|
|
|
[inventory]
|
|
cache = yes
|
|
cache_connection = /tmp/ansible_inventory
|
|
|
|
Besides cache plugins shipped with Ansible, cache plugins eligible for caching inventory can also reside in a custom cache plugin path or in a collection. Use FQCN if the cache plugin is in a collection.
|
|
|
|
.. _inventory_plugin_list:
|
|
|
|
Plugin List
|
|
-----------
|
|
|
|
You can use ``ansible-doc -t inventory -l`` to see the list of available plugins.
|
|
Use ``ansible-doc -t inventory <plugin name>`` to see plugin-specific documentation and examples.
|
|
|
|
.. seealso::
|
|
|
|
:ref:`about_playbooks`
|
|
An introduction to playbooks
|
|
:ref:`callback_plugins`
|
|
Ansible callback plugins
|
|
:ref:`connection_plugins`
|
|
Ansible connection plugins
|
|
:ref:`playbooks_filters`
|
|
Jinja2 filter plugins
|
|
:ref:`playbooks_tests`
|
|
Jinja2 test plugins
|
|
:ref:`playbooks_lookups`
|
|
Jinja2 lookup plugins
|
|
:ref:`vars_plugins`
|
|
Ansible vars plugins
|
|
`User Mailing List <https://groups.google.com/group/ansible-devel>`_
|
|
Have a question? Stop by the google group!
|
|
`irc.freenode.net <http://irc.freenode.net>`_
|
|
#ansible IRC chat channel
|