Docker na prática: como escolher entre bridge, host e overlay

Começando por uma falha real

Duas da manhã. O serviço de API em produção começou a dar timeout do nada.

O contêiner tinha subido, docker ps mostrava running, o firewall estava desligado, o mapeamento de portas parecia correto e os logs do contêiner não acusavam erro. Depois de meia hora investigando, já quase no limite, encontramos a causa: o modo de rede do Docker estava errado. Usávamos a bridge padrão, mas o serviço precisava acessar o banco de dados em outro nó. Bridge só conversa dentro da mesma máquina; não atravessa hosts.

Esse caso expõe um problema bem comum: muita gente sabe que o Docker tem os modos bridge, host e overlay, mas não sabe quando usar cada um. Para ser sincero, eu também caí nessa armadilha no começo.

Depois deste texto, você terá um fluxo de decisão completo e uma tabela de benchmark para os três modos. Da próxima vez que aparecer um problema de rede, a primeira pergunta será “é uma máquina só ou vários hosts?”. Isso já evita metade da confusão.

Bridge: a escolha padrão e o rei da comunicação em uma máquina

Bridge é o modo de rede padrão do Docker.

Quando você roda docker run sem especificar --network, o contêiner é conectado automaticamente a esse modo. A ideia central é simples: o Docker cria no host uma ponte virtual chamada docker0; cada contêiner recebe um IP próprio, geralmente 172.17.x.x, e se conecta à ponte por um veth pair, uma espécie de cabo de rede virtual.

Parece abstrato? Na prática, é como tratar o contêiner como uma máquina virtual independente, dar a ele um IP privado e usar NAT, ou mapeamento de portas, para falar com o mundo externo.

Cenários indicados

Para múltiplos contêineres em um único host, Bridge é a primeira escolha.

Ambientes de desenvolvimento, testes e até muitos cenários de produção que não precisam de comunicação entre hosts funcionam bem com ele. É simples, seguro e não exige configuração extra.

Exemplo de configuração

O padrão já é Bridge, então você nem precisa declarar:

# bridge padrão, com IP automático e -p para mapear portas
docker run -d -p 8080:80 nginx

Mas existe uma pegadinha: na bridge padrão, contêineres só conseguem conversar por IP, não pelo nome do contêiner. Se você sobe dois contêineres e quer que eles se acessem, precisa consultar o IP manualmente. É chato.

Como consultar? Use docker inspect:

# Inicia dois contêineres
docker run -d --name web nginx
docker run -d --name db redis

# Verifica o IP do contêiner web
docker inspect web | grep IPAddress
# Saída: 172.17.0.2

# Dentro do contêiner db, faz ping no web usando IP
docker exec db ping 172.17.0.2

Repare: toda comunicação exige descobrir o IP antes. Se o contêiner reiniciar, o IP ainda pode mudar. Mais trabalho à toa.

A prática recomendada é criar uma bridge personalizada:

# Cria uma rede personalizada
docker network create --subnet=192.168.100.0/24 my-net

# Inicia contêineres conectados à rede personalizada
docker run -d --network my-net --name web nginx
docker run -d --network my-net --name db redis

# O contêiner web consegue fazer ping em db diretamente
docker exec web ping db

Assim, o nome do contêiner passa a funcionar como domínio. Facilita bastante. Sinceramente, isso me surpreendeu na época: achei que teria de configurar DNS manualmente, mas o próprio Docker já resolve.

Host: melhor desempenho, pior isolamento

O modo Host é meio direto ao ponto: o contêiner usa a pilha de rede do próprio host.

Não há IP independente, não há conversão NAT e não há veth pair. As interfaces de rede vistas dentro do contêiner são as interfaces do host. O desempenho fica próximo do nativo, praticamente sem custo extra.

Você pode pensar: se é tão direto, então é o mais rápido, certo? Sim. Só que o preço é perder isolamento.

Cenários indicados

Quando a aplicação é sensível a desempenho de rede, Host é a melhor opção.

Servidores de jogos, comunicação em tempo real com WebSocket ou streaming de vídeo, sistemas de trading de alta frequência: nesses casos, até dezenas de microssegundos importam. O modo Host remove boa parte desse custo.

