Como adequar as políticas de reinício do Docker a bases de dados, processos de trabalho e aplicações Web

Associe as políticas de reinício do Docker ao ciclo de vida do serviço e à semântica de saída, em vez de atribuir unless-stopped a todos os contentores num ficheiro Compose.

As políticas de reinício reagem quando o processo principal de um contentor termina; uma verificação de integridade pode marcar um processo ainda em execução como não íntegro sem o reiniciar automaticamente. Por isso, bases de dados, workers, aplicações Web, migrações e tarefas agendadas precisam de escolhas diferentes, com base no facto de deverem permanecer em execução, no significado de uma saída normal e na forma como uma falha repetida deve ser comunicada.

Separe o Comportamento de Reinício da Integridade e da Prontidão

Uma política de reinício determina se o Docker deve iniciar novamente um contentor depois de o respetivo processo parar. Uma verificação de integridade determina se o serviço em execução consegue realizar uma operação definida. A prontidão das dependências determina se outro serviço já deve arrancar. Resolvem problemas relacionados, mas diferentes.

Um artigo de 2026 sobre integridade e reinício separados explica esta separação e mostra como as condições de integridade do Compose podem atrasar o arranque de serviços dependentes até que um serviço esteja efetivamente pronto.

Não espere que restart: always repare um processo Web não íntegro que nunca termina, nem que uma verificação de integridade, por si só, o reinicie. Faça a aplicação terminar quando não for seguro continuar, adicione um mecanismo externo de correção ou alerte para o estado não íntegro, de acordo com o desenho do serviço.

Utilize Políticas de Reinício Persistentes para Bases de Dados de Longa Duração

Normalmente, espera-se que uma base de dados num servidor doméstico volte a estar disponível depois de um reinício do anfitrião ou do daemon do Docker. unless-stopped é frequentemente uma predefinição prática quando se deve respeitar uma paragem intencional por parte do administrador; always é adequada quando, por conceção, o reinício deve ignorar esse estado de paragem manual.

Um artigo de julho de 2026 sobre o comportamento das políticas de reinício detalha as diferenças entre no, on-failure, always e unless-stopped, incluindo o facto de a política reagir à saída do processo e não ao estado de integridade.

A base de dados também precisa de uma verificação de integridade real e de armazenamento persistente. Reiniciar repetidamente o PostgreSQL não pode resolver um disco cheio, uma configuração inválida, um estado corrompido ou uma migração incompatível. Em vez de tratar os reinícios como resiliência bem-sucedida, alerte para reinícios repetidos.

Escolha a Política do Worker com Base na Fila e na Semântica de Saída

Um worker de fila de longa duração pode justificar unless-stopped se dever consumir trabalho continuamente. Um worker finito ou um processo de lote pode utilizar on-failure:N, para que os erros transitórios recebam novas tentativas limitadas, enquanto uma falha persistente para de forma visível.

Um artigo atual sobre novas tentativas limitadas com on-failure salienta que o comportamento das tentativas deve corresponder ao facto de um processo dever permanecer permanentemente ativo ou poder terminar normalmente.

Saiba o que significa o código de saída 0 na imagem do worker. Se significar “tarefa concluída”, always pode transformar uma tarefa executada uma única vez com sucesso num ciclo infinito. Se o worker se destinar a funcionar como daemon, uma saída normal inesperada pode ainda justificar um reinício automático através de unless-stopped.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Mantenha as Aplicações Web em Execução, mas Condicione-as a Dependências Reais

A maioria das aplicações Web autoalojadas destina-se a permanecer continuamente disponível, pelo que unless-stopped é normalmente mais fácil de interpretar do que uma política limitada apenas a falhas. A definição de reinício não elimina a necessidade de a base de dados, a cache, o DNS, os segredos e os caminhos montados estarem prontos.

O diagnóstico relacionado da ZimaSpace sobre ciclos de reinício causados por dependências de contentores mostra por que motivo reiniciar repetidamente a aplicação visível pode ocultar a falha da base de dados, da cache, da montagem, da migração ou da memória que ocorreu primeiro.

Utilize verificações de integridade das dependências para ordenar o arranque quando apropriado e limite o comportamento de novas tentativas da aplicação. Um serviço Web que falha a cada cinco segundos até o PostgreSQL arrancar é menos observável do que um serviço que aguarda a prontidão e produz um único arranque limpo.

Dê às Migrações e às Tarefas Executadas uma Única Vez um Ciclo de Vida Finito

Contentores de migração, importadores, tarefas de manutenção e tarefas de inicialização executadas uma única vez não são daemons comuns. O estado de sucesso é frequentemente “terminar com o código 0 e permanecer parado”. Utilizar always ou unless-stopped pode repetir involuntariamente trabalho já concluído.

Mantenha explícitas as ferramentas operacionais executadas uma única vez, em vez de permitir que se tornem serviços ocultos sempre ativos. Uma migração ou um importador deve ter um estado de sucesso finito, que permaneça visível depois de o comando terminar.

Utilize restart: "no" quando uma falha deva interromper o processo para inspeção, ou on-failure limitado apenas quando for seguro repetir o comando. No caso de migrações de esquema, confirme primeiro que é possível repetir uma migração parcialmente aplicada antes de automatizar novas tentativas.

Teste a Política com Modos de Falha Reais

Para cada serviço, teste uma saída normal do processo, uma falha com código diferente de zero, um reinício do anfitrião, um reinício do daemon do Docker, uma paragem manual, uma condição de serviço não íntegro mas em execução e uma dependência indisponível. Registe o estado esperado após cada evento antes de considerar a configuração resiliente.

Acompanhe a contagem de reinícios e alerte quando ultrapassar um limite baixo num determinado intervalo de tempo. O reinício automático deve reduzir o tempo de recuperação de uma falha transitória; não deve tornar uma falha persistente invisível ao produzir um fluxo interminável de novos contentores.

Uma boa matriz de políticas é explícita: as bases de dados e aplicações Web de longa duração regressam após reinícios da infraestrutura, os workers daemon recuperam de acordo com a semântica da fila, as tarefas finitas param quando terminam e as verificações de integridade e prontidão expõem falhas que a política de reinício não consegue detetar.