12.4 Playbooks und Inventories in Ansible verstehen

Wer Ansible im Netzwerk sinnvoll einsetzen möchte, muss vor allem zwei Grundbausteine sicher verstehen: Playbooks und Inventories. Genau diese beiden Elemente entscheiden darüber, ob Automatisierung nur aus einzelnen Befehlsfolgen besteht oder zu einem strukturierten, wiederverwendbaren und teamfähigen Betriebsmodell wird. Playbooks beschreiben, welche Aufgaben ausgeführt werden sollen. Inventories definieren, auf welchen Geräten diese Aufgaben laufen und wie diese Geräte logisch gruppiert sind. Für Network Engineers ist dieses Zusammenspiel besonders wichtig, weil Netzwerke selten aus nur einem Router oder Switch bestehen. Stattdessen müssen Änderungen typischerweise auf Gerätegruppen, Standorte, Rollen oder Plattformen abgestimmt werden. Ansible macht das möglich, indem es Ausführungslogik und Zielsysteme klar voneinander trennt.

Warum Playbooks und Inventories im Netzwerk so wichtig sind

Automatisierung braucht Struktur

Einzelne SSH-Kommandos oder kleine Skripte reichen oft für spontane Aufgaben aus. Sobald jedoch mehrere Geräte, wiederkehrende Änderungen oder teamübergreifende Standards ins Spiel kommen, braucht Automatisierung eine saubere Struktur. Genau hier setzen Playbooks und Inventories an.

• Playbooks definieren die Aufgaben und deren Reihenfolge.
• Inventories definieren die Zielgeräte und deren Gruppen.
• Variablen ergänzen Unterschiede zwischen Rollen, Standorten oder Plattformen.
• Templates und Module setzen die eigentliche Logik auf den Geräten um.

Ohne diese Trennung würde ein Ansible-Projekt schnell unübersichtlich. Jede Änderung müsste direkt mit Hostadressen, Plattformdetails und Einzelbefehlen vermischt werden. Das wäre im Ergebnis kaum besser als ein großes, schlecht wartbares Skript.

Netzwerke bestehen aus Gerätegruppen, nicht aus Einzelgeräten

Ein großes Netzwerk wird selten pro Gerät verwaltet. Viel häufiger arbeitet man mit logischen Gruppen wie Access-Switches, Core-Routern, WAN-Edges oder Firewalls. Ein NTP-Standard soll vielleicht auf allen Access-Switches gelten, eine Routing-Änderung aber nur auf Core-Geräten. Genau diese Logik bildet Ansible über Inventories und Playbooks sauber ab.

• Standortgruppen wie BER, HAM oder FRA
• Rollen wie access, distribution, core oder edge
• Plattformen wie ios, nxos oder eos
• Spezielle Gruppen für Migrationen, Tests oder Piloten

Diese Gruppierung ist kein Nebenthema, sondern eine zentrale Voraussetzung für kontrollierte Netzwerkautomatisierung.

Was ein Inventory in Ansible ist

Das Inventory beschreibt die Zielsysteme

Ein Inventory ist die Liste der Systeme, die Ansible kennt und ansprechen kann. Im Netzwerkumfeld sind das typischerweise Router, Switches, Firewalls oder virtuelle Netzwerkgeräte. Das Inventory enthält dabei nicht nur Hostnamen oder IP-Adressen, sondern oft auch Verbindungsparameter, Gruppenzugehörigkeiten und zusätzliche Metadaten.

Ein sehr einfaches Inventory kann so aussehen:

[access_switches]
sw01 ansible_host=192.0.2.10
sw02 ansible_host=192.0.2.11

[core_routers]
rtr01 ansible_host=192.0.2.20
rtr02 ansible_host=192.0.2.21

Dieses Beispiel zeigt bereits die zwei wichtigsten Funktionen:

• Hosts werden eindeutig definiert.
• Hosts werden zu logischen Gruppen zusammengefasst.

Genau dadurch kann ein Playbook später gezielt auf access_switches oder core_routers angewendet werden, ohne jede Geräteadresse im Playbook selbst zu hinterlegen.

