Verwenden von Windows-Containern zum "Containerisieren" vorhandener Anwendungen

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

Windows-Container bieten einen hervorragenden Mechanismus zum Modernisieren herkömmlicher oder älteren 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 wird verwendet, um die Migration von Workloads zur Cloud zu beschreiben. Heute wird dieser Begriff besser auf die Migration virtueller Computer (VMs) angewendet. Container sind jedoch keine virtuellen Maschinen, und sie als solche zu betrachten, kann zu Verwirrung darüber führen, wie eine Anwendung containerisiert wird oder ob sie containerisiert werden kann oder sollte.

Dieses Thema enthält praktische Anleitungen zum Verschieben herkömmlicher Anwendungen in Windows-Container. Sie sollen dabei helfen, zu priorisieren, welche Anwendungen containerisiert werden sollen, indem besondere Überlegungen im Vorfeld erläutert werden.

Einleitung

Was Windows-Container sind und was sie nicht sind

Der generische Begriffscontainer bezieht sich auf eine Technologie, die das Betriebssystem (Os) virtualisiert. Diese Virtualisierung bietet eine Isolationsstufe vom Betriebssystem des Servers/Hosts selbst, was wiederum mehr Flexibilität für Anwendungsentwickler und Betriebsteams ermöglicht.

Windows-Container sind eine bestimmte Implementierung der Containertechnologie. Sie stellen Instanzen virtualisierter Betriebssysteme bereit, die vom Windows-Betriebssystem isoliert sind. Die gesamte Interdependenz zwischen Container und Host ist jedoch unmöglich: Ein Windows-Container muss den Bedarf an Ressourcen und Funktionen mit dem Windows-Betriebssystem koordinieren. Warum ist dies wichtig? Da es sich bei einem Windows-Container nicht um einen ganzen virtualisierten Server handelt, und einige der Dinge, die Sie mit einer Anwendung tun möchten, können nicht nur mit einem virtualisierten Betriebssystem ausgeführt werden.

Weitere Informationen zu diesem Thema finden Sie in Containern im Vergleich zu virtuellen Computern. Aber ein paar gute Punkte, die Ihnen helfen, Container und VMs zu unterscheiden, sind:

• Container sind keine Lösung, die der Desktopanwendungsvirtualisierung entspricht. Sie unterstützen nur serverseitige Anwendungen, für die keine interaktive Sitzung erforderlich ist. Da sie auf speziellen Containerimages ausgeführt werden, unterstützen sie nur die Anwendungen, die kein grafisches Front-End benötigen.
• Container sind von Natur aus ephemeral. Dies bedeutet, dass standardmäßig kein Mechanismus zum Speichern des Status einer Containerinstanz vorhanden ist. Wenn eine Instanz fehlschlägt, wird sie durch eine andere ersetzt.

Die Containertechnologie begann unter Linux, wobei Docker sich als Standard entwickelt hat. Microsoft hat eng mit Docker zusammengearbeitet, um sicherzustellen, dass die Containerfunktionalität unter Windows so weit wie möglich der anderer Plattformen entspricht. Inhärente Unterschiede zwischen Linux und Windows können auf Arten auftreten, die als Einschränkungen von Windows-Containern erscheinen, wenn sie tatsächlich nur die Linux- und Windows-Unterschiede sind. Andererseits stellen Windows-Container einige eindeutige Implementierungen bereit, z. B. Hyper-V Isolation, die später behandelt werden. Dieses Thema hilft Ihnen, diese Unterschiede zu verstehen und wie Sie sie berücksichtigen können.

Vorteile der Verwendung von Containern

Ähnlich wie das Ausführen mehrerer VMs auf einem einzelnen physischen Host können Sie mehrere Container auf einem einzelnen physischen oder virtuellen Host ausführen. Im Gegensatz zu VMs müssen Sie das Betriebssystem für einen Container nicht verwalten, wodurch Sie sich auf die Anwendungsentwicklung und die zugrunde liegende Infrastruktur konzentrieren können. Es bedeutet auch, dass Sie eine Anwendung isolieren können, sodass sie von anderen Prozessen, die vom Betriebssystem unterstützt werden, nicht betroffen ist.

Container bieten eine einfache Methode zum Erstellen und dynamischen Beenden der Ressourcen, die für eine funktionierende Anwendung erforderlich sind. Während es möglich ist, virtuelle Computer zu erstellen und bereitzustellen, da die Anwendungsnachfrage zunimmt, ist es schneller, Container zum Skalieren zu verwenden. Mit Containern können Sie auch schnell neu starten, wenn ein Absturz oder eine Hardwareunterbrechung auftritt. Mit Containern können Sie jede App von der Entwicklung in die Produktion mit wenig oder ohne Codeänderung übernehmen, da sie Anwendungsabhängigkeiten enthalten, sodass sie in allen Umgebungen funktionieren. Die Möglichkeit, eine vorhandene Anwendung mit minimalen Codeänderungen zu containern, aufgrund der Docker-Integration über Microsoft-Entwicklertools hinweg, ist auch ein leistungsstarker Faktor bei der Anwendungsentwicklung und -wartung.

Schließlich ist einer der wichtigsten Vorteile der Verwendung von Containern die Flexibilität, die Sie für die App-Entwicklung gewinnen, da Sie unterschiedliche Versionen einer App haben können, die auf demselben Host ausgeführt wird, ohne dass Ressourcen kollidieren.

Eine vollständigere Liste der Vorteile für die Verwendung von Containern für vorhandene Anwendungen finden Sie auf der Microsoft .NET-Dokumentationsseite.

Wichtiges Konzept der Isolationsstufe

Windows-Container bieten eine Isolation vom Windows-Betriebssystem, die beim Erstellen, Testen und Bewerben einer App für die Produktion von Vorteil ist. Aber die Art und Weise, wie die Isolation erreicht wird, ist wichtig zu verstehen, wenn Sie über die Containerisierung einer Anwendung nachdenken.

Windows Container bieten zwei verschiedene Modi der Laufzeitisolation: Prozess und Hyper-V-. Container unter beiden Modi werden identisch erstellt und verwaltet und funktionieren identisch. Was sind also die Unterschiede und warum sollten Sie sich interessieren?

