Redes no Docker: bridge, host e overlay

1. Introdução às Redes no Docker

No ecossistema DevOps, a comunicação entre containers é um dos pilares para construir aplicações distribuídas escaláveis. O Docker oferece um modelo de rede flexível que permite isolar, conectar e gerenciar a comunicação entre containers, sejam eles executando em um único host ou em um cluster.

O Docker possui cinco drivers de rede nativos:

  • bridge: rede privada padrão para containers no mesmo host
  • host: compartilha o namespace de rede do host diretamente
  • overlay: conecta containers em múltiplos hosts (essencial para Swarm e Kubernetes)
  • macvlan: atribui um endereço MAC real a cada container
  • none: container sem interface de rede

Cada driver atende a diferentes necessidades de isolamento, desempenho e conectividade. Vamos explorar os três principais.

2. Rede Bridge: Conectando Containers no Mesmo Host

A rede bridge é o driver padrão do Docker. Quando você inicia um container sem especificar uma rede, ele se conecta à bridge docker0.

# Verificar a bridge padrão
docker network ls
# Saída esperada: NETWORK ID NAME DRIVER SCOPE
#                     ...      bridge bridge local

# Inspecionar a bridge padrão
docker network inspect bridge

Na bridge padrão, containers se comunicam por IP interno (geralmente 172.17.0.x), mas não por nome. Para expor serviços ao mundo externo, usamos o mapeamento de portas:

# Container expondo porta 80 como porta 8080 no host
docker run -d --name web -p 8080:80 nginx

Criar uma rede bridge customizada traz vantagens significativas:

# Criar rede bridge customizada
docker network create --driver bridge minha-rede

# Containers na mesma rede podem se resolver pelo nome
docker run -d --name api --network minha-rede minha-api
docker run -d --name frontend --network minha-rede meu-frontend

# frontend pode acessar api pelo nome "api"

Com redes bridge customizadas, você obtém resolução DNS automática por nome do container, melhor isolamento e controle sobre o subnet.

3. Rede Host: Desempenho Máximo sem Isolamento de Rede

No driver host, o container compartilha o namespace de rede do host, eliminando a camada de tradução NAT e o roteamento via bridge.

# Container usando rede host
docker run -d --name servidor --network host nginx

Neste modo, o container escuta diretamente nas portas do host. Se o nginx escuta na porta 80, ela fica disponível em localhost:80 sem mapeamento.

Casos de uso:

  • Aplicações sensíveis à latência (monitoramento, proxies de alto desempenho)
  • Serviços que precisam de portas dinâmicas (como servidores VoIP)
  • Ferramentas de diagnóstico de rede executadas dentro do container

Limitações importantes:

  • Conflito de portas: dois containers na rede host não podem usar a mesma porta
  • Perda de isolamento de rede: o container tem acesso total às interfaces do host
  • Incompatibilidade com orquestração (Swarm/Kubernetes não suportam rede host para pods)

Comparação prática:

# Bridge: container tem IP próprio, precisa de -p para expor
docker run -d -p 8080:80 nginx

# Host: container usa IP do host, sem mapeamento
docker run -d --network host nginx

4. Rede Overlay: Comunicação Entre Múltiplos Hosts

Redes overlay são essenciais para clusters Docker Swarm e Kubernetes. Elas usam encapsulamento VXLAN para criar uma rede virtual que atravessa múltiplos hosts físicos.

# Inicializar o Swarm (em um nó manager)
docker swarm init

# Criar rede overlay
docker network create -d overlay --attachable minha-overlay

# Executar serviços em diferentes nós na mesma overlay
docker service create --name backend --network minha-overlay --replicas 3 minha-imagem
docker service create --name frontend --network minha-overlay --replicas 2 meu-frontend

A mágica da rede overlay:

  • Cada container recebe um IP único na overlay, independente do host onde está
  • A comunicação usa tunelamento VXLAN (porta UDP 4789)
  • A resolução DNS funciona por nome do serviço em toda a overlay
  • O tráfego é criptografado por padrão no Swarm
# Verificar nós do Swarm
docker node ls

# Escalar serviço e ver comunicação entre hosts
docker service scale backend=5

Para ambientes Kubernetes, a rede overlay é implementada pelo CNI (Container Network Interface), com soluções como Calico, Flannel e Weave.

5. Gerenciamento de Redes no Docker

Comandos essenciais para o dia a dia de um DevOps:

# Listar todas as redes
docker network ls

