La historia de Docker: la ballena que envolvió el software

Mascote do LinuxPro empilhando um contêiner no cais, com a baleia do Docker carregando a carga

En marzo de 2013, en un lightning talk de cinco minutos en la PyCon de Santa Clara, Solomon Hykes mostró lo que dotCloud utilizaba por debajo del PaaS. El nombre era Docker. El 20 de marzo se abrió el código. En junio de 2014 salió la 1.0. Trece años después, Docker Engine 29.8.0 (3 de septiembre de 2026) sigue siendo la forma más común de empaquetar un proceso Linux, incluso después de que el orquestador de la flota se haya convertido en Kubernetes y el runtime de bajo nivel se haya convertido en containerd.

dotCloud, YC y un motor interno

Kamel Founadi, Solomon Hykes y Sebastien Pahl fundaron dotCloud en Y Combinator del verano de 2010. El producto, lanzado en 2011, era un PaaS: tú enviabas el código, la plataforma apilaba el runtime. Por debajo había un motor de contenedores que nadie veía. Hykes, francés, había pasado por Epitech y un tiempo en Estados Unidos. El insight no era “inventar el contenedor” — LXC, cgroups y namespaces ya estaban en el kernel. El insight era la experiencia: un archivo de receta, una imagen apilable, un comando para ejecutarlo igual en cualquier Linux.

La metáfora vino del puerto. Contenedor de barco: estándar ISO, se apila, se cambia de barco sin reempaquetar la carga. El software merecía lo mismo. La ballena azul con cajas en la espalda — Moby Dock — se convirtió en la mascota. En octubre de 2013 la empresa dejó el nombre dotCloud y pasó a llamarse Docker, Inc. El PaaS se vendió. El motor se convirtió en el producto.

PyCon 2013: cinco minutos que cambiaron el deploy

La charla se llamaba “The future of Linux Containers”. Cinco minutos, demo, aplausos. En 20 de marzo de 2013 el código se abrió. Al principio el runtime por defecto era LXC. En marzo de 2014, en la 0.9, Docker cambió LXC por libcontainer, escrito en Go, hablando directamente con cgroup, namespace, capabilities y apparmor/selinux. Menos dependencia, más control. La API alta — build, run, push, pull — ocultó el kernel. Fue eso, y no la virtualización en sí, lo que explotó.

Quien ya tenía LXC en producción miró y dijo “esto ya lo hacemos”. Quien nunca había mirado cgroup empezó a empaquetar la aplicación en 40 minutos. La diferencia era el Dockerfile y el Hub. Receta en texto, capa cacheada, registro público. El “funciona en mi máquina” perdió la excusa — la máquina iba junto, en capas.

1.0, Hub y la carrera de 2014–2015

La 1.0 salió en 9 de junio de 2014, en el mismo verano en que Google anunció Kubernetes. Docker Hub se convirtió en el GitHub de las imágenes. En septiembre de 2013 Red Hat ya había cerrado la colaboración (Fedora, RHEL, OpenShift). En octubre de 2014 Microsoft anunció Engine en Windows Server. En noviembre Amazon lanzó EC2 Container Service. IBM, Oracle, todo el mundo quería la ballena en la diapositiva.

En 22 de junio de 2015 Docker, CoreOS, Google, Microsoft, Amazon y otros anunciaron lo que se convirtió en la Open Container Initiative: un estándar de runtime y de formato de imagen, para que el mundo no quedase rehén de un único daemon. runc nació de ahí (libcontainer donado). containerd — el runtime que Engine ya usaba por debajo — fue donado a la CNCF. En 2017 Docker creó el proyecto Moby: el kit de piezas open source, separado de la marca comercial.

Swarm, Kubernetes y lo que la ballena ya no orquesta

Docker nunca quiso ser “solo el runtime”. Swarm mode entró en Engine 1.12: cluster, servicio, overlay, Raft. Compose (beta en diciembre de 2013, 1.0 en octubre de 2014) ya resolvía el portátil con YAML. El problema era la flota de verdad — decenas de nodos, rolling update, CRD, operador. Ahí ganó el timón de Google. En 2017 la propia Docker anunció soporte para Kubernetes. Swarm sobrevivió en el nicho y en Docker Desktop; el estándar de producción quedó el heptágono. La historia completa está en A história do Kubernetes.