In Prozessisolationwerden mehrere Container gleichzeitig auf einem einzelnen Host mit Isolation ausgeführt, die über Namespace, Ressourcensteuerung und andere Features bereitgestellt wird. Container im Prozessisolationsmodus teilen denselben Kernel mit dem Host und einander. Dies entspricht ungefähr der Ausführung von Linux-Containern.

In Hyper-V Isolationwerden mehrere Container auch gleichzeitig auf einem einzelnen Host ausgeführt, aber die Container werden innerhalb hochoptimierter virtueller Computer ausgeführt, wobei jeder effektiv seinen eigenen Kernel erhält. Das Vorhandensein dieses virtuellen Computers – effektiv ein "Hilfscomputer" – bietet eine Hardwareebenenisolation zwischen jedem Container 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 eine wahrscheinliche Auswirkung auf die Gesamtleistung der App.
• Nicht alle Tools funktionieren nativ mit Hyper-V Isolation.
• Derzeit unterstützen weder Azure Kubernetes Service (AKS) noch AKS auf Azure Stack HCI Hyper-V Isolation.

Weitere Informationen darüber, wie die beiden Isolationsmodi im Thema Isolationsmodiimplementiert sind, finden Sie hier. Wenn Sie eine App zum ersten Mal containern, müssen Sie zwischen den beiden Modi wählen. Glücklicherweise ist es sehr einfach, später von einem Modus in einen anderen zu wechseln, da keine Änderungen an der Anwendung oder dem Container erforderlich sind. Beachten Sie jedoch, dass bei der Containerisierung einer App die Auswahl zwischen den beiden Modi einer der ersten Schritte ist, die Sie tun müssen.

Containerorchestrierung

Die Möglichkeit, mehrere Container auf einem einzelnen oder mehreren Hosts auszuführen, ohne sich um die Betriebssystemverwaltung zu sorgen, bietet Ihnen große Flexibilität und hilft Ihnen dabei, zu einer mikroservicebasierten Architektur zu wechseln. Ein Kompromiss für diese Flexibilität ist jedoch, dass eine Umgebung, die auf Containern und Microservices basiert, schnell zu vielen beweglichen Teilen anwachsen kann – zu vielen, um den Überblick zu behalten. Glücklicherweise ist die Verwaltung des Lastenausgleichs, der hohen Verfügbarkeit, der Planung von Containern, der Ressourcenverwaltung und vieles mehr die Rolle eines Container-Orchestrators.

Orchestratoren sind vielleicht falsch benannt; Sie sind eher wie die Dirigenten eines Orchesters, da sie die Aktivität mehrerer Container koordinieren, um die Musikwiedergabe beizubehalten. In einem Sinne behandeln sie die Planung und Ressourcenzuordnung für Container auf eine Weise, die der Funktionsweise eines Betriebssystems ähnelt. Wenn Sie also zur Containerisierung Ihrer Anwendungen wechseln, müssen Sie zwischen den Orchestratoren wählen, die Windows-Container unterstützen. Einige der am häufigsten verwendeten sind Kubernetes und Docker-Schwarm.

Was kann nicht in Windows-Container verschoben werden?

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

In der folgenden Tabelle sind die Arten von Apps zusammengefasst, die nicht in Windows-Container verschoben werden können und warum nicht. Die Gründe werden in den Unterabschnitten nach der Tabelle genauer erläutert. Das Verständnis der Gründe für diese Einschränkungen kann Ihnen eine klarere Vorstellung davon geben, was Container wirklich sind, einschließlich der Unterschiede zwischen den VMs. Dies hilft Ihnen wiederum, die Funktionen von Windows-Containern besser zu bewerten, die Sie mit den vorhandenen Apps nutzen können, die Sie containerisieren können.

Hinweis: Die folgende Liste ist keine vollständige Liste. Stattdessen ist es eine Zusammenstellung von Apps, bei denen Microsoft beobachtet hat, dass Kunden versuchen, sie in Container zu verpacken.

Anwendungen/Features werden nicht unterstützt	Warum nicht unterstützt	Können Sie dies umgehen?
Anwendungen, die einen Desktop erfordern	Container unterstützen keine Grafische Benutzeroberfläche (GUI)	Wenn die Anwendung nur eine GUI zur Installation benötigt, könnte die Umstellung auf eine stille Installation eine Lösung sein.
Anwendungen mit Remotedesktopprotokoll (RDP)	RDP ist für interaktive Sitzungen vorgesehen, daher gilt auch hier das oben genannte Prinzip.	Möglicherweise können Sie Windows Admin Center (WAC) oder Remote PowerShell als Alternative für die Remoteverwaltung verwenden.
Zustandsbehaftete Anwendungen	Container sind kurzlebig.	Ja, einige Anwendungen erfordern möglicherweise minimale Änderungen, sodass sie keine Daten oder den Zustand im Container speichern.
Datenbankanwendungen	Container sind kurzlebig.	Ja, einige Anwendungen erfordern möglicherweise minimale Änderungen, sodass sie keine Daten oder den Zustand im Container speichern.
Active Directory	Der Entwurf und Zweck von Active Directory schließt 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, gMSA) verwenden. Weitere Informationen zu gMSA finden Sie unten.
Ältere Windows Server-Versionen	Nur Windows Server 2016 oder höher wird unterstützt.	Nein. Anwendungskompatibilität kann jedoch eine Option sein – die meisten Windows Server 2008/R2 und ältere Apps werden auf neueren Versionen von Windows Server ausgeführt.
Apps mit .NET Framework, Version 2.0 oder älter	Bestimmte Containerimages sind erforderlich, um .NET Framework zu unterstützen, und nur neuere Versionen werden unterstützt.	Versionen, die älter als 2.0 sind, werden überhaupt nicht unterstützt, sehen Sie sich jedoch unten für die Containerimages an, die für höhere Versionen erforderlich sind.
Apps, die andere Drittanbieterframeworks verwenden	Microsoft zertifiziert oder unterstützt nicht ausdrücklich die Verwendung von Nicht-Microsoft-Frameworks in Windows-Containern.	Überprüfen Sie beim Anbieter des spezifischen Frameworks oder der App die Supportrichtlinie für Windows-Container. Weitere Informationen finden Sie weiter unten.

