Java 17 Migration in der Google Cloud App Engine: Unsere Lessons Learned
Seit Ende Oktober hat Java 11 sein „End of Support“ in der Google Cloud erreicht. Zwar können bestehende Applikationen weiterhin betrieben werden, doch für neue Deployments ist Java 17 nun Pflicht. In diesem Beitrag berichten wir von unserer Migration einer bestehenden Kundenapplikation auf Java 17 in der GCP App Engine und teilen dabei unsere Erfahrungen, Herausforderungen und Lösungen.
Von Java 11 zu Java 17 in der App Engine: Der einfache Fall
Im einfachsten Szenario genügt es, die app.yaml zu aktualisieren und die Anwendung neu in die Cloud zu deployen. Die app.yaml-Datei ist eine Konfigurationsdatei, die der GCP App Engine mitteilt, wie eine Anwendung eingerichtet und ausgeführt werden soll. Neben zahlreichen Konfigurationsoptionen, wie Skalierungsstrategien, ist für uns die Laufzeitumgebung relevant.
Für die Migration musste lediglich der Wert für „runtime“ in der Datei aktualisiert werden, von:
runtime: java11
instance_class: B4
env_variables:
...hin zu:
runtime: java17
instance_class: B4
env_variables:
...Ein anschließender Aufruf des Gradle-Tasks appengineDeploy, und fertig! Wäre da nicht der Rest der Applikation, der auch Java 17-kompatibel sein muss – was in unserem Fall leider nicht gegeben war.
Stolpersteine in die Cloud
Abhängigkeiten aktualisieren: Ein Muss
Im Idealfall hält man Abhängigkeiten konstant aktuell. Das erleichtert spätere Updates, da diese in kleineren Schritten erfolgen können, und erhöht zugleich die Sicherheit der Anwendung. In der Praxis jedoch stehen dem oft zeitliche, finanzielle und organisatorische Hürden im Weg.
Für unsere Migration war ein Update der Abhängigkeiten unumgänglich. Insbesondere mussten wir Spring Boot auf Version 2.7.18 aktualisieren. Dies hatte auch Auswirkungen auf die verwendeten Spring Cloud GCP Starter, die in ein neues Repository verschoben wurden.
Die relevanten Spring Cloud GCP Starter sind von org.springframework nach com.google ausgelagert worden. Die Version 2021.0.9 dieser Starter ist kompatibel mit Spring Boot 2.7.x. Neben dem Update des Repositories und der Versionen mussten wir sicherstellen, dass die Konfiguration in den application.properties korrekt war, insbesondere hinsichtlich der spring.datasource.driver-class-names. Des Weiteren waren im Zuge dessen kleinere Anpassungen im Code, an Imports und an den Tests notwendig, auf die ich hier aber nicht näher eingehen will.
Ungeahnte Probleme mit dem Build-Prozess
Ein weiteres Problem trat nach der Aktualisierung auf: Der Build-Prozess erzeugte ein zusätzliches JAR-File, ein sogenanntes *plain.jar. Dieses wurde beim Deployment in die Google Cloud mit hochgeladen und verhinderte den Start der Anwendung in der App Engine.
Dieses Verhalten, das ab Spring Boot Version 2.5 auftritt, lässt sich durch folgende Änderung in der build.gradle unterdrücken:
jar {
archiveClassifier = ''
enabled = false
}Nach diesen Anpassungen lief die Anwendung endlich wieder in der Google App Engine.
Läuft endlich! Fazit und Ausblick
Die Migration einer bestehenden Anwendung auf Java 17 in der Google Cloud App Engine ist mehr als nur eine Runtime-Anpassung. Besonders ältere oder vernachlässigte Abhängigkeiten und Frameworks können unerwartete Hürden darstellen. Dennoch zahlt sich der Aufwand aus: Mit der Aktualisierung profitieren Anwendungen nicht nur von der aktuellen Java-Version, sondern auch von erhöhter Sicherheit, Performance und langfristiger Wartbarkeit.
Links
- Java 11 End of Support in Appengine: https://cloud.google.com/appengine/docs/standard/java-gen2/release-notes
- Spring Cloud Repository Change: https://spring.io/projects/spring-cloud-gcp
- Spring Framework on Google Cloud: https://googlecloudplatform.github.io/spring-cloud-gcp/3.8.9/reference/html/index.html
- Spring Packaging Executable and Plain Archives: Spring Boot Gradle Plugin – Packaging Executable and Plain Archives
