Docker
Beneficios, costes y criterios para decidir cuándo Docker aporta valor.
Los contenedores no son valiosos por sí mismos. Aportan valor cuando convierten un entorno difícil de repetir en un artefacto y una configuración que pueden construirse, distribuirse y ejecutarse de forma consistente.
La pregunta correcta no es “¿Docker es una buena práctica?”, sino:
¿Qué variación, dependencia o dificultad operativa elimina en este sistema, y qué nuevas responsabilidades introduce?
Docker suele mejorar la entrega cuando varios ambientes deben ejecutar el mismo software, existen dependencias incompatibles o se necesita crear y destruir entornos con frecuencia. También puede ser una capa innecesaria cuando el problema ya está resuelto por una plataforma administrada o el sistema es demasiado simple para justificarla.
Una aplicación no está formada únicamente por su código fuente. Su comportamiento también depende de:
Cuando esos elementos se configuran manualmente, el conocimiento queda repartido entre documentación, scripts, memoria del equipo y estado histórico de cada máquina.
Imagina una API Node.js que necesita Node 22, una versión concreta de libc, PostgreSQL y Redis. Sin una estrategia reproducible, cada desarrollador debe instalar y mantener todo eso. CI necesita otra preparación. Producción necesita una tercera. Aunque las instrucciones sean iguales, los resultados pueden diferir por actualizaciones, archivos residuales o configuración previa.
Docker permite describir una parte de ese entorno como código:
source + lockfiles + Dockerfile
→ image versionada
→ misma unidad de ejecución en desarrollo, CI y producciónEsto no significa que todos los ambientes sean idénticos. El kernel, recursos, secretos, red y servicios externos pueden cambiar. La ventaja es que el artefacto principal deja de reconstruirse manualmente en cada destino.
Una imagen fija un filesystem y metadata de ejecución. Si el mismo digest se ejecuta en dos hosts compatibles, ambos parten del mismo artefacto.
La reproducibilidad no es absoluta. Una aplicación todavía puede variar por environment, arquitectura, servicios externos, tiempo, red o recursos. Docker reduce una categoría de variación: la preparación interna del runtime.
Dos aplicaciones pueden usar versiones distintas de Node, Python o librerías del sistema sin instalarlas globalmente en el host.
host
├── container API A → Node 20
├── container API B → Node 22
└── container worker → Python 3.13El aislamiento no equivale a seguridad total. Los procesos siguen compartiendo el kernel y pueden recibir mounts o privilegios peligrosos.
Una imagen puede etiquetarse, publicarse y referenciarse por digest. Esto permite saber qué artefacto se desplegó y volver a uno anterior.
commit abc123
→ image registry/app:1.8.0
→ digest sha256:...
→ staging
→ productionUn rollback confiable reutiliza un digest ya probado. Reconstruir una versión antigua durante el incidente puede producir un artefacto distinto.
CI puede levantar una aplicación y sus dependencias, ejecutar pruebas y destruir todo después.
docker compose up -d --wait
npm run test:e2e
docker compose down -vEsto reduce dependencia de servidores de prueba compartidos y estados acumulados. Sin embargo, las pruebas solo son útiles si las imágenes y configuración representan realmente el entorno objetivo.
Un desarrollador nuevo puede iniciar varios servicios con menos instalación global. Esto reduce tiempo inicial, pero no elimina la necesidad de comprender el sistema. Un equipo que solo sabe ejecutar docker compose up seguirá teniendo problemas cuando red, permisos o datos fallen.
El build produce un artefacto. El runtime inyecta configuración y recursos.
build una vez
→ image
→ ejecutar con configuración de desarrollo
→ ejecutar con configuración de staging
→ ejecutar con configuración de producciónEsta separación mejora trazabilidad y evita compilar una variante diferente por ambiente.
Docker no elimina complejidad; la redistribuye.
Debes elegir base images, actualizar dependencias, corregir vulnerabilidades, gestionar cache y garantizar compatibilidad.
Una imagen que funcionaba hace meses puede contener paquetes obsoletos aunque el código no haya cambiado. Mantener imágenes implica reconstrucciones periódicas y pruebas.
Las imágenes necesitan almacenamiento, autenticación, retención, escaneo y trazabilidad. Debes decidir quién puede publicar, qué artefactos son confiables y qué ocurre si el registry no está disponible.
El contenedor es reemplazable, pero los datos no siempre lo son. Databases, uploads y colas requieren volumes o servicios externos, backups, restore y capacidad.
Ahora existen al menos dos perspectivas: red del host y red del contenedor. localhost cambia de significado, aparecen DNS interno, publicaciones de puertos y firewalls.
Un fallo puede estar en:
contexto CLI
→ daemon
→ build
→ image
→ configuración de runtime
→ proceso
→ network
→ mount
→ aplicaciónDocker facilita reproducir entornos, pero añade nuevas capas que el equipo debe saber observar.
Debes proteger daemon, socket, images, secrets, mounts, capabilities, usuarios y kernel. Ejecutar una aplicación insegura dentro de Docker no la vuelve segura.
Una API depende de PostgreSQL, Redis y un worker. Compose puede describir versiones, redes y volúmenes en un proyecto reproducible.
Windows, macOS y Linux pueden trabajar sobre imágenes Linux mediante Docker Desktop o Engine. Persisten diferencias de filesystem y rendimiento, pero se reduce la instalación específica del stack.
Las pruebas necesitan PostgreSQL o RabbitMQ reales. Los contenedores permiten crear dependencias aisladas por ejecución.
Una aplicación se despliega en VMs o servidores propios. La imagen sirve como unidad de entrega en lugar de copiar código y ejecutar instalación remota.
Dos proyectos requieren versiones distintas de runtime o paquetes nativos. Los contenedores evitan que compartan una instalación global.
El negocio necesita identificar y restaurar rápidamente una versión aprobada. Un digest inmutable ofrece una referencia concreta.
Una plataforma que recibe el repositorio y publica archivos ya resuelve build y distribución. Mantener Docker puede no aportar valor al equipo.
La plataforma controla runtime, escalado y despliegue. Empaquetar una imagen personalizada solo tiene sentido si se necesita una dependencia o control que el runtime estándar no ofrece.
Un script con una dependencia y uso individual puede ser más sencillo con un entorno del lenguaje. Docker añade daemon, imagen, mounts y comandos sin eliminar un problema real.
Acceso a GUI, dispositivos, audio o servicios nativos puede volver la containerización incómoda o poco portable.
Adoptar Docker para “modernizar” sin responsables de seguridad, backups, actualizaciones y diagnóstico puede empeorar la confiabilidad.
| Aspecto | Instalación local | Contenedores |
|---|---|---|
| Dependencias | Instaladas en host o entorno del lenguaje | Incluidas en image y runtime |
| Inicio | Puede ser más simple para un proyecto pequeño | Requiere Engine, build o pull |
| Aislamiento | Depende de herramientas del lenguaje | Filesystem, procesos y red aislados |
| Persistencia | Filesystem normal del host | Debe diseñarse con volumes o servicios externos |
| Distribución | Instrucciones o instalador | Image en registry |
| Diagnóstico | Menos capas | Más aislamiento, pero más fronteras |
La elección no es universal. Un proyecto puede usar instalación local para desarrollo frontend y contenedores para servicios backend o CI.
Sin contenedores, cada persona instala tres servicios y mantiene puertos, versiones y datos. Con Compose:
services:
api:
build: .
environment:
DATABASE_URL: postgres://app:app@db:5432/app
REDIS_URL: redis://cache:6379
ports:
- "3000:3000"
depends_on:
db:
condition: service_healthy
db:
image: postgres:17
environment:
POSTGRES_USER: app
POSTGRES_PASSWORD: app
POSTGRES_DB: app
volumes:
- db-data:/var/lib/postgresql/data
healthcheck:
test: ["CMD-SHELL", "pg_isready -U app -d app"]
interval: 5s
timeout: 3s
retries: 10
cache:
image: redis:8
volumes:
db-data:El beneficio no es el YAML. El beneficio es que versiones, DNS, almacenamiento y arranque quedan declarados.
El ejemplo sigue teniendo límites:
depends_on no garantiza disponibilidad futura.Puede depender de una API externa, una zona horaria o datos variables. Docker fija el artefacto, no todo el universo de ejecución.
Una image solo amd64 puede ejecutarse mediante emulación en ARM, con coste o incompatibilidad. Las imágenes multi-platform reducen este problema.
Un host que ya tiene la image puede arrancar; uno nuevo puede no hacer pull. La disponibilidad del registry forma parte del diseño de despliegue.
Ningún comando de runtime funciona. Debes distinguir fallo de aplicación de fallo del Engine.
Docker no administra automáticamente capacidad de datos. El host puede quedarse sin disco aunque los contenedores sigan running.
Consecuencia: más archivos, tooling y mantenimiento sin mejora medible.
Detección: nadie puede explicar qué variación o proceso se simplificó.
Corrección: documentar el caso de uso y comparar con alternativas más simples.
Una image Linux no contiene kernel y puede depender de arquitectura o capacidades del host.
Corrección: declarar plataformas soportadas y probarlas.
restart: always puede recuperar un proceso, pero no un host perdido ni una dependencia caída.
Corrección: definir SLO, redundancia y failover según el riesgo.
Instalar paquetes o editar archivos dentro de producción rompe reproducibilidad.
Corrección: cambiar Dockerfile, reconstruir y desplegar una nueva image.
Antes de adoptar Docker, responde:
Contenedores frente a máquinas virtuales, para entender qué se aísla realmente y por qué ambos modelos suelen combinarse.