20 Statische Inventories

20.1 Aufbau und Syntax einer statischen Inventardatei

Ein statisches Inventory in Ansible ist eine strukturierte Datei, die alle Zielsysteme definiert und organisiert. Es dient als Grundlage für die gezielte Ausführung von Playbooks auf spezifischen Gruppen von Hosts.

20.1.1 Grundlegende Syntax (INI-Format)

Die einfachste Form eines statischen Inventars ist eine INI-Datei mit Hostnamen oder IP-Adressen. Hosts werden in Gruppen organisiert, indem der Gruppenname in eckigen Klammern [] vorangestellt wird.

Einfaches Beispiel:

# Kommentare beginnen mit #

[webservers]
web1.example.com
web2.example.com

[dbservers]
db1.example.com
db2.example.com

# Hosts ohne Gruppe landen automatisch in [ungrouped]
backup.example.com

Syntax-Hinweise: - Leerzeilen zwischen Gruppen verbessern die Lesbarkeit - Kommentare mit # sind möglich - Hosts ohne Gruppenzugehörigkeit werden automatisch in [ungrouped] einsortiert

20.1.2 Verbindungsparameter und Host-Variablen

Ansible bietet spezielle Variablen zur Steuerung der Verbindung zu Remote-Hosts:

Variable	Bedeutung	Beispiel
`ansible_host`	IP oder DNS, falls abweichend vom Hostnamen	`ansible_host=192.168.1.100`
`ansible_port`	SSH-Port (Standard: 22)	`ansible_port=2222`
`ansible_user`	Remote-Benutzer	`ansible_user=deploy`
`ansible_connection`	Verbindungstyp	`ansible_connection=winrm`

Erweiterte Syntax mit Verbindungsparametern:

[webservers]
web1.example.com ansible_user=deploy ansible_port=2222
web2.example.com ansible_host=192.168.1.100 ansible_user=admin

[dbservers]
db1.example.com ansible_connection=ssh ansible_user=dbadmin
db2.example.com ansible_connection=winrm ansible_user=winadmin

[monitoring]
localhost ansible_connection=local

20.2 Gruppierung von Hosts: Struktur und Hierarchie

20.2.1 Vordefinierte Gruppen

[all]: Umfasst automatisch alle Hosts im Inventory
[ungrouped]: Enthält alle Hosts ohne explizite Gruppenzugehörigkeit

20.2.2 Verschachtelte Gruppen mit `[children]`

Komplexe Hierarchien lassen sich mit der :children Syntax erstellen:

[webservers]
web1.example.com
web2.example.com

[dbservers]
db1.example.com
db2.example.com

[loadbalancers]
lb1.example.com
lb2.example.com

# Verschachtelte Gruppen
[frontend:children]
webservers
loadbalancers

[backend:children]
dbservers

[production:children]
frontend
backend

20.3 Variablen: Definition und Prioritäten

20.3.1 Inline-Variablen vs. Verzeichnisstruktur

Inline-Definition (in der Inventory-Datei):

[webservers:vars]
ansible_user=deploy
ntp_server=ntp.web.com
ssl_enabled=true

[production:vars]
ansible_user=admin
backup_schedule=daily

Best Practice: Verzeichnisbasierte Struktur

inventory/
├── hosts.ini                    # Nur Host-Definitionen
├── group_vars/
│   ├── all.yml                  # Variablen für alle Hosts
│   ├── webservers.yml           # Variablen für webservers-Gruppe
│   └── production.yml           # Variablen für production-Gruppe
└── host_vars/
    ├── web1.example.com.yml     # Host-spezifische Variablen
    └── db1.example.com.yml

Beispiel: group_vars/webservers.yml

ansible_user: deploy
ntp_server: ntp.web.com
ssl_enabled: true
max_connections: 100

Beispiel: host_vars/web1.example.com.yml

ansible_port: 2222
server_id: web01
memory_limit: 8GB

20.3.2 Variablenauflösung und Prioritäten

Ansible löst Variablen nach einer festen Prioritätsreihenfolge auf (von niedrig zu hoch):

group_vars/all - Globale Variablen
group_vars/<group> - Gruppenvariablen
host_vars/<host> - Host-spezifische Variablen
Playbook vars - Variablen im Playbook
Rollen defaults/main.yml - Standardwerte von Rollen
Rollen vars/main.yml - Rollenvariablen
Extra Vars (-e) - Kommandozeilen-Parameter (höchste Priorität)

Praktisches Beispiel der Auflösung:

# group_vars/all.yml
ansible_user: default_user

# group_vars/webservers.yml  
ansible_user: web_user

# host_vars/web1.example.com.yml
ansible_user: special_user

Für web1.example.com wird special_user verwendet (Host-Variablen überschreiben Gruppenvariablen).

