¿Cómo desplegar un proyecto real con Docker en producción?

Desplegar un proyecto real con Docker en producción significa llevar tus contenedores a un servidor Linux accesible desde internet, con configuraciones de seguridad, reinicio automático y monitoreo básico.

El momento de la verdad

Imagina que trabajas en una startup de e-commerce en Guadalajara. Llevas semanas construyendo una API para gestionar pedidos. En tu laptop todo funciona perfecto. Pero cuando llega el momento de publicarla para que los clientes reales la usen, el equipo no sabe por dónde empezar. Ese salto de "funciona en mi máquina" a "funciona en producción" es exactamente lo que resolverás en esta lección.

Estás en la lección 9 de 9. Todo lo que aprendiste — imágenes, contenedores, volúmenes, redes, docker-compose y Docker Hub — se une aquí en un solo flujo real.

El Sistema SDRS: Servidor, Despliegue, Reinicio y Supervisión

Para producción, usarás el Sistema SDRS: cuatro capas que garantizan que tu aplicación esté disponible, sea segura y se recupere sola ante fallos.

• Servidor: configura el entorno Linux correctamente.
• Despliegue: lleva tu imagen al servidor y levanta los servicios.
• Reinicio: configura el reinicio automático para sobrevivir cortes de luz o reinicios del sistema.
• Supervisión: monitorea que los contenedores estén corriendo.

Sigue estas cuatro capas en orden y tendrás un despliegue profesional.

Capa 1 — Preparar el Servidor Linux

Usa un servidor Ubuntu 22.04. Puedes rentar uno en DigitalOcean o Linode desde $150 al mes. Una vez dentro, instala Docker con estos comandos:

sudo apt update
sudo apt install -y docker.io docker-compose
sudo systemctl enable docker
sudo systemctl start docker

El comando systemctl enable docker es clave. Le dice al sistema que Docker debe arrancar automáticamente cada vez que el servidor reinicie. Sin esto, un corte de energía en el datacenter apaga tus contenedores para siempre.

También crea un usuario sin permisos de root para correr Docker:

sudo useradd -m deployuser
sudo usermod -aG docker deployuser

Nunca corras tu aplicación como root en producción. Si un atacante compromete el contenedor, no quieres que tenga control total del servidor.

Capa 2 — Desplegar tu Aplicación

En tu servidor, crea una carpeta para el proyecto:

mkdir ~/mi-app && cd ~/mi-app

Aquí no copies el código fuente. Solo necesitas el archivo docker-compose.yml y un archivo .env con las variables de entorno. Recuerda: la imagen ya está en Docker Hub gracias a la lección anterior.

Ejemplo de docker-compose.yml para producción:

version: '3.9'

services:
  api:
    image: miusuario/pedidos-api:1.0
    restart: always
    ports:
      - "8080:3000"
    env_file:
      - .env
    networks:
      - red-produccion
    depends_on:
      - db

  db:
    image: postgres:15
    restart: always
    volumes:
      - datos-db:/var/lib/postgresql/data
    env_file:
      - .env
    networks:
      - red-produccion

volumes:
  datos-db:

networks:
  red-produccion:

Observa la línea restart: always. Esto es parte de la capa R del sistema SDRS. Si el contenedor falla o el servidor reinicia, Docker lo levanta solo sin que nadie tenga que intervenir.

Luego, levanta todo con:

docker-compose up -d

El flag -d lo corre en segundo plano. Tu terminal queda libre y los contenedores siguen corriendo.

Capa 3 — Opciones de Reinicio Automático

Docker tiene cuatro políticas de reinicio. Conocerlas te evita sorpresas:

Para producción, usa unless-stopped si quieres control manual. Usa always si prefieres que el sistema sea completamente autónomo. En el ejemplo de la API de pedidos, unless-stopped es la mejor opción: reinicia solo si hubo un fallo, pero respeta cuando tú decides detenerlo para un mantenimiento.

Cambia la política así en el docker-compose.yml:

restart: unless-stopped

Capa 4 — Monitoreo Básico de Contenedores

Un contenedor puede estar "corriendo" pero sin responder peticiones reales. Para supervisarlo, tienes tres herramientas nativas de Docker.

Ver el estado de los contenedores:

docker ps

Te muestra qué contenedores están activos, cuánto tiempo llevan corriendo y qué puertos exponen.

Ver el consumo de recursos en tiempo real:

docker stats

Esto imprime CPU, RAM, red y disco de cada contenedor. Si tu API de pedidos consume más del 80% de RAM de forma constante, necesitas escalar o revisar fugas de memoria.

Ver los logs del contenedor:

docker logs nombre-contenedor --tail 50 -f

El flag --tail 50 muestra las últimas 50 líneas. El flag -f sigue el log en vivo, como tail -f en Linux. Si un cliente reporta un error a las 3pm, aquí encontrarás exactamente qué pasó.

Buenas Prácticas de Seguridad en Producción

Antes de dar por terminado el despliegue, revisa esta lista:

1. Nunca pongas credenciales en el docker-compose.yml. Usa siempre un archivo .env separado. Ese archivo jamás debe subirse a GitHub. Agrégalo al .gitignore:

.env

2. Limita los puertos expuestos. Solo expón el puerto que necesitas. Si tu base de datos solo la usa la API internamente, no expongas su puerto al exterior. En el ejemplo anterior, db no tiene ports definido. Se comunica con api a través de red-produccion sin ser accesible desde internet.

3. Usa versiones fijas en tus imágenes. Escribe postgres:15 en lugar de postgres:latest. En producción, una actualización automática de imagen puede romper compatibilidad sin aviso.

4. Revisa el uso de recursos regularmente. Un servidor de $300 al mes en DigitalOcean con 2GB de RAM puede sostener fácilmente una API con base de datos. Pero si agregas tres servicios más sin monitorear, te quedarás sin memoria.

Ejemplo Completo: API de Inventario para una Tienda

Supón que una tienda mediana en Ciudad de México usa tu API para consultar inventario en tiempo real. El equipo ya publicó la imagen inventarios/api-tienda:2.1 en Docker Hub.

El .env en producción contiene:

POSTGRES_USER=admin
POSTGRES_PASSWORD=clave-segura-123
POSTGRES_DB=inventarios
PORT=3000

El docker-compose.yml ya está en el servidor. El equipo ejecuta:

docker-compose pull   # Descarga la imagen más reciente
docker-compose up -d  # Levanta los servicios
docker ps             # Confirma que todo está corriendo

Tres comandos. El sistema está en producción. Si el servidor reinicia a las 3am por una actualización del datacenter, Docker levanta los contenedores solo y nadie tiene que despertar.

Lo Que Aprendiste en Todo el Curso

En estas nueve lecciones construiste una base sólida:

1. Imágenes y contenedores: la diferencia entre el plano y el edificio.
2. Dockerfile: instrucciones para construir tu propia imagen.
3. Volúmenes: persistencia de datos fuera del contenedor.
4. Redes: comunicación segura entre servicios.
5. Docker Compose: orquestación de múltiples contenedores con un solo archivo.
6. Docker Hub: publicar y compartir imágenes en la nube.
7. Producción: desplegar con seguridad, reinicio automático y monitoreo.

Tu siguiente paso práctico: toma un proyecto real, aunque sea pequeño, y despliégalo siguiendo el Sistema SDRS. Puede ser una API personal, un bot de Telegram o un scraper de precios. Lo que importa es hacer el ciclo completo una vez.

Docker no se aprende leyendo. Se aprende desplegando.

El desarrollador que sabe llevar código a producción con confianza no solo programa: construye sistemas que funcionan cuando nadie los está mirando.