Redes Docker: Isolando Containers com Bridge Network

Introdução à Isolamento de Redes no Docker

A arquitetura de containers moderna exige mais do que apenas executar imagens; ela demanda uma orquestração precisa de recursos, segurança e conectividade. Um dos pilares fundamentais para uma infraestrutura Docker robusta é a compreensão profunda das redes do Docker. Embora o Docker Network possa parecer simples à primeira vista, sua configuração incorreta é a causa raiz da maioria dos problemas de conectividade entre serviços, falhas de exposição de portas e vulnerabilidades de segurança.

Neste tutorial técnico, vamos explorar como criar, configurar e solucionar problemas em redes docker, com foco específico na rede padrão bridge e em redes customizadas. Abordaremos desde a criação de um ambiente isolado até a integração com ferramentas essenciais como Traefik para roteamento reverse proxy, Watchtower para atualizações automáticas e o uso de volumes persistentes para garantir a durabilidade dos dados.

Ao final deste guia, você terá um entendimento sólido de como isolar seus containers, permitindo que eles comuniquem-se entre si de forma segura enquanto permanecem protegidos do tráfego externo indesejado, preparando o terreno para uma infraestrutura em VPS escalável e confiável.

Entendendo a Rede Bridge Padrão

Quando você inicia um container sem especificar uma rede, o Docker o anexa automaticamente à rede bridge padrão. Esta é uma rede de nível de link local que permite a comunicação entre containers no mesmo host via IPs internos. No entanto, a rede bridge padrão possui limitações significativas em ambientes de produção:

• Falta de Resolução DNS Integrada: Containers na rede bridge padrão não podem se resolver uns aos outros pelo nome do container. Eles precisam usar o IP dinâmico, que muda quando o container é reiniciado.
• Risco de Colisão de Portas: Se dois containers em redes diferentes tentarem expor a mesma porta (ex: 80) ao host, ocorrerá um conflito, a menos que você use mapeamentos específicos de porta do host para o container.
• Sem Isolamento Lógico: Não há separação clara entre serviços de front-end e back-end, facilitando acessos não autorizados se a configuração de firewall do host for falha.

Para superar essas limitações, a prática recomendada é criar redes docker customizadas. Elas oferecem isolamento lógico, resolução DNS automática entre containers e controle granular sobre quem pode falar com quem.

Passo 1: Criando uma Rede Bridge Customizada

O primeiro passo para isolar seus serviços é criar uma rede dedicada. Vamos utilizar o driver bridge, que é o padrão do Docker e oferece a melhor performance para containers no mesmo host.

1. Abra seu terminal na VPS ou máquina local.
2. Crie uma nova rede com um nome descritivo, por exemplo, app_backend. Isso ajudará a identificar a finalidade da rede (ex: backend, frontend, database).

docker network create app_backend

Agora que a rede existe, vamos verificar se ela foi criada corretamente e inspecionar seus detalhes:

docker network ls
docker network inspect app_backend

O comando inspect mostrará o CIDR da sub-rede (ex: 172.18.0.0/16), os gateways e os containers atualmente conectados a ela. Note que, inicialmente, estará vazio.

Passo 2: Conectando Containers à Rede Isolada

Agora vamos criar serviços que utilizarão essa rede isolada. Imagine uma arquitetura simples com um banco de dados PostgreSQL e uma aplicação Node.js que precisa acessá-lo.

# Criar o container do banco de dados conectado à rede
docker run -d \
  --name postgres_db \
  --network app_backend \
  -e POSTGRES_PASSWORD=minha_senha_segura \
  -v pg_data:/var/lib/postgresql/data \
  postgres:15-alpine

# Criar a aplicação conectada à mesma rede
docker run -d \
  --name node_app \
  --network app_backend \
  -p 3000:3000 \
  my-node-app:latest

Neste exemplo, o container postgres_db não expõe portas ao host (-p), tornando-o acessível apenas por outros containers na rede app_backend. O container node_app é o único que precisa de acesso externo e, portanto, mapeia a porta 3000.

Dica de Troubleshooting: Se você precisar conectar um container já existente a uma nova rede, use o comando:

docker network connect app_backend nome_do_container

Passo 3: Isolamento e Resolução DNS

A grande vantagem da rede customizada é a resolução de nomes. Dentro do container node_app, você não deve usar o IP do banco de dados, mas sim seu nome de host ou o nome definido na criação do container.

Se sua aplicação Node.js tentar conectar ao banco usando a string de conexão postgres://user:password@localhost:5432/mydb, ela falhará, pois localhost dentro do container refere-se ao próprio container. Em vez disso, use:

postgres://user:password@postgres_db:5432/mydb

O Docker DNS resolverá postgres_db para o IP interno da rede app_backend. Isso garante que, mesmo se o container do banco for reiniciado e receber um novo IP, a conexão continuará funcionando.

Passo 4: Integrando com Traefik para Roteamento

Em ambientes de produção, expor portas diretamente dos containers é arriscado. A solução padrão da indústria é usar um Reverse Proxy como o Traefik. O Traefik gerencia as rotas HTTP/HTTPS e fornece SSL automático.

Para que o Traefik possa rotear tráfego para seus containers, ele precisa estar na mesma rede ou ter acesso a ela. A configuração mais segura é criar uma rede pública para o proxy e redes privadas para os serviços internos.

