Bei onway haben wir verstreute Scripts für NetBox, Observium und die Generierung von Netzwerkkonfigurationen in ontool zusammengeführt, einer gemeinsamen CLI für wiederkehrende Engineering-Aufgaben. Eine zentrale Konfiguration, ein einheitlicher Zugriff auf über 40 NetBox-Datentypen und eine klare Trennung von Bedienung und Fachlogik sorgen dafür, dass neue Funktionen ohne Umbau hinzukommen. ontool get commands zeigt jederzeit den aktuellen Befehlsumfang. Das Ergebnis sind weniger duplizierter Code, zentrale Wartung und ein einfacherer Einstieg für neue Teammitglieder.

Wie aus einzelnen Scripts eine strukturierte, erweiterbare Plattform wurde.

In einem Netzwerk- und Infrastrukturteam entstehen laufend kleine Scripts. Jemand braucht schnell eine Liste doppelter IP-Adressen aus dem IPAM. Jemand anderes will prüfen, ob die Interfaces einer VM in NetBox und im Monitoring übereinstimmen. Wieder jemand baut sich ein Script, das aus IPAM-Daten die Netzwerkkonfiguration für eine neue Kundenumgebung generiert. Jedes dieser Scripts ist nützlich und löst ein konkretes Problem der Person, die es geschrieben hat.

Mit der Zeit wird genau das zum eigentlichen Problem. Ein Script hilft nur, wenn man weiss, dass es existiert, wo es liegt, wie man es aufruft und ob es noch aktuell ist. Bei uns kam so eine ganze Reihe von Scripts zusammen: für den Umgang mit unserem IPAM (NetBox), für Abgleiche mit unserem Monitoring (Observium) und für die Generierung von Netzwerkkonfigurationen. Nicht alle im Team wussten, welche Scripts es überhaupt gab. Und Verbesserungen an einer Stelle – etwa an der Authentifizierung gegenüber NetBox – mussten im schlechtesten Fall in mehreren Scripts nachgezogen werden.

Daraus entstand ontool: eine CLI-Applikation, unter der wir diese wiederkehrenden Aufgaben bündeln.

ontool wird wie jedes andere Tool installiert und steht danach im Terminal als ein einziger Befehl zur Verfügung. Alle wiederkehrenden Aufgaben hängen unter diesem einen Einstiegspunkt.

Ruft man ontool ohne weitere Angaben auf, zeigt es eine Übersicht der Themenbereiche, die es aktuell abdeckt:

• get – Informationen über ontool selbst und die eigene Konfiguration

• check – Abweichungen zwischen Systemen aufspüren

• export – Daten aus dem IPAM exportieren

• ipam – Aufgaben rund um die Adressverwaltung

• network – Netzwerkkonfigurationen generieren

• oncloud – Helfer für unsere Cloud-Umgebungen

• sync – Daten zwischen Systemen abgleichen

• diagram – Netzwerkdiagramme erzeugen

Jeder dieser Bereiche bringt eigene Unterbefehle mit, zum Beispiel ontool check observium-to-netbox oder ontool ipam duplicate-ips. Entscheidend ist dabei nicht die Anzahl, sondern das Prinzip: Der Startpunkt der Applikation enthält keine Fachlogik, sondern verbindet nur die Themenbereiche zu einem Ganzen. Ein neuer Bereich lässt sich anhängen, ohne die bestehenden anzufassen.

Damit niemand mehr rätseln muss, was es alles gibt, zeigt ontool get commands die Struktur jederzeit an. Der Befehl liest sie direkt aus dem laufenden Programm aus und stellt sie als Baum im Terminal dar. Es gibt also keine separate Liste, die veralten könnte – die Übersicht entspricht immer exakt dem tatsächlichen Stand des Tools.

