Vertiefung in Windows Server Containers und Docker - Teil 3 - Grundlegende Implementierung von Hyper-V Containern

Im vergangenen April besuchte ich die DockerCon 2017 und während sie viele neue großartige Dinge wie das LinuxKit und das Moby-Projekt ankündigten, war eine der ansprechendsten Ankündigungen für mich definitiv die Ankündigung von John Gossman, dass Microsoft und Docker es möglich machen, Linux-Container nativ auf Windows-Hosts auszuführen, indem sie die gleiche Hyper-V-Isolierungsschicht wie Hyper-V-Container verwenden. Zeit also für mich, einen Blogpost über Hyper-V Container zu verfassen und zu erklären, wie diese Hyper-V Container-Virtualisierungsschicht funktioniert.

Im letzten Blogpost dieser Serie haben wir den Unterschied zwischen Containern und VMs und sogar zwischen Windows- und Linux-Containern kennengelernt. Während Linux-Hosts nur eine Art von Containern unterstützen: Linux-Container, unterstützen Windows-Hosts mehrere Container-Typen wie Windows Server-Container, Hyper-V-Container und sogar Linux-Container. Lassen Sie uns in die Hyper-V Container-Technologie eintauchen.

Normale Windows Server-Container

Auch wenn normale Windows Server Container große Vorteile haben, wie z.B. sofortige Startzeiten und einen geringen Platzbedarf im Vergleich zu VMs, kann ihre Verwendung einige Risiken bergen. Insbesondere in Szenarien, in denen die Container-Hosts von mehreren Mietern genutzt werden oder im Falle von Container-Hosts, die von einem Dritten verwaltet werden. Da Windows Server Container den Kernel eines Container-Hosts gemeinsam nutzen, ist es theoretisch möglich, dass containerisierte Anwendungen auf den Container-Host zugreifen, indem sie einige Implementierungsfehler im Kernel ausnutzen. Dies mag zwar nur eine theoretische Möglichkeit sein, ist aber eine reale Bedrohung, wenn Sie an die Anzahl der entdeckten Kernel-Exploits unter Windows denken, die mehrmals pro Jahr gemeldet werden. Das Risiko in diesen Fällen besteht darin, dass ein Angreifer, der in der Lage ist, den Kernel zu kompromittieren, potenziell den Container-Host oder sogar andere Container, die auf diesem Host laufen, beeinträchtigen könnte. Nicht nur Implementierungsfehler, sondern auch das Design von Windows Server Containern kann Ihre mandantenfähige Anwendungslandschaft einem hohen Risiko aussetzen. Im vorigen Beitrag dieser Serie habe ich erwähnt, dass Container eine Isolierung von Dateisystem, Umgebungsvariablen, Registrierung und Prozessen zwischen Anwendungen gewährleisten. Diese Isolationsebene ist jedoch zwischen Windows Server Containers und dem Container-Host nicht der Fall. Obwohl die Implementierungen der Isolierung von Umgebungsvariablen und der Registrierung in etwa gleich sind (Sie sind nicht in der Lage, containerspezifische Umgebungsvariablen und Registrierungswerte vom Container-Host aus zu sehen), sind die Implementierungen des Dateisystems und der Prozessisolierung leicht unterschiedlich.

Unterschied zwischen der Isolierung von Dateisystemen zwischen Containern und Host-Containern

Änderungen am Dateisystem innerhalb laufender Container werden in einer .vhdx-Datei auf dem Container-Host gespeichert. Innerhalb eines Containers können Sie den Inhalt des Dateisystems eines anderen Containers nicht sehen, aber vom Container-Host aus können Sie diese .vhdx-Dateien auf dieselbe Weise verfolgen wie bei VMs. Um den Speicherort dieser .vhd-Datei für einen bestimmten Container zu finden, verwenden Sie den Befehl docker inspect [container_name] und sehen Sie sich das Attribut GraphDriver - Data an, wie in Abbildung 1 gezeigt. Beachten Sie den Größenunterschied zwischen einem Container und einer VM-Festplatten-Image-Datei, wie in Abbildung 2 und 3 dargestellt.

Unterschied bei der Isolierung von Prozessen zwischen Containern und Host-Containern

Auf der Ebene der Prozessisolierung ist der Unterschied noch größer. Im Gegensatz zur echten Prozessisolierung zwischen Windows Server Containern gibt es keine Prozessisolierung zwischen dem Container-Host und den Windows Server Containern, die auf dem Host ausgeführt werden. Das bedeutet, dass jeder, der Zugriff auf den Container-Host hat, laufende Prozesse von Windows Server Containern, die auf dem Host laufen, sehen und beenden kann, wie in Abbildung 4 dargestellt. Obwohl diese Implementierung die gleiche ist wie bei Linux-Containern, ist sie möglicherweise nicht für alle Situationen sicher genug.

Hyper-V Container

Aufgrund des Risikos von Implementierungsfehlern im Kernel und der Prozessisolationsebene von Windows Server Containern hat Microsoft beschlossen, einen neuen Containertyp namens Hyper-V Container einzuführen. Hyper-V-Container bieten eine sichere Lösung für Situationen, in denen Container-Hosts von verschiedenen Mandanten gemeinsam genutzt werden, und sind zu 100% mit normalen Windows Server Containern kompatibel.

Interne Implementierung

