Docker
Montajes del host, desarrollo local, permisos y datos temporales.
Un bind mount conecta una ruta concreta del host con una ruta del contenedor. Un tmpfs crea almacenamiento temporal respaldado por memoria. Ambos cruzan la frontera de la writable layer, pero tienen propósitos y riesgos diferentes.
bind mount → path real del host
volume → almacenamiento administrado por Docker
tmpfs → memoria temporalLa elección no debe basarse solo en sintaxis. Debe considerar lifecycle, portabilidad, seguridad, rendimiento, ownership y recuperación.
docker run --rm \
--mount type=bind,src="$PWD",dst=/app \
node:22-slimEl contenedor ve el contenido del directorio actual en /app. Las escrituras se reflejan directamente en el host.
El contenedor depende de:
Esto reduce portabilidad frente a un volume o artefacto incorporado en la image.
Forma explícita:
docker run --mount type=bind,src=/host/path,dst=/container/path,readonly imageForma corta:
docker run -v /host/path:/container/path:ro image--mount hace visibles tipo, source, destination y opciones, y evita algunos comportamientos implícitos de creación de paths. Para documentación y producción suele ser más claro.
docker run \
--mount type=bind,src=/etc/my-api/config.yaml,dst=/app/config.yaml,readonly \
my-apiReduce modificaciones accidentales o maliciosas al archivo del host.
Read-only no significa confidencial: el proceso todavía puede leer y exfiltrar el contenido. Aplica permisos mínimos también en el host.
Un proceso comprometido puede:
Montar /, /etc, /proc, devices o directorios sensibles puede romper el aislamiento. Nunca utilices mounts amplios solo para “hacer que funcione”.
docker run -v /var/run/docker.sock:/var/run/docker.sock toolEsto entrega acceso a la API del daemon. Un proceso puede solicitar containers privilegiados y montar el host. Debe tratarse como capacidad administrativa, no como un bind mount ordinario.
Alternativas:
Un bind mount conserva ownership numérico del host.
Problema común:
host user UID 501
container user UID 1000
→ permission denied o archivos con dueño inesperadoEn Linux puedes alinear UID/GID o ajustar permisos. En Docker Desktop existe traducción adicional de filesystem.
No ejecutes todo como root para resolverlo. Define:
En hosts con SELinux, el label del path puede impedir acceso aunque los permisos Unix parezcan correctos. Opciones de relabel pueden existir en la sintaxis corta según plataforma.
Cambiar labels tiene impacto fuera del container. Comprende la política y evita aplicar opciones al azar en paths compartidos críticos.
Compose:
services:
app:
image: node:22-slim
working_dir: /app
command: npm run dev
volumes:
- .:/app
- node-modules:/app/node_modules
volumes:
node-modules:El source se monta desde el host, pero node_modules Linux vive en un volume.
Esto evita:
Si la image contiene /app/node_modules y montas .:/app, el bind mount cubre todo /app. Los módulos dejan de ser visibles.
El contenido no fue eliminado; quedó oculto. Un volume separado en /app/node_modules puede restablecer una capa independiente.
Este comportamiento explica muchos fallos de “funciona sin volume, falla con Compose”.
En macOS/Windows, el bind cruza host y VM. Workloads con muchos archivos pequeños pueden ser lentos:
Estrategias:
En Compose, los paths relativos se resuelven respecto al proyecto/configuración según reglas de Compose. En CLI se resuelven en el shell antes de enviarse.
Con un daemon remoto, el source del bind debe existir en el host del daemon. Tu $PWD local no se transfiere automáticamente.
docker run \
--tmpfs /tmp:rw,noexec,nosuid,size=64m \
my-apiLos datos:
/tmp con root filesystem read-only;size: límite;noexec: evita ejecutar binarios desde el mount;nosuid: ignora bits setuid;nodev: evita devices cuando esté disponible;mode, uid, gid: permisos iniciales según soporte.Un restart de la misma instancia puede tener comportamiento diferente según operación y runtime, pero debes diseñarlo como temporal y descartable. La pérdida del host o recreación elimina el contenido.
No guardes:
Tmpfs consume memoria. Sin límite, un proceso puede llenar capacidad y provocar OOM.
Monitorea:
docker statsLa contabilidad exacta depende del kernel y cgroups. Prueba el workload real.
Tmpfs reduce persistencia en disco, pero no evita:
Es una capa, no un vault.
| Criterio | Bind mount | Volume | Tmpfs |
|---|---|---|---|
| Source | Path del host | Docker/driver | Memoria |
| Persistencia | Según host path | Separada del container | No durable |
| Portabilidad | Baja/media | Media | Media |
| Uso principal | Integración con host | Datos persistentes | Temporales |
| Riesgo clave | Modificar host | Pérdida/backup | Memoria/OOM |
docker run -d \
--read-only \
--mount type=bind,src=/etc/my-api/config.yaml,dst=/app/config.yaml,readonly \
--mount type=volume,src=uploads,dst=/app/uploads \
--tmpfs /tmp:rw,noexec,nosuid,size=64m \
my-apiCada path tiene un propósito:
/tmp: temporal;--mount suele fallar claramente. Verifica path en el host del daemon.
Revisa UID/GID, modo, SELinux, rootless mapping y read-only.
El mount los está cubriendo.
Puede intervenir sincronización de Desktop, watcher, caching o path equivocado.
Revisa límite, tamaño de archivos y memoria total.
Consecuencia: source mutable y host acoplado.
Corrección: incorporar artefacto en image.
Consecuencia: permisos, rendimiento o corrupción.
Corrección: volume/driver soportado y pruebas.
Consecuencia: control administrativo del host.
Corrección: eliminar o aislar la capacidad.
Consecuencia: presión de memoria.
Corrección: size y observabilidad.
Consecuencia: privilegios excesivos.
Corrección: ownership explícito.
.:/app puede ocultar node_modules de la image?/etc?Networking de Docker, donde se estudian namespaces, interfaces, rutas, DNS y comunicación entre servicios.