Container in Windows Server 2016: Was Sie wissen müssen

In einer Geschichte, die ich im Januar für Computerworld geschrieben habe und die einen Überblick über die technische Vorschau 4 von Windows Server 2016 gab, erwähnte ich die neue Unterstützung von Windows Server für Hyper-V-Container, die zu der Unterstützung für Docker-ähnliche Container (in der Beta vorhanden) hinzugefügt wurde Produkt seit der vorherigen Beta-Meilenstein-Version).

Das Vorhandensein von zwei Containeroptionen hat jedoch zu vielen Fragen geführt. Was ist der Unterschied zwischen einem Docker-Container und einem neuen Hyper-V-Container? In welchen Szenarien möchten Sie eine Containerlösung über der anderen verwenden? Gibt es separate Methoden zum Bereitstellen dieser Methoden?

Microsoft hat diese beiden Containeroptionen nicht besonders gut dokumentiert, und die Container selbst sind neu in der Windows Server-Plattform. Angesichts dieser beiden Faktoren möchte ich eine ganze Geschichte darüber widmen, welche spezifischen Containerlösungen Windows Server 2016 entweder jetzt in Vorschauform in den verfügbaren Versionen bereitstellt oder verspricht, diese vor dem Release der Software zum Herstellungsdatum (RTM) bereitzustellen, höchstwahrscheinlich in das zweite Halbjahr 2016.

Überblick

Derzeit sind in Windows Server 2016 zwei Arten von Containern vorhanden: Windows Server-Container und Hyper-V-Container. Beide unterstützen nur Windows Server. Weder kann beispielsweise Linux und / oder Unix mischen und anpassen.

Lassen Sie uns für faule Administratoren wie mich die wichtige Frage aus dem Weg räumen: Ist einer der beiden Containertypen schwieriger bereitzustellen als der andere? Die Antwort ist ein klares Nein.

[Weiterführende Literatur: Erster Blick: Ausführen von VMs in VMs mit Hyper-V-Containern]

Die Containertypen werden unterschiedlich ausgeführt und haben unterschiedliche Isolations- und Vertrauensstufen für den Hypervisor. Im Kern handelt es sich jedoch um eine Entscheidung zur Bereitstellungszeit, die vom Eigentümer der physischen Maschine - dem Host-Eigentümer - getroffen wird, welcher Containertyp verwendet wird. Sie ist so einfach wie das Überprüfen des richtigen Optionsfelds in einem Assistenten . Sie können bei der Erstellung einfach zwischen den beiden wählen. Die Entscheidung wirkt sich darauf aus, wie Windows Server 2016 - das Betriebssystem selbst (der Hypervisor, der am Ende all dieser Dinge sitzt, auf Silizium und physischem Eisen läuft) - die Workloads in jedem Container isoliert und ausführt.

Nun, da Sie wissen, dass beide Containeroptionen für Sie den gleichen Arbeitsaufwand bedeuten, wie entscheiden Sie sich intelligent zwischen beiden? Im Wesentlichen kommt es auf das Vertrauen an: Wenn Sie dem im Container ausgeführten Code vertrauen, wählen Sie einen Windows Server-Container (sprich: traditionell im Docker-Stil). Wenn Sie dem Code nicht vertrauen oder ihn nicht überprüfen können oder er nicht von Ihren internen Entwicklern in Ihrer eigenen Organisation stammt, ist ein Hyper-V-Container der richtige Weg. Schauen wir uns jede Option im Detail an.

Windows Server-Container

Windows Server-Container sind eigentlich nur ein Teil des Open Source-Containerprojekts von Docker. Wenn Sie also an einen Container im Docker-Stil denken, denken Sie an einen Windows Server-Container. Diese Container sind im Wesentlichen eine neue Art von virtueller Maschine, die in gewisser Weise weniger isoliert ist als eine herkömmliche virtuelle Maschine - und zwar in vielen Fällen, wenn alle auf einem Host ausgeführten Container gemeinsam genutzt werden. Zu diesen freigegebenen Elementen gehören Betriebssystemdateien, Verzeichnisse und ausgeführte Dienste. Dies geschieht aus Gründen der Effizienz. Wenn Sie drei verschiedene Container auf einem Host ausführen, die alle dieselbe Windows Server-Version wie Gäste haben, benötigen Sie jeweils nur eine Kopie des Verzeichnisses C: \ Windows.

