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.

Fortgeschrittene Migrationsszenarien

In diesem Abschnitt werden erweiterte Migrationsszenarien für komplexe IIS-Bereitstellungen behandelt.

Migrationen an mehreren Standorten mit Application Request Routing (ARR)

Der eb migrate Befehl erkennt ARR-Konfigurationen während der Migration automatisch und behält sie bei. Wenn er die ARR-Einstellungen in Ihrem IIS identifiziertapplicationHost.config, generiert er die erforderlichen PowerShell Skripts, um ARR auf den EC2 Zielinstanzen neu zu installieren und zu konfigurieren.

Erkennung der ARR-Konfiguration

Der Migrationsprozess untersucht drei wichtige Konfigurationsabschnitte in IIS:

Stellen Sie sich zum Beispiel eine gängige ARR-Konfiguration vor, bei der ein auf Port 80 RouterSite laufendes Objekt Anfragen an die Ports 8081 bzw. 8082 APIService AdminPortal weiterleitet und auf diesen Ports läuft:

<!-- Original IIS ARR Configuration -->
<rewrite>
    <rules>
        <rule name="Route to API" stopProcessing="true">
            <match url="^api/(.*)$" />
            <action type="Rewrite" url="http://backend:8081/api/{R:1}" />
        </rule>
        <rule name="Route to Admin" stopProcessing="true">
            <match url="^admin/(.*)$" />
            <action type="Rewrite" url="http://backend:8082/admin/{R:1}" />
        </rule>
    </rules>
</rewrite>

Das folgende Diagramm zeigt, wie diese Regeln hinter Port 80 im IIS-Server versteckt sind und nicht über die Sicherheitsgruppen offengelegt werden. EC2 Nur Port 80 ist für den Application Load Balancer zugänglich und der gesamte Datenverkehr von dort wird an Port 80 an die Zielgruppe weitergeleitet.

Mit dem folgenden Befehl kann diese Konfiguration migriert werden:

