Jak wyglądają procesy w kontenerze Docker?

Ostatnio słyszałem zamieszanie kilka razy wokół tego, czym jest kontener Docker, a ściślej mówiąc, co dzieje się w środku, w odniesieniu do poleceń i procesów, które wywołuję, będąc w kontenerze Docker.

Czy ktoś może przedstawić ogólny przegląd tego, co się dzieje?

Docker zostaje wrzucony do segmentu wirtualizacji, ponieważ ludzie zakładają, że w jakiś sposób wirtualizuje on sprzęt poniżej. Jest to myląca nazwa, która przenika terminologię, z której korzysta Docker, głównie termin kontener.

Jednak Docker nie robi nic magicznego w odniesieniu do wirtualizacji sprzętu systemu. Raczej wykorzystuje zdolność jądra Linuxa do konstruowania „ogrodzeń” wokół kluczowych obiektów, co pozwala procesowi współdziałać z zasobami takimi jak sieć, system plików i uprawnienia (między innymi), aby dać złudzenie, że wchodzisz w interakcje z w pełni funkcjonalnym systemem.

Oto przykład ilustrujący, co się dzieje, gdy uruchamiamy kontener Docker, a następnie wprowadzamy go przez wywołanie /bin/bash.

$ docker run -it ubuntu:latest /bin/bash
root@c0c5c54062df:/#

Teraz z wnętrza tego kontenera, jeśli uruchomimy ps -eaf:

Przechodząc do innej karty terminala, w której jesteśmy zalogowani do systemu hosta, który hostuje kontener Docker, możemy zobaczyć, jak zajmuje miejsce procesowe, które kontener „faktycznie” zajmuje:

Teraz, jeśli wrócimy do zakładki Docker i uruchomimy w niej kilka procesów, a wszystkie z nich uruchomimy w tle, możemy zobaczyć, że mamy kilka procesów potomnych uruchomionych w ramach podstawowego procesu Bash, który pierwotnie rozpoczęliśmy jako część uruchomienia kontenera Docker.

UWAGA: Procesami są 4 sleep 1000polecenia, które są w tle.

Zauważ, jak wewnątrz kontenera Dockera procesom są przypisywane identyfikatory procesów (PID) 48–51. Zobacz je również ps -eafw wynikach:

Jednak dzięki temu następnemu obrazowi ujawnia się wiele „magii”, którą wykonuje Docker.

Zobacz, jak te 4 sleep 1000procesy są tak naprawdę procesami potomnymi w stosunku do naszego oryginalnego procesu Bash? Weź również pod uwagę, że nasz oryginalny pojemnik Docker/bin/bash jest w rzeczywistości procesem potomnym demona Docker.

Teraz, jeśli mielibyśmy czekać ponad 1000 sekund na zakończenie oryginalnych sleep 1000poleceń, a następnie uruchomić jeszcze 4 nowe i uruchomić kolejny kontener Docker w następujący sposób:

$ docker run -it ubuntu:latest /bin/bash
root@450a3ce77d32:/#

Dane wyjściowe komputera hosta ps -eafwyglądałyby tak:

Wszystkie inne kontenery Docker będą po prostu pojawiać się jako procesy w ramach demona Docker.

Widzisz, Docker tak naprawdę nie wirtualizuje ( w tradycyjnym sensie ), buduje „ogrodzenia” wokół różnych zasobów jądra i ogranicza ich widoczność dla danego procesu + dzieci.

Wewnątrz kontenera procesy powinny być izolowane (poddane kwarantannie). W rzeczywistości nie powinieneś widzieć żadnych procesów oprócz tych, które określisz (przynajmniej powłoki). Nie jest przeznaczony do testów „towarzyskich”. Jedyne podobieństwo do chroot polega na tym, że używane jest jądro hosta. Docker jest świetny, jeśli chcesz coś wyizolować lub użyć innej wersji oprogramowania architektury platformy niż ta uruchomiona na hoście. (mówią bardzo stare wersje Javy lub inne rozwidlenie Pythona). Pamiętaj, że foldery i pliki binarne, z którymi masz do czynienia, mogą nie być takie same jak te na hoście. To nie jest ten sam folder / bin itp.

EDYCJA: podobieństwo z chroot zamiast z maszynami wirtualnymi.