Verwenden von Windows-Containern zum Containerisieren vorhandener Anwendungen

  • Artikel

Gilt für: Windows Server 2022, Windows Server 2019, Windows Server 2016

Windows-Container bieten einen hervorragenden Mechanismus zur Modernisierung herkömmlicher oder älterer Anwendungen. Dieser Ansatz wird zwar bisweilen als Lift & Shift-Migration zu Containern bezeichnet, die Lift & Shift-Metapher geht allerdings auf die Verlagerung von Workloads von physischen auf virtuelle Computer zurück und wurde in letzter Zeit verwendet, um die Migration von Workloads im Ist-Zustand zur (privaten oder öffentlichen) Cloud zu beschreiben. Heutzutage wird der Begriff für die Migration virtueller Computer (virtual machines, VMs) verwendet, was passender ist. Container sind jedoch keine virtuellen Computer. Wenn Container als virtuelle Computer betrachtet werden, kann dies zu Verwirrungen führen – sowohl bei der Frage, wie eine Anwendung containerisiert werden kann, als auch bei der Frage, ob sie überhaupt containerisiert werden kann (oder sollte).

Dieses Thema enthält praktische Informationen zur Migration herkömmlicher Anwendungen zu Windows-Containern. Hier werden vorab besondere Überlegungen erläutert, um Ihnen dabei zu helfen, die zu containerisierenden Anwendungen zu priorisieren.

Einführung

Was sind Windows-Container (und was sind sie nicht)?

Der generische Begriff „Container“ bezieht sich auf eine Technologie zur Virtualisierung des Betriebssystems (Operating System, OS). Diese Virtualisierung bietet eine gewisse Isolation vom Betriebssystem des Servers/Hosts, was wiederum mehr Agilität für Anwendungsentwickler und Betriebsteams bedeutet.

Windows-Container sind eine spezielle Implementierung der Containertechnologie. Sie bieten Instanzen virtualisierter Betriebssysteme, die vom Windows-Betriebssystem isoliert sind. Eine vollständige gegenseitige Abhängigkeit zwischen Container und Host ist jedoch nicht möglich: Ein Windows-Container muss seinen Ressourcen- und Funktionsbedarf mit dem Windows-Betriebssystem koordinieren. Warum ist dies wichtig? Weil ein Windows-Container kein vollständiger virtualisierter Server ist und einige der Dinge, für die Sie eine Anwendung ggf. verwenden möchten, nicht möglich sind, wenn nur ein virtualisiertes Betriebssystem verwendet wird.

Weitere Informationen zu diesem Thema finden Sie unter Container im Vergleich zu virtuellen Computern. Im Anschluss haben wir einige der Punkte zusammengefasst, die Ihnen bei der Unterscheidung zwischen Containern und virtuellen Computern helfen:

  • Container sind keine äquivalente Lösung zur Virtualisierung von Desktopanwendungen. Sie unterstützen nur serverseitige Anwendungen, die keine interaktive Sitzung erfordern. Da sie auf spezialisierten Containerimages basieren, unterstützen sie nur Anwendungen, die kein grafisches Front-End benötigen.
  • Container sind naturgemäß kurzlebig. Das bedeutet, dass standardmäßig kein Mechanismus zum Speichern des Zustands einer Containerinstanz vorhanden ist. Wenn eine Instanz ausfällt, wird sie durch eine andere Instanz ersetzt.

Die Containertechnologie hat Ihren Ursprung unter Linux. Daraus entwickelte sich Docker als Standard. Microsoft hat eng mit Docker zusammengearbeitet, um sicherzustellen, dass Container unter Windows möglichst ähnlich funktionieren. Inhärente Unterschiede zwischen Linux und Windows können wie Einschränkungen von Windows-Containern erscheinen, sind aber eigentlich nur Unterschiede zwischen Linux und Windows. Andererseits bieten Windows-Container einige besondere Implementierungen wie etwa Hyper-V-Isolation, die später noch behandelt werden. Dieses Thema hilft Ihnen dabei, die Unterschiede zu verstehen, und Sie erfahren, wie Sie ihnen Rechnung tragen.

Vorteile der Verwendung von Containern

Ähnlich wie beim Ausführen mehrerer virtueller Computer auf einem einzelnen physischen Host können auch mehrere Container auf einem einzelnen physischen oder virtuellen Host ausgeführt werden. Anders als bei virtuellen Computern müssen Sie jedoch das Betriebssystem für einen Container nicht verwalten. Dadurch erhalten Sie die Flexibilität, sich auf die Anwendungsentwicklung und auf die zugrunde liegende Infrastruktur zu konzentrieren. Es bedeutet auch, dass Sie eine Anwendung isolieren können, damit sie von allen anderen Prozessen, die vom Betriebssystem unterstützt werden, unberührt bleibt.

Container bieten eine einfache Methode zum Erstellen und dynamischen Beenden der Ressourcen, die für eine funktionierende Anwendung erforderlich sind. Es ist zwar möglich, virtuelle Computer zu erstellen und bereitzustellen, wenn der Anwendungsbedarf zunimmt, die Verwendung von Containern ermöglicht jedoch schnelleres horizontales Skalieren. Außerdem ermöglichen Container im Falle eines Absturzes oder einer Hardwareunterbrechung einen schnelleren Neustart. Mithilfe von Containern lässt sich jede App mit nur minimalen oder ganz ohne Codeänderungen von der Entwicklung in die Produktion überführen, da die Container Anwendungsabhängigkeiten enthalten, damit sie in allen Umgebungen funktionieren. Die Möglichkeit, eine vorhandene Anwendung dank Docker-Integration in Microsoft-Entwicklertools mit minimalen Codeänderungen containerisieren zu können, ist auch ein wichtiger Faktor bei der Anwendungsentwicklung und -pflege.

Einer der wichtigsten Vorteile der Verwendung von Containern ist jedoch die zusätzliche Agilität bei der App-Entwicklung, da verschiedene Versionen einer App ohne Ressourcenkonflikte auf dem gleichen Host ausgeführt werden können.

Eine umfassendere Liste der Vorteile, die sich durch die Verwendung von Containern für vorhandene Anwendungen ergeben, finden Sie auf der Seite mit der Dokumentation zu Microsoft .NET.

Wichtiges Konzept der Isolationsstufe

Windows-Container ermöglichen die Isolation vom Windows-Betriebssystem. Diese Isolation ist sowohl bei der App-Erstellung als auch beim Testen und beim Hochstufen einer App für die Produktion von Vorteil. Es ist jedoch wichtig, zu verstehen, wie die Isolation erreicht wird, wenn Sie erwägen, eine Anwendung zu containerisieren.

Windows-Container bieten zwei verschiedene Modi der Runtimeisolation: Prozessisolation und Hyper-V-Isolation. Container werden in beiden Modi auf die gleiche Weise erstellt und funktionieren auch gleich. Was sind also die Unterschiede, und warum sind sie relevant? Bei der Prozessisolation werden mehrere Container auf einem einzelnen Host gleichzeitig isoliert ausgeführt. Erreicht wird dies durch Namespaces, Ressourcensteuerung und andere Features. Container im Prozessisolationsmodus teilen sich den gleichen Kernel – sowohl untereinander als auch mit dem Host. Dies entspricht in etwa der Funktionsweise von Linux-Containern.

