Skip to main content

¡El proyecto Docker cumple 10 años! Una década de contenedores en retrospectiva

Escrito por
secure containerized applications

17 de marzo de 2023

0 minutos de lectura

El 15 de marzo de 2023 se cumplieron 10 años de la famosa charla relámpago de Solomon Hyke en PyCon, en la que presentó Docker al mundo.

Veamos cuánto ha cambiado todo y escuchemos las historias de algunas personas que abrieron camino hacia el mundo de los contenedores en el que vivimos hoy. Abrí mi pequeña libreta negra de contactos de contenedores y cloud native, y les pedí que compartieran historias sobre cómo conocieron Docker y alguna anécdota interesante de las trincheras durante la década transcurrida desde que conocimos a Moby y Molly.

¡Hola, wowrld!

Solomon Hykes presentando Docker con el famoso error ortográfico «Hello wowrld» en la pantalla detrás de él.
Solomon Hykes hablando en PyCon 2013

En 2013, el mundo conoció Docker. Para muchos desarrolladores, fue nuestra primera experiencia con los conceptos de cgroups, espacios de nombres y otras tecnologías de Linux usadas para «contener» procesos. Como les gusta decir a los creadores de Docker, «democratizaron» la tecnología de contenedores y la hicieron fácil de usar, sin necesidad de tener un título en administración de sistemas Linux.

Asombroso y mágico

Al preguntarles a algunas personas por sus primeras experiencias con Docker, ciertos adjetivos aparecieron una y otra vez: mágico, asombroso y ese momento de «¡ajá!».

Nirmal Mehta en el escenario de DockerCon 2015
Nirmal Mehta hablando en DockerCon 2015

¡Imagínate! Portland, Oregón, 2013, en la conferencia OpenSource de O'Reilly. Hacía unos meses que Docker había nacido como proyecto de código abierto y ya ganaba popularidad en distintas comunidades de TI: código abierto, cloud, DevOps, etc. Era el último día de la conferencia y asistí a una sesión un viernes temprano por la mañana sobre esta nueva tecnología llamada Docker. El ponente era Solomon Hykes, quien se metió de lleno en los conceptos de las capas de contenedores y explicó sus capacidades y las tecnologías subyacentes. Para terminar, hizo una demostración y, si no me falla la memoria, puso en marcha 5, 10, 15, ¡20 contenedores de apache/httpd en cuestión de segundos! Incluso para el pequeño grupo de asistentes medio dormidos de esa mañana, y especialmente para mí, fue asombroso... De inmediato sentí que estaba presenciando el comienzo de un cambio de paradigma y quise saberlo todo.

Sé que Docker no fue el primero en combinar las tecnologías subyacentes para crear procesos o contenedores aislados, pero la experiencia de usuario que mostró ese día —y que ha mantenido hasta hoy— fue mágica.

- Nirmal Mehta, especialista principal de SA en AWS

Captura de pantalla de Twitter de Brandon Mitchell abrigado y con artículos promocionales de Docker. El texto dice: «Mientras todos regalan camisetas, Docker me prepara para una gran tormenta invernal en Barcelona. ¿Me perdí algo en el pronóstico?»
Brandon Mitchell abrigado con artículos promocionales de Docker

Recuerdo la primera vez que usé Docker, después de seguir todo el proceso para configurar una VM y ejecutar nginx con herramientas como Ansible y Chef. Me pasaba una hora creando un playbook, lo configuraba para la VM que había puesto en marcha y luego esperaba a que se instalara todo. Después ejecuté el comando de Docker para iniciar nginx y, menos de 30 segundos después, el proceso ya se había iniciado en ese mágico entorno aislado. Ese fue el gancho que me lanzó a descubrir qué acababa de pasar y cómo funcionaba Docker.

- Brandon Mitchell, arquitecto de soluciones en BoxBoat, una empresa de IBM

