Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Scenari di migrazione avanzati

Questa sezione descrive gli scenari di migrazione avanzati per implementazioni IIS complesse.

Migrazioni multisito con Application Request Routing (ARR)

Il eb migrate comando rileva e conserva automaticamente le configurazioni ARR durante la migrazione. Quando identifica le impostazioni ARR in IISapplicationHost.config, genera gli PowerShell script necessari per reinstallare e configurare ARR sulle istanze di destinazione. EC2

Rilevamento della configurazione ARR

Il processo di migrazione esamina tre sezioni di configurazione chiave in IIS:

Ad esempio, si consideri una configurazione ARR comune in cui un proxy RouterSite in esecuzione sulla porta 80 richiede e viene AdminPortal eseguito rispettivamente sulle porte 8081 APIService e 8082:

<!-- 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>

Il diagramma seguente illustra come queste regole siano nascoste dietro la porta 80 nel server IIS e non siano esposte tramite i gruppi di sicurezza. EC2 Solo la porta 80 è accessibile all'Application Load Balancer e tutto il traffico proveniente da essa viene indirizzato al gruppo di destinazione sulla porta 80.

Il comando seguente può migrare questa configurazione:

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

Processo di migrazione ARR

Il processo di migrazione preserva la configurazione ARR attraverso diversi passaggi.

Integrazione del sistema di bilanciamento del carico

Il processo di migrazione traduce le regole ARR in regole del listener Application Load Balancer (ALB), ove possibile. Ad esempio, la configurazione ARR di cui sopra comporta regole ALB che indirizzano il traffico in base ai modelli di percorso degli URL mantenendo il routing interno sulle istanze. EC2

L'ambiente risultante mantiene la logica di routing ARR sfruttando al contempo l'infrastruttura elastica di cui dispone. AWS Le applicazioni continuano a funzionare come prima, con ARR che gestisce il routing interno mentre Application Load Balancer gestisce la distribuzione del traffico esterno.

Migrazioni multisito senza ARR utilizzando il routing basato su host

Sebbene Application Request Routing (ARR) sia un approccio comune per la gestione di più siti in IIS, puoi anche migrare le implementazioni multisito direttamente su Elastic Beanstalk senza ARR sfruttando le funzionalità di routing basato su host di Application Load Balancer. Questo approccio può ridurre la complessità e migliorare le prestazioni eliminando un livello di routing aggiuntivo.

Panoramica del routing basato su host

In questo approccio, ogni sito IIS è esposto all'esterno dell' EC2 istanza e l'Application Load Balancer indirizza il traffico direttamente alla porta appropriata in base all'intestazione dell'host. Ciò elimina la necessità di ARR mantenendo al contempo la separazione tra le applicazioni.

Prendi in considerazione una configurazione IIS multisito con tre siti, ciascuno con il proprio nome host binding:

<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>

Questi siti sono esposti alle porte 8081, 8082 e 8083 tramite i gruppi di sicurezza. EC2 L'Application Load Balancer li indirizza in base alla configurazione delle regole del listener Load Balancer.

Processo di migrazione

Per migrare questa configurazione su Elastic Beanstalk senza usare ARReb migrate, usa il comando nell'esempio seguente:

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

Il processo di migrazione configura automaticamente l'Application Load Balancer con regole di routing basate su host che indirizzano il traffico verso il gruppo di destinazione appropriato in base all'intestazione dell'host. Ogni gruppo target inoltra il traffico alla porta corrispondente sulle istanze: EC2

Configurazione SSL/TLS

Per proteggere le tue applicazioni con SSL/TLS procedi nel seguente modo:

Con questa configurazione, la terminazione SSL avviene sul sistema di bilanciamento del carico e il traffico viene inoltrato alle istanze tramite HTTP. Ciò semplifica la gestione dei certificati mantenendo al contempo connessioni sicure con i client.

Best practice

Gestione delle directory virtuali

Il eb migrate comando preserva le strutture di directory virtuali durante la migrazione delle applicazioni IIS su Elastic Beanstalk.

Configurazione predefinita delle autorizzazioni

Durante la migrazione delle directory virtuali, eb migrate stabilisce un set di autorizzazioni di base concedendo l'accesso a: ReadAndExecute

Ad esempio, si consideri una tipica struttura di directory virtuale:

<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>

Directory virtuali protette da password

Quando eb migrate incontra directory virtuali protette da password, emette avvisi e richiede un intervento manuale.

Il seguente esempio di configurazione genererà la risposta di avviso che segue l'esempio.

<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.

Per mantenere la protezione tramite password, create uno script di distribuzione personalizzato come il seguente:

# 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

Aggiungi questo script alla tua distribuzione includendolo nel manifesto:

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

Gestione delle autorizzazioni personalizzata

Il eb migrate comando fornisce una struttura per gli script di autorizzazione personalizzati per ospitare applicazioni che richiedono autorizzazioni diverse da quelle predefinite.

$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"
}

Best practice

Segui queste best practice per pianificare, eseguire, monitorare e verificare la migrazione.

Impostazioni personalizzate del pool di applicazioni

Per impostazione predefinita, il eb migrate comando non copia le impostazioni personalizzate del pool di applicazioni. Per preservare le configurazioni personalizzate dei pool di applicazioni, seguite questa procedura per creare e applicare una sezione del manifesto personalizzata.

L'--archive-dirargomento dice eb migrate di usare il codice sorgente creato in precedenza, evitando la creazione di nuovi archivi.

Distribuzione delle versioni precedenti

eb migrateMantiene una cronologia delle migrazioni tramite directory con data e ora e versioni delle applicazioni in Elastic Beanstalk. Ogni migrazione crea un file zip unico che può essere distribuito se necessario.

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

Il collegamento latest simbolico punta sempre alla directory degli elementi di migrazione creata più di recente. Oltre ai registri delle applicazioni e degli errori pertinenti, ogni directory degli elementi di migrazione contiene anche un upload_target.zip file che puoi distribuire su Elastic Beanstalk.

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

Puoi distribuire il file utilizzando: upload_target.zip eb migrate

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