Betrachten wir alle diese Einschränkungen wiederum.

Anwendungen, die einen Desktop erfordern

Container eignen sich ideal für kurzlebige Funktionen, die von anderen Anwendungen aufgerufen werden, einschließlich benutzerinteraktionen. Sie können sie jedoch nicht für Anwendungen verwenden, die über GUIs selbst verfügen. Dies gilt auch dann, wenn die Anwendung selbst nicht über eine GUI verfügt, aber über ein Installationsprogramm verfügt, das auf einer GUI basiert. Im Allgemeinen kann Windows Installer mithilfe von PowerShell aufgerufen werden, aber wenn Ihre Anwendung eine Installation über eine GUI erfordert, wird diese Anforderung als Kandidat für die Containerisierung entfernt.

Dies ist kein Problem mit der Implementierung von Windows-Containern, sondern ein grundlegendes Konzept der Funktionsweise von Containern.

Es ist anders, wenn eine App GUI-APIs benötigt. Die APIs werden unterstützt, obwohl die GUI, 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 der gesamte Zweck des Remotedesktopprotokolls (RDP) darin besteht, eine interaktive, visuelle Sitzung einzurichten, gilt auch die soeben beschriebene GUI-Einschränkung. Eine Anwendung mit RDP kann nicht as-iscontainerisiert 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 dass RDP darin enthalten sein muss. Sie können auch eine PowerShell-Remotesitzung auf dem Hostsystem und/oder den Containern öffnen, um sie zu verwalten.

Zustandsbehaftete Anwendungen

Anwendungen, die Zustandsdaten beibehalten müssen, können nur dann containert werden, wenn Sie die daten isolieren, die von einer Sitzung zur nächsten benötigt werden, und sie im beständigen Speicher speichern. Dies könnte eine Umstrukturierung erfordern, die möglicherweise nicht trivial ist, aber wenn Sie damit fortfahren, wird diese Barriere für die Containerisierung beseitigt.

Ein Beispiel für den Status ist eine Webanwendung, die Bilder oder Musikdateien in einem lokalen Ordner speichert. In einer herkömmlichen Windows-Umgebung wird eine Datei zum Zeitpunkt des Schreibvorgangs auf dem Datenträger gespeichert. Wenn also die Instanz (in diesem Fall eine VM) fehlschlägt, rufen Sie sie einfach wieder auf, und die Datei ist weiterhin vorhanden. Wenn dagegen eine Containerinstanz, die einen Schreibvorgang ausführt, fehlschlägt, enthält die neue Containerinstanz diese Datei nicht. Aus diesem Grund sollten Sie die Verwendung des beständigen Speichers in Betracht ziehen, damit alle Containerinstanzen Zustandsdaten oder Dateien an einem zentralen, dauerhaften Speicherort speichern können. Für diese Art der Umrüstung ist es nicht erforderlich, den Code der Anwendung zu ändern, nur den Von der Windows-Instanz verwendeten Speichertyp. Weitere Informationen finden Sie in der Dokumentation zu Windows-Containern bezüglich Speicher.

Dies bringt jedoch ein weiteres verwandtes Thema mit sich...

Datenbankanwendungen

In der Regel sind Datenbankanwendungen keine hervorragenden Kandidaten für die Containerisierung. Sie können zwar eine Datenbank in einem Container ausführen, aber die Containerisierung einer vorhandenen Datenbank ist in der Regel nicht ideal, aus zwei Gründen.

Erstens erfordert die leistung, die für eine Datenbank erforderlich ist, möglicherweise die gesamten Hardwareressourcen, die für den Host verfügbar sind – was den Vorteil der Konsolidierung entwertet. Zweitens benötigen mehrere Instanzen einer einzelnen Datenbankebene eine Koordination für ihre Schreibvorgänge. Container-Orchestrierung kann dies lösen, aber bei vorhandenen Datenbanken kann die Orchestrierung zu einem Mehraufwand werden. Die meisten Datenbanken, z. B. Microsoft SQL Server, verfügen über einen integrierten Lastenausgleich und einen Mechanismus für hohe Verfügbarkeit.

Infrastrukturrollen unter Windows Server

Windows Server-Infrastrukturrollen behandeln in erster Linie Funktionen näher am Betriebssystem (z. B. AD, DHCP und Dateiserver). Somit stehen sie zum Ausführen von Containern nicht zur Verfügung. Daher sind Anwendungen, die diese Rollen benötigen, immer schwierig zu containern.

Es gibt einige graue Bereiche. Beispielsweise können einige Features wie DNS unter Windows-Containern funktionieren, obwohl sie nicht wirklich für die Verwendung in Containern vorgesehen sind. Andere Infrastrukturrollen werden einfach aus dem Basiscontainerimage entfernt und können nicht installiert werden, z. B. Active Directory, DHCP und andere.

Active Directory (AD)

Active Directory wurde vor mehr als zwanzig Jahren auf Windows 2000 Server veröffentlicht. Es verwendet einen Mechanismus, in dem jedes Gerät oder jeder Benutzer durch ein objekt dargestellt wird, das in seiner Datenbank gespeichert ist. Diese Beziehung ist eng gekoppelt, und Objekte werden in der Datenbank aufbewahrt, auch wenn der tatsächliche Benutzer oder das Gerät nicht mehr im Einsatz ist. Dieser Ansatz für Active Directory widerspricht direkt der kurzlebigen Natur von Containern, die entweder von kurzer Dauer sein oder gelöscht werden sollen, wenn sie deaktiviert 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 die Domäne eingebunden werden. Daher können Sie Active Directory-Domänendienste nicht als Infrastrukturrolle für Windows-Container ausführen. Sie können das PowerShell-Modul für die Remoteverwaltung von Domänencontrollern in einem Windows-Container ausführen.

Verwenden Sie für Anwendungen, die auf Active Directory-abhängigen Windows-Containern ausgeführt werden, gruppenverwaltete Dienstkonten (Group Managed Service Accounts, gMSA), die weiter erläutert werden.

Apps mit .NET Framework, Version 2.0 oder älter