Descubrir Docker fue como descubrir poderes mágicos. Ya me había pasado algo así cuando la virtualización reemplazó a los servidores y me dio la posibilidad de empaquetar VM en infraestructura física y aprovecharla al máximo. Docker fue como entrar en otro nivel del sueño: ahora podía empaquetar aplicaciones en VM y aprovechar aún mejor el hardware.

- Adrian Goins, ex defensor de desarrolladores en Rancher/SUSE

Andy Clemenko, ingeniero de campo en Rancher Government Solutions
Andy Clemenko, uno de los primeros en adoptar Docker e ingeniero de campo

A principios de 2015, mi empleador me pidió que me convirtiera en un experto en «Docker». Sabía muy poco, aparte de unas cuantas publicaciones del sitio Orange, así que empecé a probarlo. Como todo el mundo, comencé con el clásico ejemplo de Docker «Hello World» usando Nginx. Para mí, el momento de «¡ajá!» fue instantáneo. Como administrador de sistemas desde hacía mucho tiempo, vi el aislamiento de procesos como un enorme salto adelante. Desde ese día, enfoqué toda mi carrera en los contenedores. Tuve la suerte de ayudar al gobierno de Estados Unidos a empezar a adoptar contenedores en varias agencias. Al cabo de un año y medio, tuve la fortuna de continuar mi recorrido con Docker al unirme a la empresa.

- Andy Clemenko, ingeniero de campo en Rancher Government Solutions

El escenario del fin del mundo

David Flanagan, quien adoptó Docker en su primer año, pronto vio cómo podía revolucionar las implementaciones en su empresa.

David Flanagan riendo con su hijo pequeño
David Flanagan, fundador de Rawkode Academy y papá divertido

Conocí Docker por primera vez en la demostración de Solomon en PyCon, en 2013. En ese momento trabajaba como director de desarrollo para una empresa británica de radio y revistas, y trataba de ayudarla a llevar su negocio al siglo XXI... transformación digital, ¿no? Su mayor problema era la escala, y teníamos un escenario «del fin del mundo»: «¿Qué hacemos si muere Lemmy, de Motörhead?». Nuestra carga era muy predecible, hasta que dejaba de serlo. No se pueden predecir las noticias y hay que escalar en tiempo real lo más rápido posible.

Llevábamos un tiempo usando Vagrant y VM, pero escalarlas rápidamente era complicado. Teníamos que aprovisionar de más con anticipación y reducir la capacidad rápidamente cuando terminaba el «evento», para bajar los costos. Así que cuando vimos Docker, se nos encendió el foco. Salvo que... Docker todavía no tenía «docker build»... Sin embargo, llegó poco después y adoptaron el lema que todavía se usa: «Build. Ship. Run». No solo resolvieron el problema de ejecución, sino que hicieron que la experiencia de desarrollo para crear imágenes de contenedores fuera increíblemente sencilla Y ofrecieron distribución (ship). Kubernetes y cloud native le deben muchísimo al equipo original de dotCloud, sin importar qué entorno de ejecución de contenedores usemos hoy.

- David Flanagan, fundador de Rawkode Academy

Estabilizar la cuadrícula

Yo también uso Docker desde sus inicios y, si me permiten decirlo, así fue mi experiencia.

Eric Smalling y sus amigos en una fiesta de KubeCon 2022
Captura de pantalla de Twitter de James Spurin: él, Eric Smalling, Bret Fisher, Chad Crowell, Kunal Kushwaha y Ramesh Kumar en KubeCon 2022

Empecé a probar Docker a fines de 2013 y lo usé en nuestras canalizaciones de CI, donde teníamos que ejecutar cientos de pruebas funcionales de extremo a extremo en cada commit de una gran aplicación web de comercio electrónico. En las horas pico, a menudo ejecutábamos más de 2000 instancias de navegador mediante cuadrículas Selenium2 basadas en VM, y nuestra pesadilla eran los resultados de pruebas inestables debido a problemas con la estabilidad de la cuadrícula. Poníamos y quitábamos instancias en la nube constantemente y, a lo largo de los años, probamos varias estrategias para reducir los tiempos de inicio, mantener la estabilidad y minimizar los costos. ¡Incluso experimentamos con instancias spot y terminamos compitiendo en subastas en distintas regiones!

