FastNetMon Configs mit CUE verwalten

Es war einmal in einem Rechenzentrum in Deutschland vor nicht all zu langer Zeit, da begab es sich, dass ein Admin FastNetsMon einrichten wollte. Doch diese Aufgabe stellte sich als mühsam heraus, da die Konfiguration nicht in einer Config-Datei gespeichert wurde, sondern nur via CLI möglich war. „Schade“, dachte sich der Admin und konfigurierte die Instanz manuell nach der Vorgabe, die ihm gegeben wurde.

Einige Jahre später wurden neue Server angeschafft, um die vorherigen auszumustern und die Zeit war gekommen die Installation zu wiederholen. Dieses mal war es jedoch anders als noch vor ein paar Jahren! Es musste nicht nur eine Instanz konfiguriert werden, sondern zwei Instanzen. Dieser Umstand führte direkt zu Fehlern, da die alte Version andere Parameter hatte als die neue. Ebenfalls wurde von IPFIX/sFlow auf einen Port-Mirror umgestellt, weshalb dort weitere Einstellungen angepasst und geprüft werden mussten.

Der Admin, der dieses mal zuständig war das System einzurichten, wollte jedoch nicht alle Einstellungen manuell vornehmen, da er dort ein hohes Fehlerpotential für sich und auch zukünftige Admins sah. „Hmm“, dachte sich also der Admin und forschte nach Möglichkeiten. In der Dokumentation wurde er schließlich fündig und erstellte mit dem Befehl „export_configuration“ einen Tarball, welcher die aktuelle Konfiguration beinhaltete. Wie aus der Pistole geschossen tipperte der Admin tar xf in sein Terminal und prüfte welche Dateien in dem Backup zu finden sind. Dort fand er eine Datei „main.json“ und einen Ordner mit mehreren Dateien „0.json“, „1.json“, welcher er sich daraufhin auf seinem Computer anschaute.

Und so begab es sich, dass der Admin die Dateien nahm, mit der Doku verglich und feststellte, dass diese identisch waren. Er wartete daher nicht und schritt direkt zur Tat, um ein CUE-Schema für die Konfiguration zu erstellen.

CUE ist eine Konfigurationssprache. Wir nutzen CUE um Configs in YAML, JSON oder anderen Formaten gegen ein Schema zu validieren und bei z.B. unserer Kubernetes-Infrastruktur auch die gesammte Config zu generieren. In CUE ist der Scope der Werte entweder die Datei oder das Package, falls gesetzt. Dieses Verhalten ist essentiell für CUE, da sich hiermit Schemas definieren lassen und man nur valide States exportieren kann.

// Dies evaluiert zu false, falls es nicht explizit anders gesetzt wird.
// Ebenfalls wird der Typ zu boolean festgelegt.
enabled: bool | *false
// { "enabled": false }



// Wir könnten nun mit folgendem den Wert zu true ändern,
// da die beiden Einträge zusammengeführt werden.
enabled: true
// { "enabled": true }

// Falls wir jedoch nun zusätzlich noch den Wert zu false ändern,
// bekommen wir einen Fehler.
enabled: false
// enabled: 1 errors in empty disjunction:
// enabled: conflicting values false and true:

Ebenfalls ist es möglich Werte, welche bereits durch einen default definiert wurden oder doppelt gesetzt sind, automatisiert mit cue trim entfernen zu lassen und die Konfiguration damit zu vereinfachen.

// Definiere ein struct welches einen Wert mit Default besitzt
#Config: {
	enabled: bool | *false
}

// "out" soll als Type das "#Config"-Struct haben
out: #Config

// Setze enabled auf false, was bereits dem default entspricht.
out: enabled: false

Wenn man nun cue trim auf die Datei ausführt sieht man folgendes verhalten:

#Config: {
	enabled: bool | *false
}
out: #Config
out: {}

Das ausführen von cue trim hat den Wert, welcher bereits über einen Default definiert war entfernt und so Einstellungen, welche bereits dem Standard entsprechen entfernt.

CUE ist Toll
Ein Admin bei Babiel

Mit diesen Grundprinzipien im lässt sich nun relativ einfach ein Schema aus der FastNetMon-Doku erstellen.

Die von FastNetMon bereitgestellten Tabelle erweiste sich als äußert nützlich, da sich diese durch ein paar Search&Replace Operationen zu einer CUE Datei inkl. Kommentaren und Default Werten konvertieren ließ. Die Tarballs um die generierte Konfiguration zu importieren, werden ebenfalls direkt mit CUE generiert.

Das Prinzip von cue trim wurde genutzt um die bereits existierenden Konfigurationsdateien einzufügen und alle Einstellungen, welche dem Standard gleichen, zu entfernen. Nach ein paar Stolpersteinen durch Bugs in FastNetMon, welche direkt gemeldet wurden, war es vollbracht und eine einfache Lösung für die zentrale und versionierte FastNetMon-Konfiguration ward geboren.

Dieser Eintrag basiert auf einer wahren Geschichte und falls du dir das CUE-Schema und damit die Lösung für zentrale FastNetMon Konfigurationen ansehen möchtest, findest du dies auf unserer Github Organisation.

Falls du auch Interesse hast solche Lösungen zu finden und an diesen zu arbeiten, bewirb dich doch bei uns.