Docker Compose na Prática

A Anatomia do Docker Compose: O Fim dos Scripts de Terminal Kaóticos

No início da adoção da conteinerização em sistemas web ou portais SaaS, o uso do Docker bruto apoia-se em rodar comandos isolados no terminal (docker run). Contudo, à medida que a inteligência comercial expande-se para arquiteturas baseadas em microsserviços ou monólitos modulares acoplados a bancos relacionais SQL (OLTP) e buffers de mensagerias assíncronas, gerenciar o ecossistema manualmente gera o caos.

Os desenvolvedores juniores veem-se forçados a digitar strings quilométricas no terminal para configurar volumes de mídias, mapeamentos de portas de hardwares, chaves de links de redes e variáveis de runtime de cada container separadamente. Esquecer um único caractere ou inverter a ordem de inicialização quebra os handshakes de redes locais, paralisando as esteiras e gerando débitos técnicos crônicos.

O **Docker Compose** erradica essa fragilidade operacional traduzindo toda a arquitetura de topologia de serviços em **Infraestrutura como Código (IaC)**. Toda a especificação da pilha reside em um arquivo de texto declarativo versionado no Git. O terminal deixa de ser um diário de comandos manuais e passa a ser controlado por gatilhos universais reativos rápidos, poupando a sanidade dos times e escalando a governança técnica de TI corporativa.

O Arquivo docker-compose.yml de Elite para Produção/Desenvolvimento

Para marcas em fase de digitalização madura e CTOs exigentes, estruturar o arquivo YAML exige premissas severas de código limpo, separação de sub-redes e Hardening. Abaixo está modelada a arquitetura declarativa de uma stack enterprise de alta performance — aglutinando proxy reverso de borda (**Nginx**), runtime backend (**API**), banco relacional (**PostgreSQL**) e camada de cache RAM (**Redis**) — imune a conflitos de portas de hardware:

version: '3.8'

services:
  # 1. A Camada de Borda: Escudo Proxy Reverso e Terminação Web
  nginx_proxy:
    image: nginx:alpine
    container_name: enterprise_nginx_borda
    restart: always
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./infra/nginx/nginx.conf:/etc/nginx/nginx.conf:ro
      - ./public:/var/www/html/public:ro
    depends_on:
      api_backend:
        condition: service_healthy # Só inicializa o Nginx quando a API passar nos exames de saude
    networks:
      - rede_borda_publica
      - rede_interna_privada

  # 2. A Camada de Aplicação: Core Backend Stateless
  api_backend:
    build:
      context: .
      dockerfile: ./infra/docker/Dockerfile
    container_name: enterprise_api_core
    restart: always
    environment:
      - APP_ENV=production
      - DB_HOST=postgres_banco # Conecta via nome semântico resolvido pelo DNS do Compose
      - REDIS_HOST=redis_cache
    env_file:
      - .env.production.secrets # Injeta segredos colhidos de cofres na esteira de CD
    volumes:
      - .:/var/www/html:ro # Trava de segurança: código em modo de leitura exclusiva (ro)
      - storage_mutavel:/var/www/html/storage
    healthcheck:
      test: ["CMD", "php", "artisan", "octane:status"] # Ou endpoint /api/health
      interval: 10s
      timeout: 5s
      retries: 3
    networks:
      - rede_interna_privada

  # 3. A Camada de Aceleração Computacional: Cache em Memória RAM
  redis_cache:
    image: redis:alpine
    container_name: enterprise_redis_buffer
    command: redis-server --requirepass ${REDIS_PASSWORD_SECRET}
    restart: always
    networks:
      - rede_interna_privada

  # 4. A Camada de Persistência de Missão Crítica: Banco Relacional ACID
  postgres_banco:
    image: postgres:16-alpine
    container_name: enterprise_postgres_db
    restart: always
    environment:
      POSTGRES_DB: stack_corporativa
      POSTGRES_USER: usuario_enterprise
      POSTGRES_PASSWORD: ${DB_PASSWORD_SECRET} # Puxa do ambiente local da maquina do host
    volumes:
      - dados_postgres_disco:/var/lib/postgresql/data
    networks:
      - rede_interna_privada

# Definição e Isolamento Estrutural das Redes Lógicas Privadas (VPCs Locais)
networks:
  rede_borda_publica:
    driver: bridge
  rede_interna_privada:
    driver: bridge
    internal: true # Bloqueia fisicamente o acesso desta rede com a internet publica

# Definição de Storages Persistentes Isolados da Efemeridade de Containers
volumes:
  storage_mutavel:
    driver: local
  dados_postgres_disco:
    driver: local

