Questão qual é a diferença entre `docker stop` e` docker kill`?


Qual é a diferença entre docker stop e docker kill?

Afaik, ambos irão parar um contêiner em execução. É isso docker stop tenta parar o processo dentro do contêiner da maneira correta, enquanto docker kill irá enviar um sinal de matar? Se sim, como seria docker stop sabe como parar corretamente o processo em execução. (Como isso difere de processo para processo)


85


origem




Respostas:


Será que o docker stop tenta interromper o processo dentro do contêiner da maneira correta, enquanto o docker kill envia um sinal de kill?

Basicamente sim, a diferença é sutil, mas delineada no Linha de comando referência:

  • paragem do docker: Pare um recipiente em funcionamento (enviar SIGTERM e depois SIGKILL após o período de carência) [...] O processo principal dentro do container receberá o SIGTERM, e após um período de carência, o SIGKILL. [ênfase minha]
  • matador do estivador: Mate um contêiner em execução (enviar SIGKILL ou sinal especificado) [...] O processo principal dentro do container será enviado SIGKILL, ou qualquer sinal especificado com a opção --sinal. [ênfase minha]

assim stop tenta disparar um desligamento normal enviando o padrão Sinal POSIX  SIGTERM, enquanto que killapenas mata o processo por padrão (mas também permite enviar qualquer outro sinal):

O sinal SIGTERM é enviado para um processo para solicitar sua finalização. Ao contrário do sinal SIGKILL, ele pode ser capturado e interpretado ou ignorado pelo processo. Isso permite que o processo execute bons recursos de liberação de terminação e salve o estado, se apropriado. Deve-se notar que o SIGINT é quase idêntico ao SIGTERM.

Embora não seja aplicado de qualquer maneira, geralmente espera-se que os processos tratem SIGTERM graciosamente e fazer a coisa certa, dependendo de suas responsabilidades - isso pode falhar facilmente devido à tentativa de desligamento normal levar mais tempo do que o período de carência, o que é algo a considerar se a integridade dos dados é primordial (por exemplo, para bancos de dados); veja por exemplo Major Hayden's SIGTERM vs SIGKILL para uma explicação mais detalhada:

O aplicativo pode determinar o que deseja fazer quando um SIGTERM é recebido. Embora a maioria dos aplicativos limpe seus recursos e pare, outros não. Um aplicativo pode ser configurado para fazer algo completamente diferente quando um SIGTERM é recebido. Além disso, se o aplicativo estiver em um estado ruim, como aguardar E / S de disco, talvez não seja capaz de agir no sinal que foi enviado.


83



Então, se eu quisesse ter um procedimento de desligamento genérico para contêineres, eu teria que pegar o SIGTERM no processo de supervisor / runit? - CMCDragonkai
Qual a melhor prática aqui? Eu entendo porque nós usaríamos docker killà mão para economizar algum tempo durante o desligamento, mas em um script, não seria sempre melhor tentar um desligamento normal via docker stop? Eu ainda estou vendo muita docker kills em scripts embora. - Dennis


docker kill irá parar abruptamente o processo / programa do ponto de entrada principal

docker stop vai tentar pará-lo graciosamente (vai pedir educadamente: P)

em ambos os casos, as alterações no sistema de arquivos serão mantidas (no momento de parar ou matar), então se você docker start <container> então continuará a partir daí.


6



... mas em caso de docker kill qualquer alteração no sistema de arquivos pendente que o processo principal ainda tivesse na memória será perdida, para que o sistema de arquivos possa ser danificado? - Arjan
obviamente, uma vez que é uma parada abrupta, apenas as alterações no momento da morte serão persistidas. Tudo o que estiver pendente será perdido. Meu ponto é que o docker kill não está realmente ... matando o contêiner, impedindo o processo. como quando você desligar o computador em vez de desligar - awkwardarts