Unterschiede VMs vs. Container

Da sich hier in diesem Forumsbereich bisher wenig getan hat, poste ich hier mal eine überarbeitete Variante eines alten Beitrags von mir aus einem anderen Forum.

Aus meiner Sicht sind dies die wesentliche Punkte die VM's bzw. Container ausmachen und einige Vor-/Nachteile.


Bei einer VM wird ein vollständiger Computer virtualisiert:
  • Eine VM läuft auf emulierter Hardware
  • Eine VM hat sein eigenes BIOS
  • Eine VM hat ein vollständiges OS mit eigenem Kernel (ineffizienter als Container: kostet RAM, CPU-Zeit und Plattenplatz)
  • Eine VM läuft vollständig isoliert und verhält sich wie ein eigenständiges System
  • Eine VM hat relativ lange Startzeiten, da erst das OS, Startprozesse und dann die Anwendungen gestartet werden müssen
  • Das OS und die Anwendungen in einer VM müssen 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 aufwändig zwischen Wirt und Gast-VMs synchronisiert werden (Ineffizienter als Container: kostet CPU-Zeit)
Vorteile:
  • Eine VM bietet ein starke Isolation gegenüber dem Host-System (stärker als Container)
  • Man kann sein gesamtes Wissen über ein OS mitnehmen und nahtlos in die VM-Welt übertragen
  • Kann sich nahtlos in das lokale Netzwerk ohne Einschränkungen einfügen
Nachteile:
  • Lange Startzeit
  • Ressourcenverschwendung im Vergleich zum Container (RAM, CPU-Zeit und Plattenplatz)
  • Die Daten für Anwendungen können quer über die VM verteilt sein
  • Werden mehrere Anwendungen in einer VM installiert, so sind diese im Gegensatz zu Containern nicht gegeneinander isoliert

Bei einem Container wird lediglich eine Anwendung virtualisiert:
  • Ein Container wird über Linux-Boardmittel isoliert, ist aber kein eigenständiges System - es ist "nur" ein Isolierter Prozess
  • Ein Container der im priviliged Mode gestartet wird, hat nur schwache Isolation - ist dabei aber nicht unsicherer als den Prozess direkt auf dem Host zu starten.
  • Ein Container verwendet den Kernel des Wirtssystems
  • 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 gewohntem Umfeld für die Kernanwendung notwendige Abhängigkeiten bereitzustellen, ist aber kein vollständiges OS - es wird nicht gebootet und es werden keine OS-Startskripte gestartet
  • Ein Container wird nicht gepatched (technisch möglich, aber sinnfrei) - stattdessen sollt man eher ein neues Image mit den Patches bauen, bzw. herunterladen
  • 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 Mehrverbrauch 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
  • Nicht alles lässt sich sinnvoll in Containern betreiben
  • Per Default ist ein Container nicht in das lokale Netzwerk eingebunden, sondern benötigt Port-Mapping zwischen Host und Container. Kann über macvlan/ipvlan in das lokale Netzwerk eingebunden werden, unterliegt dann aber der Kernel-Einschränkung, dass das macvlan/ipvlan Interface im Container nicht direkt mit der Host-IP kommunizieren darf
Solange nur eine Anwendung betrieben werden soll, die keine besonderen Anforderungen an die Netzwerk-Konfiguration stellt (bspw. Multicast Nachrichten, Multiple-Interfaces), wilde Kernel-Tweaks benötigt, oder spezielle Hardware benötigt, würde ich immer einen ressourcensparenden Container verwenden. Wobei Hardware mittlerweile durch --device auch direkt an den Container durchgereicht werden kann. Wenn man natürlich eine Windows-Anwendung oder ein besondere Unix/Linux Variante einsetzen möchte die es nicht als Basis-Image gibt, führt kein Weg an einer VM vorbei!

