Custom Bridge Networks and DNS for Container Communication

O Problema: Comunicação em Ambientes Dinâmicos

Quando você inicia um contêiner, o Docker atribui a ele um endereço IP de um pool privado da rede à qual ele está conectado. Você poderia obter o IP de um contêiner de banco de dados com docker inspect e colocar esse IP na string de conexão da sua API.

No entanto, essa abordagem é extremamente frágil. Os contêineres são efêmeros; eles podem ser parados, reiniciados ou substituídos. Cada vez que isso acontece, o Docker pode atribuir um novo endereço IP, quebrando sua aplicação. Precisamos de um método de descoberta de serviço (service discovery) que seja estável.

A Solução: DNS Interno do Docker

A razão pela qual as redes bridge definidas pelo usuário (user-defined) são superiores à rede bridge padrão é que elas vêm com um benefício crucial: um servidor DNS integrado.

A documentação oficial do Docker explica isso muito bem.

Como você leu, quando você conecta contêineres a uma rede bridge definida pelo usuário, o Docker automaticamente registra o nome de cada contêiner em seu servidor DNS interno. Isso significa que, de dentro dessa rede, qualquer contêiner pode encontrar qualquer outro simplesmente usando seu nome.

Demonstração: A Diferença na Prática

Nada é mais claro do que ver o conceito em ação. O vídeo a seguir demonstra de forma concisa a limitação da rede padrão e o poder da rede personalizada.

O vídeo ilustra o fluxo de trabalho exato:

1. Na rede bridge padrão, curl myapp-v2 falha.
2. Após criar a rede my-bridge-net e conectar os contêineres a ela, curl myapp-v2 funciona.

Hands-On: Conectando uma API a um Banco de Dados

Vamos aplicar isso a um cenário prático para você, como desenvolvedor .NET. Imagine que você tem uma API (my-api) que precisa se conectar a um banco de dados PostgreSQL (my-db).

Passo 1: Crie a rede

Primeiro, criamos uma rede dedicada para nossa aplicação. Isso isola nossos serviços de outros contêineres que possam estar rodando no host.

docker network create meu-projeto-net

Passo 2: Inicie o contêiner do banco de dados

Agora, iniciamos o contêiner do PostgreSQL. Damos a ele um nome (--name my-db) e o conectamos à nossa rede (--network meu-projeto-net).

# Nota: Este é um exemplo simplificado. Em produção, você usaria volumes para persistir dados.
docker run -d --name my-db --network meu-projeto-net \
  -e POSTGRES_USER=user \
  -e POSTGRES_PASSWORD=password \
  -e POSTGRES_DB=mydb \
  postgres:16-alpine

O contêiner my-db está agora rodando e seu nome foi registrado no DNS da rede meu-projeto-net.

Passo 3: Inicie o contêiner da API

Agora, vamos iniciar nossa API. Supondo que você já tenha uma imagem chamada minha-api:1.0, o comando seria:

docker run -d --name minha-api --network meu-projeto-net \
  -p 8080:8080 \
  minha-api:1.0

O Ponto Chave: A String de Conexão

Dentro do código da sua API .NET, a string de conexão no appsettings.json não usará localhost ou um IP. Ela usará o nome do contêiner do banco de dados:

{
  "ConnectionStrings": {
    "DefaultConnection": "Host=my-db;Port=5432;Database=mydb;Username=user;Password=password"
  }
}

Com essa configuração, sua API fará uma consulta DNS para my-db, o Docker resolverá para o IP interno correto do contêiner do banco de dados e a conexão será estabelecida. Simples, robusto e portátil.

# 1. Criar a rede
docker network create servicos-internos

# 2. Rodar o serviço de autenticação
docker run -d --name auth-service --network servicos-internos nginx:alpine

# 3. Rodar um contêiner temporário para fazer a chamada
# O comando irá executar, fazer o curl, imprimir o HTML do nginx e o contêiner será removido (--rm)
docker run --rm --network servicos-internos curlimages/curl http://auth-service/

Conclusão

Hoje, você adicionou uma peça fundamental ao seu conhecimento de Docker, uma que é vital para a construção de sistemas distribuídos.

Principais pontos a reter:

• Comunicação por IP é frágil: Endereços IP de contêineres são efêmeros e não devem ser usados para configuração.
• Redes bridge personalizadas fornecem DNS: Esta é a principal razão para sempre criar redes dedicadas para suas aplicações multi-serviço.
• O nome do contêiner é o hostname: Use o nome que você define com --name diretamente em suas strings de conexão ou URLs de API.
• Isolamento e Descoberta: Redes personalizadas oferecem o melhor de dois mundos: isolamento do mundo exterior e descoberta de serviço automática no interior.

Até agora, cobrimos como os contêineres se comunicam entre si e com o mundo exterior. No entanto, há um problema crítico que não abordamos: o que acontece com os dados do seu banco de dados se você remover o contêiner my-db? Eles são perdidos para sempre. Na próxima lição, vamos resolver esse problema crucial explorando a diferença entre volumes, bind mounts e armazenamento persistente.