Container: Docker wird durch Windows Server-Container für Windows-Entwickler verfügbar

Von Taylor Brown | April 2017

In den letzten Jahren waren Docker und Container weltweit in Entwicklerkreisen und Unternehmen ein heiß diskutiertes Thema. Das Release von Windows Server 2016 im letzten Herbst erweiterte diesen Diskurs um einen neuen Aspekt, weil Container nun auch für Windows-Entwickler zugänglich sind. Wie trafen sich die Welten von Windows und Docker? Alles begann im traumhaften Sommer 2014 am Puget Sound, als das Windows-Basisteam ein neues Projekt anging, aus dem schließlich Windows Server-Container entstanden. Dies ist die Geschichte hinter dem Code und ein kurzer Einblick in die Entstehung eines der wichtigsten neuen Features in Windows Server 2016.

Die Geschichte von Containern und die Entstehung von Docker

Im Jahr 2013 erweckten Container schnell das Interesse von Solomon Hykes (der natürlich vor seiner Tastatur saß). Er war damals CTO und Gründer eines PaaS-Startups (Platform-as-a-Service) namens DotCloud. Hykes verwendete eine Sammlung relativ obskurer und schwierig zu verwendender Features des Linux-Kernels und brachte diese unter einem Open Source-Tool zusammen, dem er den Namen „Docker“ gab. Es lag nicht in seiner Absicht, zum König der Container zu werden, aber er suchte nach einer Lösung für ein Problem, mit dem sich DotCloud herumschlug: Wie können Entwickler Code bereitstellen, der auf Servern auf die gleiche Weise wie in ihrer Arbeitsumgebung funktioniert?

Ein echtes Problem für Dienste wie DotCloud beruhte auf der umfangreichen und verschiedenartigen Sammlung von Softwareanwendungen, die Kunden bereitstellen wollten: Software, die mit unterschiedlichen Entwicklungsverfahren erstellt wurde, die unterschiedliche Patchzyklen und -anforderungen aufwies, die in verschiedenen Sprachen (sowohl bezüglich Code als auch natürlicher Sprache) geschrieben wurde und unterschiedliche Abhängigkeiten aufwies. Hardwarevirtualisierung (virtuelle Computer, VMs) war das beste verfügbare Tool, stellte jedoch auch Herausforderungen bei der Auslieferung von Software von den Entwicklerlaptops in die Produktion dar. Es mussten entweder vollständig konfigurierte virtuelle Computer vom Entwickler verwendet werden (wodurch Skalierbarkeit und Verwaltung schwierig wurden), oder es mussten Bereitstellungstools und Skripts erstellt werden, um die Anwendungen der Entwickler auf virtuellen Computern aus dem Bestand zu installieren (eine unflexible und fehleranfällige Lösung).

Hykes war der Meinung, dass Docker die Antwort auf dieses Problem war. Im Rückblick lag er damit nicht einmal so falsch. Er war jedoch nicht der erste Clouddienst, der sich mit Containern befasste. Tatsächlich waren es die Bedürfnisse eines anderen Clouddiensts, der den Startschuss für das ganze Konzept setzte: Google. Im Jahr 2006 wurde durch einen von Rohit Seth (Engineer bei Google) entwickelten Patch des Linux-Kernels Unterstützung für Gruppierungsprozesse unter einer allgemeinen Sammlung von Ressourcensteuerelementen in einem Feature namens „cgroups“ hinzugefügt. Seths Beschreibung dieses Patch beginnt folgendermaßen: „Standardhardware wird leistungsfähiger. Dadurch entsteht die Möglichkeit, verschiedene Arbeitsauslastungen auf der gleichen Plattform auszuführen, damit eine bessere Nutzung der Hardwareressourcen erzielt wird“ (bit.ly/2mhatrp). cgroups lösten zwar das Problem der Ressourcenisolierung, nicht jedoch die inkonsistente Verteilung. Aus diesem Grund verwendet Docker nicht nur cgroups, sondern außerdem ein anderes Feature der Linux-Technologie: Namespaces.