Auf Windows Server bzw. Docker Desktop for Windows können natürlich auch Windows Container betrieben werden - allerdings nur Backend-Anwendungen, Windows Anwendungen mit UI sind nicht lauffähig. Ein Mischbetrieb von Windows- und Linux-Container ist dabei nicht möglich. Windows-Container können nur auf Windows-Systemen betrieben werden.
 
Zuletzt bearbeitet:

rednag

Well-known member
Ich bin für Docker zu blöd. Ich mag VMs immer noch irgendwie am liebsten. Samt den Nachteilen.
Aber eine super Gegenüberstellung. (y)
 
Ich musste vor drei oder vier Jahren mal eine Gegenüberstellung für Verteilung, Konfiguration und Betrieb von VM-Lösungen und Container ausarbeiten. Das ist die konzentrierte Essenz von dem was hängen geblieben ist 🤓

Ich hab ja die Hoffnung, dass es den Einen oder Andern motiviert sich hier doch noch mit Containern auseinanderzusetzen und die Probleme entlang der "Erschließung" hier im Forum zu posten :)
 

rednag

Well-known member
Auch ich schiele hin und wieder zu Containern.
So ein kleiner LibreNMS,- oder was weiß ich Container hat schon was. Aber als ich mir das mal (sehr oberflächlich) angeguckt habe konnte man das Ding keinem vLAN zuweisen. Mag sich zwischenzeitlich geändert haben, weiß ich nicht. Trotz schöner GUI wie Portainer etc. ist das meines Erachtens nichts für die breite Masse. Container kann man sich beliebig zusammenklicken, aber wehe es geht was nicht.
 
Aber als ich mir das mal (sehr oberflächlich) angeguckt habe konnte man das Ding keinem vLAN zuweisen. Mag sich zwischenzeitlich geändert haben, weiß ich nicht.
Das geht durch Verwendung eines Docker ipvlan Netzwerks, bei dem das Parent-Interface die VLAN Konfiguration "mitbringt". Das trifft man tatsächlich so gut wie nie an :)

Trotz schöner GUI wie Portainer etc. ist das meines Erachtens nichts für die breite Masse. Container kann man sich beliebig zusammenklicken, aber wehe es geht was nicht.
Wie heisst es so schön "a fool with a tool, is still a fool". Einfach zusammenklicken und "Walkthrough Tutorials" nachklicken hilft nicht sonderlich Verständnis aufzubauen. Da macht Docker keine Ausnahme.

Im Grunde ist Docker nicht schwer. Wenn man einmal den Blick für "wann befinde ich mich in welchem Kontext" heraus hat und klar unterscheiden kann welcher Teil der Konfiguration die Host-Seite repräsentiert, welcher die Container-Seite, dann wird es einfacher. Ich bin schon seit Jahren im offiziellen Docker Forum aktiv und bin dort einer von den dort "Leader"-geflaggten Benutzern. Jeden Tag fangen Leute bei Null an - die Anzahl der neuen Nutzer, die keine Doku lesen kann (oder möchte) oder die Forums-Suche verwenden kann (oder möchte) nimmt täglich zu - es gibt nichts was die Leute nicht fragen und die kreativsten Vorstellungen wie Docker nutzbar wäre oder was es alles leisten können sollte. Container-Technologien sind gekommen um zu bleiben....

Kannst ja mal ein paar Image aussuchen, versuchen die als Container zum Laufen zu kriegen, teilen was Du gemacht hast (exakten Docker-Befehle bzw. compose file), dann kann ich versuchen zu Unterstützen es gerade zu biegen. Ich helfe gerne denen, die sich damit selbst auseinandersetzen.
 

frosch2

Active member
Was mir immer wieder an VM- und Dockerlösungen fehlt, ist ein Backup dieser.
Ich mag Anwendungen, die auf dem System selbst laufen.
 

blurrrr