KiloClaw - OpenClaw gerenciado para empresas: orquestração de agentes IA e roteamento inteligente

Começar →Anúncio

Outro uso é depuração de rede. Rodar tcpdump dentro do contêiner e capturar diretamente o tráfego do host, sem configuração extra, ajuda bastante na investigação.

Exemplo de configuração

É ainda mais simples: nem -p é necessário.

# modo host: o contêiner ocupa diretamente a porta 80 do host
docker run -d --network host nginx

Depois de iniciar, acessar a porta 80 do host leva diretamente ao nginx dentro do contêiner.

Alertas de risco

Mas há algumas armadilhas importantes.

Conflito de portas: se você já tem um nginx rodando no host, ocupando a porta 80, e inicia outro contêiner em modo host que também tenta usar 80, ele falha na hora.

A mensagem de erro costuma ser parecida com esta:

docker: Error response from daemon: driver failed programming external connectivity on endpoint xxx: Bind for 0.0.0.0:80 failed: port is already allocated.

A investigação é simples: primeiro verifique o uso da porta no host.

# Verifica uso da porta
netstat -tuln | grep :80
# Ou
ss -tuln | grep :80

# Verifica o processo
lsof -i :80

Se houver um processo ocupando a porta, você para esse processo ou altera a porta da aplicação no contêiner. No modo Host, não dá para resolver com -p; é preciso mudar a configuração da aplicação dentro do contêiner, por exemplo fazendo o nginx escutar em 8080.

Segurança: o contêiner consegue enxergar todas as interfaces de rede do host, incluindo rede interna, rede externa e até conexões VPN. Se o contêiner for comprometido, o atacante pode alcançar recursos de rede do host. Em produção, isso precisa ser tratado com cuidado.

Na prática, o modo Host é usado com menos frequência. Na maior parte dos casos, Bridge resolve. Mas quando aparece um gargalo real de desempenho, ou quando baixa latência é indispensável, Host vale entrar na lista, desde que você aceite o custo de isolamento.

Overlay: a resposta para comunicação entre hosts

Bridge só funciona dentro de uma máquina. Host é rápido, mas também não resolve comunicação entre hosts. Então como contêineres em vários servidores conversam entre si? Aí entra o Overlay.

Uma rede Overlay se baseia em túneis VXLAN para colocar contêineres distribuídos em hosts diferentes dentro de uma mesma rede local virtual, como se todos estivessem na mesma máquina.

Princípio central

VXLAN é a peça-chave do Overlay.

Ele encapsula o tráfego do contêiner em uma camada adicional, envia esse tráfego por um “túnel” até outro host e, no destino, remove a encapsulação antes de entregar ao contêiner correto. Esse processo de encapsular e desencapsular é feito pelo VTEP, ou VXLAN Tunnel Endpoint, que o Docker Swarm gerencia automaticamente.

Uma analogia: você envia um pacote de São Paulo para o Rio de Janeiro. A transportadora coloca seu pacote dentro de uma caixa maior, leva essa caixa pela malha logística e, no destino, abre a caixa para entregar o pacote ao destinatário. O VXLAN é essa “caixa maior”; o tráfego do contêiner é o pacote; o VTEP é a etapa de empacotar e desempacotar.

A vantagem do VXLAN é que, independentemente de como a rede física está conectada por baixo, os contêineres enxergam a mesma rede local virtual: IPs organizados e comunicação simples.

Há um pré-requisito: redes Overlay exigem um cluster Swarm ou um KV store externo, como Consul. Um Docker em uma única máquina não dá conta; é preciso coordenação entre nós.

Por que Swarm? Porque uma rede Overlay precisa gerenciar IPs de contêineres em vários hosts, conexões VTEP e informações de roteamento. Isso exige um coordenador central, e o Swarm faz esse papel. Sem Swarm, você pode usar Consul ou Etcd como KV store, mas a configuração fica mais trabalhosa.

Cenários indicados

Em um cluster Docker Swarm, Overlay é a escolha natural.

Para deploy de microsserviços entre hosts, por exemplo com o serviço Web no nó A e o banco de dados no nó B, ambos precisam se acessar. O Overlay coloca os dois na mesma rede virtual, e o nome do contêiner passa a resolver sem configuração manual de IP.

