Durante a\u00f1os trabaj\u00e9 con m\u00e1quinas virtuales y pens\u00e9 que era suficiente. Cada nuevo proyecto significaba clonar una VM, esperar que levantara, rezar para que las dependencias fueran las correctas y luego descubrir, inevitablemente, que algo fallaba en producci\u00f3n que no fallaba en mi m\u00e1quina. Docker cambi\u00f3 todo eso. Pero no fue amor a primera vista.<\/p>\n\n\n\n
Me acuerdo exactamente del momento. Eran las 11 de la noche, est\u00e1bamos por hacer un deploy de una API .NET y el servidor de producci\u00f3n se negaba a arrancar la aplicaci\u00f3n. El error era cr\u00edptico: una biblioteca de dependencias con versi\u00f3n diferente a la que ten\u00edamos en desarrollo. Tres horas despu\u00e9s, con el equipo exhausto, logramos resolver el problema manualmente. Al d\u00eda siguiente alguien pregunt\u00f3: \u00ab\u00bfy si usamos Docker?\u00bb<\/em><\/p>\n\n\n\n En ese momento yo ten\u00eda mis reservas. \u00ab\u00bfPara qu\u00e9 complicar las cosas si las VMs ya funcionan?\u00bb<\/em>, pens\u00e9. Tard\u00e9 un tiempo en entender que no se trataba de complicar, sino exactamente de lo contrario.<\/p>\n\n\n\n Docker es una plataforma de c\u00f3digo abierto que permite empaquetar una aplicaci\u00f3n junto con todas sus dependencias<\/strong> \u2014bibliotecas, runtime, herramientas del sistema, configuraci\u00f3n\u2014 en una unidad estandarizada llamada contenedor<\/strong>. Ese contenedor se puede ejecutar de forma id\u00e9ntica en cualquier entorno que tenga Docker instalado: tu notebook, el servidor de staging, producci\u00f3n en cloud o un cluster on-premise como el que manejo yo en SUSE Linux HA.<\/p>\n\n\n\n La definici\u00f3n t\u00e9cnica es elegante: Docker comparte el kernel del sistema operativo anfitri\u00f3n en lugar de virtualizar hardware completo. Eso lo hace liviano, r\u00e1pido y eficiente<\/strong>. Pero lo que me convenci\u00f3 no fue la definici\u00f3n t\u00e9cnica sino lo que significa en la pr\u00e1ctica: el contenedor que prob\u00e9 en mi m\u00e1quina es exactamente<\/em> el mismo que se ejecuta en producci\u00f3n. Sin sorpresas.<\/p>\n\n\n\n Algo que me result\u00f3 fascinante cuando profundic\u00e9 en el tema es que la idea de contenedores no naci\u00f3 con Docker. La tecnolog\u00eda de aislamiento de procesos tiene d\u00e9cadas:<\/p>\n\n\n\n La genialidad de Docker no fue inventar algo nuevo sino hacer accesible lo que ya exist\u00eda. Y eso, en tecnolog\u00eda, suele ser la innovaci\u00f3n m\u00e1s poderosa.<\/p>\n\n\n\n Este es el grande. El que me hizo pasar de esc\u00e9ptico a evangelista. Con Docker, la frase \u00abfunciona en mi m\u00e1quina\u00bb<\/em> pierde sentido. Si el contenedor corre en dev, corre en prod. La imagen es la misma. Las dependencias son las mismas. El runtime es el mismo.<\/p>\n\n\n\n Ven\u00eda de un mundo donde levantar una VM significaba esperar 2 o 3 minutos m\u00ednimo. Con Docker, un contenedor arranca en segundos o incluso milisegundos<\/strong>. Eso transforma completamente el flujo de trabajo: pod\u00e9s destruir y recrear entornos constantemente sin perder el hilo.<\/p>\n\n\n\n En mi cluster on-premise de dos nodos SUSE Linux, cada recurso cuenta. Antes, cada servicio necesitaba su propia VM con un SO completo. Hoy tengo decenas de contenedores corriendo en los mismos nodos<\/strong> que antes apenas soportaban cinco VMs. Los contenedores comparten el kernel del host: no replican el sistema operativo, solo empaquetan lo que la aplicaci\u00f3n necesita.<\/p>\n\n\n\n Constru\u00eds la imagen una vez y la ejecut\u00e1s en cualquier lado: tu notebook con WSL2, un servidor Ubuntu on-premise, AWS EC2, Azure Container Instances, Google Cloud Run. La misma imagen. Sin recompilar, sin reconfigurar. Esta portabilidad es lo que despu\u00e9s abre la puerta a Kubernetes, que orquesta esos contenedores a escala.<\/p>\n\n\n\n Cada contenedor vive en su propio mundo: sus procesos, su sistema de archivos, su red. Si un contenedor tiene un problema, los dem\u00e1s no se enteran. Puedo tener dos versiones de Python corriendo en paralelo sin conflictos. Puedo experimentar con una nueva versi\u00f3n de una librer\u00eda sin tocar el sistema. Para un entorno de producci\u00f3n, eso es tranquilidad.<\/p>\n\n\n\n Cuando empec\u00e9 con Docker, la pregunta que m\u00e1s me hac\u00edan era: \u00ab\u00bfy entonces las VMs mueren?\u00bb<\/em>. La respuesta corta es no. La respuesta larga es m\u00e1s interesante.<\/p>\n\n\n\n En muchos de mis entornos actuales uso ambos: contenedores Docker corriendo dentro<\/em> de VMs. As\u00ed combino el aislamiento fuerte de las VMs con la eficiencia y portabilidad de los contenedores.<\/p>\n\n\n\n Hace poco tuve que desplegar una aplicaci\u00f3n .NET 8 que en desarrollo corr\u00eda perfecto y en producci\u00f3n fallaba por diferencias en las librer\u00edas del sistema. Con Docker, la soluci\u00f3n fue crear una imagen que empaquetara exactamente el runtime y las dependencias necesarias:<\/p>\n\n\n\n Desde ese d\u00eda, el deploy es siempre el mismo comando:<\/p>\n\n\n\n Sin sorpresas. Sin diferencias entre entornos. Sin las 11 de la noche arreglando dependencias.<\/p>\n\n\n\n Si est\u00e1s evaluando si meterte con Docker, mi respuesta es s\u00ed, sin dudar. La curva de aprendizaje existe, pero no es empinada. En pocos d\u00edas pod\u00e9s tener tus primeros contenedores funcionando. Y una vez que lo incorpor\u00e1s a tu flujo de trabajo, no entend\u00e9s c\u00f3mo trabajabas sin \u00e9l.<\/p>\n\n\n\n En los pr\u00f3ximos art\u00edculos de esta serie voy a ir a fondo con la arquitectura interna de Docker, los Dockerfiles, la gesti\u00f3n de redes, vol\u00famenes y finalmente Docker Compose \u2014el salto que te lleva de un contenedor a un entorno completo con m\u00faltiples servicios coordinados.<\/p>\n\n\n\n Si ten\u00e9s preguntas o quer\u00e9s compartir tu propia experiencia con Docker (o con las VMs que todav\u00eda no pudiste abandonar), dej\u00e1 tu comentario abajo. 👇<\/p>\n\n\n\n\u00bfQu\u00e9 es Docker, realmente?<\/h2>\n\n\n\n
# As\u00ed de simple es levantar un servidor nginx con Docker\ndocker run -d -p 8080:80 --name mi-web nginx\n\n# En segundos ten\u00e9s un servidor web corriendo\n# Sin instalar nginx, sin configurar nada en el sistema<\/code><\/pre>\n\n\n\nUn poco de historia: Docker no invent\u00f3 los contenedores<\/h2>\n\n\n\n
\n
Por qu\u00e9 Docker importa: los 5 beneficios que cambiaron mi forma de trabajar<\/h2>\n\n\n\n
1. Consistencia entre entornos<\/h3>\n\n\n\n
# Si esto funciona en tu m\u00e1quina...\ndocker run --rm -v $(pwd):\/app -w \/app node:20 node app.js\n\n# ...esto funcionar\u00e1 igual en el servidor de producci\u00f3n\ndocker run --rm -v \/apps\/miapp:\/app -w \/app node:20 node app.js<\/code><\/pre>\n\n\n\n2. Arranque en segundos (no en minutos)<\/h3>\n\n\n\n
# Levantar PostgreSQL 16 completo en segundos:\ndocker run -d --name postgres-dev -e POSTGRES_PASSWORD=mipassword -e POSTGRES_DB=miapp -p 5432:5432 postgres:16-alpine\n\n# Listo. Base de datos funcionando sin instalar nada en el sistema.<\/code><\/pre>\n\n\n\n3. Eficiencia de recursos<\/h3>\n\n\n\n
4. Portabilidad real<\/h3>\n\n\n\n
5. Aislamiento y seguridad<\/h3>\n\n\n\n
Docker vs. M\u00e1quinas Virtuales: la comparaci\u00f3n que aclara todo<\/h2>\n\n\n\n
Caracter\u00edstica<\/th> Docker (Contenedor)<\/th> M\u00e1quina Virtual<\/th><\/tr><\/thead> Abstracci\u00f3n<\/td> Nivel de SO<\/td> Nivel de hardware<\/td><\/tr> Kernel<\/td> Comparte el kernel del host<\/td> Kernel propio por VM<\/td><\/tr> Tiempo de arranque<\/td> Segundos \/ milisegundos<\/td> Minutos<\/td><\/tr> Tama\u00f1o de imagen<\/td> MBs<\/td> GBs<\/td><\/tr> Consumo de recursos<\/td> Muy bajo<\/td> Alto (OS completo por VM)<\/td><\/tr> Densidad en el host<\/td> Alta (decenas\/cientos)<\/td> Baja (pocas VMs)<\/td><\/tr> Aislamiento<\/td> A nivel de proceso<\/td> Aislamiento completo de SO<\/td><\/tr> Portabilidad<\/td> Muy alta<\/td> Media (im\u00e1genes pesadas)<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n \u00bfCu\u00e1ndo uso Docker?<\/h3>\n\n\n\n
\n
\u00bfCu\u00e1ndo sigo usando VMs?<\/h3>\n\n\n\n
\n
Un ejemplo real: de \u00abfunciona en mi m\u00e1quina\u00bb a \u00abfunciona en todos lados\u00bb<\/h2>\n\n\n\n
# Dockerfile simple para una API .NET 8\nFROM mcr.microsoft.com\/dotnet\/aspnet:8.0 AS base\nWORKDIR \/app\nEXPOSE 80\n\nFROM mcr.microsoft.com\/dotnet\/sdk:8.0 AS build\nWORKDIR \/src\nCOPY [\"MiApi.csproj\", \".\"]\nRUN dotnet restore\nCOPY . .\nRUN dotnet build -c Release -o \/app\/build\n\nFROM build AS publish\nRUN dotnet publish -c Release -o \/app\/publish\n\nFROM base AS final\nWORKDIR \/app\nCOPY --from=publish \/app\/publish .\nENTRYPOINT [\"dotnet\", \"MiApi.dll\"]<\/code><\/pre>\n\n\n\ndocker build -t miapi:latest .\ndocker run -d -p 80:80 --name miapi miapi:latest<\/code><\/pre>\n\n\n\nConclusi\u00f3n: vale la curva de aprendizaje<\/h2>\n\n\n\n
\n\n\n\n