Well-known member
Was mir immer wieder an VM- und Dockerlösungen fehlt, ist ein Backup dieser.
Bei so ziemlich jeder Virtualisierungslösung gibt es ein Backup (die NAS-Dinger mal aussen vor gelassen und KVM ist so eine Sache für sich, geht aber auch). Bei Docker einfach Volume/Verzeichnis sichern? Davon ab, gibt es i.d.R. auch immer die Möglichkeiten Dinge von innen heraus zu sichern :)
 

frosch2

Active member
Nun mal konkret, ich habe eine Linuxinstallation.
Auf dieser laufen 2 Docker-Container und eine VM.
Jetzt platzt mir meine Festplatte, baue eine neue ein und nun?
Alles wieder installieren und dann Container und VMs restaurieren?
Nein Danke.
 

blurrrr

Well-known member
Volumes der Container und VM wieder aus dem Backup einspielen? Muss man bei Nutzdaten aus einem Backup irgendwie auch... also seh ich das Problem da ehrlich gesagt nicht so ganz 🙃

EDIT: Das ist vllt erklärungsbedürftig...
Muss man bei Nutzdaten aus einem Backup irgendwie auch...
Wenn der Rechner/Server die Biege macht, kann man auf ein neues nacktes Gerät auch keine reinen Nutzdaten aufspielen, man braucht zumindestens wieder ein OS + ggf. noch extra Software.
 

blurrrr

Well-known member
Kann man sehen wie man mag... Ich sichere von meinen Hypervisorn lediglich die Config und die VMs (und Container bisher nur sehr eingeschränkt, da diese hier noch nicht wirklich ernsthaft zum Einsatz kommen).
 
Bei Containern würde ich für die Volumes in der Frequenz deines RPO-Bedürfnisses Backups anlegen.

Meine Deployment-Skripte erlauben mir alle meine Container (sind um die 50) zu stoppen und auch einfach wieder über meinen Cluster verteilt zu starten.

Dann kommt ein Skript zum Einsatz, dass in einer Schleife alle Volumes sichert, in dem es je Volume einen Container erzeugt der das Volume + ein Backup-Verzeichnis mounted, dann tar ich den Kram innerhalb des Containers und sicher mir das tar Archive auf mein NAS rüber.

Ich verwende keine Volume-Binds (~=host Verzeichnis in Container mounten) zum persistieren der Daten, da ich meine Container im Cluster betreibe und jeder Node an die Daten rankommen muss. Meine Volumes sind mit Portworx-Developer inkl. Replikaten verstreut über meine 3 Cluster Nodes.

Zum Wiederherstellen habe ich dann ein entsprechendes Skript, dass die Daten wieder in die Volume einspielen kann. Die RTO mag deutlich höher liegen als bei einem Baremetal-Recovery - insbesondere wenn man das "dadrunter" nicht automatisiert hat - oder keinen Cluster nutzt.
 
Zuletzt bearbeitet:

frosch2

Active member
Ich habe nicht die Hälfte von dem verstanden, was du schreibst.
Denkst du bitte dran, dass hier Leute unterwegs sind, die ein Heimnetzwerk haben aber keine ITler sind!
Eine einfache Lösung von Backups der Container erschließt sich mir nicht.
Ich bin immer noch der Meinung, dass Anwendungen aufs "Blech" gehören, wenn es nicht gerade Cloud-Gedöns ist.
 
Ich habe nicht die Hälfte von dem verstanden, was du schreibst.
Och alles gut. Mich muss man manchmal bremsen.

RPO=Recovery Point Objective = Datenverlust-Intervall das Du in Kauf nehmen möchtest. Manch einer kann eine Stunde kaum akzeptieren, andere kommen mit einem Tag oder länger zurecht.
RTO=Recovery Time Objective = Wiederherstellungszeit nach ein Ausfall.

Im Einfachsten Fall stoppt man seine Container, sichert die Datenverzeichnisse und startet danach die Container wieder. Wenn man ein vollständiges, konsistentes Backup haben will, ist das immer noch der sauberste Weg.

