Una imagen de Docker es una plantilla inmutable de solo lectura que contiene el todo lo necesario para que una aplicación se ejecute de forma aislada.
Es decir, una imagen de Docker es una “foto” estática de como estaba tu aplicación. Contiene todo lo necesario, incluyendo el código, las librerías, las dependencias, las herramientas y las configuraciones.
La palabra clave del artículo es INMUTABLE (Solo Lectura). Una vez que una imagen ha sido creada, no se puede cambiar.
Si quieres modificar algo de una imagen, no la editas: creas una imagen nueva con el cambio.
Las imágenes de Docker son las plantillas que se utilizan para crear contenedores de Docker. Con una imagen se puede utilizar para crear múltiples contenedores de Docker.
Vamos a profundizar en el concepto y entender por qué estas “plantillas” son la base tus de los contenedores 👇.
El sistema de capas
Si una imagen fuera simplemente un bloque monolítico de datos (como una ISO de 2GB), Docker sería lentísimo. Cada vez que actualizaras una pequeña librería, tendrías que volver a descargar los 2GB.
Para solucionar esto, Docker utiliza una arquitectura de Capas (Layers).
Imagina una imagen de Docker no como un solo archivo, sino como una pila de transparencias (como las capas de Photoshop).
Cada capa representa un cambio en el sistema de archivos:
Capa Base: Pone un Ubuntu básico.
Capa 2: Instala Python encima.
Capa 3: Copia tu código fuente app.py.
Capa 4: Define el comando de inicio.
Cuando Docker “mira” la imagen, superpone todas estas transparencias y tú ves el resultado final combinado.
La reutilización del almacenamiento
Aquí está la base (y la gracia) del sistema. Las capas son compartidas. Por ejemplo, la imagina que tienes dos aplicaciones diferentes en tu ordenador:
- App A: Usa Ubuntu + Python + Django.
- App B: Usa Ubuntu + Python + Flask.
En un sistema de máquinas virtuales tradicional, tendrías dos copias de Ubuntu y dos copias de Python. Ocupando el doble de espacio.
En Docker, ambas imágenes comparten las capas de “Ubuntu” y “Python”. Solo se almacenan una vez en tu disco duro. Docker es lo suficientemente listo para saber que son idénticas (usando un hash SHA256) y las reutiliza.
Es uno de los motivos por los que son de solo lectura. Si las app pudieran modificar las capas sobre las que levantan, podrían romper algo, o ser un riesgo de seguridad.
Ninguna App (ni la tuya) puede modificar tocar tu “capa Ubuntu” o tu “capa Python”. Podemos poner capas encima, pero las de abajo están selladas.
Imagen vs Contenedor: La capa de escritura
Si hemos dicho que las imágenes son de solo lectura (Read-Only), ¿cómo es posible que un contenedor pueda escribir logs, crear archivos temporales o guardar datos?
Porque cuando haces un docker run, Docker toma la pila de capas de la imagen (que son intocables) y añade una capa extra vacía justo encima.
Esta es la Container Layer (Capa del Contenedor) y es la única que es Read-Write (Lectura/Escritura).
Cuando borras un contenedor (docker rm), lo único que se elimina es esa fina capa superior de escritura. Las capas de la imagen subyacente permanecen intactas en tu disco para que puedas crear otros contenedores con ellas.
Viéndolo en acción
Vamos a ver esto en la terminal. Cuando te bajaste la imagen de nginx en el capítulo anterior, seguramente viste algo así:
$ docker pull nginx Using default tag: latest latest: Pulling from library/nginx a2abf6c4d29d: Pull complete a9edb18c7728: Pull complete 3e731ddb2164: Pull complete …
¿Ves esos códigos raros (a2abf6...)? Esas son las capas. Docker se está bajando la imagen trozo a trozo.
Si ahora intentas bajar otra versión de Nginx u otra aplicación basada en la misma versión de Debian que usa Nginx, verás que en algunas líneas dice:
a2abf6c4d29d: Already exists
No lo descarga, reutiliza el bloque que ya tenía.
Por eso, la primera vez que descargas una imagen tarda un poco. La segunda vez, si comparte la base con alguna que ya tienes, es casi instantáneo.
