Las imágenes distroless permiten reducir drásticamente el tamaño de tus contenedores sin sacrificar requisitos de ejecución. Aquí verás cómo, con multi-stage y un ejemplo en Python 3, se pasa de 840 MB a 52 MB, con builds más rápidos y despliegues más eficientes.
¿Qué es distroless y cómo optimiza tus imágenes Docker?
Las distroless no eliminan Linux: eliminan lo innecesario. La idea es no pensar en una distribución completa, sino usar una base más pequeña, compacta y ajustada al servicio. Así logras imágenes angostas en tamaño y listas para producción.
¿Cómo se relaciona distroless con serverless y wireless?
La analogía aclara el concepto.
En wireless no usas cables, pero existen en la infraestructura.
En serverless no administras el servidor, pero sigue ahí.
En distroless no “desaparece” Linux: simplemente usas una distro mínima.
¿Qué papel cumple Debian en estas imágenes distroless?
Muchas variantes se basan en Debian.
Verás opciones como Debian o No SSL Debian.
La elección depende de requisitos del servicio.
¿Qué considerar sobre arquitecturas?
Revisa las arquitecturas soportadas por cada imagen.
Asegura compatibilidad con tu entorno de ejecución.
Evita sorpresas al desplegar.
¿Cómo crear una imagen distroless con Python 3 y multi-stage?
El repositorio de Google Container Tools ofrece ejemplos listos. Con dos archivos y un Dockerfile breve, puedes construir y publicar una imagen final mínima basada en distroless.
¿Qué archivos necesitas del repositorio de Google Container Tools?
Ubica el repo distroless en Google Container Tools.
En la carpeta de ejemplos, entra a Python 3.
Copia dos archivos: dockerfile y hello.py.
Crea un folder local llamado "distroless".
Añade hello.py y dockerfile sin modificar el contenido.
¿Cómo funciona el Dockerfile multi-stage?
Primera etapa con Python 3 slim: aquí “ocurre la magia” de la app.
Publicación con distroless Python 3: imagen final mínima y optimizada.
Pocas líneas, enfoque claro y sin capas innecesarias.
¿Cómo construir y etiquetar la imagen con docker build?
Abre la terminal en la carpeta del dockerfile.
Ejecuta el build con etiqueta identificable.
docker build -t <tu-tag>.
Observa la velocidad del build.
Verifica el resultado en Docker Desktop.
¿Qué resultados obtienes y por qué convienen?
El cambio es notable: menor peso, builds más ágiles y despliegues más confiables. Todo gracias a escoger bien las imágenes base y aprovechar multi-stage para separar construcción y ejecución.
¿Qué tamaño logramos frente a imágenes tradicionales?
Antes: 840 MB para una aplicación similar.
Ahora: 52 MB con distroless.
Se refleja directamente en transferencia, arranque y costos.
¿Por qué escoger bien la imagen base es clave?
“La magia” está en la selección de la imagen correcta.
Distroless no es “sin Linux”: es Linux mínimo y optimizado.
Cumple los requisitos de la app con el menor peso posible.
¿Qué significa realmente distroless en Linux?
No administras una distro completa.
Usas solo lo necesario para ejecutar tu servicio.
Menos superficie de ataque y menos capas inútiles.
¿Ya probaste imágenes distroless en tus proyectos con Python 3 u otros runtimes? Cuéntame qué tamaños y mejoras has logrado y qué variantes de Debian te han funcionado mejor.
Distroless es un enfoque para crear imágenes de contenedores mínimas, sin incluir herramientas o paquetes innecesarios como shells o administradores de paquetes.
Principales características:
Ligero y seguro: Reduce el tamaño de las imágenes y minimiza la superficie de ataque al eliminar componentes innecesarios.
Específico para aplicaciones: Contiene solo las bibliotecas esenciales para ejecutar una aplicación.
Optimizado: Mejora los tiempos de arranque y la eficiencia del contenedor.
Distroless te permite crear contenedores más seguros y eficientes, enfocados únicamente en ejecutar tu aplicación.
claro por que fue utilizada la version python:3-slim siendo slim la version mas austera es decir la imagen python:3.10-slim es una de las versiones más básicas y ligeras del contenedor de Docker para Python. Esta imagen contiene solo los componentes esenciales necesarios para ejecutar Python, lo que reduce significativamente el tamaño de la imagen
Esta parte de Distroless se ve que esta en progreso, pero eso no le quita el gran potencial que tiene. El decremento de tamaño es genial porque cuando tienes tu registry, es muy importante el tamaño así podrías almacenar mas imágenes históricas por cualquier tema. Ademas la velocidad de pull cuando se corren en ambiente productivo es mucho más rápido.
Vayah, Esto <<Distroless>> Esta R Genial, Que Bien por saber esto @hora.
Yo si que habia tenido contacto con Distroless en AWS cuando crecias una Instancia en EC2 y la arrancabas se debia seleccionar la Imagen ISO para el O>S de la Nueva Instancia, estas Imagenes viene con lo minimo posible de la distribucion , ahora para dockerImage la minimilismo sera mucho mayor aun permitiendo crear imagenes muy Ligeras para conteneer todas las dependecias y pequetes necesarios para Software.
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
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.
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.
Yo hice la prueba creando la imagen SIN distroless y pesó 118 MB (un ahorro de 66 MB aprox. con distroless)
¡Espectacular! 🤯
desplegando contenedor de imagen creada:
docker run -it --rm --name hellopythoncnt hellopython
