Docker
Tamaño, base images, dependencias y superficie de ataque.
Optimizar una imagen Docker no significa perseguir el menor tamaño posible. Significa construir un runtime para el workload real.
imagen óptima
= contenido necesario
+ base mantenida
+ dependencias compatibles
+ superficie reducida
+ diagnóstico posible
+ actualización controladaUna imagen de 60 MB que falla con módulos nativos, no puede validar certificados o impide investigar incidentes es peor que una de 120 MB bien mantenida. El tamaño es una métrica; no es el objetivo completo.
Una imagen más pequeña y mejor estructurada puede reducir:
No necesariamente reduce:
Una imagen grande puede ejecutar un proceso ligero; una imagen pequeña puede consumir gigabytes de heap.
docker image ls my-api
docker image inspect my-api --format '{{.Size}}'El tamaño local puede incluir capas compartidas. No representa necesariamente el espacio adicional consumido ni el tamaño comprimido transferido desde el registry.
docker image history --no-trunc my-apiAyuda a relacionar instrucciones con cambios grandes, aunque BuildKit y multi-stage pueden hacer que el historial no explique todo el contenido.
docker system df -vDistingue images, layers compartidas, containers y build cache.
time docker pull registry.example.com/team/api@sha256:...Mide desde un host sin las capas para representar un nodo nuevo.
La base determina gran parte del filesystem, librerías y mantenimiento de la imagen.
Ejemplo conceptual:
FROM node:22-bookwormPuede incluir más paquetes y herramientas. Ventajas:
Costes:
FROM node:22-bookworm-slimSuele conservar glibc y una base Debian reducida. Puede ser un buen equilibrio para aplicaciones Node.js con dependencias nativas.
FROM node:22-alpineAlpine utiliza musl en lugar de glibc. Puede ofrecer una base pequeña, pero algunos módulos, binarios precompilados y herramientas esperan glibc.
Problemas posibles:
Alpine no es automáticamente inseguro ni incorrecto; debe elegirse por compatibilidad probada, no por moda.
Una imagen distroless elimina shell, package manager y muchas utilidades.
Ventajas:
Trade-offs:
docker exec sh no funciona;curl, ps o package manager;Una imagen distroless exige madurez operativa. No debe adoptarse antes de tener logs, métricas, traces y procedimientos de diagnóstico.
scratch representa una imagen vacía. Es apropiada para ciertos binarios estáticos.
Puede faltar:
/etc/passwd;Un binario que compila no demuestra que pueda resolver HTTPS, usuarios o zonas horarias dentro de scratch.
Una etapa de build puede incluir toolchain y source; la etapa final copia solo outputs.
FROM node:22-bookworm AS build
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci
COPY . .
RUN npm run build
FROM node:22-bookworm-slim AS runtime
ENV NODE_ENV=production
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci --omit=dev \
&& npm cache clean --force
COPY --from=build --chown=node:node /app/dist ./dist
USER node
CMD ["node", "dist/server.js"]La etapa final no recibe:
Verifica que source maps, bundles y outputs no contengan secretos o rutas internas.
Para Node.js:
npm ci --omit=devVentajas:
Revisa lifecycle scripts. Algunos paquetes compilan durante instalación y pueden requerir herramientas que no existen en la etapa final. Una estrategia es generar dependencias en una etapa compatible y copiarlas, pero módulos nativos exigen misma arquitectura y libc.
No elimines una dependencia solo porque parece “de desarrollo” si el runtime realmente la importa.
Este patrón conserva índices en capas distintas:
RUN apt-get update
RUN apt-get install -y curl
RUN rm -rf /var/lib/apt/lists/*Mejor:
RUN apt-get update \
&& apt-get install -y --no-install-recommends curl \
&& rm -rf /var/lib/apt/lists/*La limpieza debe ocurrir en la misma instrucción cuando el objetivo es evitar que el contenido quede en la layer.
Con BuildKit, cache mounts pueden acelerar descargas sin incluir la cache en el resultado.
Evita copiar todo cuando la imagen final solo necesita una parte.
Débil:
COPY . .Más controlado:
COPY package.json package-lock.json ./
COPY dist ./dist
COPY migrations ./migrationsBeneficios:
.dockerignore sigue siendo obligatorio como frontera adicional.
Cada herramienta añadida debe responder una necesidad:
Evita conservar:
No elimines CA certificates si la aplicación realiza HTTPS. No elimines timezone data si el negocio depende de zonas horarias reales.
Tener muchas layers no es por sí mismo un problema. Las layers permiten cache y deduplicación.
Squashing puede:
La estrategia preferida es diseñar bien Dockerfile y multi-stage, no corregir una construcción desordenada al final.
Menos paquetes pueden significar menos vulnerabilidades conocidas, pero el conteo bruto de CVEs puede engañar.
Evalúa:
Una base mínima pero abandonada es peor que una base algo mayor con mantenimiento activo.
Reconstruye periódicamente aunque el source no cambie para incorporar parches de base y dependencias. Cada rebuild debe pasar tests y despliegue gradual.
Antes de publicar una imagen mínima, prueba:
docker run --rm my-api node --version
docker run --rm my-api id
docker run --rm --read-only my-api
docker inspect my-api
docker history my-apiAdemás:
Puedes mantener dos targets:
FROM runtime AS production
FROM runtime AS debug
USER root
RUN apt-get update \
&& apt-get install -y --no-install-recommends curl procps \
&& rm -rf /var/lib/apt/lists/*Publica tags claramente distintos y restringe el uso de la variante debug. No la conviertas en producción por comodidad.
node:22 completa;node:22-alpine;node:22-bookworm-slim;La imagen C puede ser la mejor aunque no sea la más pequeña.
El archivo existe en una layer anterior. Reestructura la instrucción o usa multi-stage.
Comprueba si están en la imagen final. Elimínalas si no son necesarias, pero no ignores automáticamente el resultado.
Faltan CA certificates o configuración de confianza.
Puede ser intencional en distroless. Usa observabilidad y una estrategia de debug.
Dependencias o binarios nativos no fueron construidos para ambas plataformas.
Puede haber throttling, latencia, muchas capas pequeñas, descompresión lenta o falta de cache en el nodo.
Consecuencia: incompatibilidad y mayor complejidad.
Corrección: probar libc, módulos nativos y plataforma.
Consecuencia: continúan ocupando blobs.
Corrección: misma instrucción o etapa de build.
Consecuencia: source, secretos y ruido llegan al runtime.
Corrección: .dockerignore y COPY explícito.
Consecuencia: trabajo sin impacto real y regresiones.
Corrección: medir tamaño, pull, CVEs, cold start y operabilidad.
Consecuencia: incidentes más largos.
Corrección: observabilidad primero, variante debug y runbooks.
.dockerignore revisado.COPY explícito aportan más que perseguir una base diminuta.Ejecución con docker run, donde la imagen se convierte en una instancia concreta mediante configuración de runtime, permisos, recursos, red y mounts.