Virtualisierung mit Docker

Virtualisierung vs. Container

LinkedIn Learning kostenlos und unverbindlich testen!

Jetzt testen Alle Abonnements anzeigen
Docker nutzt zur Virtualisierung nicht die Hypervisor-Technologie, sondern setzt auf Container. Lernen Sie die fundamentalen Unterschiede zwischen den beiden Möglichkeiten kennen.

Transkript

Im Zusammenhang mit Docker fällt der Begriff Virtualisierung des Öfteren. Auch wenn Docker eine Form von Virtualisierung ist, hängt sie nicht zwangsläufig mit klassischen Arten der Virtualisierung zusammen. Wie Sie genau diesen Trugschluss entgehen können, zeige ich Ihnen in den folgenden Minuten. Als Erstes möchte ich mit den typischen Arten von Hypervisorn, wie sie heute existieren, beginnen. Man unterscheidet grundsätzlich erstmal in einen so genannten Typ-1-Hypervisor. Der Typ-1-Hypervisor zeichnet sich durch die höchst mögliche Effizienz zwischen Hardware und Hypervisor an sich aus. In diesem Fall ist also der Hypervisor direkt mit der Hardware verknüpft. Und es gibt im Regelfall kein Host-Betriebssystem bzw. ein absolut minimales Host-Betriebssystem. Ansonsten werden in den virtuellen Maschinen jeweils die Betriebssysteme unabhängig von der Plattform, also sowohl Linux als auch Windows, bereitgestellt. Diese Betriebssysteme funktionieren dann, wie gewöhnt mit den jeweiligen Abhängigkeiten also den Bibliotheken und den jeweiligen installieren Anwendungen. Beispiel für einen solchen Typ-1-Hipervisor ist zum Beispiel Hyper-V oder VMware ESXi. Die zweite Art von Hypervisor die weniger effizient ist, aber man oft in Falle von Workstations oder Entwicklern-Rechnern findet, ist der so genannte Typ-2-Hypervisor. Der Typ-2-Hypervisor zeichnet sich dadurch aus, dass zwischen Hardware und Hypervisor selbst noch das Betriebssystem steht. Also beispielsweise eine Installation von Linux oder Windows. Bis auf wenige Performance-Aspekte und geringe Sicherheitsprinzipien sind die Funktionalitäten für das jeweilige Betriebssysteme in der virtuellen Maschine weitestgehend gleich. Die bekanntesten Beispiele für einen Typ-2-Hypervisor sind Oracle VirtualBox oder auch VMware Workstation. Bei Docker sprechen wir jetzt allerdings von Betriebssystemvirtualisierung. Das heißt, das Betriebssystem sorgt dafür, dass etwas virtualisiert wird. Der offensichtliche Kontrast ist hier also, dass das Betriebssystem, wie regulär üblich mit der Hardware spricht und dass es keinen Hypervisor gibt. Lediglich das Betriebssystem sorgt dafür, dass die Anwendungen hier in den Containern virtualisiert werden. An der Stelle lassen sie sich noch zwei Arten von Container- Virtualisierung unterscheiden. Die Art von Virtualisierung bei der Anwendungen in Containern laufen und die ursprünglichen Bibliotheken des jeweiligen Betriebssystems nutzen. Oder die bei Docker übliche Art von Virtualisierung, bei der der Container selbst die Komponenten eines Betriebssystems beinhaltet. Das ermöglicht es also, dass beispielsweise auf dem Betriebssystem Red Hat Enterprise Linux installiert ist und im Container selber dann die Bibliotheken der Ubuntu- Installation zur Verfügung stehen und die Anwendung dann auch entsprechend die Ubuntu-Komponenten nutzen kann. Ich möchte nun also noch einmal etwas tiefgründiger auf diese Form von Betriebssystemvirtualisierung eingehen. Dem Ganzen zugrunde liegt also kein Hypervisor, sondern das so genannte Sanbox-Prinzip. Sandboxen kennt man herkömmlich vor allem aus dem Bereich Antiviren-Software oder auch Anwendungssandboxing, wie Sandboxies auf Windows möglich macht. Die Grundidee ist also eine Anwendung auf dem Betriebssystem regulär auszuführen, aber eine Umgebung für diese Anwendung zu simulieren. Das Problem das also zugrunde liegt ist, man hat Anwendungen, die viele Abhängigkeiten zu diversen Betriebssystemkomponenten und Funktionalitäten haben, aber man hat auf der anderen Seite das Problem, dass diese Anwendungen schädliche Änderungen am jeweilige Betriebssystem vornehmen könnten. Im Normalfall simuliert man nun also das Betriebssystem und die jeweilige zur Verfügung stehenden Komponenten für diese Anwendung, speichert aber alle Änderungen, die diese Anwendung am System vornehmen würde in separate Einheiten, die am Ende des Tages nur für die Anwendung selbst sichtbar sind. Und so werden auch die Möglichkeiten, die die Anwendung selbst hat mit anderen Prozessen und dergleichen zu interagieren dementsprechend eingeschränkt. Die Umsetzung dieser Funktionalität muss prinzipiell immer im Kernel des Systems stattfinden, weil es unter anderen Umständen sehr schwierig ist zu garantieren, dass es keine Schlupflöcher gibt, die tatsächlich wieder auf die Ursprungsfunktionalität des Betriebssystems zurückgreifen kann und dementsprechend dann Änderungen am System vornimmt. Letztendlich ist der Kernel die höchste Stufe der Hierarchie, das heißt, alles was am Ende des Tages von einer Anwendung gemacht wird, spricht mit dem Kernel des Systems. Zum Beispiel eben eine Änderung an Dateisystem wird vom Kernel des Systems als letzte Einheit vor der Hardware terminiert. Im Falle von Docker hat man also nun eine Linux-Installation. Auf dieser Linux-Installation findet man nun diverse Standardprozesse, die zur jeweilige Linux-Installation selbst dazu gehören, vor. Genau diese Linux-Installation startet nun einen Prozess zum Beispiel eine Shell, wie die Kommandozeile Bash und vergeht hier für eine reguläre Prozessnummer, wie beispielsweise hier 65321. Das heißt aus Sicht des Host-Betriebssystems hat der Prozess diese Bash-Shell also nun eine reguläre Prozessnummer. Durch diesen geschlossenen Kasten allerdings simuliert handelt es sich hierbei um eine geschlossene Umgebung die durch die jeweiligen Kernel-Features auf Ubuntu umgestellt ist. Es stehen also alle für Ubuntu üblichen Bibliotheken und kleinst Anwendungen, wie beispielsweise der Repository Manager Apt Get innerhalb dieser Bash nun zu Verfügung. Führe ich nun an dieser Stelle eine andere Anwendung von dieser Bash aus aus, so bekommt diese Anwendung eine Prozessnummer sowohl auf dem Host-Betriebssystem, eine reguläre, als auch eine neue Prozessnummer, die nur innerhalb dieses Bereiches gilt. Wenn ich mir also an der Stelle eine Prozessliste von der Bash aus anzeigen lassen würde, würde ich entsprechend auch nur den jeweiligen gestarteten Prozess sehen, der auch eine sehr niedrige Nummer aus Sicht dieser Bash bekommen hat. Insofern die Mechanismen natürlich nicht garantieren können, dass der Prozess aus diesem Gefängnis ausbrechen kann, besteht grundsätzlich Kompromittierungsgefahr des jeweiligen Host-Betriebssystems. Da aber viele der zugrunde liegenden Features schon jahrelang im Einsatz sind und dementsprechend getestet worden, kann grundsätzlich angenommen werden, dass das so in der Form nicht unmittelbar vorkommen wird. Nach diesem Video wissen Sie nun also, wie Sie zwischen herkömmliche Virtualisierung und Betriebssystemvirtualisierung bzw. Anwendungsvirtualisierung unterscheiden können.

Virtualisierung mit Docker

Steigen Sie in die Container-Virtualisierung ein und entdecken Sie einfaches Prototyping neuer und unkomplizierte Skalierung bestehender Anwendungen.

3 Std. 36 min (36 Videos)
Derzeit sind keine Feedbacks vorhanden...

Dieser Online-Kurs ist als Download und als Streaming-Video verfügbar. Die gute Nachricht: Sie müssen sich nicht entscheiden - sobald Sie das Training erwerben, erhalten Sie Zugang zu beiden Optionen!

Der Download ermöglicht Ihnen die Offline-Nutzung des Trainings und bietet die Vorteile einer benutzerfreundlichen Abspielumgebung. Wenn Sie an verschiedenen Computern arbeiten, oder nicht den ganzen Kurs auf einmal herunterladen möchten, loggen Sie sich auf dieser Seite ein, um alle Videos des Trainings als Streaming-Video anzusehen.

Wir hoffen, dass Sie viel Freude und Erfolg mit diesem Video-Training haben werden. Falls Sie irgendwelche Fragen haben, zögern Sie nicht uns zu kontaktieren!