Saltar al contenido

lección 1

¿Qué es Docker? Cuando "en mi máquina funciona" no es suficiente

El problema que Docker resuelve, la historia de Solomon Hykes y dotCloud (2013), y por qué los contenedores cambiaron la industria.

50 min

Déjame contarte algo que le pasa a TODOS los equipos de software del mundo. Un desarrollador escribe código durante semanas. Lo prueba en su portátil. Funciona perfecto. Lo sube al servidor de producción y... se rompe. "Pero en mi máquina funciona", dice con cara de inocencia. Su compañero tiene otra versión de Python. El servidor tiene otra versión de una librería. El sistema operativo es diferente. Los paths son distintos. Es un desastre.

Esta historia la he vivido docenas de veces en mi carrera. En 2014 estaba en un equipo donde teníamos un script de Python que procesaba datos de clientes. Funcionaba perfecto en el Mac del desarrollador senior. Cuando lo pasamos al servidor de producción (un Ubuntu), se rompía porque usaba una librería que dependía de una versión específica de libxml2 que no estaba instalada. Perdimos DOS DÍAS resolviendo dependencias. Dos días que podrían haberse evitado con Docker.

### La analogía del restaurante

Imagina que eres un chef con un plato estrella: una paella valenciana increíble. Un amigo te pide que le enseñes a hacerla. Tienes dos opciones. Opción A: le cocinas la paella y se la envías por mensajero. Llega fría, el arroz se ha pegado, el marisco huele raro. Opción B: le envías la RECETA exacta — con la lista de ingredientes, las cantidades precisas, la marca del arroz, el tipo de sartén, la temperatura exacta, y los pasos en orden. Tu amigo puede reproducir la paella idéntica en su propia cocina.

Docker es la Opción B. No envías tu entorno ya configurado (que se "rompe en el camino"). Envías una RECETA (llamada Dockerfile) que describe exactamente qué sistema operativo base usar, qué programas instalar, qué versiones, qué archivos copiar y qué comando ejecutar. Cualquier persona, en cualquier ordenador, puede seguir esa receta y obtener EXACTAMENTE el mismo resultado. Siempre. Sin excepciones.

Consejo de senior: "En mi máquina funciona" es la frase más cara de la industria del software. He visto equipos perder semanas enteras resolviendo problemas de entorno que Docker habría evitado desde el día 1. Si aprendes UNA cosa de esta skill, que sea esta: el entorno es parte del código. Si no puedes reproducirlo, no existe.

### La historia: Solomon Hykes y el nacimiento de Docker (2013)

En 2008, un francés llamado Solomon Hykes fundó una empresa llamada dotCloud en París. Era una plataforma como servicio (PaaS) — algo parecido a lo que hoy es Heroku o Railway. El negocio no iba especialmente bien, pero el equipo había desarrollado una herramienta interna brutal para empaquetar y desplegar aplicaciones. Esa herramienta se llamaba Docker.

En marzo de 2013, Solomon presentó Docker en una charla de 5 minutos en PyCon (sí, una conferencia de Python — Docker y Python siempre han estado muy unidos). La demo era simple: en unos pocos comandos, empaquetabas una aplicación con TODAS sus dependencias y la ejecutabas en cualquier servidor de forma idéntica. La audiencia enloqueció. En semanas, Docker tenía miles de estrellas en GitHub. En meses, todas las empresas de tecnología del mundo estaban adoptándolo.

Lo que hizo Solomon fue democratizar una tecnología que ya existía en Linux desde hacía años (los "containers" basados en cgroups y namespaces) pero que era increíblemente compleja de usar. Docker la envolvió en una interfaz simple, elegante y accesible. Es como lo que hizo Apple con los smartphones: no inventó el teléfono con pantalla táctil, pero lo hizo USABLE.

### VMs vs Contenedores: casa entera vs habitación de hotel

Para entender Docker, necesitas entender qué había ANTES. La solución al problema de "en mi máquina funciona" antes de Docker era usar Máquinas Virtuales (VMs). Una VM es como construir una CASA ENTERA dentro de tu ordenador: tiene su propio sistema operativo completo, su propio kernel, sus propios drivers, todo. Es como si para resolver el problema del chef de la paella, construyeras una cocina industrial completa dentro de tu casa.

Un contenedor Docker, en cambio, es como una HABITACIÓN DE HOTEL. Comparte los cimientos del edificio (el kernel del sistema operativo), la fontanería, la electricidad — pero es completamente independiente de las otras habitaciones. Tiene su propia decoración (sus propios programas), su propia llave (su propio filesystem aislado), y puedes entrar y salir sin afectar a nadie más. Es MUCHO más ligero que construir una casa entera.

Una VM carga un sistema operativo completo por cada aplicación. Un contenedor comparte el kernel del host y arranca en segundos.
  • VM: arranca en 1-5 minutos. Contenedor: arranca en menos de 1 segundo.
  • VM: ocupa 2-10 GB por instancia. Contenedor: ocupa 50-500 MB.
  • VM: puedes correr 2-3 en un portátil. Contenedores: puedes correr 20-50 fácilmente.
  • VM: simula hardware completo. Contenedor: comparte el kernel del host.
  • VM: aislamiento total (diferente OS). Contenedor: aislamiento de procesos (mismo kernel).

