Das ist eigentlich ganz einfach: Ich habe meinen Hosting-Anbieter gewechselt und lasse meine Webseiten und Webanwendungen jetzt in Containern laufen. Um die Resourcen meines Servers zu schonen und noch ein wenig Platz für wichtigere Dinge zu haben, mache ich aus zwei Containern (Wordpress & mySQL), die ziemlich viele Prozesse starten (apache2, mysql, php uvm.) nur noch einen Container, der mit nginx ein wenig sparsamer ist, kein internes Netzwerk mehr braucht und als Bonus nur einen Bruchteil der Imagegröße der anderen Lösung hat.

Und sind wir ehrlich, bei meiner Frequenz and Postings und der niedrigen Zahl an Besuchern/Tag ist das wohl mehr als ausreichend…

Nun war es halt mal wieder Zeit: Ich habe von den ganzen dunklen Farbschemata genug und habe meinen Desktop in ein helles Farbschema umgestellt. Plötzlich ist der Desktop wieder ein ganzes Stück fröhlicher und die Welt sicherlich ein bisschen besser geworden ;-)

Ich habe ziemlich viel im Internet gesucht und einige Beschreibungen gefunden, die sehr ähnlich klangen. Leider half alles nichts. Auch wenn ich das Problem so weiter eingrenzen konnte - es betraf nur meinen Benutzer, als root oder neu eingerichteter Nutzer startete Thunar immer schnell. Das kürzlich eingetroffenen XFCE 4.16 brachte auch keine Besserung. Ich hatte schon resigniert, als ich zufällig meinen Desktop-Papierkorb öffnete. Dann passierte lange Zeit gar nichts. Nach laaaaaangem Warten musste ich feststellen, dass einige Programme die ich regelmäßig nutze (u.a. Shotwell, Rhythmbox) Objekte nicht löschen, sondern in den globalen Papierkorb legen. Mittlerweile hatten sich dort fröhliche 220 GB angesammelt :-|

Nachdem ich den Papierkorb geleert habe (auch das hat sehr lange gedauert) hat sich mein Thunar wieder so flott wie immer gemeldet - auch beim ersten Start nach dem Boot! Wenn ihr mal ein ähnliches Problem habt, hilft dieser Tipp vielleicht ;-)

Und natürlich: Ein frohes neues Jahr!

Docker Multistage Builds

Das Docker-Image für das Deployment von Ranking-Info war bisher ziemlich gewichtig: rund 1,07 GB brachte es auf die Waage. Aber warum? Die Anwendung selber ist ja nicht gerade umfangreich und Konfiguration, Bilder und sonstige Bestandteile bringen auch nicht viele Daten dazu. Schuld an der enormen Image-Größe sind die vielen Abhängigkeiten und Build-Artefakte für die Installation der benötigten Rubygems. Zudem basiert das Ruby-Basisimage auf Debian Buster und bringt schon einige nicht benötigte Programme und Bibliotheken mit.

Die Lösung? Ranking Info nutzt Docker Multistage Builds! Der einfache Trick ist die Nutzung von zwei Images - eines zum Bauen der Software und eines für das Deployment. Informationen gibt es dazu im Internet tonnenweise. Und sicherlich auch verständlichere Informationen, als ich sie liefern könnte :-)
Die Methode verlagert das Bauen der Rubygems inklusive der benötigten Linux-Bibliotheken in das Build-Image. In das Ziel-Image kommen dann nur noch die Binaries und die Applikation selbst. Zusätzlich basiert das Deployment Image nicht mehr auf Debian, sondern auf Alpine (ein sehr schlankes Linux extra für Container konzipiert). Das Ergebnis? 220 MB - mehr als 80% weniger als vorher.

REPOSITORY                                                    TAG                 SIZE
docker.pkg.github.com/hwesselmann/ranking-info/ranking-info   1.4.4               220MB

Ein weiterer netter Effekt: Für viele Schritte beim Zusammenbau des Docker-Images nun der Docker-Cache genutzt werden kann. Der Build produziert also nicht nur ein kleineres Artefakt, sondern geht in vielen Fällen auch schneller!

Das Projekt findert ihr auf Github, das Dockerfile hier!

Schön länger habe ich mich geärgert: Meine alte WindBox von MSI hat meinen Plex Media Server bisher zuverlässig serviert. Aber neuere Medien (z.B. welche in HD Auflösung) können nicht direkt auf meine Endgeräte gestreamt werden. Warum? Trotz eines dicken Netzteils und scheinbar hohem Prozessortakt ist der eingebaute Celeron einfach zu schlapp - manches NAS kann da schon mehr. Da hieß es immer, optimierte Versionen erstellen und den Plattenspeicher zumüllen.

Ein Ersatz für den Plex Media Server muss her