Eine Konfiguration für alle Befehle.
Fast jeder Befehl braucht früher oder später Zugriff auf NetBox oder Observium, also eine Adresse und ein Zugangs-Token oder Passwort. Statt das jedes Mal neu zu lösen, gibt es genau eine Stelle, die diese Angaben beim Start von ontool liest. Fehlt ein nötiger Wert, bricht ontool sofort mit einer verständlichen Meldung ab – etwa mit dem Hinweis, welche Zugangsvariable in der Konfiguration fehlt. So scheitert kein Befehl erst nach einigen Sekunden mit einer kryptischen Fehlermeldung eines Umsystems. Läuft die automatisierte Testsuite, greift ontool automatisch auf eine separate Testkonfiguration zurück; Tests können so nie versehentlich gegen Produktivsysteme laufen. Jeder neue Befehl nutzt automatisch dieselbe Konfiguration – niemand muss sich beim Entwickeln fragen, woher die Zugangsdaten kommen.

Ein einheitlicher Zugriff auf NetBox.
NetBox verwaltet für uns unter anderem VLANs, IP-Adressen, Netzbereiche, Kunden und Geräte – insgesamt über 40 Datentypen. Ohne gemeinsame Struktur müsste jedes Script selbst wissen, wie man mit der NetBox-Schnittstelle spricht, und die Antworten selbst aufbereiten. In ontool ist das an einer einzigen Stelle gelöst. Für jeden Datentyp gibt es dieselben vier Abfragen: einen Eintrag über seine ID, einen Eintrag über seinen Namen, alle Einträge oder alle Einträge, die zu einem Filter passen. Diese vier Abfragen sind einmal definiert und werden von allen Datentypen wiederverwendet. Fragt man etwa nach einem VLAN, werden der zugehörige Standort oder Kunde gleich mitgeliefert. Für Observium gilt dasselbe Prinzip, technisch leicht anders umgesetzt, weil dieses System alle Werte als reinen Text statt als Zahl oder Datum liefert.

Klare Trennung von Bedienung, Fachlogik und Systemzugriff.
Jeder Befehl ist bewusst schlank: Er nimmt die Eingabe entgegen und übergibt sie an eine andere Stelle im Programm, die die eigentliche Aufgabe erledigt – zum Beispiel «vergleiche eine virtuelle Maschine zwischen NetBox und Observium». Diese Fachlogik ist unabhängig von der Kommandozeile geschrieben. Dadurch lässt sie sich separat testen und in mehreren Befehlen wiederverwenden, und jeder Befehl bleibt so einfach, dass man seine Wirkung auf einen Blick versteht. Im Änderungsprotokoll von ontool ist diese Trennung als bewusste Aufräumaktion festgehalten.

Am deutlichsten zeigt sich der Nutzen dieser Architektur beim Befehl, der aus IPAM-Daten die Netzwerkkonfiguration für einen Kunden generiert. Dahinter steckt ein mehrstufiger Ablauf:

1. ontool sucht den angegebenen Kunden in NetBox.
2. Es lädt alle zugehörigen VLANs, Netzbereiche, IP-Adressen und weiteren Netzwerkdaten – über dieselben Bausteine, die auch andere Befehle nutzen.
3. Aus diesen Daten entstehen pro Standort und Gerät (Router, Switch, Firewall) fertige Konfigurationsdateien. Grundlage sind Vorlagen, die festlegen, wie eine Konfiguration aufgebaut ist.
4. Die Konfigurationsdateien werden zusammen mit einer Kopie der Rohdaten abgelegt. So bleibt nachvollziehbar, mit welchem Datenstand eine Konfiguration entstanden ist.
5. Anschliessend checkt ontool die Dateien selbst in die Versionsverwaltung ein und lädt sie hoch.

Die generierten Konfigurationen liegen bewusst getrennt vom Programmcode von ontool, in einer eigenen, ebenfalls versionierten Ablage. Wer die Historie der Kundenkonfigurationen ansehen will, muss sich so nicht durch die Entwicklungsgeschichte von ontool arbeiten – und umgekehrt bleibt die Entwicklung von ontool frei von Kundendaten.

