Migração para Ambiente do Serviço de Aplicativo v3 com o recurso de migração lado a lado

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. Caso não solicitou um período de cortesia de 30 dias, revise a visão geral sobre o período de cortesia e solicite um período de cortesia acessando o portal do Azure e visitando a folha Migração para cada um de seus Ambientes do Serviço de Aplicativo.

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.

A migração lado a lado implica em desafios adicionais em comparação com a migração in-loco. Para clientes que precisam decidir entre as duas opções, a recomendação é usar a migração in-loco, já que tem menos etapas e menor complexidade. Se você decidir usar a migração lado a lado, leia a seção fontes comuns de problemas ao migrar usando o recurso de migração lado a lado para evitar as armadilhas mais comuns.

O Serviço de Aplicativo pode automatizar a migração do Ambiente do Serviço de Aplicativo v1 e v2 para um Ambiente do Serviço de Aplicativo v3. Há várias opções de migração. Examine a árvore de decisão de caminho de migração para decidir qual opção é melhor para seu caso de uso. O Ambiente do Serviço de Aplicativo v3 fornece vantagens e diferenças de recursos em relação às versões anteriores. Examine os recursos com suporte do Ambiente do Serviço de Aplicativo v3 antes de migrar para reduzir o risco de um problema inesperado com o aplicativo.

O recurso de migração lado a lado automatiza sua migração para o Ambiente do Serviço de Aplicativo v3. O recurso de migração lado a lado cria um novo Ambiente do Serviço de Aplicativo v3 com todos os seus aplicativos em uma sub-rede diferente. O Ambiente do Serviço de Aplicativo existente não será excluído até que você inicie a exclusão no final do processo de migração. Essa opção de migração é melhor para clientes que desejam migrar para o Ambiente do Serviço de Aplicativo v3 sem tempo de inatividade e podem usar uma sub-rede diferente para o novo ambiente. Se você precisar usar a mesma sub-rede e puder dispor de cerca de uma hora de tempo de inatividade do aplicativo, consulte o recurso de migração in-loco. Para obter opções manuais de migração que permitam migrar em seu próprio ritmo, consulte as opções de migração manual.

Importante

Se você não conseguir concluir todas as etapas descritas neste tutorial, haverá tempo de inatividade. Por exemplo, se você não atualizar todos os recursos dependentes com os novos endereços IP ou não permitir o acesso de/para sua nova sub-rede, como no caso do cofre de chaves de sufixo de domínio personalizado, haverá tempo de inatividade até que isso seja resolvido.

Recomenda-se usar esse recurso para ambientes de desenvolvimento antes de migrar qualquer ambiente de produção para ensaiar o processo e garantir que não haja problemas inesperados. Forneça comentários relacionados a este artigo ou ao recurso usando os botões na parte inferior da página.

Cenários com suporte

No momento, o recurso de migração lado a lado não oferece suporte às migrações para o Ambiente do Serviço de Aplicativo v3 nas seguintes regiões:

Público do Azure

• EAU Central

Azure Government

• DoD Central dos EUA
• DoD do Leste dos EUA
• Governo dos EUA do Arizona
• Governo dos EUA do Texas
• Gov. dos EUA – Virgínia

Microsoft Azure operado pela 21Vianet

• Leste da China 2
• Norte da China 2

As seguintes configurações do Ambiente do Serviço de Aplicativo podem ser migradas usando o recurso de migração lado a lado. A tabela fornece a configuração do Ambiente do Serviço de Aplicativo v3 ao usar o recurso de migração lado a lado com base em seu Ambiente do Serviço de Aplicativo existente.

Configuração	Configuração do Ambiente do Serviço de Aplicativo v3
Ambiente do Serviço de Aplicativo v2 de ILB (Balanceador de Carga Interno)	Ambiente do Serviço de Aplicativo v3 de ILB
Ambiente do Serviço de Aplicativo v2 do Externo (ELB/para internet com IP público)	Ambiente do Serviço de Aplicativo v3 do ELB
|Ambiente do Serviço de Aplicativo v2 com ILB com sufixo de domínio personalizado	|Ambiente do Serviço de Aplicativo v3 de ILB com sufixo de domínio personalizado

O Ambiente do Serviço de Aplicativo v3 pode ser implantado com redundância de zona. A redundância de zona pode ser habilitada desde que o Ambiente do Serviço de Aplicativo v3 esteja em uma região que dê suporte à redundância de zona.

Se você quiser que o novo Ambiente do Serviço de Aplicativo v3 use um sufixo de domínio personalizado e não estiver usando um atualmente, o sufixo de domínio personalizado poderá ser configurado a qualquer momento após a conclusão da migração. Para obter mais informações, consulte Configurar o sufixo de domínio personalizado para o Ambiente do Serviço de Aplicativo. Se o ambiente existente tiver um sufixo de domínio personalizado e você não quiser mais usá-lo, você deverá configurar um sufixo de domínio personalizado para a migração. Você pode remover o sufixo de domínio personalizado após a conclusão da migração.

Limitações do recurso de migração lado a lado

Veja a seguir as limitações ao usar o recurso de migração lado a lado:

• Seu novo Ambiente do Serviço de Aplicativo v3 está em uma sub-rede diferente, mas na mesma rede virtual que o ambiente existente.
• Não será possível alterar a região em que o Ambiente do Serviço de Aplicativo está localizado.
• O Ambiente de Serviço de Aplicativo do ELB não poderá ser migrado para o Ambiente do Serviço de Aplicativo v3 de ILB e vice-versa.
• Se o Ambiente do Serviço de Aplicativo existente usar um sufixo de domínio personalizado, será necessário configurar o sufixo de domínio personalizado para o Ambiente do Serviço de Aplicativo v3 durante o processo de migração.
  • Se você não quiser mais usar um sufixo de domínio personalizado, poderá removê-lo assim que a migração for concluída.