Namespaces wurden im Jahr 2002 im Linux-Kernel eingeführt. Sie bieten ein Verfahren zum Steuern, welche Ressourcen ein Prozess sehen kann und wie diese Ressourcen benannt sind. Namespaces unterscheiden sich deutlich von Zugriffssteuerungen, weil der Prozess nicht einmal weiß, dass die Ressourcen vorhanden sind oder dass er eine Version dieser Ressourcen verwendet. Ein einfaches Beispiel ist die Prozessliste: Möglicherweise werden 20 Prozesse auf einem Server ausgeführt, ein in einem Namespace ausgeführter Prozess sieht jedoch ggf. nur fünf dieser Prozesse. Der Rest wird ausgeblendet und ist für den Prozess unsichtbar. Ein weiteres Beispiel wäre ein Prozess, der meint, aus dem Stammverzeichnis zu lesen, während dieses von einem anderen separaten Speicherort virtualisiert wurde. Es war die Kombination aus cgroups und Namespaces sowie CoW-Dateisystemtechnologien (Copy-on-Write) in einem einfach zu verwendenden Open Source-Produkt, das zur Grundlage von Docker wurde.

Mitte 2013 startete das Docker-Toolset, das Hykes und sein Team erstellten, richtig durch und wurde zu einem der wichtigsten Trendprojekte auf GitHub. Die Marke Docker war formal geboren. Hykes Schwerpunkt verlagerte sich von DotCloud zu Docker, und er erklärte DotCloud letztlich zu einem Spin-off, blieb aber CTO von Docker Inc.

Windows Server-Container

Im gleichen Zeitraum, in dem Docker in Linux-Kreisen Aufmerksamkeit erregte, suchte das Windows-Basisteam nach Möglichkeiten, die Effizienz der Microsoft Azure-Dienste zu isolieren und zu steigern, die Kunden- oder Drittanbietercode ausführten. Ein Microsoft Forschungsprototyp mit dem Codenamen „Drawbridge“ war einer der eingeschlagenen Wege. Für das Projekt wurde ein Prozessisolierungscontainer erstellt, der ein Bibliotheksbetriebssystem nutzt (bit.ly/2aCOQxP). Unglücklicherweise wies Drawbridge Einschränkungen bezüglich der Verwaltbarkeit, Leistung und Anwendungskompatibilität auf und war damit nur schlecht als Universallösung geeignet. Eine noch frühere Prototyptechnologie, die als „Serversilos“ bezeichnet wurde, schien anfangs untersuchungswürdig zu sein. Silos erweiterten den vorhandenen Ansatz der Windows-Auftragsobjekte, der Prozessgruppierung und Ressourcensteuerelemente (ähnlich den cgroups in Linux) (bit.ly/2lK1AbI) bereitstellt. Der Serversiloprototyp fügte eine isolierte Ausführungsumgebung hinzu, die ein Dateisystem, eine Registrierung und Objektnamespaces (ähnlich den Namespaces in Linux) umfasste. Der Serversiloprototyp wurde vor Jahren zugunsten von virtuellen Computern zurückgestellt, dann aber als Grundlage für Windows Server-Container erneut angedacht.

Der Code des Serversiloprototyps war jahrelang nicht mehr beachtet worden. Er ließ sich nicht einmal kompilieren (und funktionierte natürlich auch nicht), und es handelte sich um Prototypcode, der beweisen sollte, dass die Technik in Windows machbar war. Bereit für die Produktion war der Code noch lange nicht. Das Team hatte die Wahl: ganz neu anzufangen oder zu versuchen, den Prototyp zum Leben zu erwecken und als Ausgangspunkt zu verwenden. Wir haben uns für Letzteres entschieden. An der ursprünglichen Entwicklung des Prototyps war nur ein kleines Team von Entwicklern beteiligt, die beweisen sollten, dass die Technologie machbar war. Nun stand die geballte Kraft des Windows-Engineeringteams hinter dem Projekt. Architekten und Engineers aus allen Bereichen von Windows wurden um Unterstützung gebeten. Das Speicherteam erstellte die Dateisystemvirtualisierung, das Netzwerkteam die Netzwerkisolierung, das Kernelteam die Speicherverwaltung und die Planungsabstraktionen usw.

Einige große Architekturfragen blieben jedoch. Insbesondere die folgende Frage: wie würden wir Systemprozesse behandeln? In Linux führt ein Container häufig nur einen einzelnen Prozess aus, der die Systemdienste im Kernel mit dem Host und anderen Containern gemeinsam verwendet. Zur Verbesserung der Wartbarkeit und Sicherheit verschiebt Windows jedoch schon seit Jahren Code aus dem Kernel in Benutzermodusprozesse. Dies stellte ein Problem für das Team dar: Wir konnten entweder alle Systemdienste freigeben (dies würde Änderungen an allen Systemdiensten bedeuten, um sie kompatibel mit Containern zu machen) oder eine neue Kopie der Benutzermodus-Systemdienste in jedem Container starten. Dies war eine schwierige Entscheidung. Wir machten uns Sorgen um die Dichte und die Auswirkungen der Startdauer beim Starten neuer Instanzen aller Benutzermodusdienste in jedem Container. Andererseits hatten wir aber auch Bedenken bezüglich der Komplexität und der laufenden Kosten für das Aktualisieren aller Systemdienste in Windows, und zwar nicht nur auf unserer Seite, sondern auch bei Entwicklern außerhalb von Windows. Am Ende landeten wir bei einer Mischung aus den beiden Ansätzen: Eine ausgewählte Sammlung von Diensten wurde mit Containerkompatibilität versehen, die meisten Dienste werden aber in jedem Container ausgeführt.

