always

A política de reinicialização always no Docker é uma das mais utilizadas para garantir a resiliência de containers em produção. Ela permite que um container seja reiniciado automaticamente sempre que ele parar, independentemente do motivo, garantindo que serviços essenciais permaneçam ativos o máximo possível.

Visão Geral da Política always

Quando a política de reinicialização always é configurada para um container, o Docker tentará mantê-lo em execução continuamente. Isso significa que, sempre que o container parar, seja por falha ou término voluntário do processo, o Docker irá reiniciá-lo automaticamente. Mesmo após a reinicialização do sistema ou do daemon Docker, o container será automaticamente restaurado.

Estrutura do Comando

Para iniciar um container com a política de reinicialização always, o comando básico é:

docker run --restart always <container_name_or_image>

Essa simples configuração é suficiente para garantir que o container seja reiniciado sempre que parar.

Comportamento da Política

1. Falha do container (Exit Status != 0):

   • Quando o container falha (ou seja, retorna um código de saída diferente de zero), o Docker irá reiniciá-lo automaticamente.

2. Encerramento normal (Exit Status = 0):

   • Mesmo que o container seja finalizado normalmente (com código de saída zero), o Docker irá reiniciá-lo automaticamente, o que garante a sua resiliência.

3. Parada manual do container:

   • Se o container for manualmente parado usando comandos como docker stop ou docker kill, ele não será reiniciado imediatamente. No entanto, após uma reinicialização do sistema ou do daemon Docker, o container será reiniciado automaticamente.

4. Reinicialização do daemon ou do sistema:

   • Quando o daemon Docker ou o sistema é reiniciado, todos os containers configurados com a política always serão automaticamente reiniciados, garantindo que seus serviços retornem sem intervenção manual.

Comparação com Outras Políticas

Para entender melhor o comportamento da política always, vamos compará-la com as outras políticas de reinicialização do Docker:

1. on-failure:

   • O Docker apenas reiniciará o container se ele falhar (retornar um código de saída diferente de zero). Se o container for finalizado com sucesso (código de saída 0) ou manualmente, ele não será reiniciado.

2. unless-stopped:

   • O Docker reiniciará o container automaticamente, a menos que ele tenha sido manualmente parado. Containers que foram parados manualmente não serão reiniciados automaticamente após uma reinicialização do sistema ou do daemon Docker.

3. always:

   • O Docker tentará manter o container em execução continuamente, independentemente do motivo de parada. Mesmo após uma reinicialização manual ou do sistema, o container será reiniciado.

Exemplo Prático

Suponha que você tenha um serviço web básico rodando com o servidor Nginx. Para garantir que o serviço esteja sempre disponível, mesmo em caso de falhas ou reinicializações, você pode iniciar o container com a política always:

docker run --name meu-site-nginx --restart always -d nginx

Neste exemplo:

• Se o container falhar ou for finalizado (normalmente ou por erro), ele será reiniciado automaticamente.

• Após uma reinicialização do sistema, o container será automaticamente restaurado.

Você pode verificar o status do container com o comando:

docker ps -a

Isso mostrará se o container está em execução e quantas vezes ele foi reiniciado.

Comportamento Após Reinicializações

Uma das principais vantagens da política always é que o container será reiniciado automaticamente quando o daemon Docker ou o sistema forem reiniciados. Isso a torna uma escolha adequada para serviços críticos que precisam estar sempre em execução, como servidores web, bancos de dados e outros serviços persistentes.

Por exemplo, suponha que o sistema onde o Docker está rodando precise ser reiniciado para manutenção. Se você tiver um container configurado com a política always, ele será reiniciado automaticamente após a conclusão da reinicialização.

Para verificar se o container foi reiniciado automaticamente, você pode usar o comando:

docker ps

Isso mostrará os containers em execução, incluindo aqueles que foram reiniciados pelo Docker após a reinicialização do sistema.

Logs e Diagnóstico

Uma maneira importante de entender o comportamento de reinicialização dos containers é observar os logs. O Docker registra o histórico de reinicializações e falhas dos containers, o que pode ser acessado com o comando docker logs.

Para ver os logs de um container específico:

docker logs <container_name_or_id>

Isso ajuda a diagnosticar o motivo de eventuais falhas e observar quantas vezes o container foi reiniciado.

Você também pode verificar quantas vezes o container foi reiniciado com o comando docker ps -a:

