Docker explicado en 15 minutos: guía visual para principiantes

Una vez pasé dos días enteros depurando una API que funcionaba perfectamente en mi laptop. Los logs estaban limpios. Los tests pasaban. Cada endpoint respondía exactamente como decía la especificación.

Luego la desplegué en el servidor de staging y todo se derrumbó. Una librería de sistema faltante. Una versión diferente de Python. Una variable de entorno que existía en mi máquina y en ningún otro lugar. Dos días perdidos, porque mi laptop y el servidor hablaban dialectos ligeramente distintos de Linux.

Mi compañero de equipo me vio dar vueltas toda una tarde, y luego me envió un mensaje de Slack de una sola línea: “¿Probaste con Docker?”

Eso fue hace tres años. No he tenido un problema de “funciona en mi máquina” desde entonces.

El problema que Docker realmente resuelve

Esto es lo que pasa sin Docker. Escribes código en tu máquina. Tu máquina tiene un sistema operativo específico, versiones específicas de lenguajes y librerías, archivos de configuración en directorios específicos. Tu código depende de todo eso, silenciosamente, te des cuenta o no.

Luego alguien más intenta ejecutar tu código. Un OS diferente. Versiones de librerías diferentes. Dependencias faltantes. Las cosas se rompen de formas que no tienen nada que ver con tu lógica de negocio.

Docker resuelve esto empaquetando tu aplicación junto con todo lo que necesita para funcionar — la capa del OS, las librerías, el runtime, la configuración, todo — en una unidad portátil llamada contenedor. Ese contenedor se ejecuta de la misma forma en todas partes. Tu laptop, el laptop de tu colega, un servidor de CI, una VM en la nube. El mismo comportamiento, siempre.

No es magia. Es simplemente empaquetado consistente. Pero resulta que el empaquetado consistente resuelve una cantidad enorme de problemas del mundo real.

Contenedores vs máquinas virtuales: apartamentos vs casas

Si has oído hablar de las máquinas virtuales, quizás te preguntes en qué se diferencian los contenedores. La analogía que uso es apartamentos contra casas.

Una máquina virtual es como una casa. Tiene sus propios cimientos, su propia fontanería, su propio sistema eléctrico. Es completamente autónoma y completamente aislada, pero es pesada. Necesitas mucho terreno (RAM, CPU, disco) para construir una, y levantar una casa nueva toma tiempo.

Un contenedor es como un apartamento. Compartes los cimientos y la fontanería del edificio (el kernel del OS anfitrión), pero tu apartamento sigue siendo tuyo. Tienes tus propios muebles, tu propia distribución, tus propias cosas. Te mudas rápido, te vas rápido, y el edificio puede albergar muchos más apartamentos que casas.

En términos prácticos: una VM puede tardar un minuto en arrancar y consumir un gigabyte de RAM antes de que tu app siquiera se inicie. Un contenedor arranca en segundos y solo usa la memoria que tu app realmente necesita.

Ambos tienen su lugar. Pero para la mayoría de los flujos de desarrollo y despliegue, los contenedores te dan el 90% del aislamiento al 10% del costo.

Imágenes vs contenedores: la receta y el pastel

Esto confunde a todos los principiantes, así que voy a ser directo.

Una imagen Docker es un plano. Es una plantilla de solo lectura que describe todo lo necesario para ejecutar tu aplicación — el OS base, los paquetes instalados, tu código, el comando de inicio. Piensa en ella como una receta.

Un contenedor Docker es una instancia en ejecución de esa imagen. Es el pastel real que preparaste a partir de la receta. Puedes hacer varios pasteles de una sola receta. Cada pastel es independiente — puedes comer uno, decorar otro de forma diferente, tirar el tercero. La receta sigue igual.

Cuando ejecutas docker run, tomas una imagen y creas un contenedor a partir de ella. Cuando ese contenedor se detiene, la imagen sigue ahí, intacta, lista para crear otro.