Für ein einzelnes Script wäre das ein beträchtlicher Aufwand: eigene Anbindung an NetBox, eigene Datenaufbereitung, eigene Anbindung an die Versionsverwaltung. In ontool ist all das bereits vorhanden. Der Befehl selbst besteht im Kern nur noch aus «Daten holen», «Vorlage befüllen» und «vorhandene Bausteine für den Rest aufrufen».

Dass es sich um eine wiederverwendbare Architektur handelt und nicht um eine Speziallösung, zeigt der Befehl ontool diagram create. Er folgt demselben Prinzip wie die Konfigurationsgenerierung – Daten aus NetBox laden, in eine Vorlage einsetzen, Ergebnis speichern. Statt einer Gerätekonfiguration entsteht dabei aber eine Diagrammdatei, die sich direkt in einem Diagramm-Programm öffnen lässt. Fehlen beim Aufruf Angaben, fragt ontool sie in einem kurzen Dialog im Terminal nach.

Damit eine spätere Änderung an anderer Stelle dieses Verhalten nicht unbemerkt bricht, gibt es dafür einen automatisierten Test. Er lässt ontool ein Diagramm erzeugen und vergleicht es mit einer hinterlegten, als korrekt bekannten Version. Weicht das Ergebnis ab, schlägt der Test fehl – bevor eine fehlerhafte Änderung zum Einsatz kommt.

Ein neues Feature hinzuzufügen bedeutet im Kern drei Schritte: einen Ort für die Fachlogik anlegen, dafür einen neuen Zweig im Befehlsbaum registrieren und diesen Zweig an einer einzigen Stelle im Hauptprogramm bekannt machen. Alles andere kommt automatisch mit – die Konfiguration, die Selbstauskunft über ontool get commands und bei Bedarf der Zugriff auf NetBox oder Observium.

Dass die Struktur tatsächlich so genutzt wird, zeigt das Änderungsprotokoll: Der Grundstock an Befehlen war früh vorhanden, die Bereiche «check» und «diagram» kamen erst in späteren Versionen dazu. Der Befehlsumfang ist über mehrere Versionen gewachsen, ohne dass die Grundstruktur angepasst werden musste.

• Auffindbarkeit: Der vollständige, aktuelle Befehlsbaum ist jederzeit abrufbar – direkt aus dem Programm erzeugt.
• Einheitliche Bedienung: Alle Befehle folgen denselben Regeln bei Aufruf, Hilfetext und Ausgabe.
• Zentrale Wartung: Die Anbindung an NetBox und Observium existiert genau einmal. Eine Änderung dort wirkt sich auf alle Befehle aus.
• Reproduzierbare Abläufe: ontool wird als versioniertes Paket gebaut und automatisiert getestet, statt als loses Script auf irgendeinem Rechner zu laufen. Generierte Konfigurationen landen versioniert in einer eigenen Ablage statt lokal auf einem Laptop.
• Einfacheres Onboarding: Neue Teammitglieder lernen eine Kommandozeile mit einer Konvention, statt sich durch mehrere unabhängige Scripts zu arbeiten.

Kleine Scripts sind ein guter, oft der beste Einstieg in die Automatisierung: Schnell geschrieben, schnell einsatzbereit, genau auf ein Problem zugeschnitten. Schwierig wird es erst, wenn viele davon nebeneinander existieren und ein ganzes Team sie nutzen soll. Dann zählt nicht mehr nur, ob ein Script funktioniert, sondern ob man es findet, versteht und ihm vertrauen kann.

ontool ist unser Weg, aus einzelnen Automatisierungen ein gemeinsames Tool zu machen: Eine Kommandozeile, eine Konfiguration, ein wiederverwendbarer Zugriff auf NetBox und Observium – und eine Struktur, in die neue Aufgaben eingehängt werden, statt daneben zu entstehen. Fertig ist das Tool damit nie. Es wächst mit jeder wiederkehrenden Aufgabe, die wir künftig dort lösen statt in einem neuen Script.