FS

Docker Networking e drivers - Conectando containers

Imagem do post Docker Networking e drivers - Conectando containers

Resumo prático da diferença entre os tipos de networking explicando com videogames!

Quando falamos em drivers de rede no Docker, estamos falando de como os containers se conectam entre si, com o host e com o mundo externo.

No post anterior, usei a analogia de um jogo multiplayer para facilitar o entendimento. Agora vamos aprofundar: vou trazer explicações técnicas + analogias para que você entenda de uma vez por todas cada driver disponível.

1. Bridge (Padrão)

🔹 Técnico:

  • É o driver padrão.
  • Cada container recebe um IP privado numa sub-rede interna criada pelo Docker.
  • Containers podem se comunicar entre si nessa rede.
  • Para falar com o mundo externo, você precisa mapear portas (-p).

🎮 Analogia:

Pense numa LAN Party em casa. Todos os jogadores estão conectados ao mesmo roteador, com IPs internos. Quer jogar online? Precisa abrir a porta do roteador.

2. Host

🔹 Técnico:

  • O container não ganha uma pilha de rede própria.
  • Ele compartilha a rede do host diretamente.
  • Isso reduz overhead, mas aumenta riscos de segurança.

🎮 Analogia:

É como se você jogasse no mesmo PC de outra pessoa, sem tela dividida. Vocês compartilham os mesmos recursos, sem separação clara.

3. None

🔹 Técnico:

  • O container não tem nenhuma rede configurada.
  • Ele só existe isolado.
  • Útil quando você quer controle manual ou criar sua própria configuração.

🎮 Analogia:

É como jogar offline sem estar conectado em lugar nenhum. Você está sozinho, sem internet e sem multiplayer.

4. Overlay

🔹 Técnico:

  • Usado em Docker Swarm ou clusters.
  • Cria uma rede virtual que conecta containers em hosts diferentes.
  • Funciona via VXLAN (encapsulamento de pacotes).

🎮 Analogia:

É como jogar em servidores online, onde cada jogador está em um computador diferente, mas todos aparecem na mesma sala virtual.

5. Macvlan

🔹 Técnico:

  • O container recebe um endereço MAC e IP direto da rede física.
  • Ele aparece como um dispositivo físico na rede local.
  • Útil para quando você precisa que containers sejam tratados como hosts reais (ex.: servidores legados).

🎮 Analogia:

É como cada jogador trazer seu próprio console físico para a LAN Party. Eles estão na mesma rede real, sem truques.

6. Ipvlan

🔹 Técnico:

  • Parecido com o Macvlan, mas mais simples.
  • Containers compartilham o mesmo MAC do host, mas têm IPs diferentes.
  • Gera menos overhead em switches que não lidam bem com múltiplos MACs.

🎮 Analogia:

É como vários jogadores usando o mesmo console, mas cada um jogando com uma conta diferente na rede.

7. Network Plugins

🔹 Técnico:

  • São drivers de terceiros (ex.: Calico, Weave, Cilium).
  • Permitem recursos avançados: segurança, roteamento, políticas de rede.
  • Usados em Kubernetes e arquiteturas complexas.

🎮 Analogia:

É como instalar mods no jogo. Você expande as possibilidades além do que vem de fábrica.

Conclusão

O Docker nos dá sete drivers de rede que podem ser usados de acordo com a necessidade:

  • Bridge → Rede padrão interna.
  • Host → Usa diretamente a rede do host.
  • None → Sem rede.
  • Overlay → Conexão entre múltiplos hosts.
  • Macvlan → Containers com identidade própria na rede física.
  • Ipvlan → Containers com IPs únicos, mas compartilhando o MAC do host.
  • Network Plugins → Redes avançadas e customizadas.

Resumo prático:

  • Para apps comuns → Bridge.
  • Para maximizar desempenho → Host.
  • Para isolamento → None.
  • Para clusters → Overlay.
  • Para integração direta com rede física → Macvlan/Ipvlan.
  • Para setups avançados → Plugins.

Mais detalhes como esse assista ao vídeo abaixo do NetworkChuck!

Post criado/atualizado em: 19/08/2025

Felipe Santiago

Autor: Felipe Santiago

Trabalho com desenvolvimento web Frontend desde 2023 com foco em React e Typescript. TailwindCSS foi uma reviravolta em meus projetos, não consigo mais ficar sem ele. Evoluindo para aplicações FullStack, foquei muito para criação de APIs com Node e Fastify/Express e manutenção de banco de dados como PostgreSQL.