Cenários avançados de migração - AWS Elastic Beanstalk

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ção de Aplicativos (ARR)

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

Detecção de configuração ARR

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

  • system.webServer/proxy: configurações principais do proxy ARR

  • system.webServer/rewrite: regras de reescrita de URL

  • system.webServer/caching: Configuração de cache

Por exemplo, considere uma configuração ARR comum em que um proxy RouterSite executado na porta 80 solicita e é AdminPortal executado nas portas 8081 APIService 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 IIS e não são expostas por meio dos grupos EC2 de segurança. 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.

Arquitetura do Elastic Beanstalk com roteamento de solicitações de aplicativos (ARR)

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

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

Processo de migração do ARR

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

Exportação de configuração

A ferramenta exporta suas configurações ARR existentes das três seções principais de configuração para arquivos XML separados armazenados no ebmigrateScripts diretório:

ebmigrateScripts\ ├── arr_config_proxy.xml ├── arr_config_rewrite.xml └── arr_config_caching.xml
Scripts de instalação

Dois PowerShell scripts são gerados para lidar com a configuração do ARR:

  1. arr_msi_installer.ps1: baixa e instala o módulo ARR

  2. arr_configuration_importer_script.ps1: Importa sua configuração ARR exportada

Integração do manifesto de implantação

Os scripts são integrados ao processo de implantação por meio de entradas emaws-windows-deployment-manifest.json:

{ "manifestVersion": 1, "deployments": { "custom": [ { "name": "WindowsProxyFeatureEnabler", "scripts": { "install": { "file": "ebmigrateScripts\\windows_proxy_feature_enabler.ps1" } } }, { "name": "ArrConfigurationImporterScript", "scripts": { "install": { "file": "ebmigrateScripts\\arr_configuration_importer_script.ps1" } } } ] } }

Integração com balanceador de carga

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