Lo que quedó para la ballena es lo que siempre hizo mejor: la imagen, el daemon de la estación de trabajo, el Hub, el Compose. En agosto de 2021 Docker Desktop dejó de ser gratis para empresa grande — Personal en lugar de Free. Engine en Linux, Apache 2.0, no cambió de licencia. Confundir los dos es la forma clásica de llevarte un susto en compliance.

Lo que Docker realmente es

No es una máquina virtual. Es virtualización a nivel del SO: procesos aislados por namespace (PID, net, mnt, uts, ipc, user), limitados por cgroup, apilados en un sistema de archivos unión (OverlayFS). Una imagen es una plantilla de solo lectura; un contenedor es la imagen más una capa de escritura. El daemon dockerd escucha la API; el CLI docker habla con el daemon. El registro guarda la imagen. Compose describe un conjunto. El volumen sostiene el dato cuando el contenedor muere.

Bajo el capó de 29.x el stack es OCI: runc ejecuta, containerd gestiona el ciclo de vida, BuildKit construye. El Engine 29.8.0 ya incorpora containerd si el host no tiene un servicio separado, y habla nftables. Podman, nerdctl, CRI-O hacen el mismo recorte sin el daemon de Docker, Inc. La receta — Dockerfile, capa, registry — es la que cuajó. En marzo de 2026 la Communications of the ACM puso a Docker en portada, retrospectiva de una década.

2026: Engine 29.8, Compose 5, Desktop de pago

El Docker Engine 29.8.0 salió el 3 de septiembre de 2026. Go 1.26.8, BuildKit 0.33.0, containerd 2.3.4, runc 1.5.1. Flag --umask no run/create, AppArmor default configurable, hardening contra AF_VSOCK mediante socketcall de 32 bits. El Desktop 4.89.0 (31 de agosto) ya incluía Compose 5.5.0. Rootless ganó gvisor-tap-vsock como driver de red por defecto.

En Linux el camino libre sigue siendo el mismo: paquete de la distro o el repositorio oficial, Apache 2.0, sin EULA de Desktop. Para quien está empezando, el material antiguo de este blog aún sirve como primer contacto — con la salvedad de 2017 —, en Curso de Docker Grátis.

Línea de tiempo

  • 2008 — Solomon Hykes funda dotCloud, un PaaS francés; el motor de contenedores nace como herramienta interna.
  • 2010 — dotCloud pasa por Y Combinator.
  • Marzo de 2013 — el lightning talk de cinco minutos en la PyCon presenta Docker al mundo; el código es abierto.
  • Junio de 2014 — Docker 1.0, considerado listo para producción.
  • 2014–2015 — carrera de adopción; nace Docker Hub y la empresa cambia su nombre a Docker, Inc.
  • 2015 — la Open Container Initiative estandariza el formato de imagen y el runtime, quitando el control de las manos de una sola empresa.
  • 2016 — llega el swarm mode, la apuesta de Docker en orquestación.
  • 2017 — la propia Docker, Inc. anuncia soporte para Kubernetes; la disputa de orquestación termina.
  • Agosto de 2021 — Docker Desktop deja de ser gratuito para empresas grandes. El Engine en Linux sigue siendo Apache 2.0.
  • 3 de septiembre de 2026 — Docker Engine 29.8.0, con BuildKit 0.33, containerd 2.3.4 y runc 1.5.1.

Cierre

Un PaaS francés que no despegó, una charla relámpago de cinco minutos y una metáfora de puerto. El kernel ya tenía cgroup; faltaba el verbo. docker run se convirtió en el verbo. El orquestador de la flota se fue a Kubernetes. El formato de la caja se quedó.

El timón está en A história do Kubernetes. El hipervisor clásico, en Proxmox e VirtualBox. El kernel, en Linux cumple 35 años.

De dotCloud al Engine 29.8.0: la ballena todavía carga las cajas. Apache 2.0 en Linux, EULA en el escritorio, OCI debajo. La charla relámpago de 2013 cabe en cinco minutos. El resto del ecosistema, no.