Tasks are run against target servers. Some Ansible documentation refers to the target servers as "hosts".
There are a few ways to run an ansible ad hoc command or the ansible-playbook command against certain managed nodes.
- Using the hosts parameter in your playbook (ansible-playbook command only)
- Using the when parameter in your playbook (ansible-playbook command only)
- Using the -i or --inventory command line option (this article)
- Using the --limit command line option
The -i or --inventory option can be used to:
- Use a specific inventory file
- List the target systems on the command line
After a clean install of Ansible, the "inventory" directive 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 the "inventory" directive 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'
Typically, target servers are defined in the default hosts file or your own inventory file. Sometimes, the "inventory" directive in ansible.cfg is uncommented and updated to point to the directory where the default hosts file or your own inventory file will be located.
Additionally, Ansible uses inventory plugins to parse inventory. The ansible-doc command can be used to list the inventory plugins that can be used with the version of Ansible you are using.
~]$ ansible-doc --type inventory --list
ansible.builtin.advanced_host_list Parses a 'host list' with ranges
ansible.builtin.auto Loads and executes an inventory plugin specified in a YAML config
ansible.builtin.constructed Uses Jinja2 to construct vars and groups based on existing inventory
ansible.builtin.generator Uses Jinja2 to construct hosts and groups from patterns
ansible.builtin.host_list Parses a 'host list' string
ansible.builtin.ini Uses an Ansible INI file as inventory source
ansible.builtin.script Executes an inventory script that returns JSON
ansible.builtin.toml Uses a specific TOML file as an inventory source
ansible.builtin.yaml Uses a specific YAML file as an inventory source
For example, ansible.cfg may have the following.
[inventory]
enable_plugins = ansible.builtin.host_list, ansible.builtin.yaml, ansible.builtin.ini
In this scenario, the hosts_lists inventory plugin allows you to pass one or more target servers on the command line using the -i or --inventory option.
AVOID TROUBLE
When the -i or --inventory option only contains one target system, you MUST INCLUDE A TRAILING COMMA after the hostname or IP address of the target system.
In this example, the example.yml playbook would only be run against server1.example.com.
ansible-playbook example.yml --inventory server1.example.com,
Here is how to do the same using the ansible ad hoc command.
ansible --inventory server1.example.com, --module-name ping
And here is how to run a playbook or ad hoc command against two (or more) managed hosts. When you have two (or more) hosts, you do not need to end with a trailing comma.
ansible-playbook example.yml --inventory server1.example.com,server2.example.com
The yaml inventory_plugin allows you to define target servers in a YAML default hosts file or your own inventory file. For example, let's say you have an default hosts file or your own inventory file named inventory.yml that contains target systems, perhaps something like this.
all:
hosts:
server1.example.com:
server2.example.com:
server3.example.com:
server4.example.com:
Here is how you can run the example.yml playbook using the target systems specified in inventory.yml.
ansible-playbook example.yml --inventory /path/to/inventory.yml
Did you find this article helpful?
If so, consider buying me a coffee over at