Ich bin immer noch der Meinung, dass Anwendungen aufs "Blech" gehören, wenn es nicht gerade Cloud-Gedöns ist.
Da Erfahrung und Wissenstand bei allen unterschiedlich sind, kann ich verstehen wenn man sich ausschließlich für "Blech", oder ausschließlich für VMs, oder ausschließlich für Container, oder einem Mischbetrieb aus mehreren Varianten entscheidet.

Ich habe berufliche lange nichts mehr erlebt, wo auf Blech etwas anderes als ein Hypervisor betrieben wird, außer es ist bereits eine spezialisierte Appliance. Ich habe selbst Behörden erlebt, die die Endbenutzergeräte (Deskop PC/Laptops) mit geschlossenem Hypervisor ausstatten und den Mitarbeitern erlauben nur in vorgefertigten VM's zu arbeiten.
 
Ich will zuhause auf so wenig Blech, so viel wie möglich, so ressourcenschonend und flexibel wie möglich mit möglichst wenig manuellem Wartungsaufwand betreiben.

Wenn ich jeweils direkt auf dem Blech betreiben würde, bräuchte ich relativ viel Blech oder hätte viele Services/Anwendungen auf den jeweiligen Maschinen. Was ist, wenn ich Services/Anwendung habe deren Dependencies verhindern das sie auf einem OS laufen - oder es Services/Anwendungen für mein OS der Wahl nicht gibt?

Hier bietet es sich dann schon an auf dem Blech Hypervisior zu betreiben. Damit reduziert sich zumindest schon mal die Anzahl der Bleche und je Service Gruppe können so VM's verwendet werden - notfalls auch mit einer zusätzliche VM mit einem bestimmten OS in einer bestimmten Version. Aber auch hier hätte ich immer noch erhebliche Wartungsaufwand und keine wirkliche Abgrenzung der Services gegeneinander.

Daher betreibe ich hauptsächlich nur noch Container Runtimes in wenigen VMs und betreibe tatsächlich nahezu alles in Containern. Ich persönlich stecke lieber Zeit um eine reproduzierbare Automatisierung zu erarbeiten, als jedes Mal Dinge händisch neu zu Installieren, oder schlimmer noch in einer UI zusammenzuklicken - das will auch alles Dokumentiert werden und veraltete Dokumentation will gepflegt werden. Ob nun händisch oder automatisiert: beide Lösungen haben einen Fleißanteil wenn man es richtig macht.

Wir haben halt alle unterschiedliche Vorstellungen von dem wie wir "schöner Wohnen" in unseren Umgebungen ausgestalten.
 
Zuletzt bearbeitet:

azrael783

Active member
Eine einfache Lösung von Backups der Container erschließt sich mir nicht.
Eine Einfach Lösung wäre zb: Du "verlinkst" einen Ordner auf deinem Host (=da wo der Container läuft) in den Container. Somit landen alle für den Container relevanten Daten auf deinem Host. Von hier kannst die diese Daten wo auch immer du willst insichern, per RTRR / Rsync auf ein NAS, per git auf einen Server (Github, zb), oder per Shell Skript auf eine USB Festeplatte, etc pp.
Ich nutze auch wesentlich lieber Container, als die Anwendung direkt auf der Maschine / dem Blech zu installieren. Hauptgrund für mich: sehr einfaches zurückspringen auf eine ältere Version der Anwendung ohne Datenverlust. Und ja, das habe ich in der Tat schon häufiger angewendet.
Wie @Confluencer bereits geschrieben hat: Einfach hier einen neue Thread aufmachen und das Problem so genau wie möglich beschreiben. Ich bin zwar nicht im offiziellen Docker Forum unterwegs und auch kein "Poweruser", habe aber im Qnap Forum dem ein oder anderen beim Thema Docker schon weiterhelfen können. ;)
 

phoneo

