← Back to list

From Zero to Automated: Defining a Static Inventory

Now that we can write a playbook that prints “Hello World,” we should probably learn how to start targeting real devices to do something a…

Michael Hagans · 2026-04-23 02:47 · 0 claps · 2.8 min read
#ansible-tutorial #networking #automation #ansible-inventory
Open on Medium ↗
Wiki topics: CRY · Crypto & Web3 ☁️ · DevOps & Cloud

From Zero to Automated: Defining a Static Inventory

Now that we can write a playbook that prints “Hello World,” we should probably learn how to start targeting real devices to do something a little more useful. To do that, we need to tell Ansible where to find them — and that’s where the inventory comes in.

What is an Inventory?

An inventory is a file that lists your hosts (devices) and organizes them into groups. You can categorize them by location, role, etc. When you run a playbook, Ansible reads the inventory to know what to connect to and how.

INI vs YAML Format

Ansible supports two inventory formats:

INI Format (simple, flat):

fw-01 ansible_host=10.0.1.1

[firewalls]
fw-01

YAML Format (structured, nested):

all:
  children:
    firewalls:
      hosts:
        fw-01:
          ansible_host: 10.0.1.1
    aci:
      hosts:
        aci-01:
          ansible_host: 10.10.1.1

Both work. I prefer INI because:

  • It’s easier to read at a glance

  • Works well when you separate inventories by device type

  • Less indentation headaches

Organizing Inventory by Device Type

For large environments, I recommend separating inventory into folders by device type:

inventory/
├── switches/
│ └── hosts
├── firewalls/
│ └── hosts
└── aci/
  └── hosts

Why?

  • Each team can own their inventory

  • Easy to target specific device types

  • Scales better than one massive file

Hosts and Groups

Let’s create a simple firewall inventory.

inventory/firewalls/hosts:

# Define hosts with their IP addresses
fw-edge-01 ansible_host=10.0.1.1
fw-edge-02 ansible_host=10.0.1.2
fw-core-01 ansible_host=10.0.1.10
fw-core-02 ansible_host=10.0.1.11

# Group all firewalls together
[firewalls]
fw-edge-01
fw-edge-02
fw-core-01
fw-core-02

# Group by role
[edge]
fw-edge-01
fw-edge-02

[core]
fw-core-01
fw-core-02

# Group by location
[dc1]
fw-edge-01
fw-core-01

[dc2]
fw-edge-02
fw-core-02

Now you can target devices by:

  • All firewalls[firewalls]

  • Just edge[edge]

  • Just DC1[dc1]

  • Just one or two hostsfw-edge-01, ‘fw-core-01’

Using Groups in a Playbook

In your playbook, the hosts parameter tells Ansible which group to target:

---
- name: Backup firewall configs
  hosts: firewalls
  gather_facts: no

  tasks:
    - name: Get running config
      cisco.asa.asa_command:
        commands:
          - show running-config
      register: config

This runs against all hosts in the [firewalls] group. But you can also limit the scope to a group of one or more hosts within that group using the limit argument, more on that below.

To target a specific group:

---
- name: Backup edge firewalls only
  hosts: edge
  gather_facts: no

  tasks:
    - name: Get running config
      cisco.asa.asa_command:
        commands:
          - show running-config
      register: config

Using — limit to Target One or more Hosts

You may not want to make changes or run a show command on all firewalls or even all hosts in a group. To do this Use — limit:

# Run against all firewalls
ansible-playbook backup.yml -i inventory/firewalls/

# Run against only fw-edge-01
ansible-playbook backup.yml -i inventory/firewalls/ --limit fw-edge-01

# Run against only a set of hosts
ansible-playbook backup.yml -i inventory/firewalls/ --limit "fw-edge-01, fw-core-01"

# Run against only edge firewalls
ansible-playbook backup.yml -i inventory/firewalls/ --limit edge

# Run against DC1 devices only
ansible-playbook backup.yml -i inventory/firewalls/ --limit dc1

This is useful for:

  • Testing changes on one or two devices first

  • Troubleshooting a specific host

  • Rolling out changes in batches

But wait… this is a lot of typing.

You’re probably thinking — do I really have to type out every single device? For a small lab, sure. But for hundreds or thousands of devices? No way.

That’s where dynamic inventory comes in. Instead of maintaining static files, you can pull inventory automatically from a source of truth — like NetBox, a CMDB, or a simple API.

We’ll cover dynamic inventory in a future tutorial.

What’s Next?

In the next tutorial, we’ll cover group_vars — how to set connection settings (credentials, network OS, etc.) per device type so you don’t repeat yourself in every playbook.

Learn More

For the full details on inventory, check out the official Ansible documentation:

-Ansible limits

Tutorial by Michael Hagans | Medium | LinkedIn


메타데이터
post_id
41e4decde92f
slug
mastering-automation-with-ansible-defining-a-static-inventory-41e4decde92f
url
https://medium.com/@mhagans/mastering-automation-with-ansible-defining-a-static-inventory-41e4decde92f
canonical_url
https://medium.com/@mhagans/mastering-automation-with-ansible-defining-a-static-inventory-41e4decde92f
author_url
https://medium.com/@mhagans
status
ok
fetched_at
2026-06-09 15:37:30