En esta lección profundizaremos en uno de los conceptos centrales de Docker: las imágenes. Ya sabes que una imagen es la "plantilla" a partir de la cual se crean los contenedores, pero ahora veremos qué hay realmente dentro de ella. Entenderás el sistema de ficheros en capas, por qué ese diseño hace que Docker sea tan eficiente, la relación exacta entre una imagen y los contenedores que genera, el papel de los tags para identificar versiones y cómo inspeccionar una imagen por dentro con docker image inspect y docker history. Comprender bien las imágenes es la base para, más adelante, construir las tuyas propias con un Dockerfile.

Una imagen es un paquete inmutable (de solo lectura) que contiene todo lo necesario para ejecutar una aplicación:

• El sistema de ficheros base (por ejemplo, una versión mínima de Linux como Alpine).
• El runtime o intérprete (Node.js, Python, la JVM…).
• Las librerías y dependencias de la aplicación.
• El código de tu aplicación.
• Metadatos: qué comando ejecutar al arrancar, qué puertos usa, variables de entorno por defecto, etc.

La clave es que una imagen es inmutable: nunca cambia una vez construida. Si necesitas una versión distinta, se crea una imagen nueva. Esta inmutabilidad es lo que garantiza que el comportamiento sea reproducible: la misma imagen produce siempre el mismo resultado.

Lo más característico de una imagen Docker es que está formada por capas (layers) apiladas una sobre otra. Cada capa representa un conjunto de cambios respecto a la anterior.

Imagina que construyes una imagen así:

1. Partir de una base de Linux (Alpine).
2. Instalar Node.js.
3. Copiar las dependencias de tu aplicación.
4. Copiar tu código.

Cada uno de esos pasos genera una capa. La imagen final es la suma de todas ellas, apiladas en orden.

El sistema de capas no es un detalle técnico cualquiera: es lo que hace a Docker eficiente. Sus ventajas principales son:

• Reutilización: si dos imágenes parten de la misma base Alpine, esa capa se almacena una sola vez en disco y se comparte. No se duplica.
• Caché de construcción: al reconstruir una imagen, Docker reutiliza las capas que no han cambiado y solo rehace las afectadas. Esto acelera mucho las construcciones repetidas.
• Descargas eficientes: al descargar una imagen, Docker solo baja las capas que aún no tienes localmente.
• Almacenamiento compacto: muchas imágenes comparten capas comunes, ahorrando espacio.

Las imágenes son de solo lectura. Entonces, ¿cómo puede un contenedor escribir archivos, crear logs o modificar datos?

Cuando arrancas un contenedor a partir de una imagen, Docker añade una capa adicional de escritura encima de las capas de solo lectura de la imagen. Todo lo que el contenedor modifica se guarda en esa capa, sin tocar la imagen original.

Consecuencias prácticas de este diseño:

• Muchos contenedores, una imagen: puedes lanzar diez contenedores de la misma imagen; todos comparten las capas de solo lectura y cada uno tiene su propia capa de escritura.
• Los contenedores son efímeros: si eliminas un contenedor, su capa de escritura desaparece con él. Por eso, para datos que deben perdurar (como una base de datos), se usan volúmenes (lo veremos en otro módulo).
• La imagen nunca se ensucia: por mucho que cambie un contenedor, la imagen permanece intacta y reutilizable.

Un tag (etiqueta) es una referencia legible a una versión concreta de una imagen. El formato completo del nombre de una imagen es:

Por ejemplo, en postgres:16:

• postgres es el repositorio (el nombre de la imagen).
• 16 es el tag (la versión).

Algunas reglas y matices importantes sobre los tags:

• Si no indicas tag, Docker asume latest (por ejemplo, nginx equivale a nginx:latest).
• latest no significa "la más reciente" de forma garantizada: es simplemente el tag por defecto que asigne el autor de la imagen. No confíes ciegamente en él.
• Varios tags pueden apuntar a la misma imagen (por ejemplo, 16 y 16.2 podrían ser la misma).
• En entornos serios conviene fijar versiones concretas (postgres:16) en lugar de latest, para que el resultado sea reproducible.