Bei der Hyper-V-Isolation werden ebenfalls mehrere Container gleichzeitig auf einem einzelnen Host ausgeführt. Die Container befinden sich allerdings auf hoch optimierten virtuellen Computern, von denen jeder im Grunde seinen eigenen Kernel erhält. Dieser virtuelle Computer (im Grunde ein virtueller Hilfscomputer) ermöglicht eine Isolation auf Hardwareebene zwischen den einzelnen Containern und dem Containerhost.

Der Hyper-V-Isolationsmodus ist fast so etwas wie eine Mischung aus virtuellem Computer und Container und bietet eine zusätzliche Sicherheitsebene, die besonders hilfreich ist, wenn Ihre App Mehrinstanzenfähigkeit benötigt. Die Verwendung des Hyper-V-Isolationsmodus hat allerdings auch potenzielle Nachteile:

  • Längere Startzeit für den Container und wahrscheinliche Auswirkungen auf die gesamte App-Leistung.
  • Nicht alle Tools funktionieren nativ mit Hyper-V-Isolation.
  • Die Hyper-V-Isolation wird derzeit weder von Azure Kubernetes Service (AKS) noch von AKS in Azure Stack HCI unterstützt.

Weitere Informationen zur Implementierung der beiden Isolationsmodi finden Sie im Thema Isolationsmodi. Wenn Sie erstmals eine App containerisieren, müssen Sie sich für einen der beiden Modi entscheiden. Glücklicherweise kann nachträglich sehr einfach zwischen den Modi gewechselt werden, da dazu weder Änderungen an der Anwendung noch Änderungen am Container erforderlich sind. Beachten Sie allerdings, dass die Entscheidung für einen der beiden Modi einer der ersten Schritte bei der Containerisierung einer App ist.

Containerorchestrierung

Die Möglichkeit, mehrere Container auf einem einzelnen Host oder auf mehreren Hosts ausführen zu können, ohne sich Gedanken über die Betriebssystemverwaltung machen zu müssen, sorgt für ein hohes Maß an Flexibilität und unterstützt Sie bei der Umstellung auf eine Microservice-basierte Architektur. Ein Nachteil dieser Flexibilität ist jedoch, dass es bei einer auf Containern und Microservices basierenden Umgebung schnell passieren kann, dass die Anzahl der Einzelkomponenten überhandnimmt. Glücklicherweise ist gibt es einen Containerorchestrator, der sich unter anderem um Aspekte wie die Verwaltung des Lastenausgleichs, Hochverfügbarkeit, Containerzeitplanung und Ressourcenverwaltung kümmert.

Der Name „Orchestrator“ ist vielleicht nicht ganz passend. Sie koordinieren die Aktivitäten mehrerer Container, um einen harmonischen Ablauf zu gewährleisten, und gleichen somit eher dem Dirigenten eines Orchesters. In gewissem Sinne behandeln sie die Planung und Ressourcenzuordnung für Container auf eine Weise, die mit der Funktionsweise eines Betriebssystems vergleichbar ist. Wenn Sie also dazu übergehen, Anwendungen zu containerisieren, müssen Sie sich zwischen den Orchestratoren entscheiden, die Windows-Container unterstützen. Einige der gängigsten Orchestratoren sind Kubernetes und Docker Swarm.

Was kann nicht zu Windows-Containern migriert werden?

Wenn Sie überlegen, ob eine App containerisiert werden kann, ist es wahrscheinlich am einfachsten, mit der Liste der Faktoren zu beginnen, die Windows-Container als Option ausschließen.

In der folgenden Tabelle sind die Arten von Apps zusammengefasst, die nicht zu Windows-Containern migriert werden können, und es ist jeweils angegeben, warum dies nicht möglich ist. Die Gründe werden in den Unterabschnitten im Anschluss an die Tabelle ausführlicher erläutert. Wenn Sie die Gründe für diese Einschränkungen verstehen, können Sie besser nachvollziehen, was Container wirklich sind und was sie von virtuellen Computern unterscheidet. Dadurch können Sie die Funktionen von Windows-Containern besser bewerten, die Sie mit den vorhandenen containerisierbaren Apps nutzen können.

Hinweis: Die folgende Liste ist nicht vollständig. Es handelt sich vielmehr um eine Zusammenstellung von Apps, für die Kunden versucht haben, eine Containerisierung durchzuführen.

Nicht unterstützte Anwendungen/Features Grund Umgehung möglich?
Anwendungen, die einen Desktop erfordern Container unterstützen keine grafische Benutzeroberfläche (Graphical User Interface, GUI) Wenn die Anwendung nur eine grafische Benutzeroberfläche für die Installation benötigt, lässt sich das Problem möglicherweise durch eine automatische Installation umgehen.
Anwendungen mit Remotedesktopprotokoll (RDP) RDP wird für interaktive Sitzungen verwendet. Daher gilt das oben genannte Prinzip auch hier. Als Alternative zur Remoteverwaltung kann möglicherweise Windows Admin Center (WAC) oder Remote PowerShell verwendet werden.
Zustandsbehaftete Anwendungen Container sind kurzlebig. Ja. Bei manchen Anwendungen sind ggf. minimale Änderungen erforderlich, damit sie keine Daten oder Zustände im Container speichern.
Datenbankanwendungen Container sind kurzlebig. Ja. Bei manchen Anwendungen sind ggf. minimale Änderungen erforderlich, damit sie keine Daten oder Zustände im Container speichern.
Active Directory Das Design und der Zweck von Active Directory schließen die Ausführung in einem Container aus. Nein. Apps, die von Active Directory abhängig sind, können jedoch gruppenverwaltete Dienstkonten (Group Managed Service Accounts, gMSAs) nutzen. Weitere Informationen zu gMSA finden Sie weiter unten.
Ältere Windows Server-Versionen Es werden nur Versionen ab Windows Server 2016 unterstützt. Nein. Anwendungskompatibilität kann jedoch eine Option sein. Die meisten Apps für Windows Server 2008/R2 sowie ältere Apps können unter neueren Versionen von Windows Server ausgeführt werden.
Apps, die .NET Framework 2.0 oder eine ältere Version nutzen Für die Unterstützung von .NET Framework sind bestimmte Containerimages erforderlich, und nur neuere Versionen werden unterstützt. Versionen vor 2.0 werden gar nicht mehr unterstützt. Informationen zu den Containerimages, die für höhere Versionen erforderlich sind, finden Sie weiter unten.
Apps, die andere Drittanbieter-Frameworks nutzen Die Verwendung Microsoft-fremder Frameworks in Windows-Containern wird von Microsoft nicht speziell zertifiziert oder unterstützt. Erkundigen Sie sich beim Anbieter des spezifischen Frameworks oder der spezifischen App nach der Supportrichtlinie für Windows-Container. Weitere Informationen finden Sie weiter unten.