Diese Freigabe trennt Container immer noch von einer bestimmten Anwendung, die möglicherweise auf einem Host ausgeführt wird. Sie reduziert jedoch auch den Overhead und macht Container leichter. Aufgrund dieser Freigabe haben Sie mehr Headroom pro Server, auf dem Container ausgeführt werden, im Gegensatz zu herkömmlichen virtuellen Maschinen, die isolierter sind und nichts gemeinsam nutzen - und daher tendenziell viel mehr Duplikate aufweisen. Im Allgemeinen verwenden Sie auch Windows Server-Container, wenn auf Ihrem Host und Ihrem Gast alle dasselbe Betriebssystem ausgeführt wird, um diese Freigabe nutzen zu können. Daher können Sie keinen Container mit Ubuntu Server ausführen, der auf einem Windows Server 2016-Host ausgeführt wird. (Für diese Art von Workload würden Sie herkömmliche virtuelle Maschinen verwenden. Container wären dafür nicht geeignet. Sie würden nur VMs verwenden, die seit 2008 in Windows unterstützt werden.)

Derzeit sind Server Core (Windows ohne grafische Benutzeroberfläche) und Windows Nano Server, der radikal überarbeitete Mikroserver, der für kleine, auf Mikrodienste ausgerichtete Rollen geeignet ist, die beiden von Windows Server-Containern unterstützten Container-Image-Betriebssysteme. (Mehr zu Microservices in Kürze.)

Wie passt Docker in all das? Docker bietet, wenn Sie so wollen, eine "Verwaltungsschicht" aus APIs und Engines zur Verwaltung von Containern - eine, die schnell zum Industriestandard geworden ist, möglicherweise weil Docker selbst Open Source ist und weit verbreitet ist. Der Docker Hub, der für alle im Internet verfügbar ist, ist ein echtes Repository für Anwendungen im Marktplatzstil, die alle in Containern im Docker-Stil ausgeführt werden.

Docker bietet auch ein mentales Framework, mit dem Entwickler dem tatsächlichen Betrieb ihres Codes näher kommen und ganze Container der Umgebungen erstellen können, für deren Ausführung der Code erforderlich ist. Entwickler erstellen im Wesentlichen Container-Images, die dann ganz einfach an den Betrieb übergeben werden, und werden im Wesentlichen so ausgeführt, wie sie als Gäste auf diesem Host sind. Updates und Codekorrekturen können auf die gleiche Weise schnell und einfach gehandhabt werden.

Jedes dieser Container-Images funktioniert möglicherweise sogar in einem sehr kleinen Teil der Gesamtanwendung, wodurch die Lösung komponiert und das Arbeiten in einer auf Microservices ausgerichteten Umgebung vereinfacht wird. Aus einer Gesamtperspektive erhöht die Arbeit mit Containern die Verantwortung der Entwickler, guten Code zu schreiben, der genau in ihrer Umgebung funktioniert. Entwickler können keinen Code mehr schreiben, der perfekt auf ihren Entwicklungsmaschinen funktioniert, sondern fallen um, wenn sie in Produktionssoftware bereitgestellt werden. Da sie ein und dasselbe sind, muss der Code an beiden Stellen funktionieren. Dies verringert auch die Reibung zwischen Betrieb und IT - IT mit seinen makellosen Serverumgebungen und Entwicklern, die bestimmte Konfigurationen erwarten, aber häufig nicht die Fähigkeit oder das Grundprinzip haben, Produktionsumgebungen so zu ändern, dass sie ihren Erwartungen entsprechen.

