Wann man Container unter Windows verwenden sollte und wann es sich nicht lohnt

Wenn Sie mit Windows-Anwendungen arbeiten und sich fragen, wann der Einsatz von Containern unter Windows sinnvoll ist und wann virtuelle Maschinen oder sogar Linux die bessere Wahl sind, sind Sie nicht allein. Es gibt immer mehr widersprüchliche Meinungen und sehr unterschiedliche Erfahrungen, insbesondere im Zusammenhang mit Windows Server-Containern.

In diesem Artikel gehen wir detailliert und praxisnah auf die Vorteile von Containern unter Windows ein , zeigen Ihnen, in welchen Szenarien sie ihre Stärken ausspielen, welche Einschränkungen sie haben und wie sie sich in Technologien wie Docker, Kubernetes, Azure und das übrige Microsoft-Ökosystem integrieren lassen. Ziel ist es, dass Sie am Ende des Artikels genau wissen, ob und mit welcher Herangehensweise sich eine Investition in Container für Ihre Projekte lohnt.

Was genau sind Container in Windows?

Ein Container in Windows ist im Wesentlichen ein leichtgewichtiges, isoliertes Paket, das eine Anwendung sowie alle Bibliotheken, Abhängigkeiten, Frameworks, Konfigurationsdateien und Benutzermoduskomponenten enthält, die sie zum Funktionieren benötigt und die auf dem Kernel des Host-Betriebssystems basieren.

Im Gegensatz zu einer virtuellen Maschine führt ein Container kein vollständiges Betriebssystem aus ; stattdessen nutzt er den Host-Kernel (Windows Server oder, in Entwicklungsszenarien, Windows 10/11). Er enthält jedoch ein „Basis-Image“ mit allen notwendigen Binärdateien und Benutzermodus-APIs, um der Anwendung die erwartete Umgebung bereitzustellen.

Durch diese Isolation sieht der Container ein teilweise oder vollständig virtualisiertes Dateisystem, eine virtualisierte Windows-Registrierung, virtualisierte Prozesse und virtualisierte Netzwerkressourcen . Änderungen, die innerhalb des Containers vorgenommen werden, gehen standardmäßig verloren, wenn dieser gestoppt oder gelöscht wird. Um die Daten dauerhaft zu speichern, können Sie Volumes oder externen Speicher (Azure Disks, Azure Files, SMB usw.) einbinden.

Dank dieses Modells starten und stoppen Windows-Container innerhalb weniger Sekunden, verbrauchen weitaus weniger Ressourcen als eine vollständige VM und ermöglichen eine wesentlich höhere Dichte an Workloads auf derselben Infrastruktur , was in Umgebungen mit hohem Bedarf und elastischer Skalierung von entscheidender Bedeutung ist.

Microsofts Container-Ökosystem

Microsoft hat ein umfangreiches Ökosystem rund um Container aufgebaut, das von der lokalen Entwicklung bis hin zu massiven Cloud-Bereitstellungen alles abdeckt. Der Clou: Windows- und Linux-Container lassen sich auf Windows-Systemen ausführen, abhängig vom gewählten Isolationsmodus und den verwendeten Tools.

In Windows 10- oder 11-Entwicklungsumgebungen ist Docker Desktop die gängigste Option, da es die Windows-Containerfunktionen integriert . Damit können Sie sowohl mit Linux-Containern (typischerweise mit WSL2 oder Hyper-V) als auch mit nativen Windows-Containern zum Testen und Debuggen arbeiten.

Für Entwicklungsteams bieten Visual Studio und Visual Studio Code eine ausgereifte Integration: Sie unterstützen Docker, Docker Compose , Kubernetes und Helm sowie Projektvorlagen, die sich ideal für die Containerisierung von .NET-, ASP.NET- und anderen Anwendungen eignen. Mit diesen IDEs lassen sich Images erstellen, lokal ausführen und sogar direkt in entfernte Registries übertragen.

Auf der Seite der Image-Registry können Sie zwischen Docker Hub und einer privaten Azure Container Registry wählen . Dadurch erhalten Sie einen vollständigen CI/CD-Workflow, in dem Ihre Pipelines Images auf Basis von Windows Server Core, Nano Server oder Windows erstellen, diese in die Registry hochladen und die verschiedenen Umgebungen (Entwicklung, Vorabversion, Produktion) diese Images von dort zur Bereitstellung abrufen.

