Container in Windows Server 2016: Funktionsweise, Typen, Anwendungen

Hyper-V muss jede VM und ihr darin enthaltenes OS starten, Ressourcen wie vCPUs, RAM usw. zuteilen bis seine physischen Kapazitäten zur Neige gehen. Außerdem unterliegen die Gastbetriebs­systeme dem ständigen Update-, Hardening- und Wartungsprozess.

Container auf einem Container-Host hingegen starten nicht mit einer eigenen OS-Kopie, sondern teilen sich ein Host-Betriebssystem und haben von Anfang an einen schmaleren RAM-Footprint.

Die Applikation im Container sieht nur ihre dedizierte Umgebung, startet schnell und nutzt nur den Speicher, den sie benötigt. Somit lässt sich damit eine höhere Dichte von Anwendungen auf einem Host erreichen als auf einem Hypervisor.

Container OS Images als Basis für neue Container

Wenn wir über Container sprechen, dann beziehen wir uns auf dateibasierte und schreibgeschützte Container-Vorlagen. Container OS Images können auf Core- oder Nano Server beruhen und weisen somit die vertraute Windows-Verzeichnis­struktur auf (Programme, Programme (x86), Benutzer, Windows, usw.). Bei manueller Container-Erstellung wird auf Basis dieses Images eine "Sandbox" eingerichtet, welche zur darunter liegenden Windows Struktur verlinkt.

Wie die folgende Tabelle zeigt, eignet sich nicht jedes Image für jeden Container-Host:

Installiert man nun in diese Sandbox eine Applikation, beispiels­weise einen Web-Server, dann wird etwa das Verzeichnis \inetpub in der Sandbox angelegt. Wird die Sandbox gestoppt, kann hieraus wieder ein Read-only-Image inklusive IIS abgeleitet werden und alle grundlegenden OS-Verzeichnisse verweisen weiter auf das Basis-Image. So lassen sich auf identischer Grundlage mehrere Ebenen aufbauen.

Windows Server-Container und Hyper-V Container

Unter anderem durch die Namespace-Technologie und Resource-Zuweisung (bekannt von LXC, Linux Containers) ist es möglich, Container gegeneinander zu isolieren. Die Isolation mittels Namespace gewährleistet, dass jeder Container sein eigenes Dateisystem und seine Registry sieht. Bei der Resource Isolation wird dem Container vorgegeben, wieviel RAM, CPU und Netzwerkbandbreite er nutzen kann.

Doch Windows Server Container teilen sich gemeinsam Bereiche des OS Kernels und haben theoretisch auf dieser Ebene Berührungs­punkte. Kommt es zu einer Kompromittierung im Container oder einem fehlerhaften Update des Kernels, dann wären alle Container davon betroffen. Hyper-V Container hingegen erreichen durch die zusätzliche Hypervisor-Ebene einen noch höheren Isolationsgrad gegenüber benachbarten Containern und dem Host.

Es handelt sich dabei um leichtgewichtige VMs, optimiert für Container und mit einer eigener Kopie des OS-Kernels. Das zusätzliche Maß an Sicherheit, etwa um Mandanten in Azure strikter voneinander zu trennen, macht sich durch ein langsameres Startverhalten und einer nicht so hohen Applikationsdichte wie bei Windows Server Containern bemerkbar.

Auch wenn es sich bei den beiden Container-Typen um verschiedene Technologien handelt, ist eine Entscheidung für einen von ihnen nicht endgültig. Von Windows Server Containern zu Hyper-V Containern kann nämlich umgeschaltet werden und auch der umgekehrte Weg ist möglich:

Einsatzgebiete für Container

Container starten zügig und sind wartungsarm. Durch ihre isolierte Umgebung lassen sie sich gut transportieren. Einem Administrator oder Mitgliedern des DevOps-Teams ist es möglich, Windows Container mit Applikationen zu konfigurieren und dann als Paket ohne große Abhängigkeiten in die Server-Umgebung zu transferieren und dort zu testen.

Ein Beispiel für eine isolierte Container-Anwendung wären etwa die Internet Information Service (IIS). Container können nicht nur on-premises ausgeführt werden, sondern lassen sich leicht in die Azure Cloud auslagern.