Docker

Del odio al amor con Docker

Le hice la cruz a Docker en un examen de grado superior por un comando que no recordaba. Pasé años evitándolo, hasta que mi propio caos me obligó a volver.

Del odio al amor con Docker
Le hice la cruz a Docker en el ciclo de grado superior, por culpa de un examen y un comando que no recordaba. Pasé años evitándolo activamente. Hoy no monto un solo servicio sin él. Esta es la historia de cómo cambié de bando.
💡
En resumen, para quien tenga prisa

Docker me arruinó una práctica de base de datos justo antes de un examen, y decidí no volver a tocarlo. Lo evité durante años, incluso cuando me habría venido bien. Lo que me hizo rendirme no fue leer sobre él ni un tutorial — fue montar tantos servicios sueltos, sin ningún criterio, que dejé de saber yo mismo qué corría dónde.

Antes de meterme en la historia, una explicación rápida para quien no lo sepa: Docker es un programa que te deja meter cada programa que instalas dentro de su propia "caja" independiente (un contenedor), con todo lo que necesita dentro — en vez de instalarlo directamente sobre tu ordenador, donde puede chocar con otras cosas que ya tengas instaladas. Es la diferencia entre tener las herramientas sueltas por el garaje y tenerlas cada una en su propia caja, etiquetada.


🎓 El origen del odio

Esto empezó cursando el ciclo formativo de grado superior de DAW (Desarrollo de Aplicaciones Web), terminando el curso. Rafa, uno de esos profesores de muy buenas vibras que se le nota que disfruta lo que enseña, nos habló de Docker un día en clase, con esa mezcla de entusiasmo y "esto os va a servir en la vida real". Nos animó a probarlo. Y lo probé, sin sospechar nada.

El problema fue el momento: estábamos en exámenes finales, y para la asignatura de bases de datos usábamos VirtualBox — un programa que simula un ordenador completo dentro del tuyo, una máquina virtual — con una de Ubuntu (otro sistema operativo, como Windows pero distinto), y dentro de esa Ubuntu, un servidor de bases de datos Oracle montado. Para que esa máquina virtual arrancara en mi ordenador había hecho falta un comando concreto que activaba el modo del procesador que permite simular ordenadores dentro del tuyo (la virtualización), pero solo lo había ejecutado una vez, dos o tres meses antes, cuando instalamos VirtualBox y levantamos los primeros servidores. Desde entonces, nunca más había tenido que tocarlo.

🐛
El problema

Docker necesita usar ese mismo modo de virtualización para sí mismo, pero de una forma distinta a como lo usaba VirtualBox para levantar la máquina de Ubuntu con Oracle dentro. Al instalar Docker y probarlo, el modo cambió para adaptarse a él — y se revirtió lo que yo tenía puesto para VirtualBox, sin que yo me diera cuenta de que había pasado ni cuándo.

Llegué a la siguiente clase de bases de datos, encendí la máquina virtual como siempre... y no arrancó. Y no recordaba el comando. Lo había ejecutado una única vez, meses atrás, sin pensar que fuera a hacerme falta nunca más — y claro, no se me había quedado grabado. Se me borró de la cabeza justo en el peor momento posible, con el examen encima.

Tiré de un ChatGPT todavía joven, buscando entre migas de información hasta reconstruir el comando exacto. Lo encontré, la máquina volvió a arrancar, sobreviví al examen. Pero ahí, en ese momento de pánico evitable, le hice la cruz a Docker. Decidí que no lo iba a volver a tocar si podía evitarlo.

📝
Apunte de Juan Eladio

Cabe recalcar que yo vivo enamorado de Docker.

🙅 Los años de evitarlo

Y lo evité. No de forma pasiva — activamente. Hubo momentos, en distintos proyectos, en los que Docker habría sido claramente la herramienta correcta, y elegí no usarlo. Prefería montar las cosas a mano, aunque me costara más, antes que volver a pasar por aquello.

No era una decisión racional. Era una cicatriz.


