Comparando Docker Stop vs. Kill: Quando Usar Cada Comando

Quando seu contêiner precisa ser desligado, docker stop e docker kill não são intercambiáveis. A diferença é mais importante quando seu aplicativo grava dados, mantém conexões de rede ou precisa de tempo de limpeza antes de sair.

Use docker stop para desligamentos normais. Use docker kill quando você precisar de um sinal imediato, geralmente porque o contêiner ignorou uma parada graciosa ou você está testando o comportamento de falha.

Entendendo docker stop

O comando docker stop pede que o processo principal do contêiner saia de forma limpa. Por padrão, o Docker envia SIGTERM para o PID 1 dentro do contêiner, aguarda um período de graça e, em seguida, envia SIGKILL se o processo ainda estiver em execução.

Esse primeiro sinal pode ser alterado pela instrução STOPSIGNAL da imagem ou pela opção --stop-signal usada quando o contêiner é criado. Na maioria dos casos do dia a dia, no entanto, você pode pensar em docker stop como "enviar ao aplicativo uma solicitação de desligamento e forçá-lo apenas se ele não sair".

• Salvar seu estado atual.
• Fechar conexões de rede abertas.
• Liberar recursos que ele mantém.
• Completar quaisquer operações em andamento (como gravar dados no disco).

Em contêineres Linux, o tempo de espera padrão é comumente de 10 segundos, a menos que um tempo limite de parada diferente tenha sido configurado para o contêiner. Contêineres Windows usam um padrão mais longo. Você pode substituir o tempo de espera por comando com -t ou --time.

Como docker stop funciona

1. Enviar SIGTERM: O Docker envia um sinal SIGTERM para o processo principal (PID 1) dentro do contêiner.
2. Aguardar o período de graça: O Docker espera o processo sair.
3. Enviar SIGKILL (se necessário): Se o processo não tiver saído até o final do período de graça, o Docker envia um sinal SIGKILL.

Quando usar docker stop

• Desligamento normal de aplicativos: Este é o método preferido para parar aplicativos que precisam ser desligados de forma limpa, como bancos de dados, servidores web ou aplicativos que realizam gravações críticas.
• Ambientes de desenvolvimento: Para paradas rotineiras durante o desenvolvimento, docker stop garante que você não interrompa acidentalmente processos em andamento.
• Ambientes de produção para manutenção planejada: Quando você precisa reiniciar um serviço ou realizar atualizações, docker stop permite que o aplicativo termine seu trabalho.

Exemplo

# Iniciar um contêiner chamado 'my-web-server'
docker run -d --name my-web-server -p 80:80 nginx

# Parar o contêiner graciosamente
docker stop my-web-server

# Verificar se o contêiner está parado
docker ps -a | grep my-web-server

Se seu aplicativo precisar de mais tempo para liberar filas ou fechar conexões de banco de dados, dê a ele um tempo limite maior:

docker stop --time 30 my-web-server

Entendendo docker kill

O comando docker kill envia um sinal para o processo principal do contêiner imediatamente. Por padrão, esse sinal é SIGKILL. Ao contrário do SIGTERM, o SIGKILL não pode ser capturado, ignorado ou tratado pelo processo. O sistema operacional encerra o processo sem dar a ele a chance de fazer uma limpeza.

Isso significa que dados não salvos, conexões abertas ou gravações em andamento podem ser interrompidos. Um contêiner de teste sem estado pode não se importar. Um banco de dados, trabalhador de fila ou trabalho de processamento de arquivos provavelmente se importa.

Você também pode usar docker kill --signal para enviar um sinal diferente, como SIGHUP, mas se sua intenção é um desligamento gracioso, docker stop geralmente é mais claro.

Como docker kill funciona

1. Enviar SIGKILL: O Docker envia um sinal SIGKILL diretamente para o processo principal (PID 1) dentro do contêiner.
2. Terminação imediata: O processo é encerrado pelo sistema operacional.

Quando usar docker kill

• Contêineres que não respondem: Quando um contêiner está travado e docker stop falhou em terminá-lo mesmo após o período de graça.
• Paradas de emergência: Em situações onde você precisa parar um contêiner imediatamente, independentemente das consequências, como incidentes de segurança ou falhas críticas.
• Testes de resiliência: Para ver como seu aplicativo se comporta quando o processo desaparece sem limpeza.

Exemplo

# Iniciar um contêiner chamado 'my-test-app'
docker run -d --name my-test-app ubuntu sleep infinity

# Forçar a parada do contêiner
docker kill my-test-app

# Verificar se o contêiner está parado
docker ps -a | grep my-test-app

Principais Diferenças Resumidas

Recurso	docker stop	docker kill
Sinal Enviado	Geralmente SIGTERM, depois SIGKILL se o tempo limite expirar	SIGKILL por padrão
Terminação	Graciosa, permite limpeza	Imediata, forçada, sem limpeza
Integridade dos Dados	Geralmente preserva a integridade dos dados	Risco de corrupção de dados ou estado inconsistente
Caso de Uso	Desligamento normal, manutenção planejada	Contêineres que não respondem, paradas de emergência
Período de Graça	Sim	Não

Melhores Práticas e Considerações

• Sempre tente docker stop primeiro: Para operações rotineiras, docker stop deve ser sua escolha padrão. Ele protege seus aplicativos e dados.
• Entenda os sinais do seu aplicativo: Os aplicativos podem ser programados para lidar com sinais SIGTERM. Certifique-se de que o script de ponto de entrada do seu aplicativo ou gerenciador de processos esteja configurado para ouvir e responder ao SIGTERM graciosamente.
• Ajuste o período de graça para docker stop: Você pode especificar um período de graça personalizado para docker stop usando a flag -t ou --time. Por exemplo, docker stop -t 30 my-container dá ao contêiner 30 segundos para desligar.
• Use docker kill como último recurso: Recorra ao docker kill apenas quando docker stop for ineficaz ou em situações críticas e urgentes.
• Monitore a saúde do contêiner: Implementar verificações de saúde em sua configuração Docker pode ajudar a identificar contêineres que estão se tornando não responsivos, permitindo que você potencialmente resolva problemas antes que eles exijam um docker kill.
• Verifique o comportamento do PID 1: Scripts wrapper de shell podem engolir sinais se não os encaminharem para o processo real do aplicativo. Prefira exec em scripts de ponto de entrada para que o aplicativo receba sinais de desligamento diretamente.

Conclusão Prática

Torne docker stop seu hábito normal, especialmente para qualquer coisa com estado. Recorra ao docker kill apenas quando o contêiner não responder, quando a velocidade for mais importante que a limpeza, ou quando você estiver deliberadamente testando o comportamento de falha.