# Criar rede pública para o proxy
docker network create public_network

# Executar Traefik na rede pública
docker run -d \
  --name traefik \
  --network public_network \
  -p 80:80 \
  -p 443:443 \
  -v /var/run/docker.sock:/var/run/docker.sock:ro \
  traefik:latest

Para conectar seu serviço interno (ex: node_app) ao Traefik, você pode conectá-lo a ambas as redes:

docker network connect public_network node_app
docker network connect app_backend node_app

O Traefik usará labels Docker para identificar quais containers rotear. Certifique-se de que seu container tenha as labels apropriadas, como traefik.enable=true e traefik.http.routers.myapp.rule=Host("meu-app.com").

Passo 5: Gerenciamento de Volumes Persistentes

Embora não seja diretamente uma configuração de rede, o gerenciamento de dados é crucial para a integridade da infraestrutura. Volumes persistentes garantem que os dados sobrevivam à reinicialização ou remoção de containers.

No exemplo anterior, usamos -v pg_data:/var/lib/postgresql/data. O volume pg_data é gerenciado pelo Docker e armazenado no sistema de arquivos do host. Para troubleshootar problemas de permissão ou espaço em disco:

# Listar volumes
docker volume ls

# Inspecionar detalhes de um volume
docker volume inspect pg_data

# Remover volumes órfãos (sem uso)
docker volume prune

Evite usar bind mounts (-v /host/path:/container/path) para dados sensíveis ou críticos, a menos que você tenha controle total sobre as permissões do host. Volumes Docker gerenciados são mais seguros e fáceis de migrar entre hosts.

Passo 6: Atualização Automática com Watchtower

Manter imagens atualizadas é essencial para a segurança. O Watchtower monitora seu registro de imagens e reinicia containers quando novas versões são detectadas.

docker run -d \
  --name watchtower \
  -v /var/run/docker.sock:/var/run/docker.sock \
  containrrr/watchtower

O Watchtower precisa de acesso ao socket Docker para gerenciar outros containers. Ele respeita as redes existentes, mas não precisa estar conectado a elas diretamente, pois ele opera no nível do daemon do Docker. Para configurar notificações ou intervalos específicos, use variáveis de ambiente como TOWER_POLL_INTERVAL.

Passo 7: Registry Privado para Imagens Seguras

Para empresas que não desejam expor imagens públicas, um registry privado é essencial. Você pode hospedar seu próprio registry usando a imagem oficial do Docker:

docker run -d \
  --name private_registry \
  --network app_backend \
  -p 5000:5000 \
  -v /opt/registry:/var/lib/registry \
  registry:2

Para enviar imagens para este registry, você deve marcá-las com o nome do host e porta:

docker tag my-app:latest localhost:5000/my-app:latest
docker push localhost:5000/my-app:latest

Lembre-se de configurar o Docker daemon no host cliente para permitir HTTP não-TLS se estiver em uma rede interna, editando /etc/docker/daemon.json:

{
  "insecure-registries" : ["localhost:5000"]
}

E reinicie o serviço Docker: systemctl restart docker.

Troubleshooting Comum em Redes Docker

Problemas de rede são frequentes. Aqui estão as etapas essenciais para diagnosticar falhas de conectividade entre containers:

1. Verificar a Conectividade da Rede: Confirme se os containers estão na mesma rede. Use docker network inspect <nome_da_rede> e verifique se o nome do container está listado.
2. Testar Ping entre Containers: Entre em um container e tente pingar outro pelo nome.

   docker exec -it node_app ping postgres_db

   Se o ping falhar, verifique firewalls internos ou configurações de rede do Docker.
3. Inspecionar Logs: Logs do Docker podem revelar erros de DNS ou timeouts.

   docker logs <container_id>

4. Verificar Portas Mapeadas: Se um serviço externo não consegue acessar o container, verifique se a porta está exposta corretamente e se não há conflitos com outros serviços no host.

   docker port <container_id>

5. Reiniciar Serviços de Rede: Em casos raros, reiniciar o daemon do Docker pode resolver problemas de estado corrupto da rede.

   systemctl restart docker

Conclusão e Melhores Práticas

A configuração adequada de redes docker é fundamental para a segurança, escalabilidade e manutenibilidade de sua infraestrutura de containers. Ao isolar serviços em redes bridge customizadas, você reduz a superfície de ataque e simplifica o gerenciamento de conectividade.

Resumo das Melhores Práticas:

• Sempre use redes docker customizadas para separar ambientes (ex: front-end vs. back-end).
• Nunca exponha portas de bancos de dados ou serviços internos ao host; use a resolução DNS da rede.
• Utilize um Reverse Proxy como Traefik para gerenciar SSL e roteamento de forma centralizada.
• Mantenha seus containers atualizados com ferramentas como Watchtower.
• Armazene dados críticos em volumes persistentes gerenciados pelo Docker.
• Use um registry privado para controlar suas imagens e evitar dependências de registros públicos.

Ao seguir estes passos, você estará construindo uma base sólida para aplicações containerizadas robustas, prontas para lidar com demandas reais de produção em ambientes VPS ou cloud. Lembre-se: a segurança e a estabilidade começam com uma configuração de rede clara e isolada.