Use o recurso de migração lado a lado para migrar o Ambiente do Serviço de Aplicativo v2 para o Ambiente do Serviço de Aplicativo v3
Nota
O recurso de migração descrito neste artigo é usado para migração automatizada lado a lado (sub-rede diferente) do Ambiente do Serviço de Aplicativo v2 para o Ambiente do Serviço de Aplicativo v3.
Se você estiver procurando informações sobre o recurso de migração in-loco, consulte Migrar para o Ambiente do Serviço de Aplicativo v3 usando o recurso de migração in-loco. Se você estiver procurando informações sobre opções de migração manual, consulte Opções de migração manual. Para obter ajuda para decidir qual opção de migração é ideal para você, consulte Árvore de decisão de caminho de migração. Para obter mais informações sobre o Ambiente do Serviço de Aplicativo v3, consulte Visão geral do Ambiente do Serviço de Aplicativo v3.
Você pode migrar automaticamente o Ambiente do Serviço de Aplicativo v2 para o Ambiente do Serviço de Aplicativo v3 usando o recurso de migração lado a lado. Para saber mais sobre o processo de migração e ver se o seu Ambiente do Serviço de Aplicativo oferece suporte à migração no momento, consulte a visão geral do recurso de migração lado a lado.
Importante
Recomendamos que você use esse recurso para ambientes de desenvolvimento antes de migrar qualquer ambiente de produção, para evitar problemas inesperados. Por favor, forneça qualquer comentário relacionado a este artigo ou ao recurso usando os botões na parte inferior da página.
Pré-requisitos
Certifique-se de entender como a migração para o Ambiente do Serviço de Aplicativo v3 afeta seus aplicativos. Analise o processo de migração para entender o cronograma do processo e onde e quando você precisa se envolver. Consulte também as Perguntas Frequentes, que podem responder a algumas das suas perguntas.
Certifique-se de que não há bloqueios em sua rede virtual, grupos de recursos, recursos ou assinatura. Bloqueia operações de plataforma de bloqueio durante a migração.
Certifique-se de que nenhuma política do Azure esteja bloqueando ações necessárias para a migração, incluindo modificações de sub-rede e criações de recursos do Serviço de Aplicativo do Azure. As políticas que bloqueiam modificações e criações de recursos podem fazer com que a migração fique bloqueada ou falhe.
Como o Ambiente do Serviço de Aplicativo v3 está em uma sub-rede diferente na rede virtual, você precisa garantir que tenha uma sub-rede disponível na rede virtual que atenda aos requisitos de sub-rede do Ambiente do Serviço de Aplicativo v3. A sub-rede selecionada também deve ser capaz de se comunicar com a sub-rede em que seu Ambiente do Serviço de Aplicativo existente está. Certifique-se de que não há nada que bloqueie a comunicação entre as duas sub-redes. Se você não tiver uma sub-rede disponível, precisará criar uma antes de migrar. A criação de uma nova sub-rede pode envolver o aumento do espaço de endereço da rede virtual. Para obter mais informações, consulte Criar uma rede virtual e uma sub-rede.
Como o dimensionamento é bloqueado durante a migração, você deve dimensionar seu ambiente para o tamanho desejado antes de iniciar a migração. Se você precisar dimensionar seu ambiente após a migração, poderá fazê-lo assim que a migração for concluída.
Siga as etapas descritas aqui na ordem e conforme escrito, porque você está fazendo chamadas de API REST do Azure. Recomendamos que você use a CLI do Azure para fazer essas chamadas de API. Para obter informações sobre outros métodos, consulte Referência da API REST do Azure.
Para este guia, instale a CLI do Azure ou use o Azure Cloud Shell e use um shell Bash.
Nota
Recomendamos que você use um shell Bash para executar os comandos fornecidos neste guia. Os comandos podem não ser compatíveis com convenções do PowerShell e caracteres de escape.
Importante
Durante a migração, o portal do Azure pode mostrar informações incorretas sobre seu Ambiente do Serviço de Aplicativo e seus aplicativos. Não vá para a experiência de migração no portal do Azure, pois o recurso de migração lado a lado não está disponível lá. Recomendamos que você use a CLI do Azure para verificar o status da migração. Se você tiver alguma dúvida sobre o status da migração ou dos aplicativos, entre em contato com o suporte.
1. Selecione a sub-rede para seu novo Ambiente do Serviço de Aplicativo v3
Selecione uma sub-rede no Ambiente do Serviço de Aplicativo v3 que atenda aos requisitos de sub-rede do Ambiente do Serviço de Aplicativo v3. Anote o nome da sub-rede selecionada. Essa sub-rede deve ser diferente da sub-rede em que seu Ambiente do Serviço de Aplicativo existente está.
2. Obtenha sua ID de Ambiente do Serviço de Aplicativo
Execute os comandos a seguir para obter sua ID de Ambiente do Serviço de Aplicativo e armazená-la como uma variável de ambiente. Substitua os espaços reservados para o nome e os grupos de recursos por seus valores para o Ambiente do Serviço de Aplicativo que você deseja migrar. ASE_RG e VNET_RG são os mesmos se a rede virtual e o Ambiente do Serviço de Aplicativo estiverem no mesmo grupo de recursos.
ASE_NAME=<Your-App-Service-Environment-name>
ASE_RG=<Your-ASE-Resource-Group>
VNET_RG=<Your-VNet-Resource-Group>
ASE_ID=$(az appservice ase show --name $ASE_NAME --resource-group $ASE_RG --query id --output tsv)
3. Validar a migração é suportado
O comando a seguir verifica se o Ambiente do Serviço de Aplicativo é compatível com a migração. Se você receber um erro ou se o Ambiente do Serviço de Aplicativo estiver em um estado não íntegro ou suspenso, não será possível migrar neste momento. Consulte a seção de solução de problemas para obter descrições das possíveis mensagens de erro que você pode receber. Se o seu ambiente não tiver suporte para migração usando o recurso de migração lado a lado ou se você quiser migrar para o Ambiente do Serviço de Aplicativo v3 sem usar o recurso de migração lado a lado, consulte as opções de migração manual. Este comando também valida se o Ambiente do Serviço de Aplicativo está na versão de compilação com suporte para migração. Se o seu Ambiente do Serviço de Aplicativo não estiver na versão de compilação suportada, você mesmo precisará iniciar a atualização. Para obter mais informações sobre a atualização de pré-migração, consulte Validar se há suporte para a migração usando o recurso de migração lado a lado para seu Ambiente do Serviço de Aplicativo.
az rest --method post --uri "${ASE_ID}/NoDowntimeMigrate?phase=Validation&api-version=2022-03-01"
Se não houver erros, sua migração será suportada e você poderá continuar para a próxima etapa.
Se você precisar iniciar uma atualização para atualizar seu Ambiente do Serviço de Aplicativo para a versão de compilação suportada, o que pode levar de 8 a 12 horas ou mais, dependendo do tamanho do seu ambiente, execute o seguinte comando. Execute este comando somente se você falhar na etapa de validação e for instruído a atualizar seu Ambiente do Serviço de Aplicativo.
az rest --method post --uri "${ASE_ID}/NoDowntimeMigrate?phase=PreMigrationUpgrade&api-version=2022-03-01"
4. Gere endereços IP de saída para seu novo Ambiente do Serviço de Aplicativo v3
Crie um arquivo chamado zoneredundancy.json com os seguintes detalhes para sua seleção de redundância de região e zona.
{
"location":"<region>",
"Properties": {
"zoneRedundant": "<true/false>"
}
}
Você pode tornar sua nova zona do Ambiente do Serviço de Aplicativo v3 redundante se o ambiente existente estiver em uma região que ofereça suporte à redundância de zona. A redundância de zona pode ser configurada definindo a zoneRedundant propriedade como true. A redundância de zona é uma configuração opcional. Essa configuração só pode ser definida durante a criação do seu novo Ambiente do Serviço de Aplicativo v3 e não pode ser removida posteriormente.
Execute o seguinte comando para criar novos endereços IP de saída. Esta etapa leva cerca de 15 minutos para ser concluída. Não dimensione ou faça alterações no seu Ambiente do Serviço de Aplicativo existente durante esse período.
az rest --method post --uri "${ASE_ID}/NoDowntimeMigrate?phase=PreMigration&api-version=2022-03-01" --body @zoneredundancy.json
Execute o seguinte comando para verificar o status desta etapa:
az rest --method get --uri "${ASE_ID}?api-version=2022-03-01" --query properties.status
Se a etapa estiver em andamento, você obterá um status de Migrating. Depois de obter um status de , execute o seguinte comando para exibir seus novos IPs de Readysaída. Se você não vir os novos IPs imediatamente, aguarde alguns minutos e tente novamente.
az rest --method get --uri "${ASE_ID}/configurations/networking?api-version=2022-03-01" --query properties.windowsOutboundIpAddresses
5. Atualize recursos dependentes com novos IPs de saída
Usando os novos IPs de saída, atualize qualquer um dos seus recursos ou componentes de rede para garantir que seu novo ambiente funcione como pretendido após a conclusão da migração. É da sua responsabilidade fazer as atualizações necessárias.
6. Delegue a sub-rede do Ambiente do Serviço de Aplicativo
O Ambiente do Serviço de Aplicativo v3 requer que a sub-rede em que está tenha uma única delegação de Microsoft.Web/hostingEnvironments. As versões anteriores não exigiam essa delegação. Você precisa confirmar se sua sub-rede está delegada corretamente e atualizar a delegação (se necessário) antes de migrar. Você pode atualizar a delegação executando o seguinte comando ou indo para a sub-rede no portal do Azure.
az network vnet subnet update --resource-group $VNET_RG --name <subnet-name> --vnet-name <vnet-name> --delegations Microsoft.Web/hostingEnvironments
7. Confirme se não há bloqueios na rede virtual
Os bloqueios de rede virtual bloqueiam as operações da plataforma durante a migração. Se sua rede virtual tiver bloqueios, você precisará removê-los antes de migrar. Se necessário, você pode adicionar novamente os bloqueios após a conclusão da migração.
Os bloqueios podem existir em três escopos: assinatura, grupo de recursos e recurso. Quando você aplica um bloqueio em um escopo pai, todos os recursos dentro desse escopo herdam o mesmo bloqueio. Se você tiver bloqueios aplicados na assinatura, grupo de recursos ou escopo de recurso, precisará removê-los antes da migração. Para obter mais informações sobre bloqueios e herança de bloqueio, consulte Bloquear seus recursos para proteger sua infraestrutura.
Use o seguinte comando para verificar se sua rede virtual tem algum bloqueio:
az lock list --resource-group $VNET_RG --resource <vnet-name> --resource-type Microsoft.Network/virtualNetworks
Exclua todos os bloqueios existentes usando o seguinte comando:
az lock delete --resource-group $VNET_RG --name <lock-name> --resource <vnet-name> --resource-type Microsoft.Network/virtualNetworks
Para obter comandos relacionados para verificar se sua assinatura ou grupo de recursos tem bloqueios, consulte a referência da CLI do Azure para bloqueios.
8. Prepare suas configurações
Se o Ambiente do Serviço de Aplicativo existente usar um sufixo de domínio personalizado, você precisará configurar um para o novo recurso do Ambiente do Serviço de Aplicativo v3 durante o processo de migração. A migração falhará se você não configurar um sufixo de domínio personalizado e estiver usando um atualmente. Para obter mais informações sobre sufixos de domínio personalizados do Ambiente do Serviço de Aplicativo v3, incluindo requisitos, instruções passo a passo e práticas recomendadas, consulte Sufixo de domínio personalizado para ambientes do Serviço de Aplicativo.
Nota
Se estiver a configurar um sufixo de domínio personalizado, quando estiver a adicionar as permissões de rede ao cofre de chaves do Azure, certifique-se de que o cofre de chaves permite o acesso a partir da nova sub-rede do Ambiente do Serviço de Aplicação v3. Se você estiver acessando seu cofre de chaves usando um ponto de extremidade privado, verifique se configurou o acesso privado corretamente com a nova sub-rede.
Para definir essas configurações, incluindo a identificação da sub-rede selecionada anteriormente, crie outro arquivo chamado parameters.json com os seguintes detalhes com base no seu cenário. Certifique-se de usar a nova sub-rede selecionada para o novo Ambiente do Serviço de Aplicativo v3. Não inclua as propriedades de um sufixo de domínio personalizado se esse recurso não se aplicar à sua migração. Preste atenção ao valor da propriedade e defina-o para o mesmo valor que você usou na etapa de geração de zoneRedundant IP de saída. Você deve usar o mesmo valor para redundância de zona usado na etapa de geração de IP de saída.
Se você estiver migrando sem um sufixo de domínio personalizado, use este código:
{
"Properties": {
"VirtualNetwork": {
"Id": "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Network/virtualNetworks/<virtual-network-name>/subnets/<subnet-name>"
},
"zoneRedundant": "<true/false>"
}
}
Se você estiver usando uma identidade gerenciada atribuída ao usuário para sua configuração de sufixo de domínio personalizado, use este código:
{
"Properties": {
"VirtualNetwork": {
"Id": "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Network/virtualNetworks/<virtual-network-name>/subnets/<subnet-name>"
},
"zoneRedundant": "<true/false>",
"customDnsSuffixConfiguration": {
"dnsSuffix": "internal.contoso.com",
"certificateUrl": "https://contoso.vault.azure.net/secrets/myCertificate",
"keyVaultReferenceIdentity": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/asev3-migration/providers/Microsoft.ManagedIdentity/userAssignedIdentities/ase-managed-identity"
}
}
}
Se você estiver usando uma identidade gerenciada atribuída ao sistema para sua configuração de sufixo de domínio personalizado, use este código:
{
"properties": {
"VirtualNetwork": {
"Id": "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Network/virtualNetworks/<virtual-network-name>/subnets/<subnet-name>"
},
"zoneRedundant": "<true/false>",
"customDnsSuffixConfiguration": {
"dnsSuffix": "internal.contoso.com",
"certificateUrl": "https://contoso.vault.azure.net/secrets/myCertificate",
"keyVaultReferenceIdentity": "SystemAssigned"
}
}
}
9. Migre para o Ambiente do Serviço de Aplicativo v3 e verifique o status
Depois de concluir todas as etapas anteriores, você pode iniciar a migração. Certifique-se de que compreende as implicações da migração.
Esta etapa leva de três a seis horas concluída. Durante esse tempo, não há tempo de inatividade do aplicativo. O dimensionamento, as implantações e as modificações no Ambiente do Serviço de Aplicativo existente são bloqueados durante esta etapa.
Execute o seguinte comando para iniciar a migração:
az rest --method post --uri "${ASE_ID}/NoDowntimeMigrate?phase=HybridDeployment&api-version=2022-03-01" --body @parameters.json
Execute o seguinte comando para verificar o status da migração:
az rest --method get --uri "${ASE_ID}?api-version=2022-03-01" --query properties.subStatus
Depois de obter um status de , a migração é concluída e você tem um recurso do Ambiente do MigrationPendingDnsChangeServiço de Aplicativo v3. Seus aplicativos agora estão sendo executados em seu novo ambiente e em seu ambiente antigo.
Obtenha os detalhes do seu novo ambiente executando o seguinte comando:
az appservice ase show --name $ASE_NAME --resource-group $ASE_RG
Importante
Durante a migração, bem como durante a MigrationPendingDnsChange etapa, o portal do Azure mostra informações incorretas sobre seu Ambiente do Serviço de Aplicativo e seus aplicativos. Use a CLI do Azure para verificar o status da migração. Se você tiver alguma dúvida sobre o status da migração ou dos aplicativos, entre em contato com o suporte.
Nota
Se a migração incluir um sufixo de domínio personalizado, a configuração do sufixo de domínio personalizado poderá ser mostrada como degradada quando a migração for concluída devido a um bug conhecido. Seu Ambiente do Serviço de Aplicativo ainda deve funcionar conforme o esperado. O estado degradado deve resolver-se dentro de 6-8 horas. Se a configuração for degradada após 8 horas ou se o sufixo de domínio personalizado não estiver funcionando, entre em contato com o suporte.
10. Obtenha os endereços IP de entrada para seu novo Ambiente do Serviço de Aplicativo v3 e atualize os recursos dependentes
Você tem dois Ambientes do Serviço de Aplicativo nesta etapa do processo de migração. Seus aplicativos estão sendo executados em ambos os ambientes. Você precisa atualizar todos os recursos dependentes para usar o novo endereço de entrada IP para seu novo Ambiente do Serviço de Aplicativo v3. Para ambientes internos do Serviço de Aplicativo (ILB), você precisa atualizar suas zonas DNS privadas para apontar para o novo endereço IP de entrada.
Você pode obter o novo endereço IP de entrada para seu novo Ambiente do Serviço de Aplicativo v3 executando o seguinte comando que corresponde ao seu tipo de balanceador de carga do Ambiente do Serviço de Aplicativo. É da sua responsabilidade fazer as atualizações necessárias.
Para ambientes ILB App Service, obtenha o endereço IP de entrada privado executando o seguinte comando:
az rest --method get --uri "${ASE_ID}?api-version=2022-03-01" --query properties.networkingConfiguration.internalInboundIpAddresses
Para ambientes do ELB App Service, obtenha o endereço IP de entrada público executando o seguinte comando:
az rest --method get --uri "${ASE_ID}?api-version=2022-03-01" --query properties.networkingConfiguration.externalInboundIpAddresses
11. Redirecionar o tráfego de clientes, validar seu Ambiente do Serviço de Aplicativo v3 e concluir a migração
Esta etapa é sua oportunidade de testar e validar seu novo Ambiente do Serviço de Aplicativo v3. Por padrão, o tráfego é enviado para os front-ends do Ambiente do Serviço de Aplicativo v2. Se você estiver usando um Ambiente do Serviço de Aplicativo ILB v3, poderá testar os front-ends do Ambiente do Serviço de Aplicativo v3 atualizando sua zona DNS privada com o novo endereço IP de entrada. Se você estiver usando um ELB App Service Environment v3, o processo de teste dependerá da sua configuração de rede específica. Um método simples para testar ambientes ELB é atualizar seu arquivo hosts para usar seu novo endereço IP de entrada do Ambiente do Serviço de Aplicativo v3. Se você tiver domínios personalizados atribuídos aos seus aplicativos individuais, poderá alternativamente atualizar o DNS deles para apontar para o novo IP de entrada. O teste dessa alteração permite que você valide totalmente o Ambiente do Serviço de Aplicativo v3 antes de iniciar a etapa final da migração, na qual o Ambiente do Serviço de Aplicativo antigo é excluído. Se conseguir aceder às suas aplicações sem problemas, isso significa que está pronto para concluir a migração.
Depois de confirmar que seus aplicativos estão funcionando conforme o esperado, você pode redirecionar o tráfego do cliente para o novo Ambiente do Serviço de Aplicativo v3 executando o seguinte comando. Este comando também exclui seu ambiente antigo. Tem 14 dias para concluir este passo. Se você não concluir essa etapa em 14 dias, sua migração será revertida automaticamente para um Ambiente do Serviço de Aplicativo v2. Se precisar de mais de 14 dias para concluir esta etapa, entre em contato com o suporte.
Se você encontrar algum problema ou decidir, neste momento, que não deseja mais prosseguir com a migração, entre em contato com o suporte para reverter a migração. Não execute o comando DNS change se precisar reverter a migração. Para obter mais informações, consulte Reverter migração.
az rest --method post --uri "${ASE_ID}/NoDowntimeMigrate?phase=DnsChange&api-version=2022-03-01"
Execute o seguinte comando para verificar o status desta etapa:
az rest --method get --uri "${ASE_ID}?api-version=2022-03-01" --query properties.subStatus
Durante esta etapa, você obtém um status de CompletingMigration. Quando você obtém um status de , a etapa de redirecionamento de MigrationCompletedtráfego é concluída e a migração é concluída.