Faça deploy de Java na Nodion

Faça deploy de Java passo a passo

1. Faça commit do wrapper Maven ou Gradle Com gradlew, a Nodion executa ./gradlew build -x test --no-daemon; com mvnw, executa ./mvnw -B -DskipTests clean package. Um pom.xml sem wrapper é compilado com o Maven da própria Nodion. Um projeto Gradle sem gradlew falha, por isso crie o wrapper com gradle wrapper e faça commit do wrapper juntamente com a pasta gradle/wrapper. Os testes são ignorados durante o deploy; execute-os na sua CI.
2. Fixe a versão do Java Sem uma versão fixada, a Nodion faz o build e executa com o Java 21. Indique outra versão em system.properties. As definições de toolchain em pom.xml ou no seu build Gradle não são lidas, por isso mantenha-as alinhadas com este ficheiro. system.properties

   java.runtime.version=25

3. Escute em PORT A Nodion define a variável PORT para o processo web e passa-a à JVM como -Dserver.port, o que basta para o Spring Boot. Outros frameworks, ou o seu próprio servidor, leem PORT por si e escutam em 0.0.0.0.

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

4. Crie a aplicação No dashboard, crie uma aplicação a partir do seu repositório GitHub, GitLab, Bitbucket ou Gitea e escolha o branch, a região EU Central e um tamanho com pelo menos 1 GB de memória. Mantenha a estratégia de build em Buildpacks; se o repositório tiver um Dockerfile, o formulário escolhe Dockerfile em vez disso.
5. Associe uma base de dados e execute as migrações No separador Environment, associe uma base de dados PostgreSQL da mesma região. DATABASE_URL é um URL postgres://, não um URL JDBC, por isso injete também host, port, database, user e password com nomes à sua escolha e construa a partir deles o URL JDBC, como mostra o guia do Spring Boot. As migrações que correm no arranque (Flyway, Liquibase) não precisam de mais nada; qualquer outro comando pode ser executado a partir de uma linha release: num Procfile, uma vez por build, antes de a nova versão arrancar.

A ter em conta

• MemóriaPor omissão, a JVM recebe JAVA_TOOL_OPTIONS=-XX:MaxRAMPercentage=80.0, por isso a heap pode usar a maior parte da memória da instância. Defina JAVA_TOOL_OPTIONS manualmente para substituir este valor, ou JAVA_OPTS para acrescentar flags ao comando de arranque. A maioria das aplicações web na JVM precisa de 1 GB ou mais.
• Que jar é iniciado?A Nodion inicia o maior jar que esteja diretamente em target/ ou build/libs/ e ignora os jars -plain, -sources e -javadoc. Num build multimódulo, o jar executável fica na pasta de um módulo; inicie-o com uma linha web: num Procfile e passe a porta manualmente.
• Quarkus e outros frameworks-Dserver.port só configura o Spring Boot. O Quarkus, o Micronaut e outros precisam da sua própria definição de porta a partir de PORT. O fast-jar predefinido do Quarkus em target/quarkus-app/ não é detetado: inicie-o com uma linha do Procfile como web: java -Dquarkus.http.port=$PORT -jar target/quarkus-app/quarkus-run.jar, ou faça o build de um uber-jar.

O que a Nodion gere por si

• Deploys sem downtime Faça push para o seu branch e a Nodion cria uma nova release. O tráfego só muda quando as novas instâncias passam no health check; se uma release falhar, a que está em execução mantém-se. Em vez disso, as aplicações com um volume local são reiniciadas, porque o disco pertence a uma única instância.
• Bases de dados junto à aplicação PostgreSQL, pgvector, MySQL, Valkey e ClickHouse geridos, na mesma região. As bases de dados associadas chegam como DATABASE_URL, REDIS_URL ou CLICKHOUSE_URL.
• Pré-visualizações por pull request Ative as pré-visualizações e cada pull request do seu repositório passa a ter uma aplicação própria, com URL próprio e bases de dados novas e vazias, criada automática ou manualmente. Os forks e os pull requests de bots são ignorados.
• Workers, cron jobs e escalabilidade Execute workers como processos adicionais da mesma aplicação, agende tarefas no separador Cron e escale cada processo até 16 instâncias.
• Etapa de release Com buildpacks, uma linha release: do Procfile é executada a cada novo build. As aplicações com Dockerfile, bem como os redeploys ou rollbacks para uma imagem anterior, usam um comando de release definido na própria aplicação, que também tem prioridade sobre a linha do Procfile. Nos sites estáticos, a etapa de release é executada numa imagem que contém apenas os ficheiros gerados pelo build.
• Logs e métricas Logs de build, release e runtime, além de métricas de CPU, memória, disco e rede de cada instância, no dashboard.
• Domínios e HTTPS Um hostname atribuído por omissão com HTTPS desde o primeiro deploy; os seus próprios domínios recebem certificados automaticamente.

Para saber mais

• Dockerfile vs buildpacks: qual deve escolher? Ambos transformam o seu código numa imagem de contentor. A diferença está em quem escreve os passos do build, e isso determina o controlo, a manutenção e as atualizações de segurança.
• Cloud Native Buildpacks: o que são e como funcionam Os buildpacks transformam o seu código-fonte numa imagem de contentor sem Dockerfile. O que são e como funcionam.

Java na Nodion: perguntas e respostas