Wenn Sie im großen Maßstab arbeiten müssen, dreht sich im Microsoft-Ökosystem alles um den Azure Kubernetes Service (AKS) und die Erweiterung von AKS auf lokale Umgebungen mit Azure Arc, Azure Stack Hub oder OpenShift. Obwohl Linux-Container die dominierende Plattform sind, unterstützt AKS Windows-Knoten für die Ausführung von Windows-Workloads in gemischten Kubernetes-Clustern und vereint so die Vorteile beider Welten.

Wie Windows-Container intern funktionieren

Im Hintergrund basiert ein Windows-Container auf denselben Grundprinzipien wie ein Linux-Container: Namensräume zur Isolation von Prozessen , Dateisystemen, Netzwerkressourcen und anderen Ressourcen sowie cgroup-ähnliche Mechanismen (oder Äquivalente) zur Steuerung der CPU-, Speicher- und sonstigen Ressourcennutzung. Die Implementierung ist unterschiedlich, das Ziel jedoch dasselbe.

Der Host-Kernel bildet die Grundlage; darauf aufbauend stellt ein Basis-Image die notwendigen Windows-Benutzermodus-Binärdateien bereit: Bibliotheken, Dienste, Laufzeitumgebungen und andere Komponenten, die die Anwendung als selbstverständlich voraussetzt. Somit ist das Basis-Image die grundlegende Schicht, auf der der Rest des Container-Images aufgebaut ist .

Images sind als Stapel unveränderlicher Schichten strukturiert: Jede Anweisung in der Dockerfile (Dateien kopieren, Abhängigkeiten installieren, Frameworks konfigurieren) fügt eine weitere Schicht hinzu. Beim Starten eines Containers bindet Docker oder containerd all diese Schichten im Lese-/Schreibmodus in eine beschreibbare oberste Schicht ein, in der temporäre Änderungen gespeichert werden.

Dieser geschichtete Ansatz ermöglicht die Wiederverwendung großer Systemblöcke in verschiedenen Containern. Wenn zehn Anwendungen auf demselben Windows Server Core-Image mit .NET Framework basieren, speichert der Host diese gemeinsamen Schichten nur einmal, und jeder Container fügt lediglich seine spezifische Komponente hinzu (Anwendungsdateien, Konfiguration usw.).

Wenn der Container Daten persistent speichern muss, werden üblicherweise Volumes eingebunden, die mit Festplatten, SMB-Freigaben oder Cloud-Speicherdiensten verknüpft sind. Dadurch kombinieren wir eine kurzlebige Laufzeitumgebung mit persistenten Daten und vermeiden, Geschäftsinformationen an den Lebenszyklus des Containers zu koppeln.

Container vs. Virtuelle Maschinen in Windows

Eine immer wiederkehrende Frage ist, ob Windows-Container virtuelle Maschinen vollständig ersetzen werden. Die kurze Antwort lautet: Nein. Es handelt sich um komplementäre Technologien , die unterschiedliche Probleme lösen, wobei Container in vielen Szenarien eine schlankere und flexiblere Alternative darstellen.

Eine VM führt ein vollständiges Betriebssystem mit eigenem Kernel, eigenen Diensten, Treibern und Software-Stack aus. Dies bietet eine sehr starke Isolation und ist ideal für anspruchsvolle Multi-Tenant-Umgebungen, stark regulierte Workloads oder Szenarien, in denen jeder Server als eine klar definierte und abgeschottete Einheit betrachtet werden soll.

Container hingegen nutzen den Host-Kernel. Dadurch lassen sie sich deutlich schneller starten und stoppen, sind wesentlich ressourcenschonender und ermöglichen ein flexibleres Ressourcenmanagement. Allerdings geht dies mit der gemeinsamen Nutzung eines kritischen Systembestandteils einher. Viele Cloud-Bereitstellungen kombinieren beide Ansätze: Containerisierung innerhalb virtueller Maschinen , wobei der Hypervisor Mandanten definiert und der Container-Orchestrator die Workloads innerhalb jeder VM organisiert.

In der Windows-Welt sind Container besonders interessant, wenn Anwendungen zuvor auf herkömmlichen virtuellen Windows-Maschinen ausgeführt wurden. In diesem Zusammenhang führt der Umstieg von VMs auf Container in der Regel zu deutlichen Verbesserungen hinsichtlich Dichte, Infrastrukturkosten, Bereitstellungsgeschwindigkeit und Automatisierungsmöglichkeiten mit DevOps-Pipelines.

