Combinación de varios mandatos en una sola sentencia RUN para reducir el tamaño de la imagen

En este ejemplo, debe instalar software en la imagen de contenedor, por ejemplo, Node.js. Utilice las imágenes base para Node.js para crear una aplicación Node.js.

Para instalar manualmente Node.js, puede utilizar el siguiente ejemplo de Dockerfile,

FROM ubuntu

RUN apt update
RUN apt upgrade -y
RUN apt install -y nodejs
RUN apt clean
RUN rm -rf /var/lib/apt/lists/\*

En este ejemplo, se utilizan varias sentencias RUN para actualizar, instalar Node.js, limpiar y eliminar la memoria caché de archivos. Aunque esta secuencia de sentencias es correcta, el uso de varias sentencias RUN no es la mejor implementación. Cuando se procesa un Dockerfile, cada sentencia del Dockerfile crea una capa. Cada capa contiene los archivos que se han creado o actualizado y también información sobre lo que se ha suprimido. Una imagen de contenedor es la colección de todas las capas. Si se añade un archivo a una sentencia y se suprime en una segunda, la imagen resultante todavía contiene el archivo en la capa correspondiente a la primera sentencia y la marca como suprimida en la segunda capa.

Para ahorrar espacio de disco, especifique una sola sentencia RUN para crear una sola capa para este conjunto de mandatos.

FROM ubuntu

RUN apt update && apt upgrade -y && apt install -y nodejs && apt clean && rm -rf /var/lib/apt/lists/\*

Para facilitar la lectura de un Dockerfile con una línea por mandato, añada saltos de línea a su código,

FROM ubuntu

RUN \
    apt update && \
    apt upgrade -y && \
    apt install -y nodejs && \
    apt clean && \
    rm -rf /var/lib/apt/lists/\*

Si utiliza este tipo de sentencia, puede reducir el tamaño de la imagen de contenedor de unos 174 MB a unos 147 MB. Tenga en cuenta que los tamaños de ejemplo pueden diferir ya que la imagen base de Ubuntu y el paquete Node.js pueden cambiar.

Este tipo de práctica recomendada no solo se aplica a las instalaciones de paquetes, sino también a tareas similares. En el siguiente ejemplo, la descarga y la extracción de un paquete de software, de nuevo Node.js, se pueden parecer similar a las del siguiente ejemplo:

FROM ubuntu

RUN apt update
RUN apt upgrade -y
RUN apt install -y curl
RUN curl https://nodejs.org/dist/v16.14.2/node-v16.14.2-linux-x64.tar.gz -o /tmp/nodejs.tar.gz
RUN mkdir /opt/node
RUN tar -xzf /tmp/nodejs.tar.gz -C /opt/node --strip 1
RUN rm /tmp/nodejs.tar.gz
RUN apt remove -y curl
RUN apt clean
RUN rm -rf /var/lib/apt/lists/\*

El mandato rm elimina el paquete nodejs descargado, pero las múltiples sentencias RUN vuelven a crear capas separadas. Además, para descargar el paquete nodejs, se instala temporalmente el paquete curl. Aunque el paquete de curl propiamente dicho se elimina más adelante, sus dependencias que se instalaron implícitamente siguen ahí. En el siguiente ejemplo se muestra un Dockerfile más adecuado,

FROM ubuntu

RUN \
    apt update && \
    apt upgrade -y && \
    apt install -y curl && \
    curl https://nodejs.org/dist/v16.14.2/node-v16.14.2-linux-x64.tar.gz -o /tmp/nodejs.tar.gz && \
    mkdir /opt/node && \
    tar -xzf /tmp/nodejs.tar.gz -C /opt/node --strip 1 && \
    rm /tmp/nodejs.tar.gz && \
    apt remove -y curl && \
    apt auto-remove -y && \
    apt clean && \
    rm -rf /var/lib/apt/lists/\*

Los mandatos relacionados se combinan en una sola sentencia RUN y se añade el mandato apt auto-remove para eliminar las dependencias. Este ejemplo reduce el tamaño de la imagen de unos 222 MB a unos 162 MB.

Utilización de una imagen base muy pequeña

En los ejemplos anteriores se utiliza Ubuntu como imagen base. Aunque esta imagen contiene muchos programas de utilidad útiles, cuantos más programas de utilidad haya en una imagen base, mayor es su tamaño. Además, al incluir más programas de utilidad, aumenta la probabilidad de que encuentre una vulnerabilidad de seguridad, lo que le requiere volver a compilar la imagen. Para evitar estos problemas, utilice una imagen base de menor tamaño. Por ejemplo:

• Alpine es una imagen de Docker oficial con un tamaño pequeño. Para entornos de programación como Java o Node.js, a menudo encontrará etiquetas basadas en Alpine.

• Las imágenes distroless (imágenes sin sistema operativo) de Google Container Tools no contienen ninguna herramienta del sistema operativo, sino solo el entorno de ejecución necesario para distintos lenguajes como Java y Node.js.

Compare estas imágenes base creando una imagen de contenedor que ejecute un programa Node.js en un archivo program.js. Para Ubuntu, el archivo Dockerfile tiene un aspecto similar al del siguiente ejemplo:

FROM ubuntu

