Ansible Inventory File
What is an Ansible Inventory?
The Ansible Inventory File defines all the hosts and groups of hosts that you want to automate with Ansible. Also called the Ansible Hosts File it tells Ansible about the hosts that it can connect to, you can also define custom options per host e.g. different port number or credentials
Why do we need Ansible Inventory?
The default Ansible inventory file is located in /etc/ansible/hosts. You can also create project-specific inventory files in alternate locations. The inventory file can list individual hosts or user-defined groups of hosts.

For Ansible to automate a Linux Server, Network device or Cloud server it has to exist within the inventory file (also known as the Ansible hosts file) and saved in either YAML or INI format.
The file can also be static or created dynamically by a script.
All options will be covered in this tutorial below.
Official documentation from Ansible is here:
https://docs.ansible.com/ansible/latest/user_guide/intro_inventory.html
Ansible / Hosts File Location

The default inventory file is named hosts by default and is one of the default files installed with Ansible – the other main one being ansible.cfg. If you cat the file you can see it does not contain any entries (they are all commented out) but what it does do is give you a template of how to start formatting your inventory file.
Can we have multiple inventories in Ansible?
You can define as many different Ansible inventories as you want and then reference as many as you like during a playbook run. I personally create a folder per project and define the inventory for all the devices in the specific project in there, however if you also want to reference other devices, you can easily add in multiple inventories.
Ansible Inventory Example
The Ansible hosts file is written in either YAML or INI format. The most common format is INI. Check the ansible/hosts file examples below.
Devices or hosts or nodes are referenced by their DNS name, hostname or with the ansible inventory ip address variable.
host1.domain.com
192.168.1.193
[routers]
router1.domain.com
router2.domain.com
CSR-1 ansible_host=192.168.1.199
[switches]
switch1.domain.com
switch2.domain.com
Ansible’s inventory is very easy to read and understand.
Hosts can be defined either by IP address or DNS name or if DNS is not resolvable using the ansible_host command syntax.
In the example above the display name is CSR-1 and the ansible host command specifies the IP address as 192.168.1.199
Hosts can also grouped together by putting under groups named by a name in square brackets e.g. [Routers]
[database servers]
[webservers group]
Multiple servers or network devices can be referenced in a playbook by referencing the group name.
The file can live anywhere but it’s a best practice to put it in the same directory as your project files.
Ansible commands like ansible and ansible-console will only look in group_vars and host_vars in the inventory directory.
Adding variables to inventory
You can also add variable values to a specific host or hosts in your inventory
[LondonDC]
LB1 http_port=8089
LB2 http_port=8090
For more details on this and many other parts of the inventory file, check out my course.
What I suggest is to delete the default hosts file and create a new inventory file.
I personally create a custom inventory file within each project folder I create, I also then create a custom ansbile.cfg file within that same folder that references your custom host file..
At any time I have multiple ansible inventories on my machine but there is only ever one per project (in a specific folder) if you do want to change devices you automate you can easily create another file and just reference it in the ansible.cfg file as shown below.
#Custom ansible.cfg file
[defaults]
inventory=./hosts
The Ansible inventory file name can be anything you want as long as you reference it in the ansible.cfg file. I always use hosts for simplicity.
You can also specify an inventory to use during a playbook run using the ansible playbook inventory command as below
ansible playbook -i <path to inventory>
ansible-playbook -i ./project1/inventory.yml
Ansible-Inventory Command
To show the current Ansible Inventory you can run the Ansible-Inventory Command as below
ansible-inventory --list
This command will list all hosts in the Ansible Inventory
Ansible Inventory Groups

Looking at the hosts file above you can see we have two groups of devices configured, CSR-Routers and SWITCHES. Each group contains some devices and in this instance the devices are defined by name and then the IP address is defined manually using the ansible_host= command.
The name CSR-1 or 2 or 3 is then what shows up when you run the playbook.
You can have multiple inventories and specify to use each inventory at the playbook runtime.
Simply create another inventory file i.e hosts-2 and at playbook runtime use the -i flag to tell Ansible to use that inventory e.g
ansible-playbook backup-router.yml -i hosts-2
You can also locate these inventory files anywhere on your device, in this example the inventory file is located in the same folder as the playbook.