Diretivas Críticas de Engenharia: Redes, Volumes e Dependências

Dominar o Docker Compose exige compreender o comportamento de runtime e a ordem de precedência que o motor aplica ao orquestrar os nós de hardware na nuvem elástica:

• O Mecanismo de DNS e Redes Isoladas (Networks): Quando o Docker Compose inicializa a stack, ele cria de forma automática uma rede privada virtual baseada no driver **Bridge**. Cada serviço vira um nó em um grafo. O Docker injeta um servidor de DNS interno em memória RAM; isso permite que a api_backend encontre e faça conexões Server-to-Server com o banco de dados simplesmente apontando para a string de host postgres_banco, eliminando o acoplamento burro de IPs estáticos. Configurar a diretiva internal: true (como feito na rede interna) cria uma **jaula de rede opaca** sem rota de saída para a internet, paralisando vazamentos horizontais de Big Data.
• Salvaguarda de Discos contra a Efemeridade (Volumes): Como a camada de escrita de contêineres Docker é volátil, deletar um container expurga todos os dados de produção criados em runtime. A declaração do nó mestre volumes cria repositórios de storages persistentes imutáveis gerenciados de forma externa pelo Linux hospedeiro. O banco de dados ou mídias de cadastros escrevem diretamente no volume estruturado, garantindo RTO próximo a zero mesmo em deploys avançados.
• Sincronização de Inicialização Dinâmica (depends_on): A diretiva simples depends_on antiga limitava-se a ditar a ordem sequencial de subida de processos no hardware de forma ingênua. O Compose moderno estendeu o recurso acoplando a cláusula **healthcheck**. Ao usar condition: service_healthy, o Nginx de borda só receberá permissão de abrir suas portas HTTP lícitas públicas na internet quando o robô validador de saúde da API backend responder com sucesso em runtime, eliminando o incidente crônico de conexões órfãs perdidas durante reinicializações.

Segurança da Informação, DevSecOps, Gestão de Segredos e LGPD

Orquestrar múltiplos containers que manipulam e cruzam massas críticas de Informações Pessoais Identificáveis (PII) de clientes (Nomes, e-mails corporativos, CPFs, registros de faturamentos contábeis) sem a aplicação rigorosa de diretrizes severas de segurança da informação transforma a TI do negócio em vetor de incidentes cibernéticos drásticos. Sob a égide da LGPD no Brasil, blindar o ecossistema digital sob as regras de *Privacy por Design* é mandatório de fábrica.

A esteira de DevSecOps e segurança da informação deve aplicar três travas de Hardening de dados no arquivo do Compose:

• Bane-se o Mapeamento Indiscriminado de Portas (Port Isolation): O maior erro de equipes juniores ao estruturarem arquivos do Compose consiste em expor a porta de todos os serviços para a máquina hospedeira host (Ex: injetar "5432:5432" no Postgres ou "6379:6379" no Redis). Essa falha de design escancara as portas dos bancos operacionais para varreduras externas de redes públicas. **Apenas o proxy Nginx de borda deve expor portas públicas (80 e 443)**. O banco de dados e os caches RAM permanecem ocultos e acessíveis exclusivamente de forma internaServer-to-Server via chaves lógicas na sub-rede privada, aplicando o princípio do privilégio mínimo.
• Gestão Dinâmica de Segredos sem Hardcoded Secrets: Nunca fixe senhas duras ou tokens lúdicos de acessos abertos textualmente dentro das linhas do arquivo docker-compose.yml versionado no Git. Utilize a interpolação de variáveis nativa do Compose (como ${DB_PASSWORD_SECRET}). Na esteira de integração contínua (CI/CD), as chaves são colhidas em cofres digitais elásticos (AWS Secrets Manager ou HashiCorp Vault) e injetadas na memória RAM temporária de runtime exclusivamente como variáveis de ambiente durante o deploy de containers Docker, preservando o valor jurídico.
• Trilhas de Logs de Auditoria Centralizadas e Observabilidade SRE: Toda subida de stack, erro de healthcheck ou transação fiscal regulada deve registrar metadados analíticos e carimbos de data/hora (Timestamp) consistentes. Configure os drivers de logs do Compose redirecionando os streams para coletores externos do **OpenTelemetry**. Indexar essas telemetrias temporais em dashboards visuais no **Grafana** alimentados pelo **Prometheus** reduz o indicador de MTTR a patamares submilissegundos e fornece evidências materiais irrefutáveis de governança técnica em fiscalizações regulatórias da ANPD (Direito ao Esquecimento).