Docker está diseñado para promover aplicaciones Stateless (sin estado). La idea es que un contenedor sea algo desechable.
Es decir, deberías poder borrar tu contenedor en cualquier momento, lanzarlo de nuevo y que todo siga funcionando igual.
Este es uno de los conceptos más importantes de Docker (incluso el que más). Para entenderlo, tenemos que volver a mirar cómo está construido un contenedor por dentro 👇.
Recordando las capas
Cuando vimos en el capítulo de Imágenes, dijimos que una imagen de Docker es un conjunto de capas de solo lectura apiladas una encima de otra.
Las imágenes son inmutables. Una vez creadas, no se pueden cambiar.
Esto es lo que permite que sean reaprovechables, entre una instancia y otra. Y lo que hace que sea un sistema tan eficiente.
Pero un sistema, una aplicación, casi siempre necesita “hacer cosas”. Es decir, tocar ficheros, crear cosas…
Si la imagen es de solo lectura… ¿cómo es posible que pueda escribir archivos dentro de un contenedor?
La capa del contenedor (Read-Write Layer)
Cuando ejecutas docker run, Docker toma las capas de la imagen y añade una fina capa extra encima del todo.
Esta es la Container Layer y es la única capa, es de lectura y escritura.
Cualquier cambio que hagas en el contenedor (crear un archivo, modificar una configuración, guardar un registro en la BD) se escribe exclusivamente en esta capa superior.
La imagen original (las capas de abajo) nunca se toca. Permanece inmaculada.
El ciclo de vida de los datos
La capa de escritura está ligada al ciclo de vida del contenedor.
Vamos a ver los tres estados:
Contenedor Corriendo (Up): Puedes escribir datos. Se guardan en la capa R/W.
Contenedor Parado (Exited): Haces un docker stop. El contenedor se apaga, pero la capa de escritura sigue ahí. Si vuelves a hacer docker start, tus datos seguirán ahí.
¡Importante! Parar un contenedor NO borra los datos.
Contenedor Borrado (Removed): Haces un docker rm. Aquí es donde ocurre la tragedia. Al destruir el contenedor, Docker destruye también su capa de escritura.
Así que cuando paras un contenedor, todo lo que hubieras escrito en esa capa se borra instantáneamente (la base de datos nueva, los logs, los archivos subidos) .
El Problema: Necesitamos persistencia
Que los contenedores sean inmutables es muy interesante. Una teoría muy bonita, y parte del funcionamiento básico del sistema.
Pero como ya te habrás empezado a preguntar, en el mundo real, necesitamos guardar cosas:
- Una base de datos necesita recordar los clientes.
- Un servidor web necesita guardar las imágenes que suben los usuarios.
Si no podemos guardar los datos dentro del contenedor porque desaperecen con él… ¿dónde los guardamos?
Necesitamos un mecanismo para “sacar” esos datos fuera del contenedor y guardarlos en nuestro ordenador (Host), de forma que sobrevivan aunque el contenedor explote.
Docker nos ofrece dos soluciones principales para esto:
- Volúmenes (Volumes): La opción gestionada por Docker.
- Bind Mounts: Mapear carpetas de nuestro PC (ideal para desarrollo).
En el próximo artículo vamos a ver la solución recomendada para bases de datos: Los Volúmenes.