In den nächsten Abschnitten werden die obigen Einschränkungen ausführlicher erläutert.

Anwendungen, die einen Desktop erfordern

Container eignen sich perfekt für kurzlebige Funktionen, die von anderen Anwendungen aufgerufen werden – auch mit Benutzerinteraktionen. Sie können jedoch nicht für Anwendungen verwendet werden, die selbst über eine grafische Benutzeroberfläche verfügen. Das gilt auch dann, wenn die Anwendung selbst keine grafische Benutzeroberfläche hat, aber das zugehörige Installationsprogramm auf einer grafischen Benutzeroberfläche basiert. Im Allgemeinen kann Windows Installer mithilfe von PowerShell aufgerufen werden, aber wenn Ihre Anwendung eine Installation über eine grafische Benutzeroberfläche erfordert, ist diese Anforderung ein Ausschlusskriterium für die Containerisierung.

Das liegt nicht an der Art der Implementierung von Windows-Containern, sondern ist vielmehr ein grundlegendes Konzept der Funktionsweise von Containern.

Anders sieht es aus, wenn eine App GUI-APIs benötigt. Die APIs werden unterstützt, obwohl die grafische Benutzeroberfläche, die von diesen APIs bereitgestellt wird, nicht unterstützt wird. Dies wird im Thema Nano Server, Server Core oder Server: Welches Basisimage ist das richtige für sie? ausführlich erläutert.

Anwendungen mit RDP

Da das Remotedesktopprotokoll (RDP) dazu dient, eine interaktive, visuelle Sitzung einzurichten, gilt die soeben beschriebene GUI-Einschränkung auch für RDP. Eine Anwendung mit RDP kann nicht ohne Änderungen containerisiert werden.

Eine gute Alternative ist jedoch ein Remoteverwaltungstool wie Windows Admin Center. Sie können Windows Admin Center verwenden, um Windows-Containerhosts und die Container selbst zu verwalten, ohne eine RDP-Verbindung herstellen zu müssen. Sie können auch eine PowerShell-Remotesitzung mit dem Host und/oder mit Containern erstellen, um sie zu verwalten.

Zustandsbehaftete Anwendungen

Anwendungen, die Zustandsdaten speichern müssen, können nur containerisiert werden, wenn Sie die benötigten Daten zwischen Sitzungen isolieren und in persistentem Speicher speichern. Hierzu ist möglicherweise eine gewisse Anpassung der Architektur erforderlich. Diese kann mehr oder weniger umfangreich ausfallen, beseitigt aber dieses Hindernis für die Containerisierung.

Ein Beispiel für den Zustand ist eine Webanwendung, die Bilder oder Musikdateien in einem lokalen Ordner speichert. In einer herkömmlichen Windows-Umgebung wird eine Datei am Ende des Schreibvorgangs auf dem Datenträger gespeichert. Sollte also die Instanz (in diesem Fall: ein virtueller Computer) ausfallen, fahren Sie ihn einfach wieder hoch, und die Datei ist weiterhin vorhanden. Fällt dagegen eine Containerinstanz aus, die gerade einen Schreibvorgang ausführt, ist die Datei in der neuen Containerinstanz nicht enthalten. Daher empfiehlt sich die Verwendung von persistentem Speicher, damit alle Containerinstanzen Zustandsdaten oder Dateien an einem zentralen, beständigen Ort speichern können. Bei dieser Architekturanpassung muss lediglich die Art des von der Windows-Instanz verwendeten Speichers geändert werden. Änderungen am Anwendungscode sind nicht erforderlich. Weitere Informationen finden Sie unter Permanente Speicherung in Containern.

Dies bringt uns zu einem ähnlichen Thema:

Datenbankanwendungen

Datenbankanwendungen eignen sich generell nicht besonders für die Containerisierung. Es ist zwar möglich, eine Datenbank in einem Container auszuführen, die Containerisierung einer vorhandenen Datenbank ist jedoch in der Regel aus zwei Gründen nicht optimal.

Erstens: Aufgrund des Leistungsbedarfs einer Datenbank werden unter Umständen die gesamten Hardwareressourcen beansprucht, die für den Host verfügbar sind, was den Vorteil der Konsolidierung mindert. Zweitens: Die Schreibvorgänge mehrerer Instanzen einer einzelnen Datenbankebene müssen koordiniert werden. Dies lässt sich zwar mittels Containerorchestrierung lösen, aber für vorhandene Datenbanken kann die Orchestrierung zu einem Mehraufwand führen. Die meisten Datenbanken wie etwa Microsoft SQL Server verfügen über einen integrierten Lastenausgleich und über einen Hochverfügbarkeitsmechanismus.

Infrastrukturrollen in Windows Server

Windows Server-Infrastrukturrollen behandeln in erster Linie Funktionen mit größerer Nähe zum Betriebssystem (z. B. AD, DHCP und Dateiserver). Somit stehen Sie zum Ausführen von Containern nicht zur Verfügung. Anwendungen, die diese Rollen benötigen, lassen sich daher nur schwer containerisieren.

Es gibt allerdings einige Grauzonen. Beispielsweise funktionieren einige Features wie DNS möglicherweise in Windows-Containern, obwohl sie eigentlich nicht für die Verwendung in Containern vorgesehen sind. Andere Infrastrukturrollen werden einfach aus dem Basiscontainerimage entfernt und können nicht installiert werden. Hierzu zählen unter anderem Active Directory und DHCP.

Active Directory (AD)

Active Directory wurde vor mehr als zwanzig Jahren zusammen mit Windows 2000 Server veröffentlicht. Es verwendet einen Mechanismus, bei dem jedes Gerät bzw. jeder Benutzer durch ein Objekt dargestellt wird, das in der zugehörigen Datenbank gespeichert ist. Diese Beziehung ist eng gekoppelt, und Objekte werden in der Datenbank aufbewahrt, auch wenn der eigentliche Benutzer oder das eigentliche Gerät gar nicht mehr im Spiel ist. Dieser Ansatz für Active Directory steht im direkten Widerspruch zur flüchtigen Natur von Containern, die entweder kurzlebig sind oder beim Deaktivieren gelöscht werden. Die Aufrechterhaltung dieser 1:1-Beziehung mit Active Directory ist für diese Szenarien nicht ideal.

Aus diesem Grund können Windows-Container nicht in eine Domäne eingebunden werden. Dies hat unter anderem zur Folge, dass Active Directory Domain Services nicht als Infrastrukturrolle in Windows-Containern ausgeführt werden können. Sie können das PowerShell-Modul für die Remoteverwaltung von Domänencontrollern in einem Windows-Container ausführen.

Für Anwendungen, die in von Active Directory abhängigen Windows-Containern ausgeführt werden, können Sie gruppenverwaltete Dienstkonten (Group Managed Service Accounts, gMSAs) verwenden. Dies wird später noch ausführlicher erläutert.

Apps, die .NET Framework 2.0 oder eine ältere Version nutzen

