Docker Basics: De Cero a Contenedores en Producción

¡Muy buenas a todos y bienvenidos a otro vídeo y artículo para el canal! ¿Cuántas veces habéis terminado de programar un proyecto en vuestro ordenador, pasa todos los tests en local, se lo enviáis a un compañero de equipo o lo desplegáis en un servidor de producción y de repente... todo salta por los aires?

En tu máquina local todo parecía impecable: tu editor de código abierto, FastAPI corriendo sobre Python 3.12 y una suite de pruebas pasando al 100% sin un solo fallo.

Sin embargo, al intentar ejecutar exactamente el mismo código en un servidor en la nube o en el ordenador de un colega, la realidad es otra:

Aparece el temido error ModuleNotFoundError, discrepancias entre versiones del intérprete (en tu equipo tenías Python 3.12 y en el servidor una versión antigua como Python 3.9), librerías del sistema no compatibles y variables de entorno ausentes. Y en ese instante surge la excusa más célebre y repetida en la historia del desarrollo de software:

"¡Pero si en mi máquina funcionaba perfectamente!"

Ante eso, la respuesta clásica del equipo de operaciones o DevOps siempre ha sido la misma: "Pues entonces tendremos que empaquetar tu ordenador físico y subirlo a producción".

Precisamente para solucionar este conflicto histórico nació Docker.

Docker es una plataforma abierta que permite empaquetar una aplicación junto con absolutamente todas sus dependencias, librerías del sistema y archivos de configuración dentro de una unidad estandarizada llamada contenedor. Gracias a esto, si tu proyecto funciona en tu portátil, puedes tener la certeza matemática de que funcionará exactamente igual en cualquier servidor, nube o máquina del mundo.

1. El Gran Duelo: Máquinas Virtuales (VM) vs Contenedores Docker

Para entender en profundidad la revolución de Docker, primero debemos compararlo con la solución clásica que reinaba en la virtualización: las máquinas virtuales tradicionales.

La Arquitectura de una Máquina Virtual

En la virtualización tradicional empleamos hipervisores como VirtualBox, VMware Workstation, KVM o Proxmox.

Para ejecutar una aplicación aislada dentro de una máquina virtual, el sistema debe levantar una pila completa y muy pesada:

1. Hardware Físico: CPU, memoria RAM, almacenamiento y adaptadores de red de tu ordenador.
2. Host OS: El sistema operativo anfitrión instalado en tu máquina.
3. Hypervisor: La capa de software encargada de emular hardware virtual.
4. Guest OS (Sistema Operativo Invitado): Cada máquina virtual instala una copia íntegra de un sistema operativo completo con su propio kernel duplicado, drivers virtuales y servicios del sistema.
5. Bins/Libs y App: Encima de ese sistema invitado se montan las librerías y finalmente tu aplicación.

Esta duplicidad genera graves inconvenientes en el día a día: * Gasto masivo de almacenamiento: Cada máquina virtual ocupa con facilidad entre 20 GB y 40 GB de disco sólo para alojar el sistema operativo base. * Kernel duplicado en RAM: La memoria RAM queda bloqueada reservando recursos para sistemas operativos enteros en lugar de para tu aplicación. * Arranque lento: Iniciar una máquina virtual requiere pasar por todo el ciclo de boot del kernel y de systemd, tardando entre 2 y 5 minutos.

La Arquitectura de Docker: Kernel Compartido

Docker no virtualiza hardware ni arranca sistemas operativos completos. En su lugar, utiliza contenerización a nivel de sistema operativo:

Como observamos en el diagrama: * Los contenedores descansan directamente sobre el Docker Engine, el cual se ejecuta sobre el sistema operativo anfitrión. * Todos los contenedores comparten el mismo kernel de Linux de la máquina host. * Cada contenedor solo contiene los binarios, librerías y código estrictamente necesarios para ejecutar ese proceso específico.

Este aislamiento no requiere emulación de hardware. Se apoya en dos características nativas avanzadas del kernel de Linux: * cgroups (Control Groups): Controlan y limitan el consumo de recursos físicos (cuánta CPU, memoria RAM o I/O de disco tiene permitido utilizar cada contenedor). * namespaces: Crean una burbuja de aislamiento para cada contenedor, separando la tabla de procesos (PID), las interfaces de red (NET), los puntos de montaje del sistema de archivos (MNT) y los identificadores de usuario (USER). Para la aplicación, ella es la única habitante del sistema.

La Metáfora: La Casa vs El Edificio de Apartamentos

Para visualizar esta diferencia de un solo vistazo, recurre siempre a esta analogía arquitectónica:

• Una Máquina Virtual es como una casa unifamiliar aislada: Si necesitas hospedar a tres personas independientes, construyes tres casas enteras desde cero. Cada una necesita sus propios cimientos, tejado, tuberías de fontanería, caldera y generador eléctrico. El coste de construcción, tiempo y mantenimiento es gigantesco.
• Un Contenedor Docker es como un apartamento dentro de un edificio moderno: La estructura del edificio, las vigas maestras, el suministro de agua y la red eléctrica (el kernel de Linux y los recursos del host) ya existen y están compartidos de forma eficiente. A cada inquilino se le asigna su apartamento privado, con cerradura y contadores independientes, consumiendo una fracción mínima de recursos.

2. Instalación y Variantes: Docker Desktop vs Docker Engine

A la hora de instalar Docker en tu estación de trabajo o servidor, existen dos caminos oficiales principales:

Vía 1: Docker Desktop (Windows y macOS)

Es la solución orientada a desarrolladores que trabajan en entornos gráficos bajo Windows 10/11 o macOS:

• Dashboard Visual: Permite encender, pausar, ver logs y eliminar contenedores e imágenes con simples clics de ratón.
• Kubernetes Integrado: Incluye un clúster local de Kubernetes listo para activar con un solo checkbox para pruebas avanzadas.
• Soporte de WSL2: En Windows se ejecuta de manera transparente apoyándose sobre el subsistema WSL2 (Windows Subsystem for Linux 2), garantizando que el motor de Docker corra sobre un kernel Linux real optimizado.

Vía 2: Docker Engine (Linux Nativo)

Es el estándar indiscutible en servidores, nubes públicas y estaciones de trabajo con Linux (Ubuntu, Debian, Fedora, Arch Linux, CachyOS):

• 100% Terminal: Sin interfaces gráficas pesadas consumiendo memoria en segundo plano.
• Rendimiento puro (Bare-Metal): Al ejecutarse de forma nativa sobre el kernel Linux anfitrión, la sobrecarga es literalmente del 0%.
• Instalación mediante repositorios oficiales o con el script automatizado oficial: bash curl -fsSL https://get.docker.com -o get-docker.sh && sh get-docker.sh

Configuración Esencial en Linux: Evitar el Uso de sudo

Por defecto, el socket de comunicación de Docker (/var/run/docker.sock) pertenece al usuario root. Si intentas ejecutar docker ps, recibirás un error de permisos denegados salvo que antepongas sudo.

Para trabajar con total comodidad y seguridad, añade tu usuario al grupo de sistema docker:

# Añadir el usuario actual al grupo docker
sudo usermod -aG docker $USER

# Actualizar el grupo en la sesión de terminal activa
newgrp docker

# Probar que tenemos acceso directo sin sudo
docker ps

3. Docker Hub y Variantes de Imágenes (Tags)

Antes de crear imágenes desde cero, la inmensa mayoría de proyectos parten de una imagen base existente. El lugar de referencia es Docker Hub (hub.docker.com), la tienda oficial de software para desarrolladores y administradores de sistemas:

En Docker Hub encontrarás imágenes oficiales de los stacks más populares: Python, Nginx, PostgreSQL, Ubuntu, Redis, Node.js, etc. Sin embargo, al buscar una imagen como python te toparás con decenas de versiones y etiquetas (tags). Saber elegir el tag adecuado es crucial:

Imágenes Base Completas: latest, debian, ubuntu

• latest / default (ejemplo: python:3.12): Basada en una distribución Linux completa como Debian Bookworm o Ubuntu LTS.
• Ventajas: Incluye compiladores (gcc, g++), herramientas de diagnóstico (curl, wget, net-tools), librerías compartidas y soporte exhaustivo de dependencias.
• Inconvenientes: Su tamaño oscila entre los 800 MB y 1.2 GB. Para entornos de desarrollo o prototipado rápido es muy cómoda, pero resulta excesivamente pesada e introduce mayor superficie de ataque para desplegar en producción.

Imágenes Base Ligeras: alpine vs slim

Para entornos de producción queremos imágenes pequeñas, rápidas de transferir y seguras. Aquí entran en juego las dos variantes estrella:

• alpine (ejemplo: python:3.12-alpine): Construida sobre Alpine Linux, una distribución orientada a la máxima seguridad y ligereza.
• Tamaño mínimo: Apenas pesa entre 5 MB y 50 MB.
• Particularidad: Utiliza la librería estándar de C musl libc en lugar de la tradicional glibc. En aplicaciones de Go o Node.js vuela, pero en Python, si requieres compilar paquetes científicos complejos con extensiones en C (como numpy o pandas), puede requerir dependencias de compilación adicionales o tiempos de build más altos.
• slim (ejemplo: python:3.12-slim): Es la opción preferida por la mayoría de ingenieros en producción. Mantiene la base de Debian pero despojada de utilidades secundarias, documentación y paquetes superfluos.
• Tamaño equilibrado: Pesa entre 120 MB y 180 MB.
• Ventajas: Conserva la compatibilidad al 100% de glibc, lo que significa que cualquier rueda binaria (wheel) de Python se instala al instante sin dolores de cabeza.