💡 El punto de inflexión

Hace cinco meses empecé a montar Orbity, uno de nuestros SaaS (un programa que el cliente usa desde el navegador, pagando una cuota, sin instalar nada en su ordenador), usando solo Claude Code — una IA que escribe código, que en ese momento estaba probando por primera vez, después de haber oído hablar de ella sin haberla tocado nunca. Al ir creciendo el proyecto en microservicios (en vez de un programa único y enorme, muchas piezas pequeñas, cada una haciendo su propio trabajo por separado y hablando entre ellas), empecé a ver con mejores ojos la idea de organizarlos con Docker. Lo tenía en el radar, rondándome.

Pero lo que de verdad me hizo ceder fue otra cosa. Nos pusimos a montar un servidor local, compartido entre los dos, para ahorrar el coste de tener todo alquilado en la nube (el hosting). Y ahí el que iba probando y buscando cada servicio era yo: los investigaba, los levantaba, los probaba primero. Los que sabía que le iban a hacer falta a Juan Eladio para lo suyo, se los pasaba para que los mantuviera él a partir de ahí.

El problema era que, en mi propia parte, todo eso lo hacía a mano y sin ningún criterio: cada servicio necesita un puerto —un número que identifica por dónde se accede a él dentro del servidor, como el número de un piso en un edificio— y yo los elegía sobre la marcha, con nombres que no significaban nada para nadie que no fuera yo. Un servicio en el piso 3000 porque sí, otro en el 8080 porque era el que venía por defecto, ninguno relacionado con el siguiente. Y llegó un punto en que ni yo mismo sabía ya qué corría dónde — y eso, cuando tienes que desarrollar encima de esos servicios cada día, se convierte en un problema de verdad.

Así que la idea de documentar cada servicio por su nombre y su puerto fue mía, por pura necesidad: no podía seguir desarrollando bien sin saber, de un vistazo, qué era cada cosa. Se lo propuse a Juan Eladio para que lo hiciéramos los dos igual, y a partir de ahí empecé a migrar mis servicios a Docker, uno detrás de otro. Despacio al principio, con la desconfianza de quien ya se quemó una vez. Pero fue quedando todo más claro, más fácil de tocar sin miedo a romper algo sin querer.


📋 Antes / después

Antes Ahora
Instalación A pelo, cada servicio a su manera Cada servicio en su contenedor
Puertos Elegidos sobre la marcha, sin criterio Documentados, sin choques
¿Quién entiende el sistema? Solo yo, y a duras penas Cualquiera que mire la configuración
Actualizar el sistema Riesgo de romper algo sin avisar El resto no se entera
Mi opinión de Docker Trauma de un examen de grado superior Ya no monto nada sin él

Así se ve ahora: cada servicio agrupado, con su puerto, su estado y su consumo a la vista.


🎓 La moraleja

No cambié de opinión sobre Docker por argumentos. Los argumentos ya los había oído — un profesor me los dio en persona, hace años, y no sirvió de nada. Cambié cuando fui yo mismo quien dejó de entender su propio desorden, y tuve que inventarme una forma de arreglarlo para poder seguir trabajando.

La cicatriz del examen de bases de datos no era irracional del todo: Docker de verdad me rompió algo importante, en el peor momento posible. Pero llevaba años castigando a la herramienta por un problema que, en realidad, era mío — no saber lo que estaba cambiando en mi propio sistema antes de tocarlo.

Ahora todo lo que monto vive en Docker, sin excepción. Los mismos contenedores que una vez evité durante años son, ahora, lo primero que abro cuando empiezo algo nuevo.

Tardé años en volver. Pero volví.

Jose Maria Gomez Lobato
Escrito por

Jose Maria Gomez Lobato

Desarrollador web y cofundador de Nebula Systems. Trabajo creando soluciones donde la inteligencia artificial se convierte en herramientas reales, combinando desarrollo, automatización y curiosidad por entender cómo funciona todo por dentro.