Anders ausgedrückt: Wenn Sie aufgrund von Plattformanforderungen, Lizenzbestimmungen oder Abhängigkeiten bei Windows bleiben müssen, ist der naheliegende Schritt nicht, um jeden Preis zu Linux zu wechseln, sondern einen Teil Ihrer VM-Flotte durch Windows-Container zu ersetzen, sofern die Art der Anwendung dies zulässt.

Basis-Container-Images in Windows

Innerhalb des Microsoft-Ökosystems gibt es mehrere offizielle Basis-Images, die für verschiedene Anwendungstypen und Szenarien entwickelt wurden. Die Wahl des richtigen Basis-Images ist entscheidend, da sie die Größe, Kompatibilität und Leistung der Container beeinflusst.

Das generische Windows- Image enthält nahezu den kompletten Satz an System-APIs und -Diensten (ohne Serverrollen) und ist für Szenarien gedacht, in denen eine sehr breite Kompatibilität mit Desktop-Anwendungen oder bestimmten Windows-Komponenten erforderlich ist.

Das Windows Server- Image stellt das vollständige Serversystem mit allen typischen APIs der Windows Server-Umgebung bereit. Es bietet eine recht umfangreiche Basis, ermöglicht aber im Gegenzug die Entwicklung von Anwendungen, die einen klassischen Server voraussetzen und erweiterte APIs oder spezifische Bibliotheken nutzen.

Windows Server Core ist eine schlankere Version, die sich auf bestimmte Serverrollen konzentriert und über eine Befehlszeilenschnittstelle, aber keine klassische grafische Oberfläche verfügt. Sie enthält weiterhin die vollständige Version des .NET Frameworks und die gängigsten Rollen. Sie ist eine hervorragende Option, wenn Sie die Image-Größe reduzieren möchten, ohne dabei zu viele Kompatibilitätseinbußen hinnehmen zu müssen.

Nano Server ist das kleinste Image der Windows Server-Familie und wurde für moderne Workloads entwickelt. Es verfügt über keine grafische Benutzeroberfläche und ist für moderne .NET Core/.NET-Anwendungen sowie bestimmte Spezialaufgaben vorgesehen. Dieses Image eignet sich ideal für sehr schlanke Microservices, die nicht die vollen Ressourcen von Server Core benötigen.

Wann man Windows-Container verwenden sollte: klare Anwendungsfälle

Die entscheidende Frage lautet: In welchen Situationen ist der Einsatz von Windows-Containern sinnvoll, anstatt auf Linux umzusteigen oder bei herkömmlichen VMs zu bleiben? Bei Unternehmen, die sie bereits produktiv einsetzen und gute Ergebnisse erzielen, lassen sich einige wiederkehrende Muster beobachten.

Der erste wichtige Anwendungsfall betrifft eine ältere Anwendung im .NET Framework (oder einem anderen Stack, der nur Windows unterstützt), die Sie modernisieren möchten, ohne sie von Grund auf neu zu schreiben. Die Migration dieser Anwendung auf das moderne .NET Framework könnte aufgrund von Kosten und Risiken nicht realisierbar sein. Die Containerisierung in Windows Server Core oder Windows hingegen ermöglicht Ihnen Automatisierung, konsistente Bereitstellungen und Flexibilität, ohne den Code wesentlich zu verändern.

Ein weiteres typisches Szenario betrifft Anwendungen mit Windows-spezifischen Abhängigkeiten : COM+-Komponenten, ältere Bibliotheken, Integrationen mit Microsoft-Produkten, die nur unter Windows verfügbar sind, oder Sicherheits- und Authentifizierungsanforderungen, die an das Windows-Ökosystem gebunden sind. Wenn es für diese Komponenten keine direkten Linux-Entsprechungen gibt, ist es sinnvoll, die Systemschicht unter Windows zu belassen und sie in Containern zu verpacken.

Es gibt zudem viele Organisationen, deren System- und Betriebsteams fast ausschließlich Erfahrung mit Windows-Umgebungen haben. In diesen Fällen passt die Entscheidung für Windows-Container besser zu bestehenden Prozessen, Tools und Kenntnissen und reduziert die kulturellen Hürden bei der Einführung von DevOps- und Infrastructure-as-Code-Modellen.

