Ansible Inventory Generator

Ansible inventory generator - host groups, variables and parent groups

The Ansible inventory generator builds an inventory.ini file: a group header [webservers], the list of hosts, a group variables section [group:vars] and a parent groups section [group:children]. Type a group name, paste your hosts (one per line), add variables and copy the finished inventory. This is the file Ansible reads through -i inventory.ini to know which machines a playbook should run on.

What this tool actually produces

The group name goes into the [group] header and is validated against [A-Za-z0-9_-]+, because a space or bracket would break the INI parser. Every line of the hosts field is trimmed and placed under the group header - repeated lines are merged. Group variables get a [group:vars] section, and child groups land in [group:children]. Empty sections are skipped, so the file holds only what you entered.

You describe a host by a name plus optional connection variables on the same line, for example web1.example.com ansible_host=10.0.0.11. The ansible_host key sets the address Ansible actually connects to when the host name is only a label. You can also add ansible_user (the SSH user), ansible_port (a port other than 22) or ansible_python_interpreter.

Anatomy of an INI inventory file

Groups, group variables and parent groups

A group is a named set of hosts a playbook treats the same way - webservers, databases, loadbalancers. The [group:vars] section sets variables once for the whole group instead of repeating them on every host: a shared user, a port, the interpreter path. The [group:children] section builds a hierarchy - a production group can contain webservers and databases, so a single command runs a task across the whole environment. Hosts and variables inherit down the tree, and a value from a narrower group wins over a wider one.

INI versus YAML - two formats for the same inventory

Ansible reads an inventory in two formats. INI, which this tool generates, is compact: headers in square brackets, one host per line. YAML records the same structure through nesting (all:, children:, hosts:, vars:) and copes better with complex variables, lists and dictionaries. For most environments INI is enough. When variables grow numerous, consider YAML or move them into group_vars/ and host_vars/ directories that Ansible loads next to the inventory.

Static versus dynamic inventory

The file from this generator is a static inventory - a host list written by hand. It works when the machines are fixed and you know their addresses. In the cloud, where servers appear and disappear, you use a dynamic inventory: plugins (such as amazon.aws.aws_ec2) query the provider's API and build the host list on the fly.

How to use the generator

1. Type a group name, for example webservers - it goes into the [webservers] header.
2. Paste your hosts, one per line, with an optional ansible_host=IP on each.
3. Add group variables (ansible_user, ansible_port) - they appear in [group:vars].
4. Optionally list child groups to build a parent [group:children] group.
5. Click Generate inventory and save the result as inventory.ini.

An inventory is one piece of an automation toolkit. The playbook that uses it you assemble in the Ansible playbook generator, and check its syntax in the YAML validator. When you move applications to containers, the Dockerfile generator and the Kubernetes deployment generator help, while recurring jobs belong in the crontab generator.

What this tool does not do

The generator builds one group at a time in INI format. Multiple groups in one file, group_vars/ and host_vars/ directories, host ranges like web[01:10] or a YAML inventory you add by hand to the skeleton. It also does not connect to hosts or check availability - that is the job of ansible ... -m ping.

Frequently asked questions