Déployez Spring Boot sur Nodion

Déployez Spring Boot étape par étape

1. Gardez le wrapper et fixez la version de Java Les projets Spring Initializr sont livrés avec mvnw ou gradlew. Nodion exécute ./mvnw -B -DskipTests clean package ou ./gradlew build -x test --no-daemon et lance le jar le plus volumineux de target/ ou build/libs/, en ignorant le jar -plain de Gradle. Gradle sans wrapper échoue ; Maven sans wrapper est compilé avec le Maven de Nodion. La version de Java vient de system.properties (21 par défaut), pas de la chaîne d'outils de votre fichier de build. system.properties

   java.runtime.version=21

2. Ajoutez Actuator pour le health check Le trafic ne bascule que lorsque le chemin du health check renvoie un code 2xx ou 3xx, et dans beaucoup d'apps Spring Boot le chemin par défaut / renvoie 404. Ajoutez Actuator (avec Gradle : implementation 'org.springframework.boot:spring-boot-starter-actuator') et définissez /actuator/health comme chemin du health check dans les paramètres de l'app. pom.xml

   <dependency>
     <groupId>org.springframework.boot</groupId>
     <artifactId>spring-boot-starter-actuator</artifactId>
   </dependency>

3. Faites pointer la datasource vers vos propres variables Spring Boot attend une URL JDBC et ne lit pas DATABASE_URL, qui est une URL postgres://. Référencez vos propres variables dans application.properties et ajoutez le pilote PostgreSQL org.postgresql:postgresql comme dépendance de runtime. Nodion renseigne ces variables quand vous rattachez la base de données à l'étape suivante. application.properties

   spring.datasource.url=jdbc:postgresql://${DB_HOST}:${DB_PORT}/${DB_NAME}
   spring.datasource.username=${DB_USER}
   spring.datasource.password=${DB_PASSWORD}

4. Créez l'app et rattachez PostgreSQL Créez une application depuis votre dépôt dans la région EU Central avec au moins 1 Go de mémoire, puis une base de données PostgreSQL dans la même région. En la rattachant dans l'onglet Environment, injectez host, port, database, user et password sous les noms DB_HOST, DB_PORT, DB_NAME, DB_USER et DB_PASSWORD. Ces variables arrivent au prochain déploiement.
5. Poussez pour déployer Chaque push sur la branche construit une nouvelle release. Les migrations Flyway ou Liquibase s'exécutent au démarrage de la nouvelle version, avant qu'elle ne passe le health check ; jusque-là, la version en cours continue de répondre. Gardez donc vos migrations compatibles avec l'ancien code.

Bon à savoir

• MémoirePrévoyez 1 Go ou plus par instance. Par 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 JAVA_TOOL_OPTIONS pour remplacer cette valeur, ou JAVA_OPTS pour ajouter des options à la commande de démarrage.
• Spring SecuritySi vous définissez votre propre security filter chain, autorisez /actuator/health sans authentification. Avec un 401 ou un 403 sur le chemin du health check, la release n'est jamais prête et elle est abandonnée au bout de 10 minutes, pendant que l'ancienne version continue de répondre.
• Projets multi-modulesNodion ne cherche les jars que directement dans target/ et build/libs/ du répertoire indiqué dans le champ Base directory. Si le jar Boot est généré dans le dossier d'un module, lancez-le avec une ligne de Procfile et passez le port vous-même, par exemple web: java -Dserver.port=$PORT -jar app/build/libs/app.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

• Alternatives à Heroku avec hébergement dans l'UE : 5 options Une plateforme allemande et des clouds américains avec des régions dans l'UE, comparés par siège, régions et bases de données managées.
• 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é.

Spring Boot sur Nodion : questions et réponses