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

  • Artigo

Nota

O recurso de migração descrito neste artigo é usado para migração automatizada lado a lado (sub-rede diferente) do Ambiente do Serviço de Aplicativo v2 para o Ambiente do Serviço de Aplicativo v3.

Se você estiver procurando informações sobre o recurso de migração in-loco, consulte Migrar para o Ambiente do Serviço de Aplicativo v3 usando o recurso de migração in-loco. Se você estiver procurando informações sobre opções de migração manual, consulte Opções de migração manual. Para obter ajuda para decidir qual opção de migração é ideal para você, consulte Árvore de decisão de caminho de migração. Para obter mais informações sobre o Ambiente do Serviço de Aplicativo v3, consulte Visão geral do Ambiente do Serviço de Aplicativo v3.

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. Devido a esse processo, há uma opção de reversão se você precisar cancelar a 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

Recomenda-se usar esse recurso para ambientes de desenvolvimento primeiro antes de migrar qualquer ambiente de produção para 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

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 não criou IPs redundantes de zona durante a etapa de geração de IP. Abra um caso de suporte para ativar o suporte se precisar habilitar a redundância de zona. 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. Em alguns casos, ao visitar a página de migração é iniciada uma atualização se o Ambiente do Serviço de Aplicações não estiver na compilação atual. 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 InteralLoadBalancingMode 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. O InternalLoadBalancingMode deve ser alterado manualmente pela equipe da Microsoft. Abra um caso de suporte para contratar o suporte para resolver seu problema. Solicite uma atualização para o InternalLoadBalancingMode para permitir a migração.
A migração é inválida. Seu ASE precisa ser atualizado para a compilação mais recente para garantir uma migração bem-sucedida. Vamos atualizar o seu ASE agora. Tente migrar novamente em algumas horas, assim que a atualização da plataforma terminar. Seu Ambiente do Serviço de Aplicativo não está na compilação mínima necessária para a migração. Uma atualização é iniciada. Seu 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 poderá migrar até que a atualização esteja concluída. Aguarde até que a atualização termine e, em seguida, migre.
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. 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 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.

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.

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 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 for concluída, mesmo que o tráfego ainda vá para os front-ends do Ambiente do Serviço de Aplicativo v2, a computação subjacente será o novo Ambiente do Serviço de Aplicativo v3.

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.

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 subjacente para seus aplicativos é movida para o novo Ambiente do Serviço de Aplicativo v3. Os front-ends do Ambiente do Serviço de Aplicativo v2 ainda estão atendendo ao tráfego. Seu endereço IP de entrada antigo permanece em uso.
    • 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, agora você também tem um Ambiente do Serviço de Aplicativo v3 com todos os seus aplicativos.

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 o novo Ambiente do Serviço de Aplicativo v3 e concluir a migração. A plataforma faz essa mudança para você, mas apenas quando você a inicia. 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 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. Se você tiver problemas, 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.

Nota

Tem 14 dias para concluir este passo. Se você não concluir essa etapa em 14 dias, sua migração será revertida automaticamente para um Ambiente do Serviço de Aplicativo v2. Se precisar de mais de 14 dias para concluir esta etapa, entre em contato com o suporte.

Se você 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 você encontrar um problema, poderá reverter todas as alterações e retornar ao seu antigo Ambiente do Serviço de Aplicativo v2. O processo de reversão leva de 3 a 6 horas para ser concluído. Não há tempo de inatividade associado a esse processo. Quando o processo de reversão for concluído, o antigo Ambiente do Serviço de Aplicativo estará online novamente e o novo Ambiente do Serviço de Aplicativo v3 será excluído. Em seguida, você pode tentar a migração novamente depois de resolver quaisquer problemas.

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 DNS é atualizado e 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?
    Não, não há tempo de inatividade durante o processo de migração lado a lado. Seus aplicativos continuam a ser executados em seu Ambiente do Serviço de Aplicativo existente até que você conclua a etapa final da migração, na qual as alterações de DNS entram em vigor imediatamente. Depois de concluir a etapa final, seu antigo Ambiente do Serviço de Aplicativo será desligado e excluído. Seu novo Ambiente do Serviço de Aplicativo v3 agora é seu ambiente de produção.
  • 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. Com o recurso de migração lado a lado, você pode reverter todas as alterações se houver algum problema.
  • 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

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

Rede do Ambiente do Serviço de Aplicativo v3

Usando um Ambiente do Serviço de Aplicativo v3

Sufixo de domínio personalizado