Inventories sind mehr als nur Hostlisten

Viele Einsteiger betrachten ein Inventory zunächst als einfache Geräteliste. In produktiven Umgebungen ist das Inventory jedoch oft eine zentrale Steuerungsebene. Hier wird festgelegt, welche Geräte wie angesprochen werden und welche Eigenschaften sie aus Sicht der Automatisierung haben.

• Management-IP oder DNS-Name
• Plattformtyp
• Verbindungsmethode
• Benutzername oder Authentifizierungslogik
• Gruppenzugehörigkeit
• Standort- oder Rollenzuordnung

Dadurch wird das Inventory zu einem entscheidenden Bindeglied zwischen Netzstruktur und Automatisierungslogik.

Typische Inventory-Formate im Netzwerk

INI-ähnliche Inventories

Das klassische Inventory-Format in Ansible erinnert an INI-Dateien und ist besonders für kleine bis mittlere Umgebungen gut lesbar. Es eignet sich gut, um die Grundidee schnell zu verstehen.

Beispiel:

[access_switches]
fra-access-sw01 ansible_host=192.0.2.10
fra-access-sw02 ansible_host=192.0.2.11

[distribution_switches]
fra-dist-sw01 ansible_host=192.0.2.20

Für einfache Automatisierungen reicht dieses Format oft aus. Mit wachsender Komplexität werden jedoch YAML-basierte Inventories oder dynamische Inventories häufig attraktiver.

YAML-basierte Inventories

YAML-basierte Inventories sind strukturierter und besser erweiterbar. Gerade in Netzwerkumgebungen mit vielen Variablen, Plattformen und Metadaten kann das ein klarer Vorteil sein.

Ein Beispiel:

all:
  children:
    access_switches:
      hosts:
        fra-access-sw01:
          ansible_host: 192.0.2.10
        fra-access-sw02:
          ansible_host: 192.0.2.11
    core_routers:
      hosts:
        fra-core-rtr01:
          ansible_host: 192.0.2.20

YAML wirkt auf den ersten Blick ausführlicher, skaliert aber oft besser, wenn zusätzliche Struktur oder Variablen nötig werden.

Gruppen im Inventory sinnvoll nutzen

Rollenbasierte Gruppen

Eine der wichtigsten Best Practices im Netzwerk ist die rollenbasierte Gruppierung. Geräte mit ähnlicher Funktion sollten in gemeinsamen Gruppen zusammengefasst werden. Das macht Playbooks einfacher, klarer und wiederverwendbarer.

• access_switches
• distribution_switches
• core_routers
• wan_routers
• firewalls

So lässt sich ein NTP-Playbook beispielsweise gezielt auf alle Access-Switches anwenden, ohne jede Gerätegruppe einzeln zu nennen.

Standortbasierte Gruppen

Zusätzlich oder alternativ können Geräte nach Standort gruppiert werden. Das ist besonders sinnvoll, wenn Standorte unterschiedliche Parameter haben, etwa VLANs, Syslog-Ziele, DNS-Server oder WAN-spezifische Eigenschaften.

Beispiel:

[berlin]
ber-access-sw01 ansible_host=192.0.2.30
ber-core-rtr01 ansible_host=192.0.2.31

[frankfurt]
fra-access-sw01 ansible_host=192.0.2.10
fra-core-rtr01 ansible_host=192.0.2.20

In größeren Umgebungen ist oft eine Kombination aus Rollen- und Standortgruppen besonders sinnvoll.

Gruppen verschachteln

Ansible erlaubt verschachtelte Gruppen. Damit können komplexere Netzstrukturen sauber modelliert werden. Beispielsweise können alle Access-Switches aus mehreren Standorten zusätzlich in einer übergreifenden Gruppe zusammengeführt werden.

Beispiel:

[fra_access]
fra-access-sw01 ansible_host=192.0.2.10
fra-access-sw02 ansible_host=192.0.2.11

[ber_access]
ber-access-sw01 ansible_host=192.0.2.30

[access_switches:children]
fra_access
ber_access

Diese Struktur ist sehr hilfreich, wenn globale Standards einerseits auf alle Access-Switches und andererseits standortspezifische Aufgaben nur auf Teilgruppen angewendet werden sollen.

