Déployez Java sur Nodion

Déployez Java étape par étape

1. Commitez le wrapper Maven ou Gradle Avec gradlew, Nodion exécute ./gradlew build -x test --no-daemon ; avec mvnw, il exécute ./mvnw -B -DskipTests clean package. Un pom.xml sans wrapper est compilé avec le Maven de Nodion. Un projet Gradle sans gradlew échoue : créez le wrapper avec gradle wrapper et commitez-le avec le dossier gradle/wrapper. Les tests sont ignorés pendant le déploiement ; exécutez-les dans votre CI.
2. Fixez la version de Java Sans version fixée, Nodion compile et exécute avec Java 21. Indiquez une autre version dans system.properties. Les réglages de toolchain de pom.xml ou de votre build Gradle ne sont pas lus : gardez-les alignés sur ce fichier. system.properties

   java.runtime.version=25

3. Écoutez sur PORT Nodion définit la variable PORT pour le processus web et la transmet à la JVM sous la forme -Dserver.port, ce qui suffit pour Spring Boot. Les autres frameworks, ou votre propre serveur, lisent PORT eux-mêmes et écoutent sur 0.0.0.0.

   int port = Integer.parseInt(System.getenv().getOrDefault("PORT", "8080"));

4. Créez l'app Dans le dashboard, créez une application depuis votre dépôt GitHub, GitLab, Bitbucket ou Gitea, puis choisissez la branche, la région EU Central et une taille avec au moins 1 Go de mémoire. Laissez la stratégie de build sur Buildpacks ; si le dépôt contient un Dockerfile, le formulaire choisit Dockerfile à la place.
5. Connectez une base de données et lancez les migrations Rattachez une base de données PostgreSQL de la même région dans l'onglet Environment. DATABASE_URL est une URL postgres://, pas une URL JDBC : injectez donc aussi host, port, database, user et password sous vos propres noms et construisez l'URL JDBC à partir de ces variables, comme le montre le guide Spring Boot. Les migrations qui s'exécutent au démarrage (Flyway, Liquibase) ne demandent rien de plus ; toute autre commande peut s'exécuter depuis une ligne release: d'un Procfile, une fois par build, avant le démarrage de la nouvelle version.

Bon à savoir

• MémoirePar défaut, la JVM reçoit JAVA_TOOL_OPTIONS=-XX:MaxRAMPercentage=80.0 : le tas peut donc occuper la majeure partie de la mémoire de l'instance. Définissez vous-même JAVA_TOOL_OPTIONS pour remplacer cette valeur, ou JAVA_OPTS pour ajouter des options à la commande de démarrage. La plupart des apps web JVM ont besoin de 1 Go ou plus.
• Quel jar est lancéNodion lance le jar le plus volumineux situé directement dans target/ ou build/libs/ et ignore les jars -plain, -sources et -javadoc. Dans un build multi-module, le jar exécutable se trouve dans le dossier d'un module : lancez-le avec une ligne web: dans un Procfile et passez le port vous-même.
• Quarkus et autres frameworks-Dserver.port ne configure que Spring Boot. Quarkus, Micronaut et les autres ont besoin de leur propre réglage de port, à partir de PORT. Le fast-jar par défaut de Quarkus dans target/quarkus-app/ n'est pas détecté : lancez-le avec une ligne de Procfile comme web: java -Dquarkus.http.port=$PORT -jar target/quarkus-app/quarkus-run.jar, ou construisez un uber-jar.

Ce que Nodion gère pour vous

• Déploiements sans interruption Faites un push sur votre branche : Nodion construit une nouvelle release. Le trafic bascule lorsque les nouvelles instances réussissent leur health check ; si la release échoue, celle en cours reste active. Les apps avec un volume local redémarrent, car le disque appartient à une seule instance.
• Bases de données à côté de l'app PostgreSQL, pgvector, MySQL, Valkey et ClickHouse managés, dans la même région. Les bases de données rattachées arrivent sous forme de DATABASE_URL, REDIS_URL ou CLICKHOUSE_URL.
• Previews par pull request Activez les previews, et les pull requests de votre dépôt obtiennent leur propre app, avec sa propre URL et des bases de données neuves et vides, créées automatiquement ou à la main. Les pull requests issues de forks ou de bots sont ignorées.
• Workers, cron jobs et mise à l'échelle Exécutez les workers comme processus supplémentaires de la même app, planifiez des tâches dans l'onglet Cron et mettez chaque processus à l'échelle jusqu'à 16 instances.
• Étape de release Avec les buildpacks, une ligne release: du Procfile s'exécute à chaque nouveau build. Les apps Dockerfile, ainsi que les redéploiements ou les rollbacks vers une image antérieure, utilisent une commande de release définie sur l'app elle-même, qui prime aussi sur la ligne du Procfile. Sur les sites statiques, l'étape de release s'exécute dans une image qui ne contient que les fichiers générés par le build.
• Logs et métriques Logs de build, de release et d'exécution, ainsi que les métriques CPU, mémoire, disque et réseau de chaque instance, dans le dashboard.
• Domaines et HTTPS Un nom d'hôte par défaut avec HTTPS dès le premier déploiement, et des certificats automatiques pour vos propres domaines.

Pour aller plus loin

• Dockerfile vs buildpacks : lequel choisir ? Les deux transforment votre code en image de conteneur. La différence, c'est qui écrit les étapes du build, et cela détermine le contrôle, la maintenance et les mises à jour de sécurité.
• Les Cloud Native Buildpacks expliqués Les buildpacks transforment votre code source en image de conteneur sans Dockerfile. Ce qu'ils sont et comment ils fonctionnent.

Java sur Nodion : questions et réponses