# Inspecionar detalhes de uma rede
docker network inspect minha-rede

# Criar rede bridge customizada
docker network create --subnet 10.10.0.0/16 --gateway 10.10.0.1 minha-rede

# Conectar container em execução a uma rede
docker network connect minha-rede meu-container

# Desconectar container de uma rede
docker network disconnect minha-rede meu-container

# Remover rede (não pode ter containers conectados)
docker network rm minha-rede

Diagnóstico de conectividade:

# Testar ping entre containers
docker exec container1 ping container2

# Testar requisição HTTP
docker exec container1 curl http://container2:8080/health

# Verificar rotas dentro do container
docker exec container1 ip route

# Verificar interfaces de rede
docker exec container1 ip addr

Boas práticas de segmentação:

# Redes separadas por camada
docker network create frontend-net
docker network create backend-net
docker network create database-net

# Container de API conectado a frontend e backend
docker network connect frontend-net api
docker network connect backend-net api

# Container de banco apenas na rede database-net
docker run -d --name db --network database-net postgres

6. Integração com Kubernetes: Redes Pod-to-Pod

No Kubernetes, cada pod recebe um IP único e todos os pods podem se comunicar sem NAT, independentemente do nó. Esse modelo é conhecido como "flat network" e é implementado por plugins CNI.

Como os drivers Docker se relacionam com CNI:

  • O driver bridge do Docker é similar ao plugin CNI bridge, usado internamente pelo kubelet
  • O driver overlay do Docker é análogo ao Flannel (VXLAN) ou Weave
  • Soluções CNI avançadas como Calico usam roteamento BGP em vez de overlay para maior desempenho

Exemplo de Service e NetworkPolicy no Kubernetes:

apiVersion: v1
kind: Service
metadata:
  name: backend-service
spec:
  selector:
    app: backend
  ports:
    - port: 80
      targetPort: 8080
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-policy
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              role: frontend
      ports:
        - port: 8080

Enquanto no Docker Swarm as políticas de rede são limitadas, no Kubernetes o NetworkPolicy oferece controle granular sobre o tráfego entre pods.

7. Segurança e Isolamento em Redes Docker

Restringindo tráfego com iptables:

O Docker gerencia regras iptables automaticamente, mas você pode adicionar regras customizadas:

# Bloquear tráfego externo para um container específico
docker run -d --name interno --network minha-rede --iptables=false minha-imagem

# Usar rede none para isolamento total
docker run -d --name isolado --network none alpine sleep 3600

Políticas de rede no Docker Swarm:

# Criar rede overlay com criptografia
docker network create -d overlay --opt encrypted minha-overlay-segura

# Apenas serviços na mesma overlay se comunicam
docker service create --name db --network minha-overlay-segura postgres
docker service create --name app --network minha-overlay-segura minha-app

No Kubernetes, o isolamento é mais robusto:

  • NetworkPolicy define regras de ingresso e egresso
  • Namespaces podem isolar ambientes (dev, staging, prod)
  • Service Mesh (Istio, Linkerd) adiciona criptografia mTLS entre pods

8. Conclusão e Boas Práticas

A escolha do driver de rede impacta diretamente o desempenho, a segurança e a escalabilidade da sua aplicação.

Checklist para escolha do driver:

Cenário Driver Recomendado
Desenvolvimento local bridge
Testes de integração bridge customizada
Aplicação sensível a latência host
Cluster multi-host (Swarm) overlay
Cluster Kubernetes CNI (Calico/Flannel)
Container totalmente isolado none

Boas práticas em pipelines DevOps:

  1. Use redes bridge customizadas com nomes descritivos
  2. Segmente ambientes por rede (frontend, backend, banco)
  3. Em produção, prefira overlay ou CNI com criptografia
  4. Documente o mapeamento de portas e redes no docker-compose.yml
  5. Teste conectividade entre containers nos testes de integração

Para orquestração com Docker Compose, defina as redes no arquivo YAML:

version: '3.8'
services:
  web:
    image: nginx
    networks:
      - frontend
  api:
    image: minha-api
    networks:
      - frontend
      - backend
  db:
    image: postgres
    networks:
      - backend
networks:
  frontend:
  backend:

Dominar as redes Docker é fundamental para qualquer profissional DevOps que trabalhe com containers e orquestração. Os conceitos de bridge, host e overlay formam a base para entender soluções mais avançadas como service mesh, políticas de rede e segurança em clusters.

Referências