top of page

Despliegue continuo en Render de una aplicación Spring Boot

Actualizado: 24 sept 2023

En este artículo voy a explicar cómo configurar el despliegue continuo en Render basado en imágenes Docker de una aplicación Spring Boot.


Herramientas y tecnologías usadas en este ejemplo:


Puedes encontrar el código de esta guía en mi repositorio de GitHub.


Crear un repositorio GitHub donde subir el código


Empecemos por lo básico. Creamos un repositorio de GitHub donde subir el código de la aplicación.


Generamos una aplicación Spring Boot en spring initializr con la siguiente configuración. Lo descargamos y lo subimos al repositorio de GitHub.


Containerización


Tenemos que containerizar nuestra aplicación para que Render pueda ejecutarla como un contenedor de Docker. Para conseguirlo, necesitamos añadir un fichero Dockerfile apropiado para nuestra aplicación Spring Boot en el directorio raíz del repositorio. El siguiente fichero Dockerfile servirá para alcanzar nuestro objetivo (si estás interesado/a en los detalles de este Dockerfile, puedes consultar la guía oficial de Spring Boot Docker que he seguido).


Publicación de una nueva imagen de Docker cuando ocurra un push a la rama principal


Ahora que ya tenemos nuestro Dockerfile listo, vamos a publicar una imagen de Docker cada vez que ocurra un push a la rama principal de nuestro repositorio. De eso se va a encargar un workflow de GitHub Actions que situaremos en la ruta «.github/workflows/on-push-to-main.yaml».


Subimos este cambio a la rama principal y esto desencadenará un workflow run que publicará una nueva imágen de Docker de la aplicación Spring Boot en el container registry de nuestra cuenta de GitHub con dos etiquetas: «latest» y otra con el commit SHA.


Conectar Render a nuestras imágenes de Docker


Ahora que ya tenemos una URL para nuestras imágenes de Docker, vamos a configurar un servicio web en Render y vamos a conectarlo a «ghcr.io/dgraciac/guide-cd-render-docker-based-spring-boot:latest».


Seleccionamos «Deploy an existing image from a registry».

Render. Deploy an existing image from a registry.
Deploy an existing image from a registry.

En el campo «Image URL» ponemos la URL con la etiqueta «latest»: ghcr.io/dgraciac/guide-cd-render-docker-based-spring-boot:latest.


Si tu repositorio es privado, tu container registry también lo es y tendrás que añadir unas credenciales en tu cuenta de Render para que pueda descargarse las imágenes del container registry.


Render. Set image URL.
Set image URL.

Elegimos nombre del servicio web, región geográfica e «Instance Type».


En la sección «Advanced»,

  • añadimos una variable de entorno «PORT» (reservada por Render) con el valor «8080» para decirle a Render que redirija las peticiones que llegan al servicio web al puerto 8080 del contenedor Docker donde se está ejecutando la aplicación Spring Boot (Spring Boot escucha el puerto 8080 por defecto).

  • en el campo «Health Check Path» añadimos «/actuator/health»

Por último, creamos el servicio web.


Web service's advanced configuration.
Render. Web service's advanced configuration.

Al cabo de unos minutos, el servicio web estará disponible en «https://guide-cd-render-docker-based-spring-boot.onrender.com». Para comprobar que la aplicación Spring Boot es accesible públicamente, pega esta URL en tu navegador: https://guide-cd-render-docker-based-spring-boot.onrender.com/actuator/health. Si todo ha ido bien, deberías ver el siguiente mensaje.

{"status":"UP","groups":["liveness","readiness"]}

Ahora ya podemos deplegar manualmente la versión «latest» de nuestra aplicación Spring Boot desde el dashboard de Render.


Render. Web service panel.
Web service panel.

Pero lo que realmente nos va a facilitar la vida es que nuestro servicio web se despliegue automáticamente cada vez que se publique una nueva imágen Docker de la aplicación. Es decir, despliegue continuo.


Despliegue continuo


Para configurar el despliegue continuo vamos a usar el webhook que nos ofrece Render para desencadenar un nuevo despliegue.


Tenemos que añadir un paso más al final de nuestro workflow de GitHub para que llame al webhook con la URL de la imagen Docker que tiene la etiqueta commit SHA (tiene que ser URL encoded).

Las opciones que se pasan al comando curl sirven para codificar la URL que añadimos al query string y poder obtener el código de respuesta para hacer fallar el workflow en caso de que Render nos conteste con un error.


Solo falta mantener la URL del webhook en secreto para evitar riesgos. Así que creamos un secreto «RENDER_DEPLOY_WEBHOOK» en nuestro repositorio de GitHub (ver documentación oficial).


En mi caso, también añado esto al job del workflow porque he configurado el secreto como un secreto del entorno de producción.




Entradas Recientes

Ver todo

Comments


bottom of page