Containerisierung von Software ebnet Weg in die Cloud

Manuel Kirchner, Head of DevOps der Finanz Informatik Solutions PlusFI-SP

Die Wege in die Cloud stehen für Finanzdienstleister in der Softwareentwicklung offen. Die dafür notwendigen Cloud-Technologien sind als Open-Source-Lösungen verfügbar. Docker-Container bieten eine einfache, schnelle und robuste Möglichkeit, Software zu entwickeln, zu testen, zu verteilen und in virtualisierten Umgebungen zu betreiben. Orchestrierungstechnologien wie Kubernetes und das Versionskontrollsystem GitLab sind weitere wichtige Open-Source-Lösungen, mit denen containerisierte Software nach Cloud-Prinzipien betrieben und dabei revisionssicher dokumentiert wird. Der Modernisierung auch hoch komplexer, unternehmenskritischer Kernanwendungen steht damit also aus technischer Sicht nichts mehr entgegen. Aber worauf kommt es dabei in der Praxis wirklich an?

von Manuel Kirchner, Head of DevOps der Finanz Informatik Solutions Plus

Bei der Containerisierung werden alle Infrastrukturkomponenten für den Betrieb eines Services (z.B. Microservice oder Java Anwendung) in einem Container „verpackt“. Hierbei startet man mit einem Basisimage (z.B. Ubuntu) und ergänzt Schicht für Schicht die benötigten Komponenten. Die Beschreibung erfolgt dabei in einer einfachen Textdatei (Dockerfile), die gut mit dem Anwendungscode versioniert werden kann.

Im Falle einer typischen Enterprise-Java-Anwendung werden zum Beispiel auf die Betriebssystem-Komponenten zuerst die benötigte Java-Version, dann ein JBOSS und schließlich die eigentliche Anwendung konfiguriert. Die Images können dann auf jeder beliebigen Container-Plattform ausgeführt werden. Hierdurch können beliebige Versionen (zum Beispiel Java 8 mit 11) und sogar Technologien (zum Beispiel NodeJS) in einer Anwendung vermischt werden. Im Vergleich zu einer virtuellen Maschine (VM) laufen die Container aber physisch auf dem jeweiligen Host-System und haben einen deutlich kleineren Ressourcenverbrauch als komplette Betriebssystem-Virtualisierungen, da nur die wirklich benötigen Komponenten (Binaries) verpackt werden. In der Entwicklung ist Docker die derzeit bekannteste Open Source Container-Technologie.

Nutzen der Containerisierung

Die Modernisierung unternehmenskritischer Software ist aufwändig und damit auch kein Selbstzweck. Sie erfordert einen strategischen Rahmen.”

Digitalisierungsstrategien sind bei Finanzdienstleistern in der Regel der Nukleus für langfristig angelegte Modernisierungsprojekte. Mit diesen stellen die Institute ihre vorhandene IT-Basis auf eine neue technische Grundlage. Cloud-Technologien sind dabei die Grundlage für flexible Anwendungslandschaften, in denen Software zügig entwickelt und ausgerollt werden kann, bedarfsgerecht einsetzbar ist und entsprechend ihrer realen Nutzung berechnet wird.

Durch Container sinkt die Time-to-Market für neue Anwendungen — FI-SP

Um die Modernisierung möglichst in der Praxis effizient durchzuführen, ist eine Reihe von Schritten notwendig. Eine intensive Analyse der bestehenden Anwendungen im Hinblick auf ihre Containerisierungspotenziale steht dabei am Anfang eines jeden Modernisierungsprojektes. Das Entwicklungsteam (Dev-Team) analysiert dabei gegebenenfalls in Kooperation mit dem Betriebsteam (Ops-Team) die einzelnen Komponenten und Technologien jeder Anwendung und beurteilt die Eignung für die Umstellung auf Software-Container. Dabei wird zunächst geprüft, welche Anwendungskomponenten selbst kontrolliert werden und welche extern laufen. Erstere bieten sich direkt für eine Containerisierung an, da das Unternehmen Hoheit über den Sourcecode und die Entwicklungsstände hat. Für letztere können gegebenenfalls Mock-ups gebaut werden, die in Containern laufen beziehungsweise per Konfiguration angebunden werden.

