Porque é que um alias de rede do Compose deixa de ser resolvido depois de a stack ser recriada com um novo nome de projeto?

Um alias do Compose pode deixar de ser resolvido após uma recriação quando o serviço entra numa rede com âmbito de projeto diferente ou quando o alias deixa de estar associado a essa rede.

Os aliases do Docker têm âmbito de rede, não são nomes globais. Recriar uma stack sob um diretório diferente, com um nome de projeto explícito, um nome de stack do Portainer ou um projeto Compose diferente pode criar uma nova rede predefinida enquanto outra aplicação permanece na antiga. O serviço pode estar saudável e acessível através da porta publicada, mas o seu alias interno falha porque o cliente e o destino já não partilham a mesma rede ou porque um proxy inverso selecionou uma associação diferente.

Compare os nomes de projeto do Compose antigo e novo

Registe o nome de projeto anterior e atual, o diretório de trabalho, o nome da stack, os nomes das redes e as etiquetas dos contentores. Compare os serviços cliente e destino após a recriação.

O Docker Compose utiliza o nome do projeto para agrupar e nomear recursos. A precedência do nome de projeto explica por que motivo alterar o diretório ou o nome da implementação pode criar uma nova rede em vez de reutilizar a rede antiga do projeto.

Se o cliente continuar associado a oldproject_default enquanto o destino entra em newproject_default, o alias anterior deixa de ter um âmbito DNS partilhado.

Verifique o alias na rede partilhada exata

Inspecione ambos os contentores e liste todas as redes associadas, os endpoints, os endereços IPv4 ou IPv6 e os aliases. Teste o DNS a partir do interior do contentor cliente.

A especificação do Compose define os aliases como nomes com âmbito de rede, pelo que um alias declarado numa rede não existe automaticamente noutra associação.

Mova a declaração do alias para a rede efetivamente partilhada pelos serviços. Não dependa de container_name como substituto da descoberta de serviços planeada.

Verifique os nomes das redes externas e a substituição na implementação

Compare a chave lógica da rede Compose com o seu name externo explícito. Verifique a substituição de variáveis de ambiente e as variáveis da interface da stack utilizadas durante a implementação.

O Portainer documenta que as stacks podem utilizar redes Docker existentes, que têm de ser selecionadas de forma consistente quando stacks implementadas de forma independente precisam de resolver os nomes umas das outras.

Uma rede externa impede alterações no prefixo do projeto apenas quando todas as stacks referenciam o mesmo nome de rede real. Um erro de digitação pode criar ou selecionar uma rede diferente sem alterar a porta publicada do serviço.

-15% OFF

ZimaBoard 2 - Mini Servidor Doméstico para a Sua Grande Ideia

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Confirme que o cliente utiliza o DNS do Docker em vez de um endereço em cache

Execute uma nova pesquisa a partir do cliente, inspecione a configuração do resolvedor e reinicie apenas o processo que mantém o DNS em cache, quando necessário. Compare a resolução do alias com a pesquisa direta pelo nome do serviço.

O modelo de namespaces de rede do Linux isola os recursos de rede, razão pela qual o sucesso do DNS no anfitrião não prova que o contentor cliente partilha a rede Docker do destino.

Não adicione o IP atual do contentor destino a /etc/hosts. Os contentores recriados podem receber um endereço diferente, deixando outra dependência obsoleta.

Verifique que rede o proxy inverso utiliza

Inspecione as associações de rede do proxy e da aplicação, as etiquetas do fornecedor e a rede selecionada para o encaminhamento para o backend. Teste o alias a partir do contentor do proxy.

O fornecedor Docker do Traefik permite especificar a rede Docker utilizada nas ligações ao backend.

Se o proxy estiver associado a várias redes, a seleção automática pode mudar após a recriação. Defina explicitamente a rede partilhada pretendida e mantenha estável o seu nome real.

Remova endpoints obsoletos sem eliminar a rede errada

Liste os contentores ligados às redes antiga e nova. Identifique endpoints órfãos, contentores parados e serviços ativos que ainda dependem da rede antiga do projeto.

O guia de redes de contentores da Red Hat descreve a associação de contentores a redes definidas pelo utilizador como parte do estado do runtime dos contentores, e não do conteúdo dos ficheiros da aplicação.

Remova uma rede antiga apenas depois de confirmar que nenhuma stack ativa a utiliza. Eliminar ambas as redes e recriar tudo de uma vez destrói as evidências que mostram qual era a associação incorreta.

Recrie um serviço e verifique o DNS a partir de todos os clientes

Uniformize o nome do projeto ou a rede externa, recrie apenas o serviço afetado e teste o nome do serviço e o alias a partir de cada contentor dependente.

O artigo da ZimaSpace sobre dependências do runtime dos contentores apresenta a regra relacionada: um teste de conectividade ao nível do anfitrião não valida o namespace nem o percurso de descoberta de serviços do contentor.

O problema está resolvido quando o alias é resolvido para o endpoint atual a partir de todos os clientes pretendidos após a recriação da stack e o reinício, sem endereços IP codificados.

Perguntas frequentes

Os aliases de rede do Docker são globais?

Não. Um alias existe apenas na rede onde está configurado e só é útil para contentores que partilham essa rede.

Alterar o nome da pasta do Compose pode quebrar o DNS?

Sim. A pasta pode afetar o nome de projeto predefinido, que por sua vez afeta os nomes das redes geradas, a menos que o nome do projeto ou da rede externa esteja fixado.

Devo utilizar container_name para manter o DNS estável?

Normalmente, não. Nomes de serviço estáveis e redes partilhadas explícitas preservam a escalabilidade do Compose e evitam colisões de nomes globais.