Imágenes distroless: de 840 MB a 52 MB

Contenido del curso

Optimización Avanzada en Docker

Buenas Prácticas en Docker

Instalación y Configuración en Entornos Multiplataforma

Redes Avanzadas y Balanceo de Carga

Automatización de CI/CD

Orquestación

Develop

34
Dev containers en VS Code con Docker
09:54 min

Tomar examen

Cursos Empresas Blog Live Conf Eventos Precios

0:005:15

Imágenes distroless: de 840 MB a 52 MB

Curso de Docker Avanzado

Clase 5 de 34

Clase 5 / 34

Recursos

Las imágenes distroless en Docker te permiten crear contenedores hasta 16 veces más pequeños sin perder funcionalidad, eliminando capas innecesarias de la distribución base. Si trabajas con Docker y buscas optimizar tus despliegues, este enfoque cambia por completo la forma en que construyes imágenes.

El concepto se popularizó junto a otras tendencias de la industria que comparten su prefijo less, como serverless o wireless. Y aunque suena a que algo desaparece, la realidad es más interesante: el componente sigue ahí, solo que mucho más reducido.

Qué significa realmente distroless en Docker

La palabra distroless se asemeja a wireless o serverless: sugiere ausencia, pero no la implica del todo. En una conexión wireless no usas cables hasta el router, aunque del router en adelante sí los hay. En serverless no administras un servidor, pero tu aplicación sigue hospedada en uno.

Con distroless pasa lo mismo. No significa que tu imagen de Docker no tenga distribución de Linux, significa que esa distribución es mínima, compacta y ajustada solo a lo que tu servicio necesita [01:00].

¿Qué es una imagen distroless? Es una imagen base de Docker que contiene únicamente lo indispensable para ejecutar tu aplicación, eliminando shells, gestores de paquetes y utilidades que no aportan valor a tu servicio.

Ese enfoque reduce superficie de ataque, acelera despliegues y hace que tus contenedores sean mucho más livianos.

Dónde encuentro las imágenes distroless oficiales

El repositorio de referencia es Google Container Tools, donde el equipo mantiene una colección de imágenes distroless listas para usar. Ahí encontrarás documentación, variantes y ejemplos por lenguaje [01:45].

Las imágenes siguen una convención de nombres clara. Después de la palabra distroless aparece la base sobre la que se construyen, normalmente Debian o NoSSL Debian. También verás distintas arquitecturas disponibles para que elijas la que coincida con tu entorno de despliegue.

Dentro del repositorio existe un folder de ejemplos con casos prácticos por tecnología. Para esta demostración se usa el ejemplo de Python 3, que contiene solo dos archivos: un Dockerfile y un hello.py.

Cómo construyo una imagen distroless paso a paso

El flujo es directo. Copias el archivo hello.py del repositorio sin modificar nada porque ya viene optimizado, y lo pegas en un nuevo folder llamado distroless dentro de Visual Studio Code.

Luego replicas el Dockerfile del mismo ejemplo. Aquí es donde aparece la pieza clave: el archivo usa la técnica de multi-stage build, con dos imágenes involucradas.

Python 3 slim: imagen donde se ejecuta toda la lógica de compilación y preparación de la aplicación.
Distroless Python 3: imagen final que publica la aplicación lista para producción, sin las herramientas de desarrollo.

Esta separación es lo que permite que tu imagen final sea minúscula, porque solo arrastra lo necesario para correr el código, no para construirlo.

Qué comando uso para compilar la imagen

Desde la terminal, ubicado en el folder donde está el Dockerfile, ejecutas:

bash docker build -t hello-python .

El tag hello-python te sirve para identificar la imagen, y el punto final indica que el contexto de construcción es el directorio actual. La compilación es notablemente rápida [04:00].

Cuánto se reduce el tamaño con una imagen distroless

Aquí viene lo interesante. Al revisar el resultado en Docker Desktop, la diferencia es brutal. Una aplicación que en imágenes tradicionales pesaba 840 MB, con distroless baja a 52 MB [04:30].

Eso es una reducción de aproximadamente 94% en el tamaño final, manteniendo la misma funcionalidad.

¿Por qué una imagen distroless es tan pequeña? Porque elimina shell, gestores de paquetes y utilidades del sistema operativo que tu aplicación no necesita en producción, dejando solo el runtime y las dependencias mínimas.

Ese ahorro impacta directamente en tiempos de pull, costos de almacenamiento en registries y velocidad de arranque en orquestadores como Kubernetes.

Cuándo conviene usar distroless en mis proyectos

La decisión depende del balance entre depuración y optimización. Como las imágenes distroless no incluyen shell, no puedes hacer docker exec para entrar al contenedor a investigar problemas en caliente. Eso es intencional: menos componentes, menos vectores de ataque.

