Ansible unterstützt zwei Haupttypen von Inventories: statische und dynamische. Beide haben ihre spezifischen Einsatzszenarien und Vorteile, abhängig von der Größe und Komplexität der IT-Umgebung, die verwaltet wird.
Ein statisches Inventory ist eine Datei, die die Liste der Zielknoten sowie deren Gruppierungen und Variablen enthält. Ansible unterstützt mehrere Formate für statische Inventories: INI, YAML und JSON.
[webservers]
web1.example.com
web2.example.com
[dbservers]
db1.example.com
db2.example.comall:
children:
webservers:
hosts:
web1.example.com:
web2.example.com:
dbservers:
hosts:
db1.example.com:
db2.example.com:Das YAML-Format wird in modernen Ansible-Umgebungen bevorzugt, da es besser lesbar ist und sich nahtlos in GitOps- und CI/CD-Workflows integriert.
Vorteile von statischen Inventories: - Einfachheit und Transparenz: Leicht zu erstellen und zu verstehen, besonders in kleinen Umgebungen - Versionskontrolle: Änderungen können einfach nachverfolgt und versioniert werden - Keine Abhängigkeit von externen Systemen: Funktioniert ohne zusätzliche Konfiguration oder Abhängigkeiten - Deterministische Ergebnisse: Identische Inventare bei jeder Ausführung
Nachteile von statischen Inventories: - Manuelle Wartung: Änderungen an der Infrastruktur müssen manuell im Inventory nachgezogen werden - Skalierungsprobleme: Bei einer großen Anzahl von Hosts oder dynamischen Umgebungen kann die Verwaltung komplex und fehleranfällig werden - Keine automatische Synchronisation: Divergenz zwischen realem Zustand und Inventory möglich
Dynamische Inventories werden durch Inventory Plugins generiert, die in Echtzeit Informationen über die Zielknoten abrufen. Dies ist besonders nützlich in Umgebungen, in denen sich die Anzahl und der Zustand der Zielknoten häufig ändern, wie z.B. in Cloud-Umgebungen.
Beispiel für AWS EC2 Plugin:
# inventory_aws.yml
plugin: amazon.aws.aws_ec2
regions:
- eu-central-1
- us-east-1
filters:
tag:Environment: production
instance-state-name: running
keyed_groups:
- prefix: tag
key: tags.Environment
- prefix: instance_type
key: instance_type
compose:
ansible_host: public_ip_addressBeispiel für Azure Plugin:
# inventory_azure.yml
plugin: azure.azcollection.azure_rm
include_vm_resource_groups:
- production-rg
- staging-rg
conditional_groups:
webservers: "'web' in tags.role"
dbservers: "'database' in tags.role"Früher wurden dynamische Inventories über eigene Skripte realisiert:
#!/bin/bash
# Nur für Verständnis - nicht mehr empfohlen
echo '{
"webservers": {
"hosts": ["web1.example.com", "web2.example.com"]
},
"dbservers": {
"hosts": ["db1.example.com", "db2.example.com"]
}
}'Moderne Praxis nutzt ausschließlich Inventory Plugins, da diese robuster, wartbarer und besser integriert sind.
Vorteile von dynamischen Inventories: - Automatisierte Anpassung: Änderungen in der Infrastruktur werden automatisch im Inventory berücksichtigt - Cloud-Integration: Native Integration mit AWS, Azure, GCP, VMware und anderen Plattformen - Aktuelle Daten: Immer synchron mit dem tatsächlichen Zustand der Infrastruktur - Skalierbarkeit: Problemlos mit hunderten oder tausenden von Hosts
Nachteile von dynamischen Inventories: - Komplexität: Erfordert Konfiguration und Verständnis der jeweiligen Plugins - Abhängigkeit von externen Systemen: Benötigt Konnektivität und Berechtigungen zu den jeweiligen APIs - Performance: API-Aufrufe können bei großen Umgebungen Zeit benötigen - Debugging: Fehlerbehebung kann komplexer sein
Inventory Plugins werden in der ansible.cfg
aktiviert:
[defaults]
inventory = inventory/
[inventory]
enable_plugins = auto, yaml, ini, amazon.aws.aws_ec2, azure.azcollection.azure_rmYAML-Format mit Variablen:
all:
vars:
ntp_server: ntp.example.com
dns_servers:
- 8.8.8.8
- 8.8.4.4
children:
webservers:
vars:
http_port: 80
max_clients: 200
hosts:
web1.example.com:
ansible_user: deploy
ansible_port: 2222
web2.example.com:
ansible_host: 192.168.1.100
ansible_user: admin
dbservers:
vars:
db_port: 5432
hosts:
db1.example.com:
ansible_connection: ssh
ansible_user: dbadmin
db2.example.com:
ansible_connection: winrm
ansible_user: winadmininventory/
├── hosts.yml # Hauptinventory
├── inventory_aws.yml # Dynamisches AWS-Inventory
├── group_vars/
│ ├── all.yml # Globale Variablen
│ ├── webservers.yml # Variablen für Webserver-Gruppe
│ └── dbservers.yml # Variablen für Datenbankserver-Gruppe
├── host_vars/
│ ├── web1.example.com.yml # Host-spezifische Variablen
│ └── db1.example.com.yml # Host-spezifische Variablen
└── vault/
├── group_vars/
│ └── all.yml # Verschlüsselte globale Variablen
└── host_vars/
└── db1.example.com.yml # Verschlüsselte Host-Variablen
Die Variablen-Priorität in Ansible (niedrig zu hoch): 1.
group_vars/all 2. group_vars/gruppe_name 3.
host_vars/hostname 4. Inventory-Variablen (in der
Inventory-Datei) 5. Play-Variablen 6. Task-Variablen
Ansible kann mehrere Inventory-Quellen gleichzeitig nutzen:
# Mehrere Dateien
ansible-playbook -i inventory/hosts.yml -i inventory/aws.yml playbook.yml
# Verzeichnis (alle Dateien darin)
ansible-playbook -i inventory/ playbook.yml
# Mix aus statisch und dynamisch
ansible-playbook -i inventory/static.yml -i inventory/aws_dynamic.yml playbook.ymlDas ansible-inventory Tool ist essentiell für das Testen
und Debuggen von Inventories:
# Inventory als JSON ausgeben
ansible-inventory -i inventory.yml --list
# Inventory als Graph anzeigen
ansible-inventory -i inventory.yml --graph
# Spezifische Hosts anzeigen
ansible-inventory -i inventory.yml --host web1.example.com
# Nur bestimmte Gruppen
ansible-inventory -i inventory.yml --graph webservers
# YAML-Ausgabe (besser lesbar)
ansible-inventory -i inventory.yml --list --yaml
# Variablen für einen Host anzeigen
ansible-inventory -i inventory.yml --host db1.example.com --vars# Alle Hosts anpingen
ansible all -i inventory.yml -m ping
# Connectivity für spezifische Gruppe testen
ansible webservers -i inventory.yml -m setup --limit 1# Dynamische Gruppierung basierend auf Fakten
webservers_nginx:
children:
webservers:
vars:
web_server: nginx
webservers_apache:
children:
webservers:
vars:
web_server: apacheinventories/
├── production/
│ ├── aws.yml
│ └── group_vars/
├── staging/
│ ├── azure.yml
│ └── group_vars/
└── development/
├── hosts.yml
└── group_vars/