• O recurso de migração lado a lado só está disponível usando a CLI ou por meio da API REST. O recurso não está disponível no portal do Azure.

O Ambiente do Serviço de Aplicativo v3 não dá suporte aos recursos a seguir que talvez você esteja usando no Ambiente do Serviço de Aplicativo v2 atual.

• Configurar uma associação TLS/SSL baseada em IP com os seus aplicativos.
• O Ambiente do Serviço de Aplicativo v3 não recorrerá ao DNS do Azure se os servidores DNS personalizados configurados na rede virtual não puderem resolver determinado nome. Se esse comportamento for necessário, verifique se você tem um encaminhador para um DNS público ou inclua o DNS do Azure na lista de servidores DNS personalizados.

O recurso de migração lado a lado não oferece suporte aos seguintes cenários. Consulte as opções de migração manual se o Ambiente do Serviço de Aplicativo se enquadrar em uma dessas categorias.

• Ambiente do Serviço de Aplicativo v1
  • Você pode encontrar a versão de seu Ambiente do Serviço de Aplicativo navegando até ele no portal do Azure e selecionando Configuração em Configurações no lado esquerdo. Você também pode usar o Azure Resource Explorer e examinar o valor da propriedade kind para o Ambiente do Serviço de Aplicativo.
  • Se você tiver um Ambiente do Serviço de Aplicativo v1, poderá migrar usando o recurso de migração in-loco ou uma das opções de migração manual.
• Ambiente de Serviço de Aplicativo v2 do ELB com endereços IP SSL.
• Ambiente do Serviço de Aplicativo v2 fixado à zona
• Ambiente do Serviço de Aplicativo do Azure com um nome que não atende aos limites de caracteres. O nome completo, incluindo o sufixo do domínio, deve ter 64 caracteres ou menos. Por exemplo: my-ase-name.appserviceenvironment.net para ILB e my-ase-name.p.azurewebsites.net para ELB devem ter 64 caracteres ou menos. Se você não atender ao limite de caracteres, deverá fazer a migração manualmente. Os limites de caracteres especificamente para o nome do Ambiente do Serviço de Aplicativo são os seguintes:
  • Limite de caracteres do nome do Ambiente do Serviço de Aplicativo ILB: 36 caracteres
  • Limite de caracteres do nome do Ambiente do Serviço de Aplicativo ELB: 42 caracteres

A plataforma do Serviço de Aplicativo examina seu Ambiente do Serviço de Aplicativo para confirmar o suporte à migração lado a lado. Se seu cenário não passar em todas as verificações da validação, você não poderá migrar neste momento usando o recurso de migração lado a lado. Se seu ambiente estiver em um estado não íntegro ou suspenso, você não poderá migrar até fazer as atualizações necessárias.

Observação

O Ambiente do Serviço de Aplicativo v3 não tem suporte para IP SSL. Se você usar o IP SSL, deverá remover todas as associações de IP SSL antes de migrar para o Ambiente de Serviço de Aplicativo v3. O recurso de migração dará suporte ao seu ambiente quando todas as associações de IP SSL forem removidas.

Solução de problemas

Se o Ambiente do Serviço de Aplicativo não passar nas verificações de validação ou tentar executar uma etapa de migração na ordem incorreta, você verá uma das seguintes mensagens de erro:

