Entender cómo funcionan las capas de una imagen en Docker es básico para construir imágenes más pequeñas, reutilizar caché y diagnosticar por qué una imagen pesa más de lo esperado.
Una imagen Docker no es un único archivo plano. Está formada por capas ordenadas, normalmente creadas a partir de instrucciones del Dockerfile. Cada capa representa cambios sobre la anterior y Docker las reutiliza cuando puede.
👉 Y recuerda, si quieres aprender más de Linux, pincha en este curso de Linux gratis.
🐳 Si quieres aprender más de Docker, pincha en este curso de Docker gratis.
Cómo funcionan las capas de una imagen
Cuando construyes una imagen, Docker va aplicando instrucciones como FROM, RUN, COPY o ADD. Muchas de esas instrucciones generan una nueva capa. El resultado final es una pila de capas de solo lectura que Docker combina para presentar el sistema de archivos de la imagen.
La ventaja principal es la reutilización. Si dos imágenes comparten la misma base, Docker puede guardar esa capa una sola vez. Si vuelves a construir una imagen y una instrucción no cambió, Docker puede reutilizar la caché y acelerar el build.
| Elemento | Qué representa | Ejemplo |
|---|---|---|
| Capa base | Punto de partida de la imagen. | ubuntu:24.04 o alpine:3.20 |
| Capa de paquetes | Cambios tras instalar dependencias. | RUN apt-get install … |
| Capa de código | Archivos copiados a la imagen. | COPY app/ /app/ |
| Metadatos | Configuración de ejecución. | CMD, ENTRYPOINT, ENV |
Qué relación tienen las capas con el Dockerfile
El Dockerfile describe el proceso de construcción. No todas las instrucciones tienen el mismo impacto, pero las instrucciones que modifican el sistema de archivos suelen crear capas nuevas.
FROM alpine:3.20
RUN apk add --no-cache curl
COPY app/ /app/
CMD ["sh"]En este ejemplo, la imagen parte de Alpine, añade curl, copia una carpeta de aplicación y define el comando por defecto. Si cambia la carpeta app, Docker puede reutilizar las capas anteriores y reconstruir solo desde el punto afectado.
Por qué las capas afectan al tamaño
Una capa guarda cambios. Si añades archivos grandes en una capa y los borras en otra posterior, la imagen final puede seguir arrastrando parte de ese peso porque el contenido existió en una capa anterior.
RUN apt-get update && apt-get install -y paquete && rm -rf /var/lib/apt/lists/*Por eso es habitual instalar paquetes y limpiar cachés en la misma instrucción. Así reduces archivos temporales dentro de la capa que se guarda en la imagen.
Cómo ver capas de una imagen
Para revisar las capas desde la terminal puedes usar docker history. Este comando muestra el historial de construcción visible para una imagen y ayuda a detectar instrucciones que añadieron mucho tamaño.
docker history nginx:alpineEl resultado permite ver comandos de creación, tamaños aproximados y orden de capas. No debes interpretarlo como un análisis de seguridad completo, pero sí como una pista rápida para entender de dónde viene el peso.
Errores comunes con las capas
Un error habitual es copiar todo el proyecto antes de instalar dependencias. Si cualquier archivo cambia, Docker invalida la caché desde esa instrucción y el build se vuelve más lento.
Otro error es guardar secretos en capas. Aunque los borres en una instrucción posterior, pueden quedar rastros en el historial o en capas intermedias. Las credenciales deben gestionarse con mecanismos seguros de build y runtime.
Lecciones relacionadas del curso Docker
- Diferencias entre imagen y contenedor Docker
- Qué son las imágenes Alpine
- Cómo escanear imágenes Docker
Documentación oficial y recursos
Buenas prácticas con capas de imagen
Ordena el Dockerfile de lo más estable a lo más cambiante. Primero la base y dependencias, después el código de aplicación. Así aprovechas mejor la caché y evitas reconstrucciones innecesarias.
Cuando expliques cómo funcionan las capas de una imagen a un equipo, insiste en dos ideas: las capas se acumulan y la caché depende del orden. Con esa base es más fácil entender por qué un pequeño cambio puede acelerar o ralentizar todo el build.
También es recomendable revisar las imágenes base que usas con frecuencia. Si una base cambia mucho o arrastra paquetes innecesarios, todas las imágenes que dependen de ella heredarán parte de ese problema y aumentarán el coste de mantenimiento diario del equipo técnico.
También conviene revisar periódicamente cómo funcionan las capas de una imagen en tus builds reales. Una imagen pequeña, reproducible y sin secretos reduce tiempos de despliegue y problemas operativos.
