Compile rápido, implemente más rápido: creación de imágenes acoplables más claras

Hola, me llamo Miguel y hoy les traigo otro nuevo artículo.

Esta publicación intenta abordar el desafío de mantener el tamaño de la imagen bajo en Docker. Con el aumento en la adopción de Docker, la mayoría de la organización se está moviendo hacia imágenes basadas en Docker para sus aplicaciones. Con esta adopción acelerada, es importante controlar el tamaño de las imágenes de la ventana acoplable, ya que afecta el tiempo de implementación en producción.

Comprensión de las compilaciones normales de Docker y sus desafíos

Echemos un vistazo a Dockerfile de nuestra aplicación basada en Golang.

FROM golang:latest
WORKDIR /app
COPY go.mod go.sum ./
RUN  go mod download
COPY . .
RUN go build -o main .
EXPOSE 8080
CMD ["./main"]

Si construimos la imagen usando el Dockerfile anterior, el tamaño de la imagen será:

$ docker images
REPOSITORY  TAG           IMAGE ID        CREATED              SIZE
go-app      single-stage  cf90e2811d8e    About a minute ago   826MB

Comprender el problema con esta compilación de Docker

Si miramos de cerca, con este enfoque hemos empaquetado las siguientes cosas con nuestra compilación actual:

1. Compilador
2. Linters
3. Tiempo de ejecución de Golang
4. Depuradores
5. Configuración
6. Solicitud

Pero en realidad, deberíamos empaquetar solo las cosas esenciales:

1. Tiempo de ejecución
2. Configuración
3. Solicitud

También la imagen base golang:latest es él mismo 809 MB. Eso es enorme.

Para resolver esto, podemos usar compilaciones de múltiples etapas introducidas con la versión 17.05 de Docker.

Construcciones de varias etapas

Con las compilaciones de varias etapas, podemos dividir nuestro Dockerfile en dos etapas:

1. Constructor: En esta etapa, copiaremos toda nuestra aplicación y otras configuraciones necesarias (si las hay) que serán necesarias para construir un ejecutable golang.
2. Ejecutable: En esto, simplemente copiaremos la salida de nuestra etapa anterior y ejecutaremos la aplicación. Esta última etapa será la parte de la imagen real. Para ejecutar nuestra aplicación, podemos usar scratch como base y el Dockerfile final será algo como:

############################
# STEP 1 build executable binary
############################
FROM golang:latest as builder
WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN go build -o main.

############################
# STEP 2 build a small image
############################

FROM scratch
WORKDIR /root/
COPY --from=builder /app/main .
EXPOSE 8080
CMD ["./main"]

Si comparamos el tamaño de las imágenes de la ventana acoplable, la que creamos anteriormente y la compilación de múltiples etapas:

REPOSITORY  TAG       IMAGE ID      CREATED        SIZE
go-app  single-stage cf90e2811d8e  13 minute ago   826MB
go-app  multi-stage  2592d4c8f313  10 minute ago   8MB

Es claramente visible que con este enfoque hemos reducido el tamaño de 826 MB a 8 MB.

Resumen

Este enfoque resulta útil cuando tenemos varias aplicaciones implementadas en un entorno en contenedores. Un tamaño menor significa menos tiempo de descarga, lo que resulta en implementaciones más rápidas.

Gracias por leer.