Deploy de Proyecto de Java en Render

Llega un momento en el cual necesitamos que todo lo que hicimos pueda ser visto (y trabajado) de forma online.

El problema radica en qué hay que encontrar un servicio que permita desplegar (hacer el deploy) de lo que hicimos de la forma en la cual está hecho...

Venimos trabajando con Java y con SpringBoot... Necesitamos algo que responda a esos requerimientos...

Estuvo Heroku en su momento... Estuvo... Seguir existiendo sigue existiendo pero no es gratuito...

Tenemos algunas opciones más pero hoy vamos a centrarnos en Render del cual tenemos mucha información que podemos compartir para todos para ayudar.

Sin dar vueltas. Con los pasos siguientes se puede hacer un deploy en Render sin ningún inconveniente, sin tarjetas de crédito de por medio, sin deudas a futuro, ni nada.

NOTA:

- Para desplegar en Render no hace falta ningĂşn archivo system.properties solo un archivo Dockerfile
- El archivo properties que tiene los datos de conexiĂłn a la Base de Datos (si esta está alojada en Clever Cloud) tiene que tener la lĂ­nea: spring.datasource.hikari.maximum-pool-size=2 sin excepciĂłn que es para limitar las conexiones a 2.

PASOS:

- Crear un archivo Dockerfile buscando crear un archivo de tipo Other (dando click derecho sobre el nombre del Proyecto que tengamos) y escribiendo docker.

-Elegir tipo Dockerfile y darle Siguiente o Next. Se tiene que llamar Dockerfile asĂ­ con mayĂşscula. Adentro de ese archivo escribir lo siguiente:

FROM amazoncorretto:11-alpine-jdk

MAINTAINER unnombreparaidentificarte

COPY target/NOMBRE-DE-TU-ARCHIVO-CONSTRUIDO-CON- SPRINGBOOT.jar 
NOMBRE-DE-TU-ARCHIVO-CONSTRUIDO-CON- SPRINGBOOT.jar

ENTRYPOINT ["java","-jar","/
NOMBRE-DE-TU-ARCHIVO-CONSTRUIDO-CON- SPRINGBOOT.jar"]

- Reemplazar el número 11 de la primera línea por la versión de Java que se tenga que está en el archivo pom (dice java.version)

- Guardar 

- Hacer Clean and build (botĂłn derecho sobre el nombre del Proyecto, elegir Clean and buld). Esperar. 

- Buscar entre los archivos una carpeta que se llama target y dentro de esa carpeta el archivo .jar que hace falta para completar el Dockerfile (dice nombredelproyecto-0.0.1-SNAPSHOT.jar o similar pueden cambiar los nĂşmeros pero siempre es asĂ­) 

- Reemplazar en el archivo Dockerfile, que creamos antes, el archivo SNAPSHOT que viene (dice NOMBRE-DE-TU-ARCHIVO-CONSTRUIDO-CON- SPRINGBOOT) por el que tengamos en target (está tres veces en el Dockerfile en dos lĂ­neas prestar atenciĂłn a las comillas, comas y guiones).

- Buscar el archivo gitignore y poner dos símbolos # (numeral) seguidos delante de la línea 2 (donde dice target) esto es para que gitignore no excluya la carpeta target al subir a GitHub debe quedar como ##target... . También se puede eliminar las líneas de target y funciona (son cuatro o cinco líneas desde target hasta que aparece el primer espacio siempre en el archivo gitignore.

- Guardar

- Hacer Clean and build otra vez

- Hacer git add . , git commit -m "Mensaje" y git push

- Ver en Github que haya subido tanto el Dockerfile como la carpeta target (sin la carpeta target que contiene el archivo .jar que está indicado en el Dockerfile no funciona) Es posible que si tienen versión 17 de Java no se cree la carpeta target o los archivos .jar o que falten carpetas. Si esto sucede hay que crear un Proyecto nuevo en SpringBoot con versión Java 11 y hacer todos los pasos anteriores (crear archivo Dockerfile incluido pero sin necesidad de subir a GitHub es decir sin hacer el paso anterior a este que estás leyendo el que dice "Hacer git add ....") en ese archivo nuevo se van a crear dos carpetas que se llaman maven-archiver y surefire-reports esas carpetas hay que copiarlas al Proyecto que tiene que subir a GitHub. Lo mismo los dos archivos .jar (no importa si los nombres de los archivos .jar no coinciden con el nombre que está en el archivo pom de nuestro Proyecto. Funciona igual.

- Si hubiera algĂşn problema y no de desplegase despuĂ©s de varios intentos se puede dejar conectado y verificar a las 24hs y si aĂşn asĂ­ no funcionase se puede eliminar, de la primera lĂ­nea del archivo Dockerfile todo lo siguiente: -alpine-jdk pero solo para casos excepcionales.

- Si está todo bien entonces ir a Render, crear una cuenta con GitHub, crear un Web Service, conectar todo con GitHub, elegir All repositories (todos los repositorios) Y seguir los pasos que nos muestre para desplegar. En el video #81 de la lista YoProgramo del Canal @ProgramaTK de YouTube tienen todo el paso a paso hecho.

- Si la primera vez no sube no hay problema arriba a la derecha en la misma pantalla de Render hay un botĂłn de color azul que dice Manual deploy ahĂ­ hay que elegir la tercera opciĂłn que dice Clear build cache & deploy. Hay que darle ahĂ­ hasta que veamos que Render lee el commit que se hizo al final (aparece el nombre del commit arriba de la ventana donde empieza a cargar todo)

- Si ya tienen desplegado el back-end en otra plataforma no funciona el deploy en Render hasta que no paren el otro servicio.

- Si Render no levanta el Ăşltimo commit es decir que no aparece entonces en el mismo botĂłn azul de arriba a la derecha de la ventana donde compila hay que darle click a Deploy latest commit entonces se dedica al Ăşltimo commit con exclusividad.

Una vez hecho, si todo está bien, vamos a tener un mensaje de Success con lo cual ya podemos hacer uso del enlace que nos brinda Render para vincular el back-end con cualquier otro servicio que utilicemos para el front-end creando una Arquitectura Distribuida.

Estos son todos los pasos para tener un back-end hecho con Java en Springboot corriendo en Render. 

Esperamos les sea de utilidad!!!