O ambiente resultante mantém sua lógica de roteamento ARR enquanto aproveita a infraestrutura elástica AWS da empresa. Seus aplicativos 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 Application Request Routing (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 o desempenho ao eliminar uma camada adicional de roteamento.

Visão geral do roteamento baseado em host

Nessa abordagem, cada site do IIS é exposto fora da EC2 instância, e o Application Load Balancer encaminha 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 seus aplicativos.

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 EC2 grupos de segurança. O Application Load Balancer encaminha até eles com base na configuração da regra do ouvinte do Load Balancer.

Arquitetura do Elastic Beanstalk sem roteamento de solicitações de aplicativos (ARR)

Processo de migração

Para migrar essa configuração para o Elastic Beanstalk sem usar o ARReb migrate, use o comando 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 em suas EC2 instâncias:

  1. Cabeçalho do host www.example.com → Grupo de destino na porta 8081

  2. Cabeçalho do host api.internal → Grupo de destino na porta 8082

  3. Relatórios do cabeçalho do host. Internal → Grupo de destino na porta 8083

Configuração de SSL/TLS

Para proteger seus aplicativos com SSL/TLS, siga as seguintes etapas:

  1. Solicite certificados para seus domínios por meio do AWS Certificate Manager(ACM).

  2. Configure ouvintes HTTPS em seu Application Load Balancer usando esses certificados.

  3. Atualize a configuração do seu ambiente para incluir ouvintes HTTPS com as seguintes opções de configuração.

    option_settings: aws:elb:listener:443: ListenerProtocol: HTTPS SSLCertificateId: arn:aws:acm:region:account-id:certificate/certificate-id InstancePort: 80 InstanceProtocol: HTTP

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 e, ao mesmo tempo, mantém conexões seguras com os clientes.

Práticas recomendadas

Grupos de segurança

Configure grupos de segurança para permitir tráfego de entrada somente nas portas usadas pelos sites do IIS (8081, 8082, 8083 neste exemplo) do grupo de segurança Application Load Balancer.

Verificações de integridade

Configure verificações de saúde para cada grupo-alvo para garantir que o tráfego seja roteado somente para instâncias íntegras. Crie endpoints de verificação de integridade para cada aplicativo, caso eles ainda não existam.

Monitoramento

Configure CloudWatch alarmes para monitorar a saúde e o desempenho de cada grupo-alvo separadamente. Isso permite identificar problemas específicos de aplicativos individuais.

Escalabilidade

Considere os requisitos de recursos de todos os aplicativos ao configurar políticas de escalonamento automático. Se um aplicativo tiver necessidades de recursos significativamente diferentes, considere migrá-lo para um ambiente separado.

Gerenciamento de diretórios virtuais

O eb migrate comando preserva as estruturas de diretórios virtuais ao migrar seus aplicativos IIS para o Elastic Beanstalk.

Configuração de permissão padrão

Ao migrar diretórios virtuais, eb migrate estabelece um conjunto básico de permissões concedendo acesso a: ReadAndExecute

  • IIS_IUSRS

  • IUSR

  • Usuários autenticados

Por exemplo, considere uma estrutura típica de diretórios virtuais:

<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 eb migrate comando fornece uma estrutura para scripts de permissão personalizados para acomodar aplicativos 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.

Planejamento de pré-migração

Documente as permissões e os requisitos de autenticação existentes antes da migração. Teste scripts de permissão personalizados em um ambiente de desenvolvimento antes de implantá-los na produção.

Gerenciamento de conteúdo compartilhado

Para diretórios de conteúdo compartilhado, certifique-se de que todas as permissões necessárias do sistema de arquivos estejam configuradas adequadamente por meio de scripts personalizados. Considere usar o Amazon FSx para Windows File Server para atender aos requisitos de armazenamento compartilhado.

Monitoramento e verificação

Monitore os registros do aplicativo após a migração para verificar o acesso adequado aos diretórios virtuais. Preste atenção especial às seguintes áreas:

  • Acesso à identidade do pool de aplicativos

  • Permissões personalizadas da conta de serviço

  • Conectividade de compartilhamento de rede

  • Falhas de autenticação

Configurações personalizadas do pool de aplicativos

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

  1. Crie um arquivo de seus artefatos de migração.

    PS C:\migrations_workspace> eb migrate --archive
  2. Crie um PowerShell script personalizado para configurar grupos de aplicativos.

    # PS C:\migrations_workspace> cat .\migrations\latest\upload_target\customize_application_pool_config.ps1 $configPath = "$env:windir\System32\inetsrv\config\applicationHost.config" [xml]$config = Get-Content -Path $configPath $newPoolXml = @" <!-- Original IIS Configuration --> <applicationPools> <add name="CustomPool" managedRuntimeVersion="v4.0" managedPipelineMode="Integrated"> <processModel identityType="SpecificUser" userName="AppPoolUser" password="[encrypted]" /> <recycling> <periodicRestart time="00:00:00"> <schedule> <add value="02:00:00" /> <add value="14:00:00" /> </schedule> </periodicRestart> </recycling> </add> </applicationPools> "@ $newPoolXmlNode = [xml]$newPoolXml # Find the applicationPools section $applicationPools = $config.SelectSingleNode("//configuration/system.applicationHost/applicationPools") # Import the new node into the document $importedNode = $config.ImportNode($newPoolXmlNode.DocumentElement, $true) $applicationPools.AppendChild($importedNode) # Save the changes $config.Save($configPath) Write-Host "ApplicationHost.config has been updated successfully."
  3. Atualize o aws-windows-deployment-manifest.json arquivo para incluir seu script personalizado.

    { "manifestVersion": 1, "deployments": { ... "custom": [ ..., { "name": "ModifyApplicationPoolConfig", "description": "Modify application pool configuration from source machine to remove", "scripts": { "install": { "file": "customize_application_pool_config.ps1" }, "restart": { "file": "ebmigrateScripts\\noop.ps1" }, "uninstall": { "file": "ebmigrateScripts\\noop.ps1" } } } ] } }
  4. Crie um ambiente com o diretório de arquivamento atualizado.

    PS C:\migrations_workspace> eb migrate ` --archive-dir '.\migrations\latest\upload_target\'

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

Implantação de versões anteriores

O eb migrate mantém um histórico de suas migrações por meio de diretórios com data e hora e versões de aplicativos 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 latest simbólico sempre aponta para o diretório de artefatos de migração criado mais recentemente. Além dos registros relevantes de aplicativos e erros, cada diretório de artefatos de migração também contém um upload_target.zip arquivo 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 upload_target.zip arquivo usandoeb migrate:

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