Réplica Docker Swarm Running mas não responde: o que verificar

Identifique a tarefa AWS, confira inicialização e dependências e rastreie uma requisição até a réplica antes de aprovar o atendimento pelo domínio público.

Se uma réplica Docker Swarm Running mas não responde, confirme a inicialização, teste suas dependências e rastreie o caminho da requisição. Running indica execução da tarefa, não atendimento HTTP, o protocolo de comunicação da aplicação web. A validação exige uma operação funcional atribuída à réplica afetada, inclusive pelo domínio público.

• Identifique a tarefa remota antes de consultar logs ou reiniciar.
• Confira versão, configuração, arquivos e interface de escuta.
• Teste dependências a partir do contêiner afetado.
• Interprete o healthcheck conforme o teste configurado.
• Comprove atendimento remoto; depois avalie capacidade sob carga.

Réplica Docker Swarm Running mas não responde: identifique a tarefa

O cenário é uma aplicação em Docker Swarm numa VPS, servidor virtual fixo, com uma réplica adicional na AWS antes da campanha. Réplica é uma cópia executável do serviço; tarefa é a unidade que o Swarm agenda para executar um contêiner. O worker é o servidor que executa essa tarefa.

1. No manager, nó que gerencia o conjunto de servidores, execute docker service ps --no-trunc SERVICO. Substitua SERVICO pelo nome real e registre tarefa, nó, estado atual e histórico de substituições.
2. No worker indicado, execute docker ps --filter label=com.docker.swarm.task.id=ID_DA_TAREFA. Consulte o contêiner encontrado com docker inspect ID_DO_CONTAINER.
3. No manager, consulte docker service logs --timestamps ID_DA_TAREFA quando o driver, mecanismo de registro de logs, permitir. Caso contrário, use docker logs --timestamps ID_DO_CONTAINER no worker.

Preserve os registros antes de reiniciar. Se a tarefa foi substituída, seus logs explicam a tentativa anterior, mas não comprovam o estado da substituta. Repita a identificação para acompanhar a tarefa atual.

Procure inicialização concluída, falhas fatais e espera por migração de banco. Confira também a porta e a interface de escuta com ferramentas existentes, como ss ou netstat, executadas por docker exec dentro do contêiner. Escuta apenas em 127.0.0.1 impede acesso pela rede do contêiner; compare a porta com o destino do proxy, programa que recebe e encaminha requisições.

Compare a configuração executada e interprete o healthcheck

No manager, compare docker service inspect SERVICO com docker inspect --type task ID_DA_TAREFA. No worker, examine o contêiner correspondente. Durante uma atualização, a especificação desejada do serviço pode diferir da tarefa ainda em execução.

Ao encontrar uma diferença, relacione o valor executado ao sintoma observado. Um caminho de arquivo divergente deve ser conferido dentro do contêiner; uma porta diferente deve ser comparada com o encaminhamento. A diferença só orienta a correção quando explica a falha.

• Confira imagem, comando de entrada e argumentos. Compare o digest, identificador do conteúdo da imagem: tags iguais não garantem conteúdo idêntico.
• Verifique variáveis, configurações e secrets, mecanismo do Docker para fornecer dados sigilosos. Remova valores sensíveis antes de compartilhar inspeções.
• Confira caminhos, permissões e montagens, que disponibilizam arquivos ao contêiner. Arquivos no disco da VPS não aparecem automaticamente no worker AWS.

No contêiner, Config.Healthcheck mostra o teste efetivo; State.Health, quando presente, mostra estado e resultados recentes. Healthcheck é uma verificação de saúde programada, e healthy significa que suas condições foram satisfeitas. Sem teste configurado, registre a ausência.

Confira comando, destino, porta, saída, intervalos e tempo limite. Compare a tolerância inicial com a inicialização observada: um teste de processo ou página estática pode passar enquanto uma operação com banco falha. Incluir dependências compartilhadas pode provocar substituições de tarefas durante uma indisponibilidade externa.