Wenn Ihre Anwendung .NET erfordert, hängt ihre Fähigkeit zur Containerisierung vollständig von der version von .NET Framework ab, die sie verwendet. Jede Version vor .NET Framework 2.0 wird überhaupt nicht unterstützt; Höhere Versionen erfordern die Verwendung bestimmter Bilder, wie später beschrieben.

Apps, die Drittanbieterframeworks (nicht von Microsoft) verwenden

Im Allgemeinen ist Microsoft nicht in der Lage, Frameworks oder Anwendungen von Drittanbietern zu zertifizieren oder sie auf Windows-Containern oder physischen und virtuellen Computern zu unterstützen. Microsoft führt jedoch eigene interne Tests für die Nutzbarkeit mehrerer Drittanbieterframeworks und -tools durch, darunter Apache, Cassandra, Chocolatey, Datadog, Django, Flask, Git, Golang, JBoss, Jenkins, Rust, Nodejs, Pearl, Python, Ruby, Tomcat und viele andere.

Überprüfen Sie bei Drittanbieterframeworks oder -software bitte die Unterstützung für Windows-Container mit dem Anbieter, der es bereitstellt.

Ideale Kandidaten für die Containerisierung

Da wir nun die schwierigen Einschränkungen für Containerisierungs-Apps berücksichtigt haben, ist es einfacher zu sehen, welche Arten von Apps sich leichter für Windows-Container eignen. Die idealen Kandidaten für Windows-Container und alle besonderen Überlegungen zur Containerisierung finden Sie in der folgenden Tabelle.

Anwendungstyp	Warum dies gute Kandidaten sind	Besondere Überlegungen
Konsolenanwendungen	Ohne GUI-Einschränkungen eignen sich Konsolen-Apps ideal für Container.	Verwenden Sie abhängig von den Anforderungen der Anwendung das entsprechende Basiscontainerimage.
Windows-Dienste	Da es sich hierbei um Hintergrundprozesse handelt, die keine direkte Benutzerinteraktion erfordern	Verwenden Sie abhängig von den Anforderungen der Anwendung das entsprechende Basiscontainerimage. Sie müssen einen Vordergrundprozess erstellen, damit alle containerisierten Hintergrundprozesse weiterlaufen. Weitere Informationen finden Sie im Abschnitt zu Hintergrunddiensten weiter unten.
Windows Communication Foundation (WCF)-Dienste	Da sie dienstorientierte Apps sind, die auch im Hintergrund ausgeführt werden	Verwenden Sie abhängig von den Anforderungen der Anwendung das entsprechende Basiscontainerimage. Möglicherweise müssen Sie einen Vordergrundprozess erstellen, damit alle containerisierten Hintergrundprozesse ausgeführt werden. Weitere Informationen finden Sie im Abschnitt zu Hintergrunddiensten weiter unten.
Web-Apps	Webanwendungen sind im Wesentlichen Hintergrunddienste, die auf einen bestimmten Port lauschen und daher hervorragende Kandidaten für die Containerisierung sind, da sie die Skalierbarkeit von Containern nutzen	Verwenden Sie abhängig von den Anforderungen der Anwendung das entsprechende Basiscontainerimage.

Hinweis: Selbst diese idealen Kandidaten für die Containerisierung können sich auf kerne Windows-Features und -Komponenten verlassen, die in Windows-Containern unterschiedlich behandelt werden müssen. Der nächste Abschnitt, der ausführlichere Informationen zu solchen praktischen Überlegungen enthält, bereitet Sie besser auf die Nutzung der Funktionalität von Windows-Containern vor.

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

Bei Projekten zur App-Renovierung wird in der Regel berücksichtigt, ob eine bestimmte App über die Perspektive der Geschäftsfunktion der App containerisiert werden kann. Aber die Geschäftsfunktionalität ist nicht der Faktor, der bestimmt, ob es technisch möglich ist. Wichtig ist die Architektur der App, d. h., auf welche technischen Komponenten sie sich stützt. Daher gibt es keine einfache Antwort auf eine Frage wie "Kann ich meine HR-Anwendung containerisieren?", da es nicht darum geht, was die Anwendung tut, sondern wie sie funktioniert und welche Windows-Komponenten/Dienste sie verwendet, die den Unterschied ausmachen.

Dies ist eine wichtige Unterscheidung, da es wahrscheinlich schwieriger ist, Ihre Anwendung in Container umzuwandeln, wenn sie nicht von Anfang an mit einer Microservices-Architektur entwickelt wurde. Während Sie mit der Containerisierung fortfahren, benötigen bestimmte Features möglicherweise eine spezielle Behandlung. Einige sind möglicherweise auf die Verwendung der wichtigsten Windows-Komponenten und Frameworks zurückzuführen, die in Windows-Containern nicht unterstützt werden. Andere, z. B. Ereignisprotokollierung und -überwachung, sind auf inhärente Unterschiede zwischen Linux und Windows zurückzuführen, die nur dann sichtbar werden, wenn Sie die App containerisieren. Andere, z. B. geplante Aufgaben und Hintergrunddienste, müssen aus der Perspektive verstanden werden, dass ein Container kein virtueller Computer ist, sondern kurzlebig ist und daher besondere Behandlung erfordert.

In der folgenden Tabelle finden Sie eine kurze Zusammenfassung der Komponenten/Features von Anwendungen, die bei der Containerisierung besondere Überlegungen erfordern. Die folgenden Unterabschnitte enthalten weitere Details, einschließlich Beispiele, die Techniken für die Behandlung der einzelnen Szenarien veranschaulichen. Die nachstehende Liste behandelt zwar Szenarien, die unter Windows-Containern unterstützt werden, diese Szenarien müssen jedoch die Anleitungen aus dem vorherigen Kapitel beachten. Während Hintergrunddienste beispielsweise unterstützt werden, wird das Ausführen eines Hintergrunddiensts unter .NET Framework 1.1 nicht unterstützt.

