Infrastruktur
Hier wird beschrieben, wie die Infrastruktur aussah, die uns zur Entwicklung und zum Deployment der Microservices zur Verfügung stand. Außerdem wird darauf eingegangen, welche Probleme bei der eingangs übernommenen Infrastruktur bestanden, was wir daran geändert haben und welche Probleme noch immer bestehen.
Für das Deployment der weiterzuentwickelnden Komponenten stand eine Ubuntu-VM zur Verfügung, die via SSH administriert werden konnte. Dort war eine funktionsfähige Version der Docker-Engine und docker-compose installiert, um die gebauten Docker-Artefakte zu deployen.
Docker wurde verwendet, um die weiterzuentwickelnden Services plattformunabhängig und trotzdem isoliert voneinander zu deployen. Dabei bildeten die Dockerfiles der einzelnen Komponenten die Basis, da dort beschrieben stand, wie die jeweiligen Komponenten gebaut werden mussten. Dort stand beispielsweise, auf welchem Basis-Image das zu bauende Docker-Image basiert. Somit sind viele der grundlegend notwendigen Entwicklungswerkzeuge und Bibliotheken bereits in das zu bauende Image integriert (JDK, Node, bash, etc.). Außerdem steht dort welche Software-Artefakte mit in das Image kopiert werden müssen und wie die Artefakte letztendlich gestartet werden. Die zugehörigen docker-compose-files beschreiben hingegen, wie die einzelnen Services gestartet werden, welche anderen Komponenten sie als Abhängigkeit besitzen (SQL-Datenbank, etc.) und wie sie zur Laufzeit über das Netzwerk kommunizieren.
Als Continuous Integration und Deployment (CI/CD) Server stand ein Jenkins-Server zur Verfügung, der auf einer separaten VM lief. Jeder Microservice enthielt ein Jenkinsfile, welches die Jenkins-Implementierung von Pipeline as Code darstellt. Somit war die Pipeline selbst, also die komplette Beschreibung zum Bauen und Deployment der Software, teil des Code-Repositories. Insbesondere die Reproduzierbarkeit der Pipeline stellt bei Pipeline as Code einen enormen Vorteil dar. Auch die Rekonfiguration der Pipeline stellt damit eine Programmieraufgabe dar, die kaum gesondert von anderen Entwicklungstätigkeiten behandelt werden muss.
Alle aus dem Internet erreichbaren Services von ArchiLab befinden sich hinter einem Reverse Proxy, der die eingehenden Anfragen anhand der angefragten URLs und Ports entsprechend weiterleitet. Diese Konfiguration war bereits vorgenommen. Somit führte ein Deployment auf dem Deployment-Server mit den richtigen Ports zu einer direkten Erreichbarkeit der Services aus dem Internet. Es handelte sich also bei der Pipeline um eine Continuous Deployment Pipeline, bei der ein Code Push zu einem direkten Deployment führte.
Als wir das Software-Projekt übernahmen, waren die Pipelines der einzelnen Microservices teilweise sehr unterschiedlich. Die hat anfangs zu Verwirrung geführt und erschwerte die Entwicklung. Insbesondere der Umgang mit Umgebungsvariablen war sehr unterschiedlich. Diese waren teilweise in die Pipeline als Code einprogrammiert, teilweise lagen sie nur als Konfigurationsvariablen im Jenkins-Server selbst vor oder waren sogar nicht vorhanden, wurden aber trotzdem innerhalb der Pipeline referenziert. Um dieses Problem zu beheben, haben wir zunächst geprüft, welche Variablen überhaupt in Verwendung waren, wo diese verwendet wurden und ob es überhaupt Sinn macht die entsprechenden Konfigurationen als Umgebungsvariablen zu definieren. Wir haben uns dazu entschieden, nur die überall verwendeten Variablen beizubehalten und diese dann in allen Services mit in die Pipeline zu programmieren. Ansonsten wäre ein großer Nachteil von Pipeline as Code, die Reproduzierbarkeit, gefährdet, da es schwer nachzuvollziehen wäre, wie die Belegungen der Variablen lauten und wo diese definiert sind. Außerdem haben wir die Pipelines in sinnvolle Schritte aufgeteilt. Wir haben dabei nicht alle gängigen Schritte einer modernen Pipeline genutzt, sondern uns nur auf die Wesentlichen beschränkt (Build, Test, Code Quality Check und Deployment). Einige davon mussten wir aus Zeitgründen mit einer simplment Info-Nachricht befüllen, die lediglich Auskunft über den aktuellen Schritt in der Konsole ausgibt. Ein weiteres Problem war die Art, wie die gebauten Docker-Images auf den Deployment-Server übertragen wurden. Statt wie bei Docker üblich die gebauten Images in einer Docker-Registry zu speichern und dann beim Deployment von dort zu laden, wurden die Images in ein tar-Archiv verpackt, mittels scp auf den Server übertragen und mit SSH gestartet. Wir haben uns dazu entschieden, dies zunächst beizubehalten, da es unserer Meinung nach wichtigere Probleme zu lösen gab.