Mensagem de erro	Descrição	Recomendação
A migração só pode ser chamada em um ASE na VNET do ARM e esse ASE está na VNET Clássica.	Os Ambientes do Serviço de Aplicativo em redes virtuais Clássicas não podem migrar usando o recurso de migração lado a lado.	Migrar usando uma das opções de migração manual.
A Migração ASEv3 ainda não está pronta.	A infraestrutura subjacente não está pronta para dar suporte a Ambiente do Serviço de Aplicativo v3.	Migre usando uma das opções de migração manual se você quiser migrar imediatamente. Caso contrário, aguarde até que o recurso de migração lado a lado esteja disponível em sua região.
Não é possível habilitar a redundância de zona para este ASE.	A região em que o Ambiente do Serviço de Aplicativo está não dá suporte à redundância de zona.	Se você precisar habilitar a redundância de zona, use uma das opções de migração manual para migrar para uma região que dê suporte à redundância de zona.
A migração não pode ser chamada neste ASE de sufixo DNS personalizado no momento.	A migração de sufixo de domínio personalizado está bloqueada.	Abra uma solicitação de suporte para envolver a equipe de suporte para resolve seu problema.
A migração do ASE com redundância de zona não pode ser chamada no momento.	A migração do Ambiente do Serviço de Aplicativo com redundância de zona está bloqueada.	Abra uma solicitação de suporte para envolver a equipe de suporte para resolve seu problema.
A migração não pode ser chamada no ASEv2 fixado em uma zona.	O Ambiente do Serviço de Aplicativo v2 que está fixado em uma zona não pode ser migrado usando o recurso de migração lado a lado no momento.	Migre usando uma das opções de migração manual se você quiser migrar imediatamente.
Operação de migração de reversão existente em andamento, tente novamente mais tarde.	Uma tentativa de migração anterior está sendo revertida.	Aguarde até que a reversão que está em andamento seja concluída para tentar iniciar a migração novamente.
Properties.VirtualNetwork.Id deve conter a ID do recurso da sub-rede.	O erro será exibido se você tentar migrar sem fornecer uma nova sub-rede para posicionamento do Ambiente do Serviço de Aplicativo v3.	Siga as diretrizes e conclua a etapa para identificar a sub-rede que você usará para o Ambiente do Serviço de Aplicativo v3.
Não é possível migrar para <requested phase> da fase <previous phase> em que a Migração sem tempo de inatividade está.	Esse erro será exibido se você tentar executar uma etapa de migração na ordem incorreta.	Siga as etapas de migração em ordem.
Falha ao iniciar a operação de reversão no ASE no estado híbrido, tente novamente mais tarde.	Esse erro será exibido se você tentar reverter a migração, mas algo der errado. Esse erro não afetará o ambiente antigo nem o novo.	Abra uma solicitação de suporte para envolver a equipe de suporte para resolve seu problema.
Esse ASE não pode ser migrado sem tempo de inatividade.	Esse erro é exibido se você tentar usar o recurso de migração lado a lado em um Ambiente do Serviço de Aplicativo v1.	O recurso de migração lado a lado não é compatível com o Ambiente do Serviço de Aplicativo v1. Migre usando o recurso de migração in-loco ou uma das opções de migração manual.
A migração não está disponível para essa assinatura.	O suporte precisa ser contratado para migrar esse Ambiente do Serviço de Aplicativo.	Abra uma solicitação de suporte para envolver a equipe de suporte para resolve seu problema.
A migração com redundância de zona não pode ser chamada, pois os endereços IP criados durante a pré-migração não contam com redundância de zona.	Esse erro aparecerá se você tentar uma migração com redundância de zona, mas os IPs gerados durante a etapa de geração de IPs não foram criados com redundância de zona. A plataforma tenta tornar todos os IPs com redundância de zona para garantir a resiliência do back-end.	Abra um caso de suporte para obter auxílio se você precisar habilitar a redundância de zona. Os engenheiros reverterão a migração e permitirão outra tentativa de criar os IPs. Caso contrário, você poderá migrar sem habilitar a redundância de zona.
A migração não poderá ser chamada se o IP SSL estiver habilitado em qualquer um dos sites.	Os Ambientes do Serviço de Aplicativo que têm sites com IP SSL habilitado não podem ser migrados usando o recurso de migração lado a lado.	Remova o IP SSL de todos os seus aplicativos no Ambiente do Serviço de Aplicativo para habilitar o recurso de migração.
Não é possível migrar dentro da mesma sub-rede.	O erro será exibido se você especificar a mesma sub-rede em que o ambiente atual está para o posicionamento do Ambiente do Serviço de Aplicativo v3.	Você deve especificar uma sub-rede diferente para o Ambiente do Serviço de Aplicativo v3. Se você precisar usar a mesma sub-rede, migre usando o recurso de migração in-loco.
A assinatura tem muitos Ambientes do Serviço de Aplicativo. Remova alguns antes de tentar criar mais.	A cota para sua assinatura do Ambiente do Serviço de Aplicativo foi atendida.	Remova os ambientes desnecessários ou contate o suporte para examinar as opções.
A migração não pode ser chamada neste ASE até que a atualização ativa seja concluída.	Os Ambientes do Serviço de Aplicativo não podem ser migrados durante as atualizações da plataforma. Você pode definir sua preferência de atualização no portal do Azure. As atualizações levam de oito a 12 horas ou mais, dependendo do tamanho (número de instâncias/núcleos) do Ambiente do Serviço de Aplicativo.	Aguarde até que a atualização seja concluída e, em seguida, migre.
Operação de gerenciamento do Ambiente do Serviço de Aplicativo em andamento.	O Ambiente do Serviço de Aplicativo está passando por uma operação de gerenciamento. Essas operações podem incluir atividades como implantações ou atualizações. A migração estará bloqueada até a conclusão dessas operações.	Você poderá migrar depois que essas operações forem concluídas.
Seu InteralLoadBalancingMode não é suportado no momento.	Os Ambientes de Serviço de Aplicativo que têm o InternalLoadBalancingMode definido com determinados valores não podem ser migrados usando o recurso de migração no momento. A equipe da Microsoft deve alterar manualmente o InternalLoadBalancingMode.	Abra uma solicitação de suporte para envolver a equipe de suporte para resolve seu problema. Solicite uma atualização para o InternalLoadBalancingMode.
A migração completa não poderá ser chamada antes que os endereços IP sejam gerados.	Esse erro aparece se você tentar migrar antes de concluir as etapas de pré-migração.	Verifique se você concluiu todas as etapas de pré-migração antes de tentar migrar. Consulte o guia passo a passo para migração.
A migração completa não pode ser chamada no Ase com o sufixo dns personalizado definido, mas sem uma Configuração de Sufixo Dns Personalizada AseV3 definida.	O Ambiente do Serviço de Aplicativo existente usa um sufixo de domínio personalizado. Será necessário configurar o sufixo de domínio personalizado para o Ambiente do Serviço de Aplicativo v3 durante o processo de migração.	Configurar um sufixo de domínio personalizado. Se você não quiser mais usar um sufixo de domínio personalizado, poderá removê-lo assim que a migração for concluída.

Visão geral do processo de migração usando o recurso de migração lado a lado

A migração lado a lado consiste em uma série de etapas que devem ser seguidas em ordem. Os pontos-chave são determinados para um subconjunto das etapas. É importante entender o que acontece durante essas etapas e como o ambiente e os aplicativos são afetados. Depois de revisar as informações a seguir e quando estiver pronto para migrar, siga o guia passo a passo.

Valide se há suporte para a migração usando o recurso de migração lado a lado para o Ambiente do Serviço de Aplicativo

A plataforma valida que o Ambiente do Serviço de Aplicativo pode ser migrado usando o recurso de migração lado a lado. Se o Ambiente do Serviço de Aplicativo não passar em todas as verificações da validação, você não poderá migrar neste momento usando o recurso de migração lado a lado. Confira a seção Solução de problemas para obter detalhes das possíveis causas de falha de validação. Se seu ambiente estiver em um estado não íntegro ou suspenso, você não poderá migrar até fazer as atualizações necessárias. Se você não puder migrar usando o recurso de migração lado a lado, confira as opções de migração manual.