Ein weiterer wichtiger Faktor ist es, die Persistenz der Anwendungen zu gewährleisten. Dazu müssen die Teile beziehungsweise Daten der Komponenten ermittelt werden, die dauerhaft gespeichert werden sollen.

Roadmap für die Containerisierung von Software

In komplexen IT-Landschaften kommt es auf eine stringente Roadmap für die Umstellung der Software an. Ein wichtiges Entscheidungskriterium für die Roadmap zur Containerisierung der Anwendungslandschaft ist die Dringlichkeit des Handlungsbedarfs bei einzelnen Anwendungen.

In der Praxis zeigt sich, dass es nahezu bei jedem Finanzdienstleister zahlreiche Anwendungen gibt, die nicht optimal ausgerollt werden können.”

Beispiel dafür sind etwa Anwendungen, bei denen sehr viele manuelle und fehleranfällige Arbeitsschritte für das Einspielen neuer Releases nötig sind. Aber auch regulatorische Anforderungen können ein Grund sein, Anwendungen zu containerisieren beziehungsweise in die DevOps-Pipeline aufzunehmen. Das gilt in besonderem Maße, wenn die ausgelieferten Artefakte von Anwendungen über die verschiedenen Umgebungen hinweg wenig oder überhaupt nicht veränderbar sind. Und schließlich stellen Kundenanforderungen ein weiteres wichtiges Kriterium dar, ob eine Anwendung vorrangig containerisiert wird oder nicht.

Autor Manuel Kirchner, FI-SP

Manuel Kirchner ist als Head of DevOps bei der Finanz Informatik Solutions Plus für das Design und den Betrieb der zentralen DevOps-Infrastruktur verantwortlich. Seine persönlichen Schwerpunkte liegen neben den rasanten technischen Entwicklungen im DevOps-Umfeld auch auf der Förderung einer entsprechenden DevOps-Kultur im Unternehmen. Durch seine langjährige Erfahrung als Softwareentwickler im Java Enterprise-Umfeld hat er aber auch immer ein Auge auf neue Entwicklungen und schaut dabei gerne über den Tellerrand.

Die FI-SP ist seit rund 20 Jahren IT-Outsourcing-Partner in der Sparkassen-Finanzgruppe und beschäftigt über 400 Mitarbeiterinnen und Mitarbeiter an den Standorten Frankfurt am Main, Fellbach und in der Geschäftsstelle München. Die Finanz Informatik Solutions Plus ist eine hundertprozentige Tochtergesellschaft der FI.

Software-Infrastruktur-Architektur

Die Entwicklung einer geeigneten Software-Infrastruktur-Architektur für eine auf Containern basierende Anwendungslandschaft setzt eine detaillierte Analyse der einzelnen Komponenten und deren Kommunikationsverbindungen voraus. Wichtig ist zudem eine dezidierte Beschreibung der Komponenten und Verbindungen in Docker- oder den entsprechenden Kubernetes-Dateien. Infrastrukturelemente, die auf allen Ebenen (Stages) identisch sind, müssen von dynamischen Elementen unterschieden werden. Die jeweils dynamischen Teile können dabei zum Beispiel über Umgebungsvariablen gesteuert werden.

Die eigentliche Konzeption der Software-Infrastruktur-Architektur hängt von den Möglichkeiten zur Automatisierung ab. Ein sehr hohes Automatisierungspotenzial bis hin zur Vollautomatisierung, Skalierbarkeit, Standardisierung, Wiederverwendbarkeit und Reproduzierbarkeit sind entscheidende Kriterien, die dabei berücksichtigt werden. Die Containerisierung/Verpackung der Anwendungskomponenten in Container erfolgt schichtweise. Zunächst wird das Basis-System ermittelt und ein passendes Speicherabbild eines Containers (Image) ausgewählt. Dafür kann ein Docker-Hub oder eine firmeninterne Docker Registry genutzt werden. Das Basis Image sollte dabei möglichst nah an dem in der Produktion verwendeten Betriebssystem sein. Auf diese Weise wird auf allen Ebenen die Kompatibilität der Zielumgebung sichergestellt.

Beschreibung der Infrastruktur

Orchestrierungstechnologien wie Kubernetes machen aus einzelnen Softwarecontainern flexible Anwendungslandschaften. Kubernetes-Konfigurationsdateien beschreiben das Zielbild eines Systems.”