New member
Ich nutze gerne Container, um mir mal schnell und unkompliziert eine Anwendung anschauen zu können. Und da liegt für mich persönlich auch der größte Vorteil: Die vereinfachte Bereitstellung von Anwendungen ohne viel Zeit investieren zu müssen. Mehr mit Containern anfangen zu können fände ich zwar auch reizvoll, scheue bisher aber den Zeitinvest.

Was ich noch nicht verstehe:

Ein Container wird nicht gepatched (technisch möglich, aber sinnfrei) - stattdessen sollt man eher ein neues Image mit den Patches bauen, bzw. herunterladen

Warum ist das Patchen eines Containers sinnfrei wenn es technisch möglich ist?

Wäre es nicht sinnfreier, wenn sich jeder selber für einen Patch einen Container bauen würde/müsste? Liegt nicht gerade darin auch ein Vorteil, dass es einige Profis gibt, die eine Auswahl an Containern der Gemeinschaft zur Verfügung stellen und deshalb nicht jeder Nutzer zum Docker-Experte werden muss?
 
Ich ahne hier ein Wording Problem. Deine Antwort verwendet zwar den Begriff Container, meint damit aber an einigen Stellen eigentlich Images.

Image = Paketiert die Anwendung/den Service, Abhängigkeiten, Konfigurationen und hat idealerweise clevere Entrypoint-Skripte. Das ist das was Du von Dockerhub ziehst.
Container = wegwerf Laufzeit-Instanz erzeugt auf Basis einer exakten Image Version (Repo@sha256:checksum, siehe weiter unten).

Profis arbeiten mit Dockerfiles als Blaupause mit den Anweisungen wie das Image zu erstellen ist. Wenn sie nur vom aktualisierten Base-Image profitieren wollen (Bspw. weil es ein neues Ubuntu oder Alpine Image gibt), dann bauen sie ihr Image ohne Anpassungen am Dockerfile neu. Andere Änderungen können durch Anpassung des Dockerfiles erreicht werden. Aber auch hier gilt: neu bauen, zu Dockerhub pushen und so mit der Welt teilen.

Bei Dockerhub gibt es viele "mutable" Tags, die zwar einen stabilen Tag haben, aber bei jeder Aktualisierung auf ein anderes Image zeigen. Wenn man einen Container hat der von einem latest Tag erzeugt wurde, nun aber den Container auf Basis des neuen Images haben will, dann muss man das neue Image pullen, den alten Container löschen und einen neuen mit exakt denselben Parametern wie den alten anlegen. Solange man Volume-Mappings für die Dauerhaft zu speichernden Daten korrekt gesetzt hat, sollte es hier auch nicht zu Datenverlusten kommen, Ansonsten profitiert man nicht vom neuen Image. Spätestens mit dem löchen des Container wären alle Änderungen die nach dem Image durchgeführt wären weg.

Einen Container direkt zu patchen ist sinnfrei, weil es wirklich nur als Wegwerf-Instanz gedacht ist. Das ist direkt vergleichbar damit, als wenn man VM's immer nur durch wegwerfen und neu erzeugen aus einem Template aktualieseren könnte (bei Cloud-Betrieb ist das tatsächlich für Compute-Instanzen in Autoscaling-Groups tatsächlich nicht mal unüblich).

Anmerkung: meiner Meinung nach hat Docker den Begriff Image auch ziemlich schwammig verwendet... Manchmal ist mit Image ein Repo:Tag gemeint, manchmal ein Repo@sha256:checksum gemeint. Repo wiederum, ist je nachdem ob es ein Repo bei Dockerhub ist oder wo anders, ohne oder mit Domainnamen.

Wenn man mal DNS zur Analogie heranziehen würde, dann wäre Repo:Tag vergleich mit dem Domainnamen und Repo@sha256:checksum vergleichbar mit der IP.
 
Zuletzt bearbeitet:

Zurzeit aktive Besucher

Letzte Anleitungen

Statistik des Forums

Themen
586
Beiträge
8.664
Mitglieder
204
Neuestes Mitglied
sina27
Oben