What Is Dynamic Inventory
Dynamic inventory pulls the list of managed hosts from an external, authoritative source — a cloud provider API, a CMDB, or a service discovery system — at the moment a playbook runs, rather than reading a hand-maintained static ini or YAML file. This matters because modern infrastructure autoscales, gets recreated by CI/CD pipelines, or churns through short-lived instances, so a static file would go stale within hours while a dynamic source stays accurate automatically.
Cricket analogy: Dynamic inventory is like a scorer using a live match feed that auto-updates the playing XI if a substitute fielder comes on, instead of relying on yesterday's printed team sheet that goes stale the moment a change happens.
Inventory Plugins and Sources
Inventory plugins such as amazon.aws.aws_ec2, azure.azcollection.azure_rm, and google.cloud.gcp_compute query the corresponding cloud provider's API at runtime, converting tags and metadata into Ansible groups and host variables automatically. A YAML source file (commonly named aws_ec2.yml or similar so Ansible auto-detects the plugin) configures which regions and filters to query, how to compose group names from tags, and whether to cache results locally to avoid provider API rate limits on large fleets.
Cricket analogy: An inventory plugin querying an API is like a broadcaster's data feed pulling live player stats directly from the stadium's official scoring system rather than an analyst manually re-entering numbers between overs.
# aws_ec2.yml — auto-detected by the 'auto' plugin because of the filename suffix
plugin: amazon.aws.aws_ec2
regions:
- us-east-1
- eu-west-1
filters:
tag:Environment: production
instance-state-name: running
keyed_groups:
- key: tags.Role
prefix: role
- key: tags.Environment
prefix: env
compose:
ansible_host: public_ip_address
cache: true
cache_plugin: jsonfile
cache_timeout: 300
cache_connection: /tmp/ansible_inventory_cacheGrouping, Caching, and Custom Scripts
keyed_groups derive dynamic Ansible groups directly from tag values — a host tagged Environment=production automatically lands in an env_production group with no manual step — while compose can compute variables such as ansible_host from a cloud-specific attribute like public_ip_address. Caching (via jsonfile, redis, or similar cache plugins) stores query results for a configurable timeout so repeated playbook runs, or Tower jobs firing every few minutes, don't hammer the provider's API and risk rate-limiting; custom inventory scripts, an older executable-returning-JSON approach that predates the plugin system, still work today through Ansible's auto plugin for backward compatibility.
Cricket analogy: Keyed groups deriving from tags is like automatically sorting players into a 'death-over specialists' group based on a stat tag in the database, rather than a selector manually re-sorting the list before every match.
Debug what a dynamic inventory source actually resolves to before running a playbook against it: ansible-inventory --graph -i aws_ec2.yml prints the resolved group/host tree, and --list prints full host variables as JSON.
Overly broad API credentials handed to an inventory plugin can leak your entire account topology to anyone who can read the playbook repo. Scope the IAM policy (or equivalent) to read-only describe/list calls only — inventory plugins never need write permissions.
- Dynamic inventory queries a live source (cloud API, CMDB) instead of reading a static file, keeping host lists accurate as infrastructure changes.
- Inventory plugins like amazon.aws.aws_ec2, azure.azcollection.azure_rm, and google.cloud.gcp_compute are configured via a YAML source file.
- keyed_groups auto-derive Ansible groups from tag values; compose computes variables like ansible_host from provider attributes.
- Caching (jsonfile, redis, etc.) reduces API calls and avoids provider rate-limiting on frequent or large-scale queries.
- Legacy executable inventory scripts returning JSON still work today via Ansible's auto plugin.
- ansible-inventory --graph and --list are the standard tools for debugging what a dynamic source resolves to.
- Inventory plugin credentials should be scoped to read-only describe/list permissions, never write access.
Practice what you learned
1. What is the main advantage of dynamic inventory over a static inventory file?
2. What does the keyed_groups option do in an inventory plugin configuration?
3. Why is caching used in dynamic inventory plugins?
4. Which command shows the resolved group/host tree of a dynamic inventory source before running a playbook?
5. What level of API permission should credentials used by an inventory plugin have?
Was this page helpful?
You May Also Like
Ansible for Cloud Provisioning
Using Ansible's cloud modules and collections to create, modify, and configure cloud infrastructure declaratively, often in the same playbook run that configures the resulting hosts.
Ansible Tower and AWX
A web-based control plane for Ansible that adds job templates, RBAC, scheduling, and notifications on top of core Ansible, available as the open-source AWX project or the commercial Ansible Automation Platform.
Idempotency in Ansible
The principle that running a playbook repeatedly against the same hosts produces the same end state, and why purpose-built modules achieve it while raw command/shell tasks require extra guards.
Related Reading
Related Study Notes in DevOps
Browse all study notesNginx Study Notes
DevOps · 30 topics
DevOpsAdvanced Kubernetes Study Notes
Kubernetes · 30 topics
DevOpsAdvanced Bash Scripting Study Notes
Bash · 30 topics
DevOpsApache Kafka Study Notes
Kafka · 30 topics
DevOpsDocker & Kubernetes Study Notes
YAML · 40 topics
DevOpsCI/CD Tools & Pipelines Study Notes
YAML · 37 topics