Sie definieren beispielsweise, wie viele Instanzen von einzelnen Services bereitgestellt werden sollen, welche URL an welchen Service geroutet werden soll oder auf welche virtuelle Maschinen eine Instanz verteilt werden soll. Kubernetes stellt den beschriebenen Zustand her. Fällt ein Service aus, startet Kubernetes automatisch einen neuen, bis der beschriebene Zustand wieder erreicht ist. Falls ein Knoten offline geht, fährt Kubernetes die Container auf einem anderen Knoten wieder hoch.

Im Gegensatz zu Monolithen bieten Container eine freie Wahl der Technologie …”

… das heißt: Teile der Anwendung lassen sich in einer für das jeweilige Problem geeigneten Technologie umsetzen. Die Modularisierung von Anwendungen erfolgt entweder über die Modularisierung ausschließlich neuer Programmteile oder schrittweise komplett. Von Vorteil ist es, kleine Module zu modularisieren, da sie unabhängig von großen Applikationen entwickelt und verteilt werden können. Dabei kommt es auf eine ausreichend hohe Performance an, denn kleine Module lassen sich leicht und automatisch skalieren. Darüber hinaus können Updates eingespielt werden, ohne dass die ganze Anwendung ein Update benötigt.

Zentrale Bereitstellung von Projektinstanzen via FI-SP

FI-SP hat für den internen Einsatz eine Lösung entwickelt, mit denen die DevOps-Abteilung den Entwicklungsprojekten containerisierte Tools zur Verfügung stellt. Die Praxis hat gezeigt, dass es unter anderem aufgrund regulatorischer Anforderungen sinnvoll ist, den Projekten eigene Instanzen zentral zur Verfügung zu stellen. So kann sich ein Projekt aus einem DevOps-Tool-Katalog die benötigten Tools auswählen, die dann automatisiert und vollständig vorkonfiguriert als Projektinstanz durch das DevOps-Team bereitgestellt werden. Dies hat viele Vorteile bei der Resourcenverteilung. Durch die physische Trennung der Instanzen ist zudem bereits eine klare Mandantentrennung und die leichte Umsetzung von Berechtigungskonzepten im System integriert. Die Projekte haben dabei sowohl den Vorteil der zentralen Bereitstellung und Wartung der Tools, als auch eine hohe eigene Administrier- und Anpassbarkeit. Nach Abschluss eines Projektes können die Instanzen dann archiviert werden und nehmen keine wertvollen Ressourcen mehr in Anspruch. Die DevOps-Abteilung der FI-SP berät in diesen Themen, neben den eigenen Projekten auch Kundenprojekte im Bankenumfeld.

Aufbau einer CI/CD-Pipeline

Für die Bereitstellung und Verteilung der entwickelten Software stellt die Abteilung zentral ein CI/CD-System (Continous Integration / Continous Delivery) auf Basis von Gitlab zur Verfügung. CI/CD-Anweisungen werden von den Entwicklern innerhalb ihres Projektes als Infrastructure as Code beschrieben. Die so entstandenen Infrastrukturkombinationen werden mit dem Projektsource-Code versioniert. Daraus kann das Projekt dann automatisch gebaut und auf die konfigurierten Umgebungen verteilt werden. Ressourcen werden dabei dynamisch vom Cluster verwaltet. Das heißt: In Release-Phasen eines Projektes bekommt es automatisch mehr Ressourcen zugewiesen. Auf diese Weise wird sichergestellt, dass die Build-Phasen möglichst kurz sind.

Der Vorteil dieses Systems ist auch die klare Trennung zwischen DevOps und den Projekt-Teams. Während DevOps die Infrastruktur und Ressourcen kontrolliert, können die Projekte ihre Software frei konfigurieren.

Fazit

Bei der Modernisierung unternehmenskritischer Software bietet die Containerisierung viele Vorteile. Rüstzeiten verringern sich, Deployment-Raten steigen und Fehler werden vermieden. Letztendlich führt dies zu einem schnelleren Time-To-Market. Darüber hinaus ist in der Produktion eine lastabhängige, horizontale Skalierung der Systeme möglich. Daraus folgen eine deutlich verbesserte Gesamtverfügbarkeit der Systeme und eine optimierte Ressourcennutzung.Manuel Kirchner, FI-SP

Sie finden diesen Artikel im Internet auf der Website:
https://itfm.link/99800