Whenever you see a reference to "creating an inventory" in Ansible, you are normally quite safe to assume that it is a static inventory. Ansible supports two types of inventory—static and dynamic, and we will cover the latter of these two later in this chapter. Static inventories are by their very nature static; they are unchanging unless a human being goes and manually edits them. This is great when you are starting out and testing Ansible, as it provides you with a very quick and easy way to get up and running quickly. Even in small, closed environments, static inventories are a great way to manage your environment, especially when changes to the infrastructure are infrequent.

Most Ansible installations will look for a default inventory file in /etc/ansible/hosts (though this path is configurable in the Ansible configuration file, as discussed in Chapter 2, Understanding the Fundamentals of Ansible). You are welcome to populate this file or to provide your own inventory for each playbook run, and it is commonplace to see inventories provided alongside playbooks. After all, there's rarely a "one size fits all" playbook, and although you can subdivide your inventory with groups (more on this later), it can often be just as easy to provide a smaller static inventory file alongside a given playbook. As you will have seen in the earlier chapters of this book, most Ansible commands use the -i flag to specify the location of the inventory file if not using the default. Hypothetically, this might look like the following example:

$ ansible -i /home/cloud-user/inventory all -m ping

Most static inventory files you will come across are created in INI format, though it is important to note that other formats are possible. The most common format you will find after INI-formatted files are YAML ones—more details of the types of inventory files you can work with may be found here: https://docs.ansible.com/ansible/latest/user_guide/intro_inventory.html.

In this chapter, we will provide some examples of both INI and YAML formatted inventory files for you to consider, as you must have an awareness of both. Personally, I have worked with Ansible for many years and worked with either INI-formatted files or dynamic inventories, but they say knowledge is power and so it will do no harm to learn a little about both formats.

Let's start by creating a static inventory file. This inventory file will be separate from the default inventory.

Create an inventory file in /etc/ansible/my_inventory using the following INI-formatted code:

target1.example.com ansible_host=192.168.81.142 ansible_port=3333

target2.example.com ansible_port=3333 ansible_user=danieloh

target3.example.com ansible_host=192.168.81.143 ansible_port=5555

The blank lines between inventory hosts are not required—they have been inserted simply to make the inventory more readable in this book. This inventory file is very simple and does not include any grouping; however, when referencing the inventory, you can still refer to all the hosts together using the special all group, which is implicitly defined regardless of how you format and divide your inventory file.

Each line in the preceding file contains one inventory host. The first column contains the inventory hostname that Ansible will use (and can be accessed through the inventory_hostname magic variable we discussed in Chapter 2, Understanding the Fundamentals of Ansible). All parameters on the same line after that are variables that are assigned to the host. These can be user-defined variables or special Ansible variables as we have set here.

There are many such variables, but the preceding examples specifically include the following:

• ansible_host: If the inventory hostname cannot be accessed directly—perhaps because it is not in DNS, for example, this variable contains the hostname or IP address that Ansible will connect to instead.
• ansible_port: By default, Ansible attempts all communication over port 22 for SSH—if you have an SSH daemon running on another port, you can tell Ansible about it using this variable.
• ansible_user: By default, Ansible will attempt to connect to the remote host using the current user account you are running the Ansible command from—you can override this in several ways, of which this is one.

Hence, the preceding three hosts can be summarized as follows:

• The target1.example.com host should be connected to using the 192.168.81.142 IP address, on port 3333.
• The target2.example.com host should be connected to on port 3333 also, but this time using the danieloh user rather than the account running the Ansible command.
• The target3.example.com host should be connected to using the 192.168.81.143 IP address, on port 5555.

In this way, even with no further constructs, you can begin to see the power of static INI-formatted inventories.

Now, if you wanted to create exactly the same inventory as the preceding, but this time, format it as YAML, you would specify it as follows:

---
ungrouped:
  hosts:
    target1.example.com:
      ansible_host: 192.168.81.142
      ansible_port: 3333
    target2.example.com:
      ansible_port: 3333
      ansible_user: danieloh
    target3.example.com:
      ansible_host: 192.168.81.143
      ansible_port: 5555

You may come across inventory file examples containing parameters such as ansible_ssh_port, ansible_ssh_host, and ansible_ssh_user–these variable names (and others like them) were used in Ansible versions before 2.0. Backward compatibility has been maintained for many of these, but you should update them where possible as this compatibility may be removed at some point in the future.

Now if you were to run the preceding inventory within Ansible, using a simple shell command, the result would appear as follows:

$ ansible -i /etc/ansible/my_inventory.yaml all -m shell -a 'echo hello-yaml' -f 5
target1.example.com | CHANGED | rc=0 >>
hello-yaml
target2.example.com | CHANGED | rc=0 >>
hello-yaml
target3.example.com | CHANGED | rc=0 >>
hello-yaml

That covers the basics of creating a simple static inventory file. Let's now expand upon this by adding host groups into the inventory in the next part of this chapter.