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 complejas de IIS.

Migraciones de sitios múltiples con enrutamiento de solicitudes de aplicaciones (ARR)

El comando eb migrate detecta y conserva automáticamente las configuraciones de ARR durante la migración. Cuando identifica la configuración de ARR en su applicationHost.config de IIS, genera los scripts de PowerShell necesarios para volver a instalar y configurar ARR en las instancias de EC2 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 de ARR común en la que un RouterSite que se ejecuta en el puerto 80 envía solicitudes al APIService y AdminPortal que se ejecutan en los puertos 8081 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 grupos de seguridad de EC2. El Equilibrador de carga de aplicación tiene acceso solamente 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 de ARR

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

Integración de un equilibrador de carga

El proceso de migración convierte las reglas de ARR en reglas de oyente del Equilibrador de carga de aplicación (ALB) siempre que sea posible. Por ejemplo, la configuración de ARR anterior da como resultado reglas del 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 de EC2.

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

Migraciones de sitios múltiples sin ARR mediante enrutamiento basado en host

Si bien el enrutamiento de solicitudes de aplicaciones (ARR) es un enfoque común para administrar sitios múltiples en IIS, también puede migrar las implementaciones de sitios múltiples directamente a Elastic Beanstalk sin ARR aprovechando las capacidades de enrutamiento basado en host del Equilibrador de carga de aplicación. Este enfoque puede reducir la complejidad y mejorar el rendimiento con la eliminación de 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 instancia de EC2 y el Equilibrador de carga de aplicación enruta el tráfico directamente al puerto correspondiente en función del encabezado del host. Esto elimina la necesidad de utilizar el ARR y, al mismo tiempo, mantiene la separación entre las aplicaciones.

Considere una configuración de IIS de sitios múltiples 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 de EC2. El Equilibrador de carga de aplicación se enruta a ellos en función de la configuración de la regla del oyente del equilibrador de carga.

Proceso de migración

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

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

El proceso de migración configura automáticamente el Equilibrador de carga de aplicación 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 sus instancias de EC2:

Configuración de SSL/TLS

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

Con esta configuración, la finalización de SSL se produce en el equilibrador de carga 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 directorio virtual

El comando eb migrate conserva las estructuras de directorios virtuales mientras migra sus aplicaciones de IIS a Elastic Beanstalk.

Configuración predeterminada de permisos

Cuando se migran directorios virtuales, eb migrate establece un conjunto básico de permisos al conceder acceso ReadAndExecute a:

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

<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 con contraseña, cree un script de implementación 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 implementación incluyéndolo en el manifiesto:

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

Administración de permisos personalizada

El comando eb migrate 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, monitorear y comprobar la migración.

Configuración personalizada del grupo de aplicaciones

De forma predeterminada, el comando eb migrate 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 personalizada del manifiesto.

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

Cómo restaurar versiones anteriores

El comando eb migrate mantiene 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 simbólico latest 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 archivo upload_target.zip 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 upload_target.zip mediante eb migrate:

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