𝐔𝐧𝐝𝐞𝐫𝐬𝐭𝐚𝐧𝐝𝐢𝐧𝐠 𝐀𝐧𝐬𝐢𝐛𝐥𝐞 𝐈𝐧𝐯𝐞𝐧𝐭𝐨𝐫𝐲: 𝐌𝐚𝐧𝐚𝐠𝐢𝐧𝐠 𝐚𝐧𝐝 𝐎𝐫𝐠𝐚𝐧𝐢𝐳𝐢𝐧𝐠 𝐘𝐨𝐮𝐫 𝐈𝐧𝐟𝐫𝐚𝐬𝐭𝐫𝐮𝐜𝐭𝐮𝐫𝐞

Hey Techies…👋

In this blog, we’re going to discuss about 𝐀𝐧𝐬𝐢𝐛𝐥𝐞 𝐈𝐧𝐯𝐞𝐧𝐭𝐨𝐫𝐲: 𝐌𝐚𝐧𝐚𝐠𝐢𝐧𝐠 𝐚𝐧𝐝 𝐎𝐫𝐠𝐚𝐧𝐢𝐳𝐢𝐧𝐠 𝐘𝐨𝐮𝐫 𝐈𝐧𝐟𝐫𝐚𝐬𝐭𝐫𝐮𝐜𝐭𝐮𝐫𝐞.

𝗪𝗵𝗮𝘁 𝗶𝘀 𝗔𝗻𝘀𝗶𝗯𝗹𝗲 𝗜𝗻𝘃𝗲𝗻𝘁𝗼𝗿𝘆?
Ansible Inventory is the backbone of server management, housing crucial details about your servers. Traditionally, it was a static file, but Ansible’s true prowess shines with dynamic inventories.

𝗜𝗻𝘁𝗿𝗼𝗱𝘂𝗰𝗶𝗻𝗴 𝗗𝘆𝗻𝗮𝗺𝗶𝗰 𝗜𝗻𝘃𝗲𝗻𝘁𝗼𝗿𝘆:
Dynamic Inventory takes server management to the next level by enabling real-time updates. No more static files! Instead, it fetches server information on-the-fly from external sources like cloud providers or databases.

𝗪𝗵𝘆 𝗗𝘆𝗻𝗮𝗺𝗶𝗰 𝗜𝗻𝘃𝗲𝗻𝘁𝗼𝗿𝘆?
✔Real-Time Updates: Reflect changes instantly.
✔Adaptability: Ideal for dynamic environments.
✔Grouping Magic: Efficiently manage server categories.
✔Structured Hierarchy: Parent-child relationships bring order.

𝗟𝗶𝗻𝗸𝗶𝗻𝗴 𝗥𝗲𝗮𝗹𝗶𝘁𝘆 𝘁𝗼 𝗔𝗻𝘀𝗶𝗯𝗹𝗲:
Dynamic Inventory seamlessly integrates with your environment. If you’re on AWS, Azure, or any major cloud platform, Ansible can automatically fetch server details. Changes in your infrastructure? No worries — Ansible stays in sync.

𝗘𝗳𝗳𝗶𝗰𝗶𝗲𝗻𝘁 𝗦𝗲𝗿𝘃𝗲𝗿 𝗚𝗿𝗼𝘂𝗽𝗶𝗻𝗴:
With Ansible Inventory, you’re not stuck managing servers individually. Leverage grouping to categorize servers based on roles, locations, or any criteria. Need to update web servers? Simply target the “web_servers” group — it’s that streamlined!

𝗜𝗡𝗜 𝘃𝘀. 𝗬𝗔𝗠𝗟:
Choose your syntax — Ansible supports both INI and YAML formats for inventory. INI is straightforward, while YAML adds flexibility and structure, catering to the scale and complexity of your IT environment.

In the realm of server management, choosing an inventory format is like selecting an organizational chart that seamlessly aligns with your company’s structure and scale.

Consider two scenarios that reflect the diversity of organizational needs:

🌱 𝗦𝗰𝗲𝗻𝗮𝗿𝗶𝗼 1: 𝗦𝗺𝗮𝗹𝗹 𝗦𝘁𝗮𝗿𝘁-𝘂𝗽

In this scenario, a small start-up operates with a handful of services managing basic functions such as web hosting and database management. The ideal choice here is a simple INI format inventory, mirroring a basic organizational chart with just a few departments.

