Netzwerkautomatisierung mit NetBox: vom Datenmodell zur Pipeline
NetBox ist die Network Source of Truth, aus der deine Automatisierung ihre Daten bezieht: Ansible zieht sich das Inventory, Templates rendern die Konfiguration, Event Rules stoßen Workflows an. Hier siehst du, wie aus einem gepflegten Datenmodell eine belastbare Pipeline wird, Schritt für Schritt und ohne Blindflug.
- REST- & GraphQL-API
- 100+ Ansible-Module
- Event Rules seit NetBox 3.7
- NetBox Labs DACH-Partner
Diagramm seitlich wischen, um alles zu sehen.
Netzwerkautomatisierung scheitert selten am Tooling. Sie scheitert an den Daten.
Bevor die erste Pipeline läuft, räumen die meisten Teams mit denselben vier Altlasten auf. Kommt dir eine davon bekannt vor?
Excel-Configs als Inventar
Hostlisten in Excel, IP-Bereiche in drei Tabs, Portbelegung im Kopf eines Kollegen. Jede Pipeline, die auf solchen Listen aufsetzt, automatisiert Fehler nur schneller.
Config-Drift zwischen Soll und Ist
Niemand weiß, welcher Stand gilt: das Template, das Gerät oder die Doku. Ohne definierten Soll-Zustand gibt es nichts, wogegen du validieren könntest.
Manuelle Changes ohne Audit-Trail
Der Hotfix um 23 Uhr landet direkt auf der CLI und nie in der Doku. Beim nächsten Rollout überschreibt die Pipeline den Fix, und die Fehlersuche beginnt von vorn.
Wissensinseln einzelner Admins
Das VLAN-Konzept existiert nur im Kopf einer Person. Fällt sie aus, steht jede Änderung still. Ein zentrales Datenmodell macht dieses Wissen fürs ganze Team nutzbar.
Network Source of Truth: das Fundament jeder Pipeline.
Eine Network Source of Truth ist ein zentrales Verzeichnis mit verlässlichen, aktuellen Informationen über alle Geräte, Verbindungen und Dienste eines Netzwerks. NetBox bildet darin bewusst den Soll-Zustand deines Netzes ab, nicht den Ist-Zustand. Genau das macht Automatisierung erst möglich: Die Pipeline rendert Konfigurationen aus dem Soll, rollt sie aus und prüft anschließend, ob die Realität dem Plan entspricht.
Soll statt Ist
NetBox beschreibt, wie dein Netz aussehen soll. Monitoring und Discovery liefern das Ist. Die Differenz ist dein Arbeitsvorrat, kein Ratespiel.
Eine API statt drei Listen
REST und GraphQL machen jedes Objekt maschinenlesbar. Skripte, Playbooks und Portale greifen alle auf dieselbe Datenbasis zu, ohne Kopien und ohne Widersprüche.
Offen und erweiterbar
NetBox ist Open Source unter Apache-2-Lizenz und positioniert sich als Source of Truth für Netzwerkautomatisierung. Deine wichtigsten Daten bleiben ohne Vendor-Lock-in.
Vom Datenmodell zur Pipeline: vier Schritte.
So sieht der Kreislauf aus, den wir in Automatisierungsprojekten aufbauen. Er beginnt und endet im Datenmodell.
Soll-Datenmodell pflegen
Sites, Geräte, Interfaces, VLANs, IP-Adressen: Alles, was deine Pipeline braucht, lebt in NetBox. Änderungen passieren zuerst im Modell, nie am Gerät.
- Namenskonventionen & Rollen
- Custom Fields für Automations-Flags
- RBAC für Schreibrechte
Intended Config erzeugen
Jinja2-Templates verwandeln das Datenmodell in fertige Gerätekonfigurationen. Gleiche Daten, gleiche Templates, reproduzierbares Ergebnis.
- Templates je Plattform
- Review im Git-Workflow
- Konfiguration als Artefakt
Deployment via Ansible & API
Ansible bezieht sein Inventory direkt aus NetBox und spielt die gerenderte Konfiguration aus. Alternativ Terraform oder eigene Skripte gegen die REST-API.
- Dynamic Inventory nb_inventory
- Rollout in Wellen
- Anbindung an CI/CD
Validieren & Drift erkennen
Nach dem Rollout vergleichst du Ist gegen Soll. Abweichungen fließen zurück ins Datenmodell oder werden als Drift gemeldet, bevor ein Audit sie findet.
- Soll-Ist-Vergleich je Change
- Alarm bei Drift
- Erkenntnisse zurück ins Modell
Schritt 4 führt zurück zu Schritt 1: der Kreislauf hält dein Modell und dein Netz synchron.
NetBox + Ansible in der Praxis.
Die Community-Collection netbox.netbox (aktuell v3.23.0, benötigt ansible-core 2.15 oder neuer) bringt rund 100 Module, das Inventory-Plugin nb_inventory und das Lookup-Plugin nb_lookup mit.
NetBox als Dynamic Inventory
Eine YAML-Datei genügt, und Ansible zieht Hosts, Gruppen und Variablen direkt aus NetBox. Über group_by gruppierst du nach Site, Rolle, Plattform oder Tag, über query_filters schränkst du die Auswahl ein. Der Platform-Slug wird per compose auf ansible_network_os gemappt.
Playbooks gegen den Soll-Zustand
Mit nb_lookup holst du einzelne Objekte wie VLANs oder Prefixe zur Laufzeit ins Playbook. Die Module der Collection schreiben auch zurück: Ein Playbook kann Geräte, Interfaces und IPs in NetBox anlegen und danach direkt konfigurieren.
Integrationen im Überblick.
Sechs Wege, über die deine Werkzeuge mit dem NetBox-Datenmodell sprechen.
REST-API & pynetbox
Die REST-API basiert auf dem Django REST Framework: Objekte anlegen, ändern und löschen per HTTP und JSON, abgesichert über Tokens, dokumentiert per OpenAPI. pynetbox ist der offizielle Python-Client dazu.
GraphQL-API
Seit NetBox 3.0 an Bord: eine read-only API, die in einer Abfrage genau die Felder liefert, die dein Client anfordert. Ideal für Reports und Dashboards ohne zehn REST-Roundtrips.
Webhooks & Event Rules
NetBox meldet Objektänderungen aktiv an externe Systeme, Webhooks gibt es seit Version 2.4. Event Rules steuern seit 3.7 fein, welches Ereignis welche Aktion auslöst.
Custom Scripts
Python-Code direkt in NetBox, ausgeführt aus der UI, per REST-API, per CLI oder zeitgesteuert. Typische Fälle: eine neue Site samt Geräten anlegen oder externe Daten importieren.
Terraform-Provider
Der Community-Provider e-breuninger/netbox verwaltet NetBox-Objekte deklarativ als Infrastructure as Code. Version 5.6.1 und neuer ist gegen NetBox 4.3.0 bis 4.6.3 getestet.
go-netbox
Der offizielle Go-Client von NetBox Labs für die REST-API. Die Basis, wenn du eigene Tools, Controller oder Operatoren im Go-Ökosystem baust.
Viele Erweiterungen laufen als Plugin direkt in der NetBox-Oberfläche, einen Überblick gibt dir unsere Seite NetBox Plugins. Wie du dein Monitoring an das Datenmodell koppelst, zeigen wir unter NetBox + Checkmk.
Event Rules: dein Datenmodell stößt die Pipeline an.
Seit NetBox 3.7 (Release Dezember 2023) reagiert NetBox automatisch auf Create-, Update- und Delete-Ereignisse. Bestehende Webhooks wurden beim Upgrade automatisch migriert. Über JSON-Conditions legst du fein fest, welche Objekte und Attribute eine Regel auslösen. Drei Aktionstypen stehen bereit:
Externe Systeme benachrichtigen
NetBox schickt eine Repräsentation des geänderten Objekts an dein CI/CD-System, deine Automation-Plattform oder einen Message-Broker. Der klassische Auslöser für Konfigurations-Pipelines: Interface geändert, Playbook läuft.
Logik direkt in NetBox
Ein Python-Script startet unmittelbar in NetBox, etwa um abhängige Objekte anzulegen, Konsistenzregeln durchzusetzen oder Daten in Drittsysteme zu synchronisieren.
Menschen im Loop halten
Nutzer werden in NetBox über relevante Änderungen informiert. Praktisch für Review- und Freigabeprozesse, bei denen nicht jede Änderung sofort automatisiert ausrollen soll.
Automatisierung beginnt mit Datenqualität.
Die 28-Punkte-Checkliste für dein Soll-Datenmodell
Jede Pipeline ist nur so gut wie das Datenmodell darunter. Wenn Hostnamen dreifach existieren, IP-Bereiche kollidieren oder die Hälfte der Interfaces fehlt, automatisierst du dein Chaos nur schneller.
Der ehrliche erste Schritt ist deshalb selten ein Playbook, sondern ein sauberes Soll-Modell: konsolidieren, bereinigen, Konventionen festlegen, strukturiert importieren. Unsere Checkliste führt dich durch genau diese Vorarbeit. Und wenn deine Daten noch in Excel oder RackTables liegen, begleitet dich die Migrationsberatung von der Bestandsaufnahme bis zum Cutover.
Vom ersten Modell bis zur laufenden Pipeline.
Als NetBox Labs Partner für die DACH-Region begleiten wir Netzwerk- und IT-Teams von ISPs über Rechenzentren bis Enterprise. Mehr zur Partnerschaft liest du unter NetBox Partner DACH.
Datenmodell-Design
Sites, Tenants, Custom Fields, RBAC: Wir modellieren dein Netz so, dass Automatisierung darauf aufsetzen kann.
Pipeline-Aufbau
Ansible Dynamic Inventory, Terraform, CI/CD-Anbindung: der Weg vom Modell zur Gerätekonfiguration.
Custom Scripts & Integrationen
Eigenentwicklungen in Python, Webhook-Empfänger, Kopplung an ITSM und Monitoring.
Team-Enablement
Workshops und gemeinsames Bauen, bis dein Team Datenmodell und Pipeline selbst sicher betreibt.
Mehr Tiefe? Schau vorbei.
Auf unserem YouTube-Kanal nscon - Sicher vernetzt findest du Deep-Dives, How-Tos und Best Practices.
Häufige Fragen, ehrliche Antworten.
Bereit für die Pipeline? Lass uns über dein Datenmodell reden.
Im kostenfreien Erstgespräch schauen wir auf deinen Stack, deine Datenlage und den kürzesten Weg zur ersten automatisierten Änderung.