Wenn Ihre Anwendung .NET benötigt, hängt die Frage, ob eine Containerisierung möglich ist, voll und ganz von der verwendeten .NET Framework-Version ab. Versionen vor .NET Framework 2.0 werden überhaupt nicht unterstützt. Für höhere Versionen müssen spezifische Images verwendet werden, wie weiter unten beschrieben.

Apps, die (Microsoft-fremde) Drittanbieter-Frameworks nutzen

Im Allgemeinen kann Microsoft keine Frameworks oder Anwendungen von Drittanbietern zertifizieren oder deren Ausführung in Windows-Containern (oder auf physischen oder virtuellen Computern) unterstützen. Microsoft führt allerdings eigene interne Usability-Tests für mehrere Drittanbieter-Frameworks und -Tools durch. Hierzu zählen unter anderem Apache, Cassandra, Chocolatey, Datadog, Django, Flask, Git, Golang, JBoss, Jenkins, Rust, Nodejs, Pearl, Python, Ruby und Tomcat.

Überprüfen Sie beim jeweiligen Anbieter des Drittanbieterframeworks bzw. der Drittanbietersoftware, ob das Framework bzw. die Software in Windows-Containern unterstützt wird.

Ideale Kandidaten für die Containerisierung

Nachdem Sie nun mit den festen Einschränkungen für die Containerisierung von Apps vertraut sind, können Sie leichter beurteilen, welche Arten von Apps besser für Windows-Container geeignet sind. Die folgende Tabelle gibt Aufschluss über die idealen Kandidaten für Windows-Container sowie über ggf. erforderliche spezielle Überlegungen zur Containerisierung.

Art der Anwendung Warum ist sie gut geeignet? Besondere Überlegungen
Konsolenanwendungen Konsolen-Apps haben keinerlei GUI-Einschränkungen und eignen sich somit sehr gut für Container. Verwenden Sie das passende Basiscontainerimage für die Anforderungen der Anwendung.
Windows-Dienste Hierbei handelt es sich um Hintergrundprozesse, die keine direkte Benutzerinteraktion erfordern. Verwenden Sie das passende Basiscontainerimage für die Anforderungen der Anwendung. Sie müssen einen Vordergrundprozess erstellen, damit containerisierte Hintergrundprozesse weiter ausgeführt werden. Weitere Informationen finden Sie weiter unten im Abschnitt zu Hintergrunddiensten.
Windows Communication Foundation-Dienste (WCF) Hierbei handelt es sich um dienstorientierte Apps, die auch im Hintergrund ausgeführt werden können. Verwenden Sie das passende Basiscontainerimage für die Anforderungen der Anwendung. Sie müssen ggf. einen Vordergrundprozess erstellen, damit containerisierte Hintergrundprozesse weiter ausgeführt werden. Weitere Informationen finden Sie weiter unten im Abschnitt zu Hintergrunddiensten.
Web-Apps Webanwendungen sind im Wesentlichen Hintergrunddienste, die an einem bestimmten Port lauschen, und eignen sich daher sehr gut für die Containerisierung, da sie die von Containern bereitgestellte Skalierbarkeit nutzen können. Verwenden Sie das passende Basiscontainerimage für die Anforderungen der Anwendung.

Hinweis: Auch diese idealen Kandidaten für die Containerisierung können von zentralen Windows-Features und -Komponenten abhängig sein, die in Windows-Containern unterschiedlich behandelt werden müssen. Der nächste Abschnitt enthält weitere Details zu solchen praktischen Überlegungen und bereitet Sie besser auf die Nutzung der Funktionen von Windows-Containern vor.

Praktische Überlegungen für Anwendungen, die containerisiert werden können

Bei App-Renovierungsprojekten wird in der Regel aus der Perspektive der geschäftlichen Funktion der App geprüft, ob eine bestimmte App containerisiert werden kann. Die geschäftliche Funktion ist jedoch nicht der entscheidende Faktor für die technische Umsetzbarkeit. Entscheidend ist die Architektur der App, also welche technischen Komponenten die App benötigt. Eine Frage wie „Kann ich meine Personalanwendung containerisieren?“ lässt sich daher nicht so einfach beantworten, da es nicht auf die Funktion der Anwendung ankommt, sondern darauf, wie die App arbeitet (und welche Windows-Komponenten/-Dienste sie verwendet).

Dies ist ein wichtiger Unterschied, denn wenn Ihre Anwendung nicht mit einer Microservices-Architektur erstellt wurde, erschwert dies wahrscheinlich ihre Containerisierung. Im weiteren Verlauf der Containerisierung müssen bestimmte Features möglicherweise besonders behandelt werden. Dies kann beispielsweise auf die Verwendung zentraler Windows-Komponenten und -Frameworks durch die App zurückzuführen sein, die in Windows-Containern nicht unterstützt werden. Andere Features wie Ereignisprotokollierung und Überwachung sind auf inhärente Unterschiede zwischen Linux und Windows zurückzuführen, die erst beim Containerisieren der App offensichtlich werden. Und bei wieder anderen (etwa bei geplanten Aufgaben und Hintergrunddiensten) muss berücksichtigt werden, dass ein Container im Gegensatz zu einem virtuellen Computer kurzlebig ist und daher eine spezielle Behandlung erfordert.

Die folgende Tabelle enthält eine kurze Zusammenfassung der Komponenten/Features von Anwendungen, bei denen im Zusammenhang mit der Containerisierung besondere Überlegungen erforderlich sind. Die anschließenden Unterabschnitte enthalten ausführlichere Details sowie Beispiele zur Veranschaulichung der Techniken für die Behandlung des jeweiligen Szenarios. In der folgenden Liste werden zwar Szenarien behandelt, die in Windows-Containern unterstützt werden, dennoch müssen auch in diesen Szenarien die Informationen aus dem vorherigen Kapitel beachtet werden. Ein Beispiel: Hintergrunddienste werden zwar unterstützt, das Ausführen eines Hintergrunddiensts in .NET Framework 1.1 aber nicht.

Windows-Feature/-Komponente, die eine spezielle Behandlung erfordert `Reason`
Microsoft Message Queuing (MSMQ) MSMQ wurde lange vor Containern entwickelt, und nicht alle Bereitstellungsmodelle für Nachrichtenwarteschlangen sind mit der Containerarchitektur kompatibel.
Microsoft Distributed Transaction Coordinator (MSDTC) Die Namensauflösung zwischen MS DTC und dem Container muss besonders berücksichtigt werden.
IIS IIS funktionieren genau wie bei einem virtuellen Computer. Bei der Ausführung in einer Containerumgebung müssen jedoch einige wichtige Punkte wie Zertifikatverwaltung, Datenbank-Verbindungszeichenfolgen und Ähnliches berücksichtigt werden.
Geplante Aufgaben Windows-Container können genau wie Windows-Instanzen geplante Aufgaben ausführen. Es muss jedoch möglicherweise eine Vordergrundaufgabe ausgeführt werden, damit die Containerinstanz weiter ausgeführt wird. Je nach Anwendung empfiehlt sich ggf. ein ereignisgesteuerter Ansatz.
Hintergrunddienste Da Container als kurzlebige Prozesse ausgeführt werden, sind zusätzliche Maßnahmen erforderlich, damit der Container weiter ausgeführt wird.
.NET Framework und .NET (ehemals .NET Core) Achten Sie darauf, dass Sie das richtige Image verwenden, um die Kompatibilität zu gewährleisten, wie im folgenden Unterabschnitt erläutert.

