Custom Bridge Networks for Service Isolation

Por que as Redes Bridge Definidas pelo Usuário são Superiores?

A documentação oficial do Docker resume perfeitamente os motivos pelos quais você deve sempre preferir redes personalizadas em vez da padrão.

Como a leitura destacou, as vantagens são claras e impactantes. Vamos resumi-las:

1. Resolução Automática de Nomes (DNS): Este é o benefício mais significativo. O Docker possui um servidor DNS embutido para redes personalizadas. Quando você conecta um contêiner a uma rede personalizada, ele pode resolver o nome de qualquer outro contêiner na mesma rede para o seu endereço IP. Se você tem um contêiner api e um database, a api pode simplesmente se conectar ao hostname database. Isso elimina a necessidade de gerenciar IPs, que são efêmeros e não confiáveis.

2. Melhor Isolamento: Em seu estudo de CCNA, você aprendeu sobre segmentação de rede para segurança e organização. As redes bridge personalizadas trazem esse mesmo conceito para seus contêineres. Cada rede que você cria é um segmento de rede isolado. Contêineres na rede-frontend não podem se comunicar com contêineres na rede-backend, a menos que um contêiner esteja explicitamente conectado a ambas. Isso impede que serviços não relacionados se comuniquem acidentalmente.

3. Gerenciamento Dinâmico: Você pode conectar (connect) e desconectar (disconnect) contêineres de redes personalizadas em tempo de execução, sem precisar pará-los ou recriá-los. Isso oferece uma flexibilidade enorme para manutenção ou para alterar dinamicamente a topologia da sua aplicação.

4. Configurabilidade: Cada rede personalizada pode ter suas próprias configurações, como sub-redes, gateways e regras de iptables, permitindo um controle granular que não é possível na rede padrão compartilhada.

Gerenciando Redes Bridge Personalizadas

O gerenciamento dessas redes é feito através do subcomando docker network. Aqui estão os comandos essenciais:

• docker network create <nome_da_rede>: Cria uma nova rede bridge.

  docker network create minha-app-net
  

• docker network ls: Lista todas as redes no host Docker. Você verá suas redes personalizadas junto com as padrão (bridge, host, none).
• docker network inspect <nome_da_rede>: Fornece informações detalhadas sobre uma rede, incluindo sua sub-rede, gateway e uma lista de contêineres conectados. É uma ferramenta de depuração inestimável.
• docker network rm <nome_da_rede>: Remove uma rede. Note que uma rede só pode ser removida se não houver contêineres conectados a ela.

Para mais detalhes sobre esses comandos, você pode consultar a documentação do Docker que lemos anteriormente, especificamente as seções "Manage a user-defined bridge" (LINK, seção 2) e as seções seguintes sobre conectar e desconectar contêineres.

Demonstração Prática: Isolamento e Comunicação

Agora, vamos ver a teoria em ação. O vídeo a seguir demonstra de forma clara e concisa como criar uma rede personalizada e provar que a resolução de nomes por DNS funciona como esperado.

Sua Vez de Praticar

Vamos recriar um cenário semelhante para solidificar o conceito. Imagine que você está construindo uma aplicação com um serviço de API (api-service) e um serviço de frontend (client-service).

1. Crie a rede:

   docker network create app-network
   

2. Inicie o contêiner da API: Usaremos uma imagem Nginx para simular um servidor web. Dê a ele o nome de host api-service e conecte-o à sua nova rede.

   docker run -d --name api-service --network app-network nginx
   

   • -d: Executa em modo detached (background).
   • --name api-service: Define o nome do contêiner, que será seu hostname na rede.
   • --network app-network: Conecta o contêiner à rede que criamos.

3. Teste a comunicação de dentro da rede: Agora, inicie um contêiner temporário na mesma rede para atuar como nosso cliente. Usaremos a imagem alpine, que é muito leve.

   docker run -it --rm --network app-network alpine sh
   

   • -it: Inicia um terminal interativo.
   • --rm: Remove o contêiner automaticamente quando sairmos.

   Dentro do shell do contêiner alpine, primeiro tente pingar o serviço da API pelo nome:

   # Dentro do contêiner alpine
   ping -c 3 api-service
   

   Você verá que o nome api-service é resolvido para um endereço IP (por exemplo, 172.19.0.2) e os pings são bem-sucedidos. Isso é o DNS do Docker em ação!

4. Teste o isolamento: Saia do contêiner alpine (digite exit). Agora, inicie outro contêiner alpine, mas desta vez não o conecte à app-network. Ele usará a rede bridge padrão.

   docker run -it --rm alpine sh
   

   Dentro deste novo contêiner, tente pingar o api-service:

   # Dentro do segundo contêiner alpine (na rede padrão)
   ping -c 3 api-service
   

   O comando falhará com um erro como ping: bad address 'api-service'. Isso prova o isolamento: contêineres fora da rede personalizada não podem resolver os nomes ou acessar os contêineres dentro dela.

5. Limpeza: Após sair do segundo contêiner, pare o serviço da API e remova a rede.

   docker stop api-service
   docker rm api-service
   docker network rm app-network
   

Este exercício prático demonstra os dois benefícios mais importantes: comunicação por nome e isolamento por padrão.

docker network connect backend-net webapp

Conclusão

Parabéns! Você agora sabe como criar e gerenciar redes bridge personalizadas, uma prática essencial para construir aplicações conteinerizadas robustas e seguras.

Principais pontos a reter:

• Sempre use redes bridge definidas pelo usuário para aplicações com mais de um contêiner.
• A principal vantagem é a resolução de nomes por DNS, que permite uma comunicação de serviço para serviço estável e desacoplada.
• Elas fornecem isolamento de rede como padrão, um princípio fundamental de segurança.
• Os comandos chave para gerenciamento são docker network create, ls, inspect e rm.
• Contêineres são conectados a redes no momento da criação com --network ou dinamicamente com docker network connect.

Na próxima lição, abordaremos o próximo passo lógico: se nossos serviços estão isolados em redes privadas, como os expomos ao mundo exterior? Vamos nos aprofundar no mapeamento de portas com a flag -p, permitindo que usuários externos acessem suas aplicações.