4. La Santísima Trinidad: Dockerfile ➔ Imagen ➔ Contenedor

Para dominar el flujo de trabajo con Docker solo necesitas interiorizar la relación causa-efecto entre tres elementos fundamentales:

1. Dockerfile (La Receta / El Código Fuente): Es un archivo de texto plano sin extensión donde describes paso a paso las instrucciones necesarias para ensamblar el entorno: qué sistema base usar, qué dependencias instalar, qué carpetas copiar y qué comando debe iniciarse.
2. Imagen (El Plato Cocinado / El Paquete Inmutable): Se crea ejecutando docker build. Es un paquete binario estático, de sólo lectura y compuesto por capas superpuestas. No cambia una vez construido y se puede almacenar localmente o subir a Docker Hub.
3. Contenedor (La Instancia Viva / El Proceso en Ejecución): Se crea ejecutando docker run. Es una instancia activa y en ejecución de una imagen. Añade una fina capa de lectura/escritura en la parte superior y puedes levantar decenas de contenedores paralelos e idénticos a partir de una única imagen.

Anatomía de un Dockerfile Real

Veamos cómo se traduce esta receta en un archivo Dockerfile para una aplicación web moderna:

# 1. Definir la imagen base ligera
FROM python:3.12-slim

# 2. Establecer el directorio de trabajo dentro del contenedor
WORKDIR /app

# 3. Aprovechar la caché de capas de Docker: copiamos primero solo los requerimientos
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

# 4. Copiar el resto del código fuente del proyecto
COPY . .

# 5. Comando que se ejecutará al iniciar el contenedor
CMD ["python", "main.py"]

⚡ Truco de Optimización (Layer Caching): Observa que primero copiamos requirements.txt y ejecutamos pip install, y sólo después copiamos el código fuente con COPY . .. Al hacer esto, si modificas una línea en tu código de Python, Docker no reinstalará todas las dependencias desde cero; reutilizará la capa en caché y compilará la imagen en milisegundos.

5. Práctica en Terminal: Los Comandos Imprescindibles

Pongamos en práctica estos conceptos ejecutando nuestros primeros contenedores desde la terminal de comandos:

Desplegar un Servidor Web Nginx

Supongamos que queremos levantar un servidor web Nginx con un único comando:

docker run -d -p 8080:80 --name mi-servidor nginx

¿Qué significa cada uno de estos argumentos clave? * docker run: Le indica a Docker que busque la imagen nginx. Si no la tiene en el disco local, la descarga automáticamente de Docker Hub y arranca el contenedor. * -d (Detached mode): Ejecuta el contenedor en segundo plano, liberando tu terminal inmediatamente para seguir trabajando. * -p 8080:80 (Port Mapping / Reenvío de Puertos): Los contenedores tienen su propia red interna aislada. Con esta directiva le decimos a Docker: «Toma las peticiones que lleguen al puerto 8080 de mi máquina física (Host) y redirígelas al puerto 80 interno del contenedor». Si abres http://localhost:8080 en tu navegador web, la página de bienvenida de Nginx responderá al instante. * --name mi-servidor: Asigna un nombre legible y fácil de recordar para interactuar con él en lugar de usar un identificador hash aleatorio.

Comandos de Ciclo de Vida Cotidiano

A continuación tienes la chuleta con las órdenes que utilizarás a diario:

# Listar los contenedores que están actualmente en ejecución
docker ps

# Listar TODOS los contenedores (incluyendo los que han finalizado o están parados)
docker ps -a

# Detener de forma ordenada un contenedor
docker stop mi-servidor

# Volver a iniciar un contenedor que estaba detenido
docker start mi-servidor

# Ver los logs y salidas estándar de un contenedor en tiempo real
docker logs -f mi-servidor

# Entrar a una sesión interactiva de terminal dentro del contenedor
docker exec -it mi-servidor bash

# Eliminar un contenedor (debe estar detenido primero)
docker rm mi-servidor

# Eliminar la imagen del disco local
docker rmi nginx

🧹 Mantenimiento y Recuperación de Espacio: Con el paso de las semanas, los contenedores de prueba parados y las capas de imágenes huérfanas pueden ocupar decenas de gigabytes. Para limpiar todo lo que no esté en uso de una sola vez: bash docker system prune -a --volumes

6. Persistencia y Redes: Volúmenes y Comunicación entre Contenedores