También puedes compartir imágenes. Docker Hub es como un libro de recetas público — millones de imágenes preconstruidas para bases de datos, servidores web, lenguajes de programación, y más. En lugar de escribir una receta desde cero, tomas una ya probada y construyes encima.

Tu primer Dockerfile: un ejemplo real

Un Dockerfile es simplemente un archivo de texto que describe cómo construir una imagen. Aquí tienes uno real para una aplicación sencilla de Node.js:

# Partir de la imagen oficial de Node.js 20
FROM node:20-alpine

# Definir el directorio de trabajo dentro del contenedor
WORKDIR /app

# Copiar primero los archivos de package (optimización de caché de capas)
COPY package.json package-lock.json ./

# Instalar las dependencias
RUN npm ci

# Copiar el resto del código de la aplicación
COPY . .

# Indicar a Docker el puerto que tu app escucha
EXPOSE 3000

# El comando a ejecutar cuando el contenedor arranque
CMD ["node", "server.js"]

Cada línea es una instrucción. FROM elige tu punto de partida. COPY trae archivos. RUN ejecuta comandos durante el build. CMD dice qué pasa cuando el contenedor se inicia.

Para construir esta imagen y ejecutarla:

# Construir la imagen y etiquetarla "my-app"
docker build -t my-app .

# Ejecutar un contenedor a partir de esa imagen
docker run -p 3000:3000 my-app

El -p 3000:3000 mapea el puerto 3000 de tu máquina al puerto 3000 dentro del contenedor. Abre http://localhost:3000 y ahí está tu app, corriendo en un contenedor.

Recuerdo la primera vez que hice esto. Me pareció excesivo para un simple servidor Node. Luego compartí esa misma imagen con mi equipo y todos estaban corriendo exactamente el mismo setup en menos de un minuto. Nada de README con doce pasos de instalación. Nada de “asegúrate de tener Node 20, no 18.” Solo docker run.

Docker Compose: cuando un solo contenedor no es suficiente

La mayoría de las aplicaciones reales no son un solo contenedor. Tienes una webapp, una base de datos, quizás un caché, quizás una cola de mensajes. Docker Compose te permite definir todo eso en un solo archivo y arrancar todo con un solo comando.

Aquí tienes un docker-compose.yml para una webapp con una base de datos PostgreSQL:

version: "3.8"

services:
  web:
    build: .
    ports:
      - "3000:3000"
    environment:
      - DATABASE_URL=postgres://user:pass@db:5432/myapp
    depends_on:
      - db

  db:
    image: postgres:16
    environment:
      - POSTGRES_USER=user
      - POSTGRES_PASSWORD=pass
      - POSTGRES_DB=myapp
    volumes:
      - pgdata:/var/lib/postgresql/data

volumes:
  pgdata:

Luego ejecutas:

docker compose up

Los dos contenedores arrancan, pueden comunicarse entre sí por nombre de servicio (db resuelve a la IP del contenedor de base de datos), y los datos de la base persisten en un volumen para sobrevivir a los reinicios.

Antes de Docker Compose, configurar un entorno de desarrollo local con base de datos significaba instalar PostgreSQL en tu máquina, crear el usuario y la base de datos correctos, esperar que la versión coincidiera con producción. Ahora es un archivo y un comando.

Cuándo NO usar Docker

Soy fan, claramente. Pero Docker no es la respuesta para todo.

Scripts simples y herramientas locales. Si estás escribiendo un script de Python que solo tú vas a ejecutar, conteneurizarlo añade complejidad sin mucho beneficio. Usa un entorno virtual y ya.

Aplicaciones gráficas. Docker está diseñado para cargas de servidor y herramientas de línea de comandos. Técnicamente puedes ejecutar apps gráficas en contenedores, pero es doloroso y rara vez vale la pena.