Weitere unterstützende Komponenten

Komponente, die eine besondere Behandlung erfordern `Reason` Alternativer Ansatz
Ereignisprotokollierung/Überwachung Das Schreiben von Ereignissen und Protokollen unter Windows unterscheidet sich grundsätzlich von „stdout“ unter Linux. Verwenden Sie das neue Protokollmonitor-Tool, um die Daten zu normalisieren und aus Linux und Windows miteinander zu kombinieren.
Sicherheit von Windows-Containern Für Container sind zusätzliche Sicherheitsmaßnahmen erforderlich. Viele Sicherheitspraktiken bleiben aber auch gleich. Verwenden Sie ein spezielles Registrierungs- und Imageüberprüfungstool. Ausführlichere Informationen finden Sie weiter unten.
Sicherung von Windows-Containern In Containern dürfen keine Daten oder Zustände gespeichert werden. Sichern Sie alle persistenten Speicher, die ggf. von Containern verwendet werden, sowie Containerimages.

Windows-Komponenten/-Features

Kommen wir nun zu den Details von Anwendungen und Komponenten, die containerisiert werden können, aber zusätzliche Maßnahmen erfordern.

MSMQ

Wenn Ihre Anwendung auf MSMQ angewiesen ist, hängt die Antwort auf die Frage, ob sie containerisiert werden kann, von ihrem MSMQ-Bereitstellungsszenario ab. MSMQ bietet mehrere Bereitstellungsoptionen. Die Faktoren „private oder öffentliche Warteschlangen“, „transaktional oder nicht“ und „Authentifizierungstyp“ bilden eine Matrix von Szenarien, für deren Unterstützung MSMQ ursprünglich entwickelt wurde. Nicht alle können problemlos zu Windows-Containern migriert werden. Die folgende Tabelle enthält die unterstützten Szenarien:

`Scope` Transaktional? Warteschlangenspeicherort Authentifizierungsart Senden und empfangen?
Privat Ja Gleicher Container (einzelner Container) Anonym Yes
Privat Ja Persistentes Volume Anonym Yes
Privat Ja Domänencontroller Anonym Yes
Privat Ja Einzelner Host (zwei Container) Anonym Yes
Öffentlich No Zwei Hosts Anonym Yes
Öffentlich Yes Zwei Hosts Anonym Yes

Einige Hinweise zu diesen unterstützten Szenarien, die von den internen Entwicklungsteams von Microsoft überprüft wurden:

  • Isolationsmodus: In den obigen Szenarien kann sowohl der Prozessisolationsmodus als auch der Hyper-V-Isolationsmodus verwendet werden.
  • Mindestanforderung für Betriebssystem und Containerimage: Für die Verwendung mit MSMQ wird mindestens die Betriebssystemversion Windows Server 2019 empfohlen.
  • Persistente Volumes: Die obigen Szenarien wurden mit MSMQ in Azure Kubernetes Service (AKS) unter Verwendung von Azure Files als persistenter Speicher überprüft.

Wenn Sie diese Überlegungen und die obige Tabelle betrachten, wird deutlich, dass nur Warteschlangen, die eine Authentifizierung mit Active Directory erfordern, nicht unterstützt werden. Die Integration gruppenverwalteter Dienstkonten (Group Managed Service Accounts, gMSAs) in MSMQ wird derzeit nicht unterstützt, da es bei MSMQ Abhängigkeiten von Active Directory gibt, die noch nicht vorhanden sind.

Alternativ können Sie Azure Service Bus anstelle von MSMQ verwenden. Bei Azure Service Bus handelt es sich um einen vollständig verwalteten Nachrichtenbroker für Unternehmen mit Nachrichtenwarteschlangen und Veröffentlichen-Abonnieren-Themen (in einem Namespace). Die Umstellung von MSMQ auf Azure Service Bus erfordert Codeänderungen sowie eine Umstrukturierung der Anwendungsarchitektur, bietet Ihnen jedoch die Flexibilität, zu einer modernen Plattform zu migrieren.

MSDTC

Microsoft Distributed Transaction Coordinator (MS DTC) wird in großen Unternehmen häufig in Windows-Legacyanwendungen verwendet. MS DTC kann in Windows-Containern installiert werden. Es gibt jedoch bestimmte Szenarien, die nicht funktionieren und in Windows-Containern nicht reproduziert werden können.

  • Achten Sie beim Erstellen des Containers darauf, den Parameter „--name“ an den Befehl „docker run“ zu übergeben. Dieser Namensparameter ermöglicht den Containern die Kommunikation über das Docker-Netzwerk. Bei Verwendung von gMSA muss der Name dem Hostnamen entsprechen, der wiederum dem gMSA-Kontonamen entsprechen muss.
    • Hier sehen Sie ein Beispiel für den Ausführungsbefehl mit gMSA:
docker run -d --security-opt "credentialspec=file://contoso_webapp01.json" --hostname webapp01 -- name webapp01 mcr.microsoft.com/windows/servercore:ltsc2022
  • Container müssen sich gegenseitig anhand des NETBIOS-Namens auflösen können. Sollten Probleme auftreten, können Sie diese am besten beheben, indem Sie den Namen und die IP-Adresse des Containers der Hostdatei des jeweils anderen Containers hinzufügen.
  • Die UUID für MS DTC muss in beiden Containern eindeutig sein. Die UUID finden Sie, indem Sie für die Container „Get-Dtc“ in PowerShell ausführen. Sind sie nicht eindeutig, können Sie dies beispielsweise beheben, indem Sie MS DTC in einem der Container deinstallieren und anschließend erneut installieren. Dazu können die PowerShell-Befehle „uninstall-dtc“ und „install-dtc“ verwendet werden.
  • Derzeit wird MS DTC in Azure Kubernetes Services nicht unterstützt. Wenn Sie MS DTC in AKS ausführen möchten, wenden Sie sich an das Team für Windows-Container, indem Sie auf GitHub im Repository für Windows-Container ein Issue erstellen.

Funktionsweise von IIS in einem Container bzw. auf einem virtuellen Computer

