Unterschied VMs / Container bzw. Virtuelle Umgebungen

vablo

Cadet 3rd Year
Registriert
Feb. 2020
Beiträge
57
Ich habe ein Verständnisproblem und hoffe, mir kann jemand helfen.

Was eine virtuelle Maschine ist und wie diese funktioniert ist mir klar. Erfahrungen mit Hyper V und Virtualbox habe ich auch. Mit Containern habe ich jedoch noch keine Erfahrung. Beim Versuch zu verstehen, worum es sich hierbei handelt stoße ich ständig auf Vergleiche mit virtuellen Maschinen. Es heißt jedoch, dass es sich bei Containern mehr um "virtuelle Umgebungen handelt".

Ich bin verwirrt...
 
nuja, eine VM schleppt einiges mit sich rum, schließlich will ein kompletter computer emuliert werden.
das is viel overhead.

und containern wird eben der overhead kräftigst reduziert, weil sich die vieles teilen.
der preis dafür ist der grad der isolation.
 
  • Gefällt mir
Reaktionen: Nilson und tony_mont4n4
Eine VM ist ein virtueller Computer. Das heißt in jeder VM läuft ein eigene Betriebssystem. Wenn du also z.B. zwei Webserver oder zwei Teamspeak-Server laufen lassen willst, müsstest du jedes mal eine eigene VM mit eigenem Betriebssystem aufsetzten, was jedes mal, je nach OS, einige GB RAM und Festplatte verwendet.
Container wie z.B. Docker setzen daher eine Ebene höher an in dem sie nur die Anwendungen von einander trennen, aber weiterhin das gleiche Betriebssystem nutzen. Daher sind sie viel Ressourcensparender als gleich ne neue VM auf zu setzen.
 
  • Gefällt mir
Reaktionen: tony_mont4n4 und whats4
vablo schrieb:
Es heißt jedoch, dass es sich bei Containern mehr um "virtuelle Umgebungen handelt".
Während bei virtuellen Maschinen typischerweise quasi die ganze Hardware nachgebildet wird um dann auch zum Beispiel komplette Betriebssysteme auszuführen (für die ausgeführten Gastsysteme sieht es halt alles so aus als wären sie alleine auf einer physischen Maschine) geht es bei Containern darum nur Teilaspekte zu virtualisieren. Oft können (und sollen) innerhalb von Containern auch gar keine vollständigen Betriebssysteme ablaufen.

Ein altes und bekanntes Containerkonzept ist zum Beispiel chroot. Hierbei wird eigentlich nichts weiter gemacht, als allen Prozessen die darin laufen eine eigene Sicht aufs Dateisystem zu geben. Vergleichbar mit Virtualisierung "denken" dann die Prozesse, sie "sehen" das gesamte Dateisystem. Dabei sehen sie nur einen Teil. Den Du bestimmst und den Du vorher befüllt hast wie es für den "eingesperrten" Prozess passend ist.

Vorteil davon: Du sparst jede Menge Overhead weil Du halt nicht eine komplette Maschine nachbauen musst. Es läuft auch kein weiterer Kernel oder so. Du kannst also relativ problemlos vorhandene Infrastruktur (Netzwerkverbindungen etc.) mitbenutzen.

Moderne Containerkonzepte machen natürlich mehr. Da ist es nicht darauf beschränkt den Zugriff auf Verzeichnisse neu zu organisieren, sondern fassen noch wesentlich mehr zusammen. Zum Beispiel eine Containereigene Prozessliste so das die Prozesse im Container nur andere Prozesse des Containers sehen können aber nicht welche diue draußen sind. Oder auch virtuelle Netzschnittstellen, womit Du dann Deiner "chroot"-Umgebung z.B: ne eigene IP-Adresse geben kannst und solche Geschichten.