No Kubernetes existe um conceito parecido, a rede CNI, embora a configuração seja diferente. Se você usa principalmente K8s, entender o Overlay neste artigo também ajuda a compreender a lógica de rede do Kubernetes.

Exemplo de configuração, fluxo completo

Overlay é mais complexo que Bridge e Host porque exige inicializar o Swarm primeiro:

# 1. Inicializa o Swarm no primeiro host
docker swarm init --advertise-addr 192.168.1.10

# Ele retorna um join token, parecido com:
# docker swarm join --token SWMTKN-xxx 192.168.1.10:2377

# 2. Nos outros hosts, entra no Swarm copiando o comando acima
docker swarm join --token SWMTKN-xxx 192.168.1.10:2377

# 3. Cria a rede Overlay
docker network create --driver overlay --subnet=10.0.1.0/24 my-overlay

# 4. Inicia contêineres em hosts diferentes na mesma Overlay
# No nó A
docker run -d --network my-overlay --name web nginx

# No nó B
docker run -d --network my-overlay --name db redis

# 5. Testa a comunicação: web consegue fazer ping em db, entre hosts
docker exec web ping db

Na primeira vez que configurei Overlay, caí em uma pegadinha: esqueci de inicializar o Swarm e tentei criar a rede overlay direto. O erro foi “This node is not a swarm manager”. Só depois ficou claro: Overlay depende do Swarm.

Outro detalhe é --subnet=10.0.1.0/24. Recomendo usar um bloco /24, com 256 IPs, para evitar conflito com outras redes. Clusters maiores podem usar /16, mas planeje bem o intervalo de IPs.

Benchmark de desempenho: deixando os dados falarem

Qual é, de fato, a diferença de desempenho entre os três modos? Separei alguns dados medidos na prática para dar uma comparação mais visual.

Dados principais, teste de carga de 72 horas

Segundo um relatório de testes em ambiente de produção publicado no CSDN, os três modos se comportaram assim sob carga:

Principais achados

Alguns números chamam atenção:

Host é bem mais rápido que Bridge. A latência média cai de 128μs para 32μs, uma diferença de 96μs, com cerca de 14% de ganho de desempenho. Em throughput, Host fica próximo do nativo, enquanto Bridge chega perto de 80%. Se sua aplicação processa milhares de requisições por segundo, essa diferença aparece.

O custo de NAT do Bridge não é pequeno. O uso de CPU sobe de 0,9 núcleo para 1,8 núcleo, quase dobrando. Isso acontece porque cada requisição externa passa por conversão NAT, adicionando uma camada de processamento.

Vultr - Servidor cloud NVMe de alto desempenho, 32 locais globais, deploy Docker com um clique

Ver preços →Anúncio

A encapsulação VXLAN do Overlay pesa mais. A comunicação entre hosts precisa encapsular e desencapsular pacotes, então a latência fica maior que no Bridge e o uso de CPU também sobe. É adequado para cenários distribuídos, não para uma única máquina de alto desempenho.

Impacto na prática

Esses números parecem abstratos, mas em cenários reais a diferença pode ser grande.

Em um sistema de trading de alta frequência, cada microssegundo conta. Os 32μs do Host contra os 128μs do Bridge podem influenciar se uma ordem chega a tempo. Já em uma aplicação Web comum, a ida e volta da requisição do usuário já costuma levar centenas de milissegundos; algumas dezenas de microssegundos quase não são percebidas.

Então não olhe apenas para a tabela. Olhe para o seu cenário. Desempenho é sensível? Comece por Host. Segurança vem primeiro? Use Bridge. Precisa cruzar hosts? Overlay, aceitando o custo.

Como testar no seu ambiente

Se você quiser medir a diferença no seu próprio ambiente, há alguns caminhos simples.

Teste de latência: use ping ou iperf3.

# Dentro do contêiner A, faz ping no contêiner B em modo bridge
docker exec container-a ping container-b

# Usa iperf3 para testar throughput, depois de instalar iperf3
docker exec container-a iperf3 -c container-b

Monitoramento de CPU: use docker stats.

