12.3 Ansible für Netzwerke einfach erklärt

Ansible hat sich zu einem der wichtigsten Werkzeuge für Netzwerkautomatisierung entwickelt, weil es wiederkehrende Aufgaben auf Routern, Switches, Firewalls und anderen Infrastrukturkomponenten strukturiert, lesbar und vergleichsweise einfach automatisierbar macht. Für viele Network Engineers ist Ansible besonders attraktiv, weil es keinen Agenten auf den Netzwerkgeräten benötigt und sich gut in bestehende SSH-basierte Betriebsmodelle einfügt. Statt Änderungen manuell auf jedem Gerät einzeln per CLI durchzuführen, lassen sich Konfigurationsstandards, Read-Only-Prüfungen, Backups und kontrollierte Rollouts zentral definieren und wiederholt ausführen. Gerade in wachsenden Netzwerken mit vielen ähnlichen Geräten schafft Ansible damit eine solide Brücke zwischen klassischem Network Engineering und moderner Automatisierung.

Was Ansible grundsätzlich ist

Ansible als Automatisierungsplattform

Ansible ist ein Automatisierungswerkzeug, das Aufgaben in Form sogenannter Playbooks beschreibt und diese auf definierte Zielsysteme ausführt. Im Netzwerkumfeld sind diese Zielsysteme typischerweise Router, Switches, Firewalls, WLAN-Controller oder virtuelle Netzwerkkomponenten. Die Automatisierung erfolgt deklarativ und aufgabenorientiert: Statt jede Aktion in einem Programmablauf selbst zu schreiben, beschreibt man in YAML-Dateien, was auf welchen Geräten geschehen soll.

• Konfigurationen ausrollen
• Show-Befehle automatisiert ausführen
• Konfigurationsstände sichern
• Standardparameter vereinheitlichen
• Compliance- oder Drift-Prüfungen durchführen
• Vorher-Nachher-Validierungen einbauen

Für Network Engineers ist dabei besonders wichtig, dass Ansible nicht zwingend wie eine klassische Programmiersprache genutzt werden muss. Es arbeitet mit klar strukturierten Playbooks, Inventaren und Variablen, was den Einstieg oft einfacher macht als der direkte Aufbau größerer Python-Automatisierungen.

Agentenloser Ansatz als praktischer Vorteil

Ein großer Pluspunkt von Ansible ist der agentenlose Ansatz. Auf den Netzwerkgeräten muss in der Regel keine zusätzliche Software installiert werden. Stattdessen verbindet sich Ansible über vorhandene Management-Protokolle mit den Geräten, häufig über SSH. Das reduziert den Einführungsaufwand und passt gut zu klassischen Netzwerkumgebungen.

Typische CLI-Grundlagen auf Netzwerkgeräten bleiben deshalb relevant, etwa für SSH:

ip domain-name example.local
crypto key generate rsa modulus 2048
ip ssh version 2

Ansible ersetzt also nicht die Management-Basis des Geräts, sondern nutzt sie systematisch für Automatisierungsprozesse.

Warum Ansible im Netzwerk so beliebt ist

Lesbarkeit und niedrige Einstiegshürde

Im Vergleich zu vielen individuell entwickelten Skripten ist Ansible für Netzwerkteams oft leichter zugänglich. Playbooks werden in YAML beschrieben, was für viele Engineers besser lesbar ist als komplexerer Programmcode. Gerade bei wiederkehrenden Standardaufgaben kann das ein großer Vorteil sein.

• Playbooks sind oft selbsterklärend strukturiert.
• Aufgaben lassen sich schrittweise aufbauen.
• Variablen und Zielgruppen sind klar erkennbar.
• Auch Teammitglieder ohne tiefe Python-Erfahrung können Inhalte verstehen.

Diese Lesbarkeit macht Ansible besonders teamfähig. Änderungen an Automatisierungslogik bleiben nachvollziehbarer, Reviews werden einfacher und Wissenssilos reduzieren sich eher als bei individuell gewachsenen Einzel-Skripten.

Gut geeignet für Multi-Device-Aufgaben

Ansible ist besonders stark, wenn dieselbe oder eine ähnliche Aufgabe auf vielen Geräten wiederholt werden soll. Genau solche Szenarien sind im Netzwerkalltag häufig:

• Neue NTP-Server auf allen Access-Switches setzen
• Syslog-Ziele netzweit vereinheitlichen
• SNMP- oder AAA-Standards anpassen
• Backups von Konfigurationen einsammeln
• Show-Befehle auf Gerätegruppen ausführen

Für diese Aufgaben bringt Ansible bereits eine geeignete Struktur mit: Inventare für Zielsysteme, Variablen für Unterschiede und Module für wiederkehrende Netzwerktätigkeiten.

