Docker oder VM: Wann wir was verwendet?

[Michael20]

Hallo,

ich habe mir heute eine DS918+ gekauft, mit der man sowohl Docker Container als auch eigene VM installieren kann.

Ich möchte nextcloud, OnlyOffice Server und OpenProject-Server installieren.
Soweit ich weiß, gibt es zu allen auch Docker Installationen.

Jetzt meine Frage an die Experten:
Was ist besser oder wann verwende ich Docker und wann setze ich eine eigene VM auf (bezüglich Wartbarkeit, Stabilität, Backup, Performance, ...)

Vielen Dank für eure Hinweise!
Michael

 

[haydibe]

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.

 

[hakiri]

Gibt es hier gar keinen DANKE Button? Der Beitrag von haydibe wäre es mehr als wert
Tolle Zusammenfassung.
Ich kann mich da nur anschließen und verwende alles mit Docker sofern es auch die Anforderungen an das Netzwerk erfüllt. Manchmal kommt es bei vielen Containern zu Überschneidungen mit einigen Ports oder nicht alles lässt sich NATen, da ja ein Container per default eine von anderen im Netzwerk befindlichen Geräten IP verwendet. Dann nehme ich eine VM. Alternativ kann man auch noch den Host Modus bei Docker verwenden, sofern die Ports nicht von Synology belegt sind.
Auch prüfen sollten man, wie man seine Backup Strategie plant. Für Docker und VMM gibt es da unterschiedliche Tools bei der Synology. Einfach mal mit rumspielen und Erfahrung sammeln.

 

[Nomad]

Ich denke wenn jemand heutzutage noch zu VM greift hat er trifftige Gründe.

Nach Migration aller Hard- und Software gibt es da z.B. eine alte Anwendung die nur unter Windows XP läuft. Dafür will man aber nicht extra Hardware abstellen und beten, dass er nicht an Alterschwäche stirbt. Oder es gibt eine bereits lange genutzte VM die einfach weiter am laufen gehalten werden soll. Oder es wird eine komplexe Netzwerkonstellation zum Testen benötigt.

Gerade wenn die benötigte Anwendung unter Docker bereits zur Verfügung steht dürfte VM selten die "effizienteste" Lösung darstellen.

Letztendlich muss man die Entwicklungshistorie sehen. VMs haben ihre Daseinsberechtigung und sind nachwievor hilfreich. Um (auch) einige ihrer Probleme zu lösen entstand Docker. Wenn ich nicht einen Haufen Altlasten in Form von VMs und Know-How mitschleppen würde wäre begeisterter von Docker oder auch nicht. Da wäre nämlich immer noch die Frage wozu der Aufwand mit Docker wenn die Anwendung auch nativ läuft? Ist es mehr Aufwand Docker UND die Anwendung zu konfigurieren als sie direkt laufen zu lassen?

 

[haydibe]

Ist es mehr Aufwand Docker UND die Anwendung zu konfigurieren als sie direkt laufen zu lassen?

Was muss denn an Docker konfiguriert werden? Es gibt zwar einige Stellschrauben, aber diese müssen in der Regel nicht angepasst werden. Solange man ein fertig Image von Dockerhub verwendet und dessen bereitgestellten Konfigurationsmöglichkeiten erlauben das benötigte Ziel zu erreichen: es wird einfacher - jemand hat bereits das Wissen um die Installation, Konfiguration und Parameterisierung von ausserhalb gelöst, so dass man sich nicht selber damit auseinandersetzen muss.

Erst wenn man selber Docker-Images bauen will, wird es schwierieger, da die Installation und Konfiguration der Anwendung komplett verscriptet werden muss. Wer seine VMs eh schon mit Konfigurationmanagement-Werkzeugen wie Anisble, Puppet, Chef oder eigenen Bash-Skripte aufsetzt und pfegt ist das schon gewohnt. Wer allerdings eigene Docker-Images bauen will und keine Ahnung von Automatisierung hat und auch kein interesse daran hat sich das Wissen anzueignen für den kann es zu einer schwer zu überbrückenden Hürde werden. Mit ein bischen Kreativität kann man sich auf Dockerhub entsprechende Repos such, von dort auf die Github Repos wechseln und diese als Inspiration für Themen wie "wie verwende ich eigentlich ENV-Variablen um Konfigurationsdateien anzupassen?" zu verwenden.

 

[Nomad]

Es liegt wohl an meinem Paranoia.

Alles was man nicht selbst kompiliert hat kommt nicht ans Netz. Wenn man aus dieser Steinzeit kommt fällt einem schwer aus den gefühlt Abermillionen von Paketen die irgend jemand zusammengestellt hat und ganze hunderte von Downloads vorweisen kann in sein Netzwerk zu holen.

Schlimm genug, wenn jemand anders es schafft Schädlinge auf meinen Rechner zu packen aber noch schlimmer wenn man so etwas höchspersönlich und eigenhändig installiert.

Bekanntes Paket aus bekannter Quelle geholt und soweit wie man versteht konfigurieren. Vielleicht umständlich aber ich mag es.

 

[haydibe]

Auf Dockerhub gibt es Images die via "automated build" erzeugt werden. Dort kann man das Dockerfile einsehen und sicher sein, dass nur das was dort steht auch passiert ist.
Mit `docker image history {imageid} --no-trunc` kann man jederzeit einsehen welche Befehl beim Bau eines Images verwendet wurden.
Selbst bei Images die nicht via "automated build" erstellt werden kann man so sehen wie das Image zustande gekommen ist.

Vorziehen würde ich trotzdem Images die per "automated build" direkt auf Servern von Docker gebaut werden. Ich bin bspw. kein Freund von Debian (weder selbstinstalliert, noch als Base-Image), da dort auch fertig kompilierte Pakete hochgeladen werden können. Bei Ubuntu werden alle Pakete direkt durch Ubuntu gebaut. Ein Stück weit kann ich die paranoia verstehen

Trotzdem bleibt es charmant, dass man das Vorgehen in einem Dockerfile dokumentiert hat und die Ausführung eines Images immer zum selben Ziel führt. Beim "Neuaufsetzen" kann man nicht versehentlich irgendwelche Schritte vergessen. Ich bin ein Freund der Automatisierung, daher passt Docker gut in mein Repertoir. Meine VMs baue ich mit packer auf ESXi. Meine VMs erzeuge und deploye ich mit Ansible auf ESXi. Meine Apps in den VMs betreibe ich mit Docker Swarm (Umstieg auf Kubernetes steht die Tage an)... Wenn ich mal eine neue Spielumgebung brauche, dann baue ich mir ein neues Ansible Inventory und eine neue Group Vars Datei und los gehts - wenige Minuten später steht alles. Aufwändig zu erstellen? Oh ja! Aufwändig zu benutzen? Nö! Zeitersparniss ab der zweiten Verwendung: definitiv.

 

[Michael20]

Hallo an Alle,

vielen Dank für eure zahlreichen Hinweise!
Ich werde mich noch weiter einlesen, was genau die Software-Pakete benötigen und dann nach euren Empfehlungen entscheiden.

Vielen Dank!
Michael