Tasks are run against managed nodes, also known as hosts.
After a clean install of Ansible, inventory in ansible.cfg is commented out, like this.
#inventory = /path/to/hosts
In this scenario, the default hosts file is /etc/ansible/hosts, and the default hosts file is completely commented out. If you were to issue command ansible all -m ping, the following would be displayed. Likewise, if you were to uncomment inventory in ansible.cfg without defining your inventory, the following would be displayed.
[WARNING]: provided hosts list is empty, only localhost is available. Note that the implicit localhost does not match 'all'
AVOID TROUBLE
Ofthen a static inventory file, such as the default hosts file or your own inventory file is used before setting up dynamic inventory. After setting up dynamic inventory, you'll use commands such as ansible all --lists-hosts, ansible-inventory --list, or ansible-inventory --graph to determine if hosts are being defined dynamically. You will probably want to back up and then remove the default hosts file to ensure that the hosts are not being obtained from the default hosts file.
By default, enable_plugins in /etc/ansible/ansible.cfg is commented out, like this.
[inventory]
# enable inventory plugins, default: 'host_list', 'script', 'yaml', 'ini'
#enable_plugins = host_list, virtualbox, yaml, constructed
To use inventory plugins, you will uncomment enable_plugins, and list (in order of precedence) the plugins you will be using. As the comment suggest, you will almost always want to enable the host_list, ini, and yaml inventory plugins, so that static inventory can still be used (more on that in a moment, read on). The use of script is discouraged, as dynamic inventory plugins have superceded inventory scripts.
[inventory]
# enable inventory plugins, default: 'host_list', 'script', 'yaml', 'ini'
enable_plugins = ansible.builtin.host_list, ansible.builtin.yaml, ansible.builtin.ini
The plugins that can be used will be found at /usr/lib/python<version>/site-packages/ansible/plugins/inventory.
advanced_host_list.py
constructed.py
host_list.py
ini.py
openstack.py
script.py
virtualbox.py
yaml.py
Likewise, the ansible-doc command can be used to gather more information on the plugins found at /usr/lib/python<version>/site-packages/ansible/plugins/inventory.
ansible-doc --type inventory --list
advanced_host_list Parses a 'host list' with ranges
constructed Uses Jinja2 to construct vars and groups based on existing inventory.
host_list Parses a 'host list' string
ini Uses an Ansible INI file as inventory source.
openstack OpenStack inventory source
script Executes an inventory script that returns JSON
virtualbox virtualbox inventory source
yaml Uses a specifically YAML file as inventory source.
Let's say you want to learn about "host_list". The -s or --snippet option can be used.
ansible-doc --type inventory --snippet host_list
In this example, you would create a YAML file. The filename can be anything, but must have the .yml or .yaml extension.
touch inventory_plugin.yml
In the newly created file, you will add plugin: plugin_name. Here are a few examples.
plugin: virtualbox
plugin: vmware_vm_inventory
plugin: aws_ec2
Probably the easist of these to demonstrate is the yaml plugin. Let's say inventory.yaml contains the following.
all:
hosts:
server1.example.com:
server2.example.com:
children:
linux:
hosts:
server3.example.com:
server4.example.com:
windows:
hosts:
server5.example.com:
server6.example.com:
Let's say dynamic_inventory.yml contains the following.
plugin: yaml
The ansible command with the --list-hosts flag can be used to determine if things are working as expected.
ansible all -i /path/to/inventory/file --list-hosts
Or, the ansible-inventory command with the --list . . .
ansible-inventory -i /path/to/inventory/file --list
. . . or --graph option could be used as well.
ansible-inventory -i /path/to/inventory/file --graph
Did you find this article helpful?
If so, consider buying me a coffee over at