Conceito e mecanismo
A rede de um contentor tem um contexto próprio. Numa bridge definida pelo utilizador, nomes e aliases permitem descoberta entre contentores ligados; a bridge predefinida não oferece a mesma conveniência automática. Um override DNS para 127.0.0.1 aponta para o loopback do contentor quando este tem namespace próprio. Isso não alcança automaticamente o resolver do host. Publicar uma porta também exige atenção ao endereço e ao modo de rede. Em Engine 28 ou posterior, uma publicação normal em loopback limita esse acesso ao host; versões anteriores têm uma ressalva de acesso no mesmo segmento L2. Regras adicionais de encaminhamento e modos routed exigem avaliação própria.
Aplicação guiada
Num incidente fictício, compara a configuração do balanceador com o modo de publicação Swarm. Ingress usa routing mesh e pode receber num nó sem tarefa local; host mode exige um destino com listener válido do serviço. Se tarefas mudam, descoberta e health checks devem acompanhar essa localização. Um teste SSH prova acesso ao host, não saúde da aplicação. Para tráfego entre nós Linux, a cifragem da gestão Swarm não ativa por si cifragem dos dados da overlay. Essa opção precisa de configuração explícita e medição de impacto. Desenha separadamente os caminhos de DNS, pedidos, gestão e observabilidade. Esta divisão permite atribuir sintomas à camada correta e evita mudanças amplas de firewall sem hipótese verificável.
Falhas apenas em destinos sem tarefa após mudar para host mode: rever descoberta do balanceador.
Armadilhas comuns
Loopback como host remoto; SSH como saúde do serviço; ingress como host; gestão cifrada como todos os dados cifrados.
Tópicos relacionados: Swarm: estado desejado, placement e quorum · Entregas, rollback e prontidão · Imagens reproduzíveis e registry
Confirma namespace, destino, listener e proteção de cada caminho.
Referência: Container networking · DCA Study Guide v1.5 (January2025); current exam listing checked2026-09-30