Die Isolierung von Hyper-V Containern basiert nicht auf einem Konstrukt auf Kernel-Ebene, sondern nutzt die Hyper-V Hypervisor-Technologie, um eine echte Isolierung auf Kernel-Ebene zu bieten. Unter der Haube ist ein Hyper-V Container eigentlich eine Hyper-V Utility VM, die einen einzelnen Windows Server Container hostet, um eine zusätzliche Sicherheitsgrenze zu schaffen. Jede Hyper-V Utility-VM enthält ihren eigenen Klon des Windows Server 2016-Kernels und hostet einen separaten Guest Compute Service für die Kommunikation mit der Compute Services-Abstraktion des Host User Mode.

Die Hyper-V Utility-VMs, die als Teil von Hyper-V-Containern verwendet werden, sind für die Verwendung als Container-Host optimiert und enthalten nur die Funktionen, die für die Ausführung von Containern auf dem Container benötigt werden. Um Hyper-V-Container so schnell wie möglich starten zu können, hat Microsoft eine spezielle Implementierung eines Operationssystems entwickelt, das eine sehr kurze Startzeit und einen geringen Platzbedarf hat. Sie könnten erwarten, dass Sie die Utility VMs von Hyper-V-Containern mit dem normalen Powershell-Befehl Get-VM finden. Aber das ist nicht richtig. Obwohl wir sie als Utility VM bezeichnen, weist sie einige bemerkenswerte Unterschiede zu normalen VMs auf. Sie ist beispielsweise nur eine schreibgeschützte Version einer VM, d.h. Schreibvorgänge werden nicht beibehalten. Sie muss auch keinen eigenen Hostnamen haben, da die gehosteten Container ihren eigenen Hostnamen und ihre eigene Identität haben. Um die Startzeit von Hyper-V Containern noch schneller zu machen, hat Microsoft ein Konzept zum Klonen der Utility VMs eingeführt. Die Idee hinter dieser Klontechnologie ist, dass der erste Teil des Bootvorgangs für jeden Hyper-V-Container, der gestartet werden muss, derselbe ist. Erst wenn Sie den Windows Server Container innerhalb der Utility VM starten, wird es anders. Die Klontechnologie gabelt also den VM-Status kurz bevor ein bestimmter Windows-Container in die Utility-VM gesetzt wird. Wenn Sie einen neuen Hyper-V-Container in einem neuen Host starten, wird eine VM gebootet und der genaue Punkt im Boot-Prozess angezeigt, an dem sie mit der Ausführung von differenziertem Code (dem Windows Server Container) beginnen wird. Kurz vor diesem Zeitpunkt wird ein kurzer Schnappschuss und eine Kopie des VM-Status erstellt, indem der Speicherstatus eingefroren wird. Das nächste Mal, wenn ein Hyper-V Container gestartet wird, wird er von dem erstellten Snapshot aus gestartet.

Verwendung

Die Erstellung von Hyper-V-Containern ist eine Entscheidung zur Laufzeit. Zur Designzeit gibt es keinen Unterschied zwischen Windows Server Containern und Hyper-V Containern. Sie definieren Ihre Container-Images einfach auf die gleiche Weise wie bei normalen Windows Server Containern und im Falle von Docker bedeutet dies, dass Sie genau die gleichen Images verwenden, um sowohl Windows Server Container als auch Hyper-V Container zu initialisieren. Um Hyper-V Container auszuführen, müssen Sie sicherstellen, dass Sie die Funktionen Windows Hyper-V und Container auf Ihrem Container-Host aktiviert haben.

Um einen neuen Hyper-V-Container auf der Grundlage eines vorhandenen Docker-Images zu erstellen, müssen Sie den Schalter isolation=hyperv zum Befehl docker run hinzufügen, wie unten gezeigt. docker run -it --isolation=hyperv microsoft/nanoserver cmd

Hyper-V-Container gegenüber VMs

Wir haben besprochen, dass Hyper-V Container für Szenarien konzipiert sind, in denen Sie eine zusätzliche Sicherheitsgrenze um Ihre containerisierten Arbeitslasten herum benötigen. Aber warum nicht eine separate Hyper-V-VM anstelle von Hyper-V-Containern verwenden? Obwohl die Verwendung von Hyper-V VMs eine alternative Lösung sein könnte, wirkt sich die Verwendung von VMs zur Schaffung einer zusätzlichen Isolationsebene negativ auf die Flexibilität, die Kosten und die Skalierbarkeit Ihrer Arbeitslast in der Produktion aus. Der große Vorteil der Verwendung von Hyper-V-Containern anstelle von VMs ist, dass Container für die heutigen Anforderungen konzipiert sind. Sie sind schnell bereitzustellen, schnell zu zerstören und haben einen geringen Platzbedarf. Hyper-V Container bieten die Vorteile von Containern wie Geschwindigkeit, Skalierbarkeit und Effizienz, bieten aber auch die gleiche Isolierung auf Kernel-Ebene wie Hyper-V VMs.

Mehr aus dieser Serie

• Vertiefung in Windows Server Containers und Docker Teil 1: Warum sollte uns das interessieren?
• Vertiefung in Windows Server Containers und Docker Teil 2: Grundlegende Implementierung von Windows Server Containers
• Vertiefung in Windows Server Containers und Docker Teil 3: Grundlegende Implementierung von Hyper-V Containern