A validação também verifica se o Ambiente do Serviço de Aplicativo não está na compilação mínima exigida para a migração. Esse build pode ser mais recente do que o build padrão implantado com o ciclo de atualização/manutenção da plataforma de rotina. A compilação mínima é atualizada periodicamente para garantir que as correções de bug e melhorias mais recentes estejam disponíveis. Se o Ambiente do Serviço de Aplicativo não estiver na compilação mínima, você precisará iniciar a atualização por conta própria. Essa atualização é um processo padrão em que o Ambiente do Serviço de Aplicativo não será afetado, mas você não poderá dimensionar ou fazer alterações no Ambiente do Serviço de Aplicativo enquanto a atualização estiver em andamento. Não é possível migrar até que a atualização seja concluída. As atualizações podem levar de 8 a 12 horas para serem concluídas ou mais, dependendo do tamanho do ambiente. Se você planejar uma janela de tempo específica para a migração, deverá executar a verificação de validação de 24 a 48 horas antes do tempo de migração planejado para garantir que você tenha tempo para uma atualização, se necessária.

Selecionar e preparar a sub-rede para o novo Ambiente do Serviço de Aplicativo v3

A plataforma cria o Ambiente do Serviço de Aplicativo v3 em uma sub-rede diferente do Ambiente do Serviço de Aplicativo existente. Você precisa selecionar uma sub-rede que atenda aos seguintes requisitos:

• A sub-rede deve estar na mesma rede virtual e, portanto, na mesma região que o Ambiente do Serviço de Aplicativo existente.
  • Se a rede virtual não tiver uma sub-rede disponível, você precisará criar uma. Talvez seja necessário aumentar o espaço de endereço da sua rede virtual para criar uma sub-rede. Para obter mais informações, consulte Criar uma rede virtual.
• A sub-rede deverá se comunicar em ambas as direções com a sub-rede em que o Ambiente do Serviço de Aplicativo existente está. Não deverá haver grupos de segurança de rede nem outras configurações de rede que possam impedir a comunicação entre as sub-redes.
• A sub-rede deverá ter uma única delegação de Microsoft.Web/hostingEnvironments.
• A sub-rede deverá ter endereços IP disponíveis suficientes para dar suporte ao novo Ambiente do Serviço de Aplicativo v3. O número de endereços IP necessários dependerá do número de instâncias que você vai usar para o novo Ambiente do Serviço de Aplicativo v3. Para saber mais, confira Rede do Ambiente do Serviço de Aplicativo v3.
• A sub-rede não deverá ter nenhum bloqueio aplicado. Se houver bloqueios, eles deverão ser removidos antes da migração. Se necessário, os bloqueios poderão ser adicionados novamente quando a migração for concluída. Para obter mais informações sobre bloqueios e herança de bloqueio, consulte Bloquear recursos para proteger a infraestrutura.
• Não deve haver nenhuma política do Azure bloqueando a migração ou as ações relacionadas. Se houver políticas que bloqueiem a criação de Ambientes do Serviço de Aplicativo ou a modificação de sub-redes, elas deverão ser removidas antes da migração. Se necessário, as políticas poderão ser adicionadas novamente quando a migração for concluída. Para obter mais informações sobre o Azure Policy, consulte a Visão geral do Azure Policy.

Gerar endereços IP de saída para o novo Ambiente do Serviço de Aplicativo v3

A plataforma cria os novos endereços IP de saída. Embora esses IPs sejam criados, a atividade com o Ambiente do Serviço de Aplicativo existente não é interrompida. No entanto, você não poderá dimensionar nem fazer alterações no ambiente existente. Esse processo leva cerca de 15 minutos para ser concluído.

Quando concluído, os novos IPs de saída que o seu futuro Ambiente do Serviço de Aplicativo v3 usará são criados. Esses novos IPs não têm nenhum efeito sobre o ambiente existente.

Você receberá o novo endereço IP de entrada após a conclusão da migração, mas antes de fazer a alteração do DNS para redirecionar o tráfego do cliente para o novo Ambiente do Serviço de Aplicativo v3. Você não obtém o IP de entrada neste momento no processo porque há dependências em recursos do Ambiente do Serviço de Aplicativo v3 que serão criados durante a etapa de migração. Você terá a chance de atualizar todos os recursos que dependem do novo IP de entrada antes de redirecionar o tráfego para o novo Ambiente do Serviço de Aplicativo v3.

Atualizar recursos dependentes com novos IPs de saída

Os novos IPs de saída são criados e fornecidos a você antes de realmente iniciar a migração. A nova saída padrão para os endereços públicos da Internet é fornecida para que você possa ajustar firewalls externos, roteamento DNS, grupos de segurança de rede e outros recursos que dependam desses IPs antes de concluir a migração. É sua responsabilidade atualizar todos os recursos que serão afetados pela alteração de endereço IP associada ao novo Ambiente do Serviço de Aplicativo v3. Não passe para a próxima etapa antes de fazer todas as atualizações necessárias. Você poderá experimentar tempo de inatividade durante e após a etapa de migração se tiver dependências nos IPs de saída e não conseguir fazer todas as atualizações necessárias. Isso ocorre porque, quando a migração é iniciada, mesmo que o tráfego ainda vá para os front-ends do Ambiente do Serviço de Aplicativo v2, sua computação subjacente é seu novo Ambiente do Serviço de Aplicativo v3 na nova sub-rede.

