jaka jest różnica między `stoper docker 'a` killer docker`?

116

Jaka jest różnica między docker stopi docker kill?

Afaik, oba zatrzymają działający pojemnik. Czy to docker stoppróbuje zatrzymać proces przebiegający w kontenerze we właściwy sposób, a jednocześnie docker killwyśle sygnał zabicia? Jeśli tak, to skąd miałby docker stopwiedzieć, jak poprawnie zatrzymać uruchomiony proces. (Ponieważ różni się to w zależności od procesu)

docker

— Geert-Jan
źródło

112

Czy to dlatego, że przystanek dokujący próbuje zatrzymać proces przebiegający w kontenerze we właściwy sposób, podczas gdy zabicie dokera wyśle sygnał zabicia?

Zasadniczo tak, różnica jest subtelna, ale przedstawiona w odnośniku do wiersza poleceń :

docker stop : Zatrzymaj działający kontener ( wyślij SIGTERM, a następnie SIGKILL po okresie karencji ) [...] Główny proces wewnątrz kontenera otrzyma SIGTERM, a po okresie karencji SIGKILL. [moje podkreślenie]
docker kill : Zabij działający kontener ( wyślij SIGKILL lub określony sygnał ) [...] Główny proces wewnątrz kontenera zostanie wysłany SIGKILL lub dowolny sygnał określony opcją --signal. [moje podkreślenie]

stopPróbuje więc wywołać płynne zamknięcie, wysyłając standardowy sygnał POSIX SIGTERM , podczas gdy killdomyślnie zabija proces (ale umożliwia także wysyłanie dowolnego innego sygnału):

Sygnał SIGTERM jest wysyłany do procesu z prośbą o jego zakończenie. W przeciwieństwie do sygnału SIGKILL, proces może go wychwycić, zinterpretować lub zignorować. Pozwala to procesowi na dobre zakończenie zwalniania zasobów i zapisywania stanu, jeśli jest to właściwe. Należy zauważyć, że SIGINT jest prawie identyczny z SIGTERM.

Mimo że w żaden sposób nie jest to egzekwowane, oczekuje się, że procesy będą postępować z SIGTERMgracją i wykonywać właściwe czynności w zależności od ich obowiązków - może to łatwo zakończyć się niepowodzeniem, ponieważ próba płynnego zamknięcia trwa dłużej niż okres karencji, co należy wziąć pod uwagę, jeśli integralność danych jest najważniejsze (np. w przypadku baz danych); patrz np. SIGTERM Majora Haydena vs. SIGKILL, aby uzyskać bardziej szczegółowe wyjaśnienie:

Aplikacja może określić, co chce zrobić po otrzymaniu SIGTERM. Chociaż większość aplikacji oczyści zasoby i przestanie działać, niektóre mogą tego nie zrobić. Aplikacja może być skonfigurowana do robienia czegoś zupełnie innego po otrzymaniu SIGTERM. Ponadto, jeśli aplikacja jest w złym stanie, takim jak oczekiwanie na dyskowe operacje we / wy, może nie być w stanie zareagować na wysłany sygnał.

— Steffen Opel
źródło

1

Więc jeśli chciałbym mieć ogólną procedurę zamykania kontenerów, musiałbym złapać SIGTERM w procesie supervisor / runit?

— CMCDragonkai

Jaka jest tutaj najlepsza praktyka? Rozumiem, dlaczego mielibyśmy używać docker killręcznie, aby zaoszczędzić trochę czasu podczas zamykania, ale w skrypcie, czy nie zawsze lepiej byłoby próbować zamknąć się z wdziękiem docker stop? Nadal jednak widzę wiele docker kills w skryptach.

— Dennis

10

docker kill nagle zatrzyma proces / program głównego punktu wejścia

docker stop spróbuje to zatrzymać z gracją (zapyta grzecznie: P)

w obu przypadkach zmiany systemu plików zostaną utrzymane (w momencie zatrzymania lub zabicia), więc jeśli to zrobisz docker start <container>, będzie kontynuowane od tego momentu.

— niezręczne
źródło

1

... ale w przypadku docker killjakichkolwiek oczekujących zmian w systemie plików, które główny proces nadal miał w pamięci, zostaną utracone, więc system plików może zostać uszkodzony?

— Arjan

oczywiście, ponieważ jest to nagłe zatrzymanie, tylko zmiany w momencie zabójstwa zostaną zachowane. Wszystko w toku zostanie utracone. Chodzi mi o to, że zabicie dokera tak naprawdę nie ... zabicie kontenera, to zatrzymanie procesu. na przykład kiedy

— wyłączasz

2

Kontenery Docker nie są maszynami wirtualnymi, a jądro pozostaje przy życiu przez zabicie. Dlatego wszelkie zmiany systemu plików, które dotarły do jądra, zostaną zatwierdzone w stanie nienaruszonym. Nie powinno być możliwe uszkodzenie systemu plików (w sensie fsck; aplikacja może nie lubić utraty niektórych zapisów). docker killjest analogiczne do zabijania procesu, a nie wyłączania komputera.

— Ian Howson

3

I dodatek do odpowiedzi dodanych wcześniej

bieganie docker eventspo docker stoppokazach wydarzeń

kill (sygnał 15): gdzie sygnał 15 = SIGTERM
umierać
zatrzymać

bieganie docker eventspo docker killpokazach wydarzeń

kill (sygnał 9): gdzie sygnał 9 = SIGKILL
Die (kod wyjścia 137)

docker stopma limit czasu przed zabiciem procesu. Domyślnie jest to 10 sekund.

Ta tabela zawiera jeszcze więcej szczegółów.

— faboulaws
źródło

1

Jest to analogiczne do ściągania wtyczki z pulpitu i wyłączania komputera

Podobnie jak wyciąganie wtyczki oznacza twarde wyłączanie zasilania, docker killoznacza bezpośredni sposób na zabicie my_container, który nie próbuje najpierw zakończyć procesu z wdziękiem.

Wyłączenie komputera oznacza wysłanie sygnału do systemu operacyjnego w celu zamknięcia wszystkich procesów, gdzie docker stopoznacza wysłanie SIGTERMsygnału do działającego kontenera, aby zatrzymać procesy z wdziękiem.

— Rajat Badjatya
źródło