Como identificar que dependência do contentor está a causar um ciclo de reinícios

Identifique a primeira dependência que fica indisponível antes de a aplicação sair, em vez de tratar todos os contentores que reiniciam como a causa principal.

Numa stack do Docker Compose, a aplicação visível pode entrar num ciclo porque uma base de dados ainda está a iniciar, o Redis está inacessível, o DNS devolve o serviço errado, falta uma montagem vinculada, um segredo foi alterado, uma migração falhou ou a aplicação foi terminada por pressão de memória. O diagnóstico mais rápido captura a primeira saída e o erro da dependência, pausa os reinícios automáticos e testa cada serviço necessário a partir da mesma rede e com as mesmas credenciais usadas pelo contentor em falha.

Encontre o Primeiro Contentor que Falha, Não o Mais Ruidoso

Apresente as contagens de reinícios, o estado atual, o estado de saúde, o último código de saída e a hora de início de cada serviço da stack. Ordene a cronologia para que a primeira falha apareça antes de os contentores secundários começarem a restabelecer ligações ou a reiniciar.

O guia da Netdata sobre ciclos de reinício mostra como os códigos de saída e os estados distinguem terminações por falta de memória, falhas de segmentação, terminações normais e paragens relacionadas com o estado de saúde. Um OOMKilled ou sinal no código de saída pode eliminar a necessidade de investigar dependências quando a aplicação está, na realidade, a ficar sem memória ou a falhar internamente.

Se uma dependência falhar primeiro, investigue-a antes da aplicação. Se a aplicação sair primeiro com erros de ligação recusada, tempo limite, autenticação ou ficheiro em falta, associe essa mensagem à dependência exata que tentou utilizar.

Pause a Tempestade de Reinícios e Capture uma Falha Limpa

Desative temporariamente ou substitua a política de reinício do serviço afetado e execute-o uma vez em primeiro plano, ou consulte os respetivos registos completos a partir de uma única tentativa de arranque. Preserve os carimbos de data e hora do daemon do Docker e de cada dependência.

Os reinícios automáticos repetidos podem substituir o primeiro erro relevante por falhas de ligação posteriores. Um contentor que reinicia a cada poucos segundos também pode sobrecarregar a base de dados, o resolvedor DNS ou o volume de registos e criar sintomas secundários.

Não elimine contentores, volumes ou bases de dados durante esta captura. Pare apenas a tempestade de reinícios, reproduza o problema uma vez e guarde o ambiente, as montagens, as ligações de rede, o comando e o estado de saída antes de alterar a configuração.

Mapeie Todas as Dependências Necessárias para o Contentor Ficar Pronto

Anote a base de dados, a cache, a fila de mensagens, o armazenamento de objetos, o resolvedor DNS, o fornecedor de identidade, os ficheiros montados, os segredos e as APIs externas necessários à aplicação. Inclua o nome de serviço esperado, a porta, o protocolo, o nome de utilizador, a base de dados e o caminho.

A Dash0 explica que a ordem de arranque do Compose não significa automaticamente que o processo dentro de uma dependência esteja pronto; uma aplicação pode iniciar enquanto o Postgres ainda está a inicializar. A solução é aguardar o estado saudável de uma dependência, em vez de aguardar apenas o seu estado em execução.

Classifique as dependências como obrigatórias ou opcionais. A ausência de um serviço opcional de métricas não deve reiniciar a aplicação principal, enquanto uma base de dados indisponível pode exigir uma espera, uma nova tentativa ou uma paragem controlada.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

Teste Cada Dependência a Partir da Rede do Contentor em Falha

Utilize um contentor de diagnóstico temporário ligado à mesma rede ou execute uma shell compatível antes de a aplicação sair. Teste, por esta ordem, o DNS do nome do serviço, a porta TCP, o TLS, a autenticação, uma consulta à base de dados e o caminho necessário.

O guia de verificações de saúde do Compose da Last9 salienta que estas verificações impedem os serviços dependentes de iniciar até que os componentes críticos consigam realmente responder. Uma verificação útil valida a operação do serviço de que os clientes necessitam, em vez de confirmar apenas que existe um processo.

Se o DNS falhar, inspecione a pertença à rede e os aliases. Se a ligação TCP for estabelecida, mas a autenticação falhar, compare os segredos e os utilizadores. Se o início de sessão funcionar, mas o esquema, o bucket, a fila ou o diretório esperado não existir, corrija a inicialização e não a rede.

Verifique Montagens, Segredos e Migrações como Dependências

Compare as montagens vinculadas atuais, os volumes nomeados, as permissões, os proprietários, os ficheiros de ambiente, os ficheiros de segredos e a versão da aplicação com a última implementação funcional. Um contentor pode alcançar a base de dados e, ainda assim, reiniciar porque um ficheiro de configuração é só de leitura ou porque uma migração não consegue escrever.

Um estudo de caso sobre o arranque de contentores mostra que a ordem de dependências baseada no estado de saúde pode impedir que uma aplicação falhe antes de a base de dados estar pronta. A sequência de arranque condicional torna-se especialmente importante durante o primeiro arranque e as migrações.

Execute as migrações uma vez com os registos visíveis e faça uma cópia de segurança da base de dados antes de repetir passos destrutivos. Se a versão da aplicação tiver mudado, confirme que a versão da dependência e o caminho de atualização do esquema são compatíveis.

Reative os Serviços pela Ordem das Dependências e Valide a Estabilidade

Inicie primeiro a dependência de nível mais baixo, aguarde pela sua verificação de saúde real, depois inicie a camada seguinte e, por fim, a aplicação. Registe as contagens de reinícios e as transições do estado de saúde ao longo de vários intervalos de verificação.

O guia da ZimaSpace sobre falhas de DNS do lado do contentor aborda um percurso de dependência que pode surgir apenas dentro do ambiente da aplicação.

O problema só está resolvido quando a aplicação inicia uma vez, todas as dependências obrigatórias permanecem saudáveis, as migrações terminam e um reinício deliberado de uma dependência desencadeia uma nova tentativa ou recuperação controlada, em vez de outro ciclo. Restaure uma política de reinício apenas depois de a falha principal ser observável e estar limitada.