IIS funktionieren in einem Windows-Container genau wie auf einem virtuellen Computer. Bei der Ausführung einer IIS-Instanz in einer Containerumgebung müssen jedoch einige Aspekte berücksichtigt werden:

  • Persistenter Speicher für lokale Daten: Ordner, in denen die App Dateien schreibt/liest, sind ein gutes Beispiel für etwas, das bei einer IIS-Instanz auf dem virtuellen Computer bleibt. Bei Containern dürfen keine Daten direkt in den Container geschrieben werden. Container verwenden einen „sicheren Speicherbereich“ für die lokale Speicherung, und wenn ein neuer Container für die gleiche Anwendung aktiv wird, hat er keinen Zugriff auf diesen Bereich eines vorherigen Containers. Daher muss für Daten, auf die die Webanwendung Zugriff benötigt, persistenter Speicher verwendet werden, damit jede Containerinstanz auf diesen Speicher zugreifen kann.
  • Zertifikate: Für Containerinstanzen können zwar lokale Zertifikate verwendet werden, es empfiehlt sich jedoch, dies zu vermeiden, da Sie Ihr Containerimage neu erstellen müssen, wenn ein Zertifikat aktualisiert werden muss. Alternativ können Sie einen Containerorchestrator mit Eingangsdatensteuerung verwenden. Eingangsdatencontroller können Netzwerkrichtlinien anwenden und auch die Zertifikatverwaltung für die Website übernehmen, die dahinter gehostet wird. Das hat den Vorteil, dass Sie die Zertifikatlebenszyklusverwaltung von der Websiteverwaltung entkoppelt wird.
  • Datenbank-Verbindungszeichenfolgen: Bei der herkömmlichen IIS-Bereitstellung können Sie die Datenbank-Verbindungszeichenfolge im Rahmen Ihrer Anwendungsbereitstellung übergeben. Bei Windows-Containern können Sie zwar diesem Modell folgen, es empfiehlt sich jedoch gegebenenfalls, die Datenbank-Verbindungszeichenfolge vom Container zu entkoppeln und in eine zentralisierte, vom Containerorchestrator bereitgestellte Konfiguration auszulagern, aus der die Anwendung lesen kann. Dadurch können Sie die Datenbank-Verbindungszeichenfolge unabhängig von der Anwendung verwalten und aktualisieren. Wenn sich die Datenbank ändert (etwa bei einer Lift & Shift-Migration zur Cloud), können Sie die Verbindungszeichenfolge ganz einfach ändern, ohne das Containerimage neu zu erstellen. Außerdem können bei diesem Ansatz auch Geheimnisse wie Benutzername und Kennwort für die Verbindung mit der Datenbank in einem Geheimnisspeicher gespeichert werden.
  • Horizontale automatische Skalierung: Bei zunehmender Last werden Rechensysteme gefühlt langsamer, während sie versuchen, die gleichzeitigen Anforderungen zu verarbeiten. Leistungseinbußen lassen sich allgemein durch zwei Maßnahmen vermeiden: vertikales Skalieren oder horizontales Skalieren. Beim vertikalen Skalieren werden die Ressourcen erhöht, die für die vorhandenen Computeinstanzen zur Verfügung stehen (mehr CPU, Arbeitsspeicher usw.). Beim horizontalen Skalieren wird die Anzahl von Instanzen erhöht, die die Anforderungen unterstützen (mehr physische Hosts, virtuelle Computer oder Container). Bei Webebenen wie IIS ist horizontales Skalieren tendenziell effizienter als vertikales Skalieren. In lokalen Umgebungen können jedoch Ressourcenbeschränkungen und Lastenausgleichsprobleme auftreten. Bei Cloudumgebungen ist horizontales Skalieren wesentlich einfacher, da Ressourcen (für eine zusätzliche Gebühr) unmittelbar verfügbar sind und der Cloudanbieter seinen Lastenausgleichsmechanismus in der Regel so gestaltet, dass er für horizontales Skalieren geeignet ist. Windows-Container können horizontales Skalieren für IIS nutzen, der kurzlebige Aspekt von Containern spielt jedoch eine wichtige Rolle. Ihre Container müssen zwingend über die gleiche Konfiguration verfügen, und es dürfen keine Zustände oder Daten in den Containern gespeichert werden, damit die Anzahl von Instanzen, die Ihre Webanwendung unterstützen, hoch- oder herunterskaliert werden kann.

Geplante Aufgaben

Geplante Aufgaben werden verwendet, um in einer Windows-Umgebung zu einem beliebigen Zeitpunkt ein Programm, einen Dienst oder ein Skript aufzurufen. Üblicherweise verfügen Sie über eine kontinuierlich ausgeführte Windows-Instanz, und wenn die Bedingungen eines Triggers erfüllt sind, wird die Aufgabe ausgeführt. Dies ist mit Windows-Containern möglich, und abgesehen von der Tatsache, dass geplante Vorgänge über Azure PowerShell konfiguriert und verwaltet werden müssen, ist die Funktionsweise identisch.

Bei einem Microservices-Ansatz gibt es jedoch einige Optionen, um zu vermeiden, dass ein Container kontinuierlich ausgeführt werden muss, um auf einen Trigger zu warten:

  • Verwenden einer ereignisgesteuerten PaaS-Lösung (Platform as a Service) wie etwa Azure Functions, um Ihren Code zu speichern und einen Trigger für diese App zu definieren. Azure Functions unterstützt sogar die Ausführung von Windows-Containerimages, wenn die Bedingungen eines Triggers erfüllt sind.
  • Verwenden von Windows-Containern in Verbindung mit einem Containerorchestrator. Der Container kann nur ausgeführt werden, wenn die Bedingungen des Triggers erfüllt sind und der Aufruf aus anderen Teilen der Anwendung erfolgt. In diesem Fall behandelt der Containerorchestrator die Planung und den Trigger für die Anwendung.
  • Kontinuierliches Ausführen eines Windows-Containers, um einen geplanten Vorgang auszuführen. Sie benötigen einen Vordergrunddienst (z. B. ServiceMonitor), damit der Container weiter ausgeführt wird.

Hintergrunddienste

Container werden zwar im Allgemeinen für kurzlebige Prozesse verwendet, Sie können jedoch eine Hintergrundanwendung mit langer Laufzeit containerisieren. Dies setzt allerdings die Erstellung eines Vordergrundprozesses heraus, um sie zu starten und weiter auszuführen.

Ein gutes Beispiel hierfür ist ServiceMonitor – eine ausführbare Windows-Datei, die als Einstiegspunktprozess beim Ausführen von IIS in Containern verwendet werden kann. Das Modell des ursprünglich für IIS entwickelten ServiceMonitor-Tools kann mit gewissen Einschränkungen auch zur Überwachung anderer Dienste verwendet werden.

Weitere Informationen zu ServiceMonitor finden Sie in der Dokumentation auf GitHub.

.NET Framework und .NET

Windows-Container unterstützen sowohl .NET Framework als auch .NET (ehemals .NET Core). Das .NET-Team erstellt eigene offizielle Images für beide Frameworks, die auf den Windows-Basiscontainerimages basieren. Die Wahl des passenden Images ist wichtig, um die Kompatibilität sicherzustellen. Das .NET-Team stellt .NET Framework-Images auf Basis des Server Core-Basiscontainerimages und .NET-Images auf Basis der Server Core- und Nano Server-Basiscontainerimages bereit. Server Core verfügt über einen größeren API-Satz als Nano Server. Das führt zu mehr Kompatibilität, aber auch zu einem größeren Image. Bei Nano Server ist der API-Umfang deutlich geringer, gleiches gilt aber auch für die Imagegröße.