Docker ofrece dos comandos muy útiles para ver qué hay dentro de una imagen.

• Muestra un JSON con metadatos completos de la imagen: arquitectura, sistema operativo, variables de entorno por defecto, comando de arranque, puertos expuestos, lista de capas y mucho más.

Como la salida es muy extensa, puedes extraer solo lo que te interese con la opción -f (formato):

• -f '{{...}}': aplica una plantilla de formato Go para mostrar solo los campos indicados.
• {{.Os}}/{{.Architecture}}: muestra el sistema operativo y la arquitectura, algo como linux/amd64.

• Muestra el historial de capas de la imagen, de la más reciente a la más antigua.
• Para cada capa indica su tamaño y la instrucción que la creó. Es ideal para entender cómo se construyó una imagen y dónde se acumula el peso.

Para ver la salida completa sin truncar:

• --no-trunc: evita que Docker recorte las líneas largas, mostrando las instrucciones completas de cada capa.

• Confiar en latest: el tag latest puede cambiar sin avisar y romper la reproducibilidad. Fija versiones concretas en entornos importantes.
• Confundir imagen y contenedor: la imagen es inmutable y de solo lectura; el contenedor añade una capa de escritura encima. Modificar un contenedor no modifica la imagen.
• Esperar que los cambios del contenedor persistan: la capa de escritura desaparece al eliminar el contenedor. Para datos persistentes, usa volúmenes.
• Ignorar el peso de las capas: imágenes con muchas capas grandes ocupan más espacio y tardan más en descargarse. docker history te ayuda a detectar qué capa engorda la imagen.
• No aprovechar la caché de capas: al construir tus propias imágenes (lo verás más adelante), el orden de las instrucciones afecta a qué capas se reutilizan. Colocar lo que cambia menos al principio mejora el rendimiento.
• Consejo: usa imágenes con base alpine cuando sea posible; son mucho más ligeras y reducen el tamaño final.

Descarga la imagen node:18-alpine y muestra su sistema operativo y arquitectura usando una sola línea de salida (sin volcar todo el JSON de metadatos).

Explica con tus palabras por qué puedes ejecutar diez contenedores de la misma imagen sin que el espacio en disco se multiplique por diez. Menciona la capa de escritura y las capas de solo lectura.

Tienes las imágenes nginx y nginx:latest. Sin descargar nada nuevo, razona si necesariamente son imágenes distintas o podrían ser la misma, y explica por qué.

Solución 1

docker pull descarga la imagen y docker image inspect -f '{{.Os}}/{{.Architecture}}' muestra únicamente el sistema operativo y la arquitectura (por ejemplo, linux/amd64), gracias a la plantilla de formato que filtra el resto de metadatos.

Solución 2

Todos los contenedores creados a partir de la misma imagen comparten sus capas de solo lectura, que se almacenan una única vez en disco. Lo único exclusivo de cada contenedor es su capa de escritura, donde se guardan los cambios que ese contenedor realiza. Por eso diez contenedores no ocupan diez veces el tamaño de la imagen: comparten la mayor parte y solo añaden su pequeña capa de escritura individual.

Solución 3

Podrían ser la misma imagen. Cuando escribes nginx sin tag, Docker asume nginx:latest, así que ambos nombres pueden referirse exactamente a la misma imagen (con el mismo ID). No son necesariamente distintas; de hecho, lo más probable es que apunten a la misma imagen.

En esta lección hemos profundizado en las imágenes de Docker: qué contienen, cómo se organizan en capas de solo lectura, por qué ese diseño hace a Docker eficiente, cómo el contenedor añade una capa de escritura efímera encima de la imagen, el papel de los tags para identificar versiones y cómo inspeccionar una imagen por dentro con docker image inspect y docker history. Ahora entiendes de verdad qué es esa "plantilla" a partir de la cual nacen los contenedores.

En la siguiente lección, Creando tu Primer Contenedor Docker, pondremos todo en práctica de principio a fin: ejecutaremos un contenedor paso a paso, exploraremos el modo interactivo y el modo detached, aprenderemos a mapear puertos y a nombrar contenedores, y montaremos un servidor Nginx accesible desde tu navegador.