Como usar políticas de reinicialização do Docker para manter os contêineres em execução

O Docker oferece várias opções para gerenciar o ciclo de vida do seu contêiner. Normalmente, os contêineres não reiniciam automaticamente após serem encerrados. Com as políticas de reinicialização, você pode controlar os ciclos de vida de contêineres individuais.

As políticas de reinicialização serão usadas sempre que um contêiner parar de funcionar. O Docker também analisa as políticas de reinicialização quando o daemon é inicializado. Você pode usar este mecanismo para trazer contêineres com seu host após as reinicializações.

Políticas disponíveis

Existem atualmente quatro políticas de reinicialização diferentes:

• não – Esta política nunca iniciará automaticamente um contêiner. Esta é a política padrão para todos os contêineres criados com docker run.
• sempre – O Docker garantirá que o contêiner esteja sempre em execução. Se o contêiner parar, ele será reiniciado imediatamente. Você ainda pode parar manualmente o contêiner com parada do docker, mas o Docker o trará de volta na próxima vez que o daemon for reiniciado.
• em caso de falha – O contêiner será reiniciado se parar devido a um erro. O Docker não abrirá o contêiner depois que o daemon for reiniciado.
• a menos que seja interrompido – Isso funciona de forma semelhante a sempre. A diferença é que o Docker nunca reiniciará o contêiner se ele tiver sido interrompido manualmente.

Você normalmente usará uma das três últimas opções para cargas de trabalho de produção. Como os contêineres do Docker costumam ser usados ​​para serviços em segundo plano de longa duração, geralmente você deseja que eles sejam reiniciados sempre que algo der errado. A política não é mais adequada para uso no desenvolvimento local. Também é útil para contêineres de utilitários que executam um único executável e, em seguida, são encerrados.

Pode ser difícil decidir qual política de reinicialização usar. sempre é sempre a escolha mais natural, mas o comportamento de reinicialização do daemon pode ser facilmente esquecido. Se quiser que os contêineres permaneçam parados de forma confiável depois de executar o docker stop, você deve usar a menos que seja interrompido.

O Docker detecta erros com base no código de saída emitido do processo de primeiro plano do contêiner. Um código de saída de 1 ou superior é interpretado como um erro. Isso corresponde ao tratamento Unix de códigos de saída, onde apenas 0 representa uma execução bem-sucedida.

Quando o Docker reinicia seu contêiner, é equivalente a executar o docker run novamente. Isso significa que o script ENTRYPOINT da imagem será invocado. Os sistemas de bootstrap devem sempre ser resilientes a várias invocações.

Aplicação de uma política de reinicialização

Você pode iniciar um contêiner com uma política de reinicialização específica passando o sinalizador --restart para docker run:

 docker run --name httpd --restart sempre httpd: mais recente 

Se você estiver usando o Docker Compose, adicione o campo de reinicialização ao seu docker-compose. yml:

Serviços de

: httpd: imagem: httpd: última reinicialização: sempre

Você pode alterar a política de reinicialização de um contêiner existente usando a atualização do docker. Passe o nome do container para o comando. Você pode encontrar nomes de contêiner executando docker ps -a.

 atualização do docker --restart-policy a menos que interrompido httpd 

Você pode usar a atualização do docker com contêineres em execução ou interrompidos.

Reiniciar loops

O Docker inclui algumas proteções contra loops de reinicialização perpétua. O primeiro é um atraso obrigatório antes de as políticas de reinicialização serem ativadas. O Docker não começará a monitorar as reinicializações até que um contêiner esteja em execução por pelo menos 10 segundos. Isso evita que um contêiner com falha reinicie continuamente.

O outro comportamento do especialista diz respeito ao comando docker stop. O Docker sempre respeitará o uso de docker stop, portanto, o contêiner não será reiniciado imediatamente após a execução do comando. Se você realmente deseja reiniciar o contêiner, use o docker restart.

Limitando as tentativas de reinicialização

A política de reinicialização em caso de falha permite especificar quantas tentativas devem ser feitas. O Docker desistirá e deixará o contêiner em um estado parado se ele falhar ao iniciar várias vezes em sucessão.

 docker executado httpd: mais recente --restart em caso de falha: 5 

Neste exemplo, o Docker tentará reiniciar o contêiner cinco vezes após uma falha (código de saída diferente de zero). Se o contêiner falhar ao iniciar na quinta tentativa, nenhuma nova tentativa será feita. Esta opção é útil para contêineres onde um erro inicial persistente provavelmente não será resolvido sem intervenção manual.

Investigando por que os contêineres pararam

Se você precisa saber por que um contêiner parou, execute docker ps -a. Isso mostrará os detalhes de todos os seus contêineres, parados ou em execução. Encontre o contêiner de destino e verifique seu “ Status ” coluna. Para contêineres parados, o código de saída será mostrado entre colchetes. Se o código for maior que zero, o contêiner foi encerrado devido a um erro.

Você precisa consultar a documentação do processo em execução no contêiner para determinar os significados dos códigos de erro individuais. No entanto, muitas vezes você pode obter insights sobre o que causou a falha, recuperando os registros do contêiner. Os registros permanecem disponíveis depois que um contêiner é interrompido.

 docker registra my-container 

O fluxo de registro agrega a saída padrão do contêiner e os fluxos de erro padrão. Se o erro foi registrado, você deve esperar vê-lo nas últimas linhas de saída.

Resumo

As políticas de reinicialização ajudam a garantir que seus contêineres do Docker estejam lá quando você precisar deles. O padrão nenhuma política é inadequado para a maioria das cargas de trabalho de produção. Você não quer que seus contêineres fiquem parados se travarem!

O uso de uma das três políticas com capacidade de reinicialização torna seus contêineres mais resistentes a reinicializações de hardware e encerramento inesperado. O Docker manterá a disponibilidade do serviço no caso de uma falha do contêiner.