Porque é que a verificação do estado de um contentor falha enquanto a aplicação continua a abrir?

Um contentor pode continuar utilizável mesmo quando a verificação de estado falha, porque a sonda testa um comando, endereço, utilizador ou condição de prontidão diferente do caminho utilizado pelo seu navegador.

Num servidor doméstico, a aplicação pode abrir através de um proxy inverso, apesar de o Docker executar o comando de verificação dentro do contentor contra localhost, um utilitário inexistente, a porta errada ou uma dependência temporariamente indisponível. Comece por reproduzir a sonda exata dentro do contentor e, em seguida, compare o respetivo destino e resultado esperado com o caminho real do utilizador antes de aumentar as tentativas ou desativar a verificação de estado.

Compare o que o navegador testa com o que a verificação de estado testa

Registe o URL e o caminho de rede que abrem corretamente a aplicação. Note se o navegador chega a um proxy inverso, a uma porta do anfitrião publicada, a um IP local ou diretamente ao contentor.

O Docker executa a sonda configurada dentro do contentor, pelo que pode testar um endpoint diferente do navegador. Um caso na comunidade Docker mostrou uma verificação de estado a falhar porque a imagem não continha o comando curl utilizado pela sonda, apesar de o próprio processo do serviço continuar a funcionar.

Se o caminho utilizado com sucesso pelo navegador passar por outro proxy ou porta, não considere esse resultado como prova de que o destino da sonda interna está correto. Anote ambos os caminhos e identifique o primeiro componente que difere.

Execute o comando exato de verificação dentro do contentor

Copie exatamente o comando de verificação de estado, incluindo o formato da shell, o URL, as opções, as credenciais e as variáveis de ambiente. Execute-o dentro do contentor em execução, com o mesmo utilizador, e registe o código de saída e o resultado.

Um contentor marcado como não íntegro pode continuar a ter um processo em execução, porque o estado de saúde reflete o resultado da sonda, não o facto de os utilizadores conseguirem carregar uma página. O fluxo de diagnóstico do Netdata distingue a falha da sonda da falha do processo antes de alterar o comportamento de reinício.

Se o comando for executado manualmente com sucesso, compare o utilizador de execução, a shell, o diretório de trabalho, o ambiente e o momento utilizados pela verificação automática. Se falhar manualmente, o erro identifica agora a camada seguinte sem ter de aguardar outro intervalo de verificação.

Verifique a ferramenta da sonda, a shell, o PATH e o utilizador

Confirme que todos os executáveis do comando de verificação existem na imagem atual e podem ser executados pelo utilizador do contentor. As imagens mínimas podem não incluir curl, wget, bash, ferramentas de DNS ou arquivos de certificados.

As sondas no formato shell e no formato exec comportam-se de forma diferente. As aspas, os pipes, a expansão de variáveis e os comandos compostos requerem uma shell disponível, enquanto um comando direto precisa do caminho completo do executável quando o ambiente da verificação tem um PATH limitado.

Execute o comando com um caminho absoluto e com o utilizador de serviço pretendido. Corrija a imagem ou a sonda em vez de instalar ferramentas interativamente, porque uma alteração manual no contentor desaparece após a próxima reconstrução.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

Verifique o endereço, a porta e o protocolo internos

Inspecione o listener da aplicação dentro do contentor e compare-o com o URL da sonda. Uma porta do anfitrião publicada, como 8080:80, não significa que o serviço esteja a escutar na porta 8080 dentro do contentor.

As verificações de estado devem testar o estado da aplicação que o contentor controla. O guia prático do Dash0 observa que uma sonda pode chamar um endpoint HTTP ou inspecionar um processo, mas o endpoint tem de refletir o estado real de prontidão do contentor, em vez de uma rota disponível apenas através de um proxy externo.

Teste 127.0.0.1, o endereço onde o contentor está a escutar e o nome do serviço, apenas quando cada um for apropriado. Se a aplicação estiver ligada apenas a um socket Unix ou a outra interface, altere a sonda para o verdadeiro ponto de entrada interno.

Separe um arranque lento de uma falha permanente

Meça quanto tempo a aplicação, a migração da base de dados, o aquecimento da cache ou o carregamento do modelo demora até o endpoint correto responder. Compare esse tempo com start_period, interval, timeout e retries.

O Compose pode bloquear serviços dependentes quando uma dependência ainda está marcada como não íntegra, mesmo que fique pronta mais tarde. Uma regressão comunicada no Compose mostrou um serviço a tornar-se íntegro apenas depois de a falha da dependência já ter parado a stack, expondo uma janela de arranque da verificação de estado demasiado curta.

Aumente os tempos apenas quando os registos demonstrarem que a aplicação está a progredir normalmente. Mais tentativas não devem ocultar uma porta errada, uma migração falhada, um certificado em falta ou uma base de dados inacessível.

Mantenha a sonda restrita e verifique a recuperação

Decida se a verificação de estado deve representar a vitalidade do processo, a prontidão da aplicação local ou uma cadeia de dependências mais profunda. Não torne um contentor local não íntegro apenas porque uma API externa opcional está indisponível.

O guia da ZimaSpace sobre encontrar a primeira dependência que falha é o passo seguinte quando a própria aplicação não consegue ficar pronta sem uma base de dados, cache ou serviço de rede.

O problema está resolvido quando a sonda automática exata é executada com sucesso após o arranque normal, o contentor permanece íntegro durante reinícios das dependências e o fluxo de trabalho real da aplicação continua disponível. Mantenha a sonda suficientemente rigorosa para detetar um serviço avariado, mas suficientemente restrita para evitar falhas falsas causadas por sistemas não relacionados.