Diese Windows Server-Container im Docker-Stil setzen ein gewisses Maß an Vertrauen voraus - entweder, dass Sie eine vertrauenswürdige Anwendung von Docker Hub heruntergeladen haben oder dass Ihre internen Entwickler oder Vertragsentwickler Ihnen einen Container zur Verfügung gestellt haben, in dem Sie vertrauenswürdigen Code ausführen. Für Anwendungen in Containern mit vertrauenswürdigem Code werden Windows Server-Container empfohlen und sind geeignet. Die Freigabe und Projektion von Betriebssystemdateien sollte für vertrauenswürdigen Code kein Problem darstellen.

Aber was passiert, wenn ein bisschen mehr Sicherheit, ein bisschen mehr Isolation mit weniger als vollständig vertrauenswürdigem Code oder Apps erforderlich ist?

Hyper-V-Container

Dann beginnen Sie mit der Betrachtung von Hyper-V-Containern, die das Modell der Isolation und Abstraktion von herkömmlichen virtuellen Maschinen mit der Flexibilität, dem Image und den einfachen Umsetzungsformaten von Windows Server-Containern im Docker-Stil sowie der Docker-API und den Verwaltungstools verbinden Ich habe im vorherigen Abschnitt besprochen.

Mark Russinovich, CTO für Microsoft Azure, hat es letztes Jahr in einem Blogeintrag so ausgedrückt: Hyper-V-Container "isolieren Anwendungen mit den Garantien, die mit der herkömmlichen Virtualisierung verbunden sind, aber mit der Einfachheit, dem Bildformat und dem Verwaltungsmodell von Windows Server-Containern, einschließlich die Unterstützung von Docker Engine. " Der Unterschied besteht in der Isolationsstufe: Hyper-V-Container teilen Betriebssystemdateien, -prozesse und -dienste nicht direkt mit dem Host. Vielmehr packt Windows Server jedes kleine Container-Image in eine virtuelle Maschine mit sehr geringem Overhead ein, wodurch die Abstraktions- und Vertrauensgrenze erreicht wird, die ein Windows Server-Container im Docker-Stil nicht erreicht.

Diese virtuelle Maschine ist jedoch für den Administrator in jeder Hinsicht transparent. Die Container-Images selbst, auf denen Windows Server ausgeführt wird, verstehen, dass es sich tatsächlich um Container-Images handelt, die nicht auf normalem, uneingeschränktem Silizium ausgeführt werden, und können daher Optimierungen für das Betriebssystem nutzen, die sich aus dieser Erkenntnis ergeben. Obwohl diese Container-Images isolierter sind, werden sie nicht anders bereitgestellt als Windows Server-Container. Sie verwenden weiterhin Docker-APIs. Sie verwenden weiterhin den Docker-Client. Sie aktivieren nur ein anderes Kontrollkästchen, aber die Container-Images selbst werden auf dieselbe Weise erstellt und geliefert, unabhängig davon, welches Isolationsmodell Sie zum Ausführen verwenden möchten.

Der Nachteil dieses Ansatzes: Es gibt mehr Overhead. Aufgrund der zusätzlichen Isolation werden mehr Code und Prozesse dupliziert. Es gibt auch die Tatsache, dass der leichte Wrapper für virtuelle Maschinen für einen Hyper-V-Container zwar klein ist, aber tatsächlich eine "Steuer" zu den Kosten für die Ausführung eines Container-Images hinzufügt. Während Sie also einen leistungsstarken Host mit Windows Server-Containern im Docker-Stil füllen können, sind Hyper-V-Container auf eine bestimmte geringere Anzahl von Containern beschränkt, alle anderen sind in Bezug auf die Hardware gleich.

Auch diese Container-Images würden nur Windows Server unterstützen. Obwohl es eine Isolation gibt, gibt es immer noch Gemeinsamkeiten zwischen den Container-Images und dem Host-Betriebssystem. Wenn auf Ihren Container-Images Linux, eine andere Variante von Unix, BSD oder ein anderes alternatives Betriebssystem ausgeführt wird, ist keine dieser neuen Windows Server 2016-Funktionen für Sie von Bedeutung.