RUN \
    apt update && \
    apt upgrade -y && \
    apt install -y nodejs && \
    apt clean && \
    rm -rf /var/lib/apt/lists/\*

COPY program.js /app/program.js

WORKDIR /app

ENTRYPOINT ["node", "program.js"]

Para Alpine, la imagen se toma directamente desde Node.js,

FROM node:16-alpine

COPY program.js /app/program.js

WORKDIR /app

ENTRYPOINT ["node", "program.js"]

Para distroless, utilice el ejemplo siguiente:

FROM gcr.io/distroless/nodejs:16

COPY program.js /app/program.js

WORKDIR /app

CMD ["program.js"]

Mientras que la imagen basada en Ubuntu es de 147 MB, la imagen basada en Alpine es de 90 MB y la imagen basada en distroless es de 94 MB.

No incluya fuentes ni herramientas de compilación para reducir el tamaño de la imagen

En los ejemplos basados en Node.js anteriores, se añade un solo archivo de origen a la imagen de contenedor. En este ejemplo se ha podido utilizar un único archivo de origen porque no era necesaria ninguna compilación. Sin embargo, si se necesita una compilación, utilice solo las herramientas necesarias para la compilación, pero no las incluya en la imagen resultante. Por ejemplo, especifique una aplicación Java que utilice Maven como ejemplo. Un Dockerfile mal codificado tiene un aspecto similar al del siguiente ejemplo:

FROM maven:3-jdk-11-openj9

WORKDIR /app
COPY . /app

RUN mvn package

EXPOSE 8080
ENTRYPOINT ["java", "-jar", "/app/target/java-application-1.0-SNAPSHOT-fat.jar"]

La imagen de contenedor resultante contiene todo el código fuente y todos los archivos intermedios de Maven (como su memoria caché de artefactos, archivos de clase que se empaquetan posteriormente en un archivo JAR) así como la herramienta de compilación Maven. Además, también se incluye el JDK (Java Development Kit) cuando se necesita un Java Runtime Environment (JRE) mucho menor en el momento de la ejecución. Como resultado, el tamaño de la imagen es de 466 MB.

Para reducir el tamaño de la imagen, utilice una característica llamada compilaciones de varias etapas. Cada etapa de una compilación de Docker tiene su propia imagen base y puede ejecutar mandatos en su etapa. Al final, se crea una imagen final que copia artefactos de etapas anteriores. Para compilar una imagen de contenedor a partir del código fuente, un patrón común consiste en tener dos etapas:

1. La etapa de compilación que utiliza una imagen base que contiene todas las herramientas necesarias para compilar el código fuente en el binario para el tiempo de ejecución.
2. La etapa de tiempo de ejecución que utiliza una imagen base con el entorno de ejecución necesario para ejecutar el binario. El binario de la etapa de compilación se copia en esta etapa.

Para el proyecto Maven, el resultado se parece al del siguiente ejemplo:

FROM maven:3-jdk-11-openj9 AS builder

WORKDIR /app
COPY . /app

RUN mvn package

FROM adoptopenjdk:11-jre-openj9

WORKDIR /app
COPY --from=builder /app/target/java-application-1.0-SNAPSHOT-fat.jar /app/java-application.jar

EXPOSE 8080
ENTRYPOINT ["java", "-jar", "/app/java-application.jar"]

En este ejemplo, la etapa de compilación utiliza la imagen base de Maven para compilar el archivo JAR de la aplicación. La etapa de tiempo de ejecución utiliza la imagen base de JRE de menor tamaño. Mediante el mandato COPY --from=STAGE_NAME, el archivo JAR se copia de la etapa de compilación en la etapa de ejecución. La imagen resultante tiene un tamaño de 242 MB, ahorrando alrededor del 48%.

Este patrón también se puede utilizar para otros lenguajes de programación en los que es necesario realizar una compilación.

• Aplicaciones de nodo que requieren una compilación, por ejemplo una compilación Angular o React. Aquí, la imagen base del compilador y del tiempo de ejecución pueden terminar siendo la misma (ambos nodos), pero no es necesario copiar todos los artefactos y orígenes de tiempo de compilación en la imagen de tiempo de ejecución.
• Cualquier lenguaje de programación que compile código fuente en un ejecutable nativo que se ejecute sin un entorno de ejecución, por ejemplo Go o Rust.

Para los lenguajes que producen un ejecutable nativo y no necesitan un entorno de ejecución, utilice otra prestación de Docker para la etapa de ejecución: scratch. Scratch se puede utilizar como base en el mandato FROM, pero no es una imagen de contenedor final. Solo indica a la compilación de Docker que no utilice una imagen base. Sin archivos de sistema operativo procedentes de una imagen base, la imagen resultante puede contener un solo archivo: el binario que se copia de la etapa de compilación. Tenga en cuenta que, en función del lenguaje de programación y del código, es posible que tenga que realizar más ajustes en las opciones del compilador, ya que la existencia de algunos archivos binarios se basa en algunos archivos del sistema operativo.

Mantenimiento de la imagen limpia

Cuando desarrolle por primera vez su Dockerfile y depure su funcionamiento, es posible que instale algunas herramientas temporales o que aplique otras cargas de trabajo que no sean necesarias en la imagen de contenedor final. La eliminación de estos archivos temporales y cargas de trabajo mantiene la imagen limpia, pequeña y segura.