Kurz gesagt: Wenn Ihre Anwendung aus technischen oder geschäftlichen Gründen unter Windows bleiben muss, bieten Windows-Container eine schlankere und besser automatisierbare Plattform als herkömmliche VMs . Es geht hier nicht um Konkurrenz zu Linux-Containern, sondern vielmehr darum, einen realistischen Modernisierungspfad für Windows-Workloads zu bieten, die nicht migriert werden können oder sollten.

Wenn Sie jedoch eine neue Anwendung von Grund auf entwickeln und keine Windows-Abhängigkeiten haben, ist es ratsam, die Entwicklung unter Linux mit modernen .NET- oder anderen plattformübergreifenden Sprachen ernsthaft in Betracht zu ziehen. In solchen Projekten sprechen die Beharrung des Ökosystems, die verfügbaren Tools und die Unterstützung durch die Hersteller eindeutig für Linux.

Vorteile für Entwickler: Warum Containerisierung unter Windows für Sie wichtig ist

Aus Sicht des Entwicklerteams dienen Windows-Container primär dazu, Reibungsverluste zwischen verschiedenen Umgebungen zu reduzieren. Das Problem, dass eine Anwendung „auf meinem Laptop, aber nicht auf meinem Desktop-PC funktioniert“, wird deutlich gemildert, wenn alle Umgebungen dasselbe Container-Image verwenden, das mit Containers International (CI) erstellt wurde.

Die Tatsache, dass jeder Container seine eigenen Bibliotheken, Laufzeitumgebungen und Abhängigkeiten enthält, verhindert, dass ein Host-Update einen Produktionsdienst beeinträchtigt. Die Anwendung läuft stets mit den in Ihrer Dockerfile und Ihrem Manifest deklarierten Bibliotheksversionen , ohne andere Anwendungen zu stören.

Darüber hinaus vereinfachen Container das Testen neuer Anwendungsversionen oder ihrer Abhängigkeiten erheblich , indem sie parallele Images erstellen, temporäre Umgebungen für QA- oder A/B-Tests starten und diese löschen, sobald sie nicht mehr benötigt werden. All dies wird mit sehr kurzen Startzeiten und ohne Anforderung neuer VMs aus der Infrastruktur erreicht.

Viele Entwickler nutzen Docker Desktop unter Windows 10/11 im täglichen Gebrauch, um ihre gesamte lokale Entwicklungsumgebung in Containern auszuführen : Datenbanken, Message Queues, Hilfs-APIs und die Anwendung selbst. Die Orchestrierung erfolgt dabei mit Docker Compose. Visual Studio und VS Code sind optimal in diesen Ansatz integriert und ermöglichen das direkte Debuggen von Windows-Containern.

Schließlich erleichtert die Containerisierung von Anfang an die Einführung von DevOps-Praktiken und CI/CD-Pipelines erheblich . Das Kompilieren der Anwendung, das Erstellen des Images, das Ausführen von Test-Suites in kurzlebigen Containern und, falls alles erfolgreich verläuft, das Deployment des neuen Images auf Kubernetes oder einer anderen Orchestrierungsplattform werden so zu einem relativ standardisierten Workflow.

Vorteile für Administratoren und Betriebsteams

Für IT- und Infrastrukturexperten ermöglichen Windows-Container den Wechsel von einem manuellen, serverbasierten Modell zu einem deklarativeren und wiederholbaren Ansatz. Anstatt Dutzende von Schritten zur Konfiguration einer VM zu dokumentieren, wird die Konfiguration explizit in den Image- und Orchestrator-Manifesten erfasst.

Dies vereinfacht Bereitstellungs-, Rollback- und Upgrade-Aufgaben: Wenn in einer neuen Version ein Problem auftritt, wird einfach das vorherige Image erneut bereitgestellt , und die Umgebung stellt ihren Zustand wieder her, ohne dass Änderungen manuell rückgängig gemacht oder VM-Snapshots wiederhergestellt werden müssen.

Die Containerdichte auf einem Windows Server-Host ist typischerweise deutlich höher als die von vollständigen virtuellen Maschinen, was zu einer besseren Auslastung von CPU, Arbeitsspeicher und Lizenzen führt . Für Cloud-Anbieter bedeutet dies in der Regel direkte Kosteneinsparungen.

Ein weiterer interessanter Aspekt ist die Verwendung von Containern als Werkzeug zur Fehlerbehebung. Sie können Container im interaktiven Modus mit verschiedenen Versionen von Befehlszeilentools, Agenten oder Diagnoseprogrammen ausführen, ohne das Host-Betriebssystem zu überlasten und ohne Versionskonflikte zu verursachen.