Die wichtigsten Bausteine von Ansible im Netzwerk

Inventar

Das Inventar beschreibt, welche Geräte von Ansible verwaltet werden. Hier werden Hosts, Gruppen und häufig auch Verbindungsparameter definiert. Im Netzwerkumfeld werden Geräte oft nach Rolle, Standort oder Plattform gruppiert.

Ein einfaches Inventar 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

Diese Struktur ist wichtig, weil Ansible selten nur auf einem Gerät arbeitet. Meist geht es um ganze Gerätegruppen, etwa alle Access-Switches eines Standorts oder alle WAN-Router einer Region.

Playbooks

Playbooks sind das Herzstück von Ansible. Sie beschreiben, welche Aufgaben auf welchen Zielsystemen ausgeführt werden. Ein Playbook besteht meist aus einem oder mehreren Plays. Jedes Play definiert Zielgruppe, Variablen und Aufgaben.

Ein einfaches Netzwerk-Playbook:

---
- name: NTP auf Access-Switches konfigurieren
  hosts: access_switches
  gather_facts: no
  tasks:
    - name: NTP-Server setzen
      ios_config:
        lines:
          - ntp server 10.10.10.10
          - ntp server 10.10.10.11

Schon dieses kleine Beispiel zeigt den Grundgedanken: Zielgruppe, Aufgabe und gewünschte Änderung sind klar voneinander getrennt.

Module

Module sind die eigentlichen Funktionsbausteine von Ansible. Im Netzwerkbereich gibt es Module zum Ausführen von Show-Befehlen, zum Ändern von Konfigurationen, zum Verwalten bestimmter Objektarten oder zum Abrufen strukturierter Daten.

• ios_config für Konfigurationsänderungen auf Cisco IOS/IOS XE
• ios_command für Show-Befehle
• plattformbezogene Module für NX-OS, EOS, Junos und weitere Systeme
• allgemeine Module für Dateien, Variablen und Logik

Die Auswahl des richtigen Moduls ist wichtig, weil davon abhängt, ob eine Aufgabe eher CLI-nah, objektorientiert oder deklarativ umgesetzt wird.

Variablen

Variablen machen Playbooks flexibel. Sie erlauben es, Unterschiede zwischen Standorten, Rollen oder Geräten sauber abzubilden, ohne dieselbe Logik mehrfach schreiben zu müssen.

Ein einfaches Beispiel:

ntp_servers:
  - 10.10.10.10
  - 10.10.10.11

Im Playbook kann diese Variable dann genutzt werden, um Konfigurationsblöcke dynamisch zu erzeugen oder Entscheidungen zu treffen.

Wie Ansible mit Netzwerkgeräten kommuniziert

SSH als häufigster Transportweg

In klassischen Netzwerkumgebungen kommuniziert Ansible häufig über SSH mit den Geräten. Das ist besonders praktisch, weil SSH in den meisten Infrastrukturen ohnehin als Standard für das Management etabliert ist. Im Hintergrund setzt Ansible je nach Modul und Plattform auf bestimmte Verbindungsarten und Bibliotheken.

Typische Voraussetzungen auf Cisco-Geräten:

line vty 0 4
 transport input ssh
 login local
 exec-timeout 10 0

Zusätzlich werden in Ansible häufig Verbindungsparameter definiert, etwa Plattformtyp, Benutzername oder Transportmethode.

CLI-orientiert und API-orientiert möglich

Ansible ist nicht auf reine CLI-Kommunikation beschränkt. Viele Netzwerkaufgaben laufen zwar weiterhin SSH- und CLI-nah, doch Ansible kann auch mit API-basierten Schnittstellen wie NETCONF oder REST APIs arbeiten, sofern passende Module oder Sammlungen vorhanden sind.

Das macht Ansible flexibel:

• klassische CLI-Automatisierung für bestehende Umgebungen
• strukturierte API-Nutzung für modernere Plattformen
• hybride Betriebsmodelle in derselben Tool-Landschaft

Typische Ansible-Anwendungsfälle im Netzwerk

Show-Befehle auf vielen Geräten ausführen

Ein sehr häufiger Einstieg in Ansible besteht darin, Read-Only-Aufgaben zu automatisieren. Dazu gehört das Sammeln von Zustandsdaten oder Konfigurationsinformationen auf vielen Geräten. So können Inventarisierung, Audits oder Vorher-Nachher-Prüfungen effizient umgesetzt werden.

Beispiel:

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

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

Solche Aufgaben sind risikoarm und liefern schnell praktischen Nutzen.

Standardisierte Basisparameter ausrollen

Ein klassischer produktiver Use Case ist das Setzen oder Vereinheitlichen globaler Standardparameter. Dazu zählen NTP, Syslog, DNS, SNMP oder grundlegende Management-Einstellungen.