Es ideal cuando ya tienes una aplicación estable, has terminado la fase de desarrollo y quieres llevarla a producción con la mínima superficie posible. Para entornos de desarrollo activo, una imagen slim sigue siendo más cómoda.

La lección central es que distroless no se trata de eliminar la distribución de Linux, sino de elegir la más reducida y optimizada posible para que tu imagen sea angosta sin sacrificar capacidad de despliegue.

¿Has medido el tamaño de tus imágenes actuales? Cuéntame en los comentarios cuánto pesan tus contenedores hoy y dónde crees que podrías aplicar distroless en tu stack.

Mauricio Escobar

Hace un año

pregunta: si usamos una versión distroless en nuestro proyecto, la cuál entiendo que no tiene bash.

Qué pasa si por alguna razón se ha roto algo y repentinamente le da la chiripiorca a la app? cómo nos comunicamos con esta distro si no hay bash?

Se me ocurre resolverlo instalando dos versiones con multi stage (versión slim para debug + distroless) aunque sería un poco contradictorio, no? porque no estaríamos ahorrando espacio

Ricardo Enrique Arias Teguedor

Hace 9 meses

Para arreglar imágenes que estén en producción o que no se puedan detener y reconstruir se me ocurre podrías copiar desde el host una shell que esté compilada de manera estática al contenedor (tiene que ser de manera estática para que el ejecutable de la shell no dependa de librerías que puedan no estar presentes en el contenedor), y ya con la shell entras en el contenedor e identificas y arreglas lo que se haya roto.

Por otro lado, para imágenes que no estén en producción o que se puedan volver a levantar, mirando logs se pueden intuir bastante bien de dónde provienen los errores. En última instancia, durante la construcción de la imagen, si la imagen base soporta por lo menos un gestor de paquetes, se puede descargar e incluir en la imagen algunas herramientas de depuración. Añadirá espacio extra a la imagen, pero servirá para el diagnóstico y luego se pueden eliminar las herramientas de depuración y tener una imagen ligera.

En todo caso, creo que la optimización agresiva (como imágenes distroless o por el estilo) es idónea cuando los recursos son muy limitados, pero si no hay necesidad de optimizar y la política de seguridad lo permite, el tener las herramientas de depuración adecuadas no añadirá mucho espacio y por otro lado permitirá arreglar cosas tanto en producción como en desarrollo.

Ricardo Enrique Arias Teguedor

Hace 9 meses

Adicionalmente, investigando un poco más en el repo de Distroless, hay imágenes debug que sí tienen shell y herramientas de depuración (https://github.com/GoogleContainerTools/distroless?tab=readme-ov-file#debug-images) . De nuevo, las herramientas de depuración no deberían afectar el comportamiento de programas así que se puede esperar el mismo comportamiento en distros con herramientas de depuración y distros que carezcan de ellas.

Optimización Avanzada en Docker

Optimización avanzada de Docker para cloud native

Docker productivo vs comandos básicos

Multi-stage builds en Docker con ASP.NET

Cómo escanear vulnerabilidades en imágenes Docker

Imágenes distroless: de 840 MB a 52 MB

Imágenes Docker para múltiples arquitecturas

Cómo funciona el caché en Docker builds

De 1.19 GB a 126 MB con Alpine

Qué es el build context en Docker

Docker Hub para compartir imágenes en la nube

Buenas Prácticas en Docker

Cómo reducir capas en Docker

Cómo usar .dockerignore para imágenes más pequeñas

Limpia Docker y recupera gigas con prune

Creando usuarios en Docker sin privilegios root

6 prácticas Docker para imágenes listas para producción

Instalación y Configuración en Entornos Multiplataforma

Publica imágenes Docker en Azure Container Registry

Azure Container Registry hacia Container App

Redes Avanzadas y Balanceo de Carga

Redes en Docker: los 5 modelos explicados

Cómo funcionan los puertos en Docker

Balanceo de carga con NGINX en Docker

Automatización de CI/CD

Optimizar Dockerfile con comandos RUN y scripts

Automatiza Docker con GitHub Actions

Pruebas automáticas de Docker con GitHub Actions

Despliegue automático en Azure con GitHub Actions

Orquestación

Docker Compose: balanceo de cargas automatizado

Estructura y plantilla de Docker Compose YAML

Volúmenes Docker: bind vs nombrados

docker-compose down vs Control C en apagado

Docker Swarm para principiantes paso a paso

Despliegue Docker Swarm con réplicas de Nginx

Costos ocultos de contenedores en la nube

Cómo habilitar Kubernetes en Docker Desktop

Planes y límites de Docker Hub en producción

Develop

Dev containers en VS Code con Docker

Imágenes distroless: de 840 MB a 52 MB