In Hybrid- oder Multi-Cloud-Umgebungen erleichtert die Verpackung von Windows-Anwendungen in Containern auch die Portabilität: Sie können Images zwischen lokalen Kubernetes-Clustern, AKS in Azure oder anderen Anbietern, die Windows-Knoten unterstützen, verschieben, ohne jede Umgebung von Grund auf neu aufbauen zu müssen.

Windows-Container-Orchestrierung

Beim Übergang von wenigen isolierten Containern zu einer Anwendung mit Dutzenden oder Hunderten von Diensten wird ein Orchestrator unerlässlich . Der Versuch, Skalierung, Neustarts, Updates und Netzwerkkommunikation in diesem Umfang manuell zu verwalten, ist unpraktisch.

Container-Orchestrierungsplattformen, allen voran Kubernetes, bieten Mechanismen, um den gewünschten Zustand der Anwendung (Replikate, Fehlertoleranz, Aktualisierungsregeln, Netzwerkrichtlinien) zu definieren und diesen Zustand im gesamten Cluster automatisch aufrechtzuerhalten . Fällt ein Knoten aus oder stürzt ein Container ab, erkennt die Orchestrierungsplattform dies und plant bei Bedarf neue Pods ein.

Zu den Funktionen dieser Orchestratoren für Windows-Workloads gehören Skalierbarkeit, intelligente Workload-Planung und die Zustandsüberwachung jedes einzelnen Dienstes. Sie können Verfügbarkeits- und Bereitschaftsprüfungen definieren, um zu steuern, wann ein Container bereit ist, Datenverkehr zu empfangen und wann er neu gestartet werden muss.

Sie übernehmen außerdem das Failover bei Knotenausfällen, die automatische Skalierung basierend auf dem CPU-Verbrauch oder benutzerdefinierten Metriken, die Verwaltung interner und externer Netzwerke sowie die Diensterkennung und das Traffic-Routing mithilfe von Ingress- oder LoadBalancer-Diensten.

Ein weiteres wichtiges Merkmal ist die Möglichkeit, Updates ohne Ausfallzeiten zu koordinieren : Rolling Deployments, Blue-Green Deployments, Canary Deployments usw. Dadurch können Sie neue Versionen Ihrer Windows-Container kontrolliert einführen, Risiken minimieren und bei Auftreten eines kritischen Fehlers schnell zurückrollen.

Container-Isolationsmodi in Windows

Windows bietet im Vergleich zu Linux einen wichtigen Unterschied: Es gibt zwei Hauptisolationsmodi für Container, jeder mit seinen eigenen Vor- und Nachteilen. Diese zu verstehen ist entscheidend, um zu entscheiden, wie Sie Ihre Container je nach gewünschtem Sicherheits- und Kompatibilitätsniveau betreiben.

Der Prozessisolationsmodus entspricht am ehesten dem klassischen Containermodell in Linux. In diesem Modus teilen sich Container den Host-Kernel direkt, wobei prozessbasierte Isolationsmechanismen unterschiedliche Arbeitslasten voneinander trennen.

Dieser Modus bietet typischerweise hervorragende Leistung und sehr geringen Ressourcenverbrauch , allerdings ist die Isolation im Vergleich zum VM- oder Hyper-V-Modus nicht so stark. Ein Kernelfehler betrifft Host und Container gleichermaßen und umgekehrt.

Der andere Modus ist die Isolation unter Hyper-V . In diesem Fall läuft jeder Container tatsächlich in einer schlanken Mini-VM mit eigenem Kernel, obwohl die Benutzererfahrung dieselbe ist wie bei einem normalen Container.

Der Vorteil dieses Ansatzes liegt in der deutlich verstärkten Isolation , sowohl zwischen Host und Containern als auch zwischen den Containern selbst. In manchen Szenarien verbessert er zudem die Kompatibilität, allerdings auf Kosten eines etwas höheren Ressourcenverbrauchs und einer etwas längeren Startzeit im Vergleich zum reinen Prozessmodus.

Einschränkungen und Anwendungen, die nicht in Windows-Container passen

Nicht alle Workloads eignen sich für die Containerisierung unter Windows. Es gibt Dienste und Anwendungstypen, die derzeit nicht unterstützt werden oder für die eine Containerisierung nicht sinnvoll ist , entweder aufgrund technischer Beschränkungen oder der Art der erforderlichen Interaktion.

