Minha experiência com programação mudou completamente no dia em que eu descobri e aprendi a usar o Docker. Conseguir subir e gerenciar serviços na minha máquina e em produção, sem me preocupar com todos os problemas de trabalhar com aplicações em ambientes diferentes, fez uma grande diferença.
Mas algo que muita gente que está começando ou já usa o Docker acaba deixando passar é o conceito de redes e os tipos (drivers) de redes que existem, suas diferenças e quando usar cada uma.
O que é a rede em containers?
Antes de falar sobre os tipos de rede disponíveis, vale a pena dar uma visão geral de como o conceito de redes é aplicado no Docker.
Quando falo de "rede em containers", estou me referindo à capacidade de containers se conectarem e se comunicarem entre si.
Talvez você já tenha precisado, por exemplo, criar um container com o nginx e outro com uma API REST (o nome do container poderia ser api). O nginx precisa se comunicar com o api, ou pelo menos saber como chegar nele (através de um IP, por exemplo), e aí vem a pergunta: como fazer isso?
A resposta é sempre a mesma: por meio de uma rede interna entre os containers. E existem vários tipos de redes para alcançar esse objetivo!
Se você já usou o Docker Compose e usou o nome de um container dentro de outro container para fazer a comunicação (por exemplo, o container api se comunicando com o postgres usando o endereço postgres), você já está usando uma rede criada automaticamente, que é do tipo bridge.
Com essa introdução feita, é hora de ir ao tópico principal do artigo.
Tipos de Rede (network drivers)
Bridge
As redes do tipo bridge são, provavelmente, as mais usadas no Docker. Elas permitem a comunicação básica entre containers na mesma máquina (host) e na mesma rede bridge.
Esse é o tipo de rede padrão quando você cria uma rede com docker network create ou quando há comunicação entre containers dentro de um Docker Compose.
Quando o Docker é iniciado, ele também cria uma rede bridge padrão, usada pelos containers que são criados sem especificar uma rede ou que estão fora do Compose. Essa rede é chamada de default bridge network e tem algumas diferenças em relação às redes bridge criadas pelo usuário (as chamadas user-defined bridge networks).
A default bridge network não permite comunicação entre containers pelo nome (ou seja, não há resolução DNS), apenas pelo IP. E sim, estou ignorando a flag --link, que poderia ser usada para isso, mas não é recomendada.
Já as user-defined bridge networks permitem comunicação entre containers pelo nome e pelo IP. Além disso, por serem mais "específicas" (criadas para containers específicos), elas oferecem uma melhor isolação comparado à rede bridge padrão.
Você pode criar uma rede bridge com o comando:
docker network create nome_da_rede, e depois conectar um container a essa rede com docker network connect nome_da_rede nome_do_container.
Quando usar redes bridge: Quando você precisa de comunicação básica entre containers na mesma máquina.
Host
As redes do tipo host permitem que o container se comunique com qualquer serviço exposto na máquina. Isso tem algumas implicações:
- Você perde parte da isolação dos containers em relação à máquina, o que pode gerar problemas de segurança.
- O container não recebe um IP exclusivo, então se ele tiver um serviço rodando na porta
80, esse serviço estará disponível na mesma porta no IP da máquina (o que também pode ser um risco de segurança, especialmente se for um banco de dados e o firewall não estiver bem configurado). - Por conta disso, não é possível mapear portas como nas redes
bridge.
Você deve estar se perguntando, com tantos problemas, por que alguém usaria uma rede host em produção? A resposta é: performance.
Isso acontece porque você elimina camadas extras de rede e isolação, ganhando desempenho.
Uma particularidade interessante é que o Docker não cria uma rede virtual isolada nesse caso, logo não é possível criar a rede usando docker network create, em vez disso, basta criar o container com a flag --network host no comando docker run.
Quando usar redes host: Quando você precisa de alta performance e está disposto a sacrificar a segurança. Também vale a pena dar uma olhada nas redes IPvlan para casos semelhantes.
Overlay
As redes do tipo overlay permitem a comunicação entre containers em máquinas diferentes.
São muito usadas no contexto do Docker Swarm para comunicação entre serviços em máquinas/nodes diferentes, mas também podem ser usadas em containers tradicionais.
As redes overlay podem ter a propriedade attachable, que permite que containers tradicionais (containers standalone) se conectem a essa rede.
Agora, um caso de uso interessante com as redes overlay: Em uma situação onde você precise rodar um serviço no Docker Swarm, para tirar uma vantagem especifica da ferramenta (por exemplo: blue-green deployments ou replicas), mas não quer rodar outros serviços na mesma modalidade e ainda precisa ter a comunicação entre eles, você pode fazer uso de uma rede overlay que esteja attachable, e ainda possuir a escalabilidade do Docker Swarm.
Você pode criar uma rede overlay com a opção attachable com o comando:
docker network create -d overlay --attachable nome_da_rede.
Quando usar redes overlay: Quando você precisa de comunicação entre containers ou serviços que estão em máquinas diferentes.
IPvlan
As redes IPvlan oferecem controle total sobre endereços IPv4 e IPv6 dos containers, usando uma rede virtual tratada como uma rede física da máquina. Elas oferecem boa performance, como a rede host, mas com maior controle e possibilidade de continuar isolando o tráfego do container.
Elas são mais complexas de configurar e exigem um bom conhecimento de redes.
Quando usar redes IPvlan: Quando você precisa de controle total sobre a rede e os endereços IPs, e tem o conhecimento necessário para configurar isso.
Macvlan
As redes Macvlan permitem que os containers sejam tratados como dispositivos independentes na rede da máquina/host. Cada container recebe seu próprio endereço MAC, como se fosse um dispositivo físico, como um computador ou celular.
Esse tipo de rede permite que os containers:
- Comuniquem-se diretamente com a rede externa, como outros dispositivos na rede física.
- Enviem e recebam pacotes diretamente da rede física, sem passar pela máquina/host.
Porém, isso pode causar problemas na rede física.
Quando usar redes Macvlan: Quando os containers precisam de acesso direto à rede física (como para monitorar o tráfego da rede).
None
Se você precisa isolar completamente um container da rede, pode usar a rede none.
Quando usar redes None: Quando você precisa de isolamento total de um container.
Conclusões
Pode ser que você nunca precise usar alguns desses tipos de rede, mas acredite, saber qual tipo de rede usar para comunicação entre containers ou serviços vai ser bem útil e vai evitar gambiarra (falo isso por experiência própria).
Foto de CHUTTERSNAP na Unsplash
Top comments (0)