Volumes, networks e isolamento

Objetivos

• Configurar persistência de dados com volumes nomeados
• Controlar comunicação entre serviços usando rede Docker
• Aplicar isolamento para reduzir acoplamento acidental

Pré-requisitos

• Conclusão da aula anterior (manifestos, código e Dockerfiles dos cinco serviços)
• Docker instalado e funcionando
• Cinco serviços com endpoint /health validado via docker build + curl

Conceito

Quando você reinicia containers sem volumes, perde dados de brokers e bancos locais. Em um curso de microsserviços isso quebra fluxo didático, porque cada etapa depende da anterior. Volumes nomeados deixam o ambiente reiniciável sem apagar tudo.

A rede Docker também é parte da arquitetura. Dentro do Compose, os serviços se encontram pelo nome (order-service, kafka, redis) e não por localhost. Esse detalhe evita erro clássico de conexão e aproxima seu ambiente local de produção.

Isolamento não significa impedir comunicação, e sim controlar por onde ela acontece. Com uma rede explícita e variáveis de ambiente corretas, cada serviço fala apenas com o que precisa, reduzindo efeito cascata em mudanças futuras.

Estrutura de arquivos

infra/
  docker-compose.yml
services/
  order-service/.env
  payment-service/.env
  notification-service/.env

Passo a passo

1. Criar rede e volumes no infra/docker-compose.yml

version: "3.9"
services:
  kafka:
    image: bitnami/kafka:3.7
    ports:
      - "9092:9092"
    environment:
      - KAFKA_CFG_NODE_ID=1
      - KAFKA_CFG_PROCESS_ROLES=broker,controller
      - KAFKA_CFG_CONTROLLER_QUORUM_VOTERS=1@kafka:9093
      - KAFKA_CFG_LISTENERS=PLAINTEXT://:9092,CONTROLLER://:9093
      - KAFKA_CFG_ADVERTISED_LISTENERS=PLAINTEXT://kafka:9092
      - KAFKA_CFG_LISTENER_SECURITY_PROTOCOL_MAP=PLAINTEXT:PLAINTEXT,CONTROLLER:PLAINTEXT
      - KAFKA_CFG_CONTROLLER_LISTENER_NAMES=CONTROLLER
      - KAFKA_CFG_LOG_DIRS=/bitnami/kafka/data
    volumes:
      - kafka_data:/bitnami/kafka
    networks:
      - aprendi_net

  redis:
    image: redis:7.2-alpine
    ports:
      - "6379:6379"
    volumes:
      - redis_data:/data
    networks:
      - aprendi_net

volumes:
  kafka_data:
  redis_data:

networks:
  aprendi_net:
    name: aprendi_net

2. Ajustar variáveis de ambiente no order-service/.env

KAFKA_BROKERS=kafka:9092
REDIS_HOST=redis
REDIS_PORT=6379

3. Ajustar variáveis no payment-service/.env

KAFKA_BROKERS=kafka:9092
REDIS_HOST=redis
REDIS_PORT=6379

4. Garantir que o app usa os hosts da rede Docker (exemplo FastAPI)

import os

KAFKA_BROKERS = os.getenv("KAFKA_BROKERS", "kafka:9092")
REDIS_HOST = os.getenv("REDIS_HOST", "redis")
REDIS_PORT = int(os.getenv("REDIS_PORT", "6379"))

Como testar

1. Subir infraestrutura:

docker compose -f infra/docker-compose.yml up -d kafka redis

2. Validar rede e volumes:

docker network inspect aprendi_net
docker volume ls | rg "kafka_data|redis_data"

3. Testar conectividade a partir de um container temporário:

docker run --rm --network aprendi_net alpine:3.20 sh -c "apk add --no-cache busybox-extras >/dev/null && nc -zv kafka 9092 && nc -zv redis 6379"

Saída esperada contém:

kafka (172.x.x.x:9092) open
redis (172.x.x.x:6379) open

Dicas de projeto

• Use nomes de serviço do Compose, nunca localhost, para tráfego interno.
• Trate volume de dados como parte do setup mínimo de desenvolvimento.
• Evite expor portas externas que você não usa.
• Documente quais serviços dependem de Kafka/Redis e por quê.

Erros comuns

• Montar volume em caminho diferente do que o processo realmente usa.
• Configurar broker com advertised.listeners inválido.
• Misturar host de desenvolvimento (localhost) com host interno (kafka).
• Remover volumes sem querer e perder estado que o fluxo depende.

Resumo

Com rede e volumes bem configurados, seu ambiente local deixa de ser descartável e passa a representar um sistema distribuído real. Isso dá estabilidade para avançar em APIs, eventos e fluxos de negócio.