Ich habe mich also auf die Suche nach einem Ersatz gemacht. Vom RasPi über Synology-NAS-Systeme bis zu Micro-Servern war alles in der Auswahl. Am Ende habe ich mich für einen gebrauchten Intel NUC entschieden. Übersichtlicher Stromverbrauch, sehr kleiner Formfaktor, gute Linux-Unterstützung und nicht zuletzt ein erschwinglicher Preis von knappt 140€ waren ausschlaggebend. Mit einem Core i5, 8 GB RAM und einer 120 GB SSD hat dieser NUC mehr als genug Power, um einen Plex Media Server laufen zu lassen. Inklusive Transcoding und Aufnahme via DVB-C-Stick. Die kleine Kiste lag dann eine Weile bei mir herum, denn es gab kleine Hürde. Nur der Fernseher hat einen HDMI-Anschluss - es darf für die Installation also niemand fernsehen wollen. zusätzlich besaß unser Haushalt bis vor kurzem kein Mini-auf-HDMI-Kabel.

Dann ging es aber erstaunlich schnell - anschließen, ArchLinux-Installationsmedium booten und eine Installation machen. In meiner Erinnerung war die Installation von Arch immer kompliziert und langwierig. In der Realität war alles in unter einer Stunde erledigt. Basissystem installiert, feste IP vergeben, Zeitserver eingestellt, Benutzer eingerichtet, SSH-Server konfiguriert, NFS-Shares eingebunden, überflüssige Ports geschlossen und zuletzt den Plex Media Server aus dem AUR installiert. Schon ist der Plex Media Server auf dem NUC!

Wie kam ich dazu? Bei einem Update mit trizen habe ich gesehen, dass meine aktuelle Lieblingsschrift Exo-2 keinen Maintainer mehr hat. Ich wollte da eh gerne eine aktuellere Version und habe mal zugeschlagen und das ganze Prozedere durchgeführt. Früher war es einfacher, jetzt aber wahrscheinlich ein wenig sicherer.

Meine aktuellen zwei Babies:

ttf-exo-2 - eine futuristische Schriftart (Google Fonts)
spark - ein Java-basierter Jabber-Client

Falls ihr eines der beiden Pakete nutzen sollte, freue ich mir über eure Stimme :-)
Adoptiert doch auch mal bei Archlinux ein verwaistes Paket im AUR. Ihr werdet sehen, seine Dankbarkeit macht euch glücklicher!

Nach langem Zögern gibt es jetzt für echte BVH-Fans und -Spieler eine Version in unseren Farben mit dem offiziellen BVH-Logo und -Schriftzug.

Meldet euch gerne bei mir oder unserem Sportwart, wenn ihr auch gerne stilecht unter die Leute gehen wollt!

Dort musste er gegen einen sehr passiven Defensivspieler spielen und hatte zwar die richtige Strategie, aber leider zu oft nicht den richtigen Treffpunkt. Optisch überlegen war dann trotzdem Schluss - im Winter gibt es die nächste Chance. Und mit Corona sind Sommer- und Hallenmeisterschaft ja sehr nah aneinandergerückt…

Höchste Zeit also, mal wieder mit etwas Altem herumzuspielen. Außer kleinen Skripten für die Arbeit habe ich schon sehr lange nichts mehr mit Ruby gemacht, Rails kenne ich dunkel noch in Version 2 - Lust mal zu schauen, was sich getan hat, hatte ich schon länger, die Zeit allerdings nicht. Bis jetzt.

Das Thema des Projektes war schnell klar, die Entwicklungsumgebung mit Visual Studio Code und rbenv schnell eingerichtet, ein wenig origineller Name gefunden: ranking-info!
Es ist eine kleine Webanwendung, die es dem Benutzer erlaubt, einige einfache Analyseaufgaben auf der Jugendrangliste des Deutschen Tennisbundes durchzuführen. Warum? Die Liste gibt es nur als PDF und auch nur in den Ausprägungen Alles, U12, U14, U16 und U18. Und selbstverständlich immer nur die aktuelle Ausgabe - keine Historie, keine “Trends”. Auf mybigpoint.de kann man als zahlender Kunde immerhin noch die Daten der letzten 3 Quartale abrufen, allerdings isoliert und ohne Verbindung zu den Vorgänger- oder Folgedaten.

Die Frage “Auf welchem Platz steht mein Sohn in seinem Geburtsjahrgang? Im Verband? In der Altersklasse U14?” hießen dann immer: Zählen oder raten. ranking-info erledigt genau das alles automatisch - man muss lediglich die Gesamtrangliste in ein CSV-Format umwandeln, importieren und los geht’s! Wie sieht das ganze aus? So:

Neben ein paar Kleinigkeiten, die ich gerne noch einbauen würde und vielen möglichen Verbesserungen am Code könnte ich das ganze eigentlich im Netz verfügbar machen - ich muss nur noch klären wo ich die Anwendung am einfachsten deployen kann und ob ich die Daten überhaupt öffentlich verwenden darf - auch wenn die Ursprungsdaten frei verfügbar sind, ist das leider noch lange kein Indiz dafür, dass die Weiterverarbeitung erlaubt ist…

Die Arbeit mit Ruby und Rails war wie in der Vergangenheit sehr spaßig. Wenig war kompliziert, Testen war eingebaut und Activerecord macht nach wie vor mehr Spaß als die Dinge, die ich bei meiner richtigen Arbeit im Java-Umfeld verwenden darf. Die letzten Tage haben auf jeden Fall Lust auf mehr geweckt :-)