Fazit: Code von Drittanbietern, Marktplatzcode oder Code, dem sonst kein Teil Ihrer Organisation vollständig vertraut, sollten in Hyper-V-Containern ausgeführt werden. Dies ist auch die beste Wahl für öffentliche Clouds mit mehreren Mandanten und ähnliche Umgebungen. Sie verlieren nur Kapazität und erhalten die Sicherheitsvorteile einer stärkeren Isolation.

Docker-Container

Um zu beweisen, dass Branding immer der schwierigste Teil jeder Technologie ist, möchte ich Docker-Container vorstellen. Oben habe ich erwähnt, dass Windows Server-Container ein Teil des Docker-Open-Source-Projekts sind. Docker-Container unterscheiden sich von Windows Server-Containern. Windows Server-Container können die gesamte zugrunde liegende Docker-Technologie verwenden, aber das vorhandene Docker-Toolset zum Verwalten von Docker-Containern funktioniert (zumindest in dieser Version) nicht mit Windows Server-Containern. Auch Windows Server-Containerverwaltungstools - zu diesem Zeitpunkt eine Reihe von PowerShell-Befehlen - können mit Docker-Containern selbst nichts Wertvolles tun.

Docker-Container sind ihre eigene spezifische Sache, und während Windows Server-Container in ihrer Fähigkeit, gemeinsam zu nutzen, aber zu isolieren, wie Docker-Container wirken - weshalb ich sie als Windows Server-Container im Docker- Stil bezeichnet habe -, sind sie per se keine Docker-Container . Dies kann sich in Zukunft ändern, insbesondere in einem Service Pack oder der nächsten Version von Windows Server. Derzeit bleiben diese drei Containertypen jedoch unterschiedliche Konzepte, auch wenn sie alle ähnlich sind. Derzeit werden nur zwei von Windows Server unterstützt.

Wo die Technologie heute ist

Derzeit ist die Containerunterstützung in Windows Server 2016 noch in Arbeit. Es gibt viele bewegliche Teile in Containern: Entfernen von Abhängigkeiten von Host- und Betriebssystemdateien sowie bestimmten Versionen und Patch-Levels; Das Erreichen der richtigen Isolation und das Sicherstellen, dass kein Code diese Sicherheits- und Vertrauensgrenze überschreiten kann; Machen Sie die Entwicklergeschichte mit Tools und Automatisierung richtig, mit denen Entwickler mit Containern in ihrer bevorzugten integrierten Entwicklungsumgebung (IDE) arbeiten und ihre Anwendungen direkt in den Container "exportieren" können. Sicherstellen, dass Container nahtlos in der öffentlichen Cloud auf und ab verschoben werden können; und mehr.

In all diesen Fällen müssen immer noch schwerwiegende Fehler und Bugs behoben werden. Wenn Container für Ihre Roadmap mit Serviceangeboten in Ihrem Shop von entscheidender Bedeutung sind, sollten Sie jetzt die Funktionen von Windows Server-Containern und Hyper-V-Containern testen und insbesondere die verfügbaren PowerShell-Befehle zum Aktivieren und Verwalten von Containern lesen auf einem Windows Server 2016-Host.

Wenn Container jedoch eine gute Option, aber kein Muss für Ihr Unternehmen sind, wäre meine informierte Empfehlung, den Versuch, etwas anderes als die rudimentärste Erkundung mit der 4-Bit-Vorschau zu versuchen, zurückzuhalten. Es gibt immer noch zu viele Warzen - einschließlich der zuvor erwähnten schwerwiegenden Fehler und Bugs -, um wirklich einen zusammenhängenden Eindruck davon zu bekommen, was passiert.

Die Containerunterstützung wird eine aufregende Ergänzung der Windows-Plattform sein. Es bleibt noch viel von dieser Geschichte zu schreiben und zu erzählen.

Diese Geschichte "Container in Windows Server 2016: Was Sie wissen müssen" wurde ursprünglich von Computerworld veröffentlicht.