Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Grundlegendes zur Migrationszuordnung von IIS zu Elastic Beanstalk
Die Migration von IIS zu Elastic Beanstalk beinhaltet die Zuordnung Ihrer lokalen Windows-Serverkonfiguration zu AWS Cloud-Ressourcen. Das Verständnis dieser Zuordnung ist entscheidend für erfolgreiche Migrationen und das Management nach der Migration.
IIS-Sites und -Anwendungen in Elastic Beanstalk
In IIS stellt eine Website eine Sammlung von Webanwendungen und virtuellen Verzeichnissen mit jeweils eigener Konfiguration und eigenem Inhalt dar. Bei der Migration zu Elastic Beanstalk werden diese Komponenten wie folgt transformiert:
- IIS-Websites
-
Ihre IIS-Websites werden zu Anwendungen innerhalb von Elastic Beanstalk. Die Konfiguration jeder Website, einschließlich ihrer Bindungen, Anwendungspools und Authentifizierungseinstellungen, wird über das Deployment-Manifest () von Elastic Beanstalk beibehalten.
aws-windows-deployment-manifest.json
Wenn Sie beispielsweise mehrere Websites wie Default Web Site und haben IntranetSite, werden die Inhalte und die Konfiguration jeder Site in eb migrate Paketen zusammengefasst, wobei die Isolierung beibehalten wird.
Der Befehl erstellt entsprechende Application Load Balancer (ALB) -Listener-Regeln für die Bearbeitung von Routing-Anfragen an Ihre Anwendungen. Außerdem werden Sicherheitsgruppen konfiguriert, um einen ordnungsgemäßen Portzugriff auf der Grundlage Ihrer ursprünglichen IIS-Bindungen sicherzustellen.
- Anwendungspools
-
IIS-Anwendungspools bieten Funktionen zur Isolierung von Arbeitsprozessen, zur Laufzeitverwaltung und zum Recycling Ihrer Anwendungen. In Elastic Beanstalk werden diese Umgebungsprozessen zugeordnet, die über den
aws:elasticbeanstalk:environment:process
Namespace definiert und über IIS auf den Instances konfiguriert wurden. EC2Bei der Migration werden wichtige Einstellungen für den Anwendungspool beibehalten, darunter die folgenden:
-
Konfigurationen des Prozessmodells — Identität (ApplicationPoolIdentity,, oder benutzerdefinierte Konten) NetworkService, Einstellungen für Leerlauf-Timeouts und Intervalle für die Wiederverwertung von Prozessen
-
.NET CLR-Versionseinstellungen — Behält Ihre angegebene .NET Framework-Version (v2.0, v4.0 oder No Managed Code) bei, um die Anwendungskompatibilität sicherzustellen
-
Verwalteter Pipeline-Modus — Behält die Einstellungen für den integrierten oder klassischen Pipeline-Modus bei, um Ihre Architektur für die HTTP-Anforderungsverarbeitung beizubehalten
-
Erweiterte Einstellungen — Warteschlangenlänge, CPU-Grenzwerte, Schwellenwerte für den Rapid-Fail-Schutz und Startzeitlimits
Der eb migrate Befehl behält die Zuordnungen zwischen Sites und Anwendungspools während der Migration zu Ihrer Elastic Beanstalk Beanstalk-Umgebung bei.
Wenn Ihre Anwendungspools benutzerdefinierte Wiederverwendungszeitpläne (bestimmte Zeiten oder Speichergrenzwerte) verwenden, werden diese mithilfe von PowerShell Skripts im Bereitstellungspaket implementiert, die die entsprechenden IIS-Einstellungen auf den Instances konfigurieren. EC2
-
- Webseiten-Bindungen
-
IIS-Website-Bindungen, die definieren, wie Clients auf Ihre Anwendungen zugreifen, werden in die folgenden Application Load Balancer (ALB) -Konfigurationen umgewandelt:
-
Port-Bindungen werden den entsprechenden ALB-Listener-Regeln zugeordnet
-
Host-Header-Konfigurationen werden in ALB-Routing-Regeln übersetzt
-
SSL-fähige Websites verwenden AWS Certificate Manager (ACM) für die Zertifikatsverwaltung
-
Verwaltung virtueller Verzeichnisse und Anwendungspfade
Virtuelle IIS-Verzeichnisse und -Anwendungen ermöglichen die Zuordnung von URL-Pfaden zu physischen Verzeichnissen. Elastic Beanstalk hält diese Beziehungen mithilfe der folgenden Konstrukte aufrecht:
- Virtuelle Verzeichnisse
-
Beim Migrationsprozess werden die physischen Pfade Ihrer virtuellen Verzeichnisse im Bereitstellungspaket beibehalten.
Pfadzuordnungen werden in der IIS-Konfiguration auf den EC2 Instanzen konfiguriert, sodass sichergestellt wird, dass Ihre URL-Struktur nach der Migration intakt bleibt.
- 2 Physische Pfade des Laufwerks
-
Wichtig
Standardmäßig stellen Elastic Beanstalk Beanstalk-Windows-Umgebungen nur das Laufwerk C:\ (Root-Volume) bereit. In der aktuellen Version werden Anwendungen, deren Inhalt sich auf den Laufwerken „D:\“, E:\ usw. befindet, für die Migration nicht unterstützt.
Der eb migrate Befehl erkennt automatisch physische Pfade, die sich auf den Laufwerken befinden, und warnt Sie vor möglichen Problemen, wie im folgenden Beispiel:
ERROR: Detected physical paths on drive D:\ which are not supported in the current version: - D:\websites\intranet - D:\shared\images Migration of content from non-system drives is not supported. Please relocate this content to the C:\ drive before migration. Otherwise, select only those sites that are on C:\.
Wenn Ihre Anwendung von Laufwerken abhängig ist, müssen Sie Ihre Anwendung so ändern, dass sie vor der Migration den gesamten Inhalt auf Laufwerk C:\ speichert.
- Verschachtelte Anwendungen
-
Unter Websites verschachtelte Anwendungen werden mit den richtigen Pfadkonfigurationen und den entsprechenden Anwendungspoolzuweisungen bereitgestellt. Beim Migrationsprozess werden alle
web.config
Einstellungen beibehalten, sodass sichergestellt wird, dass anwendungsspezifische Konfigurationen in der Cloud-Umgebung weiterhin erwartungsgemäß funktionieren.
URL-Umschreibung und Routing von Anwendungsanfragen (ARR)
Wenn Ihre IIS-Bereitstellung URL Rewrite oder Application Request Routing (ARR) verwendet, werden diese Konfigurationen anhand der folgenden Regeln und Konfigurationen eb migrate behandelt:
- Regeln für das Umschreiben von URLs
-
Regeln zum Umschreiben von URLs aus Ihren
web.config
Dateien werden nach Möglichkeit in ALB-Routing-Regeln übersetzt. Der folgende Eintrag wird beispielsweise zu einer ALB-Listener-Regel, die den Datenverkehr auf der Grundlage von Host-Headern und Pfadmustern leitet. :<!-- Original IIS URL Rewrite Rule --> <rule name="Redirect to WWW" stopProcessing="true"> <match url="(.*)" /> <conditions> <add input="{HTTP_HOST}" pattern="^example.com$" /> </conditions> <action type="Redirect" url="http://www.example.com/{R:1}" /> </rule>
- Weiterleitung von Anwendungsanfragen
-
ARR-Konfigurationen werden durch die Installation von ARR-Funktionen auf EC2 Instanzen beibehalten. Der Migrationsprozess umfasst die folgenden Aufgaben:
-
Konfiguriert die Proxyeinstellungen so, dass sie zu Ihrer Quellumgebung passen
-
Behält die mit ARR verknüpften Regeln zum Umschreiben von URLs bei
-
Struktur des Migrationsartefakts
Bei der Ausführung wird ein strukturiertes Verzeichnis erstellteb migrate, das alle erforderlichen Bereitstellungskomponenten enthält. In der folgenden Liste wird die Verzeichnisstruktur beschrieben:
C:\migration_workspace\
└── .\migrations\latest\
└── upload_target\
├── [SiteName].zip # One ZIP per IIS site
├── aws-windows-deployment-manifest.json
└── ebmigrateScripts\
├── site_installer.ps1 # Site installation scripts
├── arr_configuration.ps1 # ARR configuration scripts
├── permission_handler.ps1 # Permission management
└── firewall_config.ps1 # Windows Firewall rules
Die aws-windows-deployment-manifest.json
Datei ist die zentrale Konfigurationsdatei, die Elastic Beanstalk anweist, wie Sie Ihre Anwendungen bereitstellen. Sehen Sie sich die folgende Beispielstruktur an:
{ "manifestVersion": 1, "deployments": { "msDeploy": [ { "name": "Primary Site", "parameters": { "appBundle": "DefaultWebSite.zip", "iisPath": "/", "iisWebSite": "Default Web Site" } } ], "custom": [ { "name": "ConfigureARR", "scripts": { "install": { "file": "ebmigrateScripts\\arr_configuration.ps1" }, "uninstall": { "file": "ebmigrateScripts\\noop.ps1" }, "restart": { "file": "ebmigrateScripts\\noop.ps1" } } } ] } }
Dieses Manifest stellt die folgenden Ergebnisse für Ihre Migration sicher:
-
Anwendungen werden bereitgestellt, um IIS-Pfade zu korrigieren
-
Benutzerdefinierte Konfigurationen werden angewendet
-
Standortspezifische Einstellungen werden beibehalten
-
Die Reihenfolge der Bereitstellung wird beibehalten