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á.
Entendendo o mapeamento de migração do IIS para o Elastic Beanstalk
A migração do IIS para o Elastic Beanstalk envolve o mapeamento da configuração do servidor Windows local para os recursos da nuvem. AWS Compreender esse mapeamento é crucial para migrações bem-sucedidas e gerenciamento pós-migração.
Sites e aplicativos do IIS no Elastic Beanstalk
No IIS, um site representa uma coleção de aplicativos da Web e diretórios virtuais, cada um com sua própria configuração e conteúdo. Ao migrar para o Elastic Beanstalk, esses componentes são transformados da seguinte forma:
- Sites do IIS
-
Seus sites do IIS se tornam aplicativos dentro do Elastic Beanstalk. A configuração de cada site, incluindo suas vinculações, pools de aplicativos e configurações de autenticação, é preservada por meio do manifesto de implantação () do Elastic Beanstalk.
aws-windows-deployment-manifest.json
Por exemplo, se você tiver vários sites, como o site padrão IntranetSite, eb migrate empacota o conteúdo e a configuração de cada site, mantendo seu isolamento.
O comando cria regras de ouvinte apropriadas do Application Load Balancer (ALB) para lidar com solicitações de roteamento para seus aplicativos. Ele também configura grupos de segurança para garantir o acesso adequado às portas com base nas ligações originais do IIS.
- Pools de aplicativos
-
Os pools de aplicativos do IIS fornecem isolamento de processos de trabalho, gerenciamento de tempo de execução e recursos de reciclagem para seus aplicativos. No Elastic Beanstalk, eles são mapeados para processos de ambiente definidos
aws:elasticbeanstalk:environment:process
por meio do namespace e configurados via IIS nas instâncias. EC2A migração preserva as configurações críticas do pool de aplicativos, incluindo as seguintes:
-
Configurações do modelo de processo - Identidade (ApplicationPoolIdentity, NetworkService, ou contas personalizadas), configurações de tempo limite de inatividade e intervalos de reciclagem do processo
-
Configurações da versão do.NET CLR - mantém sua versão especificada do.NET Framework (v2.0, v4.0 ou Sem código gerenciado) para garantir a compatibilidade do aplicativo
-
Modo de pipeline gerenciado - preserva as configurações do modo de pipeline integrado ou clássico para manter sua arquitetura de processamento de solicitações HTTP
-
Configurações avançadas - comprimento da fila, limites de CPU, limites de proteção contra falhas rápidas e limites de tempo de inicialização
O eb migrate comando preserva os mapeamentos entre sites e pools de aplicativos durante a migração para o ambiente do Elastic Beanstalk.
Se seus pools de aplicativos usarem cronogramas de reciclagem personalizados (horários específicos ou limites de memória), eles serão implementados por meio de PowerShell scripts no pacote de implantação que definem as configurações apropriadas do IIS nas EC2 instâncias.
-
- Vinculações de sites
-
As vinculações de sites do IIS, que definem como os clientes acessam seus aplicativos, são transformadas nas seguintes configurações do Application Load Balancer (ALB):
-
As ligações de porta são mapeadas de acordo com as regras de ouvinte ALB correspondentes
-
As configurações do cabeçalho do host são traduzidas em regras de roteamento ALB
-
Sites habilitados para SSL usam o AWS Certificate Manager (ACM) para gerenciamento de certificados
-
Gerenciamento virtual de diretórios e caminhos de aplicativos
Os diretórios e aplicativos virtuais do IIS fornecem mapeamento de caminhos de URL para diretórios físicos. O Elastic Beanstalk mantém esses relacionamentos por meio das seguintes construções:
- Diretórios virtuais
-
O processo de migração preserva os caminhos físicos de seus diretórios virtuais no pacote de implantação.
Os mapeamentos de caminho são configurados na configuração do IIS nas EC2 instâncias, garantindo que sua estrutura de URL permaneça intacta após a migração.
- Caminhos físicos que não são do sistema
-
Importante
Por padrão, os ambientes Windows do Elastic Beanstalk provisionam somente a unidade C:\ (volume raiz). Na versão atual, aplicativos com conteúdo em unidades que não são do sistema (D:\, E:\ etc.) não têm suporte para migração.
O eb migrate comando detecta automaticamente caminhos físicos localizados em unidades que não são do sistema e avisa sobre possíveis problemas, como no exemplo a seguir:
ERROR: Detected physical paths on drive D:\ which are not supported in the current version: - D:\websites\intranet - D:\shared\images Migration of content from non-system drives is not supported. Please relocate this content to the C:\ drive before migration. Otherwise, select only those sites that are on C:\.
Se seu aplicativo tiver dependências em unidades que não sejam do sistema, você precisará modificá-lo para armazenar todo o conteúdo na unidade C:\ antes da migração.
- Aplicativos aninhados
-
Os aplicativos aninhados em sites são implantados com as configurações de caminho corretas e as atribuições apropriadas do pool de aplicativos. O processo de migração preserva todas as
web.config
configurações, garantindo que as configurações específicas do aplicativo continuem funcionando conforme o esperado no ambiente de nuvem.
Reescrita de URL e roteamento de solicitação de aplicativo (ARR)
Se sua implantação do IIS usa Regravação de URL ou Roteamento de Solicitação de Aplicativo (ARR), eb migrate manipule essas configurações por meio das seguintes regras e configurações:
- Regras de reescrita de URL
-
As regras de regravação de URL de seus
web.config
arquivos são traduzidas em regras de roteamento ALB sempre que possível. Por exemplo, a entrada a seguir se torna uma regra de ouvinte do ALB que direciona o tráfego com base nos cabeçalhos do host e nos padrões de caminho. :<!-- Original IIS URL Rewrite Rule --> <rule name="Redirect to WWW" stopProcessing="true"> <match url="(.*)" /> <conditions> <add input="{HTTP_HOST}" pattern="^example.com$" /> </conditions> <action type="Redirect" url="http://www.example.com/{R:1}" /> </rule>
- Roteamento de solicitações de aplicativos
-
As configurações de ARR são preservadas por meio da instalação de recursos de ARR nas instâncias. EC2 O processo de migração conclui as seguintes tarefas:
-
Define as configurações de proxy para corresponder ao seu ambiente de origem
-
Mantém as regras de regravação de URL associadas ao ARR
-
Estrutura do artefato de migração
Quando você executaeb migrate, ele cria um diretório estruturado contendo todos os componentes de implantação necessários. A lista a seguir descreve a estrutura de diretórios:
C:\migration_workspace\
└── .\migrations\latest\
└── upload_target\
├── [SiteName].zip # One ZIP per IIS site
├── aws-windows-deployment-manifest.json
└── ebmigrateScripts\
├── site_installer.ps1 # Site installation scripts
├── arr_configuration.ps1 # ARR configuration scripts
├── permission_handler.ps1 # Permission management
└── firewall_config.ps1 # Windows Firewall rules
O aws-windows-deployment-manifest.json
arquivo é o arquivo de configuração principal que instrui o Elastic Beanstalk a implantar seus aplicativos. Consulte o exemplo de estrutura a seguir:
{ "manifestVersion": 1, "deployments": { "msDeploy": [ { "name": "Primary Site", "parameters": { "appBundle": "DefaultWebSite.zip", "iisPath": "/", "iisWebSite": "Default Web Site" } } ], "custom": [ { "name": "ConfigureARR", "scripts": { "install": { "file": "ebmigrateScripts\\arr_configuration.ps1" }, "uninstall": { "file": "ebmigrateScripts\\noop.ps1" }, "restart": { "file": "ebmigrateScripts\\noop.ps1" } } } ] } }
Esse manifesto garante os seguintes resultados para sua migração:
-
Os aplicativos são implantados para corrigir os caminhos do IIS
-
Configurações personalizadas são aplicadas
-
As configurações específicas do site são preservadas
-
A ordem de implantação é mantida