Von der Entwicklung bis zur Produktreife mit Docker

Die RISC Software GmbH unterstützte das LKR Leichtmetallkompetenzzentrum Ranshofen bei der Ausrollung eines Softwareprodukts zur Produktion im Aluminiumstrangguss. Durch diese Software ist für die genaue Parameterkonfiguration über eine Webapplikation möglich. Um unterschiedliche Nutzerumgebungen und Versionen zu vereinen, wurde auf die Plattform Docker zurückgegriffen.

Moderne Softwareprojekte benötigen eine Vielzahl unterschiedlicher Bibliotheken, Systemeinstellungen, Umgebungen und Dienste in jeweils unterschiedlichen Versionen. Das Endprodukt muss jedoch auf einer Vielzahl von Systemen laufen. Docker hat sich als De-Facto-Norm herausgebildet, diese abweichenden Bedingungen unter einen Hut zu bringen.

Die RISC Software GmbH brachte mit dem LKR Leichtmetallkompetenzzentrum Ranshofen von März bis Juli 2022 das FReSGo-Rahmenwerk von der reinen Entwicklerversion in einen Zustand, der das Ausrollen produktionsgeeigneter Installationen über Dockerabbilder ermöglicht.

Funktionalität

Das FReSGo-Rahmenwerk lässt den Benutzer über eine Webapplikation eine Parameterkonfiguration für einen Aluminiumstrangguss auswählen. Existiert für die gewünschten Parameter keine Konfiguration, so führt das Rahmenwerk eine Simulation über OpenFoam aus, um die nötige Konfiguration zu ermitteln. Webapplikation und Simulation benutzen eine gemeinsame PostgreSQL-Datenbank.

Ausgangssituation

Das Rahmenwerk inklusive der Webapplikation ist in Python geschrieben und lief auf den jeweiligen Entwicklerrechnern, ebenso jeweils eine lokale PostgreSQL-Datenbank. Die Simulation bestand aus einer C++-Komponente für OpenFOAM und dem OpenFOAM-Simulationskern, der wegen seiner anspruchsvollen Anforderungen eines verhältnismäßig hohen Aufwands zur lokalen Installation bedurfte. Die C++-Komponente musste nach jeder Änderung gebaut werden, das Wissen lag bei einem einzelnen Entwickler. Alle Quellen sind in einer LKR-internen Installation von Gitlab verwaltet.

Maßnahmen

Folgende Schritte wurden unternommen, um das implizite Wissen zu formalisieren und den Bau, das Testen und das Ausrollen in Produktionssystemen zu automatisieren:

Einführung oder Überarbeitung von Docker-Konfigurationen für jedes Unterprojekt.
Erstellung von gemeinsamen Elterndockerabbildern, sodass die Zahl der unterschiedlichen Konfigurationen niedrig blieb.
Konsolidierung von gemeinsam genutzte Informationen in Umgebungsvariablen, die in einer .env-Datei kodifiziert sind.
Basierend dem öffentlich verfügbaren Dockerabbild von OpenFOAM wurde ein Simulationsabbild erstellt, das die C++-Komponente automatisch baut.
Extraktion der Testfälle in ein eigenes Docker-Testabbild.

Ergebnisse

Die Entwicklung profitierte von der Umstellung enorm. Blieb kaputter Code im Repositorium bisher oft unbemerkt, weil er auf der speziellen Systemumgebung des einen Entwicklers tadellos lief, bei einem anderen Entwickler mit leicht abweichender Umgebung aber nicht mehr, so legte die CI/CD-Pipeline nach Bau und Ausführung der Tests Probleme viel früher offen. Fehlersuchzyklen verkürzten sich.