Despliega Spring Boot en Nodion

Despliega Spring Boot paso a paso

1. Mantén el wrapper y fija la versión de Java Los proyectos de Spring Initializr ya traen mvnw o gradlew. Nodion ejecuta ./mvnw -B -DskipTests clean package o ./gradlew build -x test --no-daemon y arranca el jar más grande de target/ o build/libs/, omitiendo el jar -plain de Gradle. Gradle sin wrapper falla; Maven sin wrapper se compila con el Maven propio de Nodion. La versión de Java sale de system.properties (por defecto 21), no de la toolchain de tu archivo de build. system.properties

   java.runtime.version=21

2. Añade Actuator para el health check El tráfico solo pasa a la nueva versión cuando la ruta del health check responde con 2xx o 3xx, y en muchas apps Spring Boot la ruta por defecto / devuelve 404. Añade Actuator (en Gradle: implementation 'org.springframework.boot:spring-boot-starter-actuator') y configura /actuator/health como ruta del health check en los ajustes de la app. pom.xml

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

3. Apunta el datasource a tus propias variables Spring Boot espera una URL JDBC y no lee DATABASE_URL, que es una URL postgres://. Haz referencia a tus propias variables en application.properties y añade el driver de PostgreSQL org.postgresql:postgresql como dependencia de runtime. Nodion rellena las variables cuando vinculas la base de datos en el siguiente paso. 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 la app y vincula PostgreSQL Crea una aplicación desde tu repositorio en la región EU Central con al menos 1 GB de memoria y, después, una base de datos PostgreSQL en la misma región. Al vincularla en la pestaña Environment, inyecta host, port, database, user y password como DB_HOST, DB_PORT, DB_NAME, DB_USER y DB_PASSWORD. Llegan con el siguiente despliegue.
5. Haz push para desplegar Cada push a la rama genera una nueva release. Las migraciones de Flyway o Liquibase se ejecutan cuando arranca la nueva versión, antes de que pase el health check; hasta entonces, la versión en marcha sigue atendiendo peticiones, así que mantén las migraciones compatibles con el código antiguo.

A tener en cuenta

• MemoriaPrevé 1 GB o más por instancia. Por defecto, la JVM recibe JAVA_TOOL_OPTIONS=-XX:MaxRAMPercentage=80.0, así que el heap puede usar la mayor parte de la memoria de la instancia. Define JAVA_TOOL_OPTIONS para sustituirlo, o JAVA_OPTS para añadir flags al comando de arranque.
• Spring SecuritySi defines tu propia security filter chain, permite el acceso a /actuator/health sin login. Con un 401 o 403 en la ruta del health check, la release nunca está lista y a los 10 minutos se cancela, mientras la versión anterior sigue atendiendo peticiones.
• Proyectos multimóduloNodion solo busca jars directamente en target/ y build/libs/ del base directory. Si el jar de Boot se genera en la carpeta de un módulo, arráncalo con una línea del Procfile y pasa tú el puerto, por ejemplo web: java -Dserver.port=$PORT -jar app/build/libs/app.jar.

Lo que Nodion gestiona por ti

• Despliegues sin downtime Haz push a tu rama y Nodion construye una nueva release. El tráfico pasa a las nuevas instancias cuando superan el health check; si una release falla, la que está en marcha sigue activa. En cambio, las apps con un volumen local se reinician porque el disco pertenece a una sola instancia.
• Bases de datos junto a la app PostgreSQL, pgvector, MySQL, Valkey y ClickHouse gestionados en la misma región. Al vincular una base de datos, sus datos de conexión llegan como DATABASE_URL, REDIS_URL o CLICKHOUSE_URL.
• Previews por pull request Activa las previews: cada pull request de tu repositorio tendrá su propia app, con URL y bases de datos nuevas y vacías. Puedes crearla automáticamente o a mano. Se omiten las pull requests de forks y bots.
• Workers, cron jobs y escalado Ejecuta workers como procesos adicionales de la misma app, programa tareas en la pestaña Cron y escala cada proceso hasta 16 instancias.
• Paso de release Con buildpacks, una línea release: del Procfile se ejecuta con cada nueva build. Las apps con Dockerfile, así como los redeploys o rollbacks a una imagen anterior, usan un comando de release definido en la propia app, que además tiene prioridad sobre la línea del Procfile. En los sitios estáticos, el paso de release se ejecuta en una imagen que solo contiene los archivos generados por la build.
• Logs y métricas Logs de build, release y runtime, además de métricas de CPU, memoria, disco y red de cada instancia, en el dashboard.
• Dominios y HTTPS Un nombre de host predeterminado con HTTPS desde el primer despliegue; tus propios dominios reciben certificados automáticamente.

Para seguir leyendo

• Alternativas a Heroku con hosting en la UE: 5 opciones Una plataforma alemana y clouds estadounidenses con regiones en la UE, comparados por sede, regiones y bases de datos gestionadas.
• Dockerfile vs buildpacks: ¿cuál deberías usar? Los dos convierten tu código en una imagen de contenedor. Lo que cambia es quién escribe los pasos de la build, y eso decide el control, el mantenimiento y las actualizaciones de seguridad.

Spring Boot en Nodion: preguntas y respuestas