Dar ao contêiner um endereço próprio na rede: o que você ganha, o que você paga

O arranjo padrão é este: o contêiner compartilha o endereço da máquina e você chega até ele por um número de porta. É simples, é seguro, e para a maior parte do trabalho basta.

Há casos em que não basta, e eles são previsíveis.

Quando um número de porta não basta

Duas aplicações querem o mesmo número. Você move uma para outro número, e então os links que essa aplicação gera sozinha não trazem aquele número e tudo se embaralha.

A aplicação se anuncia na rede. Encontrar impressoras, encontrar reprodutores de mídia, encontrar dispositivos de casa inteligente: isso funciona por mensagens que se anunciam sozinhas. Essas mensagens não sobrevivem ao mapeamento de portas. A aplicação se anuncia, mas o endereço que ela anuncia é o da máquina, e o outro lado não a alcança.

Você quer ver a aplicação na lista de dispositivos do roteador. Para dar um endereço fixo, escrever uma regra de firewall à parte, ver o tráfego dela separado. Com mapeamento de portas, aquela aplicação não existe para a rede; só a máquina existe.

O outro caminho: dar ao contêiner uma identidade própria

O contêiner aparece na rede com o próprio endereço de hardware, pega o próprio endereço do roteador, e fica na lista de dispositivos como um aparelho físico.

A primeira reação costuma ser "por que nem todo mundo faz assim". A resposta está no preço.

Preço um: a máquina não alcança o próprio contêiner

Essa é a parte que mais surpreende, e costuma ser descoberta com o trabalho já pronto.

Todos os dispositivos da rede alcançam aquele contêiner. A máquina que o hospeda não.

O motivo faz sentido: os dois usam a mesma interface física, e o tráfego não volta do comutador. A máquina manda o pacote para fora, e o pacote não retorna para a própria placa.

As consequências são do dia a dia: uma verificação de saúde rodando na máquina não alcança a aplicação, outro contêiner na mesma máquina não consegue se conectar, um script que você escreveu não funciona. Tudo isso enquanto a rede parece impecável vista de fora.

Existe solução, mas é uma peça a mais: abrir na máquina uma segunda interface virtual ligada à mesma placa e passar por ali a rota até o endereço do contêiner. Instalada, o problema some, mas por ser um acréscimo, se for esquecida ninguém entende.

Preço dois: você gasta um endereço de verdade

Cada contêiner consome um endereço da sua rede. Dez aplicações significa dez endereços. Numa rede pequena você chega ao limite rápido.

Além disso, se o endereço for um empréstimo ele pode mudar. Quando muda, tudo que estava preso a ele, inclusive uma regra que você escreveu, passa a apontar em silêncio para o lugar errado.

Preço três: a placa de rede e o firewall

A placa precisa aceitar mais de um endereço de hardware. A maioria das conexões sem fio não aceita, e alguns ambientes virtuais vêm com isso desativado. Não decida sem testar.

E o seu firewall agora enxerga na rede um dispositivo que ele não conhece. Para você é um contêiner; para quem escreve as regras é um aparelho comum. Não é um problema, mas se ficar não dito, um dia vai confundir alguém.

Endereço não basta, também é preciso um nome

Uma aplicação com endereço e sem nome é metade do ganho. Ninguém quer decorar um endereço.

Para o nome ser anunciado na rede, algo precisa fazer esse trabalho. A imagem da própria aplicação em geral não tem essa peça, e não há por que ter: uma imagem de banco de dados não precisa se anunciar numa rede.

A regra

Um mapeamento de porta dá número a uma porta. Uma identidade de rede concede cidadania.

Conceda cidadania só quando a rede realmente precisar tratar aquela aplicação como um dispositivo. Quando não precisar, um número de porta é ao mesmo tempo mais simples e mais seguro.

O que o Atlas faz

Ao montar isso, o Atlas não mexe na imagem da própria aplicação. Ele abre ao lado dela um pequeno auxiliar, e o auxiliar compartilha a pilha de rede da aplicação. É o auxiliar que pede o endereço ao roteador, e é ele que anuncia o nome na rede.

Esse acoplamento é proposital e traz duas coisas. A imagem da aplicação não precisa conter nem um cliente de endereço nem um anunciador de nome. E como a pilha de rede pertence à aplicação, quando a aplicação para o auxiliar cai junto, sem deixar contêiner órfão para trás.

Para o problema de a máquina não alcançar o próprio contêiner, instala-se a ponte descrita acima, e ela é instalada como serviço, de modo que se reconstrói quando a máquina reinicia.

O que de fato vale contar é um defeito encontrado nessa ponte durante um teste em condições reais.

A ponte abria uma rota até o endereço do contêiner. Mas não apagava a rota de um contêiner que sumiu. Depois de um reinício, a rota de um endereço temporário tinha ficado pendurada. A consequência: se mais tarde outro dispositivo pegar aquele endereço, o tráfego destinado a ele é desviado para a ponte. Ou seja, o defeito não atinge o contêiner, atinge um terceiro inocente da rede.

A correção foi deixar de manter a ponte como algo que só adiciona rotas, e torná-la algo que apaga as rotas que não correspondem mais a um contêiner vivo.

A lição geral vale também fora de rede: adicionar é a metade fácil. Uma rota, uma regra, um mapeamento é uma afirmação que você faz sobre o mundo. Quando o mundo muda, uma afirmação que ninguém retirou vira mentira, e costuma atingir não você, mas alguém que não tem nada a ver com você.