Essa etapa também é um bom momento para examinar as alterações de dependência de rede de entrada e saída ao mudar para o Ambiente do Serviço de Aplicativo v3, incluindo a alteração de porta para a investigação de integridade do Azure Load Balancer, que agora usa a porta 80.

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. A migração não terá êxito se a sub-rede do Ambiente do Serviço de Aplicativo não for delegada ou for delegada a um recurso diferente. A sub-rede selecionada para o novo Ambiente do Serviço de Aplicativo v3 deverá ter uma única delegação de Microsoft.Web/hostingEnvironments.

Reconhecer alterações no tamanho da instância

Seus Planos do Serviço de Aplicativo serão criados com o SKU Isolado v2 correspondente como parte da migração. Por exemplo, os planos I2 correspondem ao I2v2. Seus aplicativos podem ficar superprovisionados após a migração, pois a camada Isolada v2 tem mais memória e CPU por tamanho de instância correspondente. Você tem a oportunidade de escalar seu ambiente conforme necessário após a conclusão da migração. Para obter mais informações, revise os Detalhes do SKU.

Verifique se não existem bloqueios em seus recursos

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, os bloqueios poderão ser adicionados novamente quando a migração for concluída. 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.

Verifique se não há nenhuma migração de bloqueio do Azure Policies

O Azure Policy pode ser usado para negar a criação e a modificação de recursos a determinadas entidades de segurança. Se você tiver uma política que bloqueie a criação de Ambientes do Serviço de Aplicativo ou a modificação de sub-redes, será necessário removê-la antes de migrar. Se necessário, os bloqueios poderão ser adicionados novamente quando a migração for concluída. Para obter mais informações sobre o Azure Policy, consulte a Visão geral do Azure Policy.

Adicionar um sufixo de domínio personalizado (opcional)

Se o Ambiente do Serviço de Aplicativo existente usar um sufixo de domínio personalizado, você deverá configurar um sufixo de domínio personalizado para o novo Ambiente do Serviço de Aplicativo v3. O sufixo de domínio personalizado no Ambiente do Serviço de Aplicativo v3 é implementado de maneira diferente do que no Ambiente do Serviço de Aplicativo v2. Você precisa fornecer o nome de domínio personalizado, a identidade gerenciada e o certificado, que devem ser armazenados no Azure Key Vault. Para obter mais informações sobre o sufixo 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 Configurar um sufixo de domínio personalizado para o Ambiente do Serviço de Aplicativo. Se o Ambiente do Serviço de Aplicativo v2 tiver um sufixo de domínio personalizado, você deverá configurar um sufixo de domínio personalizado para o novo ambiente, mesmo se você não quiser mais usá-lo. Após concluir a migração, você poderá remover a configuração de sufixo de domínio personalizado, se necessário.

Se a migração incluir um sufixo de domínio personalizado, para o Ambiente do Serviço de Aplicativo v3, o domínio personalizado não será mostrado na seção Essentials da página Visão Geral do portal, como é para o Ambiente do Serviço de Aplicativo v1/v2. Em vez disso, para o Ambiente do Serviço de Aplicativo v3, vá para a página Sufixo de domínio personalizado em que você poderá confirmar se o sufixo de domínio personalizado está configurado corretamente. Além disso, no Ambiente do Serviço de Aplicativo v2, se você tiver um sufixo de domínio personalizado, o nome do host padrão incluirá o seu sufixo de domínio personalizado e estará no formulário APP-NAME.internal.contoso.com. No Ambiente do Serviço de Aplicativo v3, o nome do host padrão sempre usa o sufixo de domínio padrão e estará no formulário APP-NAME.ASE-NAME.appserviceenvironment.net. Essa diferença ocorre porque o Ambiente do Serviço de Aplicativo v3 mantém o sufixo de domínio padrão quando você adiciona um sufixo de domínio personalizado. Com o Ambiente do Serviço de Aplicativo v2, há apenas um único sufixo de domínio.

Migrar para o Ambiente do Serviço de Aplicativo v3

Após concluir as etapas anteriores, será necessário continuar com a migração o mais rápido possível.

Não há tempo de inatividade do aplicativo durante a migração, mas como ocorre na etapa de geração de IP, você não poderá escalar ou modificar o Ambiente do Serviço de Aplicativo existente nem implantar aplicativos nele durante esse processo.

Importante

Como o dimensionamento é bloqueado durante a migração, você deve dimensionar seu ambiente para o tamanho desejado antes de iniciar a migração. Se o escalonamento automático estiver habilitado e um evento de escalonamento ocorrer antes do início da migração, será necessário aguardar a conclusão dele para iniciar a migração. Para evitar esse problema, desabilite o escalonamento automático 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.

Esta etapa também é aquela em que você decide se deseja habilitar a redundância de zona para o novo Ambiente do Serviço de Aplicativo v3. A redundância de zona pode ser habilitada desde que o Ambiente do Serviço de Aplicativo v3 esteja em uma região que dê suporte à redundância de zona.

A migração lado a lado exige uma janela de serviço de três a seis horas para migrações do Ambiente de Serviço de Aplicativo v2 para v3. Durante a migração, as configurações de dimensionamento e ambiente são bloqueadas e os seguintes eventos ocorrem:

• O novo Ambiente do Serviço de Aplicativo v3 é criado na sub-rede selecionada.
• Seus novos Planos do Serviço de Aplicativo são criados no novo Ambiente do Serviço de Aplicativo v3 com a camada Isolada v2 correspondente.
• Seus aplicativos serão criados no novo Ambiente do Serviço de Aplicativo v3.
• Os funcionários/computação subjacentes para seus aplicativos são movidos para o novo Ambiente do Serviço de Aplicativo v3, o que significa que seus aplicativos agora estão em execução no Ambiente do Serviço de Aplicativo v3. No entanto, os front-ends do Ambiente do Serviço de Aplicativo v2, por padrão, ainda estão em execução e atendendo ao tráfego. Seu endereço IP de entrada antigo permanece em uso, mas seus novos IPs de saída estão em uso. Além disso, seus novos front-ends do Ambiente do Serviço de Aplicativo v3 são criados e prontos para atender ao tráfego.
  • Para ambientes do Serviço de Aplicativo ILB, os front-ends do Ambiente do Serviço de Aplicativo v3 não serão usados até que você atualize as zonas DNS privadas com o novo endereço IP de entrada.
  • Para Ambientes do Serviço de Aplicativo de ELB, o processo de migração não redireciona o tráfego para os front-ends do Ambiente do Serviço de Aplicativo v3, até que você conclua a etapa final da migração.

