Taking Inventory of Infrastructure with Ansible: A Practical Guide

Before you automate anything with Ansible, you need a clear answer to a simple question: what exactly are you managing? That’s where inventory comes in.

Ansible inventory is more than just a list of servers. It’s the backbone of your automation strategy—defining environments, grouping systems, and attaching variables that drive behavior. Get this wrong, and your playbooks become fragile. Get it right, and everything else feels predictable.

Starting with the simplest form

The most basic inventory is just a file listing hosts. It often looks like this:

1[web]
2web-1.example.com
3web-2.example.com
4
5[db]
6db-1.example.com
7

At first glance, it feels almost too simple. But even here, you're already doing two important things:

• Defining groups (web, db)
• Creating a logical structure Ansible can target

You can now run commands like:

1ansible web -m ping

And just like that, you’re targeting a subset of your infrastructure.

Adding context with variables

Inventory becomes far more powerful when you attach variables. For example:

1[web]
2web-1.example.com ansible_user=ubuntu
3web-2.example.com ansible_user=ubuntu
4
5[db]
6db-1.example.com ansible_user=postgres

Now Ansible knows how to connect to each system without hardcoding that logic into playbooks.

Here’s where things get interesting: variables can also be applied at the group level.

1[web:vars]
2ansible_port=22
3nginx_worker_processes=4

This keeps your playbooks clean and your infrastructure definitions centralized.

Organizing inventory like a real system

Flat files work for small setups, but they don’t scale well. A more realistic approach is splitting inventory into directories.

1inventory/
2  production/
3    hosts.yml
4    group_vars/
5    host_vars/
6  staging/
7    hosts.yml
8

This structure allows you to isolate environments while reusing patterns.

A sample YAML-based inventory might look like:

1all:
2  children:
3    web:
4      hosts:
5        web-1.example.com:
6        web-2.example.com:
7    db:
8      hosts:
9        db-1.example.com:
10

YAML inventories are easier to extend and read, especially when nesting groups or defining complex variables.

Grouping strategies that actually help

A common mistake developers make is grouping only by role (web, db). That’s useful, but incomplete.

Consider grouping by multiple dimensions:

• Environment: production, staging, dev
• Region: us-east, eu-west
• Application: payments, auth

Ansible supports overlapping groups, so a host can belong to several categories at once. This flexibility is key when your infrastructure grows.

Dynamic inventory: when static files break down

Static inventories don’t work well in cloud environments where instances are constantly created and destroyed.

This is where dynamic inventory comes in.

Instead of maintaining host lists manually, Ansible can query cloud providers like AWS, Azure, or GCP.

Example using AWS EC2 plugin:

1plugin: amazon.aws.aws_ec2
2regions:
3  - us-east-1
4filters:
5  tag:Environment: production
6keyed_groups:
7  - key: tags.Role
8    prefix: role

Now your inventory updates automatically based on tags.

Run this command to see what Ansible discovers:

1ansible-inventory -i aws_ec2.yml --list

No more outdated host lists. No more manual edits.

Why dynamic inventory changes how you think

With dynamic inventory:

• Infrastructure becomes data-driven
• Tags and metadata define behavior
• Scaling doesn’t require inventory updates

This aligns much better with modern DevOps practices.

Mixing static and dynamic approaches

You don’t have to choose one or the other.

A common pattern is:

• Use dynamic inventory for cloud resources
• Keep static inventory for edge cases (legacy servers, local VMs)

Ansible allows multiple inventory sources:

1ansible-playbook -i inventory/production -i aws_ec2.yml site.yml

This hybrid approach gives you flexibility without sacrificing control.

Debugging your inventory

When things don’t behave as expected, the inventory is often the culprit.

Use these commands to inspect it:

1ansible-inventory --list
2ansible-inventory --graph
3

The graph view is especially helpful for visualizing group relationships.

If variables seem off, check precedence rules—Ansible merges variables from multiple sources, and the final value may not come from where you think.

A few practical habits that pay off

• Name groups consistently — avoid mixing naming conventions
• Keep secrets out of inventory — use Ansible Vault instead
• Prefer group variables over host variables when possible
• Document unusual group logic — future you will thank you

Also, treat your inventory like code. Version it, review changes, and test it.

Wrapping it up

Ansible inventory isn’t just a prerequisite—it’s a design decision. Whether you stick with a simple hosts file or build a dynamic system driven by cloud metadata, the goal is the same: make your infrastructure predictable and queryable.

Once your inventory is clean and expressive, your playbooks become smaller, clearer, and easier to maintain. And that’s when Ansible really starts to feel powerful.