Beispielsweise wird die Ausführung von Diensten wie Microsoft Distributed Transaction Coordinator (MSDTC) in Windows-Containern derzeit nicht unterstützt , da diese ein komplexes Betriebsmodell aufweisen und eng mit dem Hostsystem verknüpft sind.

Dasselbe gilt für Anwendungen wie Microsoft Office und andere Produktivitätssuiten für Endbenutzer, bei denen die grafische Benutzeroberfläche und die Desktop-Umgebung wesentliche Bestandteile des Produkts sind. Client-Anwendungen mit aufwendigen Benutzeroberflächen, die eine vollständige Desktop-Umgebung voraussetzen, passen ebenfalls nicht gut.

Im Infrastrukturbereich ist es derzeit ebenfalls nicht möglich, Rollen wie Domänencontroller, DNS-Server, DHCP-Server , Druckserver, Dateiserver oder bestimmte Zeitsynchronisierungs- und Identitätsverwaltungsdienste in Containern auszuführen. Diese Rollen sind weiterhin für den direkten Betrieb auf Servern (physisch oder virtuell) konzipiert.

Generell gilt die Faustregel, dass Container für Backend-Dienste, APIs, Webanwendungen, Worker, Hintergrundprozesse und ähnliche Komponenten gedacht sind, vorzugsweise ohne oder mit einer minimalen webbasierten Benutzeroberfläche. Benötigt die Anwendung spezielle Hardwaretreiber oder eine sehr geringe Systemintegration, ist eine virtuelle Maschine (VM) wahrscheinlich immer noch die beste Option.

Vergleich von Windows- und Linux-Containern

Der Großteil des Container-Ökosystems entstand und entwickelte sich zunächst unter Linux. Docker, Kubernetes, die meisten offiziellen Images und ein Großteil der Tools konzentrierten sich traditionell auf die Linux-Welt, die bei der Akzeptanz und Unterstützung durch Cloud-Anbieter führend war.

Das bedeutet, dass Linux hinsichtlich Imagegröße, Tool-Ökosystem, verfügbaren Beispielen und Anzahl tatsächlicher Workloads im Vorteil ist . Es ist einfacher, fertige Images für nahezu alles unter Linux zu finden, von Datenbanken über Proxys bis hin zu Messaging-Diensten.

Dennoch haben Windows-Container den Abstand verringert. Heute lassen sich Windows-Container nativ auf Windows-Hosts ausführen , und Linux-Container können auf denselben Hosts mithilfe von WSL2- oder Hyper-V-Isolation mit zunehmend besserer Integration genutzt werden.

Die Kompatibilität zwischen den Systemen ist nicht vollständig: Ein Linux-Host kann Windows-Container nicht nativ ausführen, und ein Windows-Host kann Linux-Container nicht nativ ohne eine Zwischenschicht wie Hyper-V oder WSL2 ausführen. Daher ist es in Produktionsumgebungen üblich, Linux-Knoten für Linux-Workloads und Windows-Knoten für Windows-Workloads im selben Kubernetes-Cluster zu verwenden.

Daher ist der übliche Ansatz einfach: Läuft Ihre Anwendung reibungslos unter Linux, ist es sinnvoll, die Reife des Linux-Ökosystems zu nutzen. Setzt Ihr Unternehmen jedoch auf Windows-Technologien, bietet der Einsatz von Windows-Containern anstelle von VMs deutliche Verbesserungen , auch wenn das Ökosystem etwas kleiner ist.

Docker-Installation und erste Schritte auf einem Windows Server

Um mit Containern auf Windows Server (2016, 2019, 2022 und später) zu arbeiten, besteht der typische Workflow darin, die Containerrolle oder das Container-Feature und eine kompatible Laufzeitumgebung zu installieren, in der Regel Docker Engine oder containerd, abhängig von der Produktionsstrategie, die Sie verfolgen.

In vielen Fällen wird Docker über den DockerMsftProvider in PowerShell installiert. Dazu wird das entsprechende Modul aus der PowerShell-Galerie hinzugefügt und anschließend die Installation des Docker-Pakets über diesen Provider angefordert.

Nach der Installation müssen Sie den Server neu starten, damit alle Container-Laufzeitkomponenten korrekt registriert werden und die Container-Funktion aktiviert wird. Anschließend können Sie den Paketstatus überprüfen und Befehle wie `docker version` oder `docker info` verwenden, um die Konfiguration zu verifizieren.