• NTP-Server auf vielen Geräten setzen
• Syslog-Ziele standardisieren
• AAA- oder SSH-Basisparameter vereinheitlichen
• Banner oder Management-ACLs ausrollen

Gerade solche Änderungen eignen sich gut für Ansible, weil sie über viele Geräte hinweg sehr ähnlich sind.

Backups und Konfigurationssicherung

Ansible wird auch häufig genutzt, um Running-Configs, Show-Ausgaben oder andere Gerätestände regelmäßig zu sichern. Das kann entweder direkt in Dateien geschrieben oder mit Versionsverwaltung und zentralen Ablagesystemen kombiniert werden.

CLI-orientierte Grundlage auf dem Gerät bleibt dabei etwa:

show running-config
show startup-config

Ansible übernimmt die Verteilung der Tasks und die zentrale Sammlung der Ergebnisse.

Compliance-Checks und Drift-Erkennung

Ein weiterer wichtiger Einsatzbereich ist die Prüfung, ob Geräte einem gewünschten Standard entsprechen. Ansible kann Konfigurationsdaten auslesen, mit definierten Sollwerten vergleichen und Berichte oder Folgeaktionen anstoßen.

• SSH statt Telnet aktiv?
• NTP-Server korrekt gesetzt?
• Syslog überall vorhanden?
• Interface-Beschreibungen nach Standard gepflegt?

Besonders in Kombination mit Inventar, Variablen und Templates wird Ansible hier zu einem leistungsfähigen Werkzeug für standardisierten Netzbetrieb.

Konfigurationsänderungen mit Ansible

Der Einsatz von ios_config und ähnlichen Modulen

Für Cisco-Umgebungen ist ios_config eines der wichtigsten Module. Es erlaubt das Senden von Konfigurationszeilen oder Konfigurationsblöcken und eignet sich gut für wiederkehrende Standardänderungen.

Beispiel:

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

Dieser Ansatz ist deutlich nachvollziehbarer als eine Vielzahl manueller SSH-Sitzungen und Copy-and-Paste-Änderungen.

Konfigurationsblöcke und Parents

Für hierarchische Konfigurationsbereiche lassen sich in Ansible auch Parents und strukturierte Blöcke verwenden. Das ist besonders nützlich für Interfaces, Routing-Prozesse oder ACL-Kontexte.

Ein Interface-Beispiel:

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

Dadurch wird klar, in welchem Konfigurationskontext die Änderung stattfindet.

Warum Ansible für Netzwerkteams oft gut geeignet ist

Deklarative Arbeitsweise statt komplexer Programmstruktur

Viele Network Engineers schätzen an Ansible, dass der Fokus auf dem gewünschten Ergebnis liegt und nicht zwingend auf detaillierter Programmierung. Ein Playbook beschreibt eher, was auf welchen Geräten passieren soll, als wie jeder Einzelschritt algorithmisch verarbeitet wird.

• Weniger Boilerplate-Code
• Mehr Fokus auf Netzwerklogik
• Gute Lesbarkeit in Teamumgebungen
• Schneller Weg von der Idee zum produktiven Ablauf

Das macht Ansible besonders attraktiv für Teams, die praxisnahe Automatisierung aufbauen wollen, ohne sofort in tiefe Softwareentwicklung einzusteigen.

Gute Skalierung für wiederkehrende Aufgaben

Ansible spielt seine Stärken besonders bei regelmäßigen und standardisierten Tasks aus. Sobald mehrere ähnliche Geräte nach gemeinsamen Regeln verwaltet werden sollen, ist Ansible oft deutlich effizienter als Einzel-Skripte oder rein manuelle CLI-Arbeit.

• Gerätegruppen gezielt adressieren
• Standortspezifische Variablen einbinden
• Wiederkehrende Tasks zentral pflegen
• Änderungen auf viele Geräte konsistent anwenden

Wichtige Begriffe für den praktischen Einsatz

Idempotenz

Ein zentrales Ziel moderner Automatisierung ist Idempotenz. Gemeint ist, dass eine Aufgabe mehrfach ausgeführt werden kann, ohne ungewollte Nebeneffekte zu erzeugen. Im Netzwerkumfeld ist das besonders wichtig, weil Playbooks regelmäßig erneut laufen und dabei möglichst nur tatsächliche Abweichungen korrigieren sollen.

In der Praxis ist Idempotenz nicht bei jeder CLI-nahen Aufgabe automatisch perfekt gegeben, aber Ansible hilft durch seine Struktur dabei, kontrollierter und konsistenter zu arbeiten als reine manuelle Änderungen.

Check Mode und Dry Runs