In the example above CSR-1 is defined without the ansible_host command. This name must be resolvable in DNS or via a local hosts file on the Ansible control node.
The other entry is just an IP address, this will work, but when the playbook runs you will just see the IP address as the device being targeted.
An SSH connection is made to the IP address defined in the file. Other variables such as passwords or specific ports or specific connection parameters can also be defined in this file.
You can also add group variables into the file, but these are best put in a more secure place. Also connection variables can also be used, but these are also best saved in group_vars or host_vars files.
(Also called group variables and host variables)
You can put each host in more than one group. For example a production router in a datacenter in London might be included in groups called [production] and [routers]

Ansible Inventory YAML
The hosts file above is written in the default INI format, an Ansible YAML Inventory is show below

In the above example we have the same inventory file but in a YAML format.
Ansible Inventory File Groups
To make managing your hosts easier you can put them into groups within your inventory file. e.g
[CSR-Routers]
CSR-1
CSR-2
CSR-3
[Switches]
SW1-3560
SW2-3850
[LAB:children]
CSR-Routers
Switches
In the above example you can see I have grouped the devies into two groups denoted with square brackets. I can now address our Ansible Playbooks to the group CSR-Routers and it will will only affect the devices in that group.
If I want to address all the devices in the inventory file, we make use of the children function, as you can see above I have created a group called LAB and it has children which are the two other groups.
Now if I address a Playbook to run against LAB it will affect all devices in this inventory.
Best Practices
- Keep your hosts file names simple – I always use hosts
- Comment were required to ensure someone else can understand your inventory
- Use children to address multiple groups at once
- Do no put passwords in your inventory file – reference them in group_vars or host_vars or even better use Ansible vault within those files.
For more information check this post – What are Ansible host_vars and group_vars?
Can Ansible have multiple inventory files?
Whilst the default hosts file resides in /etc/hosts a best practice is to create a custom inventory/hosts file within your project folder, so you basically have a hosts file per project. This depends on your use case but for myself as a consultant and working in different environments this is what I do.
What is a Dynamic Inventory in Ansible?
For small environments, a static inventory file is sufficient as there are typically not rapid changes to the devices in use.
If you are working within a cloud environment or one where multiple hosts are being spun up and tore down regularly your Ansible Inventory file will become very difficult to manage. Most cloud providers will provide you a script you can use within Ansible to regularly poll your devices and import the inventory, this is referred to as an Ansible dynamic inventory.
Dynamic inventory is a powerful feature that adjusts to the ever-changing landscape of managed nodes in computing environments. Especially for large organizations and those leveraging cloud services, static lists of nodes simply can’t keep up. That’s where the strength of dynamic inventory shines.
Dynamic inventory, instead of being a manually curated document of your nodes, is a system that dynamically pulls the node list from a source as required. This source can be almost anything, including cloud services, databases, or other types of servers. The dynamic nature of this system provides far more flexibility and scalability compared to its static counterpart.
For instance, let’s say you have a cluster of servers on a cloud service that regularly scales up and down based on traffic patterns. With a static approach, you would need to continually update your list of nodes to match the current state of your infrastructure. With dynamic inventory, however, your node list is always up-to-date. Whenever a new server spins up, it automatically becomes part of the managed nodes.
Additionally, dynamic inventory isn’t just about scaling. It also allows for real-time configuration updates. If you need to change a particular setting across all of your servers, dynamic inventory ensures this change is propagated immediately. It also guarantees that any new nodes that come online will receive this configuration.
There are numerous use cases where dynamic inventory makes sense. One of the most common is within a large enterprise setting. In these environments, there are likely to be many different servers, databases, and services, each with their unique configuration. Trying to manage all of these with a static inventory would be nearly impossible.
Another use case is within a managed service provider (MSP). MSPs need to manage multiple customers, each with their distinct environments and configurations. With dynamic inventory, an MSP can maintain a high level of service without getting overwhelmed by the sheer volume of nodes.
Similarly, companies that leverage microservices could benefit greatly from dynamic inventory. Microservices architecture often involves numerous small, specialized services running in tandem. Keeping track of each service, especially when they’re continually being scaled and updated, is much easier with dynamic inventory.
Moreover, dynamic inventory plays a crucial role in managing containerized applications. In these environments, containers are regularly created and destroyed. Having a system that can automatically recognize and manage these containers can be a huge asset.
One last consideration is the overall efficiency. With dynamic inventory, tasks like configuration updates, scaling, and management become automated. This significantly reduces the overhead and the chance of human error, allowing for more efficient operations.
In conclusion, dynamic inventory represents a significant advancement in node management. It provides much-needed flexibility, scalability, and automation, making it an invaluable tool in a wide range of situations.
What is the difference between Ansible Inventory and Playbook?
The Ansible Inventory File defines the hosts and groups of devices that you want to perform automation on. Your Ansible Playbooks perform tasks against the hosts and devices that are defined in the Ansible Inventory File.
Ansible Hosts File Comments
If you want to put a comment next to any item in your Ansible Hosts file just start a new line with a #
Ansible is a powerful open-source tool for automation that enables software provisioning, configuration management, and application deployment. At the heart of Ansible’s functionality lies the “inventory file”, a cornerstone component that allows Ansible to interact with hosts (the machines you want to manage).
The inventory file is essentially a list of nodes, often represented as IP addresses, domain names, or hostnames, that Ansible will manage. It is, in its simplest form, a text file that serves as a map for Ansible to understand the infrastructure it manages. The default location for an inventory file in an Ansible setup is “/etc/ansible/hosts”, but users can create custom inventory files and reference them in commands using the “-i” flag.
Beyond listing hosts, the inventory file allows for the grouping of hosts into logical units. These groups can be arranged to reflect the infrastructure’s architecture or other desired organizational patterns. For example, you might have groups named “webserver”, “database”, or “testing” – and each group contains the hosts associated with that specific function. This feature is useful when running playbook tasks selectively on specific groups of servers, enhancing the efficiency and flexibility of management tasks.
Moreover, inventory files support the concept of hierarchical grouping, enabling users to create parent-child relationships between groups. You could, for instance, have a “webservers” group and a “dbservers” group nested within a parent “production” group. Ansible allows operations to be performed at any level of this hierarchy, offering granular control over task execution.
Inventory files also allow the assignment of variables. These variables can be used to override default variables or to supply required values to your Ansible playbook. Variables can be assigned to individual hosts or entire groups. This feature can be leveraged to define specific configurations for each host or group of hosts.
There are two formats that an Ansible inventory file can be written in: INI and YAML. The INI format is simpler and tends to be more common, but the YAML format can provide a more human-readable and organized structure, especially for complex inventories.
In recent versions of Ansible, a feature called “Dynamic Inventory” has been introduced. This allows the inventory to be fetched dynamically from external systems, including cloud providers like AWS, Google Cloud, or Azure. This is particularly beneficial for organizations managing volatile, cloud-based infrastructure, where static lists of hosts quickly become outdated.
In conclusion, the Ansible inventory file is a crucial component of any Ansible setup. It serves as a roadmap for Ansible, defining what hosts to connect to, how they are grouped, and what variables are associated with them. It provides the necessary flexibility and granularity to manage infrastructure efficiently, making Ansible a highly capable tool for infrastructure management.
For more information you can reference the Ansible Best Practice guide on the Ansible Documentation site here: https://docs.ansible.com/ansible/latest/user_guide/playbooks_best_practices.html
Ansible is the most popular tool for Network Automation right now, mainly because of it simplicity to get started. You can be up and running in a few hours.
If you want a hand to get started I have a course which takes you from installation to running your first production ready playbooks.