In einigen Fällen müssen Sie möglicherweise Ihr eigenes .NET Framework- oder .NET-Image auf Basis des Windows- oder Server-Basiscontainerimages erstellen. Dies kann erforderlich sein, wenn Ihre Anwendung nicht nur eine Frameworkabhängigkeit, sondern auch eine Betriebssystemabhängigkeit aufweist. Solche Abhängigkeiten können Sie erkennen, indem Sie Ihre Anwendung mit einem bestimmten Basiscontainerimage testen.

Beispielsweise ist in den Server Core- und Nano Server-Basiscontainerimages nur eine einzelne Schriftart verfügbar, um die Imagegröße zu verringern. Wenn Ihre Anwendung eine andere Schriftart benötigt, müssen Sie diese Schriftart installieren oder die Server- oder Windows-Images verwenden, die über einen größeren API-Satz verfügen und alle Windows-Standardschriftarten enthalten. Aus Kompatibilitätssicht ermöglicht dies die Containerisierung nahezu jeder App – vorausgesetzt, sie erfüllt die Voraussetzungen für Container (beispielsweise keine grafische Benutzeroberfläche). Auf der anderen Seite werden sie dadurch deutlich größer, was sich ggf. auf die Leistung auswirkt.

Microsoft empfiehlt Folgendes, wenn Sie überprüfen, ob die zu containerisierende Anwendung in Windows-Containern funktioniert:

Framework Containerimage für den ersten Test Alternatives Containerimage, wenn das erste nicht funktioniert Base image
.NET Framework-Versionen 2.x und 3.x .NET Framework 4.x .NET Framework 3.5 Windows Server Core
.NET Framework 4.x-Versionen .NET Framework 4.x Erstellen Sie Ihr .NET Framework-Containerimage mit Server- oder Windows-Images Windows Server Core
.NET 6 oder 7 .NET 6 bzw. 7 Erstellen Sie Ihr .NET-Containerimage mit Windows- oder Server-Basisimages Windows Nano Server oder Server Core

Weitere unterstützende Komponenten

Die folgenden Komponenten und Themen enthalten zusätzliche Informationen für Elemente, die parallel verwendet werden oder Windows-Container noch besser verständlich machen.

Ereignisprotokollierung

Windows und Linux verwenden unterschiedliche Methoden, um Protokolle und Ereignisse zu speichern und den Benutzern zu präsentieren. Unter Windows wurde traditionell das EVT-Format verwendet, das strukturiert in der Ereignisanzeige betrachtet werden kann. Im Gegensatz dazu wurde unter Linux ein optimierter Ansatz mit Standardausgabe (Standard Output, stdout) bereitgestellt, der von anderen Tools wie Docker genutzt wird.

Bei Docker stand schon immer ein Mechanismus zum Extrahieren von Protokollen aus Linux-Containern zur Verfügung. Wenn der Befehl „docker logs“ mit einer stdout-Standardkonfiguration verwendet wird, ruft Docker Anwendungsprotokolle aus dem Container ab, ohne den Container interaktiv zu öffnen. Bis zur Einführung des Protokollmonitor-Tools funktionierte diese Technik jedoch nicht unter Windows.

Das Protokollmonitor-Tool präsentiert die Windows-Protokolle im stdout-Format, sodass andere Tools wie etwa Docker die erforderlichen Informationen sammeln können, um sie anzuzeigen. Die Verwendung des Protokollmonitors hat noch weitere Vorteile:

  • Sie können filtern, welche Arten von Ereignissen/Protokollen Sie in „stdout“ verfügbar machen möchten. So können Sie das Anwendungsprotokoll beispielsweise nach Fehler- und Warnmeldungen filtern, wenn Informationsereignisse für Sie nicht relevant sind.
  • Sie können zwischen Ereignisprotokollen, benutzerdefinierten Protokolldateien und der Ereignisablaufverfolgung für Windows (Event Tracing for Windows, ETW) wählen. Dies ist besonders hilfreich, wenn Ihre Anwendung Schreibvorgänge für eine andere Protokolldatei ausführt. Ein Beispiel hierfür sind die IIS-Protokolle, die sich im Ordner „C:\inetpub“ befinden.
  • Der Protokollmonitor sorgt dafür, dass sich Windows-Container mehr wie Linux-Container verhalten, sodass Tools, die nach „stdout“ suchen und mit der Containerruntime interagieren, wie erwartet funktionieren. Wenn Sie beispielsweise die Containerruntime von Docker auf ContainerD umstellen, sollten die Protokolle weiterhin vom Containerhost aus sichtbar sein (beispielsweise über „crictl logs“).

Weitere Informationen zum Protokollmonitor-Tool finden Sie in diesem Blogbeitrag.

Sicherheit von Windows-Containern

Windows-Container haben die gleiche Grundlage wie Windows-Instanzen, die auf physischen oder virtuellen Computern ausgeführt werden. Für den Schutz containerisierter Anwendungen ist es hilfreich, mit den Besonderheiten der Implementierung von Containern vertraut zu sein (insbesondere mit der gemeinsamen Kernel-Nutzung):

  • Gemeinsam genutzte Komponenten. Aus Sicherheitsgründen teilen sich Windows-Container einige Komponenten des Hosts. Hierzu zählen unter anderem die Windows-Firewall, Windows Defender (Antivirus) und andere Ressourcenzugriffseinschränkungen. Sie müssen diese Komponenten nicht direkt für Ihren Container konfigurieren, da der Containerhost die erforderlichen Anpassungen basierend auf Ihrer Containerworkload vornimmt. Wenn der Container beispielsweise eine Webanforderung vornimmt, leitet der Containerhost den erforderlichen Datenverkehr durch seine Firewall, damit der Container auf das Web zugreifen kann.
  • Isolationsmodus: Wie bereits erläutert, können Windows-Container im Prozessisolationsmodus oder im Hyper-V-Isolationsmodus bereitgestellt werden, wobei der Hyper-V-Isolationsmodus die sicherste Isolation bietet. Im Prozessisolationsmodus teilt der Container seinen Kernel, sein Dateisystem und seine Registrierung mit dem Host, wodurch ein Prozess mit erhöhten Rechten (Administratorprozess) mit den Containerprozessen und -diensten interagieren kann. Die Wahl des richtigen Isolationsmodus ist wichtig, um das passende Sicherheitsmodell zu verwenden.
  • Windows-Updates Da der Wartungsstapel in Windows-Containern nicht vorhanden ist, erhalten Windows-Container keine Updates wie allgemeine Windows-Instanzen. Stattdessen müssen Windows-Container unter Verwendung des neuesten verfügbaren Basiscontainerimages neu erstellt werden. Kunden können hierzu DevOps-Pipelines nutzen. Microsoft aktualisiert die Basiscontainerimages für alle offiziellen Images jeden Monat im Patch-Dienstag-Rhythmus.
  • Containerbenutzerkonto: Standardmäßig werden Anwendungen in Windows-Containern mit erhöhten Rechten unter dem ContainerAdmin-Benutzerkonto ausgeführt. Dies ist hilfreich, um die erforderlichen Komponenten innerhalb des Containerimages zu installieren und zu konfigurieren. Es empfiehlt sich jedoch, das Benutzerkonto in „ContainerUser“ zu ändern, wenn eine Anwendung ausgeführt wird, die keine erhöhten Rechte erfordert. In bestimmten Szenarien können Sie auch ein neues Konto mit den entsprechenden Rechten erstellen.
  • Image- und Runtimeüberprüfungen: Container erfordern, dass Images in Repositorys und Containerinstanzen sicher sind. Microsoft empfiehlt die Verwendung von Microsoft Defender für Container, um Images und Runtimes zu überprüfen. Defender für Container unterstützt Windows-Container für die Sicherheitsrisikobewertung mit Registrierungsüberprüfung und Runtimeschutz mit Bedrohungserkennung.

