Fai il deploy di Java su Nodion

Deploy di Java passo dopo passo

1. Fai il commit del wrapper Maven o Gradle Con gradlew, Nodion esegue ./gradlew build -x test --no-daemon; con mvnw, esegue ./mvnw -B -DskipTests clean package. Un pom.xml senza wrapper viene compilato con il Maven di Nodion. Un progetto Gradle senza gradlew fallisce: crea il wrapper con gradle wrapper e fanne il commit insieme alla cartella gradle/wrapper. Durante il deploy i test vengono saltati; eseguili nella tua CI.
2. Fissa la versione di Java Se non fissi una versione, Nodion compila ed esegue con Java 21. Per un'altra versione, indicala in system.properties. Le impostazioni della toolchain in pom.xml o nella build Gradle non vengono lette, quindi tienile allineate a questo file. system.properties

   java.runtime.version=25

3. Ascolta su PORT Nodion imposta PORT per il processo web e la passa alla JVM come -Dserver.port, e questo basta per Spring Boot. Gli altri framework, o un tuo server, leggono PORT da soli e si mettono in ascolto su 0.0.0.0.

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

4. Crea l'app Nella dashboard crea un'applicazione dal tuo repository GitHub, GitLab, Bitbucket o Gitea, scegli il branch, la regione EU Central e una dimensione con almeno 1 GB di memoria. Lascia la strategia di build su Buildpacks; se il repository contiene un Dockerfile, il modulo seleziona invece Dockerfile.
5. Collega un database ed esegui le migrazioni Nella scheda Environment collega un database PostgreSQL della stessa regione. DATABASE_URL è un URL postgres://, non un URL JDBC: fai inserire automaticamente anche host, port, database, user e password con nomi tuoi e costruisci da questi l'URL JDBC, come mostra la guida per Spring Boot. Le migrazioni eseguite all'avvio (Flyway, Liquibase) non richiedono altro; qualsiasi altro comando può girare da una riga release: in un Procfile, una volta per build, prima che parta la nuova versione.

Da sapere

• MemoriaDi default la JVM riceve JAVA_TOOL_OPTIONS=-XX:MaxRAMPercentage=80.0, quindi l'heap può usare gran parte della memoria dell'istanza. Imposta tu JAVA_TOOL_OPTIONS per sostituirlo, oppure JAVA_OPTS per aggiungere flag al comando di avvio. La maggior parte delle web app JVM richiede 1 GB o più.
• Quale jar viene avviatoNodion avvia il jar più grande che si trova direttamente in target/ o build/libs/ e salta i jar -plain, -sources e -javadoc. In una build multi-modulo il jar eseguibile si trova nella cartella di un modulo; avvialo con una riga web: in un Procfile e passa tu la porta.
• Quarkus e altri framework-Dserver.port configura solo Spring Boot. Quarkus, Micronaut e gli altri hanno bisogno di una propria impostazione della porta, letta da PORT. Il fast-jar predefinito di Quarkus in target/quarkus-app/ non viene rilevato: avvialo con una riga del Procfile come web: java -Dquarkus.http.port=$PORT -jar target/quarkus-app/quarkus-run.jar, oppure crea un uber-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

• 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.
• Cloud Native Buildpacks: cosa sono e come funzionano I buildpack trasformano il tuo codice sorgente in un'immagine container senza Dockerfile. Cosa sono e come funzionano.

Java su Nodion: domande e risposte