Różnica między dockerem a maszyną wirtualną

Hej zapewne to bardzo podstawowe pytanie, ale zaczynam przerabiać Dockera i zastanawia mnie jedna rzecz, na która chyba zbyt głupi jestem by sam wpaść.

Wszędzie mówią, że Docker tak dużo zyskuje względem VM, ponieważ sharowany jest OS na hoscie, natomiast w VM każda wirtualka stawia swój OS. Jaki tutaj jest plus/różnica, bo gdzie nie patrzę na kontenery to i tak każdy raktycznie ich image ma BASE po jakieś dystrybucji linuxa, więc z tego co rozumiem, każdy kontener i tak tworzy OS w swoim zakresie na którym potem jest jakiś nginx czy inne serwisy instalowany.

Nie mogę tego skumać bo wychodzi mi, że i w przypadku VM instalujesz OS by na nim postawić np nginxa, tak samo w kontenerze tworzysz image BASE jakiś distro linuxa i ostatecznie też w każdym kontenerze masz postawiony OS.

Są znacznie różniące się poziomy izolacji

Maszyna Wirtualna daje cie jakby nowy pecet ze "urządzeniami sprzętowymi" i BIOSem, instalujesz wszystko.

Konteneryzacja w stylu Dockerowym udostepnia wycinek zasobów w już itsniejacycm (na zewnątrz dockera) systemie operacyjnym co do załadowanego kernela *)
Uciekły mi z głowy nazwy funkcji systemowych linuxa (cgroups ??), na jakich to jest oparte, generalnie dość stare funkcje, specjaliści budowali fundamenty od dawna. super ze Docker z tego zrobił użytek.
Przed dockerem służyły podobnie, choć w znacznie prostszych zastosowaniach: skroić limitowane środowisko dla jakiegoś programu.

Np developerze javowscy (do którejś wersji Javy) stali przed głupiejącym GC. Kroisz Dockera na 2 GB RAM, sądzisz, ze apka javowska będzie odpalać GC jak podejdzie pod 1.5 GB (przykładowo)
Ale JVM (w tych starszych wersjach) pytała systemu funkcjami, których docker nie przechwytywał "hej systemie, ile masz wolnego RAM" ... "a powiem ci mam 47 GB" ... "aha, to nie odśmiecam i mogę jeszcze sporo alokować"

*) dystrybucja to coś jakościowo innego, niż aktywny kernel, ale chyba rozumiesz

Jak masz wirtualk,i to każda wirtualka jest osobnym i niezależnym bytem. Każda z nich zawiera w sobie wszystko, co jest potrzebne do działania.
Plusem jest to, że są one niezależne, każda jest kompletna. Każda ma swoje niezależne pliki - cały core/jądro systemu, ustawienia, dyski itp.
Minusem jest to, że każda z nich ma zapotrzebowanie na CPU, RAM, tworzy wirtualny dysk itp. - także masz kilka osobnych systemów, ale dużo rzeczy się pokrywa, wszystkie systemu mają podobne elementy itp.
Za to w przypadku Dockera masz jeden system, który jest jakby współdzielony między kontenerami. Czyli - sam system (jądro, katalogi systemowe, partycje, RAM, CPU itp) jest odpalony raz, a poszczególne aplikacje w systemie (czyli kontenery) są jakby "nakładane" na system. Są one od siebie oddzielone, ale "pod spodem" mają wiele rzeczy wspólnych.

Jak się sypnie jedna wirtualka, to inne chodzą, ale dzieje się to kosztem tego, że każda VM potrzebuje dużo zasobów CPU/RAM/HDD.
Kontenery/Docker są o wiele mniej zasobożerne, ale za to jest ryzyko, że jak się uszkodzi system, na którym one stoją (i z którego biorą "wspólną część") to żaden kontener nie ruszy.

Do tego - w przypadku VM masz jakby goły serwer, na który musisz sobie sam poinstalować i skonfigurować usługi. Jak masz Dockera to go po prostu odpalasz, a aplikacja się odpala. I już w tym obrazie możesz mieć zaszyte różne ustawienia, detale konfiguracji i inne rzeczy, które w wypadku VM musiałbyś sobie sam ustawiać. Przykładowo - możesz pobrać Dockera jakieś aplikacji, odpalić go i praktyczne ta usługa działa od ręki. Albo idziesz w kierunku wirtualki - ściągasz sobie instalkę jakiejś apki, instalujesz ręcznie, potem grzebiesz w konfiguracji, dostrajasz i po godzinie możesz korzystać ;)

EDIT
Wymyśliłem właśnie fajną analogię:

• Docker: Jeden duży lokal, w którym masz kilka okienek z rożnymi typami potraw: pizza, chińskie, kebab itp. Wspólna kuchnia, jeden właściciel, wspólni kucharze, kelnerzy, jedna księgowa
• Wirtualka: kilka niezależnych knajp wynajmujących lokale obok siebie w centrum handlowym: osobni właściciele, osobne kuchnie i kucharze, osobna obsługa, niezależna księgowa dla każdego z lokali

cerrato napisał(a):

Kontenery/Docker są o wiele mniej zasobożerne, ale za to jest ryzyko, że jak się uszkodzi system, na którym one stoją (i z którego biorą "wspólną część") to żaden kontener nie ruszy.

Jak padnie VMM lub system hosta wirtualizacyjnego, to jest mniej więcej taki sam skutek.

Jak padnie VMM lub system hosta wirtualizacyjnego, to jest mniej więcej taki sam skutek.

Oczywiście, ale jak np. zrobisz sudo apt-get upgrade na wirtualce i coś się skonfliktuje, wychrzani, złamią się jakieś zależności itp, to psujesz system tylko tej jednej wirtualki. A jak zrobisz to na systemie, na którym stoi Docker i coś się zepsuje to wszystkie kontenery moga się wysypać. O to mi chodziło.
Oczywiste jest to (masz rację) że jak padnie hypervisor to wszystkie stojące na nim wirtualki staną się niedostępne.

Ok dzięki za wytłumaczenie. Myślę, już po części rozumiem. W skrócie wynika, że tak naprawdę te wszystkie image w dockerze, które w większości są oparte na jakiś imagach linuxowych dysturbucji to stawiają w obrębie kontenera system, ale tylko warstwę aplikacyjną bo warstwa jądra linuxa jest współdzielona z hostem.

Widać to było dla mnie mylne bo jak widzę w jakimś image "BASE linux xxx" to od razu zakładałem, że tam cały system się postawi w kontenerze razem z kernelem.

Warto wspomnieć, że w kontenerze używa się okrojonych do minimum dystrybucji Linuxa, które nie zawierają ton narzędzi, których potrzebujesz na VM. Jak odpalisz na nim tylko aplikację w Javie, to nie potrzebujesz gcc, Perli, Pythonów i mnóstwa innych rzeczy, więc ten system jest dużo lżejszy niż na VM.