Die Auswirkungen auf die Dichte waren minimal, weil die Container schreibgeschützten Arbeitsspeicher untereinander und mit dem Host teilen. Daher ist nur der private Arbeitsspeicher pro Container ausgelegt. Die Startzeit war jedoch eine erhebliche Herausforderung. Diese Entscheidung wurde viele Male infrage gestellt. Als wir Windows Server-Container in der Keynote von Build 2015 erstmals vorgestellt haben, nahm der Start mehrere Sekunden in Anspruch, und zwar größtenteils aufgrund der Startdauer der Systemdienste. Das Windows Server-Leistungsteam hat sich jedoch der Sache angenommen. Seine Mitglieder haben profilt, analysiert und mit Teams rund um Windows zusammengearbeitet, um die Dienste schneller bereitzustellen und Abhängigkeiten zu verringern, damit die Parallelität verbessert wird. Das Ergebnis dieser Anstrengungen hat nicht nur den Containerstart beschleunigt, sondern tatsächlich auch die Startdauer von Windows optimiert. (Wenn Ihre Xbox oder Ihr Surface im letzten Jahr schneller gestartet wurde, können Sie sich bei den Containern bedanken.) Die Containerstartdauer verringerte sich in weniger als einem Jahr von ungefähr sieben oder acht Sekunden auf unter eine Sekunde. Diese Kurve zum Verringern der Startdauer wird noch heute fortgesetzt.

Hyper-V-Isolierung

Die erste Frage, die ich häufig bezüglich der Hyper-V-Isolierung höre, lautet: „Stellen Container nicht bereits Isolierung bereit? Wozu brauche ich dann noch Hyper-V?“ Container stellen in der Tat Isolierung bereit, und für die meisten Szenarien ist diese Isolierung wahrscheinlich vollkommen ausreichend. Wenn ein Angreifer in der Lage ist, den Kernel zu kompromittieren, besteht das Risiko jedoch darin, dass der Angriff potenziell den Container verlässt und sich negativ auf andere Container oder den Host auswirkt. Da Kernelangriffe in Windows relativ häufig sind (in der Regel mehrere pro Jahr), ist das Risiko für Dienste wie Azure Automation oder Azure Machine Learning, die Endbenutzer- oder Drittanbietercode in einer freigegebenen Infrastruktur nutzen oder ausführen, zu hoch, um sich nur auf Kernelisolierung zu verlassen. Teams, die diese Art von Diensten erstellen und betreiben, mussten die Dichte und Startkosten vollständiger virtueller Computer verwalten oder andere Sicherheits- und Isolierungstechniken einsetzen. Benötigt wurde ein Allzweckisolierungsmechanismus, der Eindringlingen feindlich gesonnen, aber sicher für mehrere Mandanten war: Windows Server-Container mit Hyper-V-Isolierung.

Das Team arbeitete bereits intensiv an Windows Server-Containern, und dieser Ansatz war eine großartige Erfahrung und ein Verwaltungsmodell für Teams, die die Dienste erstellen. Indem die Technologie mit der umfassend getesteten Isolierung von Hyper-V gekoppelt wurde, konnten wir die erforderlich Sicherheit bereitstellen. Wir mussten jedoch noch die Herausforderungen der Startdauer und Dichte meistern, die virtuellen Computern traditionell nachgesagt werden.

Hyper-V war wie die meisten Virtualisierungsplattformen dafür konzipiert, Gastsysteme mit einer Vielzahl von alten und neuen Betriebssystemen auszuführen. Das Ziel war, ein Verhalten bereitzustellen, das Hardware so weit wie möglich ähnelt. Zum Erreichen dieses Ziels wählten die meisten Virtualisierungsplattformen das Emulieren gängiger Hardware als Lösung. Als Virtualisierung alltäglich geworden war, wurden Betriebssysteme jedoch so „erleuchtet“ (unter dem Gesichtspunkt geändert, gut als virtuelle Gastcomputer zu funktionieren), dass ein Großteil der Emulation nicht mehr erforderlich war. Ein gutes Beispiel dafür sind virtuelle Hyper-V-Computer der 2. Generation, die Emulation zugunsten verbesserter Startdauer und Leistung aufgeben, aber trotzdem das gleiche Ziel erreichen: Sie verhalten sich so, als würde das Gastsystem direkt auf Hardware ausgeführt (bit.ly/2lPpdAg).