PS C:\migrations_workspace> eb migrate --sites "RouterSite,APIService,AdminPortal" `
    --copy-firewall-config

ARR-Migrationsprozess

Beim Migrationsprozess wird Ihre ARR-Konfiguration in mehreren Schritten beibehalten.

Integration des Load Balancers

Der Migrationsprozess übersetzt Ihre ARR-Regeln nach Möglichkeit in Application Load Balancer (ALB) -Listener-Regeln. Die obige ARR-Konfiguration führt beispielsweise zu ALB-Regeln, die den Datenverkehr auf der Grundlage von URL-Pfadmustern weiterleiten und gleichzeitig das interne Routing auf den Instances beibehalten. EC2

Die resultierende Umgebung behält Ihre ARR-Routing-Logik bei und nutzt gleichzeitig AWS die elastische Infrastruktur. Ihre Anwendungen funktionieren weiterhin wie zuvor, wobei ARR das interne Routing übernimmt, während der Application Load Balancer die externe Datenverkehrsverteilung verwaltet.

Migrationen an mehreren Standorten ohne ARR mithilfe von hostbasiertem Routing

Application Request Routing (ARR) ist zwar ein gängiger Ansatz für die Verwaltung mehrerer Sites in IIS, aber Sie können Bereitstellungen mit mehreren Standorten auch ohne ARR direkt zu Elastic Beanstalk migrieren, indem Sie die hostbasierten Routing-Funktionen des Application Load Balancers nutzen. Dieser Ansatz kann die Komplexität reduzieren und die Leistung verbessern, indem eine zusätzliche Routing-Ebene entfällt.

Überblick über das hostbasierte Routing

Bei diesem Ansatz wird jede IIS-Site außerhalb der EC2 Instance verfügbar gemacht, und der Application Load Balancer leitet den Datenverkehr basierend auf dem Host-Header direkt an den entsprechenden Port weiter. Dadurch entfällt die Notwendigkeit von ARR, während gleichzeitig die Trennung zwischen Ihren Anwendungen gewahrt bleibt.

Stellen Sie sich eine IIS-Konfiguration mit mehreren Standorten mit drei Standorten vor, von denen jeder über eine eigene Hostnamenbindung verfügt:

<sites>
    <site name="Default Web Site" id="1">
        <bindings>
            <binding protocol="http" bindingInformation="*:8081:www.example.com" />
        </bindings>
    </site>
    <site name="InternalAPI" id="2">
        <bindings>
            <binding protocol="http" bindingInformation="*:8082:api.internal" />
        </bindings>
    </site>
    <site name="ReportingPortal" id="3">
        <bindings>
            <binding protocol="http" bindingInformation="*:8083:reports.internal" />
        </bindings>
    </site>
</sites>

Diese Sites sind über die Sicherheitsgruppen an den Ports 8081, 8082 und 8083 verfügbar. EC2 Der Application Load Balancer leitet sie auf der Grundlage der Load Balancer-Listener-Regelkonfiguration weiter.

Migrationsprozess

Verwenden Sie den eb migrate Befehl im folgenden Beispiel, um diese Konfiguration auf Elastic Beanstalk zu migrieren, ohne ARR zu verwenden:

PS C:\migrations_workspace> eb migrate --sites "Default Web Site,InternalAPI,ReportingPortal"

Der Migrationsprozess konfiguriert den Application Load Balancer automatisch mit hostbasierten Routing-Regeln, die den Traffic auf der Grundlage des Host-Headers an die entsprechende Zielgruppe weiterleiten. Jede Zielgruppe leitet den Traffic an den entsprechenden Port auf Ihren Instances weiter: EC2

SSL/TLS-Konfiguration

Gehen Sie wie folgt vor, um Ihre Anwendungen mit SSL/TLS zu sichern:

Bei dieser Konfiguration erfolgt die SSL-Terminierung am Load Balancer, und der Datenverkehr wird über HTTP an Ihre Instances weitergeleitet. Dies vereinfacht die Zertifikatsverwaltung und gewährleistet gleichzeitig sichere Verbindungen zu Clients.

Bewährte Methoden

Verwaltung virtueller Verzeichnisse

Der eb migrate Befehl behält virtuelle Verzeichnisstrukturen bei der Migration Ihrer IIS-Anwendungen zu Elastic Beanstalk bei.

Standardkonfiguration für Berechtigungen

eb migrateLegt bei der Migration virtueller Verzeichnisse einen Basissatz von Berechtigungen fest, indem ReadAndExecute Zugriff gewährt wird auf:

Stellen Sie sich zum Beispiel eine typische virtuelle Verzeichnisstruktur vor:

<site name="CorporatePortal">
    <application path="/" applicationPool="CorporatePortalPool">
        <virtualDirectory path="/" physicalPath="C:\sites\portal" />
        <virtualDirectory path="/shared" physicalPath="C:\shared\content" />
        <virtualDirectory path="/reports" physicalPath="D:\reports" />
    </application>
</site>

Kennwortgeschützte virtuelle Verzeichnisse

Wenn eb migrate kennwortgeschützte virtuelle Verzeichnisse gefunden werden, werden Warnungen ausgegeben und ein manuelles Eingreifen ist erforderlich.

Das folgende Konfigurationsbeispiel führt zu der Warnantwort, die dem Beispiel folgt.

<virtualDirectory path="/secure" 
                 physicalPath="C:\secure\content"
                 userName="DOMAIN\User"
                 password="[encrypted]" />

[WARNING] CorporatePortal/secure is hosted at C:\secure\content which is password-protected and won't be copied.

Um den Kennwortschutz aufrechtzuerhalten, erstellen Sie ein benutzerdefiniertes Bereitstellungsskript wie das Folgende:

# PS C:\migrations_workspace> cat secure_vdir_config.ps1

$vdirPath = "C:\secure\content"
$siteName = "CorporatePortal"
$vdirName = "secure"
$username = "DOMAIN\User"
$password = "SecurePassword"

# Ensure directory exists
if (-not (Test-Path $vdirPath)) {
    Write-Host "Creating directory: $vdirPath"
    New-Item -Path $vdirPath -ItemType Directory -Force
}

# Configure virtual directory with credentials
Write-Host "Configuring protected virtual directory: $vdirName"
New-WebVirtualDirectory -Site $siteName -Name $vdirName `
    -PhysicalPath $vdirPath -UserName $username -Password $password

# Set additional permissions as needed
$acl = Get-Acl $vdirPath
$rule = New-Object System.Security.AccessControl.FileSystemAccessRule(
    $username, "ReadAndExecute", "ContainerInherit,ObjectInherit", "None", "Allow"
)
$acl.AddAccessRule($rule)
Set-Acl $vdirPath $acl