Cuando no entiendes lo que hay dentro. He visto equipos descargar imágenes aleatorias de Docker Hub y ejecutarlas en producción sin leer el Dockerfile. Eso es como comer comida que un desconocido te ofrece en un estacionamiento. Como mínimo, usa imágenes oficiales y revisa lo que contienen.

Cargas bare-metal críticas en rendimiento. La sobrecarga es mínima, pero no es cero. Para la mayoría de las aplicaciones nunca lo notarás. Para trading de alta frecuencia o procesamiento de audio en tiempo real, tal vez sí.

Docker brilla cuando necesitas reproducibilidad, portabilidad y aislamiento. Para todo lo demás, evalúa con honestidad. Si Docker te parece que resuelve un problema que no tienes, probablemente sea así.

La práctica diaria de 15 minutos

Aprender Docker leyendo es como aprender a nadar viendo YouTube. Necesitas meter las manos en el agua.

Esto es lo que haría durante las próximas dos semanas, quince minutos al día:

Días 1-3. Descarga imágenes y ejecuta contenedores. docker run -it ubuntu bash te da un shell Linux desechable. Explora. Instala cosas. Sal. Se fue. Esa es la belleza del asunto.

Días 4-6. Escribe Dockerfiles para proyectos que ya tengas. Aunque sean simples. El acto de decidir qué necesita tu app para funcionar te enseña más que cualquier tutorial.

Días 7-9. Usa Docker Compose para montar un entorno multi-contenedor. Una webapp con base de datos es el proyecto clásico para empezar.

Días 10-14. Rompe cosas a propósito. Elimina volúmenes, cambia imágenes base, modifica los mapeos de puertos. Depurar Docker te enseña Docker más rápido que hacerlo todo bien a la primera.

Si quieres un enfoque estructurado para construir este tipo de hábito de aprendizaje diario, escribí sobre ese proceso en cómo construir un hábito de aprendizaje de 15 minutos que realmente funciona.

Docker también es tu puerta de entrada al ecosistema cloud en general — orquestación con Kubernetes, pipelines de CI/CD, infraestructura como código. Si ese camino te interesa, aquí es donde empezar a aprender cloud computing desde cero.

FAQ

¿Necesito saber Linux para usar Docker?

Ayuda, pero no necesitas ser administrador de Linux. La mayor parte del trabajo con Docker involucra comandos básicos — copiar archivos, instalar paquetes, definir variables de entorno. Si puedes navegar en una terminal, puedes usar Docker. Dicho esto, entender cómo funcionan los procesos, los sistemas de archivos y las redes en Linux hará que la depuración sea mucho más fácil a largo plazo.

¿Docker es gratis?

Docker Engine es open source y gratuito. Docker Desktop (la app gráfica para Mac y Windows) es gratis para uso personal, educación y pequeñas empresas. Las empresas más grandes necesitan una suscripción de pago para Docker Desktop, pero siempre puedes usar las herramientas de línea de comandos directamente sin él.

¿Cuál es la diferencia entre Docker y Kubernetes?

Docker ejecuta contenedores. Kubernetes los orquesta a gran escala. Si Docker es como conducir un auto, Kubernetes es como gestionar una flota de camiones de reparto — decidir qué camión va a dónde, reemplazar los que se descomponen, escalar durante las horas pico. No necesitas Kubernetes hasta que estés ejecutando muchos contenedores en múltiples servidores. Empieza con Docker. Kubernetes viene después.

¿Puedo usar Docker en Windows?

Sí. Docker Desktop para Windows usa WSL 2 (Windows Subsystem for Linux) bajo el capó, y funciona bien. Lo he usado en máquinas Windows para desarrollo y aprendizaje sin problemas mayores. Solo asegúrate de que WSL 2 esté habilitado y de que tengas suficiente RAM — Docker puede ser bastante hambriento.

¿Quieres construir habilidades reales de cloud desde cero, un concepto a la vez? Descubre SkillRealm Learn →