Automatisierung digitaler Infrastruktur

Der Konstitumator als Automatisierung digitaler Infrastruktur

Die Idee hinter dem Konstitumator

Aufgrund der voranschreitende Digitalisierung steigt der Bedarf an der Einrichtung und Verwaltung digitaler Ressourcen, beispielsweise Entwicklertools wie BitBucket Repositories aber auch Social Media Anwendungen wie Microsoft Yammer und der damit einhergehende zeitliche Aufwand. Da die Entwicklungsressourcen jedoch endlich sind, kann dieses Problem nur durch einheitliche, möglichst automatisierte und wiederverwendbare Lösungen behoben werden. Im Folgenden stellen wir den “Konstitumator” als eine mögliche Lösung dieser Problemstellung vor.

Wir, die esentri AG, legen unseren internen Fokus auf eine kollegiale Führung, weshalb die Organisation grundlegend in Kreise aufgeteilt ist. Diese Organisationsstruktur ermöglicht eine hohe Transparenz und Effizienz. Neben den Geschäftskreisen existieren bei uns derzeitig 16 Projektkreise, auf welche die erläuterte Problemstellung am häufigsten zutrifft. Diese beinhalten unterschiedliche Anforderungen und Zuständigkeiten, welche sich stetig ändern können. Bei der Eröffnung eines Kreises wird bei uns von einer Konstitution gesprochen, bei der die grundlegenden Strukturen und Prozesse dieser Gruppe festgelegt werden. Entstanden ist dieses Projekt in der Theorie bei uns erstmals infolge einer Abschlussarbeit und wurde Mitte Januar 2022 als studentisches Projekt gestartet.

Wie sieht ein Use-Case für den Konstitumator aus?

Angenommen, die Entstehung eines neuen Projektes steht bevor, bei dem es sich um die Umsetzung einer Web-Application handelt, welche zudem innerhalb von AWS zur Verfügung gestellt wird. Aufgrund dieses Einleitungssatzes kann man sich als Leser schon vorstellen, wie viele Ressourcen für die Entwicklung notwendig sind. Neben Entwicklungstools wie beispielsweise BitBucket für die Versionskontrolle und Jira für die einheitliche Definition von Aufgaben, sind auch verschiedene Ressourcen innerhalb von AWS nötig, damit eine Bereitstellung der Web-Application möglich ist.

