- Un artículo de ACM que destaca el proceso de evolución técnica de Docker, que desde su primer lanzamiento en 2013 ha transformado de raíz la forma en que los desarrolladores construyen, despliegan y ejecutan aplicaciones, y que organiza décadas de investigación en sistemas ocultas detrás de una CLI aparentemente simple
- La base técnica central de Docker es el uso de namespaces de Linux para lograr aislamiento de procesos sin máquinas virtuales, combinando 7 tipos de namespaces agregados gradualmente desde 2001 para implementar contenedores ligeros
- Para dar soporte a macOS y Windows, adoptó una arquitectura contraintuitiva al integrar un monitor de máquina virtual de biblioteca (HyperKit) dentro de la app de escritorio, ejecutando Linux dentro de un proceso de usuario en lugar de usar el enfoque tradicional de hipervisor
- Actualmente soporta hardware heterogéneo como ARM y RISC-V y cargas de trabajo de IA, y se ha consolidado como infraestructura de desarrollo estándar en la nube, escritorio y edge
- Con el auge de las cargas de trabajo de IA, la gestión de dependencias de GPU ha surgido como un nuevo desafío, y la evolución de Docker continúa con soporte de GPU mediante CDI (Container Device Interface) e integración con TEE (entornos de ejecución confiables)
Orígenes técnicos
- A inicios de los años 2000 era común instalar manualmente numerosas dependencias en distribuciones Linux y compilar y configurar software directamente, y con el auge de la computación en la nube en 2010 este proceso se volvió aún más complejo
- Docker simplificó esto permitiendo que los desarrolladores empaquetaran la aplicación y todas sus dependencias como una imagen de sistema de archivos ("contenedor") para ejecutarla en cualquier máquina donde solo estuviera instalado Docker
- A diferencia de una máquina virtual, puede ejecutarse con unos cuantos comandos sin instalar un sistema operativo completo
Flujo de trabajo habitual
- Cuando el desarrollador escribe un Dockerfile, define un proceso de compilación paso a paso basado en sintaxis de shell
- Ejemplo de un sitio web en Python: comienza con
FROM python:3 y describe en un solo archivo la instalación de dependencias, copia del código, exposición de puertos y comando de ejecución
- Con
docker build se crea la imagen del contenedor y con docker push se publica en Docker Hub
- Se ejecuta especificando el montaje de volúmenes de datos y la exposición de puertos de red, como en
docker run -v data:/app/data -p 80:80
- Desde 2013 la CLI se ha expandido mucho y el backend fue rediseñado por completo, pero el flujo de trabajo básico se ha mantenido consistente: escribir Dockerfile →
docker build → docker run
- En GitHub se encontraron más de 3.4 millones de Dockerfiles ubicados en la raíz de repositorios públicos
Cómo funciona internamente: namespaces de Linux
- El kernel del SO aísla la memoria de los procesos, pero muchos recursos del sistema como el sistema de archivos, archivos de configuración y bibliotecas dinámicas siguen siendo compartidos
- Es muy difícil instalar varias apps con requisitos conflictivos de bibliotecas dinámicas en una misma máquina
- También pueden producirse interferencias no deseadas entre procesos, como conflictos de puertos de red
- Ejecutar cada app en una máquina virtual (VM) separada lo resuelve, pero resulta muy pesado por la duplicación de kernel, sistema de archivos, caché y redes bridge
- Como cada SO invitado funciona de forma independiente, también es difícil deduplicar almacenamiento y memoria
- En 1978,
chroot() de Unix v7 permitió usar un sistema de archivos raíz separado, pero no soportaba composición de sistemas de archivos para múltiples apps
- Nix y Guix lo resuelven mediante reempaquetado por directorio para cada app y enlazado dinámico, pero es difícil aplicarlo a software propietario y no resuelve los conflictos de puertos de red
- Docker eligió los namespaces de Linux: cada proceso puede controlar de forma independiente cómo accede a recursos compartidos como archivos y directorios
- Ejemplo: dos procesos en distintos namespaces pueden interpretar
/etc/passwd de manera distinta como /alice/etc/passwd y /bob/etc/passwd
- El namespace se aplica solo al abrir el recurso; después, el descriptor de archivo funciona como un recurso normal del kernel sin sobrecarga adicional
- Historia de la introducción de namespaces
- 2001, Linux 2.5.2: namespace de montaje
- 2006, Linux 2.6.19: namespace de IPC
- 2007, Linux 2.6.24: namespace de stack de red
- En total se soportan 7 tipos de namespaces
- A diferencia de Plan 9, los namespaces no fueron diseñados desde el inicio, sino que se agregaron gradualmente, por lo que eran de bajo nivel y difíciles de usar
- Funciones similares en FreeBSD y Solaris tampoco alcanzaron un uso masivo
- La contribución clave de Docker en 2013: encontrar un equilibrio práctico entre el aislamiento pesado de las VM y la facilidad de uso de los elementos nativos del SO
Estructura de ejecución de contenedores Linux en Docker
- Docker tiene una estructura de cliente-servidor, compuesta por un demonio de servidor que se ejecuta en el host (
dockerd) y un cliente CLI que envía solicitudes a través de una API RESTful
- Hacia 2015, el demonio monolítico se dividió y reorganizó en componentes especializados
- BuildKit: ensambla imágenes de sistema de archivos
- containerd: instancia imágenes como contenedores en ejecución y administra recursos de red y almacenamiento
Imágenes de contenedor
- Al invocar
docker build, se crea una imagen de sistema de archivos en capas que representa los ejecutables y datos del Dockerfile
- Capa más baja: una distribución del SO como Debian o Alpine Linux (o ensamblada manualmente como archivo tar)
- Capas posteriores: diferencias del sistema de archivos generadas por el resultado de ejecutar cada comando individual del Dockerfile
- Se almacenan en un sistema de almacenamiento de direccionamiento por contenido: se administra usando como clave el hash de la imagen del sistema de archivos
- Permite deduplicación eficiente, garantiza inmutabilidad y verifica alteraciones mediante hashes
- En 2016, la Open Container Initiative (OCI) estandarizó el formato de imagen, y existen múltiples implementaciones independientes
- Usa sistemas de archivos Linux como overlayfs, btrfs y ZFS para hacer snapshot y clonar eficientemente capas copy-on-write
- Soporta lazy-pulling de imágenes mediante el snapshotter de almacenamiento
stargz
Instancias de contenedor
- Al invocar
docker run, se asignan recursos del sistema para crear un proceso aislado con namespaces ("contenedor") a partir de una imagen OCI
containerd configura dinámicamente los namespaces necesarios para cada contenedor y realiza lo siguiente:
- Define cgroups (grupos de control) de procesos para aislamiento de recursos y limitación de velocidad de E/S
- Remapea puertos de red locales dentro del contenedor a puertos expuestos externamente en la interfaz del host
- Conecta volúmenes de almacenamiento mutables del sistema de archivos del host para mantener el estado persistente de la app
- Aísla el árbol de procesos del contenedor con namespace PID
- Mapea el UID local dentro del contenedor a otro UID del host mediante namespace de usuario (por ejemplo, UID 1000 dentro del contenedor → UID 12345 o 23456 en el host)
- Aunque configurar namespaces tiene un pequeño costo, es mucho menor que iniciar una VM Linux completa, y en la mayoría de los casos tarda menos de 1 segundo
- El kernel de Linux realiza recolección de basura de los contenedores terminados como si fueran procesos normales
Más allá de Linux: soporte para macOS y Windows
- Gracias a la arquitectura cliente-servidor, la CLI puede enviar comandos a instancias remotas de Docker mediante una conexión de red segura
- En 2015, Docker ya había sido adoptado ampliamente en el desarrollo sobre Linux, pero los desarrolladores de macOS y Windows se enfrentaban a una barrera de usabilidad al no poder ejecutar contenedores Linux
- La mayoría de los desarrolladores usa macOS o Windows como entorno principal de desarrollo, pero las imágenes de sistema de archivos de Docker solo pueden ejecutarse sobre el kernel de Linux
- Con el auge de la nube pública, Linux se convirtió en el entorno preferido para despliegue
Construcción de la aplicación Docker for Mac
- Restricción clave: para los desarrolladores acostumbrados a Docker en Linux, debía funcionar sin configuración adicional y poder ejecutar las mismas imágenes de Docker
- Se invirtió el enfoque existente —ejecutar Linux por separado junto al sistema operativo de escritorio— integrando el hipervisor dentro de una app en espacio de usuario de macOS/Windows y ejecutando Linux ahí
- Inspirado en la investigación sobre unikernels: demostró que los componentes del sistema operativo podían integrarse de forma flexible dentro de aplicaciones más grandes
- HyperKit: un VMM en forma de biblioteca que usa las extensiones de virtualización por hardware de los CPU Intel para ejecutar el kernel de Linux desde un proceso normal de usuario
- El kernel de Linux integrado ejecuta el demonio de Docker, que administra los contenedores y actúa como un endpoint normal del servidor Docker
- Todos los detalles de administración de Linux quedan ocultos dentro de la app de escritorio →
docker build y docker run en el escritorio se reenvían a la instancia integrada de Linux y "simplemente funciona"
- Este enfoque también fue adoptado por otros sistemas de contenedores como Podman, y terminó consolidándose como la forma estándar de ejecutar contenedores en macOS/Windows
LinuxKit: una distribución Linux personalizada e integrada
- Una distribución Linux personalizada diseñada para integrarse como componente de otras apps, no para ejecutarse de forma independiente
- Se construyó un espacio de usuario personalizado que incluye solo los componentes mínimos necesarios para ejecutar contenedores Docker, con el fin de reducir al mínimo el tiempo de inicio de la app
- Todos los componentes individuales se ejecutan dentro de contenedores, por lo que en el espacio de nombres raíz usado durante el arranque no se ejecuta nada
- Aprovecha el mismo sistema de archivos copy-on-write y los espacios de nombres de red que usan los contenedores Docker
- Con la combinación de LinuxKit + HyperKit, es posible iniciar procesos Linux a una velocidad casi igual a la de los procesos nativos de macOS
- Lanzado en 2016 en las apps Docker for Mac y Windows
Problemas de red y la solución SLIRP
- La conectividad de red desde contenedores Linux integrados hacia macOS/Windows resultó ser un problema inesperadamente complicado
- El enfoque tradicional de puente Ethernet requería una administración de red compleja, y los firewalls y antivirus en escritorios corporativos lo detectaban como tráfico potencialmente malicioso, lo que generó miles de reportes de errores por parte de los usuarios beta
- Solución SLIRP: una herramienta usada originalmente a mediados de los 90 para conectar a internet la PDA Palm Pilot
- Durante el handshake TCP del contenedor, las tramas Ethernet se envían al host mediante el protocolo virtio sobre memoria compartida
- Aprovecha bibliotecas unikernel de MirageOS para convertir las solicitudes de red de Linux en llamadas nativas de sockets de macOS/Windows
- La pila TCP/IP en espacio de usuario vpnkit, escrita en OCaml, la recibe en el sistema operativo host y llama a la syscall
connect() de macOS
- Desde la perspectiva de las políticas de VPN, el tráfico saliente se reconoce como generado por la app de Docker, no por una máquina separada
- Tras desplegar vpnkit en la beta de 2016, los reportes de errores de usuarios corporativos se redujeron en más de 99%
- El enfoque SLIRP también fue adoptado después en el ámbito de la nube serverless, reutilizando una vieja técnica de redes dial-up para resolver nuevos problemas de gestión de contenedores
Manejo del tráfico de red entrante
- Cuando un contenedor Linux escucha en un puerto, no queda expuesto automáticamente a internet a menos que se solicite explícitamente desde la CLI (por ejemplo,
docker run -p 80:80 nginx)
- La experiencia ideal para el usuario: que el puerto del contenedor aparezca directamente en la IP del escritorio y pueda accederse desde el navegador con
http://localhost:8080
- La virtualización de escritorio tradicional, como VMware Fusion, exponía una IP intermedia temporal en lugar de
localhost
- Se instaló un programa eBPF personalizado en el kernel de LinuxKit → activa la creación de un socket en escucha correspondiente en el host de escritorio → activa el reenviador de puertos
- Resultado: al ejecutar un contenedor Linux en Mac, se puede acceder de inmediato por
localhost, con la misma experiencia de desarrollo que en una máquina Linux nativa
Almacenamiento
- Los desarrolladores necesitan editar el código localmente mientras ejecutan el código y las pruebas dentro de contenedores
- En Linux, esto se logra con bind mounts usando
docker run -v /host:/container para acceder a archivos en vivo
- En macOS y Windows los kernels son distintos, por lo que los bind mounts no funcionan
- Docker usa virtio-fs, un protocolo de memoria compartida derivado del hipervisor KVM, para enviar las operaciones del sistema de archivos al host (en formato de solicitudes FUSE)
- El host recibe estas solicitudes y llama a las syscalls correspondientes de
open, read y write
- El código y los datos del desarrollador permanecen en el sistema de archivos del host, por lo que herramientas de respaldo y búsqueda como Time Capsule o Spotlight de Apple pueden acceder a ellos
Windows Services for Linux (WSL)
- En 2017, Microsoft lanzó WSL: ejecución directa de apps Linux en Windows
- La primera versión seguía un enfoque de sistema operativo-biblioteca, convirtiendo dinámicamente las syscalls de binarios Linux en syscalls de Windows en lugar de usar virtualización
- Funcionó bien para muchas apps, pero para ejecutar contenedores Docker faltaban syscalls compatibles
- En 2018 se lanzó WSL2: rediseñado, de forma similar a Docker for Mac, para ejecutar una VM Linux completa en segundo plano
- Docker en WSL2 ejecuta el daemon y los contenedores de usuario dentro de una distribución LinuxKit para WSL
- Maneja la API de Docker y el reenvío de puertos de red desde el propio Windows y desde otras distribuciones Linux
- La arquitectura clave que hizo posible la evolución multiplataforma de los contenedores Docker: un enfoque de sistema operativo-biblioteca que reutiliza código tradicionalmente exclusivo del kernel como bibliotecas en espacio de usuario e integradas en otras apps
- El éxito de esta arquitectura se demuestra en que es invisible pero omnipresente: millones de desarrolladores usan Docker cada día sin preocuparse por en qué sistema operativo se está ejecutando
Nuevo flujo de trabajo para desarrolladores: múltiples arquitecturas de CPU
- En los inicios de Docker, la mayoría de las cargas de trabajo en la nube se basaban en la arquitectura Intel
- La situación cambió con la llegada de los procesadores Amazon Graviton ARM en 2018 y los CPU Apple M1 ARM en 2020
- Ejecutar cargas de trabajo en ARM puede ofrecer menor costo y mejor rendimiento
- Se volvió necesario admitir múltiples arquitecturas de CPU dentro de la misma imagen Docker, como Intel, ARM, POWER y RISC-V
- Del lado del servidor, el formato de imagen OCI se amplió con manifiestos multiarquitectura (multiarch manifests)
- Para construir imágenes para múltiples arquitecturas de CPU en un solo host, se aprovechó la función
binfmt_misc de Linux
- Con QEMU, se realiza una conversión transparente entre binarios ARM e Intel
- La sobrecarga ocurre principalmente en la fase de compilación; la imagen multiarquitectura resultante se ejecuta de forma nativa en cualquier host
- Apple introdujo soporte de hardware y software para traducir conjuntos de instrucciones de CPU mediante Rosetta, lo que facilitó su integración en la arquitectura de Docker
- Hoy es común en el flujo de trabajo de los desarrolladores ejecutar contenedores Intel y ARM en paralelo
Gestión de secretos mediante entornos de ejecución confiables (TEE)
- En entornos de contenedores, la gestión de secretos como contraseñas o claves de API siempre ha sido un reto
- Deben inyectarse dinámicamente sin hornearlos en la imagen del sistema de archivos
- Docker admite el reenvío de sockets, lo que permite montar sockets de dominio local dentro de un contenedor
- En Docker for Mac/Windows, el reenvío de sockets llega hasta la VM de Linux
- Permite usar dentro del contenedor sistemas de gestión de claves como
ssh-agent sin exponer directamente las claves
- El reenvío de sockets ofrece un nivel básico de protección, pero hacen falta más capas de defensa frente al malware dentro de una cadena de suministro de software cada vez más grande
- Se está aplicando protección a nivel de hipervisor directamente en el runtime de contenedores para mejorar el nivel de protección entre contenedores
- Los entornos de ejecución confiable (TEE): funciones de hardware de las CPU modernas que permiten crear VM confidenciales capaces de proteger datos secretos incluso del sistema operativo anfitrión
- Pueden imponer restricciones de acceso a los datos a través de los límites de la app, el kernel y el hipervisor
- Sin embargo, configurar y usar TEE también implica una complejidad operativa similar a la de la virtualización del sistema operativo
- El grupo de trabajo Confidential Containers está desarrollando aplicaciones que se ejecutan dentro de TEE y se administran con Docker
- El Docker CLI reenvía mensajes cifrados desde el TEE local del escritorio, pasando por el host, hasta entornos TEE remotos en la nube
- Los desarrolladores pueden autenticarse en entornos sensibles de la nube sin desplazarse físicamente, y las credenciales se almacenan de forma segura en el enclave del escritorio
Soporte GPGPU para cargas de trabajo de IA
- Con el auge de las cargas de trabajo de IA ha surgido un desafío completamente nuevo: la mayoría de las cargas de machine learning se ejecutan en GPU
- Problema clave: las cargas de trabajo en GPU requieren drivers de GPU del kernel y bibliotecas de espacio de usuario que coincidan exactamente, mientras múltiples contenedores se ejecutan sobre un solo kernel compartido
- Si dos aplicaciones requieren versiones distintas del mismo driver de GPU del kernel, aparece el mismo conflicto fundamental que Docker buscaba resolver originalmente
- Desde marzo de 2023, Docker ofrece soporte para CDI (Container Device Interface)
- Personaliza la imagen del sistema de archivos en el momento de iniciar el contenedor
- Hace bind mount de archivos de dispositivo GPU y bibliotecas dinámicas específicas de GPU, y vuelve a generar la caché de
ld.so
- CDI garantiza la portabilidad de imágenes entre ciertas clases y proveedores de GPU, pero no es totalmente fluido entre distintos sistemas operativos y marcas de hardware
- Las bibliotecas dinámicas que añade CDI definen API diferentes, por lo que no existe nada comparable a la tradicional interfaz estable de los contenedores, la ABI de llamadas al sistema de Linux
- Por eso es difícil que una app para GPU de Nvidia se ejecute en una CPU Apple serie M: el soporte de virtualización de GPU aún no ha madurado lo suficiente como para traducir instrucciones vectoriales entre hardware diverso
- Se está trabajando con la comunidad de contenedores y con fabricantes de GPU para desarrollar un método más flexible y seguro de gestionar las dependencias relacionadas con GPU
- Se espera que la iniciativa de interfaces portables llegue a un consenso
Conclusión
- Docker comenzó en 2013 con el objetivo de ayudar a los desarrolladores a compilar, compartir y ejecutar aplicaciones más fácilmente
- Hoy está profundamente integrado en los flujos de trabajo estándar de desarrollo en la nube y en escritorio, y millones de desarrolladores en todo el mundo lo usan a diario, procesando decenas de miles de millones de solicitudes al mes
- Un objetivo constante ha sido mantener una comunidad open source activa y diversa que construya estándares para la interoperabilidad
- La CNCF (Cloud Native Computing Foundation) actúa como administradora de varios componentes clave
- La Open Container Initiative (parte de la Linux Foundation) administra el formato de imágenes
- Hoy existen muchas implementaciones activas de estos elementos, y su despliegue aumenta en entornos edge como la nube, el escritorio, la automoción, los móviles y las naves espaciales
- En 2025, el flujo de trabajo típico de un desarrollador integra pruebas y despliegue continuos, servidores de lenguaje en el IDE y asistencia de IA mediante agentic coding
- Desde la perspectiva de Docker, el flujo esencial de "build and run" es muy parecido al de hace 10 años, pero el soporte del sistema para reducir la fricción en entornos diversos se ha reforzado de forma notable
- El objetivo es que Docker sea un acompañante invisible que ayude a los desarrolladores a desplegar código más rápido, y que esté diseñado para escalar a los flujos modernos de programación con IA
1 comentarios
Opiniones de Hacker News
Cuando salió Docker por primera vez, ya estaba cansado de oír hablar de otra “innovación” más
No me gustaban los NoSQL a medio hacer, los microservicios impuestos a la fuerza ni la tendencia de convertir cada llamada de función en RPC
Pero ahora lo uso con frecuencia gracias a su simplicidad
Aun así, los contenedores de otras personas siguen siendo un infierno. Yo al menos intento mantenerlos simples, pero algunos meten demasiadas cosas y da la impresión de que ni ellos mismos entienden su proceso de despliegue
Ahora parece que vivimos en una época en la que llueve código que los desarrolladores ni siquiera han revisado por sí mismos gracias a los LLM
Hubo muchísimos intentos, pero al final la razón por la que Dockerfile sobrevivió fue su flexibilidad
Era familiar porque seguía la lógica operativa de siempre: copiar archivos y ejecutar comandos
Se ve tosco, pero parece que esa flexibilidad simple seguirá siendo la opción dominante en el futuro
Si todos usaran Nix o Bazel, tal vez
docker buildse habría vuelto un chisteSi el hash cambia entre builds distintos, no se puede confiar en ellos, así que mientras factores como la hora de modificación del archivo entren en el hash, la consistencia total será difícil
Personalmente me gusta mkosi, pero no todo el mundo quiere empezar desde una plantilla vacía de sistema operativo
En la mayoría de los casos solo haces pull desde un registry público y push a uno privado, así que casi no usas imágenes locales
Es un poco ineficiente, pero no lo bastante molesto como para cambiarlo
Recuerdo que Docker se presentó por primera vez en PyCon US Santa Clara en 2013
Si ves el video de la charla en YouTube, fue un momento histórico
Parece que hubo confusión porque la fecha de publicación del paper y la fecha real de la presentación eran distintas, pero estamos hablando de hace unos 13 años
“A decade of Docker” sonaba más natural que “Twelve years of Docker containers”
Recuerdo la publicación inicial en HN
En ese momento ya estaba harto de alternativas como LXC o Vagrant, y Docker realmente fue como un salvador
Es interesante que Docker reutilizara una herramienta de acceso telefónico de los años 90 llamada SLIRP para saltarse firewalls
No permitía conexiones entrantes, pero era algo así como un precursor del NAT
Quise usar Docker, pero cada vez que lo intentaba faltaba alguna función que necesitaba
Probablemente porque uso un stack técnico poco común
La grandeza de Docker está en haber convertido el “en mi computadora funciona” en estándar de la industria
Ahora vivimos en una época en la que esa misma computadora se “envía” a producción
Antes desplegar era un procedimiento enorme, pero ahora puedes desplegar directamente el sistema de archivos
La actual revolución de los agentes de programación me da una sensación parecida de cambio cultural
Si puedes reproducir el entorno con un script de 10 líneas, entonces “desplegar la máquina” tampoco suena tan mal
Vale la pena preguntarse por qué este enfoque resulta tan atractivo
La abstracción siempre gana porque arreglar el problema de fondo es demasiado difícil
No sé mucho de networking, pero en Mac me gustaría que los contenedores tuvieran direcciones IP separadas
Quisiera acceder con
container_ip:80sin mapeo de puertosEn Linux se podía, pero en Mac se complica porque hay que pasar por una VM
Probé un método basado en WireGuard, pero se rompía con cada actualización de Docker
Ojalá hubiera una forma oficialmente soportada
Tailscale Docker Extension maneja la configuración automáticamente
Si quieres evitar el mapeo de puertos por puertos dinámicos, te recomendaría probar la opción
--net=hosty activar Host Networking2013 fue un año de cosecha abundante para el empaquetado: aparecieron Docker, Guix y NixOS
Descubrí este dato mientras escribía un paper relacionado
Me pregunto si después hubo otro año en que tantos proyectos excelentes surgieran al mismo tiempo
Guix y Nix siguen siendo herramientas de nicho
A medida que ML y AI entran en todas partes, el tamaño de las imágenes crece exponencialmente
Solo torch ya ocupa varios GB
Extraño las imágenes de 30 MB de antes
Como no hay archivos compartidos entre capas, el desperdicio es enorme
Por eso estoy construyendo yo mismo un registry alternativo con soporte de deduplicación a nivel de archivo
Me pareció realmente interesante que Docker se disfrazara como una VPN para engañar al software corporativo de seguridad
También es un caso fascinante como historia técnica