### Los tres conceptos clave de Docker

Docker se basa en tres conceptos que debes tener clarísimos antes de seguir adelante. Los tres son parte de la analogía del restaurante que ya conoces:

  1. 01.Imagen (Image): es la RECETA escrita. Un archivo inmutable que describe exactamente qué tiene tu entorno: sistema operativo base, programas instalados, archivos copiados, configuración. No se modifica nunca — es como un molde.
  2. 02.Contenedor (Container): es el PLATO cocinado a partir de la receta. Una instancia viva y ejecutándose de una imagen. Puedes crear múltiples contenedores a partir de la misma imagen, igual que puedes cocinar múltiples paellas con la misma receta.
  3. 03.Dockerfile: es el DOCUMENTO donde escribes la receta. Un archivo de texto con instrucciones paso a paso para construir una imagen.

Y hay un cuarto concepto bonus: Docker Hub es como el RECETARIO de internet. Un registro público donde millones de personas comparten sus imágenes listas para usar. ¿Quieres PostgreSQL? Alguien ya creó la imagen. ¿Python 3.12? Ya existe. ¿Redis, Kafka, Jupyter, Airflow? Todo está ahí, a un comando de distancia.

### ¿Por qué Docker importa para ingeniería de datos?

En data engineering, Docker no es opcional — es FUNDAMENTAL. Mira todo lo que vas a hacer en las próximas skills de este track:

  • PostgreSQL: lo levantarás con docker-compose en la skill de SQL. Un comando y tienes una base de datos profesional corriendo.
  • PySpark: Spark es notoriamente difícil de instalar. Con Docker, un comando y tienes un cluster listo.
  • Airflow: el orquestador más usado necesita una base de datos, un scheduler y un webserver. Docker Compose los levanta todos juntos.
  • LocalStack: emula TODA la infraestructura de AWS en tu portátil. Gracias a Docker.
  • Kafka: un broker de mensajería con Zookeeper. Sin Docker, la instalación lleva horas. Con Docker: 30 segundos.

Docker es la PUERTA DE ENTRADA a todas las herramientas de datos profesionales. Sin Docker, cada instalación es una aventura diferente, con incompatibilidades y horas perdidas. Con Docker, todo se reduce a: escribe un archivo docker-compose.yml, ejecuta docker-compose up, y a trabajar.

Atención: Docker NO es una máquina virtual y NO es un emulador. No "simula" otro ordenador. Comparte el kernel de tu sistema operativo real y simplemente AÍSLA procesos. Esto es lo que lo hace tan rápido y ligero. Si alguien te dice "Docker es como una VM ligera", técnicamente está simplificando mucho — pero la analogía sirve para empezar.

### Resumen: qué vas a aprender en esta skill

En las próximas 7 lecciones vas a ir de cero a tener un entorno de desarrollo profesional completo corriendo en Docker. La progresión es intencionada: primero usas contenedores que otros crearon, luego creas los tuyos propios, y finalmente los combinas para construir entornos multi-servicio. Al final de esta skill, serás capaz de levantar PostgreSQL, Redis, Jupyter y cualquier herramienta de datos con un solo comando.

Consejo de senior: Docker es de esas herramientas que una vez que las dominas, no puedes creer que vivías sin ellas. Es como descubrir los atajos de teclado o el autocompletado. Sé paciente con los primeros conceptos — la curva de aprendizaje vale absolutamente la pena.

## ejercicios

[01]

Clasifica: ¿VM o Contenedor?

Para cada escenario, ¿usarías una VM o un contenedor Docker? Escribe "vm" o "container".

💡 Resultado esperado

 CONTAINER | Ejecutar una app Python con sus dependencias exactas
        VM | Correr Windows dentro de un Mac para usar Excel
 CONTAINER | Levantar PostgreSQL para desarrollo local
        VM | Testear software en un OS completamente diferente
Cargando editor...
[02]

Ordena la historia de Docker

Cinco hitos desordenados. Pon los índices en orden cronológico (el más antiguo primero). No hace falta recordar los años: razona la secuencia.

💡 Resultado esperado

  1. Solomon Hykes y dos socios fundan dotCloud en París
  2. Docker se presenta en una charla relámpago en PyCon
  3. Docker 1.0: primera versión estable
  4. Docker Compose permite levantar varios contenedores a la vez
Cargando editor...
[03]

Calcula el ahorro con contenedores

8 microservicios: 4 GB por VM contra 200 MB por contenedor. ¿Cuánta RAM ahorras? Usa la conversión decimal: 1 GB = 1000 MB.

💡 Resultado esperado

RAM con VMs: 32 GB
RAM con Docker: 1.6 GB
Ahorro: 30.4 GB (95%)
Cargando editor...

Regístrate para guardar tu progreso.

## comentarios

Reporta erratas, ayuda a otros o comparte tu opinión. Sé constructivo.

Inicia sesión para comentar y responder.

cargando comentarios...