Docker
Modelo mental inicial de Docker, sus componentes y el problema que resuelve.
Docker permite empaquetar una aplicación como una imagen inmutable y ejecutarla como un , es decir, como uno o varios procesos aislados que comparten el kernel del host.
La diferencia importante no está solamente en “meter una app en una caja”. Docker intenta convertir la preparación del entorno en un proceso repetible:
código fuente
+ dependencias
+ instrucciones de construcción
→ imagen versionada
→ contenedor configurado
→ proceso ejecutándoseUna imagen responde principalmente qué debe ejecutarse. El contenedor representa una instancia concreta en ejecución, con variables, red, mounts, límites y permisos propios.
Antes de usar contenedores, una aplicación suele depender de preparación manual:
Ese proceso produce variación. Dos máquinas que parecen iguales pueden tener versiones distintas, archivos residuales o configuraciones no documentadas. El conocido “funciona en mi máquina” normalmente significa que la aplicación depende de características del entorno que nunca fueron declaradas.
Docker no elimina todas las diferencias, pero mueve una parte importante de ellas hacia artefactos y configuración explícita. El Dockerfile documenta la construcción; la imagen conserva el resultado; el runtime define cómo se ejecuta.
Piensa en una imagen como una plantilla de solo lectura y en un contenedor como una instancia temporal creada a partir de esa plantilla.
Dockerfile
↓ build
Image my-api:1.0
├── Container api-1
├── Container api-2
└── Container job-42Los tres contenedores pueden compartir las capas de la misma imagen, pero cada uno tiene:
Modificar un contenedor no modifica automáticamente la imagen. Cuando ese contenedor se elimina, los cambios realizados en su capa writable desaparecen, salvo que se hayan guardado en un volume o en un servicio externo.
Un contenedor Linux no es una máquina virtual pequeña. Es un conjunto de procesos normales del host a los que el kernel presenta una vista aislada de ciertos recursos.
Los mecanismos principales son:
Los namespaces hacen que un proceso vea una versión aislada de recursos como:
Por ejemplo, el proceso principal puede verse a sí mismo como PID 1 dentro del contenedor, aunque en el host tenga otro PID.
Los cgroups contabilizan y limitan recursos como CPU, memoria y cantidad de procesos. El aislamiento no implica automáticamente límites: un contenedor sin restricciones puede competir por gran parte de la capacidad del host.
La imagen aporta capas read-only. Encima se añade una capa writable específica del contenedor. Volumes y bind mounts pueden reemplazar rutas concretas del filesystem visible.
Linux divide muchos privilegios de root en capabilities. Docker puede eliminar capacidades, aplicar seccomp y trabajar con AppArmor o SELinux. Estas medidas reducen lo que un proceso comprometido puede hacer, pero no convierten el contenedor en una frontera absoluta.
Es la descripción de cómo construir una imagen. Incluye la base, archivos, dependencias, usuario y comando de arranque.
Es un artefacto inmutable compuesto por capas de filesystem y metadata. Puede identificarse mediante tags legibles y digests basados en contenido.
Es una instancia creada desde una imagen más configuración de runtime. Su lifecycle depende de su proceso principal.
Almacena y distribuye imágenes. Docker Hub, GitHub Container Registry y registries privados cumplen esta función.
Persiste datos fuera de la capa writable del contenedor. Su lifecycle puede continuar aunque el contenedor sea reemplazado.
Controla cómo se comunican los contenedores entre sí, con el host y con sistemas externos.
Permite describir varios servicios, redes y volúmenes en un archivo declarativo para operar la aplicación como un proyecto.
Supón una API Node.js con este Dockerfile:
FROM node:22-slim
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci --omit=dev
COPY server.js ./
USER node
CMD ["node", "server.js"]Se construye la imagen:
docker build -t my-api:1.0 .Durante el build ocurre, de forma simplificada:
my-api:1.0.Luego se crea y ejecuta un contenedor:
docker run --rm -p 3000:3000 my-api:1.0El runtime:
node server.js como proceso principal;--rm indica que el contenedor debe eliminarse cuando termine. -p 3000:3000 publica el puerto 3000 del contenedor en el puerto 3000 del host.
Una aplicación real puede tener:
navegador
↓ localhost:3000
API container
↓ db:5432
PostgreSQL container
↓
volume db-dataLa API y PostgreSQL se ejecutan como contenedores diferentes porque tienen lifecycle, dependencias y responsabilidades distintas. La base de datos usa un volume porque sus datos deben sobrevivir al reemplazo del contenedor.
La API no conecta a localhost:5432: dentro del contenedor, localhost significa el propio contenedor. Se conecta al nombre DNS del servicio, por ejemplo db.
Docker ayuda a conseguir:
Docker no garantiza por sí solo:
Una aplicación mal diseñada sigue estando mal diseñada dentro de un contenedor.
El contenedor también termina. Esto puede ocurrir por configuración inválida, archivos faltantes o porque se lanzó una tarea que finaliza en lugar de un servidor persistente.
Diagnóstico:
docker ps -a
docker logs <container>
docker inspect <container>Puede escuchar solo en 127.0.0.1 dentro del contenedor, no tener el puerto publicado o estar enlazada a otro puerto.
Probablemente estaban en la writable layer. La corrección es decidir qué estado debe persistir y moverlo a un volume o servicio externo.
Puede existir una diferencia de arquitectura, por ejemplo amd64 frente a arm64, o una dependencia del host que nunca se incluyó realmente.
Root dentro del contenedor no siempre equivale a root sin restricciones en el host, pero aumenta el impacto potencial. Debe usarse un usuario no privilegiado salvo necesidad justificada.
Normalmente no. Los contenedores Linux comparten el kernel del host. Docker Desktop utiliza una VM Linux en macOS y Windows para disponer de ese kernel.
No. La modificación vive en la capa writable de esa instancia. Crear otro contenedor desde la misma imagen no incluye esos cambios.
No. EXPOSE documenta intención. La publicación ocurre con opciones de runtime como -p o mediante Compose.
No necesariamente. Mounts peligrosos, capabilities excesivas, --privileged, acceso al Docker socket o vulnerabilidades del kernel pueden ampliar el riesgo.
Docker suele aportar valor cuando:
Puede ser complejidad innecesaria para:
La decisión no debe ser “Docker es moderno”, sino “¿qué variación, aislamiento o problema de entrega elimina en este sistema?”.
Ejecuta este laboratorio:
docker run --name demo alpine sh -c 'echo hello > /tmp/message && sleep 60'
docker exec demo cat /tmp/message
docker rm -f demo
docker run --rm alpine sh -c 'cat /tmp/message || echo no-existe'El segundo contenedor no encuentra el archivo porque cada instancia tiene su propia writable layer. Luego repite usando un volume para observar la diferencia.
Por qué usar contenedores, donde se evalúa cuándo este modelo aporta valor y cuándo introduce más complejidad de la que elimina.