Golb Slexa :: 08 2022

Der IML CI Server ist ein seit 2015 produktives Werkzeug, mit dem bei uns am Institut gut 50 Projekte ausgerollt werden. Bediente Programmiersprachen für unsere Projekte sind PHP, NodeJs und Ruby - aber eine Zielsprache ist nicht limitiert. Der CI Server erzwingt den Workflow der Installations-Reihenfolge über Preview -> Stage -> Live.

Einschub:

F: Warum beschreibe ich das hier auf einer privaten Webseite?
A: Opensource wird an unserem Institut in einem Ausmass genutzt, dass ohne Opensource Produkte bei unserem Betrieb so ziemlich nichts ginge. Aber auch hauseigene Opensource-Projekte werden auf unserer offiziellen Seite ferngehalten. Begriffe, wie “Opensource” oder “GPL” sind genauso inexistent, wie “mein” hier beschriebener CI Server in der Rubrik Software-Entwicklung.

Wie das Rollout im Groben funktioniert:

Build

1. Mit einem Git clone wird der Sourcecode des Projektes in ein temporäres Build-Verzeichnis geholt.
2. Das Projekt kann mit einem definierten Hook-Skript Aktionen triggern, um Module nachzuladen, etwas compilieren, Javascript+CSS minimieren … was auch immer
3. Was dann noch im Build-Verzeichnis überbleibt, wird zu einem Archiv zusammengepackt und eine Metainfo-Datei angelegt.
4. Der CI Server kann die Installation triggern. Mitgeliefert werden 2 Plugins für einen SSH-Aufruf und Ansible AWX. Damit etwaige Tools die Installation starten können - und ohne Zugriff auf den CI-Server im internen Netz haben zu müssen, kann man das Paket per Rsync zu mehreren Zielsystemen syncen, z.B. zu einem Puppet Master oder einem abgesicherten Software-Download-Server (das ist ein seperates Open Source-Projekt).

Installation auf der ersten Phase (Preview)

1. Das Paket wartet in der Queue im Modus “zur Installation bereit”. Die Queue besitzt eine zeitliche Freigabe. Man kann erzwingen, dass eine Installation beipielsweise nur von Montag bis Donnerstag im Zeitfenster 14:00-15:00 Uhr erfolgen darf.
2. Im Projekt-spezifischen Setup ist festgelegt, ob das Rollout per SSH oder AWX mit entsprechender Parametrisierung erfolgt … und auch welche Zielsysteme existieren. Das AWX Rollout-Plugin holt sich per API die Templates, Inventories und Playbooks vom AWX Server, die in den Prohjekteinstellungen als Dropdown zur Auswahl stehen. Nach einem Build wird das Rollout-Plugin auf die erste Projekt-Phase angewendet, um das Projekt zu installieren.
3. Die Implementierung der Installation ist keine Komponente des CI Servers. Es gibt aber eine Bash-Implementierung für ein Installations-Werkzeug (ebenfalls ein separates Opensource Projekt).
4. Unsere Installation umfasst … (sicherer) Download des Software Archivs … Entpacken dessen … Start eines Hook-Skripts zur Installation und anderen Aktionen (Cleanup des Cache, Restart von Services) … Generieren von systemspezifischen Konfigurationsdateien mittels Templates
5. Feedback an den CI Server, damit dieser weiss, wie weit das Paket ausgerollt wurde.

Rollout auf Stage und Live

Rein technisch ist das identisch mit dem, was zur Installation auf Preview gesagt wurde.

Damit ein Paket von einer zur nächsten Phase freigegeben werden kann, bedingt es die Interaktion - den Klick eines [Accept] Buttons plus Bestätigung, dass man die Featrues und Software-Zustand für OK befunden hat.

Zum Update auf PHP 8.1 habe ich für eine Entwicklungsumgebung mit rootless Docker die benötigte Konfiguration aufgebaut - diese ist im Repository im Unterverzeichnis “docker” enthalten (zuvor habe ich mit einer lokalen Virtualbox-Instanz entwickelt). Das wird Weiterentwicklungen vereinfachen.