Host- und Gruppenvariablen im Inventory

Warum Variablen im Netzwerk so wichtig sind

Netzwerke sind selten vollständig homogen. Auch wenn Geräte gleichartig erscheinen, unterscheiden sie sich oft in Details wie Management-IP, Standort, Plattform oder Rolle. Genau deshalb sind Variablen im Ansible-Umfeld so zentral. Sie erlauben es, dieselbe Playbook-Logik auf unterschiedliche Geräte anzuwenden, ohne alles doppelt zu schreiben.

• Unterschiedliche NTP- oder Syslog-Ziele je Standort
• Andere Plattformparameter für IOS und NX-OS
• Abweichende Interface-Namen oder VRFs
• Gerätespezifische Management-IPs und Hostnamen

Variablen können direkt im Inventory oder in separaten Dateien gepflegt werden. Für kleinere Beispiele ist die direkte Zuordnung im Inventory hilfreich.

Hostvariablen

Hostvariablen gelten nur für ein einzelnes Gerät. Das ist nützlich, wenn ein bestimmter Wert nicht aus der Gruppe ableitbar ist.

Beispiel:

[core_routers]
fra-core-rtr01 ansible_host=192.0.2.20 loopback_ip=10.255.0.1
fra-core-rtr02 ansible_host=192.0.2.21 loopback_ip=10.255.0.2

Solche Variablen können im Playbook oder Template direkt verwendet werden.

Gruppenvariablen

Gruppenvariablen gelten für alle Hosts einer Gruppe. Das ist besonders praktisch für standardisierte Netzwerkparameter.

Beispiel:

[access_switches:vars]
ansible_network_os=ios
ansible_connection=network_cli
ntp_server_1=10.10.10.10
ntp_server_2=10.10.10.11

Damit wird sofort klar: Alle Geräte dieser Gruppe nutzen dieselbe Plattformlogik und dieselben NTP-Standards.

Was ein Playbook in Ansible ist

Playbooks beschreiben die Automatisierungslogik

Ein Playbook ist eine YAML-Datei, die definiert, welche Aufgaben auf welchen Geräten ausgeführt werden sollen. Ein Playbook besteht aus einem oder mehreren Plays. Jedes Play enthält mindestens eine Zielgruppe und eine Liste von Tasks.

Ein minimales Beispiel:

---
- name: Interface-Status anzeigen
  hosts: access_switches
  gather_facts: no
  tasks:
    - name: Show ip interface brief ausfuehren
      ios_command:
        commands:
          - show ip interface brief

Dieses Playbook ist bewusst einfach, zeigt aber die Grundstruktur klar:

• name beschreibt das Play.
• hosts definiert die Zielgruppe aus dem Inventory.
• tasks enthält die auszuführenden Aufgaben.

Playbooks sind deklarativ aufgebaut

Im Gegensatz zu einem klassischen Python-Skript beschreibt ein Playbook eher, was getan werden soll, statt jeden technischen Ablauf programmatisch im Detail zu definieren. Gerade für Network Engineers ist das oft ein großer Vorteil, weil der Fokus stärker auf der Netzwerklogik liegt.

Die Grundstruktur eines Playbooks verstehen

Der hosts-Bereich

Mit hosts wird festgelegt, auf welche Geräte oder Gruppen ein Play angewendet wird. Hier zeigt sich sofort, warum das Inventory so wichtig ist: Ohne saubere Gruppen wäre jedes Playbook unnötig starr.

Beispiele:

hosts: access_switches
hosts: core_routers
hosts: berlin

Der hosts-Eintrag verbindet also die Ausführungslogik des Playbooks mit der Zieldefinition aus dem Inventory.

Tasks als eigentliche Arbeitsschritte

Tasks sind die einzelnen Aufgaben innerhalb eines Plays. Sie können Show-Befehle ausführen, Konfigurationszeilen setzen, Ergebnisse speichern oder Entscheidungen treffen.

Ein einfaches Beispiel:

tasks:
  - name: NTP konfigurieren
    ios_config:
      lines:
        - ntp server 10.10.10.10
        - ntp server 10.10.10.11

Jeder Task sollte klar benannt sein. Gute Task-Namen verbessern Lesbarkeit, Debugging und Teamfähigkeit erheblich.

gather_facts im Netzwerk richtig einordnen

In klassischen Server-Automatisierungen sammelt Ansible oft automatisch Systeminformationen. Im Netzwerkbereich wird gather_facts häufig deaktiviert oder gezielt gesteuert, weil andere Mechanismen und Module für Netzgeräte typischer sind.

Deshalb sieht man in Netzwerk-Playbooks oft:

gather_facts: no

Das ist kein Nachteil, sondern schlicht eine Anpassung an die Besonderheiten von Netzwerkgeräten.

Typische Netzwerk-Playbooks in der Praxis

Show-Befehle ausführen

Ein häufiger Einstieg in Ansible ist das automatisierte Ausführen von Show-Befehlen. Das eignet sich sehr gut für Bestandsaufnahmen, Vorabprüfungen und Reports.

Beispiel:

---
- name: Versionen auf Access-Switches prüfen
  hosts: access_switches
  gather_facts: no
  tasks:
    - name: Show version ausfuehren
      ios_command:
        commands:
          - show version
      register: version_output

    - name: Ausgabe anzeigen
      debug:
        var: version_output.stdout_lines

Hier sieht man bereits einen wichtigen Mechanismus: Das Ergebnis eines Tasks wird mit register in einer Variablen gespeichert und kann später weiterverwendet werden.

Konfigurationen ändern

Für Konfigurationsänderungen werden häufig Module wie ios_config verwendet. Damit lassen sich Standardparameter gezielt ausrollen.

Beispiel:

---
- name: Syslog konfigurieren
  hosts: access_switches
  gather_facts: no
  tasks:
    - name: Logging-Hosts setzen
      ios_config:
        lines:
          - logging host 10.20.20.20
          - logging host 10.20.20.21

Genau solche Playbooks sind in der Praxis besonders wertvoll, weil sie viele gleichartige Geräte konsistent behandeln können.

Kontextbezogene Konfiguration mit parents

Für hierarchische CLI-Kontexte, etwa Interfaces oder Routing-Prozesse, ist der Einsatz von parents hilfreich.

Beispiel:

---
- name: Interface-Beschreibung setzen
  hosts: core_routers
  gather_facts: no
  tasks:
    - name: Uplink konfigurieren
      ios_config:
        parents: interface GigabitEthernet0/1
        lines:
          - description Uplink-to-Core
          - no shutdown

Dadurch wird sauber beschrieben, in welchem CLI-Kontext die untergeordneten Zeilen gesetzt werden.

Wie Playbooks und Inventories zusammenwirken

Das Inventory definiert das Ziel, das Playbook die Aufgabe

Das Zusammenspiel ist einfach, aber zentral: Das Inventory sagt Ansible, welche Geräte existieren und wie sie gruppiert sind. Das Playbook sagt Ansible, was auf diesen Gruppen oder Hosts passieren soll. Erst beides zusammen ergibt eine belastbare Automatisierung.

Beispielhaft:

• Das Inventory enthält die Gruppe access_switches.
• Das Playbook adressiert genau diese Gruppe.
• Ein Task rollt NTP-Parameter aus.
• Variablen sorgen dafür, dass Werte flexibel bleiben.

Diese Trennung erhöht die Wiederverwendbarkeit stark. Dasselbe Playbook kann mit einem anderen Inventory in einer Testumgebung, in einem anderen Standort oder auf einer Pilotgruppe verwendet werden.

Skalierung durch Gruppierung und Wiederverwendung

Ein sauber aufgebautes Inventory erlaubt es, mit wenigen Änderungen sehr unterschiedliche Zielgruppen anzusprechen. Genau das macht Ansible im Netzwerk so effizient. Ein NTP-Playbook muss nicht neu geschrieben werden, nur weil statt Frankfurt plötzlich Berlin oder nur die Distribution-Switches behandelt werden sollen.

Typische Fehler beim Verständnis von Playbooks und Inventories