Um diese Vielzahl von Tools nun bereitzustellen, wird meist die interne IT beauftragt, die nötigen Zugänge händisch anzulegen und Rechte auf die Mitglieder aufzuteilen. Diese Aufgabe nimmt kostbare Zeit und Aufwand in Anspruch, welche durch eine einheitliche Lösung ausgelagert werden kann. Hier kommt der Konstitumator ins Spiel, dieser kann durch HTTP-Request angesteuert werden und bietet die Möglichkeit, Ressourcen im Rahmen eines Projekts aufzusetzen und den Zugang für Mitwirkende zu ermöglichen./*—

Was steckt an Technik hinter dem Konstitumator?

Der Konstitumator ist ein Server-System, welches in Java konzipiert wurde und über eine Schnittstelle (API) bedient werden kann. Hierbei werden seitens des Konstitumators verschiedene Services bereitgestellt, die von Benutzern genutzt werden können, um Konstitutionen aufzusetzen, aufzulisten, zu ändern oder verfügbare Terraform Ressourcen-Module auszugeben.

Angenommen, das im Anwendungsfall genannte Projekt soll nun umgesetzt werden, beginnend mit dem Erstellen eines BitBucket Repository. Hierfür wird durch den Anwender eine Anfrage an den Konstitumator geschickt, mit den nötigen Inhalten, beispielsweise den Entwicklern, die am Ende darauf Zugriff haben sollen.

Die eingehende Anfrage wird zuerst innerhalb eines Rest Services im Konstitumator verarbeitet und an die notwendigen weiteren Services weitergeleitet. Hierzu gehört der GitService, bei dem die aktuelle Version aller Terraform-Module abgerufen wird. Welche im weiteren Verlauf benötigt werden, damit im nächsten Schritt alle Funktionen auf dem neuesten Stand sind. Hierbei kommuniziert der Konstitumator mit dem intern genutzten Terraform Repository (zu sehen in der folgenden Abbildung). In diesem liegen alle verfügbaren Terraform-Module mit der jeweils aktuellsten Version.

Im nächsten Schritt wird innerhalb eines weiteren Services, dem TerragruntService, die notwendige Terragrunt Datei basierend auf den Inhalten der eingegangenen erstellt und anschließend ausgeführt. Das Ausführen dieser Datei führt das vorher angesprochene Terraform-Modul zur Erstellung eines BitBucket Repository aus und legt den aktuellen Zustand als Terraform State (siehe https://developer.hashicorp.com/terraform/language/state) in einem S3 Bucket in AWS ab. Anschließend wird die erstellte Terragrunt Datei in unserem Terragrunt Repository gespeichert. Die Kommunikation mit AWS und dem Terragrunt Repository ist ebenfalls im nächsten Schaubild zu sehen. Das Speichern des Terraform State und der Terragrunt Datei sind essentiell, um das Projekt und dessen Ressourcen, wie in diesem Fall das BitBucket Repository, zu einem anderen Zeitpunkt ändern oder auflisten zu können.

Die Schnittstelle des Konstitumators ist eine REST-API und kann über HTTP-Anfragen angesteuert werden. Die nachfolgende Swagger-Dokumentation beschreibt alle verfügbaren Endpunkte der Schnittstelle.

Wie sah der Projektablauf aus?

Das Projekt wurde in fünf Meilensteine aufgeteilt mit der Absicht, dass der Konstitumator nach dem letzten Meilenstein alle Funktionen beinhaltet. Der erste Meilenstein beinhaltet das Ausführen von Terragrunt-Konfigurationen, welche händisch angelegt wurden. Um diesen Schritt des Anlegens zu automatisieren, wurde innerhalb des zweiten Meilensteins der Fokus auf das Erstellen von Terragrunt-Konfigurationen und das Abbilden von Projekten als Ordnerstruktur gelegt.

Der dritte Meilenstein, welcher der aktuelle Stand des Konstitumators ist, umfasst das Auflisten von verfügbaren Terraform-Modulen und existierenden Terragrunt-Modulen bei Anfragen über die API-Schnittstelle. Hierfür wurde ein Type-Parser erstellt, welcher die Datentypen der Modul-Variablen aus den Terraform-Modulen einliest. Der große Vorteil hierbei: noch bevor Terraform überhaupt ausgeführt wird, kann die Anwendung dem Benutzer Fehler innerhalb der Inputs aufzeigen.

Der vierte Meilenstein dient dem Umgang mit mehreren Terraform-Modulen, hierbei steht die Umsetzung von Abhängigkeiten zwischen den Modulen im Zentrum. Hierdurch wird das Aufsetzen und Verwalten von Konstitutionen mit mehreren Ressourcen ermöglicht. Da Projekte auch zu einem Abschluss kommen und die verwendeten Ressourcen nicht weiter benötigt werden, dient der fünfte und letzte geplante Meilenstein der Umsetzung des Löschens von Konstitutionen.

Wie wird der Konstitumator bereitgestellt?

Im bisherigen Entwicklungsprozess des Konstitumators wurde Continuous Integration und Continuous Deployment (CI/CD) verwendet. Die hierfür genutzte Pipeline ist BitBucket Pipelines, da die Versionierung des gesamten Projekts in BitBucket verwaltet wird.

Innerhalb der Pipeline existieren die folgenden drei Schritte: das Testen, Bauen und Bereitstellen des Projekts. Dabei beschränkt sich das Testen auf das Ausführen von Unit-Tests mittels Maven. Der zweite Schritt ist das Erzeugen einer JAR-Datei. Dieses ausführbare Java-Archiv wird daraufhin als Artefakt für den nachfolgenden Schritt innerhalb der Pipeline gespeichert. Hierbei werden die bisherigen beiden Schritte bei jedem Pull-Request ausgeführt. Der folgende Schritt wird hingegen nur bei einem Merge auf den Entwicklungszweig ausgeführt, auf dem zu jederzeit ein funktionierender Entwicklungsstand des Konstitumators bereitsteht.

Abschließend im dritten und letzten Schritt wird ein Docker-Image mit der JAR-Datei des Konstitumators erzeugt und in AWS Elastic Beanstalk (EBS) bereitgestellt. Hierfür wird das Docker-Image innerhalb der Pipeline erzeugt und anschließend in AWS Elastic Container Registry (ECR) hochgeladen. Anschließend wird ein Verweis auf die aktuelle Version des Docker-Images in der EBS-Umgebung bereitgestellt und eine Aktualisierung der EBS-Umgebung und Anwendung angestoßen.

Nach diesem letzten Schritt ist der Konstitumator über die URL des EBS erreichbar und kann wie in der bereits gezeigten Swagger-Dokumentation verwendet werden.

Welche Herausforderungen gab es?

Einerseits bestand die Herausforderung im Projekt darin, eine Lösung für die fehlende Kompatibilität zwischen Java und Terraform zu finden. Hierfür gibt es bislang keine passenden Java-Bibliotheken, weshalb die Erstellung von Terraform-Modulen und deren Ausführung durch Terragrunt improvisiert wurden. Abgesehen davon fiel die in der Vision des Konstitumators angenommene Zeit- und Aufwandsreduktion deutlich geringer aus als erwartet. Fairerweise muss erwähnt werden, dass der mögliche Umfang des Konstitumators nicht vollständig ausgeschöpft wurde. Gerade das Zusammenspiel einzelner Ressourcen hätte einen besseren Einblick über den Vorteil des Konstitumators geben können.

Fazit

Das Projekt Konstitumator musste bei uns beendet werden, da sich der zeitliche Aufwand nicht mehr gelohnt hat. Eine nachvollziehbare Entscheidung, jedoch keine leichte, da der Konstitumator ein stetiger Begleiter seit mehr als einem ganzen Jahr war. Hinzukommend bot der Projektkontext eine Vielzahl an unterschiedlichen Einblicken in die Softwareentwicklung. Das Projekt konnten auch die unerfahrenen Beteiligten mitgestalten, was bei einem Einstieg in die IT nicht selbstverständlich ist. Besonders der schnelle und kontinuierliche Austausch und der lockere Umgang miteinander bleiben positiv mit dem Konstitumator verknüpft.

Diese Themen könnten Dich auch interessieren

Ein Generativer KI-Assistent für Domain-Driven Design

2024-09-30

Hier erfährst Du, wie der KI-Assistent für Domain-Driven Design „Domainlifecycles Code Generator“ funktioniert und entwickelt wurde.

Chatbot Assistenten durch Nutzung von LLMs und Retrieval Augmented Generation

2024-08-28

Wir erläutern die Architektur eines Chatbots, der durch die Nutzung von LLMs und Retrieval Augmented Generation schnell und effizient auf Fragen antwortet.