Patrones de Docker Compose de Grado de Producción

1. Visión general del concepto y problema sistémico

Muchos desarrolladores utilizan Docker Compose solo localmente, considerándolo una "herramienta de desarrollo", mientras que en producción intentan desplegar clústeres pesados o, por el contrario, ejecutan todo manualmente en el host a través de pm2 o nohup:

• Sin límites de memoria, un proceso colapsado provoca un desbordamiento y activa el OOM-killer de Linux, que termina con la base de datos.
• Los logs de un solo contenedor en 3 meses crecen hasta 50 GB y llenan todo el espacio libre en la partición raíz /, paralizando el servidor.
• Los contenedores están en una red compartida bridge, por lo que un servicio web comprometido tiene acceso directo a los puertos internos de la base de datos.

Patrones de Docker Compose de Grado de Producción es una colección de patrones de ingeniería probados que transforman un solo archivo docker-compose.prod.yml en una plataforma confiable, segura y resistente a desastres.

2. Taxonomía arquitectónica y modelo mental

┌─────────────────────────────────────────────────────────────┐
│              TOPOLOGÍA DE DOCKER COMPOSE EN PRODUCCIÓN      │
├─────────────────────────────────────────────────────────────┤
│ 1. REDES INTERNAS SEPARADAS                                 │
│    • `public-network`: Solo Traefik/Caddy ➔ Aplicación Web (Puerto 80/443)│
│    • `backend-network`: Solo Aplicación Web ➔ Base de Datos Postgres & Redis │
│    ➔ ¡Base de datos físicamente aislada del mundo exterior!  │
├─────────────────────────────────────────────────────────────┤
│ 2. RESILIENCIA Y CONTROLES DEL CICLO DE VIDA                │
│    • `restart: unless-stopped` (Autoarranque tras reinicio del VPS) │
│    • Healthchecks: `test: ["CMD", "curl", "-f", "/health"]` │
│    • Depends_on con condición: `service_healthy`            │
├─────────────────────────────────────────────────────────────┤
│ 3. LÍMITES DUROS DE RECURSOS (Prevención de Caídas del Host)│
│    • Límite de memoria: `max: 2G` | CPU: `1.5` núcleos      │
│    • Rotación de Logs: `max-size: 10m` | `max-file: 3`     │
└─────────────────────────────────────────────────────────────┘

3. Pipeline técnico y mecánica interna

01. Fragmento de producción de referencia para base de datos PostgreSQL

services:
  db:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      POSTGRES_DB_FILE: /run/secrets/db_name
      POSTGRES_PASSWORD_FILE: /run/secrets/db_password
    secrets:
      - db_name
      - db_password
    volumes:
      - pgdata:/var/lib/postgresql/data
    networks:
      - internal-tier
    deploy:
      resources:
        limits:
          memory: 1536M
          cpus: "1.0"
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 10s
      timeout: 5s
      retries: 5
    logging:
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "3"

4. Escenarios prácticos de ingeniería en producción

01. Publicación de puertos de base de datos al exterior

• Publicar puertos de base de datos al exterior: Usar la directiva ports: ["5432:5432"] abre automáticamente el puerto en todas las interfaces públicas, eludiendo incluso el firewall UFW (debido a la especificidad de Docker iptables). Usa expose: ["5432"] o vincula el puerto estrictamente a localhost: 127.0.0.1:5432:5432.

02. Pérdida de datos debido a volúmenes anónimos

• Pérdida de datos a través de volúmenes no nombrados (Anonymous Volumes): Si olvidas especificar un volumen nombrado (volumes: pgdata:/data), al ejecutar el comando docker compose down -v, la base de datos será eliminada de forma irreversible.

03. Configuración de logs inadecuada

• Configuración de logs inadecuada: No establecer logging.options.max-size puede llevar a un desbordamiento del disco, afectando el rendimiento del servidor. Asegúrate de implementar límites de tamaño de logs para evitar este problema.

5. Errores comunes, trampas y seguridad

Un Docker Compose bien configurado es una navaja suiza del DevOps práctico. Proporciona máxima resiliencia sin los costos operativos de Kubernetes, permitiendo que el equipo se enfoque en la velocidad de desarrollo del producto.