Fügen Sie dieses Skript zu Ihrer Bereitstellung hinzu, indem Sie es in das Manifest aufnehmen:

{
    "manifestVersion": 1,
    "deployments": {
        "custom": [
            {
                "name": "SecureVirtualDirectory",
                "scripts": {
                    "install": {
                        "file": "secure_vdir_config.ps1"
                    }
                }
            }
        ]
    }
}

Benutzerdefiniertes Berechtigungsmanagement

Der eb migrate Befehl bietet ein Framework für benutzerdefinierte Berechtigungsskripten für Anwendungen, für die andere Berechtigungen als die Standardberechtigungen erforderlich sind.

$paths = @(
    "C:\sites\portal\uploads",
    "C:\shared\content"
)

foreach ($path in $paths) {
    if (-not (Test-Path $path)) {
        Write-Host "Creating directory: $path"
        New-Item -Path $path -ItemType Directory -Force
    }

    $acl = Get-Acl $path

    # Add custom permissions
    $customRules = @(
        # Application Pool Identity - Full Control
        [System.Security.AccessControl.FileSystemAccessRule]::new(
            "IIS AppPool\CorporatePortalPool", 
            "FullControl", 
            "ContainerInherit,ObjectInherit", 
            "None", 
            "Allow"
        ),
        # Custom Service Account
        [System.Security.AccessControl.FileSystemAccessRule]::new(
            "NT SERVICE\CustomService", 
            "Modify", 
            "ContainerInherit,ObjectInherit", 
            "None", 
            "Allow"
        )
    )

    foreach ($rule in $customRules) {
        $acl.AddAccessRule($rule)
    }
    
    Set-Acl $path $acl
    Write-Host "Custom permissions applied to: $path"
}

Bewährte Methoden

Folgen Sie diesen bewährten Methoden, um Ihre Migration zu planen, auszuführen, zu überwachen und zu verifizieren.

Benutzerdefinierte Einstellungen für den Anwendungspool

Der eb migrate Befehl kopiert standardmäßig keine benutzerdefinierten Anwendungspool-Einstellungen. Um benutzerdefinierte Anwendungspoolkonfigurationen beizubehalten, gehen Sie wie folgt vor, um einen benutzerdefinierten Manifestabschnitt zu erstellen und anzuwenden.

Das --archive-dir Argument weist eb migrate an, den zuvor erstellten Quellcode zu verwenden, um die Erstellung neuer Archive zu vermeiden.

Bereitstellung früherer Versionen

Der eb migrate führt eine Historie Ihrer Migrationen anhand von Verzeichnissen und Anwendungsversionen mit Zeitstempel in Elastic Beanstalk. Bei jeder Migration wird eine einzigartige ZIP-Datei erstellt, die bei Bedarf bereitgestellt werden kann.

PS C:\migrations_workspace> ls .\migrations\

Mode                LastWriteTime         Length Name
----                -------------         ------ ----
d----l        3/18/2025  10:34 PM                latest
d-----        3/16/2025   5:47 AM                migration_1742104049.479849
d-----        3/17/2025   9:18 PM                migration_1742246303.18056
d-----        3/17/2025   9:22 PM                migration_1742246546.565739
...
d-----        3/18/2025  10:34 PM                migration_1742337258.30742

Der latest symbolische Link verweist immer auf das zuletzt erstellte Migrationsartefaktverzeichnis. Zusätzlich zu den relevanten Anwendungs- und Fehlerprotokollen enthält jedes Migrationsartefaktverzeichnis auch eine upload_target.zip Datei, die Sie auf Elastic Beanstalk bereitstellen können.

PS C:\migrations_workspace> ls .\migrations\latest\

Mode                LastWriteTime         Length Name
----                -------------         ------ ----
d-----        3/18/2025  10:34 PM                upload_target
-a----        3/18/2025  10:34 PM          13137 application.log
-a----        3/18/2025  10:34 PM              0 error.log
-a----        3/18/2025  10:34 PM        1650642 upload_target.zip

Sie können die Datei wie folgt bereitstellen: upload_target.zip eb migrate

PS C:\migrations_workspace> eb migrate --zip .\migrations\latest\upload_target.zip