🌐 𝗦𝗰𝗲𝗻𝗮𝗿𝗶𝗼 2: 𝗠𝘂𝗹𝘁𝗶𝗻𝗮𝘁𝗶𝗼𝗻𝗮𝗹 𝗖𝗼𝗿𝗽𝗼𝗿𝗮𝘁𝗶𝗼𝗻

For a multinational corporation with hundreds of servers globally, each handling diverse functions like e-commerce, customer support, and data analysis, a more detailed and structured inventory is paramount. Here, the YAML format comes into play, resembling a complex organizational chart with various departments, sub-departments, and teams.

🤝 𝗙𝗹𝗲𝘅𝗶𝗯𝗶𝗹𝗶𝘁𝘆 𝗶𝗻 𝗚𝗿𝗼𝘂𝗽𝗶𝗻𝗴:

The flexibility of these inventory formats empowers you to group servers based on roles (e.g., web servers, database servers), geographic locations (e.g., U.S., Europe, Asia), or any criteria crucial to your organization’s dynamics.

🔍 𝗠𝗼𝘀𝘁 𝗨𝘀𝗶𝗻𝗴 𝗔𝗻𝘀𝗶𝗯𝗹𝗲’𝘀 𝗜𝗻𝘃𝗲𝗻𝘁𝗼𝗿𝘆 𝗙𝗼𝗿𝗺𝗮𝘁𝘀:
✔INI Format
✔YAML Format

🔄 𝗖𝗵𝗼𝗼𝘀𝗶𝗻𝗴 𝗬𝗼𝘂𝗿 𝗢𝗿𝗴𝗮𝗻𝗶𝘇𝗮𝘁𝗶𝗼𝗻𝗮𝗹 𝗕𝗹𝘂𝗲𝗽𝗿𝗶𝗻𝘁:

Just as a company selects the right organizational chart, your project should choose the inventory format that aligns seamlessly with its needs. Whether it’s the simplicity of INI or the flexibility of YAML, the key is to ensure effective collaboration between your servers and departments to achieve organizational objectives.

Let’s see how the INI and YAML formats play a crucial role in defining and organizing your infrastructure, providing with the flexibility and clarity needed for effective Ansible playbook execution.

Inventory Formats

We can create inventory file in one of many formats, depending on the inventory plugins we have. The most common formats are INI and YAML.

INI Format

INI file based inventory, sections are groups or group related with Entries in sections [group_1] are hosts, members of the group. Hosts can have variables defined inline as key/value pairs The children modifier indicates that the section contains groups. The vars modifier indicates that the section contains variables special :modifiers. separated by =. assigned to members of the group.

✔Classic and simple.

✔Suitable for basic inventories.

Sections: Denoted by square brackets ([]), allowing grouping of hosts based on functionality.(e.g., [web_servers]).

Hosts: Listed under sections with unique names (server1, server2). Variables: Assigned to hosts using key=value pairs, enhancing flexibility and customization.

YAML Format:

YAML-based inventory, should start with the all group and contain hosts/vars/children entries. Host entries can have sub-entries defined, which will be treated as variables.Vars entries are normal group vars. Children are ‘child groups’ , which can also have their own File MUST have a valid extension, defined in configuration.

✔Offers a more structured and readable approach.

✔Suitable for complex environments with nested variables.

Structure: YAML uses indentation to represent the hierarchy, making it visually intuitive.

Hosts: Defined under named groups (web_servers, db_servers) with associated hosts and their attributes.

Variables: Assigned as key-value pairs within each host’s details.

Let’s consider a practical scenario to know more about Ansible Inventory.

****************************************************************************

Prerequisites — 3 Virtual Machines

1. server — 1 CPU — 1GB RAM (Python 2.7) — Ansible Server

2. node1–1 CPU — 1GB RAM ( python 2.6 and above) — Ansible Client

3. node2–1 CPU — 1GB RAM ( python 2.6 and above) — Ansible Client

From ansible user execute below command:

ansible all -m ping

the above ping command should return with a ping / pong green color.

***************************************************************************

Certainly! The ansible.cfg file is the configuration file for Ansible, a popular open-source automation tool. It allows you to configure various settings for Ansible, such as default inventory locations, remote user, and more. Below is a simple example of an ansible.cfg file:

This example includes some common configurations:

• inventory: Specifies the path to your inventory file, which contains information about your managed hosts.
• remote_user: Specifies the default user that Ansible should use when connecting to remote hosts.