Wenn Sie Docker auf diesem Server später aktualisieren möchten, können Sie zum selben Anbieter zurückkehren und angeben, dass die Paketaktualisierung erzwungen werden soll. Dadurch bleibt die Engine mit den für die verwendeten Images und Orchestratoren erforderlichen Versionen kompatibel.

Unter Windows 10/11 im Entwicklermodus ist die einfachste Methode in der Regel die Installation von Docker Desktop über den grafischen Installer . Dadurch können bei Bedarf Hyper-V- oder WSL2-Funktionen aktiviert werden. Anschließend konfigurieren Sie einfach, ob Sie das WSL2- oder Hyper-V-Backend verwenden möchten, und wechseln je nach Bedarf zwischen Linux- oder Windows-Containern.

Praktisches Beispiel: ein Webcontainer in Windows

Ein sehr anschauliches Beispiel zum Verständnis der Dynamik ist die Erstellung eines Containers mit einer einfachen Webanwendung auf IIS unter Windows Server Core . Der grundlegende Ablauf umfasst die Erstellung einer Dockerfile, eines Images und eines oder mehrerer darauf basierender Container.

Zuerst erstellen Sie ein Arbeitsverzeichnis auf dem Server und darin eine Datei namens Dockerfile (ohne Dateiendung). Diese Datei enthält die Anweisungen für Docker, welches Basis-Image verwendet werden soll und welche Schritte beim Erstellen des neuen Images ausgeführt werden müssen .

In der Dockerfile legen Sie beispielsweise fest, dass das Basis-Image eine Windows Server Core-Vorlage mit bereits aus der offiziellen Microsoft-Registry installiertem IIS sein soll, dass beim Start des Containers PowerShell ausgeführt werden soll und dass eine index.html-Datei vom Host in den Standard-IIS-Webordner innerhalb des Containers kopiert werden soll.

Als Nächstes erstellen Sie die Datei index.html mit einer einfachen „Hello World“-Seite. Sobald sich beide Dateien (Dockerfile und index.html) im selben Ordner befinden, führen Sie einen Docker-Build mit einem Tag wie beispielsweise „webserver“ durch , der auf das aktuelle Verzeichnis verweist. Die Engine lädt das Basis-Image von Windows Server Core mit IIS herunter, falls dieses noch nicht vorhanden ist, und wendet Ihre Anweisungen an.

Sobald das Image erstellt ist, können Sie die verfügbaren Images auflisten und Ihren ersten Container mit dem Befehl docker run starten, ihm einen Namen geben, ihn im Hintergrund ausführen lassen und die Ports zwischen dem Port 80 des Containers und dem Port 80 des Hosts zuordnen.

Wenn Sie nun einen Browser öffnen und sich mit localhost verbinden, greifen Sie auf IIS innerhalb des Containers zu, nicht auf den Host, und sehen die kopierte HTML-Seite. Sie können einen zweiten Container aus demselben Image erstellen und diesmal Port 8080 des Hosts auf Port 80 des Containers abbilden. So erhalten Sie zwei unabhängige Instanzen, die unterschiedliche Inhalte vom selben Rechner bereitstellen.

All dies wird erreicht, ohne IIS direkt auf dem Host zu installieren, zusätzliche VMs zu erstellen oder jeder Instanz festen Arbeitsspeicher zuzuweisen. Container nutzen nur die benötigten Ressourcen, werden innerhalb von Sekunden erstellt und gelöscht und ermöglichen die konfliktfreie Koexistenz mehrerer Versionen derselben Anwendung.

Kurz gesagt, sind Container in Windows ein sehr leistungsstarkes Werkzeug, wenn es darum geht, Anwendungen zu modernisieren, die das Windows-Ökosystem nicht verlassen können: Sie bieten eine leichtgewichtige, reproduzierbare und einfach zu automatisierende Umgebung, verbessern klassische virtuelle Maschinen deutlich in Geschwindigkeit und Dichte, ermöglichen die Einführung von DevOps-Praktiken und Orchestratoren wie Kubernetes und bieten, obwohl sie Linux nicht dort ersetzen, wo es am besten geeignet ist, eine realistische und ausgereifte Möglichkeit, vielen kritischen Windows-basierten Workloads ein zweites Leben zu schenken.