La maldición de Docker
Desarrolladores y operadores sopesan los beneficios de Docker para simplificar el despliegue frente a su papel creciente como una herramienta bruta de empaquetado para software de servidor. Muchos elogian los contenedores por las configuraciones reproducibles, la experimentación más sencilla y la reducción de los problemas de “funciona en mi máquina”, pero critican la procedencia de las imágenes, la configuración opaca, la seguridad por defecto basada en root y la carga de parchear muchos sistemas base separados. Se plantean alternativas como los paquetes tradicionales de distribución, Nix, las VMs y prácticas de contenedorización más disciplinadas como formas de recuperar el control sobre las dependencias y el mantenimiento a largo plazo.
Alcance de la crítica: Docker como distribución vs despliegue
- Muchos comentaristas dicen que el artículo trata realmente de Docker siendo mal usado como mecanismo de distribución (como un formato de paquete), no de los contenedores para despliegue.
- Queja: enviar solo una imagen de Docker (o una pila de
docker-compose) oculta dependencias y dificulta la integración con infra existente (bases de datos, copias de seguridad, monitorización, autenticación, TLS). - Defensa: para aplicaciones complejas (por ejemplo, muchos servicios como BD, caché, colas),
docker compose upreduce drásticamente la barrera para probar y ejecutar software, especialmente para aficionados y equipos pequeños.
Confianza, procedencia y “imágenes aleatorias de Internet”
- Preocupación: la gente ejecuta imágenes de terceros con poca reflexión sobre mantenimiento, soporte, garantías de actualización, compatibilidad de arquitectura o disponibilidad a largo plazo.
- Algunos argumentan que las imágenes “oficiales” de organizaciones (por ejemplo, Bitnami, linuxserver.io) siguen siendo, en la práctica, binarios aleatorios de Internet a menos que tengas una relación comercial o garantías claras.
- Otros responden que todas las pilas de software implican confianza (distribuciones, hardware, nube), y los contenedores son solo otra capa de confianza.
Seguridad, root y actualizaciones
- Problema ampliamente señalado: ejecutar contenedores como root se ha normalizado, y hacer imágenes sin root/de solo lectura es engorroso, así que los valores predeterminados inseguros ganan.
- Se plantean dudas sobre cómo las organizaciones gestionan realmente las actualizaciones de seguridad de imágenes base y bibliotecas en muchos contenedores; algunos dicen que reconstrucciones en CI + escáneres y herramientas (p. ej., estilo Watchtower) hacen de esto un problema “resuelto”, mientras que otros dicen que en la práctica la mayoría no lo hace bien.
Configuración, sistemas de archivos y red
- Puntos de dolor frecuentes:
- Los montajes de archivos/volúmenes y el mapeo de UID son complicados; copiar archivos dentro y fuera de contenedores a menudo falla por permisos.
- La red de Docker y Docker Compose se vuelve frágil en hosts complejos; algunos también señalan que la red de podman es problemática.
- Los generadores de configuración/scripts de entrada y la configuración en varias capas (Helm → variables de entorno → imagen → app) pueden hacer que depurar sea muy opaco.
Alternativas y debate más amplio sobre empaquetado
- Nix/NixOS se cita repetidamente como una mejor respuesta para la reproducibilidad, el aislamiento de dependencias y el control de la cadena de suministro; otros señalan que sigue teniendo blobs binarios y complejidad.
- Algunos abogan por el empaquetado tradicional de sistemas operativos, binarios estáticos (Go, musl) o modelos simples de “un solo EXE/zip” (como en Windows) como algo más limpio que Docker.
- Tema meta: Docker se ve a la vez como una mejora práctica enorme frente al caos anterior a los contenedores y como una herramienta que consolida la pereza, la complejidad y las pilas opacas.