Article Categories
- All Categories
-
Data Structure
-
Networking
-
RDBMS
-
Operating System
-
Java
-
MS Excel
-
iOS
-
HTML
-
CSS
-
Android
-
Python
-
C Programming
-
C++
-
C#
-
MongoDB
-
MySQL
-
Javascript
-
PHP
-
Economics & Finance
How to Use Static and Dynamic Inventories in Ansible?
Ansible is a powerful automation tool that allows you to manage and configure systems, deploy software, and orchestrate advanced IT tasks such as continuous deployments or zero downtime rolling updates. One of the key components of Ansible is the inventory file, which describes the hosts and groups of hosts upon which commands, modules, and tasks in a playbook operate.
In this article, we'll explore how to use both static and dynamic inventories in Ansible, complete with examples and their outputs.
Static Inventories
Static inventories are the simplest way to manage and organize your servers. They are defined in INI or YAML format and remain unchanged unless manually modified. Here's an example of a static inventory in INI format:
[webservers] webserver1.example.com webserver2.example.com [dbservers] dbserver1.example.com
In this example, we have two groups ? webservers and dbservers. Each group contains the hostnames of the servers in that group.
You can use these groups in your playbooks to target specific servers for different tasks:
- hosts: webservers
tasks:
- name: ensure apache is at the latest version
ansible.builtin.yum:
name: httpd
state: latest
Using Variables in Static Inventory
You can define variables directly in your static inventory file. These variables can be used in your playbooks:
[webservers] webserver1.example.com http_port=80 max_clients=200 [dbservers] dbserver1.example.com mysql_port=3306
In your playbook template, you can reference these variables:
Listen {{ http_port }}
MaxClients {{ max_clients }}
Using Child Groups and Aliases
Static inventories support hierarchical organization through child groups and host aliases:
[atlanta] host1 host2 [raleigh] host3 host4 [southeast:children] atlanta raleigh [webservers] web1 ansible_host=webserver1.example.com web2 ansible_host=webserver2.example.com
The southeast group includes all hosts from both atlanta and raleigh groups, while aliases like web1 provide readable names for actual hostnames.
Dynamic Inventories
While static inventories are easy to understand, they become difficult to manage as infrastructure scales. Dynamic inventories are scripts that automatically generate inventory data from external sources like cloud providers, databases, or APIs.
AWS Dynamic Inventory
To use AWS dynamic inventory, install the required dependencies and configure access:
pip install boto3 export AWS_ACCESS_KEY_ID=your_access_key export AWS_SECRET_ACCESS_KEY=your_secret_key
Create an AWS inventory configuration file aws_ec2.yml:
plugin: aws_ec2
regions:
- us-west-2
- us-east-1
filters:
instance-state-name: running
keyed_groups:
- key: tags.Environment
prefix: env
- key: instance_type
prefix: type
Use the dynamic inventory in your playbooks:
ansible-playbook -i aws_ec2.yml playbook.yml
Docker Dynamic Inventory
For Docker containers, create a docker.yml inventory file:
plugin: docker_swarm
docker_host: unix://var/run/docker.sock
compose:
ansible_host: ansible_docker_swarm_node_attributes.Addr
keyed_groups:
- key: ansible_docker_swarm_node_attributes.Role
prefix: role
Run playbooks against Docker containers:
ansible-playbook -i docker.yml playbook.yml
Comparison
| Feature | Static Inventory | Dynamic Inventory |
|---|---|---|
| Configuration | Simple INI/YAML files | Scripts or plugins |
| Management | Manual updates required | Automatic synchronization |
| Best For | Small, stable environments | Cloud, containerized environments |
| Scalability | Limited by manual maintenance | Scales with infrastructure |
| Complexity | Low | Moderate to high |
Conclusion
Static inventories work well for small, stable environments with predictable infrastructure, while dynamic inventories excel in cloud and containerized environments where infrastructure changes frequently. Choose based on your environment's scale, change frequency, and complexity requirements.