Windows-Feature/-Komponente, die eine spezielle Behandlung erfordert	Grund
Microsoft Message Queuing (MSMQ)	MSMQ stammt lange vor Containern 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 ist identisch mit einer VM, aber es gibt wichtige Überlegungen beim Ausführen in einer Containerumgebung, z. B. Zertifikatverwaltung, Datenbankverbindungszeichenfolgen und vieles mehr.
Geplante Vorgänge	Windows-Container können geplante Aufgaben wie jede Windows-Instanz ausführen. Es muss jedoch möglicherweise eine Vordergrundaufgabe ausgeführt werden, damit die Containerinstanz weiter ausgeführt wird. Je nach Anwendung sollten Sie möglicherweise einen ereignisgesteuerten Ansatz in Betracht ziehen.
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 (früher .Net Core)	Stellen Sie sicher, dass Sie das richtige Bild verwenden, um die Kompatibilität sicherzustellen, wie im Unterabschnitt unten erläutert.

Weitere unterstützende Komponenten

Komponente, die spezielle Handhabung erfordert	Grund	Alternativer Ansatz
Ereignisprotokollierung/-überwachung	Da sich die Art und Weise, wie Windows Ereignisse und Protokolle schreibt, von Linux stdout unterscheidet	Verwenden Sie das neue Protokollmonitor-Tool, um die Daten zu normalisieren und aus Linux und Windows zu kombinieren.
Sicherheit von Windows-Containern	Während viele Sicherheitspraktiken gleich bleiben, erfordern Container zusätzliche Sicherheitsmaßnahmen.	Verwenden Sie ein zweckorientiertes Registrierungs- und Bildscantool – weitere Details später.
Sicherung von Windows-Containern	In Containern dürfen keine Daten oder Zustände gespeichert werden.	Sichern Sie alle persistenten Speicher, die von Containern verwendet werden, sowie Containerimages.

Windows-Komponenten/-Features

Nun befassen wir uns mit den Details von Anwendungen und Komponenten, die containerisiert werden können, erfordern jedoch eine zusätzliche Handhabung.

MSMQ

Wenn Ihre Anwendung von MSMQ abhängig ist, hängt die Möglichkeit, sie zu containerisieren, von ihrem MSMQ-Bereitstellungsszenario ab. MSMQ enthält mehrere Bereitstellungsoptionen. Die Faktoren privater und öffentlicher Warteschlangen, Transaktions- oder Nicht-Warteschlangen und Authentifizierungstyp bilden eine Matrix von Szenarien, die MSMQ ursprünglich für die Unterstützung entwickelt hat. Nicht alle dieser Elemente können einfach in Windows-Container verschoben werden. In der folgenden Tabelle sind die szenarien aufgeführt, die unterstützt werden:

Umfang	Transaktional?	Standort der Warteschlange	Authentifizierungstyp	Senden und Empfangen?
Privat	Ja	Gleicher Container (einzelner Container)	Anonym	Ja
Privat	Ja	Persistentes Volume	Anonym	Ja
Privat	Ja	Domänencontroller	Anonym	Ja
Privat	Ja	Einzelner Host (zwei Container)	Anonym	Ja
Öffentlich	Nein	Zwei Gastgeber	Anonym	Ja
Öffentlich	Ja	Zwei Gastgeber	Anonym	Ja

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

• Isolationsmodus: Sowohl der Prozessmodus als auch Hyper-V Modus für die Isolation funktionieren mit den oben aufgeführten Szenarien.
• Minimales Betriebssystem- und Containerimage: Die minimale Betriebssystemversion, die für die Verwendung mit MSMQ empfohlen wird, ist Windows Server 2019.
• Persistente Volumes: Die oben genannten Szenarien wurden überprüft, in denen MSMQ auf Azure Kubernetes Service (AKS) mit Azure-Dateien für beständigen Speicher ausgeführt wird.

Wenn Sie diese Überlegungen mit der obigen Tabelle zusammensetzen, können Sie sehen, dass das einzige Szenario, das nicht unterstützt wird, für Warteschlangen gilt, die eine Authentifizierung mit Active Directory erfordern. Die Integration von gMSAs (Group Managed Service Accounts) mit MSMQ wird derzeit nicht unterstützt, da MSMQ Abhängigkeiten von Active Directory aufweist, die noch nicht vorhanden sind.

Verwenden Sie alternativ Azure Service Bus anstelle von MSMQ. Azure Service Bus ist ein vollständig verwalteter Nachrichtendienst für Unternehmen mit Nachrichtenwarteschlangen und Veröffentlichungs- und Abonnementthemen (in einem Namespace). Der Wechsel von MSMQ zu Azure Service Bus erfordert Codeänderungen und Anwendungs-Neuarchitektur, bietet Ihnen jedoch die Flexibilität, auf eine moderne Plattform zu wechseln.

MSDTC

Microsoft Distributed Transaction Coordinator (MSDTC) wird in Windows-Legacyanwendungen unter großen Unternehmen stark verwendet. MSDTC kann unter Windows-Containern installiert werden, aber es gibt bestimmte Szenarien, die nicht funktionieren und nicht in Windows-Containern reproduziert werden können.

• Achten Sie beim Erstellen des Containers darauf, den Parameter "-name" an den Docker-Run-Befehl zu übergeben. Dieser Namensparameter ermöglicht es den Containern, über das Docker-Netzwerk zu kommunizieren. Wenn Sie gMSA verwenden, muss der Name mit dem Hostnamen übereinstimmen, der mit dem gMSA-Kontonamen übereinstimmen muss.
  • Hier ist ein Beispiel für den Befehl "Ausführen" 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 unter Verwendung des NETBIOS-Namens gegenseitig auflösen können. Wenn es damit Schwierigkeiten gibt, ist es am besten, den Namen und die IP-Adresse der Container zu den Hostdateien der jeweils anderen hinzuzufügen.
• Die uuid für msdtc auf beiden Containern muss eindeutig sein. Die uuid kann gefunden werden, indem Sie "Get-Dtc" in PowerShell auf den Containern ausführen. Wenn sie nicht eindeutig sind, besteht eine Möglichkeit zum Beheben darin, msdtc auf einem der Container zu deinstallieren und neu zu installieren. Dazu können die PowerShell-Befehle „uninstall-dtc“ und „install-dtc“ verwendet werden.
• Derzeit wird MSDTC für Azure Kubernetes Services nicht unterstützt. Wenn Sie MSDTC auf AKS ausführen müssen, informieren Sie das Windows-Containerteam, indem Sie das Problem beim Windows-Container-Repository auf GitHub öffnen.