Ya habíamos estado probando Docker para ejecutar la aplicación web y los controladores del conjunto de pruebas, pero para mí el momento decisivo llegó cuando me di cuenta de que podía crear una imagen con el navegador y xvfb y ponerla en marcha al instante. Esto nos permitió ejecutar cuadrículas de Selenium estables con tantos navegadores como cupieran en un solo nodo. (Los problemas de estabilidad de la cuadrícula solían deberse a que el nodo no podía escalar para ejecutar muchos navegadores, por lo que necesitábamos muchos nodos pequeños, cada uno con pocos navegadores). El resultado fue tan bueno que prácticamente dejamos de usar las instancias en la nube y usamos solo unas pocas VM locales para estas cuadrículas, con lo que ahorramos miles de dólares por semana.

- Eric Smalling, defensor sénior de desarrolladores en Snyk

Convencer a todo el mundo

Para quienes recién comienzan a desarrollar software empresarial, las ventajas de los contenedores y del ecosistema que surgió a su alrededor pueden parecer indiscutibles. Sin embargo, durante los primeros cinco o seis años, el futuro de Docker estuvo lejos de ser seguro.

Los resultados hablan por sí solos

A las personas suele costarles aceptar los cambios, pero los beneficios demostrables de Docker convencieron fácilmente:

Yo solía incorporar nuevas tecnologías de moda, así que siempre había cierto aire de frustración cuando decían «Dave tiene otro juguete». Además, la mayoría de mi equipo usaba Mac, ¡así que definitivamente me odiaban!

Pero para nosotros Docker se usaba principalmente en el servidor. Todavía no existía boot2docker, así que el equipo siguió usando Vagrant para el desarrollo. Con el tiempo, lo incorporamos a ese entorno cuando las ventajas se hicieron evidentes por sí solas. El equipo vio cómo simplificaba nuestra canalización de implementación y terminó convenciéndose.

Era difícil argumentar en contra cuando nuestras implementaciones pasaron de 40 minutos a unos 3.

- David Flanagan

Sevi Karakula detrás de una laptop, con un brazo extendido para señalar una calcomanía de Container Solutions que dice «Shift happens»
¡Sevi Karakula haciendo que la transición sea posible!

Cuando conocí Docker, llevaba suficiente tiempo trabajando como desarrollador de software para saber lo difícil que puede ser incorporar a un nuevo miembro al equipo y proporcionarle todas las herramientas que necesita. Además, cada vez que intentábamos introducir nuevos frameworks y lenguajes en el entorno de desarrollo —para hacer que todo fuera un poco más liviano—, solía ser un dolor de cabeza porque la reacción habitual de la mayoría de los desarrolladores era poner los ojos en blanco.

Docker nos facilitó mucho la vida porque solo teníamos que enseñar al equipo a usar esta herramienta mágica y, de inmediato, podían disfrutar de sus beneficios sin lidiar con toda la complejidad de instalarla y configurarla. Fue un momento de gran liberación para los desarrolladores: ya no tenían que instalar cada herramienta en una máquina fuertemente supervisada, hacer seguimiento de solicitudes para conseguir aprobaciones ni preocuparse por las licencias. Si había una imagen, podían empezar a trabajar.

- Sevi Karakulak, líder de ingeniería en Container Solutions

No estaba «listo para empresas»

El término «listo para empresas» es subjetivo y puede significar algo distinto para cada empresa. Matt Bentley recuerda una interpretación interesante de la época en que, como ingeniero de soluciones de Docker, tuvo que abordar qué tan «atractivo» era Docker —o, en este caso, qué tan poco lo era— en sus primeros días.

Matt Betley de pie detrás del mostrador de un stand en DockerCon 2019, con las manos apoyadas en el mostrador y una credencial que dice «Docker Team»
Matt Bentley en DockerCon 2019

