Pequeñas imágenes de Docker que creían en sí mismas*

[referencia a un cuento infantil estadounidense 'El pequeño tren que podía' ('The Little Engine That Could') — nota del traductor]*

Cómo crear automáticamente pequeños imágenes docker para tus necesidades

Una obsesión inusual

En los últimos meses he estado obsesionado con la idea de: ¿cuánto se puede reducir una imagen de Docker mientras la aplicación sigue funcionando?

Entiendo, la idea es extraña.

Antes de profundizar en los detalles y aspectos técnicos, me gustaría explicar por qué este problema me ha atrapado tanto y cómo te afecta a ti.

Por qué el tamaño importa

Al reducir el contenido de la imagen de Docker, también estamos reduciendo la lista de vulnerabilidades. Además, hacemos las imágenes más limpias, ya que solo contienen lo necesario para ejecutar aplicaciones.

Hay otra pequeña ventaja: las imágenes se descargan un poco más rápido, pero, en mi opinión, eso no es tan importante.

Ten en cuenta: si te preocupa el tamaño, las imágenes Alpine son pequeñas por sí solas y seguramente te convendrán.

Imágenes sin distribución

El proyecto Distroless ofrece una colección de imágenes básicas 'distroless', que no contienen gestores de paquetes, shells ni otras utilidades que estás acostumbrado a ver en la línea de comandos. Como resultado, no podrás usar gestores de paquetes como pip y apt :

FROM gcr.io/distroless/python3
RUN  pip3 install numpy

Dockerfile que utiliza la imagen distroless de Python 3

Enviando contexto de construcción al demonio de Docker  2.048kB
Paso 1/2 : FROM gcr.io/distroless/python3
 ---> 556d570d5c53
Paso 2/2 : RUN  pip3 install numpy
 ---> Ejecutándose en dbfe5623f125
/bin/sh: 1: pip3: no encontrado

Pip no está en la imagen

Normalmente, este problema se resuelve mediante la construcción de múltiples etapas:

FROM python:3 as builder
RUN  pip3 install numpy

FROM gcr.io/distroless/python3
COPY --from=builder /usr/local/lib/python3.7/site-packages /usr/local/lib/python3.5/

Construcción de múltiples etapas

Como resultado, se obtiene una imagen de 130MB. ¡No está tan mal! Para comparación: la imagen predeterminada de Python pesa 929MB, mientras que la versión 'adelgazada' (3.7-slim) — 179MB, la imagen alpine (3.7-alpine) — 98.6MB, mientras que la imagen distroless básica utilizada en el ejemplo pesa 50.9MB.

Se puede argumentar que en el ejemplo anterior copiamos un directorio completo /usr/local/lib/python3.7/site-packages, que podría contener dependencias innecesarias para nosotros. Aunque está claro que la diferencia en tamaños de todas las imágenes base de Python disponibles varía.

Al momento de escribir estas líneas, Google distroless no soporta muchas imágenes: Java y Python están aún en fase experimental, y Python solo existe para 2.7 y 3.5.

Imágenes diminutas

Volvamos a mi obsesión por crear imágenes pequeñas.

En realidad, quería ver cómo están construidas las imágenes distroless. El proyecto distroless utiliza la herramienta de construcción de Google bazel. Sin embargo, para instalar Bazel y escribir mis propias imágenes, tuve que sudar un poco (y para ser completamente honesto, reinventar la rueda es divertido y educativo). Quería simplificar la creación de imágenes reducidas: el acto de crear una imagen debe ser lo más simple posible, banal. Así que no debería haber archivos de configuración, solo una línea en la consola: simplemente construir una imagen para.

. Así que, si deseas crear tus propias imágenes, debes saber: hay una imagen de docker única llamada scratch. Scratch es una imagen "vacía", no tiene archivos, aunque por defecto pesa —¡vaya!— 77 bytes.

FROM scratch

La imagen scratch

La idea de la imagen scratch es que puedes copiar en ella cualquier dependencia desde la máquina host y usarla dentro del Dockerfile (es como copiarla y apt instalar desde cero), o más tarde, cuando la imagen de Docker se haya materializado. Esto permite tener un control total sobre el contenido del contenedor de Docker y, por lo tanto, controlar completamente el tamaño de la imagen.

Ahora necesitamos encontrar la manera de reunir estas dependencias. Las herramientas existentes como apt permiten descargar paquetes, pero están atadas a la máquina actual y, al final, no son compatibles con Windows o MacOS.

Así que me propuse construir una herramienta que reuniera automáticamente la imagen base del menor tamaño posible y que además pudiera ejecutar cualquier aplicación. Utilicé paquetes de Ubuntu/Debian, seleccioné (obteniendo paquetes directamente de los repositorios) y encontré sus dependencias de forma recursiva. El programa debía descargar automáticamente la versión estable más reciente del paquete, minimizando los riesgos de seguridad.

Llamé a la herramienta fetchy, porque… encuentra y trae… lo que necesitas [del inglés "fetch", "traer" — nota del traductor.]. La herramienta funciona a través de una interfaz de línea de comandos, pero al mismo tiempo ofrece una API.

Para construir una imagen usando fetchy (esta vez tomemos la imagen de Python), solo necesitas usar el CLI así: fetchy dockerize python. Te pueden pedir el sistema operativo objetivo y el nombre en clave, ya que fetchy actualmente solo utiliza paquetes basados en Debian y Ubuntu.

Ahora puedes elegir qué dependencias son completamente innecesarias (en nuestro contexto) y excluirlas. Por ejemplo, Python depende de Perl, aunque funciona perfectamente sin tener Perl instalado.

Resultados

La imagen de Python creada con el comando fetchy dockerize python3.5 pesa solo 35MB (estoy más que seguro de que en el futuro se podrá aún más liviano). De esta manera, se consiguió reducir 15MB de la imagen sin distribución.

Puedes ver todas las imágenes recopiladas hasta ahora aquí.

Proyecto — aquí.

Si te faltan funciones, simplemente crea una solicitud — estaré encantado de ayudar 🙂 De hecho, actualmente estoy trabajando en la integración de otros administradores de paquetes en fetchy, para que no sea necesario tener compilaciones en múltiples etapas.

Fuente: habr.com