Déployer Spring Boot : pourquoi un Dockerfile est la bonne réponse, pas une solution de repli

Rails a une convention de serveur web, Django a gunicorn, Laravel a Octane ou PHP-FPM — chaque écosystème a convergé vers un petit ensemble devinable de façons de réellement démarrer un processus web. Le monde JVM n’a jamais fait ça de la même façon : une application Spring Boot peut être un simple jar, un WAR dans Tomcat, construite avec Maven ou Gradle, démarrée avec une demi-douzaine de formes de commandes raisonnables selon l’organisation du projet. Deviner la mauvaise ne échoue pas bruyamment — elle échoue d’une façon qui ressemble à un problème de l’application plutôt qu’à un problème de détection.

Pourquoi privilégier le Dockerfile est le choix honnête ici

Plutôt que de prétendre détecter automatiquement une commande de build et d’exécution JVM qui est réellement ambiguë selon les projets, un dépôt avec son propre Dockerfile est la vraie méthode de build de premier choix sur Railyard — vérifiée avant Railpack, avant Nixpacks, avant tout le reste. Pour Spring Boot en particulier, ce n’est pas une fonctionnalité manquante à contourner; c’est le bon outil pour une forme de build qui a trop de réponses valides pour être devinée en toute sécurité. Un Dockerfile dit exactement quelle version de JDK, quel outil de build, et quelle commande d’exécution finale l’application a besoin — une information qu’aucun scanner de pom.xml ou build.gradle seul ne peut inférer de façon fiable.

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

La seule vraie exigence : l’application doit se lier à $PORT (Spring Boot le lit depuis SERVER_PORT ou server.port), le même contrat que toute méthode de build sur la plateforme attend.

Ce qui fonctionne encore de la même façon que pour n’importe quelle autre application

• Config et secrets : tout ce qui est lu via @Value ou la syntaxe ${VAR} d’application.properties est une variable d’environnement simple sous Variables, ou réglée avec railyard env:set my-app KEY=VALUE — jamais intégrée dans l’image, donc le même build tourne sans changement de staging jusqu’à la production.
• Bases de données : pointez l’application vers un addon Postgres ou MySQL depuis le canvas et câblez sa chaîne de connexion dans application.properties comme une variable — l’addon lui-même est provisionné de la même façon peu importe le langage.
• Déploiement au push : une fois que le Dockerfile compile en local, git push (ou railyard create my-app https://github.com/me/my-app) reconstruit et redéploie à chaque push, comme n’importe quel autre dépôt.

Le vrai compromis, dit clairement

Ça signifie un peu plus de travail en amont qu’un dépôt Rails ou Django obtient gratuitement — écrire le Dockerfile une fois, plutôt qu’il soit inféré. En échange, le build se comporte exactement comme le Dockerfile le dit, chaque fois, ce qui pour un build JVM vaut plus qu’une commodité qui aurait mal deviné sur un vrai pourcentage de projets.

Référence complète : Méthodes de build, Déployer une image Docker.