Quando essa etapa for concluída, o tráfego do aplicativo continuará direcionado para o antigo Ambiente do Serviço de Aplicativo v2 e os IPs de entrada que foram atribuídos a ele. No entanto, seus aplicativos estão realmente em execução em trabalhos em seu novo Ambiente do Serviço de Aplicativo v3.

Observação

Devido a um bug conhecido, os trabalhos da Web podem não ser iniciados durante a etapa de implantação híbrida. Se você usar trabalhos da Web, esse bug poderá causar problemas/tempo de inatividade do aplicativo. Abra um caso de suporte caso tenha dúvidas ou preocupações sobre esse problema.

Obter o endereço IP de entrada para seu novo Ambiente do Serviço de Aplicativo v3 e atualizar recursos dependentes

O novo endereço IP de entrada é fornecido para que você possa configurar novos pontos de extremidade com serviços como o Gerenciador de Tráfego ou o Azure Front Door e atualize qualquer uma de suas zonas DNS privadas. Não passe para a próxima etapa antes de fazer essas alterações. Haverá tempo de inatividade se você não atualizar recursos dependentes com o novo IP de entrada. É sua responsabilidade atualizar todos os recursos afetados pela alteração de endereço IP associada ao novo Ambiente do Serviço de Aplicativo v3. Não passe para a próxima etapa antes de fazer todas as atualizações necessárias.

Redirecionar o tráfego do cliente, validar o Ambiente do Serviço de Aplicativo v3 e concluir a migração

A etapa final é redirecionar o tráfego para seus novos front-ends do Ambiente do Serviço de Aplicativo v3 e concluir a migração. Antes de executar esta etapa, você deve examinar o novo Ambiente do Serviço de Aplicativo v3 e executar todos os testes necessários para validar que ele está funcionando conforme o esperado. Por padrão, o tráfego vai 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.

Quando estiver pronto para redirecionar o tráfego, você poderá realizar a etapa final da migração. Esta etapa atualiza registros DNS internos/de plataforma para apontar para o endereço IP do balanceador de carga do novo Ambiente do Serviço de Aplicativo v3 e os front-ends que foram criados durante a migração. As alterações são efetivadas em alguns minutos. É sua responsabilidade atualizar seus registros DNS para apontar para o novo endereço IP de entrada. Se você tiver problemas ou tempo de inatividade do aplicativo, verifique as configurações de cache e TTL. Esta etapa também desliga o ambiente antigo do Serviço de Aplicativo e o exclui. Seu novo Ambiente do Serviço de Aplicativo v3 agora é o ambiente de produção.

Importante

A plataforma garante uma experiência de migração de tempo de inatividade zero. No entanto, suas configurações de DNS podem causar tempo de inatividade durante a etapa de alteração de DNS. Isso pode ser devido a problemas relacionados a configurações de TTL e cache, pois o tráfego ainda pode ser direcionado para o ambiente antigo do Serviço de Aplicativo após a alteração do DNS. Você deve examinar suas configurações de DNS e garantir que você tenha um TTL baixo e que seu provedor DNS dê suporte à propagação rápida. Se você tiver um TTL alto, poderá enfrentar tempo de inatividade durante a etapa de alteração de DNS.

Observação

É importante concluir esta etapa o mais rápido possível. Quando o seu Ambiente de Serviço de Aplicações está no estado híbrido, não consegue receber atualizações de plataforma e patches de segurança, o que o torna mais vulnerável à instabilidade e às ameaças de segurança.

Você tem 14 dias para concluir esta etapa. Após 14 dias, a plataforma concluirá automaticamente a migração e excluirá seu antigo ambiente. Se precisar de mais tempo, você pode abrir um caso de suporte para discutir suas opções.

Se você descobrir problemas com o novo Ambiente do Serviço de Aplicativo v3, não execute o comando para redirecionar o tráfego do cliente. Esse comando também iniciará a exclusão do Ambiente do Serviço de Aplicativo v2. Se você encontrar um problema, entre em contato com o suporte.

Usar o recurso de migração lado a lado

Pré-requisitos

Certifique-se de entender como a migração para um Ambiente do Serviço de Aplicativo v3 afeta seus aplicativos. Examine o processo de migração em sua totalidade para entender a linha do tempo do processo e onde e quando 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. Se o escalonamento automático estiver habilitado e um evento de escalonamento ocorrer antes do início da migração, ela ficará bloqueada até que o evento de escalonamento seja concluído. Para evitar esse problema, desabilite o escalonamento automático antes de iniciar a migração.

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. 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

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"

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

Usando os novos IPs de saída, atualize qualquer um dos seus recursos ou componentes de rede para garantir que seu novo ambiente funcione conforme pretendido após a migração ser iniciada. É sua responsabilidade fazer as atualizações necessárias. Os novos IPs de saída são usados depois que o Ambiente do Serviço de Aplicativo v3 é criado durante a etapa de migração. Por exemplo, se você tiver um sufixo de domínio personalizado e um Azure Key Vault e estiver gerenciando restrições de acesso com um firewall, será necessário atualizar o firewall do Azure Key Vault para permitir apenas os novos IPs de saída ou toda a nova sub-rede.

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.

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. Você sofrerá tempo de inatividade se não conseguir definir corretamente esse acesso antes da migração.

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.