Funktionsweise von IIS in einem Container im Vergleich zu einer VM

IIS funktioniert auf einem Windows-Container wie in einem virtuellen Computer. Es gibt jedoch einige Aspekte der Ausführung einer IIS-Instanz, die bei der Ausführung in einer Containerumgebung berücksichtigt werden sollte:

• Beständiger Speicher für lokale Daten: Ordner, in denen die App Dateien schreibt/ausliest, sind ein großartiges Beispiel für etwas, das Sie in einer VM für eine IIS-Instanz beibehalten würden. Bei Containern möchten Sie keine Daten direkt in den Container schreiben. Container verwenden einen "Scratch Space" für den lokalen Speicher und wenn ein neuer Container für dieselbe Anwendung angezeigt wird, hat er keinen Zugriff auf diesen Bereich von einem vorherigen Container. Verwenden Sie daher beständigen Speicher für Daten, auf die für die Webanwendung zugegriffen werden muss, damit jede Containerinstanz Zugriff auf diesen Speicher haben kann.
• Zertifikate: Obwohl Sie lokale Zertifikate auf Containerinstanzen haben können, vermeiden Sie dies, denn wenn ein Zertifikat aktualisiert werden muss, müssen Sie das Containerimage neu erstellen. Alternativ können Sie einen Container-Orchestrator mit Ingress-Kontrolle verwenden. Ingress-Controller können Netzwerkrichtlinien anwenden und auch die Zertifikatsverwaltung für die Website übernehmen, die dahinter gehostet wird. Der Nachteil besteht darin, dass Sie die Zertifikatlebenszyklusverwaltung von der Websiteverwaltung entkoppeln.
• Datenbankverbindungszeichenfolgen: Bei der herkömmlichen IIS-Bereitstellung können Sie die DB-Verbindungszeichenfolge als Teil der Anwendungsbereitstellung übergeben. Windows-Container ermöglichen es Ihnen zwar, diesem Modell zu folgen, sie sollten jedoch in Erwägung ziehen, die DB-Verbindungszeichenfolge vom Container in eine zentralisierte Konfiguration zu entkoppeln, die vom Container orchestrator bereitgestellt wird, aus der die Anwendung lesen kann. Auf diese Weise können Sie die DB-Verbindungszeichenfolge unabhängig von der Anwendung verwalten und aktualisieren. Wenn sich die DB ändert (z. B. für "Lift" und "Shift" in die Cloud), können Sie die Verbindungszeichenfolge ganz einfach ändern, ohne das Containerimage neu zu erstellen. Mit diesem Ansatz können Sie auch geheime Schlüssel (z. B. Benutzername und Kennwort für die Verbindung mit der DB) in einem geheimen Speicher aufbewahren.
• Horizontale automatische Skalierung: Wenn die Last steigt, verlangsamen Rechensysteme die wahrgenommene Leistung, während sie versuchen, die gleichzeitigen Anforderungen zu verarbeiten. Es gibt in der Regel zwei Möglichkeiten, um Leistungseinbußen zu vermeiden: vertikale oder horizontale Skalierung. Die vertikale Skalierung erhöht die für die vorhandenen Computeinstanzen verfügbaren Ressourcen (mehr CPU, Arbeitsspeicher usw.). Die horizontale Skalierung erhöht die Anzahl der Instanzen, die die Anforderungen unterstützen (physischere Hosts oder VMs oder Container). Bei Webebenen wie IIS ist die horizontale Skalierung tendenziell effizienter als vertikal, aber lokale Umgebungen können auf Ressourcenbeschränkungen und Lastenausgleichsprobleme stoßen. Bei Cloudumgebungen ist die horizontale Skalierung viel einfacher, da Ressourcen leicht verfügbar sind (für zusätzliche Kosten), und der Cloudanbieter entwirft in der Regel seinen Lastenausgleichsmechanismus mit horizontaler Skalierung. Windows-Container können horizontale Skalierung für IIS nutzen, aber der kurzlebige Aspekt von Containern spielt eine wichtige Rolle. Es ist zwingend erforderlich, dass Ihre Container über die gleiche Konfiguration verfügen und dass kein Zustand oder keine Daten gespeichert werden, damit die Anzahl der Instanzen, die Ihre Webanwendung unterstützen, skaliert oder herunterskaliert werden kann.

Geplante Vorgänge

Geplante Aufgaben werden verwendet, um ein Programm, einen Dienst oder ein Skript jederzeit in einer Windows-Umgebung aufzurufen. Traditionell verfügen Sie über eine Windows-Instanz, die jederzeit ausgeführt wird und wenn ein Trigger erfüllt ist, wird die Aufgabe ausgeführt. Dies ist mit Windows-Containern möglich, und – abgesehen davon, dass Sie geplante Aufgaben über Azure PowerShell konfigurieren und verwalten müssen – funktionieren sie genau so.

Bei einem Microservices-Ansatz haben Sie jedoch einige Optionen, um zu vermeiden, dass ein Container ausgeführt wird, um auf einen Trigger zu warten:

• Verwenden Sie einen ereignisgesteuerten PaaS (Platform as a Service), z. B. Azure Function, 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 Sie Windows-Container in Verbindung mit einem Container-Orchestrator. 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. Service Monitor), damit der Container weiter ausgeführt wird.

Hintergrunddienste

Obwohl Container im Allgemeinen für flüchtige Prozesse gedacht sind, können Sie eine Hintergrund-, langfristig ausgeführte Anwendung containerisieren, vorausgesetzt, Sie erstellen einen Vordergrundprozess, um sie zu starten und am Laufen zu halten.