Zu viel Logik direkt im Inventory

Ein häufiger Fehler ist, immer mehr fachliche Logik in das Inventory zu verlagern. Das Inventory sollte vor allem Geräte, Gruppen und grundlegende Variablen beschreiben. Komplexe Change-Logik oder Prozessentscheidungen gehören in Playbooks, Rollen oder Templates.

• Inventory für Struktur und Zielsysteme
• Playbooks für Aufgaben und Abläufe
• Templates für Konfigurationsdarstellung
• Variablen für flexible Werte

Je klarer diese Trennung, desto besser bleibt die Automatisierung wartbar.

Playbooks zu eng auf einzelne Hosts zuschneiden

Wer Playbooks direkt für Einzelgeräte schreibt, verschenkt einen großen Teil der Stärke von Ansible. Playbooks sollten möglichst auf Gruppen, Rollen oder standardisierte Muster ausgerichtet sein. Einzelhosts sind eher Ausnahmen.

Inventories ohne saubere Gruppierungslogik

Ein flaches Inventory mit vielen Hosts, aber ohne sinnvolle Gruppen, erschwert jede Wiederverwendung. Gerade in Netzwerken sollte Gruppierung bewusst geplant sein.

• nach Standort,
• nach Rolle,
• nach Plattform,
• oder nach Change-Relevanz.

Ohne solche Struktur werden Playbooks unnötig kompliziert.

Best Practices für Inventories im Netzwerk

Nach Rollen und Standorten strukturieren

Die sinnvollste Grundstruktur ergibt sich meist aus einer Kombination aus Rollen- und Standortlogik. Dadurch lassen sich sowohl globale Standards als auch lokale Besonderheiten sauber abbilden.

• Access-, Distribution- und Core-Gruppen definieren
• Standortgruppen wie berlin, hamburg oder frankfurt anlegen
• Kindergruppen für gemeinsame Obergruppen nutzen
• Plattformen zusätzlich sauber kennzeichnen

Verbindungsparameter konsistent pflegen

Gerade im Netzwerkumfeld ist es wichtig, Verbindungsparameter sauber und konsistent zu halten. Dazu gehören Plattformtyp, Verbindungsmethode und gegebenenfalls Authentifizierungslogik.

Typische Variablen:

ansible_connection=network_cli
ansible_network_os=ios
ansible_user=admin

Diese Angaben helfen Ansible, das passende Verhalten für Netzwerkgeräte zu nutzen.

Best Practices für Playbooks im Netzwerk

Klare, kleine und verständliche Plays bauen

Ein gutes Playbook ist nicht unnötig komplex. Besonders im Netzwerkbereich lohnt es sich, kleine, gut lesbare Playbooks für klar definierte Aufgaben zu bauen.

• ein Playbook für NTP,
• ein Playbook für Syslog,
• ein Playbook für Backups,
• ein Playbook für Read-Only-Checks.

So bleiben Aufgaben überschaubar und besser prüfbar.

Tasks sauber benennen

Jeder Task sollte einen präzisen Namen haben. Das erleichtert Ausführung, Fehlersuche und Teamarbeit enorm. Gerade bei größeren Rollouts ist es wichtig, im Laufprotokoll sofort zu erkennen, was gerade passiert.

Read-Only vor Write-Operations

Für Einsteiger und auch für produktive Teams ist es sinnvoll, zunächst Read-Only-Playbooks zu entwickeln. Damit lassen sich Inventar, Verbindungen und Grundlogik testen, bevor schreibende Änderungen ausgerollt werden.

Typische Read-Only-Beispiele:

show version
show ip interface brief
show running-config | include ntp

Erst danach sollten produktive Konfigurations-Tasks folgen.

Variablen statt Hardcoding verwenden

Werte wie NTP-Server, Syslog-Ziele oder Standortparameter sollten nicht fest im Playbook kodiert werden, wenn sie sich logisch als Variablen ausdrücken lassen. Das erhöht Wiederverwendbarkeit und reduziert Pflegeaufwand.

Playbooks, Inventories und Templates gemeinsam denken

Die eigentliche Stärke entsteht im Zusammenspiel