Das Update beinhaltet rein die Portierung auf ein aktuelles PHP 8.1 um es auf einem Server mit aktuellesten OS zum Laufen zu bringen. Andere Komponenten, wie Bootstrap 3 sind gnadenlos veraltet und dürfen wohl in naher Zukunft aktualisiert werden.

Screenshots

In der Übersichtsseite aller Projekte kann man filtern, um die Ansicht zum Auffinden “seines” Projektes zu reduzieren.

Ein neuer Build erhält basierend auf dem Hash der Commit ID einen Farbcode. Damit lässt sich optisch darstellen, wie weit ein neuer Build bereits ausgerollt ist. In jeder Phase gibt es [Info] Buttons, die einem Details im Popup aufzeigen.

Erstellen eines neuen Projektes.

Wahlt man ein Projekt, sieht man zunächst eine Seite mit Repo, Archiv (der Builds) und die Phasen des Projekts

In den Projekt-Einstellungen .. Tab Rollout: hier das AWX-Plugin mit den allg. Voreinstellungen. Jedes einzelne Feld lässt sich in jeder der Phasen äbernehmen oder aber nochmals übersteuern.

weiterführende Links:

1. Repo: IML CI Server (Opensource; GPL 3.0)
2. Docs: IML CI Server auf os-docs.iml.unibe.ch (WIP)
3. Repo: IML CI Paket Server (Opensource; GPL 3.0) - Software-Archiv für ein öffentlich zugängliches System, welches nur sichere Downloads mit one time Tokens zulässt
4. Docs: IML CI Paket Server auf os-docs.iml.unibe.ch
5. Repo: IML CI Deployment Client (Opensource; GPL 3.0) - Bash-Skript zur Installation via IML CI Paket Server, Ondeploy-Hook, Generierung von Konfigurationen aus Templates
6. Docs: IML CI Deployment Client auf os-docs.iml.unibe.ch

Unter https://www.axel-hahn.de/docs/[POJEKT] habe ich diverse Hilfen für PHP- und Javascript Tools bereitgestellt, die ich mit einem Parser generieren lasse. Jener Ansatz ist etwas älter und länger her - und stellt bereits geraume Zeit so einige meiner Dokumentationen bereit…

Eigentlich suchte ich nach einem mehr generischen Ansatz, um heutzutage in Git übliche Markdown-Dateien in statisches HTML umzuwandeln. Es gibt da diverse Tools, aber ich bin beim PHP-CLI Tool Daux hängengeblieben. Insbesondere, weil ich hier im Gegensatz zu anderen angetesten Werkzeugen keine Extra Konfiguration für einen Navigationsbaum als Config-Datei hinterlegen muss. Auch hat der Entwickler sehr schnell reagiert und auf gemeldete Feature Requests reagiert. Kurz: ich habe nun diverse einzelne Dokumentationen verschiedener Produkte und Klassen mit Daux gebaut. Das sind jeweils statische Verzeichnisse mit statischen HTML-Dateien + Javascript und Css out of the Box in jedem Browser laufen, wenn man sie vom Filesystem oder aber USB-Stick startet.

Was diverse Markdown zu Html Generatoren bieten, ist ein eingebauer Webserver für eine Vorschau. Der hilft beim Schreiben der Markdown-Dateien. Mittlerweile in Markdown Quasi-Standard ist der Support von mathematischen Formeln oder aber Graphen (mermaid.js) - das soweit ich auf Github, Gitlab oder aber lokal im Visual Studio Code per Markdown Preview gesehen habe.

Soweit so gut. Und wenn ich nun zig alleinstehende Dokumentationen habe und eine Index-Seite haben will?

Ich habe dazu einen Ansatz zum Generieren einer Index-Seite wie folgt gewählt:

• ich möchte Gruppen: nach Programmiersprache oder nach einer sonstigen Rubrik
• in jeder Rubrik werden N Projekt-Dokumenationen verlinkt
• … wobei jene referenziert wird als Git-Repository, um diese mit Daux on the fly generieren zu lassen
• … oder aber: weil ich noch meine geparsten Dokumentationen habe: ich kann anderweitig bestehende Dokumentationen ebenfalls einbetten
• die Index-Seite soll flexibel sein und verschiedene Templates/ CSS/ Javascritpt unterstützen

Ich habe dazu ein Bash-Skript geschrieben, das mit jq eine JSON Config-Datei parst und mittels eines Templates die Seitenelemente generieren lässt. Die Flexibilität steckt in den Templates - dese bestimmen, ob es ein

OK, all das ist zu viel Text … so sieht meine Übersichtsseite mit dem Template mit Gruppen und Boxen sieht so aus: Axels Docs

weiterführende Links: (en)

1. Axels Docs-Index-Seite
2. daux.io Hilfe-generator - Markdown zu HTML
3. Github: axelhahn/multidoc-generator
4. Statische Hilfe zum multidoc-generator
5. Mermaid.js

Hach, das war ja mal wieder eine lustige Spam-Mail.

Jemand mit Absender info@republicofskincare.com kennt sich supergut mit Computern aus! Bei dem etwas fachfremd anmutenden Domainnamen ist es gut, dass sie sogleich mit fundiertem Wissen glänzen und meine Bedenken sowas von vom Tisch fegen.

Ganz usability freundlich werden mir 2 grosse Buttons angeboten. Der linke von beiden ist geisterhaft weiss und ist nicht beschriftet - den soll ich wahrscheinlich gar nicht anklicken. Dann ist ja nur noch einer übrig. Das nenne ich durchdachte Benutzerführung.

“Branchenbester Malware-Schutz, Adware- und Spyware-Cleaner
Repariert Dateien & ist ressourcenschonender als jedes andere Antivirus.”

Grandios!

Es ist ein halbes Jahr her, dass ich Synology von DSM 7 auf Version aktualisierte. Dies bedingte eine neue Installation einer neueren Version von Emby. Und irgendwie war die Video-Wiedergabe seither immer nur am Ruckeln, dass ich den Spass verlor. Verursacher war Ffmpeg, das on-the-fly das Video-Ausgangsfile für eine Wiedergabe auf einem Ziel in eine Auflösung umrechnet. Mit Herunterschrauben der Auflösung während der Videowiedergabe kam man dem bei, aber schlechtere Auflösungen trüben auch den Filmgenuss.

Wie es der Zufall will habe ich mich nun nochmals in den Emby-Einstellungen verirrt (von der Emby Startseite rechts oben das Zahnrad-Symbol).
Unter Wiedergabe -> Video -> Heimnetzwerkqualität habe ich “auto” voreingestellt.
Im Menü unterhalb “Server” gibt es den Eintrag “Transcodiere“, wo man Hardware-Beschleunigung und andere Transcoding-Einstellungen setzen kann. Ich habe weder Emby Premiere noch würde ich mit der Synology eine Hardware-Beschleunigung aktivieren können. Aber auf dieser Einstellungsseite ist ja noch mehr.

Unter “H264-Kodiereinstellung” war “auto” gewählt. Und was soll ich sagen: das bewusste wählen einer langsameren Einstellung wirkt Wunder. Während bei Einstellung “auto” bei Fimlwiedergabe die CPU nahezu ausgelastet war und der Load sich bei 15 einpegelte … hingegen bei “superfast” wird die CPU nur noch kurz zu 20% belastet und liegt dann im einstelligen Bereich. Und bei Videowiedergabe die gewählte Videoqualität mit “auto” besser, als die zuvor gedrosselte Bandbreiten-Auswahl, damit es nicht ruckelte.

Wer mag, kann es von der schlechtesten Qualitätsstufe “superfast” schrittweise noch hochsetzen. Aber das ist eine gute Stellschraube, bei der man ansetzen kann.