Ein großartiges Beispiel hierfür ist ServiceMonitor, eine ausführbare Windows-Datei, die als Einstiegspunktprozess beim Ausführen von IIS in Containern verwendet werden soll. Obwohl es für IIS erstellt wurde, bietet das ServiceMonitor-Tool ein Modell, das auch zum Überwachen anderer Dienste verwendet werden kann, mit einigen Einschränkungen.

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 (früher .NET Core). Das .NET-Team erstellt eigene offizielle Images für beide Frameworks, die auf den Windows-Basiscontainerimages basieren. Die Auswahl des entsprechenden Images ist wichtig, um die Kompatibilität zu gewährleisten. Das .NET-Team stellt .Net Framework-Images über dem Server Core-Basiscontainerimage und .NET-Images auf dem Server Core- und Nano Server-Basiscontainerimage bereit. Server Core verfügt über einen größeren API-Satz als Nano Server, der eine höhere Kompatibilität, aber auch eine größere Bildgröße ermöglicht. Nano Server verfügt über eine stark reduzierte API-Oberfläche, aber eine viel kleinere Bildgröße.

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

Beispielsweise ist bei den Server Core- und Nano Server-Basiscontainerimages nur eine Schriftart verfügbar, um die Bildgröß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ätsgründen lässt dies praktisch jede App (sofern sie die Art von Containern, wie z. B. keine GUI) berücksichtigen, containerisiert werden. Auf der Anderen Seite werden sie viel größer sein, was sich auf die Leistung auswirken kann.

Bei der Überprüfung, ob die zu containerisierende Anwendung unter Windows-Containern funktioniert, empfiehlt Microsoft Folgendes:

Framework	Testen mit diesem Containerimage zuerst	Zurückgreifen auf dieses Container-Image, wenn das erste nicht funktioniert	Basisbild
.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 Ihres .NET Framework-Containerimages mit Server- oder Windows-Images	Windows Server Core
.NET 6 oder 7	.NET 6 bzw. 7	Erstellen Ihres .NET-Containerimages mit Windows- oder Server-Basisimages	Windows Nano Server oder Server Core

Weitere unterstützende Komponenten

Die folgenden Komponenten und Themen enthalten zusätzliche Anleitungen für Elemente, die zusammenkommen oder eine bessere Klarheit in Windows-Containern bieten.

Ereignisprotokollierung

Windows und Linux verwenden verschiedene Methoden zum Speichern und Präsentieren von Protokollen und Ereignissen für die Benutzer. Traditionell hat Windows das EVT-Format verwendet, das in der Ereignisanzeige strukturiert angezeigt werden kann. Linux hat dagegen einen optimierten Ansatz mit Standard output (stdout) bereitgestellt, auf den andere Tools wie Docker basieren.

Docker verfügte immer über einen Mechanismus zum Extrahieren von Protokollen aus Linux-Containern. Mit dem Befehl "Docker logs" mit einer standard-Stdout-Konfiguration bringt Docker Anwendungsprotokolle aus dem Container heraus, ohne den Container interaktiv zu öffnen. Bis zum Start des Log Monitor-Tools funktionierte dasselbe Verfahren unter Windows jedoch nicht.

Das Protokollmonitor-Tool stellt die Windows-Protokolle im Stdout-Format dar, sodass andere Tools, z. B. Docker, die erforderlichen Informationen sammeln können, um sie anzuzeigen. Zu den weiteren Vorteilen bei der Verwendung des Protokollmonitors gehören die folgenden:

• Es ist möglich zu filtern, welche Arten von Ereignissen/Protokollen Sie für stdout verfügbar machen möchten. Sie können z. B. das Anwendungsprotokoll nur nach "Error"- und "Warnmeldungen" filtern, wenn Sie nicht an "Informationsereignissen" interessiert sind.
• Die Möglichkeit, aus Ereignisprotokollen, benutzerdefinierten Protokolldateien oder Ereignisablaufverfolgung für Windows (ETW) auszuwählen. Dies ist besonders hilfreich, wenn Ihre Anwendung in einer anderen Protokollquelle schreibt. 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 von Docker zu ContainerD als Containerlaufzeitumgebung wechseln, sollten die Protokolle weiterhin vom Containerhost über "crictl logs" sichtbar sein.

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

Sicherheit von Windows-Containern

Windows-Container basieren auf derselben Basis wie Windows-Instanzen, die auf physischen oder virtuellen Computern ausgeführt werden. Das Verständnis der Besonderheiten der Implementierung von Containern, insbesondere der art des gemeinsam genutzten Kernels, hilft Ihnen, eine containerisierte Anwendung zu sichern:

• Gemeinsam genutzte Komponenten. Windows-Container teilen einige komponenten des Hosts für Sicherheitszwecke. Dazu gehören die Windows-Firewall, Windows Defender (Antivirus) und andere Einschränkungen des Ressourcenzugriffs. Sie müssen diese Komponenten nicht direkt auf Ihrem Container konfigurieren, da der Containerhost die erforderlichen Anpassungen basierend auf Ihrer Containerarbeitsauslastung vorschreibt. Wenn der Container beispielsweise eine Webanforderung vorlegt, leitet der Containerhost den erforderlichen Datenverkehr über seine Firewall weiter, damit der Container auf das Web zugreifen kann.
• Isolationsmodus: Wie bereits erwähnt, können Windows-Container im Prozess- oder Hyper-V Isolationsmodus bereitgestellt werden, wobei Hyper-V die sicherste Isolation bereitstellen. In der Prozessisolation teilt der Container seinen Kernel, das Dateisystem und die Registrierung mit dem Host, wodurch ein Prozess mit erhöhten Rechten (Administrator) mit den Containerprozessen und -diensten interagieren kann. Die Auswahl des richtigen Isolationsmodus für Ihre Anwendung ist wichtig, um das entsprechende Sicherheitsmodell sicherzustellen.
• Windows-Updates: Da der Wartungsstapel in Windows-Containern nicht vorhanden ist, erhalten Windows-Container keine Updates wie allgemeine Windows-Instanzen. Stattdessen müssen Sie Windows-Container mithilfe des neuesten verfügbaren Basiscontainerimages neu erstellen. Kunden können DevOps-Pipelines für diesen Zweck nutzen. Microsoft aktualisiert die Basiscontainerimages für alle offiziellen Images jeden Monat im Patch Tuesday-Rhythmus.
• Containerbenutzerkonto. Standardmäßig werden Anwendungen in Windows-Containern mit erhöhten Rechten unter dem ContainerAdmin-Benutzerkonto ausgeführt. Dies ist hilfreich für die Installation und Konfiguration der erforderlichen Komponenten innerhalb des Containerimages. Sie sollten jedoch erwägen, das Benutzerkonto in ContainerUser zu ändern, wenn eine Anwendung ausgeführt wird, die keine erhöhten Berechtigungen erfordert. Für bestimmte Szenarien können Sie auch ein neues Konto mit den entsprechenden Berechtigungen erstellen.
• Image- und Runtimeüberprüfungen: Container erfordern, dass Images in Repositorys und Containerinstanzen sicher sind. Microsoft empfiehlt, Microsoft Defender für Container für die Image-Überprüfung und Laufzeit-Überprüfung zu verwenden. Defender für Container unterstützt Windows-Container für die Sicherheitsrisikobewertung mit Registrierungsscans und Laufzeitschutz mit Bedrohungserkennung.