O Swarm não oferece uma readinessProbe separada, mecanismo do Kubernetes para indicar prontidão para receber tráfego. HEALTHCHECK não cria uma barreira universal para qualquer proxy; confirme o comportamento da entrada usada. Consulte a instrução HEALTHCHECK e os estados das tarefas.

Teste banco e outras dependências a partir da réplica AWS

Execute as verificações no contexto de rede do contêiner afetado, usando ferramentas disponíveis. Sucesso no manager ou no sistema operacional do worker não comprova acesso pela aplicação. Use os mesmos destinos e parâmetros configurados nela.

1. Resolva o nome da dependência e confira o endereço obtido.
2. Teste conexão à porta configurada, com tempo limite explícito.
3. Verifique TLS, proteção criptográfica da conexão, quando aplicável.
4. Autentique com o usuário da aplicação e execute uma operação representativa, sem efeito destrutivo.

Resultado observado	O que investigar
Nome não resolvido	Nome configurado e serviço de resolução de nomes.
Conexão recusada	Destino, porta, serviço escutando ou rejeição explícita.
Tempo esgotado	Rota, filtragem e disponibilidade do destino.
Certificado inválido	Nome, validade e cadeia de confiança.
Acesso negado	Credenciais, origem permitida e permissões.
Limite de conexões	Conexões abertas e capacidade da dependência.

Esses resultados orientam a investigação; isoladamente, não fecham o diagnóstico. Porta aberta comprova conexão, mas não autenticação nem execução de consulta. Registre destino, duração, erro e horário para comparar com os logs da dependência.

Se a conexão funciona, mas a operação demora, meça sua duração também pela VPS. A comparação ajuda a distinguir demora do banco de atraso no caminho remoto, sem presumir a causa. Saturação ou excesso de conexões pede diagnóstico de gargalo no MySQL, pois mais réplicas podem aumentar essa pressão.

Mantenha a operação e o destino iguais ao comparar AWS e VPS. Se os testes usarem usuários ou consultas diferentes, a duração deixa de isolar o caminho remoto. Registre essas condições junto dos resultados para tornar a comparação verificável.

Comprove qual tarefa recebeu e respondeu à requisição

Faça uma requisição identificável e procure o registro correspondente no log de acesso da tarefa AWS. Use um identificador que a aplicação já registre, sem incluir credenciais ou dados pessoais. Horário sozinho pode ser ambíguo quando há requisições simultâneas.

Acessar a porta publicada no IP do worker não fixa necessariamente a réplica. O routing mesh, malha de encaminhamento do Swarm, pode entregar o pedido a uma tarefa em outro nó. Uma resposta de sucesso pode ter vindo apenas da VPS.

1. Identifique um caminho privado autorizado até a tarefa específica, sem um endereço intermediário que redistribua o pedido. O endereço deve estar acessível pela rede usada no teste.
2. Preserve o nome do site esperado pela aplicação. Se houver HTTPS, HTTP protegido por TLS, preserve também o nome validado pelo certificado; não desative essa validação para aprovar o ensaio.
3. Escolha uma rota representativa e controle o cache, armazenamento de respostas reutilizadas. Confirme pelos registros que a aplicação executou a operação.
4. Repita pelo domínio público e correlacione novamente a requisição com a tarefa AWS.

Se o tráfego público não alcançar a réplica, investigue a seleção de destinos antes de concluir. Ausência de log também pode indicar registro desativado ou consultado no lugar errado. Sem atribuição confiável, o teste permanece inconclusivo.

Valide o conteúdo e a operação esperados, além do código HTTP. Uma página de erro personalizada pode retornar sucesso, e uma página estática não comprova acesso ao banco. Registre tarefa, rota, identificador e resultado.

Separe as evidências do acesso direto e do público. O primeiro verifica o atendimento pelo caminho privado escolhido; o segundo inclui a entrada pública. Se os resultados divergirem, compare os registros da mesma operação em cada caminho.

Se o acesso direto funciona, revise a entrada pública

Desenhe o caminho efetivo: domínio público → proxy ou balanceador → destino configurado → tarefa remota. Balanceador é o componente que distribui requisições entre destinos. Compare registros nas etapas para localizar onde o pedido deixa de aparecer.