… al cliente le encantaba Docker como tecnología y también le encantaba el producto Docker Trusted Registry, pero, mientras no tuviéramos algo que no se basara únicamente en API y línea de comandos, su equipo directivo nunca lo consideraría listo para empresas.

Tenían un proceso en el que necesitaban que les mostraran los productos internamente. Si les mostraba lo que yo había hecho con una canalización de CI/CD creada en Jenkins para tomar el código, compilarlo y probarlo en un contenedor, implementarlo y promover la imagen, no lo entenderían, porque las soluciones listas para empresas tenían interfaces de usuario atractivas.

- Matt Bentley, gerente de ingeniería de soluciones en VMware

Otra duda que se escuchaba con frecuencia tenía que ver con la relativa inmadurez del proyecto. Aunque las tecnologías subyacentes llevaban muchos años existiendo, para muchos era demasiado arriesgado apostar por un proyecto de código abierto surgido de una startup, con mascotas de caricatura y una tortuga mascota que hacía implementaciones.

Eric Smalling y Rachel Leeken en la fiesta de AWS en KubeCon EU 2022
Rachel Leeken y Eric Smalling en Kubecon EU 2022

Empecé a aprender sobre Docker en 2015 y, por el potencial que le vi, propuse que valía la pena considerarlo para modernizar los sistemas, en lugar de usar la solución antigua y costosa de un proveedor. El cliente no lo eligió porque dijo que no estaba seguro de la tecnología de contenedores ni de que siguiera existiendo durante los cinco años del contrato.

- Rachel LeeKin, especialista de SA en contenedores en AWS

Heridas autoinfligidas

A veces, lograr que un equipo adoptara los contenedores no era la tarea más difícil; lo complicado era enseñarle a usarlos correctamente.

Adrian Goins con casco y varios equipos de cámara, de pie junto a una aeronave paramotor cuadricóptero naranja y negra
Adrian Goins y el Iron Condor, su paramotor de cuatro ruedas


Al principio, me costaba convencer a mis clientes de que lo hicieran… Quienes entendían la idea no siempre comprendían sus beneficios ni cómo aprovechar un contenedor. Recuerdo a un cliente que tenía contenedores a los que accedía mediante una consola para recompilar su aplicación o sus dependencias y luego confirmaba los cambios en el contenedor como si fuera un repositorio de código. Sus contenedores de producción eran enormes y probablemente más frágiles que su infraestructura original sin contenedores.

- Adrian Goins

Crece el interés

Con el paso de los años, cada vez más personas empezaron a ver el potencial de los contenedores, sobre todo a medida que maduraban los orquestadores, aunque también trajeron sus propios desafíos. Adrian Mouat (@adrianmouat | @adrianmouat@hachyderm.io), autor y otro de los primeros Docker Captain, recuerda la experiencia de las primeras conferencias DockerCon y la gran actividad que se generó cuando cada vez más personas empezaron a probar esta tecnología y las empresas comenzaron a ofrecer soluciones para responder a sus necesidades.

Selfi de Betty Junod, Adrian Mouat, Eric Smalling y Matt Jarvis, de pie con rascacielos al fondo. Tomada durante KubeCon North America 2022 en Detroit, Michigan.
Adrian Mouat con Betty Junod, Eric Smalling y Matt Jarvis en KubeCon NA 2022

Una cosa que recuerdo muy bien es que, en 2014, quienes daban las charlas (yo incluido) preguntábamos: «¿Quién usa Docker?». Se alzaba un mar de manos. «¿Quién usa Docker en producción?». Casi todas las manos bajaban.

Dicho esto, la cantidad de personas que usaban Docker en producción incluso antes de que llegara a la versión 1.0 (octubre de 2014) y se declarara listo para producción era asombrosa.

Solíamos usar metáforas de transporte marítimo y hablar de cómo resolvía el problema de «pero en mi máquina sí funciona». Por desgracia, k8s apareció y recreó ese problema.