Weitere Informationen zu den oben genannten Themen finden Sie auf der Dokumentationsseite von Windows-Containern .

Sicherung von Windows-Containern

Sie müssen bei der Verwendung von Containern anders an Sicherungen denken. Wie bereits erwähnt, sollte ein Container aufgrund seiner kurzlebigen Natur nicht zum Speichern von Zustand oder Daten verwendet werden. Wenn Sie den Zustand und die Daten von der Containerinstanz trennen, befinden sich Ihre Sicherungsbedenken außerhalb der Laufzeit der Containerinstanz, die durch eine neue ersetzt werden kann, für die alle erforderlichen beständigen Speicher weiterhin verfügbar sind.

Es gibt jedoch noch Komponenten, die Sie sichern müssen, einschließlich der Anwendung, des Containerimages und der Dockerfile-Datei, die das Containerimage erstellt. Die meisten dieser Vorgänge werden von der Plattform verarbeitet, auf der Sie Ihre Produktions- und Entwicklungsworkloads ausführen. Berücksichtigen Sie bei der Einführung eines DevOps-Ansatzes die am häufigsten verwendeten Fälle:

• Anwendung: Ihre Anwendung befindet sich wahrscheinlich in einem Quell-Repository wie GitHub oder Azure DevOps. Diese Repositorys stellen die Versionssteuerung bereit, mit der Sie wieder auf eine bestimmte Version der Anwendung zurücksetzen können. Wenn Sie der Besitzer des Quell-Repositorys sind, müssen Sie den Empfehlungen für Sicherung und Verwaltung folgen.
• Containerimage: Für Produktionsumgebungen sollte Ihr Containerimage in einem zentralen Image-Repository wie Azure Container Registry (ACR) gespeichert sein. Sie können Ihre Container-Images in ACR übertragen, damit sie anderen Hosts zum Herunterladen zur Verfügung stehen. ACR gewährleistet die Verfügbarkeit der Container-Images und dient als Sicherungsoption. Beachten Sie jedoch, dass ACR nicht verhindert, dass ein Image gelöscht oder überschrieben wird. Befolgen Sie für jedes andere lokale oder vor Ort befindliche Image-Repository die Empfehlung des Anbieters, vorhandene Registries zu sichern.
• Dockerfile: Dockerfiles erstellen neue Containerimages und werden in der Regel zusammen mit der Anwendungsquelle gespeichert. Da die Dockerfile möglicherweise nicht mit der Anwendung erstellt wurde, insbesondere wenn es sich um eine vorhandene Anwendung handelt, die containerisiert wird, müssen Sie sicherstellen, dass die Dockerfile-Datei an einem sicheren und gesicherten Speicherort gespeichert ist. Sie sollten auch sicherstellen, dass alle anderen Ressourcen, die für ihre Anwendung erforderlich sind, in einem Container gesichert werden; Beispiel: YAML- und JSON-Dateien für Kubernetes-, Docker-Schwarm- und Azure ARM-Vorlagen befolgen die gleichen Richtlinien wie oben.

Planen des Lift & Shift-Prozesses

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

1. Ermitteln Sie das windows-Betriebssystembasisimage, das Sie benötigen: Windows Server Core-, Nano Server-, Windows-oder Server- Images.
2. Bestimmen Sie den Typ des Isolationsmodus für den Container: Wählen Sie zwischen Prozess- oder Hyper-V Isolationsmodi aus. Hinweis: Derzeit unterstützen AKS und AKS auf Azure Stack HCI nur prozessisolte Container. In einer zukünftigen Version werden sowohl AKS als auch AKS auf Azure Stack HCI hyper-V-isolierte Container unterstützen. Weitere Informationen finden Sie unter Isolationsmodi.
3. Wählen Sie die richtige Windows Server-Version für Ihre Anwendung für App-Compat-Zwecke aus. Die minimale Windows Server-Version für Container ist Windows Server 2016, aber Windows Server 2019 und Windows Server 2022 sind die einzigen Containerhostbetriebssysteme, die auf AKS und AKS auf Azure Stack HCI unterstützt werden.
4. Stellen Sie sicher, dass die Sicherheitsrichtlinien Ihres Unternehmens für die Containerumgebung vorhanden sind. Dazu gehört auch die Anpassung an containerspezifische Anforderungen, z. B. Die Überprüfung der Registrierung und die Bedrohungserkennung.
5. Berücksichtigen Sie die Anforderungen des Lastenausgleichs. Container selbst werden nicht verschoben; Sie können stattdessen einen Orchestrator verwenden, um Container auf Clusterknoten automatisch zu starten oder zu beenden, oder um Änderungen beim Laden und der Verfügbarkeit mit automatischer horizontaler Skalierung zu verwalten.
6. Berücksichtigen Sie die Orchestrierungsanforderungen. Nach der Containerisierung benötigt Ihre Anwendung wahrscheinlich eine automatisierte Verwaltung, die mit Tools wie Kubernetes, AKS oder AKS auf 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. Übertragen Sie die App an ein Bild-Repository. Dadurch können die Containerhosts das Image in einer beliebigen Umgebung herunterladen, einschließlich Entwicklungs-, Test- und Produktionsumgebung.

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 auf der Dokumentationsseite Azure Migrate.