Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Escenarios de migración avanzada

En esta sección se describen los escenarios de migración avanzada para implementaciones de IIS complejas.

Migraciones de varios sitios con enrutamiento de solicitudes de aplicaciones (ARR)

El eb migrate comando detecta y conserva automáticamente las configuraciones de ARR durante la migración. Cuando identifica la configuración de ARR en su IISapplicationHost.config, genera los PowerShell scripts necesarios para volver a instalar y configurar ARR en las EC2 instancias de destino.

Detección de configuración de ARR

El proceso de migración examina tres secciones clave de configuración en IIS:

Por ejemplo, considere una configuración ARR común en la que una RouterSite ejecución en el puerto 80 envía solicitudes a los puertos 8081 APIService y AdminPortal 8082 y 8082, respectivamente:

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

El siguiente diagrama muestra cómo estas reglas se ocultan detrás del puerto 80 del servidor IIS y no se exponen a través de los EC2 grupos de seguridad. El Application Load Balancer solo tiene acceso al puerto 80 y todo el tráfico procedente de él se enruta al grupo de destino en el puerto 80.

El siguiente comando puede migrar esta configuración:

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

Proceso de migración a ARR

El proceso de migración conserva la configuración de ARR mediante varios pasos.

Integración del balanceador de carga

El proceso de migración convierte las reglas de ARR en reglas de escucha de Application Load Balancer (ALB) siempre que es posible. Por ejemplo, la configuración de ARR anterior da como resultado reglas de ALB que enrutan el tráfico en función de los patrones de rutas de URL y, al mismo tiempo, mantienen el enrutamiento interno en las instancias. EC2

El entorno resultante mantiene la lógica de enrutamiento ARR y, al mismo tiempo, aprovecha la infraestructura elástica AWS de la empresa. Sus aplicaciones seguirán funcionando como antes: ARR gestiona el enrutamiento interno mientras que Application Load Balancer gestiona la distribución del tráfico externo.

Migraciones de varios sitios sin ARR mediante enrutamiento basado en host

Si bien el enrutamiento de solicitudes de aplicaciones (ARR) es un enfoque común para administrar varios sitios en IIS, también puede migrar las implementaciones de varios sitios directamente a Elastic Beanstalk sin ARR aprovechando las capacidades de enrutamiento basado en host de Application Load Balancer. Este enfoque puede reducir la complejidad y mejorar el rendimiento al eliminar una capa de enrutamiento adicional.

Descripción general del enrutamiento basado en host

En este enfoque, cada sitio de IIS se expone fuera de la EC2 instancia y el Application Load Balancer dirige el tráfico directamente al puerto correspondiente en función del encabezado del host. Esto elimina la necesidad de utilizar ARR y, al mismo tiempo, mantiene la separación entre las aplicaciones.

Considere una configuración de IIS multisitio con tres sitios, cada uno con su propio enlace de nombre de host:

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

Estos sitios están expuestos en los puertos 8081, 8082 y 8083 a través de los grupos de seguridad. EC2 El Application Load Balancer se dirige a ellos en función de la configuración de la regla de escucha del Load Balancer.

Proceso de migración

Para migrar esta configuración a Elastic Beanstalk sin usar ARR, eb migrate utilice el comando del siguiente ejemplo:

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

El proceso de migración configura automáticamente el Application Load Balancer con reglas de enrutamiento basadas en el host que dirigen el tráfico al grupo objetivo adecuado en función del encabezado del host. Cada grupo objetivo reenvía el tráfico al puerto correspondiente de las instancias: EC2

Configuración de SSL/TLS

Para proteger sus aplicaciones con SSL/TLS, siga estos pasos:

Con esta configuración, la terminación de SSL se produce en el balanceador de cargas y el tráfico se reenvía a las instancias a través de HTTP. Esto simplifica la administración de los certificados y, al mismo tiempo, mantiene las conexiones seguras con los clientes.

Prácticas recomendadas

Administración de directorios virtuales

El eb migrate comando conserva las estructuras de directorios virtuales al migrar las aplicaciones de IIS a Elastic Beanstalk.

Configuración de permisos predeterminada

Al migrar directorios virtuales, eb migrate establece un conjunto básico de permisos al conceder ReadAndExecute acceso a:

Por ejemplo, considere una estructura de directorios virtuales típica:

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

Directorios virtuales protegidos con contraseña

Cuando eb migrate encuentra directorios virtuales protegidos por contraseña, emite advertencias y requiere una intervención manual.

El siguiente ejemplo de configuración generará la respuesta de advertencia que sigue al ejemplo.

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

Para mantener la protección mediante contraseña, cree un script de despliegue personalizado como el siguiente:

# 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

Añada este script a su despliegue incluyéndolo en el manifiesto:

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

Administración de permisos personalizada

El eb migrate comando proporciona un marco para que los scripts de permisos personalizados se adapten a las aplicaciones que requieren permisos distintos de los predeterminados.

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

Prácticas recomendadas

Siga estas prácticas recomendadas para planificar, ejecutar, supervisar y verificar la migración.

Configuración personalizada del grupo de aplicaciones

De forma predeterminada, el eb migrate comando no copia la configuración personalizada del grupo de aplicaciones. Para conservar las configuraciones personalizadas del grupo de aplicaciones, siga este procedimiento para crear y aplicar una sección de manifiesto personalizada.

El --archive-dir argumento indica eb migrate que hay que utilizar el código fuente que creó previamente, evitando la creación de nuevos archivos.

Despliegue de versiones anteriores

eb migrateMantiene un historial de sus migraciones a través de directorios con marca de tiempo y versiones de aplicaciones en Elastic Beanstalk. Cada migración crea un archivo zip único que se puede implementar si es necesario.

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

El enlace latest simbólico siempre apunta al directorio de artefactos de migración creado más recientemente. Además de los registros de aplicaciones y errores relevantes, cada directorio de artefactos de migración también contiene un upload_target.zip archivo que puede implementar en 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

Puede implementar el archivo mediante: upload_target.zip eb migrate

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