Definition

Windows-Container

Was sind Windows-Container?

Windows-Container bieten abstrahierte, isolierte, leichtgewichtige und portable Betriebsumgebungen für die Anwendungsentwicklung auf einem einzigen System. Diese Umgebungen erleichtern Entwicklern das Entwickeln, Bereitstellen, Ausführen und Verwalten ihrer Anwendungen und Anwendungsabhängigkeiten, sowohl in lokalen Umgebungen als auch in der Cloud.

Ein Container ist eine logische Umgebung, die auf einem Computer erstellt wird und in der eine Anwendung ausgeführt werden kann. Container und Gastanwendungen sind von den Hardwareressourcen des Host-Computers abstrahiert und auch logisch von anderen Containern isoliert. Da sie nicht auf einer separaten Hypervisor-Schicht basieren, sondern vom zugrunde liegenden Betriebssystem unterstützt werden, unterscheiden sich Container von virtuellen Maschinen (VMs).

Um Unternehmensanwendungen zu verpacken und auszuführen, sind Windows-Container nützlich. Sowohl Windows- als auch Linux-Betriebssysteme werden unterstützt. Container können schnell gestartet und gestoppt werden, da sie leichtgewichtig und schnell sind. Das macht sie ideal für die Entwicklung von Anwendungen, die sich schnell an wechselnde Anforderungen anpassen und vergrößern oder verkleinern lassen. Sie sind auch nützlich, um die Nutzung und Dichte der Infrastruktur zu optimieren.

Windows-Container eignen sich für die Entwicklung aller Arten von Anwendungen, einschließlich Monolithen und Microservices. Diese Anwendungen können in jeder Sprache entwickelt – einschließlich Python, Java und .NET – und sowohl in lokalen als auch in Cloud-Umgebungen ausgeführt werden.

Virtuelle Maschinen versus Container
Abbildung 1: Während virtuelle Maschinen Anwendungen isolieren – jede mit einem eigenen Betriebssystem – sind Container eine Isolationstechnologie auf Betriebssystemebene.

Wie funktionieren Windows-Container?

Container werden von einem Container-Host-System erstellt, das steuert, wie viele seiner Ressourcen von einzelnen Containern genutzt werden können. Beispielsweise kann so die CPU-Nutzung auf einen bestimmten Prozentsatz begrenzt werden, den Anwendungen nicht überschreiten dürfen. Außerdem stellt der Host jedem Container einen virtualisierten Namensraum (Namespace) zur Verfügung, der nur den Zugriff auf die Ressourcen gewährt, die der Container benötigt. Dieser eingeschränkte Zugriff stellt sicher, dass der Container sich so verhält, als wäre er die einzige Anwendung, die auf dem System läuft.

Es ist nicht notwendig, für jeden Container eine eigene Betriebssysteminstanz zu installieren: alle Container auf einem System bauen auf demselben Betriebssystem-Kernel auf und nutzen diesen gemeinsam. Jeder Container erhält keinen vollständigen Zugriff auf den Kernel, sondern nur eine isolierte oder virtualisierte Sicht auf das System. Das heißt er kann auf eine virtualisierte Version des Dateisystems und der Registrierung des Betriebssystems zugreifen. Änderungen an diesen Elementen wirken sich nur auf diesen Container aus.

APIs und Dienste, die eine Anwendung zur Ausführung benötigen, werden von Systembibliotheken und nicht vom Kernel bereitgestellt. Bei diesen Bibliotheken handelt es sich um Dateien, die oberhalb des Kernels im Benutzermodus laufen und in einem Container- oder Basis-Image verpackt sind. Um einen Container zu erstellen, sind Container-Images erforderlich. Die Anwendung läuft, wenn das Image auf einem Host-System mit einer kompatiblen Containerplattform wie Docker bereitgestellt wird, ohne dass andere Komponenten auf dem Host installiert oder aktualisiert werden müssen.

Durch die Kombination aus Virtualisierung und Container-Image sind Container sehr portabel und autark. Ohne Änderungen am Image vornehmen zu müssen, können Entwickler dank dieser Eigenschaften Anwendungen erstellen, testen und in der Produktion einsetzen. Um größere Anwendungen mit einer Microservices-Architektur zu erstellen, können sie auch mehrere Container miteinander verbinden. Diese Anwendungen sind skalierbar und bestehen aus Blöcken oder Funktionen, die über APIs miteinander kommunizieren.

Docker Stack
Abbildung 2: Ein Container-Stack wie Docker läuft auf dem Host-Betriebssystem, zum Beispiel Windows, mit Host-Ressourcen.

Microsoft Containerökosystem

Es ist einfach, mit dem umfangreichen Containerökosystem von Microsoft Container zu entwickeln und einzusetzen. Docker Desktop ist ein Teil dieses Ökosystems und praktisch, um Windows oder Linux Container auf Windows 10 zu entwickeln und zu testen.

Alle Anwendungen können als Container-Image im öffentlichen Docker Hub oder in einer privaten Azure Container Registry veröffentlicht werden. Microsoft-Tools wie Visual Studio und Visual Studio Code unterstützen Container und Technologien wie Docker und Kubernetes, um Windows-Container zu entwickeln, zu testen, zu veröffentlichen und bereitzustellen.