Para definir essas configurações, incluindo a identificação da sub-rede que você selecionou anteriormente, crie um arquivo chamado parameters.json com os seguintes detalhes baseados 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-o de acordo com seu requisito de resiliência.

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 haverá tempo de inatividade do aplicativo se você seguiu as etapas anteriores. 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.

Observação

Devido a um bug conhecido, os trabalhos da Web podem não ser iniciados durante a etapa de implantação híbrida. Se você usar trabalhos da Web, esse bug pode causar problemas/tempo de inatividade do aplicativo. Abra um caso de suporte caso tenha dúvidas ou preocupações sobre esse problema.

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 conjuntos de front-ends do Ambiente do Serviço de Aplicativo neste estágio no processo de migração e ambos os conjuntos são capazes de atender ao tráfego do aplicativo. O DNS não é alterado, portanto, por padrão, o tráfego é enviado para os front-ends antigos do Ambiente do Serviço de Aplicativo. 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

Importante

Se a sua migração incluir um sufixo de domínio personalizado, o comportamento do nome do host padrão para o Ambiente do Serviço de Aplicativo v3 será diferente do comportamento para o Ambiente do Serviço de Aplicativo v2. Para o Ambiente do Serviço de Aplicativo v3, o nome do host padrão sempre usa o sufixo de domínio padrão e tem o formato APP-NAME.ASE-NAME.appserviceenvironment.net. Revise todos os seus recursos dependentes, como o Gateway de Aplicativo, que usam os nomes de host dos seus aplicativos para garantir que eles sejam atualizados para levar em conta esse comportamento. Para obter mais informações sobre as diferenças de recursos do Ambiente do Serviço de Aplicativo entre as diferentes versões, consulte Comparação de versões do Ambiente do Serviço de Aplicativo.

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.

Importante

Você tem 14 dias para concluir esta etapa. Após 14 dias, a plataforma concluirá automaticamente a migração e excluirá seu antigo ambiente. Se precisar de mais tempo, você pode abrir um caso de suporte para discutir suas opções.

Depois de confirmar que seus aplicativos estão funcionando conforme o esperado, você pode finalizar a migração executando o comando a seguir. Esse comando também exclui seu ambiente antigo.

Se você encontrar problemas ou decidir que não deseja continuar com a migração neste ponto, entre em contato com o suporte para discutir suas opções. Não execute o comando de alteração de DNS, pois esse comando conclui a 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.

Fontes comuns de problemas ao migrar usando o recurso de migração lado a lado

Veja a seguir exemplos de fontes comuns de problemas que os clientes encontram ao migrar usando o recurso de migração lado a lado. Examine estas áreas para garantir que não tenha tempo de inatividade ou interrupções de serviço durante ou após o processo de migração.

• O Azure Key Vault deverá permitir o tráfego dos novos IPs/sub-rede de saída.
• As duas sub-redes devem poder se comunicar entre si em ambas as direções. Os clientes normalmente permitem o tráfego da sub-rede antiga para a nova, mas esquecem de permitir o tráfego da nova para a sub-rede antiga.
• O Gateway de Aplicativo deve ser atualizado com os novos endereços IP.
• Os registros de DNS devem ser atualizados com os novos endereços IP.
• Caso tenha codificado endereços IP nos aplicativos, precisará atualizá-los com os novos endereços IP.
• As tabelas de rotas devem ser atualizadas com novas rotas.

Preços

Não há nenhum custo para migrar o Ambiente do Serviço de Aplicativo. No entanto, você será cobrado pelo Ambiente do Serviço de Aplicativo v2 e o novo Ambiente do Serviço de Aplicativo v3 depois de iniciar o processo de migração. Você deixa de ser cobrado pelo antigo Ambiente do Serviço de Aplicativo v2 ao concluir a etapa de migração final em que o ambiente antigo é excluído. Você deve concluir a validação o mais rápido possível para evitar o acúmulo de cobranças em excesso. Para obter mais informações sobre os preços do Ambiente do Serviço de Aplicativo v3, consulte os detalhes de preços.

Ao migrar de versões anteriores para o Ambiente do Serviço de Aplicativo v3, há cenários que você deve considerar que podem reduzir o custo mensal. As reservas e os planos de economia podem reduzir ainda mais seus custos. Para obter informações sobre oportunidades de economia de custos, consulte Oportunidades de economia de custos após a atualização para o Ambiente do Serviço de Aplicativo v3.

Observação

Devido às diferenças entre os tipos de preço Isolado e Isolado v2, seus aplicativos poderão ser superprovisionados após a migração, uma vez que a camada Isolado v2 tem mais memória e CPU por tamanho de instância correspondente. Você terá a oportunidade de escalar o ambiente conforme necessário quando a migração for concluída. Para obter mais informações, revise os Detalhes do SKU.

Reduzir verticalmente seus planos do Serviço de Aplicativo

Os SKUs do plano do Serviço de Aplicativo disponíveis para Ambiente do Serviço de Aplicativo v3 são executados na camada Isolado v2 (Iv2). O número de núcleos e a quantidade de RAM são efetivamente dobrados por camada correspondente em comparação com a camada Isolada. Ao migrar, seus planos do Serviço de Aplicativo são convertidos na camada correspondente. Por exemplo, suas instâncias I2 são convertidas em I2v2. Embora a I2 tenha dois núcleos e 7 GB de RAM, a I2v2 tem quatro núcleos e 16 GB de RAM. Se você espera que seus requisitos de capacidade permaneçam iguais, você está superprovisionado e pagando por computação e memória que não está usando. Para esse cenário, você pode reduzir verticalmente sua instância I2v2 para I1v2 e acabar com um número semelhante de núcleos e RAM que você tinha anteriormente.

