Fai il deploy di Spring Boot su Nodion

Deploy di Spring Boot passo dopo passo

1. Mantieni il wrapper e fissa la versione di Java I progetti creati con Spring Initializr includono già mvnw o gradlew. Nodion esegue ./mvnw -B -DskipTests clean package o ./gradlew build -x test --no-daemon e avvia il jar più grande in target/ o build/libs/, saltando il jar -plain di Gradle. Gradle senza wrapper fallisce; Maven senza wrapper viene compilato con il Maven di Nodion. La versione di Java arriva da system.properties (predefinita 21), non dalla toolchain del tuo file di build. system.properties

   java.runtime.version=21

2. Aggiungi Actuator per l'health check Il traffico passa alla nuova versione solo quando il percorso dell'health check risponde con 2xx o 3xx, e in molte app Spring Boot il percorso predefinito / restituisce 404. Aggiungi Actuator (in Gradle: implementation 'org.springframework.boot:spring-boot-starter-actuator') e imposta /actuator/health come percorso dell'health check nelle impostazioni dell'app. pom.xml

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

3. Fai puntare il datasource alle tue variabili Spring Boot si aspetta un URL JDBC e non legge DATABASE_URL, che è un URL postgres://. In application.properties fai riferimento a variabili tue e aggiungi il driver PostgreSQL org.postgresql:postgresql come dipendenza di runtime. Nodion valorizza le variabili quando colleghi il database nel passo successivo. application.properties

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

4. Crea l'app e collega PostgreSQL Crea un'applicazione dal tuo repository nella regione EU Central con almeno 1 GB di memoria, poi un database PostgreSQL nella stessa regione. Quando lo colleghi nella scheda Environment, fai inserire automaticamente host, port, database, user e password come DB_HOST, DB_PORT, DB_NAME, DB_USER e DB_PASSWORD. Le variabili arrivano con il deploy successivo.
5. Push e deploy Ogni push sul branch crea una nuova release. Le migrazioni Flyway o Liquibase girano all'avvio della nuova versione, prima che superi l'health check; fino ad allora la versione in esecuzione continua a rispondere, quindi mantieni le migrazioni compatibili con il codice vecchio.

Da sapere

• MemoriaPrevedi 1 GB o più per istanza. Di default la JVM riceve JAVA_TOOL_OPTIONS=-XX:MaxRAMPercentage=80.0, quindi l'heap può usare gran parte della memoria dell'istanza. Imposta JAVA_TOOL_OPTIONS per sostituirlo, oppure JAVA_OPTS per aggiungere flag al comando di avvio.
• Spring SecuritySe definisci una tua security filter chain, consenti l'accesso a /actuator/health senza login. Con un 401 o 403 sul percorso dell'health check la release non diventa mai pronta e dopo 10 minuti viene interrotta, mentre la versione vecchia continua a rispondere.
• Progetti multi-moduloNodion cerca i jar solo direttamente in target/ e build/libs/ della base directory. Se il jar di Boot viene generato nella cartella di un modulo, avvialo con una riga del Procfile e passa tu la porta, per esempio web: java -Dserver.port=$PORT -jar app/build/libs/app.jar.

Cosa gestisce Nodion per te

• Deploy senza downtime Fai push sul tuo branch e Nodion crea una nuova release. Il traffico passa alle nuove istanze solo quando superano l'health check; una release fallita lascia attiva quella in esecuzione. Le app con un volume locale invece si riavviano, perché il disco appartiene a una sola istanza.
• Database accanto all'app PostgreSQL, pgvector, MySQL, Valkey e ClickHouse gestiti, nella stessa regione. I database collegati arrivano come DATABASE_URL, REDIS_URL o CLICKHOUSE_URL.
• Anteprime per ogni pull request Attiva le anteprime: ogni pull request del tuo repository riceve un'app dedicata, con un proprio URL e database nuovi e vuoti, creata automaticamente o manualmente. Le pull request dai fork e quelle dei bot vengono ignorate.
• Worker, cron job e scalabilità Esegui i worker come processi aggiuntivi della stessa app, pianifica i job nella scheda Cron e scala ogni processo fino a 16 istanze.
• Fase di release Con i buildpack, la riga release: del Procfile viene eseguita a ogni nuova build. Le app con Dockerfile, così come i redeploy e i rollback a un'immagine precedente, usano un comando di release impostato sull'app stessa, che ha anche la precedenza sulla riga del Procfile. Nei siti statici, la fase di release gira in un'immagine che contiene solo i file generati dalla build.
• Log e metriche Nella dashboard trovi log di build, release e runtime, oltre alle metriche di CPU, memoria, disco e rete per ogni istanza.
• Domini e HTTPS Un hostname predefinito con HTTPS dal primo deploy; i tuoi domini ricevono i certificati in automatico.

Per approfondire

• Alternative a Heroku con hosting UE: 5 opzioni a confronto Una piattaforma tedesca e cloud statunitensi con regioni nell'UE, a confronto per sede, regioni e database gestiti.
• Dockerfile vs buildpack: quale dovresti usare? Entrambi trasformano il tuo codice in un'immagine container. Cambia chi scrive i passaggi della build, e questo determina controllo, manutenzione e aggiornamenti di sicurezza.

Spring Boot su Nodion: domande e risposte