Container können in großem Umfang On-Premises oder in der Cloud bereitgestellt werden. Für die Bereitstellung in Azure oder anderen Clouds ist ein Orchestrator wie Azure Kubernetes Service (AKS) nützlich, nachdem das Container-Image aus der einer Container-Registry gezogen wurde. Für die Bereitstellung vor Ort kann AKS auf Azure Stack HCI, Azure Stack mit der AKS Engine oder Azure Stack Hub mit OpenShift verwendet werden.

Windows-Containerabbilder

Das Windows-Container Image ist eine Datei oder ein Paket, das die eigene Kopie aller Systemdateien des Benutzermodus des Containers enthält. Enthalten sind Details der Anwendung, Daten, Betriebssystembibliotheken sowie alle Abhängigkeiten und verschiedene Konfigurationsdateien, die für den Betrieb der Anwendung erforderlich sind. Das Image kann in einem lokalen, öffentlichen oder privaten Container-Repository gespeichert werden.

Microsoft stellt die folgenden Basis-Images zur Verfügung, die Entwickler verwenden, um ihre eigenen Windows-Container-Images zu erstellen:

  • Windows ist das vollständige Windows-Basis-Image und enthält alle Bibliotheken, APIs und Systemdienste mit Ausnahme der Serverrollen.
  • Windows Server enthält einen vollständigen Satz von Windows APIs und Systemdiensten. Es entspricht einer vollständigen Installation von Windows Server.
  • Windows Server Core ist kleiner und enthält eine Teilmenge der APIs, Bibliotheken und Dienste, die in Windows Server Core enthalten sind. Es enthält viele, aber nicht alle Serverrollen.
  • Nano Server ist das kleinste Windows Basis Image in Bezug auf die Größe des Images und die Anzahl der Bibliotheken und Dienste. Es enthält Unterstützung für die ASP.NET Core APIs und einige Serverrollen.

Windows- und Linux-Containerplattform

Die Windows- und Linux-Containerplattform umfasst zahlreiche Tools:

  • Containernerd wurde in Windows Server 2019 und Windows 10 Version 1809 eingeführt und ist ein Daemon, der den gesamten Lebenszyklus von Containern verwaltet. Verwendet wird er zum Herunterladen und Entpacken des Container-Images sowie zum Ausführen und Überwachen von Containern.
  • Runhcs ist ein Windows-Container-Host und eine Abspaltung von runc. Der Runhcs-Kommandozeilen-Client wird verwendet, um Anwendungen auszuführen, die gemäß der Format- und Laufzeitspezifikation der Open Container Initiative (OCI) gepackt wurden. Er läuft unter Windows und kann neben Windows- und Linux-Hyper-V-Isolation und Windows-Prozesscontainer noch weitere Containertypen ausführen.
  • HCS ist eine C-Sprach-API mit zwei verfügbaren Wrappern, die eine Schnittstelle zu HCS bilden und es von höheren Sprachen aus aufrufen können. Ein Wrapper ist hcsshim, der die Grundlage für runhcs bildet. Der andere ist dotnet-computevirtualization, der in C# geschrieben ist.

Virtuelle Maschinen versus Windows-Container

VMs und Container sind komplementäre, aber unterschiedliche Technologien. Eine VM führt ein komplettes Betriebssystem einschließlich eines eigenen Kernels aus, weshalb sie mehr Systemressourcen wie Arbeitsspeicher und Speicherplatz benötigt. Container bauen im Gegensatz dazu auf dem Kernel des Host-Betriebssystem auf und enthalten nur Anwendungen, APIs und Dienste, die im Benutzermodus ausgeführt werden. Daher benötigen sie weniger Systemressourcen.

Ein weiterer Unterschied besteht darin, dass in einer VM jedes beliebige Betriebssystem ausgeführt werden kann, während in Containern zwangsläufig dasselbe Betriebssystem und dieselbe Betriebssystemversion wie auf dem Host laufen. Da die VM vollständig vom Host-Betriebssystem und anderen VMs isoliert ist, bietet sie auch eine stärkere Sicherheitsabgrenzung. Container bieten nur eine leichte Isolierung gegenüber dem Host und anderen Containern. Indem Sie jeder Container in einer leichtgewichtigen VM mit dem Hyper-V-Isolationsmodus isolieren, erhöht sich die die Sicherheit von Windows-Containern jedoch.

Weitere wichtige Unterschiede zwischen VMs und Windows-Containern:

  • Einzelne VMs werden über das Windows Admin Center oder den Microsoft Hyper-V Manager bereitgestellt, während einzelne Container mit Docker bereitgestellt werden.
  • Mit PowerShell oder System Center Virtual Machine Manager werden mehrere VMs bereitgestellt. Mehrere Container lassen sich am besten mit einem Orchestrator wie AKS bereitstellen. Der unterstützt die Verwaltung von Containern im großen Maßstab und bietet zum Beispiel Funktionen für Workload Scheduling, Zustandsüberwachung, Networking und Service Discovery.
  • Eine einzelne VM nutzt für die lokale dauerhafte Speicherung eine virtuelle Festplatte, während ein einzelner Containerknoten Azure Disks verwendet.
  • Zum Lastausgleich schieben Sie laufende VMs auf andere VMs in einem Failover Cluster. Um Container in Reaktion auf Laständerungen zu starten oder zu stoppen, ist ein Orchestrator erforderlich.
  • VMs verwenden virtuelle Netzwerkadapter, während Container eine isolierte Ansicht eines virtuellen Netzwerkadapters verwenden und die Firewall des Hosts mit anderen Containern teilen.
Diese Definition wurde zuletzt im Oktober 2023 aktualisiert

Erfahren Sie mehr über Serverbetriebssysteme