Vorteil von Containergeschichten ist, das sie relativ leichtgewichtig sind. Du kannst einzelne Prozesse isolieren und brauchst nicht gleich ein ganzes Betriebssystem mitzuschleppen. Gibt natürlich auch Nachteile. Manchmal will man ja gezielt andere Systeme ausführen. Zum Beispiel unter Linux eine Windows-VM haben um Windows-Programme auf seiner Linux-Büchse auszuführen und sowas.
Solche Szenarien lassen sich mit Containern meist weniger gut oder gar nicht darstellen.

Somit kommt es immer auf den konkreten Fall an, wozu man dann greift.
 
  • Gefällt mir
Reaktionen: ###Zaunpfahl### und whats4
24 Seiten "Grundlagen von Virtualisierungstechnik und Cloud Computing" : uni passau (via veröffentlichungsliste)
Hat verschiedene Definitionen und Skizzen von VMs und Containern.
 
  • Gefällt mir
Reaktionen: Nilson und whats4
Ich möchte hier noch ne kleine noob Sicht geben ist evtl. nicht ganz korrekt aber vielleicht für den ein oder anderen (mich :D) verständlicher.

Also das erste und ganz wichtig dabei ist, dass das eher aus der Linux Welt kommt.
Grob gesagt braucht man für Linux nur den Linux Kernel und dann noch ein paar Programme drum herum. Das sind dann aber CLI (Command Line Interface) Programme (also nichts grafisches wie man es nur zuoft von Windows kennt). Nun gibt es eine sogenannte Docker Datei. Dort Steht drin wie der Container gebaut werden soll also welche Programme (cli) installiert werden sollen und wie diese konfiguriert werden sollen. Mittels dem Docker cli programm führt man dann diese Docker Datei aus. Dadurch wird dann ein Container in einer speziellen Umgebung erstellt (man kann natürlich auch 23534 mal den gleichen Contairer erstellen, wer will). So ein Container hat dann auch sein eigenes Netzwerk Interface (ip) worüber man dann interagieren kann.

Beispiel: Wordpress mit MariaDB und Apache (Best practice ist aber eigentlich das jedes Programm seinen eigenen Container hat, hier also 3).

Wofür das ganze? Als Programmierer ist es zum Beispiel Super um auf verschiedenen Linux Distributionen die gleiche Umgebung zu haben mit den gleichen Einstellungen. Anstatt dann überall Wordpress, Mysql, Apache installieren und konfigurieren zu müssen startet man einfach den Container (10s) und es läuft überall gleich. (Das erste starten, eher bauen, des Containers kann aber durchaus einige Minuten dauern)

Es gibt natürlich nicht nur Docker sondern auch andere. Mittlerweile ist das aber auch schon spezifiziert so das sich die an Standards halten...
 
Zuletzt bearbeitet: (besser MariaDB promoten ^^)
Wie schaut es eigentlich mit der Sicherheit aus bei diesen Lösungen?
Kann ein Container auf einen anderen Container zugreifen?
Kann eine VM auf eine andere zugreifen?
Ist es ausgeschlossen, dass solche Zugriffe funktionieren?
 
Also ich kann da jetzt auch nur nachplappern.
https://duckduckgo.com/?t=ffab&q=security+container+vs+vm&ia=web

Aber was ich definitiv sagen kann. Bei Containern ist es oft ausdrücklich erwünscht das die Container miteinander kommunizieren. Ich denke Standardmäßig übers Netzwerkprotokoll.
Man kann aber auch volumes mappen, das bedeutet ein Ordner im Container spiegelt dem im Host System wieder und umgekehrt...
Damit man dann viele "schiffe" (Gruppen) Container administrieren kann wurde dann sowas wie https://de.wikipedia.org/wiki/Kubernetes entwickelt.

Wer sich wirklich dafür interessiert am besten einfach selber ausprobieren!

Docker Tutorial Deutsch - heise online​

https://invidious.tube/playlist?list=PLTiAR9GPzmX1ehCBiTs9j4oYB5jUZNV1V