# Verifica o uso de CPU dos contêineres
docker stats --no-stream

Monitoramento de tráfego de rede: use tcpdump para capturar pacotes.

# Captura o tráfego de rede do host, direto no modo host
docker exec -it container-host tcpdump -i eth0

# Captura o tráfego da rede bridge, especificando a ponte
tcpdump -i docker0

Minha sugestão: antes de colocar em produção, rode uma rodada de teste de carga e veja se o modo de rede escolhido aguenta o tráfego. Não espere descobrir o problema depois do deploy.

Fluxo de decisão: do cenário ao modo certo

Depois de tudo isso, como escolher? Dá para seguir uma lógica simples.

Decisão em três etapas

Quando aparecer uma configuração de rede, siga este fluxo:

Primeira etapa: precisa de comunicação entre hosts?

Se vários contêineres estão distribuídos em servidores diferentes e precisam se acessar, por exemplo Web no nó A e banco de dados no nó B, então há comunicação entre hosts.

• YES -> segunda etapa
• NO -> terceira etapa

Segunda etapa: você usa Swarm?

Para comunicação entre hosts, há dois caminhos: Docker Swarm com Overlay, ou roteamento manual com Host + iptables.

• YES -> rede Overlay, a opção mais simples, com gerenciamento automático pelo Swarm
• NO -> considere Macvlan ou Host + configuração de rotas, que é mais complexo e serve para casos especiais

Terceira etapa: a aplicação é sensível a desempenho de rede?

Se a aplicação depende muito de latência e throughput, como trading de alta frequência, comunicação em tempo real ou jogos, desempenho vem primeiro.

• YES -> modo Host, avaliando o risco de segurança
• NO -> modo Bridge, a escolha segura por padrão

Tabela de recomendação por cenário

De forma ainda mais direta:

Uma sugestão prática

Não comece tentando descobrir “qual modo é o melhor”.

Na maioria dos cenários, Bridge basta. Ajuste quando o problema aparecer:

• Descoberta de serviço ficou chata -> troque para uma Bridge personalizada
• Desempenho realmente não aguenta -> considere Host, avaliando o custo de segurança
• Precisa atravessar hosts -> use Overlay, aceitando o custo do VXLAN

Já vi equipes começarem direto com Host e acabarem com conflitos de porta e brechas de segurança. Na prática, Bridge resolve 90% dos casos. Não vale otimizar antes da hora.

Melhores práticas em produção

Cada modo tem seus pontos fortes e fracos. Então como usar com mais estabilidade em produção? Algumas práticas ajudam.

Bridge: rede personalizada + DNS

A bridge padrão tem um problema grande: contêineres só conversam por IP, não por nome.

Em produção, recomendo criar uma bridge personalizada:

# Cria uma rede personalizada com sub-rede definida para evitar conflito
docker network create --subnet=192.168.100.0/24 --name my-app-net

# Inicia os serviços conectados à rede personalizada
docker run -d --network my-app-net --name web-server nginx
docker run -d --network my-app-net --name redis-cache redis

# web-server consegue acessar redis-cache diretamente via DNS
docker exec web-server ping redis-cache

Assim, a descoberta de serviço não depende de IP manual. O nome do contêiner vira o endereço, e isso simplifica bastante.

Outro ponto: planeje a sub-rede com cuidado. Evite o padrão 172.17.x.x, que pode conflitar com a rede interna da empresa. Prefira algo como 192.168.100.0/24 ou 10.10.10.0/24, alinhando antes com o time de operações.

Railway - Plataforma de deploy moderna, sem ops complexas, no ar em minutos

Começar agora →Anúncio

Host: reforço de segurança é obrigatório

O modo Host tem bom desempenho, mas segurança pior. O contêiner enxerga todas as interfaces do host, incluindo rede interna, externa e VPN.

Em produção, se você usar Host, faça pelo menos duas coisas.

Primeiro: limite as permissões do contêiner. Use --cap-drop para remover Linux capabilities desnecessárias, como CAP_NET_RAW, evitando que o contêiner capture pacotes livremente:

docker run -d --network host --cap-drop NET_RAW nginx