• Confira porta, protocolo, nome do site, regras de encaminhamento e descoberta dos destinos. Verifique se o proxy considera a tarefa apta a receber tráfego.
• Identifique VIP, endereço virtual do serviço, ou DNSRR, resolução de nomes que retorna endereços das tarefas. São formas diferentes de localizar destinos.
• Confira publicação ingress, pela malha do Swarm, ou host, diretamente no nó. Em host, o acesso depende da presença da tarefa naquele nó.
• Examine a rede overlay, rede virtual entre contêineres de nós diferentes, e o túnel privado, quando existente. Confira firewall, Security Groups, regras de tráfego da AWS, e caminho de retorno.

Se pedidos pequenos funcionam e transferências maiores travam, compare limites de tempo e tamanho no proxy e na aplicação. Investigue também o tamanho de pacote permitido pelo caminho de rede. Esse padrão orienta testes, mas não comprova sozinho uma causa.

Não exponha portas internas publicamente para contornar a falha. O artigo sobre balanceamento entre VPS e servidores extras complementa essa revisão; a documentação de ingress detalha a malha. Para divergência de arquivos ou sessões, veja estado local em múltiplos servidores.

Conclusão: aprove atendimento remoto antes de medir capacidade

Aprove o ensaio somente com tarefa e versão identificadas, configuração conferida, dependências acessíveis e operação funcional atribuída à réplica AWS pelo domínio público. Inicialização incompleta, falha de saúde sem explicação ou ausência de evidência impedem o aceite. Guarde os registros para repetir a validação após mudanças.

Funcionamento não comprova capacidade: depois, execute carga representativa com critérios de latência, tempo de resposta, e erros definidos para a aplicação. O SwarmBurst é um agente instalado no cluster do cliente para burst, capacidade temporária na AWS durante picos. Ele não corrige banco saturado nem estado local incompatível; com o atendimento validado, avance pelo checklist de implantação assistida.

Perguntas frequentes

Por que uma tarefa Docker Swarm fica Running mesmo sem responder HTTP?

Running indica que a tarefa está em execução, mas não comprova atendimento HTTP, o protocolo de comunicação da aplicação web. A aplicação pode estar inicializando, esperando uma migração de banco, sem acesso às dependências ou escutando em uma interface inacessível pela rede do contêiner.

Um healthcheck healthy garante que a réplica pode receber visitantes?

Não. Healthcheck é uma verificação de saúde programada; healthy significa apenas que o teste configurado passou. Um teste de processo ou página estática pode passar enquanto uma operação com banco falha. Confira o teste efetivo e o comportamento do proxy, componente que recebe e encaminha requisições, antes de aprovar o atendimento.

Como confirmar que a resposta veio da réplica AWS e não da VPS?

Faça uma requisição com um identificador que a aplicação já registre e encontre o registro correspondente na tarefa AWS. Acessar a porta publicada no endereço do worker, servidor que executa a tarefa, não garante essa atribuição: a malha de encaminhamento do Swarm pode enviar o pedido a outro nó. Teste um caminho privado autorizado até a tarefa específica e depois repita pelo domínio público, correlacionando os registros.

Por que a réplica responde diretamente, mas falha pelo domínio público?

O caminho público pode apresentar problemas na seleção de destinos, porta, protocolo, nome do site ou regras de encaminhamento. Compare os registros entre domínio, proxy ou balanceador, componente que distribui requisições, e tarefa remota. Confira também a rede entre contêineres, as regras de tráfego e o caminho de retorno para localizar onde o pedido deixa de aparecer.

O que impede aprovar o ensaio antes da campanha?

Inicialização incompleta, falha de saúde sem explicação ou ausência de evidência de atendimento impedem a aprovação. O aceite exige tarefa e versão identificadas, configuração conferida, dependências acessíveis e uma operação funcional atribuída à réplica AWS pelo domínio público. Sem atribuição confiável da requisição, o teste permanece inconclusivo.