Ein sehr nützliches Ansible-Konzept ist der Check Mode. Er erlaubt, geplante Änderungen zu simulieren, ohne sie tatsächlich anzuwenden. Nicht jedes Modul unterstützt das gleich gut, aber dort, wo es funktioniert, ist es ein starkes Werkzeug für sichere Change-Prozesse.

• Vorab prüfen, welche Änderungen geplant wären
• Risiken vor produktiven Rollouts reduzieren
• Änderungen besser dokumentieren
• Freigaben fundierter vorbereiten

Register und Conditionals

Ansible kann Ergebnisse von Tasks in Variablen speichern und anschließend weiterverwenden. Dadurch lassen sich Prüfungen, Abhängigkeiten und Validierungsschritte in Playbooks integrieren.

So können zum Beispiel Show-Ausgaben gesammelt und nur bei bestimmten Ergebnissen weitere Schritte ausgeführt werden.

Grenzen von Ansible im Netzwerkbetrieb

Nicht jede Aufgabe ist deklarativ optimal lösbar

Obwohl Ansible für viele Netzwerkaufgaben hervorragend geeignet ist, ist es nicht in jedem Szenario das beste Werkzeug. Sehr spezielle Sonderlogik, komplexe Parsing-Anforderungen oder ungewöhnliche API-Workflows lassen sich manchmal in Python direkter und sauberer umsetzen.

• Komplexe Spezialfälle brauchen oft zusätzliche Skripte
• Stark individuelle Datenverarbeitung ist manchmal einfacher in Python
• Plattformunterschiede können Playbooks komplexer machen

In der Praxis ist deshalb eine Kombination aus Ansible und ergänzenden Skripten häufig sinnvoll.

Gute Datenbasis bleibt Voraussetzung

Ansible allein löst keine schlechten Inventare, keine widersprüchlichen Standards und keine ungepflegten Netzstrukturen. Ohne klare Rollen, saubere Variablen und definierte Soll-Zustände kann auch ein Ansible-Ansatz schnell unübersichtlich werden.

• Inventar muss gepflegt sein
• Variablen müssen konsistent sein
• Standards sollten vor dem Rollout klar definiert sein
• Write-Tasks brauchen Validierung und Rollback-Überlegungen

Typischer Einstieg mit Ansible im Netzwerk

Mit Read-Only und einfachen Standards beginnen

Ein praxisnaher Einstieg startet meist nicht mit komplexen End-to-End-Rollouts, sondern mit überschaubaren Aufgaben. So kann das Team den Umgang mit Playbooks, Inventar und Modulen lernen, ohne sofort hohe Produktionsrisiken einzugehen.

• Show-Befehle automatisiert sammeln
• Konfigurationen sichern
• NTP- oder Syslog-Standards ausrollen
• Read-Only-Compliance-Checks etablieren

Dieser Weg ist meist erfolgreicher als der Versuch, sofort hochkomplexe Automatisierungsframeworks für alle Netzbereiche gleichzeitig einzuführen.

Schrittweise Reife aufbauen

Mit wachsender Erfahrung lässt sich Ansible dann um weitere Bausteine ergänzen:

• Jinja2-Templates für Konfigurationsgenerierung
• Git für Versionsverwaltung
• Source of Truth für Inventardaten
• Vorher-Nachher-Validierungen
• Rollen und wiederverwendbare Task-Strukturen

So entsteht aus einfachen Playbooks nach und nach ein belastbares Automatisierungsmodell für den Netzwerkbetrieb.

Best Practices für Ansible im Netzwerk

• Mit kleinen, klaren und risikoarmen Use Cases beginnen.
• Inventar logisch nach Rolle, Standort oder Plattform strukturieren.
• Read-Only-Tasks zuerst etablieren, bevor produktive Write-Changes automatisiert werden.
• Variablen, Templates und Playbooks sauber voneinander trennen.
• Standardänderungen wie NTP, Syslog oder Management-Parameter als erste Write-Use-Cases wählen.
• Konfigurationsänderungen immer mit Validierung und möglichst auch Post-Checks kombinieren.
• Playbooks in Git versionieren und im Team reviewen.
• Check Mode und strukturierte Tests nutzen, wenn Module das sinnvoll unterstützen.
• Plattformspezifische Unterschiede bewusst berücksichtigen und nicht verstecken.
• Ansible mit Python, Templates und Source-of-Truth-Werkzeugen ergänzen, statt es isoliert zu betrachten.

Damit wird Ansible für Netzwerke zu einem sehr praxisnahen Werkzeug: Es verbindet die vertraute Welt des Network Engineering mit einer strukturierteren, teamfähigeren und skalierbaren Form der Automatisierung. Gerade für wiederkehrende Aufgaben, standardisierte Rollouts und kontrollierte Änderungen ist Ansible deshalb für viele Netzwerkteams einer der sinnvollsten Einstiege in moderne Automatisierung.

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.