Immer wieder Mal lasse ich hier ein paar Worte zum Thema PowerShell und Icinga for Windows fallen und so ist es auch dieses Mal wieder. In meinem letzten Blogpost Plugins, Provider, PowerShell habe ich schon ein bisschen ein Blick in die einzelnen Repositories im Zusammenhang mit Icinga for Windows gegeben.
Dieses Mal betrachten wir das Framework, beziehungsweise dessen Komponenten und Tools, welche wichtig oder praktisch für Plugin-Entwicklung und Troubleshooting sind.
Tools
Mit den Tools des Frameworks lässt sich einiges an Arbeit sparen, diese befinden sich im icinga-powershell-framework repository unter /lib/core/tools. Natürlich können diese Tools auch außerhalb des Icinga-Kosmoses Anwendung finden.
Unter den Tools finden sich die verschiedenste Module, wie zum Beispiel Convert-Bytes, dessen Aufgabe es ist die Einheit entsprechender Byte Werte umzurechnen. Während der Anwendungsfall von Convert-Bytes sehr offensichtlich ist, gibt es ebenso Tools, welche Nischen bedienen, wie zum Beispiel ConvertTo-IcingaIPBinaryString, welches in der Bestimmung des Network-Interfaces mittels Get-IcingaNetworkInterface eine Rolle spielt.
Genauso wie im Developer-Guide beschrieben, sollten Custom-Plugins, sowie Tools, die von euch selbst geschrieben werden in ein separates Modul gespeichert werden. Falls der bisherige Funktionsumfang eines Tools nicht ausreichend ist für ein Custom Plugin oder Provider, dann sollte wenn möglich auf der Basis des Tools weiterentwickelt werden, wenn das möglich ist – aber natürlich innerhalb eines separaten Moduls.
Wie immer sind Pull-Request und Feature-Anfragen auch für Tools des Frameworks mehr als willkommen.
Wrapper
Um nicht willkürlich unterschiedliche Funktionen zu nutzen und eine grundsätzliche Einheitlichkeit in der Entwicklung von Plugins und Modulen im Framework zu habe werden Wrapper genutzt. Es ist also zielführender, wenn man sich im Voraus erkundigt, ob bestehende PowerShell-Kommandos in einem Wrapper mit gegebenenfalls erweiterter Logik bereits genutzt werden. Um ein paar Beispiele hierfür zu nennen, Restart-IcingaService ist im eigentlichen ein Wrapper für das PowerShell-Kommando Restart-Service. Dabei nutzt Restart-IcingaService aber Module, wie zum Beispiel Write-IcingaConsoleNotice oder Write-IcingaConsoleWarning, die dann entsprechend dafür sorgen, dass via Write-IcingaConsoleOutput entsprechende Informationen in einheitlicher Formatierung ausgegeben werden.
Ein ähnliches Szenario liegt auch vor für Start-IcingaService, Stop-IcingaService für Start-Service und Stop-Service. Im Falle dieser drei Wrapper wurde das Error-Handling im Icinga-Kontext verbessert im Vergleich zu den einzelnen zugrunde liegenden Kommandos.
Prominentestes Beispiel für die Plugin-Entwicklung jedoch ist wahrscheinlich Get-IcingaWindowsInformation, mehr oder weniger ein Wrapper für Get-WmiObject und Get-CimInstance. Get-IcingaWindowsinformation hilft hierbei nur WmiObjects aufzurufen, welche vom Framework unterstützt werden, beziehungsweise weißt es auf fehlende Berechtigungen hin und beschreibt eventuelle Fehler genauer bei der Plugin-Entwicklung. Sollten also in einem Provider CimObjects oder WimObjects benötigt werden, dann sollten diese mittels Get-IcingaWindowsInformation aufgerufen werden.
Selbiges wie bei den Tools gilt natürlich auch hier. Wenn Kommandos mit logischen Strukturen für das icinga-powershell-framework verbessert werden können, zum Beispiel in Form eines Wrappers, dann sind Vorschläge stets erwünscht.
Management
Hier ein kleiner Einblick in ein bisher noch experimentelles Feature und zwar die Management-Konsole. Die Funktion Invoke-IcingaCommand oder gemeinhin eher icinga, sollte bekannt sein, aber nichts desto trotz hier noch einmal. Der icinga Befehl ist grundsätzlich dafür da um Framework-Befehle in einer neuen PowerShell-Instanz auszuführen, was das Testen von neuen Plugins schnell und angenehm gestaltet.
Als Beispiel kann somit direkt durch geschweifte Klammern ein Skriptblock übergeben werden:
PS> icinga { Get-IcingaCPUs }
Name Value
---- -----
0 {specs, errors, metadata}
Alternativ kann ohne Parameter, beziehungsweise Klammern, eine Icinga-Konsole aufgerufen werden, die wie beim gebrauch von Use-Icinga die Framework-Funktionalitäten lädt:
PS> icinga
********************************************
** Icinga for Windows v1.5.0 **
** Copyright (c) 2021 Icinga GmbH | MIT **
** User environment Test\Test **
********************************************
icinga> Get-IcingaCPUs
Name Value
---- -----
0 {specs, errors, metadata}
Jetzt aber zur Management-Konsole, die wird aufgerufen durch das Benutzen von icinga -Manage. Es ist notwendig den Befehl auf einer Administrator-Shell auszuführen, ansonsten stehen nicht alle Funktionalitäten zur Verfügung. Durch das Ausführen des Befehls landet man in einem Interaktiven Menü, mit den folgenden Punkten und Aktionsmöglichkeiten:
[0] Installation
[1] Update environment
[2] Manage environment
[3] Remove components
[x] Exit [c] Continue [h] Help [m] Main
Input (Default 0 and c):
Abhängig von der Installation der Umgebung sind Punkte abgeschaltet und aus gegraut. Die Hilfe gibt zu jeden einzelnen Punkt und Schritt in den jeweiligen Untermenüs Informationen. Dadurch dass die vielen Untermenüs und Schritte zahlreich sind, sollte sich das jeder selbst genauer anschauen, beispielsweise ähnelt der erste Punkt, der der Installation sehr dem Interaktiven-Menü des Kickstarts-Skripts. Während die anderen Punkte, wie Update, und Manage environment es einen Nutzer erlauben auch mit geringen Kenntnisstand über Framework-Funktionen, die Funktionalitäten auszukosten. Wer also kein Freund von Befehlen wie Invoke-IcingaFrameworkUpdate oder Install-IcingaFrameworkComponent ist, kann die Sache hiermit unter einem Hut einfach zusammenfassen. Genau das Gleiche gilt auch für Befehle wie Uninstall-IcingaFrameworkComponent mit Punkt 3.
Wir würden uns wirklich sehr darüber freuen, wenn ihr das experimentelle Feature ausprobieren könntet und uns dazu Feedback zu kommen lassen würdet.
0 Kommentare