Docker es raro

Artículo original ↗ Discusión en Hacker News ↗

Los ingenieros analizan por qué Docker se siente “raro”, rastreando cómo superpone primitivas de Linux como namespaces y cgroups para crear la ilusión de máquinas autocontenidas y cómo decisiones de diseño tempranas —como un daemon que se ejecuta como root, un runtime basado en Go y la sintaxis de Dockerfile— moldearon tanto su potencia como sus rarezas. Los participantes contrastan Docker con alternativas como Podman, Incus y Firecracker, debatiendo la operación rootless, los modelos de red y la idoneidad de Go frente a C o Rust para trabajo de contenedores de bajo nivel. Hay amplio acuerdo en que los verdaderos avances de Docker fueron su experiencia de desarrollador, el layerizado de imágenes y el registro central, que cambiaron fundamentalmente cómo se empaqueta y despliega el software, aunque el ecosistema haya evolucionado hacia runtimes más ligeros o más seguros.

Origen, historia e impacto de Docker

  • Docker surgió tras años de experimentación con vserver/openvz/LXC y sistemas de archivos de unión dentro de una empresa de PaaS, y luego pivotó desde ese PaaS.
  • Innovaciones clave señaladas: Dockerfiles y el layerizado de imágenes (compilaciones rápidas y cacheables), un registro centralizado de imágenes, y una evangelización y demostraciones incesantes.
  • Muchos comentaristas dicen que transformó sus carreras y flujos de trabajo, reemplazando Vagrant, configuraciones a medida de LXC/Zones, largas guías de configuración y problemas de “funciona en mi máquina”.
  • Algunos argumentan que el valor principal fue hacer que los primitivos del kernel (namespaces, cgroups, chroot) fueran trivialmente accesibles; otros destacan el registro y el impulso del ecosistema.

Elección del lenguaje y diseño del runtime

  • El proyecto original usaba Python; Docker más tarde eligió Go por los binarios estáticos, la adopción entre distintas “tribus” y la facilidad para contribuir.
  • El creador y otros coinciden en que Go era torpe para trabajo de contenedores de bajo nivel (clone, namespaces), requiriendo shims en C y soluciones alternativas, pero aun así era el tradeoff correcto entonces.
  • El comportamiento de threading y goroutines causó errores sutiles (por ejemplo, namespaces no limpiados, dificultad con syscalls ligadas a hilos).
  • Debate sobre Rust: algunos dicen que hoy elegirían Rust o C para un runtime; otros sostienen que la velocidad de desarrollo de Rust y el borrow checker lo vuelven impracticable para muchos equipos.

Daemon, root y modelo de permisos

  • El modelo cliente-servidor con daemon de Docker se debate mucho:
    • Críticos: complica permisos, hace que el socket de Docker ≈ root, choca con firewalls y resulta incómodo en sistemas multiusuario.
    • Defensores: en los primeros días de Linux/contenedores era la forma pragmática de permitir que usuarios no root gestionaran contenedores y unificar la UX de Mac/Windows/Linux.
  • Hoy existen modos rootless, pero llegaron tarde; Podman y otros ganaron tracción al ser daemonless/rootless por defecto.

Redes y terminología

  • Hay un fuerte desacuerdo sobre las redes “bridge” de Docker:
    • Los administradores de redes sostienen que el término es engañoso frente al bridging tradicional y los dominios de broadcast, y que los valores predeterminados (NAT, ajustes de DNS) sorprenden a los equipos de operaciones.
    • Otros insisten en que la terminología coincide con los dispositivos bridge de Linux subyacentes y que las redes de Docker sirven principalmente para la conectividad entre contenedores, con NAT solo como comodidad.

Comercialización y ecosistema

  • Varios comentarios analizan las dificultades comerciales de Docker: una división cultural entre los equipos de open source y enterprise, falta de un “dictador” claro para el producto, y una monetización difícil de una herramienta central para desarrolladores.
  • Algunos creen que ignorar ciertas necesidades empresariales abrió espacio a competidores; otros dicen que esos problemas no fueron los verdaderos bloqueos comerciales.

Uso actual, alternativas y evolución

  • Docker sigue siendo central en muchos flujos de trabajo de desarrollo y CI, especialmente mediante Compose.
  • Algunos usuarios han migrado a Podman, Incus, LXC/systemd-nspawn o configuraciones basadas en Firecracker para una mejor aislamiento o propiedades de seguridad más simples.
  • Nuevas herramientas (por ejemplo, Dagger, Range) se apoyan en ideas de contenedores/imágenes para optimizar CI y la ejecución bajo demanda sin daemons ni registros tradicionales.

Aprendizaje y educación

  • Visiones divididas sobre enseñar Docker: algunos dicen que la sintaxis de Dockerfile es trivial y puede delegarse fácilmente a herramientas/LLMs; otros subrayan que entender contenedores frente a VMs, namespaces, layering y caching es el verdadero valor educativo.