Frequently Asked Questions
What is the Ansible hosts file?
The Ansible hosts file is a file which lists all the hosts that you want to connect to. Hosts can grouped into groups and also put into a super-set with the the :children operator.
Where is the Ansible Hosts file?
By default the Ansible Hosts file is located in /etc/ansible/hosts but you can create a custom hosts file and put it wherever you want and then specify it’s location using a custom ansible.cfg
What are the different types of inventories in Ansible?
There are two types of inventory you can use within Ansible. Also there are two file types.
The Ansible Hosts file can be static or dynamic and can be in an ini format or YAML.
How do I create an Ansible hosts file?
You can create an inventory hosts in Ansible anywhere you like. It is just a text file which by default is called hosts and located in /etc/ansible/ but you can create the file wherever you like and just tell Ansible where it is when you run the playbook either with the -i switch or by defining it in the ansible.cfg file.
Is Ansible inventory case sensitive?
The group names in the Ansible inventory are case sensitive so [Servers] is a different group name to [servers]
What is the difference between the hosts file and an inventory file in Ansible?
They are the same file used to define hosts that you want to automate with Ansible. The hosts file is the default name created when you install Ansible and is located in /etc/ansible/hosts You can create multiple inventory files and call them what you want as long as you reference them in the ansible.cfg file
Where is inventory file located by default?
After installation of Ansible the inventory file is located in /etc/ansible/hosts
How do I change the default inventory file in Ansible?
The default inventory file is located in /etc/ansible/hosts You can make Ansible use a different file by specifying a different inventory file using the -i <path> option on the command line when running a playbook, or by creating another inventory file and specifying it’s location in the ansible.cfg file
Where is Ansible Inventory stored?
By default the Ansible Inventory is stored in /etc/ansible/hosts but you can save your inventory anywhere you like.
How do I know if my host is reachable in Ansible?
You can use the Ansible ping module to check successful ssh connectivity to target devices – use the command ansible all -m ping -v
What is an Ansible Inventory File?
The Ansible Inventory File defines the hosts and groups of devices that you want to perform automation on. Your Ansible Playbooks perform tasks against the hosts and devices that are defined in the Ansible Inventory File.
What are the types of inventory in Ansible?
There a two types of inventory in Ansible, Static and Dynamic. Both files can be defined in INI or YAML format. The static file is defined manually and the dynamic file is updated via a script and is used for environments where hosts are changing e.g. in a cloud environment.
What is the Ansible command to list inventory?
The Ansible command to list inventory is ansible-inventory –list
Ansible Inventory Types
In which two file types can the Ansible inventory file be represented?
The Ansible inventory file can be represented in two types, INI and YMAL. The INI file format is a simple human readable format, it allows the definition of hosts and groups in a clear and organised manner. YAML is another human-readable data serialisation standard, It allows for more complex configurations and is recommended for more advanced use cases.
Ansible Inventories
Quick facts
- Ansible inventory is a file used to store information about the hosts in your infrastructure
- This file can be in one of many formats, including INI, YAML, and JSON
- Ansible will automatically search for this file in several locations, including the current working directory, ~/.ansible/hosts, and /etc/ansible/hosts
- You can specify a different inventory file using the -i /path/to/file option
- The inventory file can contain groups of hosts and variables associated with those groups
- Groups can be nested inside of other groups
- You can use the special all group to refer to all hosts in your inventory
- Variables can be defined at the group or host level and are inherited by child groups and hosts
- You can use the ansible-inventory command to view and manipulate your inventory file
Statistics
- Ansible inventory is a file that contains a list of hosts that Ansible can manage.
- The inventory file can be in one of two formats: INI or YAML.
- The default location for the inventory file is /etc/ansible/hosts.
- Ansible inventory can also be specified as a comma-separated list of hosts on the command line.
- Ansible inventory can be dynamically generated from a variety of sources, such as cloud providers, CMDBs, and monitoring systems.
- Ansible inventory can be used to group hosts into logical groups, such as “webservers” or “databases”.
- Ansible inventory can also be used to specify variables that should be applied to all hosts in a group.
- Ansible inventory can be used to specify connection information, such as SSH user and private key.
Other Ansible Resources
I hope you found this short tutorial informative and if you want to keep learning check out these other Ansible posts
- Ansible Backup Cisco Tutorial – this posts covers a step by step guide to installing Ansible and creating your first playbook to backup a Cisco router config.
- What is Ansible used for? – this post covers the very basics of Ansible, what it is and what it can do?
- Open Source Network Automation Tools – My Top 7 List – This post discusses some of the most popular network automation tools in use today.
- Ansible Vault Best Practices – this post covers how to encrypt your passwords and sensitive information using Ansible Vault
- Ansible Training Course – this is my flagship course covering all aspects of using Ansible also covering Network Automation
- Ansible vs Python – Which one should you learn?
- Cisco Switch IOS Upgrade using Ansible
- How to install Ansible Tower
- What are the advantages of using Ansible Roles
- Ansible IOS Command Example
- Ansible Tutorial for Network Engineers
Table of Contents
More Info
inventory ansible documentation |
topics |
to track |
at what |
products |
documentation ansible |
strategies |
behavioral inventory parameters |
selected |
multiple inventory |
atlanta |
asked questions |
next copyright |
previous next copyright |
how variables |
previous next |
webinars |
bsd |
end |
appendices |
community webinars |
products community |
training blog documentation |
training blog |
ansiblefest products community |
ansiblefest products |
products community webinars |
last updated |
ansiblefest |
consuming |
automation hub |
inclusive |
track |
inventory directory |
porting guides |
ansible documentation ansiblefest |
documentation ansiblefest |
3 support |
developer guide |
variables set |
glossary |
locations |
datacenter |
multiple inventory sources |
configuration settings |
sets |
previous |
yaml syntax |
special variables |
ansible tips |
frequently |
ansible getting |
ansible getting started |
utilities |
guide ansible |
formatted |
feb |
tricks |
host alias |
keywords |
patterns |
extension |
controlling |
inventory sources |
developer |
plugin |
data |
extensions |
host and group |
playbooks |
maintenance |
not use |
vault using |
on windows |
using ansible collections |
network developer |
guides network automation |
network getting |
ansible documentation style |
ansible scenarios legacy |
guide advanced |
vault using ansible |
copyright ansible |
plugins playbook |
scenarios legacy |
search docs |
core roadmaps ansible |
plugins playbook keywords |
ansible building ansible |
core contributors guide |
ansible collections using |
guide ansible collections |
protecting sensitive |
releases and maintenance |
ansible project contributors |
network advanced topics |
network developer guide |
ansible automation hub |
windows and bsd |
copyright ansible project |
9 select |
building ansible inventories |
devel search docs |
network getting started |
playbooks protecting |
playbooks protecting sensitive |
on feb |
advanced contributor guide |
collections using |
core roadmaps |
contributor guide ansible |
advanced topics |
project contributors |
collections contributor |
started getting |
protecting sensitive data |
core contributors |
9 devel |
collection index |
platform ansible |
to inventory |
module utilities |
guide extending ansible |
roadmaps |
sanity |
strategies sanity |
questions glossary ansible |
testing strategies sanity |
values ansible |
tests frequently asked |
configuration installation |
tests frequently |
ansible roadmap |
return values ansible |
maintenance testing |
upgrade and configuration |
roadmaps ansible roadmap |
ansible ansible community |
module utilities special |
porting guides using |
advanced |
merged |
command line tools |
line tools |
roadmap |
groups connection methods |
child groups |
ansible documentation |
group names |
using inventory |
user guide galaxy |
ansible galaxy galaxy |
output roadmaps |
galaxy galaxy |
developer guide reference |
guide reference |
galaxy developer |
logging ansible |
logging ansible output |
keywords return |
overwrite |
legacy |
official |
ansible automation platform |
options |
format |
hosts can also |
user guide |
option |
on github |
network automation |
plugins using |
installation |
against |
convenient |
json |
indexes |
glossary ansible |
adding variables |
guides |
execution environments |
command line |
variables that |
channel |
build your inventory |
inventory ansible |
support |
behavioral |
behavioral inventory |
contributor guide |
extending |
ansible chat |
channels previous |
time chat how |
join ansible chat |
time chat |
channels previous next |
getting started |
paths |
properties |
per |
ansible community |
network |