Playbooks und Inventories sind die Grundlage, aber ihre volle Wirkung entfalten sie erst zusammen mit Variablen und Templates. Gerade in Netzwerken mit wiederkehrenden Konfigurationsmustern ist diese Kombination besonders mächtig.

• Inventory liefert Zielsysteme und Gruppierung.
• Variablen liefern Unterschiede und Standards.
• Templates erzeugen konsistente Konfigurationsblöcke.
• Playbooks führen die Aufgaben kontrolliert aus.

Dieses Zusammenspiel macht aus einzelnen Automatisierungsjobs ein wiederverwendbares Betriebsmodell.

Ein Beispiel für ein standardisiertes Interface-Template

interface {{ interface_name }}
 description {{ description }}
 switchport mode access
 switchport access vlan {{ vlan_id }}
{% if portfast %} spanning-tree portfast {% endif %}

Das Playbook ruft dieses Template auf, Variablen liefern die Werte, und das Inventory legt fest, auf welchen Geräten der Task läuft. Genau das ist die eigentliche Stärke von Ansible im Netzwerk.

Best Practices für Playbooks und Inventories in Ansible

• Inventories logisch nach Rollen, Standorten und Plattformen strukturieren.
• Playbooks auf Gruppen statt auf Einzelhosts ausrichten.
• Host- und Gruppenvariablen gezielt statt willkürlich einsetzen.
• Playbooks klein, klar und gut benannt halten.
• Read-Only-Use-Cases zuerst automatisieren, bevor produktive Write-Tasks folgen.
• Konfigurationslogik nicht im Inventory verstecken, sondern sauber in Playbooks und Templates trennen.
• Wiederkehrende Aufgaben standardisieren und mehrfach nutzbar machen.
• Verbindungsparameter im Inventory konsistent pflegen.
• Templates, Variablen und Playbooks bewusst gemeinsam designen.
• Inventories und Playbooks versionieren und im Team reviewen.

Damit werden Playbooks und Inventories in Ansible zu weit mehr als nur technischen Dateien. Sie bilden zusammen das organisatorische und technische Fundament dafür, dass Netzwerkautomatisierung lesbar, steuerbar, wiederverwendbar und auf viele Geräte skalierbar wird. Genau dieses Verständnis ist entscheidend, wenn Ansible im Netzwerk nicht nur für Einzelaufgaben, sondern als belastbares Betriebswerkzeug eingesetzt werden soll.

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab/GNS3

Ich biete professionelle Unterstützung im Bereich Netzwerkkonfiguration und Network Automation für private Anforderungen, Studienprojekte, Lernlabore, kleine Unternehmen sowie technische Projekte. Ich unterstütze Sie bei der Konfiguration von Routern und Switches, der Erstellung praxisnaher Topologien in Cisco Packet Tracer, dem Aufbau und Troubleshooting von GNS3- und EVE-NG-Labs sowie bei der Automatisierung von Netzwerkaufgaben mit Netmiko, Paramiko, NAPALM und Ansible. Kontaktieren Sie mich jetzt – klicken Sie hier.

Meine Leistungen umfassen:

• Professionelle Konfiguration von Routern und Switches

• Einrichtung von VLANs, Trunks, Routing, DHCP, NAT, ACLs und weiteren Netzwerkfunktionen

• Erstellung von Topologien und Simulationen in Cisco Packet Tracer

• Aufbau, Analyse und Fehlerbehebung von Netzwerk-Labs in GNS3 und EVE-NG

• Automatisierung von Netzwerkkonfigurationen mit Python, Netmiko, Paramiko, NAPALM und Ansible

• Erstellung von Skripten für wiederkehrende Netzwerkaufgaben

• Dokumentation der Konfigurationen und Bereitstellung nachvollziehbarer Lösungswege

• Konfigurations-Backups, Optimierung bestehender Setups und technisches Troubleshooting

Benötigen Sie Unterstützung bei Ihrem Netzwerkprojekt, Ihrer Simulation oder Ihrer Network-Automation-Lösung? Kontaktieren Sie mich jetzt – klicken Sie hier.