Inventory Plugins

    Most inventory plugins shipped with Ansible are disabled by default and need to be whitelisted in youransible.cfg file in order to function. This is how the default whitelist looks in theconfig file that ships with Ansible:

    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:

    1. [inventory]
    2. enable_plugins = advanced_host_list, constructed, yaml

    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:

    Or for the openstack plugin:

    1. # clouds.yml
    2. plugin: openstack

    You can set the default inventory path (via in the ansible.cfg [defaults] section or the 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 creates and modifies host variables. Here is an aws_ec2 example utilizing constructed features:

    1. # demo.aws_ec2.yml
    2. plugin: aws_ec2
    3. regions:
    4. - us-east-1
    5. - us-east-2
    6. keyed_groups:
    7. # add hosts to tag_Name_value groups for each aws_ec2 host's tags.Name variable
    8. - key: tags.Name
    9. prefix: tag_Name_
    10. separator: ""
    11. groups:
    12. # add hosts to the group development if any of the dictionary's keys or values is the word 'devel'
    13. compose:
    14. # set the ansible_host variable to connect with the private IP address without changing the hostname
    15. ansible_host: private_ip_address

    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.

    You can use ansible-doc -t inventory -l to see the list of available plugins.Use to see plugin-specific documentation and examples.

    See also

    • An introduction to playbooks
    • Callback Plugins
    • Ansible callback plugins
    • Ansible connection plugins
    • Filters
    • Jinja2 filter plugins
    • Jinja2 test plugins
    • Lookups
    • Jinja2 lookup plugins
    • Ansible vars plugins
    • User Mailing List
    • Have a question? Stop by the google group!
    • ansible IRC chat channel