Do you think IIT Guwahati certified course can help you in your career?
Introduction
Ansible uses a list or collection of lists known as inventory to operate simultaneously against a number of managed nodes, or "hosts," in your infrastructure. Using patterns, you may choose which hosts or groups you want Ansible to execute against after defining your inventory.
This blog explains the specifics of ansible inventory as well as the specifics of adding variables, assigning variables, setting up hosts, and examples of inventory setup.
Without further ado, let's get started.
Inventory basics: formats, hosts, and groups
Depending on the inventory plugins you have, the inventory file may be in one of the various forms. The most widely used formats are YAML and INI. An example of a basic INI for /etc/ansible/hosts might be:
The group names in brackets are used to categorise hosts and determine which hosts you are in control of at what times and for what purposes. The same rules that apply to creating appropriate variable names also apply to group names.
Here is the YAML version of that same basic inventory file:
All and ungrouped are the two pre-defined groups. Each host is a member of the all group. All hosts with no other group besides all are included in the ungrouped group. Every host will consistently be a part of at least two groups . All and ungrouped can be implicit and not show up in group listings like the group_names, despite the fact that they are always present.
Hosts in multiple groups
You can (and most likely will) place each host in many groups. For instance, the groups [prod], [atlanta], and [webservers] may comprise a production webserver located in an Atlanta datacenter. You can make groups that keep tabs on:
What: A software stack, microservice, or application (for example, database servers, web servers, and so on).
Where: A datacenter or area to communicate with local DNS, storage, and other services (for example, east, west).
When - During the development stage, avoid testing on resources used for production (for example, prod, test).
Including what, when, and where items in the previous YAML inventory:
Instead of specifying each hostname individually, you can add a range of hosts if you have numerous hosts with the same pattern:
In INI:
[webservers]
www[01:50].example.com
In YAML:
...
webservers:
hosts:
www[01:50].example.com:
When specifying a numeric range of hosts, a stride (increments between sequence numbers) can be specified:
In INI:
[webservers]
www[01:50:2].example.com
In YAML:
...
webservers:
hosts:
www[01:50:2].example.com:
The subdomains www01, www03, www05,..., www49 would match in the example above but not www00, www02, www50, and so on because the stride (increment) is two units each step.
Leading zeros can be added or subtracted from numerical patterns as required. A range is inclusive. Additionally, alphabetic ranges may be defined.
[databases]
db-[a:f].example.com
Let's look at the details of adding variables to inventory.
Adding variables to inventory
Variable values related to a particular host or group can be kept in inventory. In your main inventory file's hosts and groups, you can start by adding variables directly. However, you will probably want to keep variables in separate host and group variable files as you continue to add managed nodes to your Ansible inventory.
Let's look at the details of assigning variables to the host machine.
Assigning a variable to one machine: host variables
One host can easily receive a variable that is later used in playbooks.
As host variables, unusual values like uncommon SSH ports work well. By following the hostname with a colon and the port number, you may add them to your Ansible inventory:
badwolf.example.com:5309
Host variables can likewise be used as connection variables:
Let's dive into the details of assigning a variable to many machine.
Assigning a variable to many machines: group variables
It is practical to apply variables to several hosts at once using group variables. But Ansible always flattens variables, including inventory variables, to the host level before running. Ansible reads variable values from all of the groups that a host is a member of. Ansible determines which value to use based on internal merging criteria if you provide the same variable with different values in various groups.
You can instantly apply a variable to a group of hosts if they all share the same value.
Inheriting variable values: group variables for groups of groups
There are a few characteristics of child groups to consider:
Every host who belongs to a child group is also a member of the parent group by default.
Variables in a child group will take precedence over variables in a parent group.
Multiple parents and children are possible within groups, but cyclical relationships are not.
Although hosts can belong to many groups, each host will only have one instance, combining the data from all of the groups.
Using the children: entry in YAML or the:children suffix in INI, you can create groups of groups. You can use :vars or vars: to apply variables to these groupings of groups.
Let's look at the details of Organizing host and group variables
Organizing host and group variables
Although variables can be kept in the main inventory file, keeping separate host and group variables files may make it simpler to keep track of your variable values. Variable host and group files must be formatted in YAML. There are several acceptable file extensions, including.yml,.yaml,.json and no file extension.
By looking for paths in the playbook or inventory files, Ansible loads host and group variable files. A host named "foosball" that belongs to the groups "raleigh" and "webservers" in your inventory file at /etc/ansible/hosts will use variables in the following YAML files:
/etc/ansible/group_vars/raleigh # can optionally end in '.yml', '.yaml', or '.json'
/etc/ansible/group_vars/webservers
/etc/ansible/host_vars/foosball
You can make a file called /etc/ansible/group_vars/raleigh to keep the variables for the raleigh group, for instance, if you organise hosts in your inventory by datacenter and each datacenter has its own NTP server and database server.
Additionally, you can name directories after your hosts or groups. All of the files in these directories will be read by Ansible in lexical order. An illustration using the "Raleigh" group:
Before a play is run, variables are by default merged or flattened to the particular host. Groups don't really exist outside of inventory and host matching because of this, which keeps Ansible focused on the Host and Task. Variables provided for a group and/or host are overwritten by default by Ansible. The following is the order/precedence (lowest to highest):
Every group (because it serves as the "parent" group for all other groups)
parent group
child group
host
The latest group loaded replaces the earlier groups by default, and Ansible combines groups at the same parent/child level in ASCII order. As an illustration, an a_group and b_group will be combined, and any matching b_group variables will replace those in the a_group.
After the parent/child order is established, you can alter this behaviour by changing the group variable ansible group priority, which will alter the merging order for groups of the same level. The number will be combined later and given more priority if it is larger. If not set, this variable defaults to 1. For instance:
a_group:
vars:
testvar: a
ansible_group_priority: 10
b_group:
vars:
testvar: b
In this case, the outcome would have been testvar == b if both groups had the same priority, but since we are giving the a_group a higher priority, the outcome is testvar == a.
It's time to dive into the details of using multiple inventory sources.
Using multiple inventory sources
By specifying multiple inventory parameters from the command line or by defining ANSIBLE_INVENTORY, you can target several inventory sources (directories, dynamic inventory scripts, or files supported by inventory plugins) at once. When you wish to simultaneously target two areas that are typically separate, such as staging and production, for a certain activity, this can be handy.
Target two sources using the following command line syntax:
Command:
ansible-playbook get_logs.yml -i staging -i production
Let's have a look over the examples of inventory setup.
Inventory setup examples
The following are examples of Inventory setup:
One inventory per environment
Sometimes it makes sense to define only the hosts of one environment per inventory if you need to manage many environments. As a result, it is more difficult, for example, to unintentionally update some "staging" servers while unwittingly altering the status of nodes inside the "test" environment.
You may have an inventory_test file for the previously described example:
Only hosts that are a member of the "test" environment are listed in that file. Create a new file called inventory staging and define the "staging" machines in it:
You already saw an example of utilising groups to cluster hosts that perform the same job in the previous section. As an example, you could implement firewall rules inside a playbook or role that only affect database servers:
Other responsibilities might be concentrated on the location of a certain host. If, however, db01.test.example.com, app01.test.example.com, and db02.test.example.com are situated in DC1 and DC2, respectively:
The Ansible inventory file specifies the hosts and groups of hosts that the commands, modules, and dependent tasks in a playbook.
What are the types of inventories in Ansible?
The inventories in Ansible are of two types, namely static and dynamic.
How does Ansible work?
Ansible operates by connecting to your nodes and sending them little programs known as "Ansible modules." These programs were created as resource models for the ideal system state. After that, Ansible runs these modules (by default over SSH) and then deletes them.
Conclusion
In this article, we have extensively discussed the details of ansible inventory, adding variables, assigning variables, organising hosts, and Inventory setup examples.
246+ registered 