Cuando trabajaba en Container Solutions, ayudamos a organizar el primer Docker Con EU en el NEMO Science Center. El entusiasmo era increíble; todo el mundo sabía que estaba ante el comienzo de algo grande. CoreOS estuvo allí (¡presentando Rocket), Alexis Richardson impulsaba las redes de Weave, Luke Marsden dirigía ClusterHQ y el administrador de datos flocker, y Timo Derstappen hacía cosas increíbles con Giant Swarm. Había empresas de todos los sectores tratando de entender qué demonios estaba pasando.

- Adrian Mouat, gerente de producto en Chainguard

Escenario de la conferencia inaugural de DockerCon 18 Europe, con Jenny Burcio y Mano Marks entregándole a Bret Fisher el premio «Top of the Captains Hat». Bret lleva una gorra blanca de capitán de barco.
Bret Fisher gana el premio «Tip of the Captains Hat» en DockerCon 18 Europe

Vi la charla de Solomon en PyCon 2013 e intenté usar docker para mejorar nuestras pruebas de Node.js en 2014, pero no lo entendí. No dejaba de intentar meter un servidor entero en una imagen de contenedor (y fracasaba), y las redes me parecían pura magia. Era un conjunto enorme de nuevas automatizaciones y conceptos mágicos, así que me rendí y volví seis meses después. Esta vez lo entendí, y me impactó como un tren. La combinación de crear imágenes, almacenarlas en registros y ejecutar contenedores a partir de ellas me voló la cabeza, y nunca miré atrás.

- Bret Fisher, experto en DevOps y creador de Docker Mastery

Los orquestadores

Si el anuncio de Docker en PyCon 2013 fue la chispa que encendió el fuego, la llegada de las plataformas de orquestación de contenedores fueron los vientos que incendiaron el bosque. Mesosphere, Rancher, Swarm, Nomad y Kubernetes fueron las «aplicaciones estrella» que realmente llevaron los contenedores al siguiente nivel. Se han escrito volúmenes sobre las ventajas y desventajas de cada plataforma, pero no se puede exagerar la importancia que tuvieron para la adopción masiva de los contenedores.

Hoy, Kubernetes es la plataforma dominante, pero todavía existe una comunidad muy fiel de usuarios de Swarm, y Nomad también tiene sus grupos de seguidores. Mesos es anterior a Docker, y estoy seguro de que todavía cuenta con una buena cantidad de usuarios. A algunas personas Kubernetes les pareció demasiado complejo, pero, como demuestra su participación de mercado, la mayoría terminó adoptándolo.

Cuando apareció Kubernetes, lo odié. Era otra capa de abstracción que no aportaba muchos beneficios adicionales... hasta que sí los aportó. Entonces me encantó, porque podía tomar esos servidores, con sus máquinas virtuales y sus contenedores, y convertirlos en un pequeño centro de datos. El hecho de que existiera un proceso para cuidar de todo las 24 horas del día, los 7 días de la semana, significaba que yo podía dedicarme a otra cosa.

- Adrian Goins

Aunque Kubernetes es ahora la forma estándar de facto de implementar contenedores, resulta interesante ver cómo ha evolucionado este espacio y cómo se están creando tantas abstracciones a su alrededor.

Cuando quedó claro que los orquestadores serían clave para adoptar contenedores a gran escala, pensé que habría espacio para que varios orquestadores importantes tuvieran éxito. Cada uno era bueno a su manera y creía que todos tenían casos de uso ideales. Lo que me encantaba de Swarm era que podía tomar a alguien que entendiera comandos sencillos de docker run o pudiera armar un archivo Docker Compose fácil de entender y poner en marcha un servicio de Swarm en minutos. La sencillez de la CLI de docker y de herramientas como Docker Compose era brillante: si alguien sabía ejecutar contenedores en un solo host con cualquiera de ellas, dar el salto a la orquestación de contenedores no suponía un gran esfuerzo. Ahora, la industria trabaja para abstraer Kubernetes y alejarlo de los desarrolladores, porque les quitaba demasiado tiempo para desarrollar y lo enfocaba en la orquestación. El tiempo que los desarrolladores dedican a la orquestación es tiempo que no pueden dedicar a generar valor para el negocio con las aplicaciones en las que trabajan.