Für Container bestanden andere Anforderungen und Ziele: Wir mussten keine älteren Betriebssysteme ausführen, und wir wussten genau, wie die Arbeitsauslastung im virtuellen Computer aussehen würde: ein Container. Daher haben wird einen neuen Typ von virtuellem Computer erstellt. Ein Computer, der für das Ausführen eines Containers konzipiert ist. Die Anforderung einer schnellen Startdauer haben wir mithilfe von Klontechnologie gelöst. Diese Herausforderung bestand für traditionelle virtuelle Computer schon immer, weil das Betriebssystem durch Dinge wie Hostnamen und Identität personalisiert wird, die nicht auf einfache Weise ohne einen Neustart geändert werden können. Da jedoch Container über einen eigenen Hostnamen und eine eigene Identität verfügen, stellte dies kein Problem mehr da. Das Klonen war ebenfalls bei der Herausforderung bezüglich der Dichte hilfreich. Wir mussten jedoch noch einen Schritt weiter gehen: Wir brauchten Arbeitsspeicherfreigabe.

Es gibt zwei Möglichkeiten, Arbeitsspeicher freizugeben. Sie können nach Arbeitsspeicher Ausschau halten, der für mehrere virtuelle Computer gemeinsam verwendet wird und eine effektive Deduplizierung ausführen (auch wenn dies durch Speicherrandomisierungstechnologie in den meisten Kerneln zu einer schwierigen Aufgabe wird). Oder Sie können den gleichen Ansatz wie der Kernel verfolgen, indem Sie schreibgeschützten (öffentlichen) Speicher von Speicher mit Lese- und Schreibberechtigung (privatem Speicher) trennen. Für die letztgenannte Strategie ist es in der Regel erforderlich, dass die Speicher-Manager in virtuellen Gastcomputern miteinander interagieren. Dies widerspricht der Isolierungsanforderung. Durch Ändern der Art und Weise, wie virtuelle Computer gestartet werden und auf Dateien zugreifen, haben wir jedoch eine Möglichkeit gefunden, bei der der Host nicht dem Gassystem trauen muss und sich die Gastsysteme auch nicht gegenseitig trauen müssen. Der virtuelle Computer wird nicht von einer virtuellen Festplatte gestartet und greift auch nicht auf Dateien auf dieser zu, sondern startet direkt aus dem Hostdateisystem. Auch der Dateizugriff erfolgt über dieses. Dies bedeutet, dass der Host die gleiche Freigabe des schreibgeschützten (öffentlichen) Speichers bereitstellen kann. Dies ist der Schlüssel zum Verbessern der Dichte um mehrere Größenordnungen, und es erschließt sich für viele Jahre eine Perspektive zum Fortsetzen dieser Optimierung.

Wir haben einen weiteren Vorteil bei der Hyper-V-Isolierung entdeckt: Durch Ausführen eines anderen Kernels für den Container für Entwickler, die Containeranwendungen auf ihren Windows 10-Computern erstellen, konnten wir den Serverkernel trotzdem weiterhin ausführen. Auf diese Weise wird sichergestellt, dass ihre Anwendungen in der Produktion auf die gleiche Weise wie auf den Entwicklungscomputern funktionieren. Im Windows 10 Anniversary Update haben wir daher Windows Server-Container mit Hyper-V-Isolierung ermöglicht und mit Docker unter Docker für Windows gearbeitet, um die neue Technologie für Entwickler optimal zu nutzen.

Docker und Windows Server-Container

Eine Frage blieb: wie würden Benutzer mit dieser neuen Plattformtechnologie interagieren? In der Linux-Welt konnte Docker viel Lob einheimsen und wurde schnell zum Industriestandard für die Containerverwaltung. Warum also nicht Benutzer in die Lage versetzen, Windows Server-Container auf die gleiche Weise verwenden zu können? In jenem Herbst flog ich nach San Francisco, um mich mit Docker zu treffen. Ich war mir nicht sicher, wie das Unternehmen zu einem auf Windows basierenden Container stehen und ob es überhaupt Interesse an einer Implementierung über Windows haben würde. Auf mich wartete eine Überraschung: Solomon fand die Idee eines Windows-Containers großartig! Würde das Unternehmen aber eine Implementierung über Windows in Betracht ziehen? Dieses Gespräch hat das Gesicht des Projekts komplett verändert. Solomon meinte einfach „Sie wissen, dass Docker Open Source ist. Sie können den Code hinzufügen, damit er unter Windows funktioniert, und wir helfen Ihnen dabei“. Und genau das haben wir gemacht. Seit damals ist John Howard, ein Software Engineer aus dem Hyper-V-Team, ein Verfechter des Docker-Projekts und tatsächlich auf Platz vier aller Codebeiträge aufgestiegen (bit.ly/2lAmaZX). Abbildung 1 zeigt die grundlegende Architektur von Containern und Docker für Windows und Linux.

