As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Cenários avançados de migração

Esta seção aborda cenários avançados de migração para implantações complexas do IIS.

Migrações de vários sites com Roteamento de solicitações de aplicações (ARR)

O comando eb migrate detecta e preserva automaticamente as configurações do ARR durante a migração. Ao identificar as configurações do ARR em seu IIS applicationHost.config, ele gera os scripts do PowerShell necessários para reinstalar e configurar o ARR nas instâncias do EC2 de destino.

Detecção de configuração do ARR

O processo de migração examina três seções principais de configuração no IIS:

Por exemplo, considere uma configuração ARR comum em que um RouterSite em execução na porta 80 encaminha solicitações para APIService e AdminPortal em execução nas portas 8081 e 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>

O diagrama a seguir mostra como essas regras estão ocultas atrás da porta 80 no servidor do IIS e não são expostas por meio dos grupos de segurança do EC2. Somente a porta 80 pode ser acessada pelo Application Load Balancer, e todo o tráfego dela é roteado para o grupo-alvo na porta 80.

O comando a seguir pode migrar essa configuração:

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

O processo de migração ARR

O processo de migração preserva sua configuração do ARR por meio de várias etapas.

Integração do balanceador de carga

O processo de migração traduz suas regras de ARR em regras de receptor do Application Load Balancer (ALB) sempre que possível. Por exemplo, a configuração do ARR acima resulta em regras de ALB que roteiam o tráfego com base nos padrões de caminho de URL enquanto mantêm o roteamento interno nas instâncias do EC2.

O ambiente resultante mantém sua lógica de roteamento do ARR enquanto aproveita a infraestrutura elástica da AWS. Suas aplicações continuam funcionando como antes, com o ARR gerenciando o roteamento interno enquanto o Application Load Balancer gerencia a distribuição do tráfego externo.

Migrações de vários sites sem ARR usando roteamento baseado em host

Embora o Roteamento de solicitações de aplicações (ARR) seja uma abordagem comum para gerenciar vários sites no IIS, você também pode migrar implantações de vários sites diretamente para o Elastic Beanstalk sem ARR, aproveitando os recursos de roteamento baseado em host do Application Load Balancer. Essa abordagem pode reduzir a complexidade e melhorar a performance ao eliminar uma camada adicional de roteamento.

Visão geral do roteamento baseado em host

Nessa abordagem, cada site do IIS é exposto fora da instância do EC2, e o Application Load Balancer roteia o tráfego diretamente para a porta apropriada com base no cabeçalho do host. Isso elimina a necessidade de ARR e, ao mesmo tempo, mantém a separação entre suas aplicações.

Considere uma configuração do IIS de vários sites com três sites, cada um com sua própria associação de nome 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>

Esses sites são expostos nas portas 8081, 8082 e 8083 por meio dos grupos de segurança do EC2. O Application Load Balancer encaminha até eles com base na configuração da regra do receptor do Balancador de carga.

Processo de migração

Para migrar essa configuração para o Elastic Beanstalk sem usar o ARR, use o comando eb migrate no exemplo a seguir:

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

O processo de migração configura automaticamente o Application Load Balancer com regras de roteamento baseadas em host que direcionam o tráfego para o grupo-alvo apropriado com base no cabeçalho do host. Cada grupo-alvo encaminha o tráfego para a porta correspondente nas suas instâncias do EC2:

Configuração de SSL/TLS

Para proteger suas aplicações com SSL/TLS, siga estas etapas:

Com essa configuração, o encerramento do SSL ocorre no balanceador de carga, e o tráfego é encaminhado para suas instâncias por HTTP. Isso simplifica o gerenciamento de certificados enquanto mantém conexões seguras com os clientes.

Práticas recomendadas

Gerenciamento de diretórios virtuais

O comando eb migrate preserva as estruturas de diretórios virtuais ao migrar suas aplicações IIS para o Elastic Beanstalk.

Configuração padrão de permissões

Ao migrar diretórios virtuais, o eb migrate estabelece um conjunto básico de permissões concedendo acesso de leitura e execução a:

Por exemplo, considere uma estrutura de diretório virtual 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>

Diretórios virtuais protegidos por senha

Quando eb migrate encontra diretórios virtuais protegidos por senha, ele emite avisos e requer intervenção manual.

O exemplo de configuração a seguir causará a resposta de aviso que segue o exemplo.

<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 manter a proteção por senha, crie um script de implantação personalizado como o seguinte:

# 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

Adicione esse script à sua implantação incluindo-o no manifesto:

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

Gerenciamento de permissões personalizado

O comando eb migrate fornece uma estrutura para scripts de permissão personalizados para acomodar aplicações que exigem permissões diferentes das padrões.

$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áticas recomendadas

Siga essas melhores práticas para planejar, executar, monitorar e verificar sua migração.

Configurações personalizadas do grupo de aplicações

Por padrão, o comando eb migrate não copia as configurações personalizadas do grupo de aplicações. Para preservar as configurações personalizadas do grupo de aplicações, siga este procedimento para criar e aplicar uma seção de manifesto personalizada.

O argumento --archive-dir instrui o eb migrate a usar o código-fonte que ele criou anteriormente, evitando a criação de novos arquivos.

Implantar versões anteriores

O mantém eb migrate um histórico das suas migrações por meio de diretórios com data e hora e versões de aplicações no Elastic Beanstalk. Cada migração cria um arquivo zip exclusivo que pode ser implantado se necessário.

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

O link simbólico latest sempre aponta para o diretório de artefatos de migração criado mais recentemente. Além dos logs relevantes de aplicações e erros, cada diretório de artefatos de migração também contém um arquivo upload_target.zip que você pode implantar no 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

Você pode implantar o arquivo upload_target.zip usando eb migrate:

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