You can customize these settings based on your specific needs and environment. Ensure that you have the necessary permissions and security considerations in place, especially when dealing with sensitive information such as passwords.

Feel free to adjust the values according to your requirements. Additionally, you can refer to the official Ansible documentation for more details on configuration options.

Below are the contents of an Ansible inventory file (hosts). In your example, you have two groups: [prod] and [backup], each containing a single host (node1 and node2, respectively).

Then, you’ve used the ansible command with the — list option to display the hosts in different groups. Here’s a breakdown:

• ansible all — list: Lists all hosts, which includes both node1 and node2.
• ansible prod — list: Lists hosts in the [prod] group, which is just node1.
• ansible backup — list: Lists hosts in the [backup] group, which is just node2.

Let’s take the below scenario :

Deploy all plays across the servers listed in the inventory file, ensuring that only one play or task is executed exclusively on the servers within the “prod” group.

Certainly! To achieve this, you can create an Ansible playbook that includes multiple plays, with one of the plays specifically targeting the hosts in the [prod] group. Below is an example playbook that you can use:

Syntax:

---
- name: Install Plays
  hosts: all
  tasks:
    - name: Your common tasks for all servers
      # Add your common tasks here

- name: Install Plays for Prod
  hosts: prod
  tasks:
    - name: Your specific tasks for the prod group
      # Add your tasks specific to the prod group here

This Ansible playbook is designed to install and configure the Apache HTTP server (httpd) on all hosts. Additionally, it includes a task to restart the HTTPD service, but this task is conditionally executed only on hosts within the “prod” group.

Breaking it down:

• Install httpd:
• The first task, named “Install httpd,” uses the yum module to install the latest version of the Apache HTTP server (httpd) on all hosts (hosts: all).
• Restart httpd on prod servers:
• The second task, named “Restart httpd on prod servers,” utilizes the service module to restart the HTTPD service.
• However, the when condition (when: “‘prod’ in group_names”) ensures that this task is only executed on hosts that belong to the “prod” group. It checks if the string “prod” is present in the list of group names (group_names).

In summary, this playbook will install the Apache HTTP server on all hosts and restart the HTTPD service only on hosts that are part of the “prod” group. If you run this playbook using the ansible-playbook command, it will apply these tasks to the specified hosts in your inventory file.

---
- name: Install and Configure HTTPD
  hosts: all
  tasks:
   - name: Install httpd
     yum:
      name: httpd
      state: latest
    
   - name: Restart httpd on prod servers
     service:
      name: httpd
      state: restarted
     when: "'prod' in group_names"

The below command will check the syntax of the playbook and report any syntax errors if they exist. If there are no syntax errors, it will display a message indicating that the syntax is okay.

ansible-playbook inventoryeg.yaml - syntax-check

Now, let’s execute the playbook by running the following command

ansible-playbook inventoryeg.yaml

The output indicates that the playbook has been executed successfully. Here’s a breakdown of the relevant information:

• PLAY [Install and Configure HTTPD]: This is the name of the play in your playbook.
• TASK [Gathering Facts]: Ansible starts by gathering facts about the target hosts. This includes information about the system such as operating system details, network interfaces, and more. It’s a necessary step for many Ansible modules.
• TASK [Install httpd]: This task uses the yum module to install the latest version of the Apache HTTP server (httpd). Both node1 and node2 report as “ok,” indicating that the task was executed successfully on both hosts.
• TASK [Restart httpd on prod servers]: This task restarts the HTTPD service, but it is conditionally executed only on hosts in the “prod” group. In this case, node2 is skipped because it is not in the “prod” group, and node1 reports as “changed,” indicating that the task was executed and resulted in a change (the service was restarted).
• PLAY RECAP: This section provides a summary of the play’s results for each host. For node1, it shows that 3 tasks were okay (ok=3), 1 task resulted in a change (changed=1), and there were no failures (failed=0). For node2, it shows 2 tasks were okay (ok=2), 0 changes, and 1 task was skipped (skipped=1). The “changed” count indicates that a task modified the system state.

I hope that this blog has provided you with valuable insights into the practical and beneficial aspects of Ansible inventories.

💹Next day — Demystifying Ansible Variables: The Key to Flexible and Dynamic Automation.

⭐⭐⭐ Enjoy your learning….!!! ⭐⭐⭐