Dockerfile

¿Qué es Dockerfile?

Según microsoft

dockerfile es un archivo de texto que contiene las instrucciones necesarias para crear una nueva imágen en el contenedor¹

Según mi experiencia

Dockerfile no es más que un fichero al que tienes que llamarle Dockerfile (literalmente). Dentro de este fichero tú vas a tener que añadir una serie de instrucciones para que tu proyecto pueda funcionar. Esto te va a crear un elemento llamado Imágen².

Pongamos un pequeño ejemplo

Todos los proyectos Java necesitan su ración de Java, ¿no? Pues aquí no es la excepción. Necesitamos un buen OpenJDK y un archivo .jar, que es básicamente el fruto de nuestras horas de compilación, donde residen todas esas clases .class que tanto nos ha costado escribir.

¿cómo metemos todo en nuestro Dockerfile?

parece fácil ¿verdad? Pero… ¿será tan sencillo como parece?

Bajo mi opinión, todos debemos de empezar creando un Dockerfile más sencillo como el ejemplo que se va a poner a continuación:

    FROM openjdk:11

    WORKDIR /app

    COPY MiApp.jar /app/MiApp.jar

    CMD ["java", "-jar", "MiApp.jar"]

Este fichero dockerfile es el que vas a encontrar en el 90% de las ocasiones, sobre todo cuando el proyecto se esta inicializando y la imágen no necesita más como para ser ejecutada en un contenedor.

Opción mas compleja

Ahora vamos a ver un fichero Dockerfile con instrucciones que en mi caso, menos veces he visto:

FROM openjdk:18-jdk-alpine as builder

WORKDIR /app/usermanagement_ms

COPY . .

COPY ./.mvn ./.mvn

COPY ./mvnw .

COPY ./pom.xml .

RUN ./mvnw clean package && rm -r ./target

COPY ./src ./src

RUN ./mvnw clean package

FROM openjdk:18-jdk-alpine

WORKDIR /app

COPY  --from=builder /app/usermanagement_ms/target/usermanagement-0.0.1-SNAPSHOT.jar .

EXPOSE 8001

ENTRYPOINT ["java","-jar","./target/usermanagement-0.0.1-SNAPSHOT.jar"]

Primera etapa

Segunda etapa

Te has quedado de piedra, como yo la primera vez cuando empecé a investigar hasta que nivel pueden llegar los ficheros Dockerfile (tranquilo a todo el mundo le pasa) Ahora bien, te voy a explicar que hemos implementado aquí y obviamente te voy a razonar todo (bajo mi experiencia)

1. Optimización del tamaño de la imágen Esto podemos separarlo en dos etápas:

   • La primer etapa es la etapa Builder, esta etapa contiene las herramientas de compilación permitiendo empaquetar la aplicación sin llevarnos el código.
   • La segunda etapa se usa una imágen mas ligera openjdk:18-jdk-alpine que solo contiene el entorno de ejecución de Java 18 en alpine Linux. Reduciendo el tamaño de la imágen final.

2. Separación de fases:

   • Gracias a separarlo hemos mejorado la seguridad al eliminar las herramientas de compilación (rm -r ./target)

3. Mantenimiento:

   • Ahora imagina que tu microservicio crece un 70% más de lo que tenias hace 3 meses de desarrollo, gracias a este Dockerfile conseguimos una mejora drástica en el mantenimiento separando las responsabilidades de cada etápa

¿Cual elegir?

Bajo mi punto de vista las dos opciones son correctas y como dije anteriormente, se suele usar las opciones mas fáciles ya que no necesitas tanta complejidad en los Dockerfile. Aun así creo que es importante y necesario saber todo el potencial que tiene Dockerfile.

Espero que esta introducción a los Dockerfile y microservicios haya sido útil y te haya inspirado a explorar nuevas formas de desarrollar y desplegar aplicaciones!

Esto es solo un pequeño ejemplo pero como todo, se puede hacer mucho mas complejo