Auf Twitter hat Jan Schaumann vor Kurzem begonnen eine Liste aufzustellen mit Dingen, die jeder Sysadmin in seinem Leben schon mindestens ein mal getan hat. Darunter zählen Sachen wie einen Parser für den ifconfig Befehl zu schreiben oder unvollständige Regexes für IP Adressen zu basteln. Beim Durchgehen dieser Liste habe ich mich immer wieder selbst ertappt. Es ist erschreckend, wie viele von diesen Dingen auf einen selbst zutreffen. Dennoch ist es sehr amüsant zu lesen.
Bei Netways arbeiten wir sehr viel im Bereich Monitoring. So ist es kein Wunder, das ich bei den Dingen die jeder Sysadmin schon mal getan hat, sofort auch an dieses Thema denken musste. Lange muss man da auch nicht überlegen: Jeder Sysadmin hat mindestens schon ein mal in seiner Karriere ein monitoring Plugin geschrieben. Das gehört einfach dazu und selbst DevOps wird uns vermutlich nicht davor bewahren.
Das Schreiben von monitoring Plugins ist auf den ersten Blick ein ziemlich einfaches Thema. So ein Plugin muss einen Rückgabewert von 0, 1 oder 2 liefert und im besten Fall einen Text ausgeben, der den Zustand beschreibt. Damit wären schon mal alle Grundvoraussetzungen gegeben. Weil es eben so einfach ist, gibt es auch so viele von diesen Plugins. Sie werden in nahezu jeder Programmiersprache geschrieben. Manche Plugins sind umfangreich mit vielen Optionen und noch mehr Performance Daten in der Ausgabe. Andere wiederum bestehen nur aus wenigen Zeilen und erfüllen einen einzigen speziellen oder simplen Zweck.
Was mich bei monitoring Plugins schon immer gestört hat, ist das Deployment von jenen. Je nachdem in welcher Sprache das Plugin entwickelt ist, müssen mit cpan, gem, pip, npm, pear, composer oder andern Package Managern Abhängigkeiten nachinstalliert werden. So richtig lästig wird das bei ein paar Hundert Plugins für ein paar Tausend Server mit unterschiedlichen Distributionen. Sind Windows Systeme dabei, … ach davon fang ich garnicht erst an.
Welche Lösung gibt es also dafür? Noch keine fertige, zumindest meiner Meinung nach. Selbst Configuration Management löst das Problem nicht ganz. Um das vernünftig zu machen, müsste man ja seine 3-Zeiler Plugins packetieren und vernünftige Module oder Cookbooks schreiben, die das dann auf die Systeme ausrollen. Bestenfalls natürlich auf jedes System nur die Plugins die dort auch wirklich hin gehören. Seitdem ich mich bezüglich eines Projekts aber mit der Programmiersprache Go auseinander setze, beschäftigt mich ein anderer Ansatz um das Problem zu lösen: was wäre, wenn so ein Plugin gar keine Abhängigkeiten hat?
Go ist eine Programmiersprache, deren Wurzeln bei C liegen. Sie ist dementsprechend auch keine Scriptsprache wie Ruby oder Python, fühlt sich manchmal aber trotzdem so an. Das führt dazu das Leute wie ich, die aus der Scripting Welt kommen, sich sehr schnell wohl fühlen mit Go. Ob Go eine objektorientierte Sprache ist, da scheiden sich die Geister. Objekte im klassischen Sinne gibt es nicht, zumindest werden sie nicht so genannt. Betrachtet man es im Detail, kann man aber nachvollziehen warum es Stimmen gibt, die Go als objektorientiert bezeichnen.
Wie bei anderen Sprachen auch gibt es bei Go viele Libraries die verwendet werden können, sie werden aber Packages genannt. Der in Go geschriebene Code muss kompiliert werden. Ein großer Vorteil dabei ist, dass die entstandenen Binaries standardmäßig statisch gelinkt sind. Das heißt im Umkehrschluss es muss nichts nachinstalliert werden mit gem, pip, cpan usw. Alles steckt schon in dieser einen Binary. Sicherlich lässt sich dasselbe auch mit C, C++ oder anderen Sprachen erreichen. Keine ist aber so einfach und einsteigerfreundlich wie Go. Das zählt für mich als sehr großer Vorteil, schließlich werden diese Plugins oft von Sysadmins entwickelt, deren Hauptbeschäftigung nicht das Programmieren ist.
Statisch gelinkte Binaries könnten also das Problem der Abhängigkeiten lösen. Spinnt man die Idee weiter, könnte man mit einem „monitoring plugin“ Package für Go ein Framework schaffen mit dem einheitliche Plugins entwickelt werden. Eine tolle Idee, wenn ihr mich fragt. Das Problem des packetierens lässt sich übrigens wunderbar mit fpm lösen, dazu aber vielleicht ein anderes Mal mehr.
Mein Aufruf an dieser Stelle also: Schreibt eure monitoring Plugins in Go, denn ich möchte mich nicht stundenlang damit Beschäftigen sie zum Laufen zu kriegen!
Statisch gelinkte Monitoring-Plugins!? Bitte erspart der Welt so ein Desaster. Dann wären wir beim Patchen wieder auf dem Stand von Windows-Systemen vor der Jahrtausendwende!!
Mal angenommen ich habe 10 Plugins von 5 verschiedenen Autoren installiert, die alle eine bestimmte Lib nutzen. In dieser Lib wird jetzt ein Sicherheitsloch bekannt. Der Autor fixt den Bug. Heute kann ich einfach diese neue Version der Lib einspielen und bin das Problem los.
Mit statisch gelinkten Plugins sieht es wohl eher so aus: Einer der Plugin-Autoren bekommt das Problem von selbst mit und baut seine Plugins mit der gefixten Lib neu. 2 der Autoren kann ich auf Nachfrage dazu bringen und bei allen übrigen Plugins kann ich mich entweder selber drum kümmern, mir eine neue Version irgendwie aus den Sourcen neu zu bauen oder bekomme das Plugin gar nicht gefixt.
Und darin soll ich jetzt wirklich einen Mehrwert sehen?
Gegenszenario: Du hast 10 Plugins die auf die selben Libs zugreifen. Du aktualisierst die Libs und 7 dieser Plugins funktionieren nicht mehr weil sie nicht mit der neuen Version kompatibel sind. Wer fixt jetzt die Bugs?
Gegenszanatio2: Du hast 10 Plugins die auf die selben Ruby Gems zugreifen. Hast du Patch management für Ruby Gems? Wie siehts aus mit cpan? Pip? Pear? Npm?
Der Blogpost ist ein Gedankenspiel, kein Grund aus dem Fenster zu springen 🙂
Theoretisch besteht die Möglichkeit, dass das Update einer Lib die Funktionalität beeinträchtigt, da gebe ich Dir Recht. Jetzt beschäftige ich mich allerdings seit >10 Jahren mit Nagios-/Icinga-Plugins und habe in der Zeit sehr oft Libs aktualisiert. Ich erinnere mich gerade an keinen einzigen Fall, wo mir dadurch ein Plugin kaputt gegangen wäre. Also kurz gesagt: In der Praxis funktioniert das aktuelle Modell meiner Einschätzung nach sehr gut, weil – großes Lob mal an der Stelle an die Entwickler der verschiedensten Libs – die Jungs das Thema Rückwärtskompatibilität im Blick haben und dafür meist verdammt gute Lösungen finden.
Aber darum geht’s mir gar nicht in erster Linie: Ich hätte mir von dem Blogpost einfach nur eine etwas ausgewogenere Darstellung gewünscht. Klar ist ein statisch gelinktes Plugin ggf. viel schneller installiert – aber eben auch mit Einschränkungen, was die Wartbarkeit des Gesamtsystems angeht. Solche „Ewigkeitskosten“ finde ich sollte man nicht einfach unter den Tisch fallen lassen.
Die Contra’s sind jetzt auch aufgeführt, wer sich dafür interessiert, kann die jetzt hier auch lesen und sich dann seine eigene Meinung dazu bilden. Damit ist das Thema erledigt und wir können gerne bei nächster Gelegenheit wieder ein Bier zusammen trinken.