Inventory, Groups, and Group of Groups
Inventory is a text file where we define the host information that we are going to manage through Ansible.
The default path of the inventory file is /etc/ansible/hosts/ but we can also specify a different inventory file using -i <path of inventory file> on the command line.
So in continuation of the previous article, we are going to create an inventory file.
Step 1
Create an inventory file using the command
Step 2
Add the below code in the inventory file.
websrv01 ansible_host=172.31.34.188 ansible_user=devops ansible_ssh_pass=admin123
websrv02 ansible_host=172.31.24.55 ansible_user=devops ansible_ssh_pass=admin123
dbsrv01 ansible_host=172.31.14.124 ansible_user=devops ansible_ssh_pass=admin123
#creating group
[websrvgrp]
websrv01
websrv02
[dbsrvgrp]
dbsrv01
#creating groups of groups
[DC_NCALI:children]
websrvgrp
dbsrvgrp
Now let’s understand code written in the inventory file,
- Here we can see that we have specified all our hosts; i.e. the IP of 3 web servers and 1 DB server and we have also given the username and password for all of them.
- We can see a group of web servers named WebServersGroup. This would be really helpful if we want to configure something on all web servers then we can simply give this WebServersGroup rather than specifying the IP of each web server host machine.
- We can see a group of DB servers, though as of now we have only 1 db server but it is a good practice to keep similar kind of hosts in a group to later manage them effectively.
- We can also see a group called DC_NCALI: children. This is a group of groups for North California region as all our servers are present in this region so we have given the group name as DC_NCALI: children. This would be helpful in case we have different hosts residing in different region.
- So, if we want to run a configuration then we can club them as per region and can run the configuration by giving the appropriate group name which will contain other subgroups.
- DC_NCALI:children is a master group and underneath specifies the other group names.
Step 3
We have to ping each of the hosts defined in the inventory file using the ping module.
To call any module in Ansible we use -m option. So, the command will be the following.
ansible -i int-qa -m ping websrv01On executing the above command we will get a below error.
This is because the target machine is not known to our Ansible server. There are 2 ways to resolve it.
1. Either make the target host entry to ~/.ssh/known_hosts
2. Make key host_key_checking = False available in /etc/ansible/ansible.cfg file.
Now, let’s again execute the command.
Hurray, we get a response now.
/usr/bin/python is telling you the path of python on target machine.
Make sure security group rules are correct. We can run the same command by providing the group name defined in the inventory. Also, if we want to test with all the hosts, we can use a * instead of a server name.
ansible -i inventory -m ping all
ansible -i inventory -m ping '*'Variables in Inventory
Variables are defined at the host level above the the inventory file. As we can see that the username and password for hosts are same, we can define the variables at the group level as well. Let’s say if the DB server is having a different username and password, then we can define the credentials at the host level for that and it will taken on priority.
Change made to the inventory and its response
websrv01 ansible_host=172.31.34.188
websrv02 ansible_host=172.31.1.113
#dbsrv01 ansible_host=172.31.14.124
#creating group
[websrvgrp]
websrv01
websrv02
[dbsrvgrp]
dbsrv01
#creating groups of groups
[DC_NCALI:children]
websrvgrp
dbsrvgrp
[websrvgrp:vars]
ansible_user=devops
ansible_ssh_pass=admin123
We can ping it again and see if it works,
Great… It works ?. So, we have learned how we can use variables at the group level.
What if some host has a different username and password?
For such cases, we can define the username and password at the host level, as host-level variables have higher priority than group-level variables.
So, suppose Db server has a different user with different username and password then we can define it at the host level for Db server. Now, for rest hosts, the group level variables will be applied but for the host with variables at the host level, group-level variables will not be applied.
Now let’s suppose we want to install some package on all servers. For this Ansible has a yum module.
Ping module didn’t have any arguments to pass but the yum module has. Values of the arguments we can get from ansible docs. We will run the below command:
ansible -i inventory -m yum -a “name=httpd state=present” websrv01
This says we need to be a root user to perform this command. Here execution is happening with DevOps user and DevOps user is a normal user so cannot install packages but it does have sudoers privilege. So, we can escalate the privilege from the command line.
To escalate the privilege from the command line we can use – – become. Now the command will look like,
ansible -i inventory -m yum -a "name=httpd state=present" websrv01 --become
Great… It says that httpd package has been installed on web server 01. YAY… ? Let’s do it again
Now it says changed as false because it has already installed the package. So this behavior is called IDEMPOTENT behavior of configuration management tools as mentioned in previous blog.
As our Web server 3 (Ubuntu) is Debian based so we can install package there using apt module. Here package name is apache2.
ansible -i inventory -m apt -a "name=apache2 state=present" websrv03 --become
ansible -i inventory -m apt -a "update-cache=yes" websrv03 --become
So apache2 package has been installed successfully.
Lastly, we can start the service on the web servers and for this we have service module in Ansible.
ansible -i inventory -m service -a "name=httpd state=started enabled=yes" websrv01 --become 
So, the service has been started on web server 1 and similarly, we can do it for other web servers.