Weitere Informationen zu den obigen Themen finden Sie auf der Dokumentationsseite zu Windows-Containern.

Sicherung von Windows-Containern

Bei der Verwendung von Containern müssen Sie Ihre Denkweise im Zusammenhang mit Sicherungen ändern. Wie bereits erwähnt darf ein Container aufgrund seiner Kurzlebigkeit nicht zum Speichern von Zuständen oder Daten verwendet werden. Wenn Sie Zustand und Daten von der Containerinstanz trennen, liegt die Sicherung außerhalb der Runtime der Containerinstanz, und diese kann durch eine neue ersetzt werden, für die weiterhin der gesamte erforderliche persistente Speicher verfügbar ist.

Es gibt jedoch noch Komponenten, die Sie sichern müssen. Hierzu zählen unter anderem die Anwendung, das Containerimage und das Dockerfile zur Erstellung des Containerimages. Die meisten dieser Vorgänge werden von der Plattform übernommen, auf der Sie Ihre Produktions- und Entwicklungsworkloads ausführen. Im Anschluss finden Sie die gängigsten Fälle bei Verwendung eines DevOps-Ansatzes:

  • Anwendung: Ihre Anwendung befindet sich wahrscheinlich in einem Quellrepository wie GitHub oder Azure DevOps. Diese Repositorys bieten eine Versionskontrolle, was die Rückkehr zu einer spezifischen Version der Anwendung ermöglicht. Wenn Sie der Besitzer des Quellrepositorys sind, stellen Sie sicher, dass Sie sich an die entsprechenden Sicherungs- und Verwaltungsempfehlungen halten.
  • Containerimage: Für Produktionsumgebungen sollte sich Ihr Containerimage in einem zentralisierten Imagerepository wie Azure Container Registry (ACR) befinden. Sie können Ihre Containerimages an ACR pushen, damit sie von anderen Hosts gepullt werden können. ACR kümmert sich um die Verfügbarkeit der Containerimages und fungiert als Sicherungsoption. Beachten Sie jedoch, dass sich ACR zwar um die Verfügbarkeit des Images kümmert, aber nicht die Löschung oder Überschreibung eines Images verhindert. Halten Sie sich bei anderen lokalen Imagerepositorys an die jeweilige Anbieterempfehlung für die Sicherung vorhandener Registrierungen.
  • Dockerfile: Dockerfiles erstellen neue Containerimages und werden normalerweise zusammen mit der Anwendungsquelle gespeichert. Da das Dockerfile möglicherweise nicht mit der Anwendung erstellt wurde (insbesondere, wenn es sich um eine vorhandene Anwendung handelt, die containerisiert wird), sind Sie dafür verantwortlich, sicherzustellen, dass das Dockerfile an einem sicheren Speicherort gespeichert wird, für den Sicherungen durchgeführt werden. Stellen Sie außerdem sicher, dass alle anderen Ressourcen, die erforderlich sind, damit Ihre Anwendung in einem Container funktioniert, gesichert werden. Für YAML- und JSON-Dateien für Kubernetes, Docker Swarm und Azure ARM-Vorlagen gelten beispielsweise die gleichen Richtlinien wie oben.

Planen des Lift & Shift-Prozesses

Nachdem Sie die Bereitschaft Ihrer Anwendung für die Containerisierung bewertet haben, können Sie den folgenden allgemeinen Leitfaden verwenden, um den Prozess zu planen:

  1. Bestimmen Sie das benötigte Basisimage des Windows-Betriebssystems: Windows Server Core, Nano Server, Windows oder Server.
  2. Bestimmen Sie den Isolationsmodus für den Container: Prozessisolation oder Hyper-V-Isolation. Hinweis: Von AKS und AKS in Azure Stack HCI werden derzeit nur Container mit Prozessisolation unterstützt. In einem zukünftigen Release werden von AKS und AKS in Azure Stack HCI dann auch Container mit Hyper-V-Isolation unterstützt. Weitere Informationen zur Isolation finden Sie unter Isolationsmodi.
  3. Wählen Sie für Ihre Anwendung die richtige Windows Server-Version aus, um die Anwendungskompatibilität zu gewährleisten. Die Windows Server-Mindestversion für Container ist Windows Server 2016, aber Windows Server 2019 und Windows Server 2022 sind die einzigen Betriebssysteme für Containerhosts, die für AKS und AKS in Azure Stack HCI unterstützt werden.
  4. Stellen Sie sicher, dass für die Containerumgebung die Sicherheitsrichtlinien Ihres Unternehmens vorhanden sind. Dies beinhaltet die Anpassung an containerspezifische Anforderungen (beispielsweise Registrierungsüberprüfung und Bedrohungserkennung).
  5. Berücksichtigen Sie Lastenausgleichanforderungen. Container selbst sind statisch. Sie können stattdessen einen Orchestrator verwenden, um Container automatisch auf Clusterknoten zu starten oder zu beenden oder um Änderungen bei der Last und Verfügbarkeit mit automatischem horizontalem Skalieren zu bewältigen.
  6. Berücksichtigen Sie Orchestrierungsanforderungen. Nach der Containerisierung benötigt Ihre Anwendung wahrscheinlich eine automatisierte Verwaltung, die mit Tools wie Kubernetes, AKS oder AKS in Azure Stack HCI verfügbar ist. Ausführliche Informationen und eine ausführliche Anleitung zur Toolauswahl finden Sie in der Übersicht zur Windows-Containerorchestrierung.
  7. Containerisieren Sie die App.
  8. Pushen Sie die App in ein Imagerepository. Dadurch können die Containerhosts das Image in jeder Umgebung herunterladen (einschließlich Entwicklung, Test und Produktion).

Azure Migrate kann einen geführten Prozess zum Ermitteln, Bewerten und Migrieren Ihrer vorhandenen Windows-Anwendung zu Azure Kubernetes Service bereitstellen. Weitere Informationen finden Sie unter Modernisieren von ASP.NET-Web-Apps auf Azure Kubernetes Service (Vorschau).