Abbildung 1: Die grundlegende Architektur von Containern und Docker für Windows und Linux im Vergleich

Zusammenfassung

Vor vier Monaten haben wir bei Microsoft Ignite Windows Server 2016 vorgestellt und die Erweiterung unserer Partnerschaft mit Docker angekündigt. Dies bedeutet, dass eine kommerziell unterstützte Version des Docker-Moduls ohne zusätzliche Kosten für Windows Server-Kunden bereitgestellt werden wird. Seitdem ist ein Sturm von Aktivitäten losgebrochen. Kunden wie Tyco haben mit Docker und Windows Server-Container revolutioniert, wie sie Software erstellen und vorhandene Anwendungen modernisiert – alles mit der gleichen Plattform (bit.ly/2dWqIFM). In Visual Studio 2017 sind Tools für Windows- und Linux-Container vollständig integriert. Dies schließt F5-Debuggen ein. In Visual Studio Code ist Dockerfile und Unterstützung für Compose direkt integriert. Azure und die Containerdienste von Amazon haben beide Unterstützung für Windows Server-Container hinzugefügt. Weit mehr als eine Million auf Windows basierende Containerimages wurden mithilfe von Pull von Docker Hub abgerufen. Docker Datacenter ist weltweit die Plattform für Entwickler und Systemadministratoren zum Erstellen, Ausliefern und Ausführen verteilter Anwendungen., um End-to-End-Sicherheit und -Orchestrierung zu erzielen. Mit Docker verkürzen Organisationen die Anwendungsbereitstellung von Monaten auf Minuten, verschieben Arbeitsauslastungen reibungslos zwischen Datencentern und der Cloud und erzielen eine um das 20-fache gesteigerte Effizienz bei der Nutzung von Computingressourcen.

Als ich mit Containern anfing, wusste ich, dass dieses Projekt mit viel Stress verbunden sein würde. Ich war auf lange Nächte, Arbeitswochenenden und einen großen Kraftaufwand vorbereitet. Das war es aber wert, weil dieses Projekt Millionen von Entwicklern das schnellere Erstellen einer größeren Anzahl von Apps ermöglicht. Ich wusste andererseits auch, dass es viel Spaß machen würde und die Möglichkeit besteht, dass dieses Projekt die Art und Weise wirklich ändern kann, wie Benutzer Anwendungen unter Windows entwickeln und ausführen. Es hat mehr Spaß gemacht als ich jemals erwartet habe. Es war aber auch mehr Arbeit als angenommen. Trotzdem möchte ich diese Erfahrung gegen nichts eintauschen. Ich erinnere mich an ein Wochenende in einer frühen Phase des Projekts. Ich sah aus dem Fenster meines Büros, in dem ich an einem herrlichen sonnigen Sommertag arbeitete, und dachte mir „Ich kann nur hoffen, dass Entwickler mit diesem Kram arbeiten werden“…

Taylor Brownist ein Principal Program Management Lead in der Windows and Devices Group bei Microsoft. Als Mitglied des Windows-Basisengineeringteams ist er für die Windows Server Developer-Strategie verantwortlich. Sein Schwerpunkt liegt außerdem insbesondere auf Containertechnologien einschließlich Windows Server-Containern. Brown begann seine Laufbahn in Windows mit der Arbeit am 1394/Firewire-Stapel für Windows 2003. Anschließend arbeitete er an ACPI/Energieverwaltung für Windows Server 2003 SP1, bevor er zum neu gebildeten Team für virtuelle Computer stieß. Seit damals hat er seinen Beitrag zu jeder VM-Technologie von Microsoft einschließlich Virtual PC, Virtual Server und jeder Version von Hyper-V geleistet und sich einen Namen als Fachmann für Virtualisierungstechnologien gemacht. Sie erreichen Ihn unter taylorb@microsoft.com.

Unser Dank gilt dem folgenden technischen Experten für die Durchsicht dieses Artikels: David Holladay