© Ink Drop/Shutterstock.com
Spring Boot 2.3

Der zehnte Geburtstag


Mit Spring Boot 2.3 erschien im Mai 2020 die nunmehr zehnte große Spring-Boot-Version, rund sechs Jahre nach Version 1.0. Ich habe das Projekt in diesem Zeitraum sowohl als Bug-Reporter als auch als Contributor, Benutzer und Autor begleitet.

In dieser Zeit hat mich eine Sache immer wieder begeistert: Das Spring-Boot-Team hatte immer ein offenes Ohr für Trends und Bedürfnisse der Benutzerinnen. Oftmals wurde abgewartet und abgewogen, bis eine optimierte Lösung angeboten werden konnte. Für Spring Boot 2.3 ist das in meinen Augen eine erhebliche Verbesserung im Build-Prozess. War das von Spring Boot 2014 favorisierte Fat-Jar-Modell damals im Vergleich zu hochkomplexen WAR und EAR Deployments ein erstrebenswertes Ziel, so hat sich die Welt inzwischen weitergedreht. Spring Boot 2.3 trägt dieser Tatsache Rechnung und startet mit Buildpack-Support und Layered Jars in eine neue Ära.

Bereits in meinem Leitartikel zu Spring Boot 2.2 auf JAXenter im vergangenen Jahr [1] habe ich die neuen Herausforderer im Microservices-Umfeld erwähnt: Micronaut und Quarkus. Diese Frameworks und die Art und Weise, wie mit ihnen extrem schnell startende Services gebaut, nativ kompiliert und komfortabel in Docker Images paketiert werden können, haben Spring Boot 2.3 und das Spring Framework im vergangenen Jahr maßgeblich beeinflusst. Auf die native Kompilierung von Spring-basierten Anwendungen werde ich am Ende des Artikels eingehen. Quarkus hat seit Version 1 ein Dockerfile – sowohl für JVM als auch für Native Images – mitgeliefert. Das Ziel-Deployement war schnell erkennbar. Spring Boot zieht nun nach.

Optimierte Docker Images

Prominentestes 2.3-Feature ist wohl eine Erweiterung der Spring-Boot-Maven- und Gradle-Plug-ins: Beide können jetzt auf Basis von Cloud Native Buildpacks [2] Docker Images erzeugen. Buildpacks sind ein Konzept, das ursprünglich von Heroku [3] stammt. Heroku ist eine „Cloud Plattform as a Service“, die seit jeher unterschiedlichste Programmiersprachen und Plattformen unterstützt und großen Bedarf hat, Anwendungen mit optimierten Images möglichst schnell und optimal zu starten. Buildpacks sollen die operative Last von Entwicklern nehmen und gleichzeitig Compliance- und Securityrichtlinien sicherstellen.

Für Spring Boot 2.3 können Buildpacks – eine Docker Installation vorausgesetzt – mit ./mvnw spring-boot:build-image genutzt werden. Es entsteht ein auf Ubuntu 18 LTS basierendes Image inklusive korrekter Java-Heap-Settings (für einen Betrieb im Container), dem JVMKill Agent (der die VM nach einem OutOfMemoryError beendet) und einiger Dinge mehr. Der Agent läuft außerhalb der JVM und verhindert, dass die JVM in einem undefinierten Zustand nach OutOfMemoryError weiterläuft.

Kodifizierung von Best Practices

Es gibt gute Gründe, keine Buildpacks zu benutzen (zum Beispiel aufgrund des bestehenden Toolings oder dem Wunsch, eigene Base Images zu nutzen). Dabei existiert mit dem Default-Deployment von Spring-Boot-Anwendungen, dem „Fat Jar“-Model, jedoch ein Problem: Die gesamte Anwendung, alle Libraries und Ressourcen liegen als ein Artefakt vor. Was in einem Szenario von Vorteil ist, ist ein riesiger Nachteil, wenn dieses Artefakt in einem Container-Image weiterverteilt und nicht per java -jar auf einem beliebigen Server gestartet wird.

Spring Boots Fat Jars sind eine komfortable Art, komplette Anwendungen inklusive aller Abhängigkeiten und der Runtime zu paketieren, aber gerade in Szenarien, in denen Services wegen kleiner Änderungen neu verteilt werden, nicht optimal: Es muss jedes Mal ein großes Jar mitsamt allen nicht geänderten Abhängigkeiten neu verteilt werden und dementsprechend ein neuer, großer Layer im Container-Build.

So wie Spring Boot seit über fünf Jahren versucht, Spring Best Practices mit Startern und automatischer Konfiguration zu kodifizieren, so geht es diesen Weg nun auch bezüglich Docker Images, um das oben beschriebene Problem der Fat Jars zu lösen. Spring Boot nutzt dazu ein neues Fat-Jar-Layout sowie einen eigenen Boot Loader, dessen Optionen ich bereits 2018 im...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang