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

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ê não solicitou um período de carência de 30 dias, revise a visão geral do período de carência e, em seguida, solicite um período de carência acessando o portal do Azure e visitando a folha Migração para cada um dos 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 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.

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

O Serviço de Aplicativo pode automatizar a migração do seu Ambiente do Serviço de Aplicativo v1 e v2 para um Ambiente do Serviço de Aplicativo v3. Existem diferentes opções de migração. Analise a árvore de decisão do caminho de migração para decidir qual opção é melhor para seu caso de uso. O Ambiente do Serviço de Aplicativo v3 oferece vantagens e diferenças de recursos em relação às versões anteriores. Certifique-se de revisar os recursos suportados do Ambiente do Serviço de Aplicativo v3 antes de migrar para reduzir o risco de um problema inesperado do 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. Seu Ambiente do Serviço de Aplicativo existente não será excluído até que você inicie sua 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 oferecer suporte ao uso de uma sub-rede diferente para seu novo ambiente. Se você precisar usar a mesma sub-rede e puder suportar cerca de uma hora de inatividade do aplicativo, consulte o recurso de migração in-loco. Para obter opções de migração manual que permitem migrar no seu próprio ritmo, consulte Opções de migração manual.

Importante

Se você não concluir todas as etapas descritas neste tutorial, você enfrentará 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 chave de sufixo de domínio personalizado, você enfrentará tempo de inatividade até que isso seja resolvido.

É recomendável usar esse recurso para ambientes de desenvolvimento primeiro antes de migrar qualquer ambiente de produção para ensaiar o processo e garantir que não haja problemas inesperados. Por favor, forneça qualquer feedback relacionado a este artigo ou ao recurso usando os botões na parte inferior da página.

Cenários suportados

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

Azure Público

• E.A.U. Central

Azure Government

• US DoD - Centro
• US DoD - Leste
• US Gov - Arizona
• US Gov - Texas
• US Gov - Virginia

Microsoft Azure operado pela 21Vianet

• China Leste 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 no 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 ILB (Balanceador de Carga Interno) v2	Ambiente do Serviço de Aplicativo ILB v3
Ambiente de Serviço de Aplicativo Externo (ELB/Internet voltado para IP público) v2	Ambiente do Serviço de Aplicativo ELB v3
ILB App Service Environment v2 com um sufixo de domínio personalizado	Ambiente do Serviço de Aplicativo ILB v3 com um sufixo de domínio personalizado

O Ambiente do Serviço de Aplicativo v3 pode ser implantado como zona redundante. A redundância de zona pode ser habilitada desde que seu Ambiente do Serviço de Aplicativo v3 esteja em uma região que ofereça suporte à redundância de zona.

Se você quiser que seu 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 assim que a migração for concluída. Para obter mais informações, consulte Configurar 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, 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

A seguir estão 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 do ambiente existente.
• Não é possível alterar a região na qual o Ambiente do Serviço de Aplicações está localizado.
• O Ambiente do Serviço de Aplicações do ELB não pode ser migrado para o Ambiente do Serviço de Aplicações v3 do ILB e vice-versa.
• Se o Ambiente do Serviço de Aplicações existente utilizar um sufixo de domínio personalizado, terá de configurar o sufixo de domínio personalizado para o Ambiente do Serviço de Aplicações v3 durante o processo de migração.
  • Se já não pretender utilizar um sufixo de domínio personalizado, pode removê-lo quando a migração estiver concluída.
• O recurso de migração lado a lado só está disponível usando a CLI ou via API REST. O recurso não está disponível no portal do Azure.

O Ambiente do Serviço de Aplicativo v3 não oferece suporte aos seguintes recursos que você pode estar usando com seu Ambiente do Serviço de Aplicativo v2 atual.

• Configurar um enlace TLS/SSL baseado em IP com as aplicações.
• O Ambiente do Serviço de Aplicações v3 não reverte para o DNS do Azure se os seus servidores DNS personalizados configurados na rede virtual não conseguirem resolver um nome especificado. Se esse comportamento for necessário, certifique-se de que 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 suporta os 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 do seu Ambiente do Serviço de Aplicativo navegando até o Ambiente do Serviço de Aplicativo no portal do Azure e selecionando Configuração em Configurações, no lado esquerdo. Você também pode usar o Gerenciador de Recursos do Azure e revisar o kind valor da propriedade para seu 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 do Serviço de Aplicações v2 do ELB com endereços SSL IP
• Ambiente do Serviço de Aplicativo fixo por zona v2
• Ambiente do Serviço de Aplicativo com um nome que não atende aos limites de caracteres. O nome inteiro, incluindo o sufixo de 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 atingir o limite de caracteres, deverá migrar 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 analisa seu Ambiente do Serviço de Aplicativo para confirmar o suporte à migração lado a lado. Se o seu cenário não passar em todas as verificações de validação, você não poderá migrar neste momento usando o recurso de migração lado a lado. Se o ambiente estiver em um estado não íntegro ou suspenso, você não poderá migrar até fazer as atualizações necessárias.

Nota

O Ambiente do Serviço de Aplicativo v3 não suporta IP SSL. Se você usar IP SSL, deverá remover todas as associações IP SSL antes de migrar para o Ambiente do Serviço de Aplicativo v3. O recurso de migração suportará seu ambiente assim que todas as ligações IP SSL forem removidas.

Resolução de Problemas

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

Mensagem de erro	Description	Recomendação
A migração só pode ser chamada em um ASE em ARM VNET e este ASE está em VNET Classic.	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.	Migre 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 suportar o Ambiente do Serviço de Aplicativo v3.	Migre usando uma das opções de migração manual se quiser migrar imediatamente. Caso contrário, aguarde até que o recurso de migração lado a lado esteja disponível na sua região.
Não é possível ativar a redundância de zona para este ASE.	A região em que o Ambiente do Serviço de Aplicativo está não oferece 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 ofereça suporte à redundância de zona.
Migrar não pode ser chamado neste sufixo DNS personalizado ASE no momento.	A migração de sufixos de domínio personalizados está bloqueada.	Abra um caso de suporte para contratar o suporte para resolver seu problema.
A migração ASE redundante de zona não pode ser chamada no momento.	A migração do Ambiente do Serviço de Aplicativo redundante de zona está bloqueada.	Abra um caso de suporte para contratar o suporte para resolver seu problema.
A migração não pode ser chamada no ASEv2 fixado por zona.	O Ambiente do Serviço de Aplicativo v2 com zona fixada 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 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 em andamento seja concluída antes de tentar iniciar a migração novamente.
Properties.VirtualNetwork.Id deve conter o ID do recurso de sub-rede.	O erro aparece se você tentar migrar sem fornecer uma nova sub-rede para o posicionamento do seu Ambiente do Serviço de Aplicativo v3.	Certifique-se de seguir as orientações e concluir a etapa para identificar a sub-rede que você usará para seu Ambiente do Serviço de Aplicativo v3.
Não é possível mover para <requested phase> a fase <previous phase> atual de Sem migração de tempo de inatividade.	Este erro aparece se você tentar fazer uma etapa de migração na ordem incorreta.	Certifique-se de seguir as etapas de migração na ordem.
Falha ao iniciar a operação de reversão no ASE no estado híbrido, tente novamente mais tarde.	Este erro aparece se tentar reverter a migração, mas algo corre mal. Este erro não afeta o ambiente antigo nem o novo.	Abra um caso de suporte para contratar o suporte para resolver seu problema.
Este ASE não pode ser migrado sem tempo de inatividade.	Esse erro aparece 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 oferece suporte ao 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.
Migrar não está disponível para esta assinatura.	O suporte precisa ser contratado para migrar esse Ambiente do Serviço de Aplicativo.	Abra um caso de suporte para contratar o suporte para resolver seu problema.
A migração redundante de zona não pode ser chamada, pois os endereços IP criados durante a pré-migração não são redundantes de zona.	Este erro aparece se você tentar uma migração redundante de zona, mas os IPs gerados durante a etapa de geração de IP não foram criados como zona redundante. A plataforma tenta tornar todas as zonas IPs redundantes para garantir a resiliência do back-end.	Abra um caso de suporte para ativar o suporte se 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ê pode migrar sem habilitar a redundância de zona.
A migração não pode 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 aparece se você especificar a mesma sub-rede em que seu ambiente atual está para o posicionamento do seu Ambiente do Serviço de Aplicativo v3.	Você deve especificar uma sub-rede diferente para seu 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. Por favor, remova alguns antes de tentar criar mais.	A cota do Ambiente do Serviço de Aplicativo para sua assinatura é atendida.	Remova ambientes desnecessários ou contacte o suporte para rever as suas opções.
A migração não pode ser chamada neste ASE até que a atualização ativa tenha sido concluída.	Os Ambientes do Serviço de Aplicativo não podem ser migrados durante as atualizações da plataforma. Pode definir a sua preferência de atualização no portal do Azure. As atualizações levam de 8 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 termine e, em seguida, migre.
Operação de gerenciamento do Ambiente do Serviço de Aplicativo em andamento.	Seu 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 é bloqueada até que estas operações estejam concluídas.	Você pode migrar assim que essas operações forem concluídas.
Seu InternalLoadBalancingMode não é suportado no momento.	Os Ambientes do Serviço de Aplicativo que têm InternalLoadBalancingMode definido para 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 um caso de suporte para contratar o suporte para resolver seu problema. Solicite uma atualização para o InternalLoadBalancingMode.
A migração completa não pode ser chamada antes que os endereços IP sejam gerados.	Este erro aparece se você tentar migrar antes de concluir as etapas de pré-migração.	Certifique-se de concluir todas as etapas de pré-migração antes de tentar migrar. Consulte o guia passo a passo para migrar.
A migração completa não pode ser chamada no Ase com o conjunto de sufixos dns personalizados, mas sem uma Configuração de Sufixo Dns Personalizado AseV3 configurada.	Seu Ambiente do Serviço de Aplicativo existente usa um sufixo de domínio personalizado. Você precisa configurar o sufixo de domínio personalizado para seu Ambiente do Serviço de Aplicativo v3 durante o processo de migração.	Configure um sufixo de domínio personalizado. Se já não pretender utilizar um sufixo de domínio personalizado, pode removê-lo quando a migração estiver 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 principais são fornecidos para um subconjunto dos passos. É importante compreender o que acontece durante estes passos e como o seu ambiente e aplicações são afetados. Depois de analisar as informações seguintes e quando estiver pronto para migrar, siga o guia passo a passo.

Valide se a migração é suportada usando o recurso de migração lado a lado para seu Ambiente do Serviço de Aplicativo

A plataforma valida que seu 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 de validação, você não poderá migrar neste momento usando o recurso de migração lado a lado. Consulte a seção de solução de problemas para obter detalhes sobre as possíveis causas da falha de validação. Se o ambiente estiver em um estado não íntegro ou suspenso, você não poderá migrar até fazer as atualizações necessárias. Se não for possível migrar usando o recurso de migração lado a lado, consulte as opções de migração manual.

A validação também verifica se o Ambiente do Serviço de Aplicativo está na compilação mínima necessária para a migração. Essa compilação pode ser mais recente do que a compilação padrão implantada com o ciclo de atualização/manutenção da plataforma de rotina. A compilação mínima é atualizada periodicamente para garantir que as últimas correções de bugs e melhorias estejam disponíveis. Se o Ambiente do Serviço de Aplicativo não estiver na compilação mínima, você mesmo precisará iniciar a atualização. Essa atualização é um processo padrão em que o Ambiente do Serviço de Aplicativo não é afetado, mas você não pode 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 seu ambiente. Se você planejar uma janela de tempo específica para sua migração, deverá executar a verificação de validação 24 a 48 horas antes do horário de migração planejado para garantir que tenha tempo para uma atualização, se necessário.

Selecione e prepare a sub-rede para seu novo Ambiente do Serviço de Aplicativo v3

A plataforma cria seu novo 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 sua 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 nova sub-rede. Para obter mais informações, consulte Criar uma rede virtual.
• A sub-rede deve ser capaz de se comunicar em ambas as direções com a sub-rede em que seu Ambiente do Serviço de Aplicativo existente está. Verifique se não há grupos de segurança de rede ou outras configurações de rede que impeçam a comunicação entre as sub-redes.
• A sub-rede deve ter uma única delegação de Microsoft.Web/hostingEnvironments.
• A sub-rede deve ter endereços IP disponíveis suficientes para dar suporte ao seu novo Ambiente do Serviço de Aplicativo v3. O número de endereços IP necessários depende do número de instâncias que você deseja usar para seu novo Ambiente do Serviço de Aplicativo v3. Para obter mais informações, consulte Rede do Ambiente do Serviço de Aplicações V3.
• A sub-rede não deve ter nenhum bloqueio aplicado a ela. Se houver bloqueios, eles devem ser removidos antes da migração. Os bloqueios podem ser readicionados, se necessário, assim que a migração for concluída. Para obter mais informações sobre bloqueios e herança de bloqueio, consulte Bloquear seus recursos para proteger sua infraestrutura.
• Não deve haver nenhuma Política do Azure bloqueando a migração ou 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. As políticas podem ser readicionadas, se necessário, assim que a migração for concluída. Para obter mais informações sobre a Política do Azure, consulte Visão geral da Política do Azure.

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

A plataforma cria os novos endereços IP de saída. Enquanto estes IPs estão a ser criados, a atividade no seu Ambiente do Serviço de Aplicações existente não é interrompida. No entanto, não pode dimensionar nem fazer alterações no seu ambiente existente. Este processo demora cerca de 15 minutos a concluir.

Quando concluído, os novos IPs de saída que seu futuro Ambiente do Serviço de Aplicativo v3 usa são criados. Estes novos IPs não têm efeito no seu ambiente existente.

Você recebe o novo endereço IP de entrada assim que a migração estiver concluída, mas antes de fazer a alteração de 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 ponto do processo porque há dependências nos recursos do Ambiente do Serviço de Aplicativo v3 que são criadas durante a etapa de migração. Você tem a chance de atualizar quaisquer 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 antes de iniciar a migração real. A nova saída padrão para os endereços públicos da Internet é fornecida para que você possa ajustar quaisquer firewalls externos, roteamento DNS, grupos de segurança de rede e quaisquer outros recursos que dependem desses IPs antes de concluir a migração. É sua responsabilidade atualizar todos e quaisquer 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 até ter feito todas as atualizações necessárias. Você pode enfrentar 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 assim que a migração é iniciada, mesmo que o tráfego ainda vá para os front-ends do Ambiente do Serviço de Aplicativo v2, a computação subjacente é o novo Ambiente do Serviço de Aplicativo v3 na nova sub-rede.

Esta etapa também é um bom momento para revisar as alterações de dependência de rede de entrada e saída ao migrar para o Ambiente do Serviço de Aplicativo v3, incluindo a alteração de porta para a sonda de integridade do Balanceador de Carga do Azure, 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 em que está tenha uma única delegação de Microsoft.Web/hostingEnvironments. A migração não poderá ser bem-sucedida se a sub-rede do Ambiente do Serviço de Aplicativo não estiver delegada ou se você delegá-la a um recurso diferente. Verifique se a sub-rede selecionada para o novo Ambiente do Serviço de Aplicativo v3 tem uma única delegação de Microsoft.Web/hostingEnvironments.

Reconhecer alterações no tamanho da instância

Seus planos do Serviço de Aplicativo são criados com a SKU Isolada v2 correspondente como parte da migração. Por exemplo, os planos I2 correspondem ao I2v2. Seus aplicativos podem ser provisionados em excesso após a migração, já que a camada Isolada v2 tem mais memória e CPU por tamanho de instância correspondente. Você tem a oportunidade de dimensionar seu ambiente conforme necessário assim que a migração for concluída. Para obter mais informações, consulte os detalhes do SKU.

Garantir que não existem bloqueios nos seus recursos

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. Os bloqueios podem ser readicionados, se necessário, assim que 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 em um escopo pai, todos os recursos dentro desse escopo herdam o mesmo bloqueio. Se você tiver bloqueios aplicados na assinatura, no grupo de recursos ou no 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 seus recursos para proteger sua infraestrutura.

Verifique se não há Políticas do Azure bloqueando a migração

A Política do Azure pode ser usada para negar a criação e a modificação de recursos para determinadas entidades. 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. A política pode ser readicionada, se necessário, assim que a migração for concluída. Para obter mais informações sobre a Política do Azure, consulte Visão geral da Política do Azure.

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 forma 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 Cofre da Chave do Azure. Para obter mais informações sobre o sufixo de domínio personalizado do Ambiente do Serviço de Aplicativo v3, incluindo requisitos, instruções passo a passo e práticas recomendadas, consulte Configurar 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 que não queira mais usá-lo. Quando a migração estiver concluída, 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á exibido 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 onde você pode 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 de host padrão incluirá seu sufixo de domínio personalizado e estará na forma APP-NAME.internal.contoso.com. No Ambiente do Serviço de Aplicativo v3, o nome de host padrão sempre usa o sufixo de domínio padrão e está no formato 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 Aplicações v3

Depois de concluir os passos anteriores, deverá continuar a migração o mais rapidamente possível.

Não há tempo de inatividade do aplicativo durante a migração, mas, como na etapa de geração de IP, você não pode dimensionar, modificar seu Ambiente do Serviço de Aplicativo existente ou 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 você tiver o dimensionamento automático habilitado, se ocorrer um evento de dimensionamento antes do início da migração, será necessário aguardar até que o evento de dimensionamento seja concluído antes de iniciar a migração. Você deve desativar o dimensionamento automático antes de iniciar a migração para evitar esse problema. Se você precisar dimensionar seu ambiente após a migração, poderá fazê-lo assim que a migração for concluída.

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

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

• 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 são criados no novo Ambiente do Serviço de Aplicativo v3.
• A computação/trabalhadores subjacentes para seus aplicativos é movida para o novo Ambiente do Serviço de Aplicativo v3, o que significa que seus aplicativos agora estão sendo executados no Ambiente do Serviço de Aplicativo v3. No entanto, os front-ends do Ambiente do Serviço de Aplicativo v2 ainda estão, por padrão, em execução e servindo tráfego. Seu antigo endereço IP de entrada 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 estão 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 são usados até que você atualize suas zonas DNS privadas com o novo endereço IP de entrada.
  • Para Ambientes do Serviço de Aplicativo 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 esta etapa for concluída, o tráfego do aplicativo ainda estará indo para os front-ends antigos do Ambiente do Serviço de Aplicativo v2 e para o IP de entrada atribuído a ele. No entanto, seus aplicativos estão realmente sendo executados em trabalhadores em seu novo Ambiente do Serviço de Aplicativo v3.

Nota

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

Obtenha o endereço IP de entrada para seu novo Ambiente do Serviço de Aplicativo v3 e atualize os 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 atualizar qualquer uma de suas zonas DNS privadas. Não passe para a próxima etapa até fazer essas alterações. Há tempo de inatividade se você não atualizar recursos dependentes com o novo IP de entrada. É sua responsabilidade atualizar todos e quaisquer 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 até ter feito todas as atualizações necessárias.

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

A etapa final é redirecionar o tráfego para os novos front-ends do Ambiente do Serviço de Aplicativo v3 e concluir a migração. Antes de executar esta etapa, você deve revisar seu novo Ambiente do Serviço de Aplicativo v3 e executar todos os testes necessários para validar se 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 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.

Quando estiver pronto para redirecionar o tráfego, você poderá concluir a etapa final da migração. Esta etapa atualiza os registros DNS internos/da plataforma para apontar para o endereço IP do balanceador de carga do seu novo Ambiente do Serviço de Aplicativo v3 e para os front-ends criados durante a migração. As alterações entram em vigor em poucos minutos. É da sua responsabilidade atualizar os seus registos 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 seu antigo Ambiente do Serviço de Aplicativo e o exclui. Seu novo Ambiente do Serviço de Aplicativo v3 agora é seu ambiente de produção.

Importante

A plataforma garante uma experiência de migração sem tempo de inatividade. 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 às configurações de TTL e cache, pois o tráfego ainda pode ser direcionado para seu antigo Ambiente do Serviço de Aplicativo após a alteração de DNS. Deve rever as suas definições de DNS e certificar-se de que tem um TTL baixo e que o seu fornecedor de DNS suporta propagação rápida. Se você tiver um TTL alto, poderá enfrentar tempo de inatividade durante a etapa de alteração de DNS.

Nota

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

Tem 14 dias para concluir este passo. Após 14 dias, a plataforma concluirá automaticamente a migração e excluirá seu ambiente antigo. Se precisar de mais tempo, pode abrir um caso de suporte para discutir as suas opções.

Se você descobrir algum problema com seu novo Ambiente do Serviço de Aplicativo v3, não execute o comando para redirecionar o tráfego do cliente. Este comando também inicia a exclusão do seu Ambiente do Serviço de Aplicativo v2. Se encontrar um problema, contacte o suporte.

Usar o recurso de migração lado a lado

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 em sua totalidade 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. Se o dimensionamento automático estiver habilitado, se ocorrer um evento de dimensionamento antes do início da migração, a migração será bloqueada até que o evento de dimensionamento seja concluído. Você deve desativar o dimensionamento automático antes de iniciar a migração para evitar esse problema.

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

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"

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 o início da migração. É da sua responsabilidade fazer as atualizações necessárias. Os novos IPs de saída são usados assim 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 Cofre de Chaves do Azure e estiver gerenciando restrições de acesso com um firewall, precisará atualizar o firewall do Cofre de Chaves do Azure para permitir apenas os novos IPs de saída ou toda a nova sub-rede.

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.

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

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.

Para definir essas configurações, incluindo a identificação da sub-rede selecionada anteriormente, crie um 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 do imóvel e configure-o zoneRedundant de acordo com o 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 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 se você tiver seguido as etapas anteriores. O dimensionamento, as implantações e as modificações no Ambiente do Serviço de Aplicativo existente são bloqueados durante esta etapa.

Nota

Devido a um bug conhecido, os trabalhos da Web podem não ser iniciados durante a etapa de implantação híbrida. Se você usa trabalhos da Web, esse bug pode causar problemas/tempo de inatividade do aplicativo. Abra um caso de suporte se tiver 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 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 conjuntos de front-ends do Ambiente do Serviço de Aplicativo neste estágio do processo de migração e ambos os conjuntos são capazes de atender ao tráfego do aplicativo. Seu 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 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

Importante

Se a migração incluir um sufixo de domínio personalizado, o comportamento de nome de host padrão para o Ambiente do Serviço de Aplicativo v3 será diferente do comportamento do Ambiente do Serviço de Aplicativo v2. Para o Ambiente do Serviço de Aplicativo v3, o nome de host padrão sempre usa o sufixo de domínio padrão e está no formato APP-NAME.ASE-NAME.appserviceenvironment.net. Analise todos os seus recursos dependentes, como o App Gateway, que usam os nomes de host de 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 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.

Importante

Tem 14 dias para concluir este passo. Após 14 dias, a plataforma concluirá automaticamente a migração e excluirá seu ambiente antigo. Se precisar de mais tempo, pode abrir um caso de suporte para discutir as suas opções.

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

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 discutir suas opções. Não execute o comando DNS change, 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 , a etapa de redirecionamento de MigrationCompletedtráfego é concluída e a migração é concluída.

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

A seguir estão exemplos de fontes comuns de problemas que os clientes encontram ao migrar usando o recurso de migração lado a lado. Você deve revisar essas áreas para garantir que não enfrente tempo de inatividade ou interrupções de serviço durante ou após o processo de migração.

• O Azure Key Vault deve permitir o tráfego dos novos IPs/sub-rede de saída.
• As duas sub-redes devem ser capazes de 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-se de permitir o tráfego da nova para a sub-rede antiga.
• O App Gateway deve ser atualizado com os novos endereços IP.
• Os registros DNS devem ser atualizados com os novos endereços IP.
• Se você codificou endereços IP em seus aplicativos, você precisa atualizá-los com os novos endereços IP.
• As tabelas de rotas devem ser atualizadas com quaisquer novas rotas.

Preços

Não há qualquer custo associado à migração do seu Ambiente do Serviço de Aplicações. No entanto, você será cobrado pelo Ambiente do Serviço de Aplicativo v2 e pelo novo Ambiente do Serviço de Aplicativo v3 assim que iniciar o processo de migração. Você deixa de ser cobrado pelo seu antigo Ambiente do Serviço de Aplicativo v2 quando conclui a etapa final de migração em que o ambiente antigo é excluído. Deve concluir a sua validação o mais rapidamente possível para evitar a acumulação de encargos em excesso. Para obter mais informações sobre os preços do Ambiente do Serviço de Aplicações v3, consulte os detalhes dos preços.

Quando você migra para o Ambiente do Serviço de Aplicativo v3 de versões anteriores, há cenários que você deve considerar que podem reduzir seu custo mensal. Considere reservas e planos de poupança para reduzir ainda mais os 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.

Nota

Devido às diferenças entre os níveis de preços Isolado para Isolado v2, seus aplicativos podem ser provisionados em excesso 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 dimensionar seu ambiente conforme necessário assim que a migração for concluída. Para obter mais informações, consulte os detalhes do SKU.

Reduza seus planos do Serviço de Aplicativo

As SKUs do plano do Serviço de Aplicativo disponíveis para o Ambiente do Serviço de Aplicativo v3 são executadas 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. Quando você migra, seus planos do Serviço de Aplicativo são convertidos para a camada correspondente. Por exemplo, suas instâncias I2 são convertidas em I2v2. Enquanto o I2 tem dois núcleos e 7 GB de RAM, o I2v2 tem quatro núcleos e 16 GB de RAM. Se você espera que seus requisitos de capacidade permaneçam os mesmos, você está provisionado em excesso e pagando pela computação e memória que não está usando. Para esse cenário, você pode reduzir sua instância I2v2 para I1v2 e acabar com um número semelhante de núcleos e RAM que você tinha anteriormente.

Perguntas mais frequentes

• E se a migração do meu Ambiente do Serviço de Aplicativo não for suportada 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 quiser migrar imediatamente, consulte as opções de migração manual.
• Como faço para escolher qual opção de migração é certa para mim?
  Analise a árvore de decisão do caminho de migração para decidir qual opção é melhor para seu caso de uso.
• Como sei 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 suportam o tempo de inatividade do aplicativo. Como uma nova sub-rede é usada para seu novo ambiente, há considerações de rede a serem observadas, incluindo novos IPs. Se você puder suportar o tempo de inatividade, consulte 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 do ambiente existente e usa a mesma infraestrutura de rede.
• Irei deparar-me com 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 às configurações de TTL e cache, pois o tráfego ainda pode ser direcionado para seu antigo Ambiente do Serviço de Aplicativo após a alteração de DNS. Deve rever as suas definições de DNS e certificar-se de que tem um TTL baixo e que o seu fornecedor de DNS suporta propagação rápida.
• Precisarei fazer alguma coisa com meus aplicativos após a migração para executá-los no novo Ambiente do Serviço de Aplicativo?
  Não, todas as suas aplicações em execução no ambiente antigo são migradas automaticamente para o novo ambiente e executadas como antes. Não é necessária nenhuma entrada de utilizador.
• E se o meu Ambiente do Serviço de Aplicações 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 fixo na 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 uma zona fixada no Ambiente do Serviço de Aplicativo e quiser migrar imediatamente, consulte as opções de migração manual.
• E se meu Ambiente do Serviço de Aplicativo tiver endereços IP SSL?
  O IP SSL não é suportado no Ambiente do Serviço de Aplicativo v3. Você deve remover todas as ligações 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 ligações IP SSL, você passa nessa verificação de validação e pode prosseguir com a migração automatizada.
• Quais propriedades do meu Ambiente do Serviço de Aplicativo serão alteradas?
  Você está no Ambiente do Serviço de Aplicativo v3, portanto, certifique-se de revisar os recursos e as diferenças de recursos em comparação com as versões anteriores. Os IPs de entrada e de saída mudam ao usar o recurso de migração lado a lado. Nota: para o Ambiente do Serviço de Aplicações do ELB, anteriormente existia um único IP para entrada e saída. Para o Ambiente do Serviço de Aplicações v3, estes estão separados. Para obter mais informações, consulte Rede do Ambiente do Serviço de Aplicações V3. Para obter uma comparação completa das versões do Ambiente do Serviço de Aplicações, consulte Comparação das versões do Ambiente do Serviço de Aplicações.
• O que acontece se a migração falhar ou se houver um problema inesperado durante a migração?
  Se houver um problema inesperado, as equipes de suporte estão à disposição. Recomendamos que você migre ambientes de desenvolvimento antes de tocar em qualquer ambiente de produção para aprender sobre o processo de migração e ver como ele afeta suas cargas de trabalho.
• O que acontece ao meu antigo Ambiente do Serviço de Aplicação?
  Se você decidir migrar um Ambiente do Serviço de Aplicativo usando o recurso de migração lado a lado, seu 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 são desligados e excluídos. Seu ambiente antigo não está mais acessível. Uma reversão para o ambiente antigo neste momento não é possível.
• O que irá acontecer aos meus recursos do Ambiente do Serviço de Aplicações v1/v2 após 31 de agosto de 2024?
  Após 31 de agosto de 2024, se você não migrar para o Ambiente do Serviço de Aplicativo v3, seu Ambiente do Serviço de Aplicativo v1/v2s e os aplicativos implantados neles não estarão mais disponíveis. O Ambiente do Serviço de Aplicações v1/v2 está alojado em unidades de escala do Serviço de Aplicações em execução na arquitetura de Serviços Cloud (clássica) que serão descontinuadas em 31 de agosto de 2024. Por este motivo, o Ambiente do Serviço de Aplicações v1/v2 deixará de estar disponível após esta data. Migre para o Ambiente do Serviço de Aplicações v3 para manter as suas aplicações em execução ou guarde ou faça uma cópia de segurança de quaisquer recursos ou dados que precise de manter.

Próximos passos

Rede do Ambiente do Serviço de Aplicativo v3

Usando um Ambiente do Serviço de Aplicativo v3

Sufixo de domínio personalizado