Google Cloud Developers Summit : Build with Gemini - 11 mars à Paris - Related to paris, microsoft, -, mai, à

Entendendo network drivers no Docker

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.

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.

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.

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).

, 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.

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.

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.

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).

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.

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).

We can put an actual number on it. In machine learning, a loss function tracks the degree of error in the out......

Microsoft annonce que Skype fermera définitivement le 5 mai prochain. L'éditeur avait racheté la solution de communication en 2011 pour la modique som......

Chip designer Arm has a new edge AI platform optimized for the Internet of Things (IoT) that expands the size of AI models that can run on edge device......

Google Cloud Developers Summit : Build with Gemini - 11 mars à Paris

Google Cloud organise Build with Gemini, une journée immersive dédiée aux développeurs, pour explorer les dernières avancées en matière d’IA et de Cloud.

L'événement mettra en lumière les nouvelles fonctionnalités de Gemini, ainsi que des présentations et nouveautés clés sur, entre autres, GKE, Firebase, Cloud Run, Gemma.

Découverte des nouvelles fonctionnalités de Gemini en matière de développement applicatif.

de Gemini en matière de développement applicatif Workshops, démonstrations et ateliers techniques pour tester les outils en direct.

pour tester les outils en direct Rencontres avec des experts et networking entre pairs.

Le Grand Rex | 1 Bd Poissonnière - 75002 Paris.

Google in the recent past unveiled quantum-safe digital signatures in its Cloud Key Management Service (Cloud KMS), aligning with the National Institute of Stan......

Bhat: What we're going to talk about is agentic AI. I have a lot of detail to talk about, but first I want to tell you the backstory. I pe......

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 min......

Skype : Microsoft ferme les portes le 5 mai !

Microsoft annonce que Skype fermera définitivement le 5 mai prochain. L'éditeur avait racheté la solution de communication en 2011 pour la modique somme de 8,5 milliards $ ! Skype remplaça Windows Live Messenger. Skype rejoint le cimetière des apps historiques.

Skype subissait une concurrence très forte depuis plusieurs années et une forte baisse d'usage. Microsoft met en avant Teams et Skype était de moins en moins évoqué.

Google in the recent past unveiled quantum-safe digital signatures in its Cloud Key Management Service (Cloud KMS), aligning with the National Institute of Stan......

We can put an actual number on it. In machine learning, a loss function tracks the degree of error in the out......

In the wave of big data, the data volume of enterprises is growing explosively, and the requirements for data processing and analysis are becoming inc......