Segundo: monitore tráfego anormal. O comportamento de rede do contêiner precisa ser monitorado. Se ele começar a fazer muitas conexões externas ou acessar interfaces internas sensíveis, isso deve gerar alerta. Prometheus + Grafana ajudam, assim como ferramentas dedicadas de segurança de rede.

Sinceramente, Host aparece pouco em produção, a menos que o desempenho seja um gargalo real. Para a maioria dos casos, Bridge com rede personalizada é suficiente.

Overlay: tamanho da sub-rede + estabilidade do Swarm

O ponto central do Overlay é a encapsulação VXLAN, e esse custo não é pequeno.

Alguns pontos de otimização:

Controle o tamanho da sub-rede: recomendo /24, com 256 IPs. Clusters grandes podem usar /16, com cerca de 60 mil IPs, mas isso precisa ser planejado antes para evitar conflitos.

# Recomendado: bloco de sub-rede /24
docker network create --driver overlay --subnet=10.0.1.0/24 my-overlay

Monitore uso de CPU: a encapsulação VXLAN aumenta o custo de CPU, especialmente em cenários de tráfego alto. Use docker stats ou Prometheus. Se a CPU subir demais, otimize a configuração, por exemplo ajustando MTU ou reduzindo comunicação entre hosts.

Priorize a estabilidade da rede entre nós do Swarm: Overlay depende do Swarm. Se a rede entre os nós for instável, a rede Overlay também vai falhar. Em produção, garanta baixa latência e pouca perda de pacotes entre os nós do Swarm; idealmente, use uma rede interna dedicada.

Conclusão: três princípios para lembrar

Depois de tudo, a decisão se resume a três frases.

1. Em uma máquina, comece por Bridge

Em 90% dos cenários, Bridge resolve. É seguro, simples e funciona por padrão. Se descoberta de serviço ficar chata, troque para uma Bridge personalizada e comunique por nome de contêiner.

2. Para desempenho sensível, use Host

Quando latência e throughput são críticos, Host é a melhor escolha. Mas lembre: melhor desempenho, pior isolamento. Em produção, reforce a segurança.

3. Entre hosts, use Overlay

Se contêineres em vários servidores precisam se acessar, Overlay é a resposta correta. O pré-requisito é um cluster Swarm. A configuração é mais complexa que Bridge e Host, mas é necessária para comunicação entre hosts.

Recomendação prática

Da próxima vez que você tiver um problema de rede no Docker, faça primeiro uma pergunta: é uma máquina só ou são vários hosts?

Se for uma máquina só, comece por Bridge. Se o desempenho não for suficiente, considere Host, mas avalie o custo de segurança. Se atravessar hosts for obrigatório, use Overlay e aceite o custo do VXLAN.

Não comece perguntando “qual modo é o melhor”. Comece por Bridge e ajuste quando o problema aparecer. Eu errei justamente nessa ordem: configurei Overlay primeiro, mas o cenário era de uma única máquina. Não precisava de nada disso.

Se você ainda não domina os fundamentos de bridge/host/none/container, vale ler antes o 11º texto da série, “Explicação dos modos de rede do Docker”. Com a base clara, este conteúdo avançado fica bem mais fácil.

Referências

"O Docker oferece vários drivers de rede, incluindo bridge, host, overlay e macvlan. Cada modo atende a cenários diferentes, e a documentação oficial explica em detalhes os métodos de configuração e os casos de uso."

"Redes Overlay se baseiam em túneis VXLAN, exigem um cluster Swarm ou um KV store externo e são adequadas para comunicação de contêineres entre hosts. A documentação oficial traz o fluxo completo de configuração."

"Guia de gerenciamento de rede do Swarm, incluindo como criar redes overlay, gerenciar redes de serviços e aplicar boas práticas para comunicação entre hosts."

"Melhores práticas de configuração de rede Docker, com relatório real de perda zero em produção. O artigo traz dados de um teste de carga de 72 horas, incluindo comparação de latência, throughput e perda de pacotes entre Host, Bridge e Overlay."

"Docker Network Tests under Host/Bridge Mode compara em detalhe as diferenças de desempenho entre os modos Host e Bridge, com métodos de teste de latência e dados experimentais."