Usar 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
Observação
O recurso de migração descrito neste artigo é usado para a 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 manuais de migração, consulte Opções de migração manual. Para obter ajuda para decidir qual opção de migração é ideal para você, confira a Árvore de decisão do 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 Ambiente do Serviço de Aplicativo dá suporte à migração no momento, confira Visão geral do recurso de migração lado a lado.
Importante
Para evitar problemas inesperados, recomendamos que você use esse recurso para ambientes de desenvolvimento antes de migrar os ambientes de produção. Forneça comentários relacionados 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 um Ambiente do Serviço de Aplicativo v3 afeta seus aplicativos. Revise o processo de migração para entender a linha do tempo do processo e quando e em que ponto você precisa se envolver. Além disso, revise as perguntas frequentes, que podem responder a algumas das suas dúvidas.
Verifique se não há bloqueios em sua rede virtual, grupos de recursos, recursos ou assinatura. Os blocos bloqueiam as operações da plataforma durante a migração.
Verifique se não há políticas do Azure que bloqueiem as 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 paralisada ou falhe.
Como o Ambiente do Serviço de Aplicativo v3 está em uma sub-rede diferente em sua rede virtual, você precisa garantir que tenha uma sub-rede disponível em sua rede virtual que atenda aos requisitos de sub-rede para o 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 o Ambiente do Serviço de Aplicativo existente está. Verifique se não há nada bloqueando 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 depois que a migração for concluída.
Siga as etapas descritas aqui em ordem e como escritas, pois você está fazendo chamadas à API REST do Azure. Recomendamos que você use a CLI do Azure para fazer essas chamadas à API. Para obter informações sobre outros métodos, confira referência à API REST do Azure.
Para este guia, instale a CLI do Azure ou use o Azure Cloud Shell, e use um shell Bash.
Observação
Recomendamos que você use um shell Bash para executar os comandos indicados 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 poderá mostrar informações incorretas sobre o Ambiente do Serviço de Aplicativo e seus aplicativos. Não acesse 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 dúvidas sobre o status da migração ou de seus 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 em seu Ambiente do Serviço de Aplicativo v3 que atenda aos requisitos de sub-rede para o Ambiente do Serviço de Aplicativo v3. Observe o nome da sub-rede selecionada. Essa sub-rede deve ser diferente da sub-rede em que o Ambiente do Serviço de Aplicativo existente está.
2. Obter sua ID do Ambiente do Serviço de Aplicativo
Execute os comandos a seguir para obter sua ID do Ambiente do Serviço de Aplicativo e armazená-la como uma variável de ambiente. Substitua os espaços reservados para nome e grupos de recursos pelos valores do Ambiente do Serviço de Aplicativo que você deseja migrar. ASE_RG e VNET_RG serão os mesmos se sua 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 que a migração tem suporte
O comando a seguir verifica se o Ambiente do Serviço de Aplicativo é suportado para 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 no 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 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, veja as opções de migração manual. Esse 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 Ambiente do Serviço de Aplicativo não estiver na versão de compilação com suporte, você precisará iniciar o upgrade por conta própria. Para saber mais sobre o upgrade pré-migração, confira Validar se a migração tem suporte com o recurso de migração lado a lado para o 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 terá suporte e você poderá prosseguir para a próxima etapa.
Caso precise iniciar uma atualização para atualizar o Ambiente do Serviço de Aplicativo para a versão de build com suporte, o que pode levar de 8 a 12 horas ou mais, dependendo do tamanho do seu ambiente, execute o comando a seguir. Execute esse comando somente se ocorrer uma falha na etapa de validação e se for necessário atualizar o Ambiente do Serviço de Aplicativo.
az rest --method post --uri "${ASE_ID}/NoDowntimeMigrate?phase=PreMigrationUpgrade&api-version=2022-03-01"
4. Gerar endereços IP de saída para o novo Ambiente do Serviço de Aplicativo v3
Crie um arquivo chamado zoneredundancy.json com os detalhes a seguir para sua seleção de região e redundância de zona.
{
"location":"<region>",
"Properties": {
"zoneRedundant": "<true/false>"
}
}
Você pode conferir redundância de zona ao novo Ambiente do Serviço de Aplicativo v3 se o ambiente existente estiver em uma região que dê suporte à redundância de zona. A redundância de zona pode ser configurada definindo a propriedade zoneRedundant como true. A redundância de zona é uma configuração opcional. Essa configuração só pode ser definida durante a criação do Ambiente do Serviço de Aplicativo v3 e não pode ser removida posteriormente.
Execute o comando a seguir para criar novos endereços IP de saída. Essa etapa leva cerca de 15 minutos para ser concluída. Não dimensione nem faça alterações no seu Ambiente do Serviço de Aplicativo durante esse tempo.
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ê receberá o status Migrating. Depois de obter um status de Ready, execute o comando a seguir para exibir seus novos IPs de saí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. Atualizar recursos dependentes com novos IPs de saída
Ao usar os novos IPs de saída, atualize todos os seus recursos ou componentes de rede para garantir que o novo ambiente funcione como esperado após a conclusão da migração. É sua responsabilidade fazer as atualizações necessárias.
6. Delegar a sub-rede do Ambiente do Serviço de Aplicativo
O Ambiente do Serviço de Aplicativo v3 requer que a sub-rede na qual ele está tenha apenas uma delegação de Microsoft.Web/hostingEnvironments. As versões anteriores não exigiam essa delegação. É necessário 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 comando a seguir ou navegando até 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 da 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 diferentes: assinatura, grupo de recursos e recurso. Quando você aplica um bloqueio a um escopo pai, todos os recursos filho herdam o mesmo bloqueio. Se você tiver bloqueios aplicados na assinatura, grupo de recursos ou escopo do recurso, eles precisarão ser removidos antes da migração. Para obter mais informações sobre bloqueios e herança de bloqueio, consulte Bloquear recursos para proteger a 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 os comandos relacionados para verificar se a assinatura ou grupo de recursos tem bloqueios, consulte a referência da CLI do Azure quanto a bloqueios.
8. Preparar suas configurações
Se o Ambiente do Serviço de Aplicativo existente utilizar um sufixo de domínio personalizado, será necessário configurar um para o novo recurso de 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 utilizando um atualmente. Para obter mais informações sobre os sufixos de domínio personalizado do Ambiente do Serviço de Aplicativo v3, incluindo os respectivos requisitos, instruções passo a passo e melhores práticas, confira Sufixo de domínio personalizado para Ambientes do Serviço de Aplicativo.
Observação
Se você estiver configurando um sufixo de domínio personalizado, ao adicionar as permissões de rede no cofre de chaves do Azure, certifique-se de que o cofre de chaves permita o acesso da nova sub-rede do Ambiente de Serviço de Aplicativo v3. Caso esteja 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 detalhes a seguir com base em seu cenário. Use a nova sub-rede selecionada para o novo Ambiente do Serviço de Aplicativo v3. Não inclua as propriedades de sufixo de domínio personalizado se não estiver usando esse recurso na sua migração. Preste atenção ao valor da propriedade zoneRedundant e defina-a com o mesmo valor usado na etapa de geração de IP de saída. Você deve usar o mesmo valor para redundância de zona que usou 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 pelo 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/00000000-0000-0000-0000-000000000000/resourcegroups/asev3-migration/providers/Microsoft.ManagedIdentity/userAssignedIdentities/ase-managed-identity"
}
}
}
Se você estiver usando uma identidade gerenciada atribuída pelo 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. Migrar para o Ambiente do Serviço de Aplicativo v3 e verificar o status
Depois de concluir todas as etapas acima, você pode iniciar a migração. Verifique se você entende as implicações da migração.
Esta etapa leva de três a seis horas de conclusão. Durante esse tempo, não há tempo de inatividade do aplicativo. A colocação em escala, as implantações e as modificações em seu Ambiente do Serviço de Aplicativo existente são bloqueadas durante essa 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 o status MigrationPendingDnsChange, a migração será feita e você terá um recurso de Ambiente do Serviço de Aplicativo v3. Os aplicativos agora estão em execução no novo ambiente e no ambiente antigo.
Obtenha os detalhes do novo ambiente executando o seguinte comando:
az appservice ase show --name $ASE_NAME --resource-group $ASE_RG
Importante
Durante a migração e durante a etapa de MigrationPendingDnsChange, o portal do Azure mostra informações incorretas sobre o Ambiente do Serviço de Aplicativo e seus aplicativos. Use a CLI do Azure para verificar o status da migração. Se você tiver dúvidas sobre o status da migração ou de seus aplicativos, entre em contato com o suporte.
Observação
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 depois que a migração for concluída devido a um bug conhecido. O Ambiente do Serviço de Aplicativo ainda deve funcionar conforme o esperado. O status degradado deve se resolver dentro de 6 a 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 fase no processo de migração. Seus aplicativos estão em execução em ambos os ambientes. Você precisa atualizar todos os recursos dependentes para usar o novo endereço de entrada de IP do seu novo Ambiente do Serviço de Aplicativo v3. Para Ambientes do Serviço de Aplicativo internos (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 o novo Ambiente do Serviço de Aplicativo v3 executando o comando a seguir que corresponde ao tipo de balanceador de carga do Ambiente do Serviço de Aplicativo. É sua responsabilidade fazer as atualizações necessárias.
Para Ambientes do Serviço de Aplicativo ILB, 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 Serviço de Aplicativo ELB, 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 do cliente, validar o 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 a zona DNS privada com o novo endereço IP de entrada. Caso esteja usando um Ambiente do Serviço de Aplicativo ELB v3, o processo de teste dependerá de sua configuração de rede específica. Um método simples para testar ambientes de ELB é atualizar o arquivo de hosts para usar seu novo endereço IP de entrada do Ambiente do Serviço de Aplicativo v3. Caso tenha domínios personalizados atribuídos a seus aplicativos individuais, você poderá, como alternativa, atualizar o DNS deles para apontar para o novo IP de entrada. Testar essa alteração permite que você valide totalmente o Ambiente do Serviço de Aplicativo v3 antes de iniciar a etapa final da migração em que o antigo Ambiente do Serviço de Aplicativo foi excluído. Se for possível acessar os aplicativos, tudo estará pronto para a conclusão da migração.
Depois de confirmar que os aplicativos estão funcionando conforme o esperado, é possível redirecionar o tráfego do cliente para o novo Ambiente do Serviço de Aplicativo v3 executando o comando a seguir. Esse comando também exclui seu ambiente antigo. Você tem 14 dias para concluir esta etapa. Se você não concluir esta etapa em 14 dias, sua migração será revertida automaticamente para um Ambiente do Serviço de Aplicativo v2. Se você precisar de mais de 14 dias para concluir esta etapa, entre em contato com o suporte.
Se você encontrar problemas ou decidir neste momento que não deseja continuar com a migração, entre em contato com o suporte para reverter a migração. Não execute o comando de alteração de DNS se for necessário 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 MigrationCompleted, a etapa de redirecionamento de tráfego é concluída e sua migração é concluída.