Ansible für Netzwerk-Switches: Ein praktischer Einstieg für Event-Techniker

Wer im Veranstaltungsbetrieb Netzwerke konfiguriert, kennt das Szenario: Ein Event steht bevor, zehn Switches warten auf ihre Grundkonfiguration, und irgendjemand muss sich jetzt durch zehn Weboberflächen oder zehn SSH-Sessions klicken — Schritt für Schritt, Switch für Switch. Wer einen Fehler macht, fängt von vorne an. Wer fertig ist, hat keine Garantie, dass alle Configs wirklich identisch sind.

Genau hier setzt Ansible an.

Dieser Artikel erklärt, was Ansible ist, wie es im Kontext von Netzwerk-Switches funktioniert, und wie man ein erstes Playbook aufbaut — auch ohne vorherige Erfahrung mit Automatisierungstools.

Was ist Ansible?

Ansible ist ein Open-Source-Automatisierungstool, das von Red Hat entwickelt wird. Es ermöglicht, wiederkehrende Aufgaben — wie das Konfigurieren von Servern, Netzwerkgeräten oder ganzen Infrastrukturen — in einer strukturierten, lesbaren Form zu beschreiben und automatisch auszuführen.

Der entscheidende Unterschied zu einem Script: Ansible-Playbooks sind deklarativ. Das bedeutet, man beschreibt nicht wie etwas ausgeführt werden soll, sondern was der gewünschte Zustand ist. Ansible übernimmt die Ausführung.

Für Nicht-Techniker: Stell dir Ansible wie ein Rezept vor, das sich selbst kocht. Du schreibst einmal auf, wie ein Switch konfiguriert sein soll — und Ansible sorgt dafür, dass alle Switches genau so aussehen. Egal ob fünf oder fünfzig.

Warum Ansible für Event-Netzwerke?

Event-Netzwerke haben ein spezifisches Problem: Sie entstehen unter Zeitdruck, werden selten dokumentiert, und müssen trotzdem zuverlässig funktionieren.

Das führt zu einem Muster, das in der Branche weit verbreitet ist:

• Eine Person konfiguriert das Netzwerk — meistens dieselbe Person, die es auch beim letzten Event gemacht hat
• Die Konfiguration existiert nirgendwo schriftlich
• Wenn etwas schiefgeht, beginnt das Troubleshooting von vorne

Ansible löst das nicht durch mehr Disziplin oder bessere Dokumentationsgewohnheiten — sondern durch einen anderen Ansatz: Die Konfiguration ist das Dokument. Ein Playbook, das ein Netzwerk aufbaut, ist gleichzeitig die vollständige, versionierbare Beschreibung dieses Netzwerks.

Dazu kommen die messbaren Vorteile im Alltag:

• Zeitersparnis: Was manuell 10–15 Minuten pro Switch kostet, läuft automatisiert in Sekunden durch
• Fehlerreduzierung: Kein Tippfehler, kein vergessener VLAN-Eintrag
• Reproduzierbarkeit: Jedes Event startet mit derselben Ausgangskonfiguration
• Übergabe: Jeder im Team kann das Playbook ausführen — nicht nur derjenige, der es geschrieben hat

Die Grundbegriffe

Bevor wir ins Playbook gehen, kurz die wichtigsten Konzepte:

Control Node Der Rechner, auf dem Ansible läuft — meistens ein Laptop oder ein Server. Von hier aus werden alle Aktionen gestartet. Auf den Switches selbst muss nichts installiert werden.

Inventory Eine Liste aller Geräte, die Ansible kennen soll. Hier stehen IP-Adressen, Zugangsdaten und gerätespezifische Variablen. Das Inventory ist der Ausgangspunkt jeder Ausführung.

Playbook Die eigentliche Automation. Ein Playbook ist eine YAML-Datei, die beschreibt, was auf welchen Geräten ausgeführt werden soll. YAML ist eine einfache, leicht lesbare Formatierungssprache — strukturiert durch Einrückungen, ähnlich wie eine geordnete Liste.

Task Eine einzelne Aufgabe innerhalb eines Playbooks. Zum Beispiel: "Setze den Hostnamen" oder "Erstelle VLAN 10".

Modul Die Bausteine, aus denen Tasks bestehen. Ansible bringt Hunderte vorgefertigte Module mit — für Netzwerke, Dateien, Pakete, Dienste und vieles mehr. Für Netzwerk-Switches gibt es spezialisierte Module, die direkt mit dem CLI der Geräte kommunizieren.

Schritt 1: Das Inventory aufbauen

Ein einfaches Inventory für drei Switches könnte so aussehen:

[switches]
switch-01 ansible_host=192.168.1.1
switch-02 ansible_host=192.168.1.2
switch-03 ansible_host=192.168.1.3

[switches:vars]
ansible_user=admin
ansible_password=geheim
ansible_network_os=ios
ansible_connection=network_cli
ansible_become=yes
ansible_become_method=enable

Was hier passiert:

• [switches] definiert eine Gruppe von Geräten
• Jede Zeile darunter ist ein Gerät mit einem Namen und seiner IP-Adresse
• [switches:vars] enthält Variablen, die für alle Geräte in der Gruppe gelten — Zugangsdaten, das Betriebssystem des Switches und die Verbindungsart

ansible_network_os teilt Ansible mit, welche Art von Switch es erwartet. Das ist wichtig, weil unterschiedliche Hersteller unterschiedliche CLI-Syntax haben. Für Cisco-IOS-Switches ist das ios, für andere Hersteller gibt es entsprechende Werte.