- Matt Bentley

Un cambio de carrera y de vida

Un peluche azul muy grande de Moby the Whale (de aproximadamente 1.5 metros de largo) sobre un escritorio de oficina vacío, con una pancarta que dice «Whalecome» sobre un tablero de anuncios vacío al fondo
Moby, la ballena en la antigua oficina de Docker en SFO

El tema común entre todas las personas a las que contacté para este artículo fue cómo el proyecto Docker y la comunidad que se formó a su alrededor transformaron la carrera y, de hecho, el sustento de tantas personas.

Sabía que era la siguiente evolución en infraestructura. Me obsesioné y enfoqué toda mi carrera exclusivamente en los contenedores.

- Bret Fisher

Desde ese día, enfoqué toda mi carrera en los contenedores… Hasta hoy, sigo dedicado a enseñar y guiar al Gobierno de Estados Unidos en su camino hacia los contenedores. Es increíble ver que una tecnología tan transformadora perdure durante 10 años.

- Andy Clemenko

Cuanto más aprendía, más me entusiasmaban las posibilidades que ofrecía la contenerización. Finalmente, empecé a enseñar Docker y decidí reorientar mi carrera hacia los contenedores y, después, Kubernetes. Al mirar atrás, puedo decir con seguridad que Docker me cambió la vida.

- Sevi Karakulak

En Snyk amamos el código abierto

Celebramos una década de trabajo transformador del proyecto Docker, como lo demuestran los testimonios inspiradores de las personas citadas aquí y los millones de desarrolladores que cada día crean, distribuyen y ejecutan contenedores en todo el mundo.

Snyk se fundó en 2015 con el objetivo de permitir que los desarrolladores programen y usen software de código abierto de forma segura, incluidos los contenedores donde lo ejecutan. Como creemos firmemente en el poder y la importancia del modelo de desarrollo de código abierto, desde el primer día ofrecemos nuestras herramientas de análisis sin costo para desarrolladores individuales.

Empieza con los desafíos de Capture the Flag

Aprende a resolver desafíos de captura la bandera con nuestro taller virtual introductorio a pedido.


Créditos

¡Gracias a todas las personas que contribuyeron a este artículo!

Nirmal Mehta

Arquitecto principal especialista en soluciones en AWS; Docker Captain desde 2016.
LinkedIn
@normalfaults
hachyderm.io/@nirmal

Brandon Mitchell

Arquitecto de soluciones en BoxBoat, una empresa de IBM; Docker Captain desde 2018; mantenedor de OCI image-spec.
LinkedIn
@sudo_bmitch
@bmitch@fosstodon.org

Adrian Goins

Exdefensor de desarrolladores en Rancher/SUSE; creador de contenido y aviador; defensor de Rancher/SUSE desde hace mucho tiempo.
LinkedIn
@creator_aviator

David Flanagan

Fundador de Rawkode Academy; creador de KubeHuddle Conference.
LinkedIn
@rawkode

Andy Clemenko

Ingeniero de campo en Rancher Government Solutions; exarquitecto de soluciones y ingeniero de soluciones en Docker.
LinkedIn
@clemenko
@clemenko@hachyderm.io

Rachel Leekin

Arquitecta especialista en soluciones de contenedores en AWS.
LinkedIn
@Rachel_LeeKin

Matt Bentley

Gerente de ingeniería de soluciones en VMware.
LinkedIn
@matthewbentley
@mbentley@hachyderm.io

Adrian Mouat

Gerente de producto en Chainguard; Docker Captain desde 2016; autor de Using Docker (O'Reilly Media, 2016).
LinkedIn
@adrianmouat
@adrianmouat@hachyderm.io

Sevi Karakulak

Líder de ingeniería en Container Solutions.
LinkedIn
@sevikarakulak