Ansible Custom Inventory – How I Organize and Manage My Servers

 While working with Ansible, one of the most essential things I learned was how to create and manage a custom inventory.

The inventory is basically the place where I list all my servers — and tell Ansible how to connect to them.

Once I understood this clearly, working with multiple EC2 instances became much easier.

In this blog, I’ll explain the concept of custom inventory the way I understood it and show the formats I used in my hands-on practice.

⭐ What Is an Inventory? (My Understanding)

An inventory is a file where I define the servers (managed nodes) that Ansible should control.

It contains:

  • server names

  • IP addresses

  • SSH usernames

  • private key file paths

  • group names

For me, the inventory acts like:

“A phonebook for Ansible — it tells Ansible which server to call and how to connect.”

⭐ Types of Inventories I Used

Ansible supports different inventory formats, but these are the two I practiced:

1️⃣ Static Inventory (INI Format)

This is the simplest format and the one I used most often.

Example: inventory.ini

[webservers]
web1 ansible_host=54.123.45.10 ansible_user=ec2-user ansible_ssh_private_key_file=mykey.pem
web2 ansible_host=54.123.45.11 ansible_user=ec2-user ansible_ssh_private_key_file=mykey.pem

[dbservers]
db1 ansible_host=54.123.45.20 ansible_user=ubuntu ansible_ssh_private_key_file=dbkey.pem

What each field means:

  • ansible_host → actual IP address

  • ansible_user → default login user

  • ansible_ssh_private_key_file → SSH key path

This format is great for quick labs or small setups.

2️⃣ Static Inventory (YAML Format)

YAML is more structured and cleaner for large inventories.

Example: inventory.yml

all:
  children:
    webservers:
      hosts:
        web1:
          ansible_host: 54.123.45.10
          ansible_user: ec2-user
          ansible_ssh_private_key_file: mykey.pem

        web2:
          ansible_host: 54.123.45.11
          ansible_user: ec2-user
          ansible_ssh_private_key_file: mykey.pem

    dbservers:
      hosts:
        db1:
          ansible_host: 54.123.45.20
          ansible_user: ubuntu
          ansible_ssh_private_key_file: dbkey.pem

I personally found YAML easier to read when managing many hosts.

⭐ Using the Inventory With Ansible

To run ad-hoc commands:

ansible all -i inventory.ini -m ping

To run playbooks:

ansible-playbook -i inventory.yml site.yml

If inventory is in the same folder as the playbook, using -i is optional.

⭐ Group Variables and Host Variables

I also learned that I can define variables at:

Group level:

[webservers:vars]
ansible_user=ec2-user
ansible_ssh_private_key_file=mykey.pem

Host level:

web1 ansible_host=54.12.34.56 ansible_port=2222

This avoids repeating values and makes the inventory cleaner.

⭐ Dynamic Inventory (For Cloud Automation)

Even though I didn’t use dynamic inventory extensively, I understood the idea.

Dynamic inventory automatically discovers servers from cloud providers like:

  • AWS EC2

  • Azure

  • GCP

Example command:

ansible-inventory -i aws_ec2.yaml --list

This is useful when servers keep changing (autoscaling, dynamic IPs, etc.).

⭐ Why Custom Inventory Is Important (My Realization)

After working with inventories in multiple playbooks, I realised:

✔ Inventory decides where Ansible runs
✔ Good inventory organization = easy automation
✔ Grouping servers simplifies operations
✔ Inventory variables reduce repetition
✔ YAML format is better for large setups
✔ Dynamic inventory is powerful for cloud environments

Without a proper inventory, automation becomes messy.

⭐ Final Thoughts

Learning how to write my own inventory file was a big improvement in my Ansible practice.
Instead of hardcoding IPs everywhere, I could manage everything from one place.

With ad-hoc commands and playbooks, a clean inventory made my setups faster, simpler, and more professional.

This completes the core fundamental topics I learned in Ansible:

  • What is Ansible

  • Architecture

  • Modules

  • Installation & Setup

  • Ad-Hoc Commands

  • Playbooks

  • Custom Inventory

Next topics I plan to cover soon:

  • Ansible Roles

  • Handlers

  • Variables & Facts

  • Loops, Conditions, Tags

  • Complete automation project

Stay tuned for the next blog in my DevOps journey!

Comments

Post a Comment

Popular posts from this blog

Ansible Playbooks – How I Learned to Automate Complete Tasks

 After getting comfortable with ad-hoc commands, I moved on to the most important part of Ansible — Playbooks . This is where the real automation happens. Ad-hoc commands are good for quick tasks, but playbooks allow me to write repeatable, structured, and complete automation scripts . In this blog, I’ll explain playbooks in the simplest way possible, based on how I understood and practiced them. ⭐ What Are Ansible Playbooks? (In My Own Words) Playbooks are YAML files where I define: what tasks I want to run on which servers in what order with what configurations Playbooks allow me to automate full workflows like: installing packages configuring services deploying applications managing files creating users restarting services For me, a playbook is basically: “A step-by-step automation recipe written in YAML.” ⭐ Basic Structure of a Playbook Here’s the structure I internalised: - name: <description> hosts: <target_serv...
Read more

Understanding Ansible Modules

 As I continued learning Ansible, one of the most important concepts I came across was Modules . They are the core of how Ansible performs automation. Once I understood modules clearly, writing playbooks and running ad-hoc commands became much easier and more meaningful. In this blog, I’m sharing what Ansible modules are and how I understood them through hands-on practice. ⭐ What Are Ansible Modules? (In My Own Words) Modules are the actual actions Ansible performs on a server. If I want to: install a package create a file add a user start a service copy a configuration Ansible uses a module to do it. So for me: “Modules are the building blocks of every automation task in Ansible.” Every ad-hoc command and every task inside a playbook uses a module. ⭐ How I Understand the Working of Modules Whenever I run Ansible: Ansible connects to the server through SSH The selected module runs on the remote machine It performs the action I defined I...
Read more

“What is Ansible? – My Understanding as a DevOps Learner”

  What is Ansible? – My Understanding as a DevOps Learner When I started my DevOps journey, Ansible was one of the first automation tools I learned. At the beginning, I only knew that Ansible “automates tasks,” but after going through my training sessions and hands-on practice, I understood how powerful and simple it actually is. In this blog, I want to explain what Ansible means in my own words , exactly how I understood it as a beginner. ⭐ How I Understand Ansible Ansible is an open-source automation tool that helps us manage servers without doing everything manually. Instead of logging into each machine and running commands one by one, I can write instructions in a simple YAML file, and Ansible applies them to any number of servers at the same time. So for me, Ansible is basically: “Write once → run anywhere → automate everything.” That’s the beauty of it. ⭐ Why Ansible is Very Useful From my learning, these are the main reasons: 1. It is agentless This was the ...
Read more