Schritt 2: Ein einfaches Playbook schreiben

Das folgende Playbook setzt auf allen Switches eine Basis-Konfiguration: Hostname, eine Management-VLAN-Beschreibung und ein einfaches Banner.

---
- name: Basis-Konfiguration auf allen Switches ausrollen
  hosts: switches
  gather_facts: false

  tasks:
    - name: Hostname setzen
      ansible.netcommon.cli_config:
        config: |
          hostname {{ inventory_hostname }}

    - name: VLAN 10 anlegen und benennen
      ansible.netcommon.cli_config:
        config: |
          vlan 10
           name SHOW

    - name: VLAN 20 anlegen und benennen
      ansible.netcommon.cli_config:
        config: |
          vlan 20
           name CREW

    - name: VLAN 30 anlegen und benennen
      ansible.netcommon.cli_config:
        config: |
          vlan 30
           name PRODUCTION

    - name: Login-Banner setzen
      ansible.netcommon.cli_config:
        config: |
          banner motd ^
          Managed by CX-Networks. Unauthorized access prohibited.
          ^

Ein paar Hinweise zum Verständnis:

• hosts: switches sagt Ansible, auf welcher Inventory-Gruppe das Playbook laufen soll
• gather_facts: false deaktiviert das automatische Einsammeln von Geräteinformationen beim Start — bei Netzwerk-Switches nicht benötigt und spart Zeit
• {{ inventory_hostname }} ist eine Variable, die Ansible automatisch aus dem Inventory befüllt — in diesem Fall der Name des jeweiligen Switches. Läuft das Playbook auf switch-01, wird der Hostname auf switch-01 gesetzt

Das Playbook läuft auf allen drei Switches nacheinander durch — identische Konfiguration, ohne manuelles Eingreifen.

Schritt 3: Konfiguration automatisch sichern

Konfigurationen deployen ist eine Seite. Die andere: sicherstellen, dass der aktuelle Zustand eines Switches jederzeit abrufbar ist.

Das folgende Playbook liest die laufende Konfiguration jedes Switches aus und speichert sie lokal als Datei:

---
- name: Konfigurationen aller Switches sichern
  hosts: switches
  gather_facts: false

  tasks:
    - name: Laufende Konfiguration auslesen
      ansible.netcommon.cli_command:
        command: show running-config
      register: config_output

    - name: Konfiguration als Datei speichern
      copy:
        content: "{{ config_output.stdout }}"
        dest: "./backups/{{ inventory_hostname }}_{{ ansible_date_time.date }}_config.txt"

Was hier wichtig ist:

• register: config_output speichert die Ausgabe des show running-config-Befehls in einer Variable
• copy schreibt den Inhalt dieser Variable in eine Datei — mit Gerätename und Datum im Dateinamen
• Nach einem Playbook-Durchlauf liegen alle Konfigurationen als strukturierte Textdateien im backups/-Ordner

Führt man dieses Playbook regelmäßig aus — zum Beispiel nach jedem Event oder nach jeder Konfigurationsänderung — entsteht automatisch eine vollständige Versionshistorie des Netzwerks.

Ansible in den Pre-Event-Workflow integrieren

Der größte Hebel entsteht nicht durch ein einzelnes Playbook, sondern durch die Integration in den Ablauf vor und nach einem Event.

Ein typischer Workflow könnte so aussehen:

1. Vor dem Aufbau: Baseline-Playbook ausführen — alle Switches starten mit einer sauberen, definierten Grundkonfiguration
2. Nach der Anpassung vor Ort: Backup-Playbook ausführen — der finale Zustand wird gesichert
3. Nach dem Abbau: Backup archivieren und für das nächste Event als Referenz nutzen

Was sich über Zeit aufbaut: ein Repository an Konfigurationen, das zeigt, wie unterschiedliche Event-Setups ausgesehen haben. Kein Wissen geht verloren, wenn eine Person das Unternehmen verlässt oder krank wird.

Wo Ansible seine Grenzen hat

Ansible wurde für stabile, homogene Umgebungen entwickelt — Server-Flotten, Cloud-Infrastrukturen, reproduzierbare Setups. In der Veranstaltungsbranche ist das selten die Realität.

Jeder Kunde hat ein anderes Netzwerk. Jedes Event bringt andere Hardware, andere Topologien, andere Anforderungen. Ansible setzt voraus, dass man weiß, was man vorfindet. Wenn das nicht der Fall ist, stößt man schnell an Grenzen.

Für den Einstieg und für wiederkehrende, strukturierte Setups ist Ansible ein ausgezeichnetes Werkzeug. Für dynamischere Umgebungen — wo das Setup erst vor Ort bekannt ist — braucht es flexiblere Ansätze. Aber das ist ein Thema für einen eigenen Artikel.

Fazit

Ansible ist kein Werkzeug, das IT-Experten vorbehalten ist. Wer YAML lesen und ein Terminal öffnen kann, kann ein funktionierendes Playbook für seine Switches aufsetzen.

Der erste Schritt ist ein Inventory und ein Playbook mit drei Tasks. Von dort aus wächst die Automation mit dem Bedarf — ein Task nach dem anderen.

Wer den nächsten Schritt gehen will: Im nächsten Artikel schauen wir uns an, wie man Playbooks für unterschiedliche Switch-Hersteller in einer einzigen Ausführung kombiniert.