Bei einer VM wird ein vollständiger Computer virtualisiert:
- eine VM läuft vollständig isoliert und verhält sich wie ein eigenständiges System
- eine VM hat sein eigenes BIOS
- eine VM hat sein eigenes OS mit eingem Kernel (ineffizieter als Container: kostet RAM, CPU-Zeit und Plattenplatz=
- eine VM hat relativ lange Startzeigen, da erst das OS und die Anwendungen gestartet werden müsse
- eine VM muss separat gepatched und aktuell gehalten werden
- In jedem OS jeder VM laufen alle für das OS notwendigen Prozesse und belegen jeweils ihre eigenen Ressourcen (Ineffizienter als Container: kostet RAM und CPU-Zeit)
- Hardwarezugriffe (jeder Zugriff auf die Festplatte, Bildschirm, durchgereichtes Gerät) werden durch den Hypervisor abstrahiert und müssen kompliziert zwischen Wirt und Gast-VMs synchronisiert werden (Ineffizienter als Container: kostet CPU-Zeit)
Vorteile:
- man kann sein gesamtes Wissen über ein OS mitnehmen und nahtlos in die VM-Welt übertragen.
Nachteile:
- Ressourcenverschwendung im Vergleich zum Container
- Die Daten für Anwendungen könnten quer über die VM verteilt sein
- lange Startzeit
Bei einem Container wird lediglich eine Anwendung virtualisiert:
- ein Container wird über Linux-Boardmittel isoliert, ist aber kein eigenständiges System
- ein Container verwenet den Kernel des Wirt-Systems
- ein Container basiert meist auf einem minimalen OS-Basis-Image (dies kann ein anderes sein als das des Wirts und für jeden Container anders sein), das eher dazu dient in gewohnten Umfeld für die Kernanwendung notwendige Abhängigkeiten bereitszustellen
- ein Container wird nicht gepachted (technisch möglich, aber sinnfrei) - ein gepatchtes Image muss gebaut bzw. heruntgerladen werden.
- In jedem Container laufen nur die Prozesse, die für den Betrieb der Kernanwendung notwendig sind (effizienter als VM: spart RAM und CPU-Zeit)
- Hardwarezugriffe werden direkt von dem Wirts-Kernel abgewickelt - (effizienter als VM: spart CPU-Zeit)
Vorteile:
- Sehr effizienter Umgang mit Ressourcen - kaum mehrverbraucht im Vergleich zum direkten Start eines Prozesses auf dem Wirtssystem
- Kapselung der Anwendungen - dadurch das man Verzeichnisse für Volume Mappings selber vorgibt weiss man IMMER wo welche Daten liegen.
- Schnelle Startzeiten (es werden ja nur die für die Hauptanwendung notwendigen Prozesse gestartet)
-Wissen über den Umgang mit Linux und Bash kann nahtlos übernommen werden und ist von Vorteil, wenn man eigene Docker Images bauen möchte.
Nachteile:
- Man muss sich erst in die "Docker-Denkweise" einarbeiten - neues Wissen ist aufzubauen
Solange nur eine Anwendung betrieben werden soll, die keine besonderen Anforderungen an die Netzwerk-Konfiguration stellt (bspw. Multicast Nachrichten ) oder Hardware (USB-Geräte) stellt, würde ich immer einen ressourcensparenden Container verwenden. Wenn man natürlich eine Windows-Anwendung oder ein besondere Unix/Linux Variante einsetzen möchte, führt natürlich kein Weg an einer VM vorbei!
Ich habe miterweile drei ESXi Server als Homelab zuhause, die einzigen VMs die dort laufen sind Docker-Hosts, meine Anwendungen laufen ALLE in Containern. Für mich hat sich die Welt dadurch deutlich vereinfacht - aber nicht jeder hat Lust oder die Kapazitäten sich in die Docker-Denkweise einzuarbeiten.
