Padrões de Docker Compose para Produção

1. Visão geral do conceito e problema sistêmico

Muitos desenvolvedores utilizam o Docker Compose apenas localmente, considerando-o uma "ferramenta de desenvolvimento", enquanto em produção tentam implantar clusters pesados ou, inversamente, executam tudo manualmente no host via pm2 ou nohup:

• Sem limites de memória, um processo travado vaza recursos e aciona o OOM-killer do Linux, que mata o banco de dados.
• Os logs de um único container podem crescer para 50 GB em 3 meses, preenchendo todo o espaço livre da partição raiz /, paralisando o servidor.
• Os containers estão na mesma rede compartilhada bridge, permitindo que um serviço web comprometido tenha acesso direto às portas internas do banco de dados.

Production-Grade Docker Compose é uma coleção de padrões de engenharia comprovados que transformam um único arquivo docker-compose.prod.yml em uma plataforma confiável, segura e resiliente a falhas catastróficas.

2. Taxonomia arquitetural e modelo mental

┌─────────────────────────────────────────────────────────────┐
│              TOPOLOGIA DE PRODUÇÃO DOCKER COMPOSE           │
├─────────────────────────────────────────────────────────────┤
│ 1. REDES INTERNAS SEPARADAS                                 │
│    • `public-network`: Apenas Traefik/Caddy ➔ Web App (Porta 80/443)│
│    • `backend-network`: Apenas Web App ➔ Banco de Dados Postgres & Redis  │
│    ➔ O banco de dados está fisicamente isolado do mundo externo!   │
├─────────────────────────────────────────────────────────────┤
│ 2. CONTROLES DE RESILIÊNCIA E CICLO DE VIDA                 │
│    • `restart: unless-stopped` (Inicialização automática após reinicialização do VPS) │
│    • Healthchecks: `test: ["CMD", "curl", "-f", "/health"]` │
│    • Depends_on com condição: `service_healthy`             │
├─────────────────────────────────────────────────────────────┤
│ 3. LIMITES RÍGIDOS DE RECURSOS (Prevenção de Falha do Host) │
│    • Limite de memória: `max: 2G` | CPU: `1.5` núcleos      │
│    • Rotação de Logs: `max-size: 10m` | `max-file: 3`       │
└─────────────────────────────────────────────────────────────┘

3. Cenários práticos de engenharia em produção

01. Fragmento de referência para produção com 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. Armadilhas, erros comuns e segurança

• Exposição das portas do banco de dados para a internet: O uso da diretiva ports: ["5432:5432"] abre automaticamente a porta em todas as interfaces públicas, contornando até mesmo o firewall UFW (devido à especificidade do iptables do Docker). Use expose: ["5432"] ou vincule a porta exclusivamente ao localhost: 127.0.0.1:5432:5432.
• Perda de dados devido a volumes anônimos (Anonymous Volumes): Se esquecer de especificar um volume nomeado (volumes: pgdata:/data), durante o comando docker compose down -v o banco de dados será destruído irreversivelmente.

5. Conclusão estratégica para o engenheiro de 2026

Um Docker Compose corretamente configurado é a canivete suíço do DevOps prático. Ele garante máxima resiliência sem os custos operacionais do Kubernetes, permitindo que a equipe foque na velocidade de desenvolvimento do produto.