Tasks are run against target servers. Some Ansible documentation refers to the target servers as "hosts".

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

For example, 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 a 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:

The all group contains every server. For example, the following command will be performed against all of the hosts in the default hosts file or your own inventory file.

ansible all -m ping

Similarly, if you have a playbook with hosts: all the play will be performed against all.

---
- hosts: all
  tasks:
  file:
    path: /tmp/example.txt
    state: touch
...

Let's say you have the following. In this example, server7.example.com would be considered ungrouped because servers that are only in the "all" group and not in any other group are considered ungrouped.

linux:
  hosts:
    server1.example.com:
    server2.example.com:
    server3.example.com:
windows:
  hosts:
    server4.example.com:
    server5.example.com:
    server6.example.com:
all:
  hosts:
    server7.example.com:

The following command will be performed against the ungrouped nodes.

ansible ungrouped -m ping

Or like this, using hosts: ungrouped.

---
- hosts: ungrouped
  tasks:
  file:
    path: /tmp/example.txt
    state: touch
...

Since there are two groups in this example, "linux" and "windows", you could use "linux" or "windows" with the ansible ad-hoc command.

ansible linux -m ping

Or like this, in a playbook.

---
- hosts: linux
  tasks:
  file:
    path: /tmp/example.txt
    state: touch
...

servers in multiple groups

A managed node can be in more than one group. In this example, server3.example.com is in both the "linux" and "test" group.

linux:
  hosts:
    server1.example.com:
    server2.example.com:
    server3.example.com:
windows:
  hosts:
    server4.example.com:
    server5.example.com:
    server6.example.com:
test:
  hosts:
    server3.example.com:

Group of groups

Let's say you have a group of web servers and database servers and file servers. Sometimes, you may want to run a task against both the web servers and database servers, but not the file servers. In this example, a group called "web" contains the web servers and database servers, but not the file servers.

webservers:
  hosts:
    server1.example.com:
    server2.example.com:
dbservers:
  hosts:
    server3.example.com:
    server4.example.com:
fileservers:
  hosts:
    server5.example.com:
    server6.example.com:
web:
  children:
    webservers:
    dbservers:

Regular Expression / Ranges

To simplify your list of nodes, ranges can be used, like this.

linux:
  hosts:
    server[1:3].example.com:
windows:
  hosts:
    server[4:6].example.com:
test:
  hosts:
    server3.example.com: