Spring Boot deployen: warum ein Dockerfile die richtige Antwort ist, kein Workaround

Rails hat eine Webserver-Konvention, Django hat gunicorn, Laravel hat Octane oder PHP-FPM — jedes Ökosystem hat sich auf eine kleine, erratbare Menge an Wegen geeinigt, einen Webprozess tatsächlich zu starten. Die JVM-Welt hat das nie auf dieselbe Weise getan: Eine Spring-Boot-App kann ein einfaches Jar sein, ein WAR in Tomcat, gebaut mit Maven oder Gradle, gestartet mit einem halben Dutzend plausibler Befehlsformen je nach Projektaufbau. Die falsche davon zu raten, scheitert nicht laut — es scheitert auf eine Art, die wie das Problem der App aussieht statt wie das der Erkennung.

Warum Dockerfile-first hier die ehrliche Wahl ist

Statt vorzugeben, einen JVM-Build- und -Run-Befehl automatisch zu erkennen, der über Projekte hinweg tatsächlich mehrdeutig ist, ist ein Repo mit eigenem Dockerfile die tatsächliche erste Wahl der Build-Methode bei Railyard — geprüft vor Railpack, vor Nixpacks, vor allem anderen. Speziell für Spring Boot ist das kein fehlendes Feature, das man umgehen muss; es ist das richtige Werkzeug für eine Build-Form mit zu vielen gültigen Antworten, um sicher zu raten. Ein Dockerfile sagt genau, welche JDK-Version, welches Build-Tool und welchen finalen Run-Befehl die App braucht — Information, die kein Scanner von pom.xml oder build.gradle allein verlässlich ableiten kann.

FROM eclipse-temurin:21-jre
COPY target/my-app.jar app.jar
ENV SERVER_PORT=$PORT
CMD ["java", "-jar", "app.jar"]

Die eine echte Anforderung: Die App muss $PORT binden (Spring Boot liest das aus SERVER_PORT oder server.port), derselbe Vertrag, den jede Build-Methode auf der Plattform erwartet.

Was weiterhin genauso funktioniert wie bei jeder anderen App

• Konfiguration und Secrets: Alles, was über @Value oder application.propertiess ${VAR}-Syntax gelesen wird, ist eine normale Umgebungsvariable unter Variables, oder gesetzt mit railyard env:set my-app KEY=VALUE — nie ins Image eingebacken, sodass derselbe Build unverändert von Staging bis Produktion läuft.
• Datenbanken: Richte die App über das Canvas auf ein Postgres- oder MySQL-Add-on aus und verdrahte dessen Connection-String als Variable in application.properties — das Add-on selbst wird unabhängig von der Sprache auf die gleiche Weise provisioniert.
• Deployment bei Push: Sobald das Dockerfile lokal baut, baut und deployt git push (oder railyard create my-app https://github.com/me/my-app) bei jedem Push neu, wie bei jedem anderen Repo.

Der tatsächliche Trade-off, klar ausgesprochen

Das bedeutet etwas mehr Vorarbeit, als ein Rails- oder Django-Repo kostenlos bekommt — das Dockerfile einmal schreiben, statt dass es abgeleitet wird. Im Gegenzug verhält sich der Build genau so, wie das Dockerfile es sagt, jedes Mal, was für einen JVM-Build mehr wert ist als eine Bequemlichkeit, die bei einem echten Prozentsatz an Projekten falsch geraten hätte.

Vollständige Referenz: Build-Methoden, Ein Docker-Image deployen.