docker ps -a

Isso mostrará uma saída semelhante a:

CONTAINER ID   IMAGE              STATUS                        RESTARTS   NAME
a1b2c3d4e5f6   nginx              Up 1 minute (Restarting)       2          meu-site-nginx

Aqui, o campo RESTARTS mostra quantas vezes o container foi reiniciado.

Casos de Uso

A política de reinicialização always é amplamente utilizada em cenários onde a disponibilidade contínua do serviço é essencial. Aqui estão alguns exemplos típicos:

1. Serviços Web e APIs: Containers que executam serviços web ou APIs precisam estar continuamente disponíveis, mesmo que falhem ou que o sistema precise ser reiniciado. A política always garante que o serviço será restaurado automaticamente.

2. Bancos de Dados: Bancos de dados, como MySQL, PostgreSQL, ou MongoDB, frequentemente são configurados com always para garantir que estejam sempre disponíveis para outras aplicações que dependem deles.

3. Aplicações em Produção: Qualquer aplicação em produção que precise de alta disponibilidade pode se beneficiar da política always. Ela elimina a necessidade de intervenção manual para reiniciar containers que param devido a falhas transitórias ou reinicializações do sistema.

Considerações

Embora a política always seja extremamente útil para garantir a continuidade do serviço, ela também pode levar a comportamentos indesejados em certos cenários, como loops de reinicialização. Se o container continuar falhando repetidamente por um motivo não resolvido (por exemplo, um erro de configuração ou recurso insuficiente), ele será reiniciado continuamente. Isso pode sobrecarregar o sistema e dificultar o diagnóstico.

Para mitigar esse risco, é importante monitorar cuidadosamente os logs dos containers e implementar boas práticas de monitoramento e alerta para identificar falhas repetitivas.

Além disso, a política always deve ser usada com cautela em containers que não precisam estar constantemente em execução. Se um container é destinado a uma execução de curto prazo ou baseado em eventos (como tarefas cron), a política de reinicialização pode não ser apropriada.

Exemplo de Reinicialização por Falha

Vamos considerar um cenário onde um container falha por algum erro interno:

docker run --name teste-falha --restart always alpine /bin/sh -c "exit 1"

Este comando inicia um container Alpine que sempre falha imediatamente (retorna código de saída 1). Com a política always, o Docker tentará reiniciar o container indefinidamente.

Você pode verificar o número de reinicializações com:

docker ps -a

A saída mostrará que o container foi reiniciado várias vezes, até que o erro seja corrigido.

Conclusão

A política restart always no Docker é uma excelente escolha para containers que precisam estar em execução contínua, garantindo alta disponibilidade de serviços. Ela oferece a vantagem de reiniciar containers automaticamente após falhas ou reinicializações do sistema, tornando-a ideal para serviços críticos. No entanto, deve ser usada com cautela em cenários onde falhas repetitivas possam causar loops de reinicialização contínuos. O uso adequado dessa política, combinado com um bom monitoramento e diagnóstico de logs, garante que seus containers permaneçam resilientes e operacionais sem necessidade de intervenção manual constante.

Laboratório

Execução do container com política always:

$ docker container run -d -p 8080:3000 --restart=always marcelodpbarbier
i/simulador-caos:v1
64d69a0146676330aadf216e7861195e98cf415573fc27ecb153e5a397459391

Monitoramente com watch:

$ watch 'docker container ls -a'

Container em execução:

Encerrar aplicação com sucesso:

Container iniciado há 2 segundos:

Encerrar aplicação com erro:

Container iniciado há 7 segundos:

Interromper o monitoramento com watch.

Parar o Docker Daemon:

$ sudo systemctl stop docker
[sudo] password for marcelo:
Warning: Stopping docker.service, but it can still be activated by:
  docker.socket

Aplicação indisponível:

Início do Docker Daemon:

$ sudo systemctl start docker

Iniciar o monitoramente com watch novamente:

$ watch 'docker container ls -a'

Container em execução há 3 segundos:

Se o container for manualmente parado usando comandos como docker stop ou docker kill, ele não será reiniciado imediatamente. No entanto, após uma reinicialização do sistema ou do daemon Docker, o container será reiniciado automaticamente.

Eventos do laboratório realizado:

$ docker events
# container criado manualmente com a política always
2024-09-08T20:01:27.169965030-03:00 container create 64d69a0146676330aadf216e7861195e98cf415573fc27ecb153e5a397459391 (image=marcelodpbarbieri/simulador-caos:v1, name=zen_dirac)
2024-09-08T20:01:27.210144945-03:00 network connect bb5c97c648c3d87055eeb562372870678811f39e672292bb8fca5cc51f776501 (container=64d69a0146676330aadf216e7861195e98cf415573fc27ecb153e5a397459391, name=bridge, type=bridge)
2024-09-08T20:01:27.409324011-03:00 container start 64d69a0146676330aadf216e7861195e98cf415573fc27ecb153e5a397459391 (image=marcelodpbarbieri/simulador-caos:v1, name=zen_dirac)
# aplicação encerrada com sucesso
2024-09-08T20:03:02.115569247-03:00 network disconnect bb5c97c648c3d87055eeb562372870678811f39e672292bb8fca5cc51f776501 (container=64d69a0146676330aadf216e7861195e98cf415573fc27ecb153e5a397459391, name=bridge, type=bridge)
2024-09-08T20:03:02.135067014-03:00 container die 64d69a0146676330aadf216e7861195e98cf415573fc27ecb153e5a397459391 (execDuration=94, exitCode=0, image=marcelodpbarbieri/simulador-caos:v1, name=zen_dirac)
# container reiniciado automaticamente
2024-09-08T20:03:02.176137067-03:00 network connect bb5c97c648c3d87055eeb562372870678811f39e672292bb8fca5cc51f776501 (container=64d69a0146676330aadf216e7861195e98cf415573fc27ecb153e5a397459391, name=bridge, type=bridge)
2024-09-08T20:03:02.423322823-03:00 container start 64d69a0146676330aadf216e7861195e98cf415573fc27ecb153e5a397459391 (image=marcelodpbarbieri/simulador-caos:v1, name=zen_dirac)
# aplicação encerrada com erro
2024-09-08T20:03:57.922442366-03:00 network disconnect bb5c97c648c3d87055eeb562372870678811f39e672292bb8fca5cc51f776501 (container=64d69a0146676330aadf216e7861195e98cf415573fc27ecb153e5a397459391, name=bridge, type=bridge)
2024-09-08T20:03:57.935289130-03:00 container die 64d69a0146676330aadf216e7861195e98cf415573fc27ecb153e5a397459391 (execDuration=55, exitCode=1, image=marcelodpbarbieri/simulador-caos:v1, name=zen_dirac)
# container reiniciado automaticamente
2024-09-08T20:03:57.972360237-03:00 network connect bb5c97c648c3d87055eeb562372870678811f39e672292bb8fca5cc51f776501 (container=64d69a0146676330aadf216e7861195e98cf415573fc27ecb153e5a397459391, name=bridge, type=bridge)
2024-09-08T20:03:58.245288583-03:00 container start 64d69a0146676330aadf216e7861195e98cf415573fc27ecb153e5a397459391 (image=marcelodpbarbieri/simulador-caos:v1, name=zen_dirac)
# Docker Daemon parado
2024-09-08T20:05:48.540629133-03:00 container kill 64d69a0146676330aadf216e7861195e98cf415573fc27ecb153e5a397459391 (image=marcelodpbarbieri/simulador-caos:v1, name=zen_dirac, signal=15)
2024-09-08T20:05:58.546249875-03:00 container kill 64d69a0146676330aadf216e7861195e98cf415573fc27ecb153e5a397459391 (image=marcelodpbarbieri/simulador-caos:v1, name=zen_dirac, signal=9)
2024-09-08T20:05:59.025173796-03:00 network disconnect bb5c97c648c3d87055eeb562372870678811f39e672292bb8fca5cc51f776501 (container=64d69a0146676330aadf216e7861195e98cf415573fc27ecb153e5a397459391, name=bridge, type=bridge)
2024-09-08T20:05:59.034000694-03:00 container stop 64d69a0146676330aadf216e7861195e98cf415573fc27ecb153e5a397459391 (image=marcelodpbarbieri/simulador-caos:v1, name=zen_dirac)
2024-09-08T20:05:59.039194557-03:00 container die 64d69a0146676330aadf216e7861195e98cf415573fc27ecb153e5a397459391 (execDuration=120, exitCode=137, image=marcelodpbarbieri/simulador-caos:v1, name=zen_dirac)
unexpected EOF

# Docker Daemon iniciado
# container reiniciado automaticamente