ansible.builtin.ini - Uses an Ansible INI file as inventory source.

This module is part of ansible-base and included in all Ansible installations. In most cases, you can use the short module name ini even without specifying the collections: keyword. Despite that, we recommend you use the FQCN for easy linking to the module documentation and to avoid conflicting with other collections that may have the same module name.

New in version 2.4: of ansible.builtin

• Synopsis
• Notes
• Examples

Synopsis

• INI file based inventory, sections are groups or group related with special :modifiers.

• Entries in sections [group_1] are hosts, members of the group.

• Hosts can have variables defined inline as key/value pairs separated by =.

• The children modifier indicates that the section contains groups.

• The vars modifier indicates that the section contains variables assigned to members of the group.

• Anything found outside a section is considered an 'ungrouped' host.

• Values passed in the INI format using the key=value syntax are interpreted differently depending on where they are declared within your inventory.

• When declared inline with the host, INI values are processed by Python's ast.literal_eval function (//docs.python.org/2/library/ast.html#ast.literal_eval) and interpreted as Python literal structures (strings, numbers, tuples, lists, dicts, booleans, None). Host lines accept multiple key=value parameters per line. Therefore they need a way to indicate that a space is part of a value rather than a separator.

• When declared in a :vars section, INI values are interpreted as strings. For example var=FALSE would create a string equal to FALSE. Unlike host lines, :vars sections accept only a single entry per line, so everything after the = must be the value for the entry.

• Do not rely on types set during definition, always make sure you specify type with a filter when needed when consuming the variable.

• See the Examples for proper quoting to prevent changes to variable type.

Notes

• Whitelisted in configuration by default.

• Consider switching to YAML format for inventory sources to avoid confusion on the actual type of a variable. The YAML inventory plugin processes variable values consistently and correctly.

Examples

example1: |
    # example cfg file
    [web]
    host1
    host2 ansible_port=222 # defined inline, interpreted as an integer

    [web:vars]
    http_port=8080 # all members of 'web' will inherit these
    myvar=23 # defined in a :vars section, interpreted as a string

    [web:children] # child groups will automatically add their hosts to parent group
    apache
    nginx

    [apache]
    tomcat1
    tomcat2 myvar=34 # host specific vars override group vars
    tomcat3 mysecret="'03#pa33w0rd'" # proper quoting to prevent value changes

    [nginx]
    jenkins1

    [nginx:vars]
    has_java = True # vars in child groups override same in parent

    [all:vars]
    has_java = False # 'all' is 'top' parent

example2: |
    # other example config
    host1 # this is 'ungrouped'

    # both hosts have same IP but diff ports, also 'ungrouped'
    host2 ansible_host=127.0.0.1 ansible_port=44
    host3 ansible_host=127.0.0.1 ansible_port=45

    [g1]
    host4

    [g2]
    host4 # same host as above, but member of 2 groups, will inherit vars from both
          # inventory hostnames are unique

---