Docker
Copy-on-write, almacenamiento efímero y consecuencias operativas.
El filesystem visible dentro de un contenedor no es un disco independiente. Es una vista compuesta por las capas read-only de la imagen, una capa writable propia de la instancia y cualquier mount aplicado sobre rutas concretas.
image layers read-only
+ container writable layer
+ volumes, bind mounts o tmpfs
= filesystem visible dentro del containerEsta composición explica por qué un archivo puede existir dentro de un contenedor, desaparecer al recrearlo o quedar oculto cuando se monta un volumen sobre su ruta.
Las imágenes deben poder compartirse entre muchas instancias sin duplicar todo su contenido ni permitir que un contenedor modifique el artefacto original.
Si cada contenedor copiara por completo la imagen:
Docker utiliza una estrategia de capas y copy-on-write. Las capas de la imagen permanecen inmutables y compartidas. Cada contenedor recibe una capa de cambios separada.
Supón que una imagen contiene:
/etc/app/config.json
/app/server.js
/app/node_modules/Al crear dos contenedores:
image read-only
├── writable layer de api-1
└── writable layer de api-2Si api-1 modifica /etc/app/config.json, Docker no cambia el archivo de la imagen. La versión modificada aparece en la writable layer de api-1. api-2 continúa viendo la versión original.
Cuando Docker resuelve una lectura:
Copy-on-write significa que el contenido compartido se copia únicamente cuando una instancia necesita modificarlo.
Flujo simplificado:
lectura de archivo de la image
→ usar layer read-only directamente
modificación del archivo
→ copiar contenido a writable layer
→ aplicar cambio sobre la copia
→ futuras lecturas usan la copia superiorEste mecanismo ahorra espacio para workloads que leen mucho y modifican poco. Sin embargo, puede introducir coste cuando se actualizan archivos grandes o se realizan muchas escrituras pequeñas.
El archivo se guarda en la writable layer.
docker run --name demo alpine sh -c 'echo hola > /message && sleep 300'El storage driver realiza la operación necesaria para que la versión modificada exista en la capa writable.
La capa inferior no se modifica. Se registra que ese path debe ocultarse en la vista combinada.
Según el filesystem y driver, puede implicar copias y operaciones adicionales. No asumas que mover un archivo grande dentro del contenedor siempre es una operación barata.
La writable layer existe mientras exista el objeto del contenedor.
docker stop demo
docker start demoDespués de detener e iniciar la misma instancia, sus cambios continúan porque la writable layer sigue asociada al objeto.
Pero al eliminar y recrear:
docker rm -f demo
docker run --name demo alpine ...la nueva instancia recibe otra writable layer. Los archivos de la anterior desaparecieron.
La diferencia práctica es:
restart
→ misma instancia
→ misma writable layer
recreate
→ nueva instancia
→ nueva writable layerEsto explica por qué una aplicación puede “perder datos” durante un deployment aunque un simple restart pareciera conservarlos.
Es apropiada para estado temporal y reemplazable:
Incluso ese contenido debe tener límites. Un cache sin control puede llenar el disco del host.
No debe ser la única copia de:
Estos datos necesitan volumes, bind mounts, object storage, databases o servicios externos según el caso.
Un volume no vuelve mágicamente distribuido o altamente disponible el estado. Solo lo separa del lifecycle del contenedor.
Si la imagen contiene archivos en /app/data y montas un volume vacío:
docker run --mount type=volume,src=app-data,dst=/app/data my-appel mount cubre la ruta. El proceso ve el contenido del volume, no directamente el contenido inferior de la imagen.
Dependiendo del tipo de volume y comportamiento de Docker, puede existir copia inicial de contenido en ciertos escenarios. No bases migrations o inicialización crítica en un comportamiento que no hayas verificado.
Un error frecuente es creer que los archivos fueron eliminados de la imagen cuando en realidad quedaron ocultos por el mount.
La writable layer es adecuada para muchas aplicaciones, pero no siempre para escrituras intensivas.
El coste puede venir de:
Una database que modifica continuamente páginas de datos suele funcionar mejor con almacenamiento diseñado y probado para ese workload.
No concluyas “Docker es lento” sin medir:
aplicación
→ filesystem del container
→ mount o writable layer
→ storage driver
→ filesystem del host
→ disco físico o virtualDocker puede usar distintas implementaciones para snapshots y filesystem por capas. En Linux, conceptos como OverlayFS han sido comunes; versiones recientes también pueden usar el image store de containerd según instalación y configuración.
La abstracción importante permanece:
No manipules manualmente paths internos como /var/lib/docker. Su estructura depende del driver, versión y configuración, y modificarla puede corromper metadata.
Para reducir modificaciones accidentales o maliciosas:
docker run --read-only my-apiEl root filesystem visible deja de aceptar escrituras. La aplicación puede necesitar paths escribibles específicos:
docker run \
--read-only \
--tmpfs /tmp:rw,noexec,nosuid,size=64m \
my-apiTambién pueden montarse volumes para rutas durables.
Beneficios:
No impide todas las modificaciones. Un proceso puede escribir en mounts permitidos, memoria, red o servicios externos. Es una capa de defensa, no una sandbox completa.
Escribir logs únicamente en /var/log/app.log dentro de la writable layer crea varios problemas:
docker logs no los ve automáticamente;Para aplicaciones modernas, suele preferirse stdout/stderr y un logging driver o collector con rotación y centralización.
Puede existir un caso válido para archivos de log específicos, pero entonces el mount, rotación, ownership y recolección deben diseñarse explícitamente.
Una API guarda imágenes en:
await writeFile(`/app/uploads/${fileName}`, buffer);Funciona durante días. Luego se despliega una nueva versión recreando el contenedor. Los archivos desaparecen.
/app/uploads pertenecía a la writable layer de la instancia anterior.
Un named volume puede resolver persistencia local, pero si existen varias réplicas en hosts diferentes, cada host podría tener datos distintos. La arquitectura debe coincidir con disponibilidad y escalado requeridos.
Una aplicación descarga modelos o dependencias en /app/cache.
Si la cache puede regenerarse:
Si reconstruirla cuesta horas o depende de una fuente inestable, puede convenir un volume o cache externo. El criterio es el coste y garantía requerida, no solo “es un archivo”.
La writable layer comparte capacidad con otros recursos del Engine. Un contenedor que genera archivos sin límite puede impedir pulls, builds y logging de otros workloads.
Diagnóstico:
docker system df -v
df -h
df -iMuchos archivos pequeños pueden agotar inodes aunque existan gigabytes libres.
Eliminar o truncar contenido puede no liberar inmediatamente lo esperado si una capa inferior o un proceso mantiene el descriptor abierto.
El contenido inferior queda oculto. Retirar el mount puede hacerlo visible nuevamente.
UID y GID dentro del contenedor deben tener acceso. Un mount puede introducir ownership diferente al esperado.
Bind mounts que cruzan host y VM pueden tener comportamiento y rendimiento diferente a volumes internos.
Consecuencia: pérdida al recrear.
Detección: docker inspect no muestra un mount en el data directory.
Corrección: identificar el directorio soportado, crear persistencia y probar backup/restore.
Consecuencia: el problema aparece solo durante replacement.
Corrección: probar explícitamente remove + create.
Consecuencia: disco lleno e incidentes opacos.
Corrección: stdout/stderr, rotación, límites y centralización.
Consecuencia: se pierde hardening sin entender la dependencia.
Corrección: identificar paths legítimos y suministrar tmpfs o mounts mínimos.
Consecuencia: backup inconsistente y dependiente de implementación.
Corrección: usar herramientas de la aplicación o mecanismos soportados para volumes y datos.
docker run -d --name fs-demo alpine sh -c 'echo hola > /message && sleep 300'
docker exec fs-demo cat /message
docker restart fs-demo
docker exec fs-demo cat /message
docker rm -f fs-demo
docker run --rm alpine sh -c 'cat /message || echo no-existe'docker volume create demo-data
docker run --rm \
--mount type=volume,src=demo-data,dst=/data \
alpine sh -c 'echo persistente > /data/message'
docker run --rm \
--mount type=volume,src=demo-data,dst=/data \
alpine cat /data/messagedocker diff <container>Muestra paths añadidos, modificados o eliminados desde la perspectiva del contenedor. Es útil para detectar escrituras inesperadas, aunque no reemplaza observabilidad completa.
docker restart pero no a remove + create?--read-only además de aportar seguridad?/var/lib/docker?Dockerfile: fundamentos, donde se define de manera reproducible qué contenido y metadata terminarán formando la imagen.