Perguntas frequentes

• E se não houver suporte para migrar meu Ambiente do Serviço de Aplicativo no momento?
  No momento, não é possível migrar usando o recurso de migração lado a lado. Se você tiver um ambiente sem suporte e desejar migrar imediatamente, consulte as Opções de migração manual.
• Como faço para escolher a opção de migração ideal para mim?
  Leia a árvore de decisão de caminho de migração para decidir qual opção é melhor para seu caso de uso.
• Como posso saber se devo usar o recurso de migração lado a lado?
  O recurso de migração lado a lado é melhor para clientes que desejam migrar para o Ambiente do Serviço de Aplicativo v3, mas não podem suportar o tempo de inatividade do aplicativo. Como uma nova sub-rede será usada para seu novo ambiente, há considerações de rede a serem observadas, incluindo novos IPs. Se você puder contar com algum tempo de inatividade, confira o recurso de migração in-loco, que resulta em alterações mínimas de configuração, ou as opções de migração manual. O recurso de migração in-loco cria o Ambiente do Serviço de Aplicativo v3 na mesma sub-rede que o ambiente existente e usa a mesma infraestrutura de rede.
• Haverá tempo de inatividade durante a migração?
  A plataforma garante que não haja tempo de inatividade durante o processo de migração lado a lado. No entanto, suas configurações de DNS podem causar tempo de inatividade durante a etapa de alteração de DNS. Isso pode ser devido a problemas relacionados a configurações de TTL e cache, pois o tráfego ainda pode ser direcionado para o ambiente antigo do Serviço de Aplicativo após a alteração do DNS. Você deve examinar suas configurações de DNS e garantir que você tenha um TTL baixo e que seu provedor DNS dê suporte à propagação rápida.
• Precisarei fazer algo com meus aplicativos após a migração para colocá-los em execução no novo Ambiente do Serviço de Aplicativo?
  Não, todos os aplicativos em execução no ambiente antigo serão migrados automaticamente para o novo ambiente e executados como antes. Nenhuma entrada do usuário é necessária.
• E se meu Ambiente do Serviço de Aplicativo tiver um sufixo de domínio personalizado?
  O recurso de migração lado a lado oferece suporte a esse cenário de migração.
• E se meu Ambiente do Serviço de Aplicativo estiver fixado à zona?
  O recurso de migração lado a lado não oferece suporte a esse cenário de migração no momento. Se você tiver um Ambiente do Serviço de Aplicativo fixado em uma zona e quiser migrar imediatamente, consulte as opções de migração manual.
• E se meu Ambiente de Serviço de Aplicativo tiver endereços IP SSL?
  Não há suporte para IP SSL no Ambiente de Serviço de Aplicativo v3. Você deve remover todos as associações de IP SSL antes de migrar usando o recurso de migração ou uma das opções manuais. Se você pretende usar o recurso de migração lado a lado, depois de remover todas as associações de IP SSL, você passará nessa verificação de validação e poderá prosseguir com a migração automatizada.
• Quais propriedades de meu Ambiente do Serviço de Aplicativo serão alteradas?
  Você está no Ambiente do Serviço de Aplicativo v3, portanto, não deixe de examinar os recursos e as diferenças de recursos em comparação com as versões anteriores. Os IPs de entrada e de saída são alterados ao usar o recurso de migração lado a lado. Observe que, para o Ambiente do Serviço de Aplicativo de ELB, anteriormente havia um único IP para entrada e saída. Para o Ambiente do Serviço de Aplicativo v3, eles são separados. Para saber mais, confira Rede do Ambiente do Serviço de Aplicativo v3. Para obter uma comparação completa das versões do Ambiente do Serviço de Aplicativo, consulte Comparação de versão do Ambiente do Serviço de Aplicativo.
• O que acontecerá se a migração falhar ou se houver um problema inesperado durante a migração?
  Se houver um problema inesperado, equipes de suporte estarão disponíveis. Recomendamos migrar ambientes de desenvolvimento antes de mexer em qualquer ambiente de produção para saber mais sobre o processo de migração e ver como isso afeta suas cargas de trabalho.
• O que acontecerá com meu Ambiente do Serviço de Aplicativo antigo?
  Se você decidir migrar um Ambiente do Serviço de Aplicativo usando o recurso de migração lado a lado, o ambiente antigo será usado até a etapa final do processo de migração. Depois de concluir a etapa final, o ambiente antigo e todos os aplicativos hospedados nele serão desligados e excluídos. Seu ambiente antigo não estará mais acessível. Não é possível reverter para o ambiente antigo neste momento.
• O que acontecerá com os recursos do Ambiente do Serviço de Aplicativo V1/V2 depois de 31 de agosto de 2024?
  Após 31 de agosto de 2024, se você não tiver migrado para o Ambiente do Serviço de Aplicativo v3, seu Ambiente do Serviço de Aplicativo v1/v2 e os aplicativos implantados neles não estarão mais disponíveis. O Ambiente do Serviço de Aplicativo v1/v2 é hospedado em unidades de escala do serviço de aplicativo em execução na arquitetura de Serviços de nuvem (clássico) que será desativada em 31 de agosto de 2024. Por isso, o Ambiente do Serviço de Aplicativo v1/v2 não estará mais disponível após essa data. Migre para Ambiente do Serviço de Aplicativo v3 para manter seus aplicativos em execução ou salvar ou fazer backup de todos os recursos ou dados que você precisa manter.

Próximas etapas

Rede do Ambiente do Serviço de Aplicativo v3

Usar um Ambiente do Serviço de Aplicativo v3

Sufixo do Custom Domain