ini – Uses an Ansible INI file as inventory source — Ansible Documentation

- AnsibleFest
- Products
- Community
- Webinars & Training
- Blog

Documentation

# ini – Uses an Ansible INI file as inventory source

New in version 2.4.

- Synopsis
- Notes
- Examples
- Status

## 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 (https://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

Note

- 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

## Status

- This inventory is not guaranteed to have a backwards compatible interface. [preview]
- This inventory is maintained by the Ansible Community. [community]

### Authors

- UNKNOWN

Hint

If you notice any issues in this documentation, you can edit this document to improve it.

Hint

Configuration entries for each entry type have a low to high priority order. For example, a variable that is lower in the list will override a variable that is higher up.