Damit hab ichs letztens dann auch erst richtig geblickt
 
vablo schrieb:
Wie schaut es eigentlich mit der Sicherheit aus bei diesen Lösungen?
Ja. Ist ein schwieriges Thema, welches man nur mit einem konkreten "Kommt drauf an" beantworten kann. :-)

Bei virtuellen Maschinen, wo von vornherein schon die Grundidee ist das das Gastsystem annehmen soll es läuft auf einem eigenen Computer ist natürlich auch der Grad der Isolation recht groß. Es ist also erst mal nicht vorgesehen das der Gast auf irgendwas außerhalb der VM zugreifen darf oder sogar nur davon was sehen soll.

In der Praxis ergeben sich dann aber trotzdem Probleme. Erstens weil die eigentliche Software (der HyperVisor usw.) relativ komplex sind. Das bedeutet leider auch, das da dann auch gern mal Bugs auftauchen. Auch Bugs die den Ausbruch aus der VM ermöglichen.

Das zweite Ding ist, das Du VMs ja gar nicht unbedingt so isoliert haben willst. Du willst ja zum Beispiel mit ihr interagieren und sie soll auch Geräte benutzen können (Bildschirm, Grafikkarte), man gibt Zugriff auf Datenträger frei für den Datenaustausch usw. Das bohrt natürlich auch alles Löcher in die Isolation.

Bei den Container-Lösungen ist das noch mal ne ganz andere Hausnummer. Weil da das das "Gastsystem" Zugriff auf das Hostsystem hat ein Teil des Konzeptes ist. Auf der anderen Seite ist die Software die hinter Containerlösungen steckt auch einfacher und hat damit potentiell weniger Fehler.

Ansonsten kommt es halt drauf an. Das schon genannte Beispiel Docker sieht zwar Isolation vor, allerdings war das dort nie als Sicherheitsfeature gedacht. Docker ist in erster Linie ein Deployment-Technologie. Das heißt, Du packst da Dein Programm plus seine Abhängigkeiten (Bibliotheken etc.) rein und verteilst halt dann den Container und kannst den auch munter durch die Gegend (also auch auf andere Maschinen) schieben (was nützlich ist, wenn Deine Hardware mal kaputt geht; ähnlicher Effekt wie bei Vollvirtualisierung).
Zwar bieten Docker-Container eine gewisse Ausbruchssicherheit die auch ausgebaut wird (weil halt zunehmend die Anforderung besteht), aber wie gesagt. Ursprünglich gedacht was dafür nicht.

Gibt aber auch andere Beispiele. Bei FreeBSD hast Du für Container-Like-Virtualisierung Jails. Hier hast Du zwar auch so die Virtualisierung auf Dateisystemebene usw. (was halt so typisch für Containerlösungen ist), aber die haben auch Security als integralen Bestandteil. Die haben halt von Anfang an darauf geachtet, das man die Beschränkungen nicht umgehen kann. Die ist initial auch viel restriktiver. Da ist eher der Ansatz:
"Wenn Du was brauchst, musst Du es explizit freischalten" und nicht "Was Du nicht brauchst, musst Du explizit sperren".

vablo schrieb:
Kann ein Container auf einen anderen Container zugreifen?
Ist letztlich Einstellungssache.

vablo schrieb:
Kann eine VM auf eine andere zugreifen?
Auch das ist Einstellungssache. Wobei es hier ein bisschen Schwieriger ist. Lösungen a-la Docker sind auch explizit dafür gedacht, das Container zusammenarbeiten. Dementsprechend ist es dort natürlich einfacher die Isolation aufzuheben. Im Guten wie im Schlechten.

vablo schrieb:
Ist es ausgeschlossen, dass solche Zugriffe funktionieren?
Das riecht so arg nach 100%iger Sicherheit. An der Stelle lacht der typische ITler, dreht sich um und holt sich nen Kaffee. :-)
 
Zurück
Oben