20.4 Komplexe Inventory-Strukturen

20.4.1 Umgebungsbasierte Organisation

# === ENTWICKLUNGSUMGEBUNG ===
[dev_webservers]
dev-web1.example.com
dev-web2.example.com

[dev_dbservers]
dev-db1.example.com

[development:children]
dev_webservers
dev_dbservers

# === PRODUKTIONSUMGEBUNG ===
[prod_webservers]
prod-web1.example.com ansible_host=10.0.1.10
prod-web2.example.com ansible_host=10.0.1.11

[prod_dbservers]
prod-db1.example.com ansible_host=10.0.2.10
prod-db2.example.com ansible_host=10.0.2.11

[production:children]
prod_webservers
prod_dbservers

# === GLOBALE KATEGORIEN ===
[webservers:children]
dev_webservers
prod_webservers

[dbservers:children]
dev_dbservers
prod_dbservers

# === VARIABLEN ===
[all:vars]
ntp_server=ntp.example.com
timezone=UTC

[development:vars]
ansible_user=dev_user
debug_mode=true

[production:vars]
ansible_user=admin
ssl_required=true

20.4.2 Multi-Datacenter Setup

[dc1_webservers]
dc1-web1.example.com
dc1-web2.example.com

[dc2_webservers]
dc2-web1.example.com
dc2-web2.example.com

[datacenter1:children]
dc1_webservers

[datacenter2:children]
dc2_webservers

[webservers:children]
datacenter1
datacenter2

[datacenter1:vars]
backup_server=backup1.dc1.example.com
dns_server=8.8.8.8

[datacenter2:vars]
backup_server=backup1.dc2.example.com
dns_server=8.8.4.4

20.5 YAML-Format als Alternative

Neben INI unterstützt Ansible auch YAML-Inventories:

# inventory.yml
all:
  children:
    webservers:
      hosts:
        web1.example.com:
          ansible_user: deploy
          ansible_port: 2222
        web2.example.com:
          ansible_host: 192.168.1.100
      vars:
        ntp_server: ntp.web.com
        ssl_enabled: true
    
    dbservers:
      hosts:
        db1.example.com:
        db2.example.com:
      vars:
        ansible_user: dbadmin
    
    production:
      children:
        webservers:
        dbservers:
      vars:
        backup_schedule: daily
  
  vars:
    timezone: UTC

20.6 Inventory-Validierung und -Verwaltung

20.6.1 Ansible-Inventory Kommando

Das ansible-inventory Tool hilft bei der Validierung und Visualisierung:

# Komplette Inventory-Struktur als JSON ausgeben
ansible-inventory -i inventory/hosts.ini --list

# Graphische Darstellung der Gruppen-Hierarchie
ansible-inventory -i inventory/hosts.ini --graph

# Spezifische Gruppe anzeigen
ansible-inventory -i inventory/hosts.ini --list --limit webservers

# Host-spezifische Variablen anzeigen
ansible-inventory -i inventory/hosts.ini --host web1.example.com

20.6.2 Troubleshooting häufiger Fehler

Syntax-Validierung:

# Syntax prüfen
ansible-inventory -i inventory/hosts.ini --list > /dev/null
echo $?  # 0 = OK, 1 = Fehler

Häufige Fehlerquellen: - Fehlende Leerzeichen um = bei Variablenzuweisungen - Ungültige Zeichen in Gruppennamen - Zirkuläre Abhängigkeiten bei :children - Doppelte Host-Definitionen

20.7 Best Practices

20.7.1 Strukturempfehlungen

Trennung von Inventar und Variablen:
- Hosts nur in hosts.ini definieren
- Variablen in group_vars/ und host_vars/

Konsistente Namenskonventionen:

# Gut: Umgebung-Rolle-Nummer
prod-web01.example.com
staging-db02.example.com

# Vermeiden: Inkonsistente Namen
webserver1
database-prod-2

Logische Gruppierung:
- Nach Funktion: webservers, dbservers, loadbalancers
- Nach Umgebung: production, staging, development
- Nach Standort: datacenter1, europe, asia

Dokumentation:

# Produktionsumgebung - Hauptdatacenter
[production]
# Webserver mit Load Balancing
[webservers]
prod-web01.example.com  # Primary web server
prod-web02.example.com  # Secondary web server

20.7.2 Sicherheitsüberlegungen

Sensible Daten (Passwörter, API-Keys) gehören in ansible-vault verschlüsselte Dateien
SSH-Keys verwenden statt Passwörter
Principle of Least Privilege bei Benutzerrechten

20.7.3 Wartung und Skalierung

Regelmäßige Validierung mit ansible-inventory
Automatisierte Tests für Inventory-Änderungen
Versionskontrolle für alle Inventory-Dateien
Bei großen Umgebungen: Dynamische Inventories erwägen