Faça deploy de Spring Boot na Nodion

Faça deploy de Spring Boot passo a passo

1. Mantenha o wrapper e fixe a versão do Java Os projetos do Spring Initializr já trazem mvnw ou gradlew. A Nodion executa ./mvnw -B -DskipTests clean package ou ./gradlew build -x test --no-daemon e inicia o maior jar em target/ ou build/libs/, ignorando o jar -plain do Gradle. O Gradle sem wrapper falha; um projeto Maven sem wrapper é compilado com o Maven da própria Nodion. A versão do Java vem de system.properties (21 por omissão), não da toolchain do seu ficheiro de build. system.properties

   java.runtime.version=21

2. Adicione o Actuator para o health check O tráfego só muda para a nova versão quando o caminho do health check responde com 2xx ou 3xx, e em muitas aplicações Spring Boot o caminho predefinido / devolve 404. Adicione o Actuator (no Gradle: implementation 'org.springframework.boot:spring-boot-starter-actuator') e defina /actuator/health como caminho do health check nas definições da aplicação. pom.xml

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

3. Configure a ligação à base de dados com as suas variáveis O Spring Boot espera um URL JDBC e não lê DATABASE_URL, que é um URL postgres://. Faça referência às suas próprias variáveis em application.properties e adicione o driver PostgreSQL org.postgresql:postgresql como dependência de runtime. A Nodion preenche as variáveis quando associar a base de dados no passo seguinte. application.properties

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

4. Crie a aplicação e associe o PostgreSQL Crie uma aplicação a partir do seu repositório na região EU Central com pelo menos 1 GB de memória e, depois, uma base de dados PostgreSQL na mesma região. Ao associá-la no separador Environment, injete host, port, database, user e password como DB_HOST, DB_PORT, DB_NAME, DB_USER e DB_PASSWORD. As variáveis chegam no próximo deploy.
5. Deploy a cada push Cada push para o branch faz o build de uma nova release. As migrações Flyway ou Liquibase são executadas quando a nova versão arranca, antes de passar o health check; até lá, a versão em execução continua a responder, por isso mantenha as migrações compatíveis com o código antigo.

A ter em conta

• MemóriaConte com 1 GB ou mais por instância. Por 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 para substituir este valor, ou JAVA_OPTS para acrescentar flags ao comando de arranque.
• Spring SecuritySe definir a sua própria security filter chain, permita o acesso a /actuator/health sem início de sessão. Com um 401 ou 403 no caminho do health check, a release nunca fica pronta e, ao fim de 10 minutos, é cancelada, enquanto a versão antiga continua a responder.
• Projetos multimóduloA Nodion só procura jars diretamente em target/ e build/libs/ do Base directory. Se o jar do Boot for gerado na pasta de um módulo, inicie-o com uma linha do Procfile e passe a porta manualmente, por exemplo web: java -Dserver.port=$PORT -jar app/build/libs/app.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

• Alternativas ao Heroku com alojamento na UE: 5 opções Uma plataforma alemã e clouds norte-americanas com regiões na UE, comparadas por sede, regiões e bases de dados geridas.
• 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.

Spring Boot na Nodion: perguntas e respostas