En aplicaciones del mundo real nos enfrentamos a dos retos indispensables: dónde almacenar los datos y cómo comunicar servicios entre sí.

Persistencia de Datos con Volúmenes (-v)

Por diseño, el sistema de archivos de un contenedor es efímero: si borras un contenedor de PostgreSQL, la base de datos y toda la información almacenada en su interior desaparecerán para siempre con él.

Para evitar la pérdida de datos, utilizamos Volúmenes de Docker. Un volumen es un directorio en el sistema de archivos del anfitrión administrado por Docker que sobrevive a la vida de los contenedores:

# 1. Crear un volumen persistente
docker volume create datos_postgres

# 2. Montar el volumen en el directorio de datos del contenedor
docker run -d   --name db-produccion   -v datos_postgres:/var/lib/postgresql/data   -e POSTGRES_PASSWORD=mi_clave_secreta   postgres:16-alpine

Aunque detengas el contenedor, lo elimines o actualices la versión de PostgreSQL a una más reciente, la información permanece íntegra en el volumen datos_postgres.

Redes Aisladas (docker network): Comunicación entre Servicios

Imagina que tienes una API en Python que necesita consultar la base de datos PostgreSQL. Nunca debes exponer el puerto de la base de datos al exterior con -p 5432:5432 por motivos elementales de seguridad.

En su lugar, conectamos ambos contenedores a una red interna privada (Bridge Network):

# 1. Crear una red privada interna
docker network create red-interna

# 2. Desplegar la base de datos conectada a la red
docker run -d --name mi-bd --network red-interna postgres:16-alpine

# 3. Desplegar la API en la misma red
docker run -d --name mi-api --network red-interna -p 3000:3000 mi-api:latest

Docker integra un servidor DNS interno automático. En el código de tu API, la dirección del host de la base de datos es simplemente el nombre del contenedor: host: "mi-bd". No necesitas preocuparte por direcciones IP dinámicas.

7. Rendimiento y Métricas Reales en Producción

Frente a la creencia errónea de que añadir capas de abstracción ralentiza el sistema, los datos de telemetría demuestran la extrema eficiencia de la contenerización frente a las máquinas virtuales:

• Tiempo de Arranque (Boot Time):
• Máquina Virtual: 2 a 5 minutos (inicialización de BIOS, kernel y servicios systemd).
• Contenedor Docker: Menos de 300 milisegundos. Es prácticamente instantáneo porque el kernel ya está en memoria y solo arranca el proceso de tu aplicación.
• Consumo de Memoria RAM en Reposo:
• Máquina Virtual: 2 GB a 4 GB reservados obligatoriamente para el sistema operativo invitado.
• Contenedor Docker: 15 MB a 45 MB de memoria en reposo. Solo consume lo que su código requiere.
• Sobrecarga en CPU (Overhead):
• Máquina Virtual: Penalización del 5% al 15% por la capa de traducción del hipervisor.
• Contenedor Docker: 0% de sobrecarga. Las instrucciones se ejecutan directamente en la CPU mediante llamadas de sistema (syscalls) nativas del kernel anfitrión.

Para comprobar el rendimiento y uso de hardware de tus contenedores en tiempo real, ejecuta en cualquier momento:

docker stats

Resumen de Buenas Prácticas

1. Utiliza siempre un archivo .dockerignore: Evita que carpetas enormes como node_modules/, directorios virtuales .venv/, .git/ o ficheros de contraseñas .env se copien accidentalmente dentro de la imagen.
2. Prioriza imágenes base slim o alpine: Reducirás radicalmente los tiempos de descarga por red, ahorrarás espacio en disco y minimizarás vulnerabilidades potenciales (CVEs).
3. Optimiza la caché de capas en tu Dockerfile: Coloca las instrucciones que cambian con menor frecuencia al principio (instalación de paquetes del sistema, pip install, npm install) y el código de tu proyecto al final.
4. Evita correr procesos como usuario root en producción: Agrega directivas USER nonroot en tu Dockerfile para blindar la seguridad en caso de brechas de aplicación.
5. Un proceso principal por contenedor: Respeta la filosofía Unix: un contenedor para el servidor web, otro para la API y otro para la base de datos. Esto permite reiniciar y escalar servicios de forma independiente.

Vídeo Completo del Curso

Si quieres ver todas estas animaciones en movimiento, con explicaciones detalladas y la terminal en vivo paso a paso, te dejamos el vídeo completo a continuación:

En la siguiente entrega profundizaremos en Docker Compose para orquestar infraestructuras completas multi-servicio con un único archivo declarativo compose.yaml. Si te ha servido esta guía o tienes dudas con tu primer contenedor, ¡déjanos un comentario y te leemos!