Die meisten Automatisierungsprojekte scheitern an einer banalen Sache: niemand weiß genau, was im Netz und Serverraum wirklich läuft. IP-Adressen in Excel, Verkabelung im Kopf eines Admins, zwei Jahre alte Doku. Ohne Source of Truth ist Automatisierung auf Sand gebaut. NetBox ändert das.
Was NetBox ist
NetBox ist ein Open-Source-Tool für IPAM (IP-Adressverwaltung) und DCIM (Data Center Infrastructure Management). Ein einziger Ort, der festhält, was Sie haben, wo es ist, wie es verkabelt ist und welche Adressen es nutzt.
Automatisierung ist nur so gut wie die Daten, auf denen sie läuft. NetBox ist diese Datenquelle.
Warum es die Basis der Automatisierung ist
Wenn Ansible oder Terraform eine Änderung ausrollen, müssen sie wissen: welcher Server, welches VLAN, welche IP. NetBox als Single Source of Truth löst das — Playbooks lesen die Wahrheit aus einer API.
- Network-as-Code — Netzkonfiguration wird aus NetBox generiert.
- Provisioning — ein neuer Server erhält IP und VLAN automatisch.
- Audit und Compliance — Sie wissen jederzeit, was Sie haben. Entscheidend für NIS2.
Reality Check
- NetBox ist nur so gut, wie Sie ihn pflegen. Die Erstbefüllung ist Arbeit — aber einmalig und essenziell.
- Es ist kein Monitoring. Was wirklich läuft, überwacht Zabbix oder Logmanager.
- Integration zahlt sich aus. Die wahre Stärke liegt in der Anbindung an Ansible, Terraform und CMDB.
Wie wir es einführen
Wir starten mit Discovery — Scan des realen Zustands und Import in NetBox. Dann verbinden wir die Automation-Pipeline (Red Hat Ansible Automation Platform).
# NetBox als Source of Truth — Config wird aus Daten generiert, nicht von Hand
- name: Switch-Configs direkt aus NetBox generieren
hosts: localhost
connection: local
tasks:
- name: Aktive Core-Switches aus NetBox laden
ansible.builtin.set_fact:
netbox_devices: "{{ query('netbox.netbox.nb_lookup', 'devices',
api_endpoint='https://netbox.internal',
api_filter='status=active role=core-switch') }}"
- name: Config aus Template + Daten rendern
ansible.builtin.template:
src: switch.cfg.j2 # ein Template, Daten aus NetBox
dest: "configs/{{ item.value.name }}.cfg"
loop: "{{ netbox_devices }}"
- name: Sicherstellen, dass jedes Gerät eine IP hat
ansible.builtin.assert:
that: item.value.primary_ip4 is not none # fehlende IP = Inventar-Fehler, kein Produktions-Fehler
loop: "{{ netbox_devices }}"Wichtiger Punkt: NetBox ist Quelle und Ziel — die Automatisierung liest daraus und schreibt den realen Zustand zurück. Kein Excel. Lookup-Plugin: NetBox Docs.
Das Provisioning eines neuen Racks (40 Geräte) dauerte 3 Tage manuelles Suchen von IPs und VLANs in Tabellen. Mit NetBox als Source of Truth: 4 Stunden, null IP-Konflikte. Illustrative Werte — vor Veröffentlichung verifizieren.
Häufige Fragen
Wie bekommen wir den realen Zustand in NetBox, wenn unser Excel ein Chaos ist?
Discovery. Wir scannen das reale Netz und die Server, importieren das Ergebnis in NetBox und vergleichen mit Excel — die Unterschiede sind meist überraschend. Ab dann ist NetBox die Source of Truth und Excel geht ins Archiv.
Was, wenn NetBox und Realität auseinanderdriften?
Deshalb nutzen wir NetBox als Quelle und Ziel — die Automatisierung verifiziert regelmäßig, dass die Realität NetBox entspricht, und meldet Drift. Ein Gerät, das nicht in NetBox ist, ist entweder ein Fehler oder eine unautorisierte Änderung.
Funktioniert es für virtuelle und Cloud-Infrastruktur?
Ja. NetBox modelliert physische und virtuelle Geräte, IP-Raum, VLANs und Verbindungen über on-prem und Cloud. Es ist vendor-neutral und bindet Sie nicht an einen Hersteller.
Wie passt NetBox zum Rest der Automatisierung?
Es ist die Basis. F5-Config, Zabbix-Monitoring und Server-Provisioning lesen ihren Zielzustand aus NetBox. Eine Quelle, viele Konsumenten.
Liegt Ihr Netz-Zustand in Excel?
Buchen Sie einen 20-Minuten-Call — wir zeigen, wie aus dem Chaos eine Source of Truth wird und was das für Ihre Automatisierung bedeutet. Kein Sales-Pitch.
20-Min-Call buchen →