Migrar para o Ambiente do Serviço de Aplicações v3

Artigo
03/06/2024

Nota

Há dois recursos de migração automatizada disponíveis para ajudá-lo a atualizar para o Ambiente do Serviço de Aplicativo v3. Para saber mais sobre esses recursos e obter ajuda para decidir qual opção de migração é a certa para você, consulte Árvore de decisão de caminho de migração. Considere uma das opções automatizadas para um caminho mais rápido para o Ambiente do Serviço de Aplicativo v3.

Se você estiver usando o Ambiente do Serviço de Aplicativo v1 ou v2, terá a oportunidade de migrar suas cargas de trabalho para o Ambiente do Serviço de Aplicativo v3. O Ambiente do Serviço de Aplicativo v3 tem vantagens e diferenças de recursos que fornecem suporte aprimorado para suas cargas de trabalho e podem reduzir os custos gerais. Considere o uso dos recursos de migração automatizada se seu ambiente atender aos critérios descritos na árvore de decisão do caminho de migração.

Se o seu Ambiente do Serviço de Aplicativo não tiver suporte para os recursos de migração, você deverá usar um dos métodos manuais para migrar para o Ambiente do Serviço de Aplicativo v3.

Pré-requisitos

Cenário: você tem um aplicativo executado no Ambiente do Serviço de Aplicativo v1 ou no Ambiente do Serviço de Aplicativo v2 e precisa que esse aplicativo seja executado no Ambiente do Serviço de Aplicativo v3.

Para qualquer método de migração que não use os recursos de migração automatizada, você precisa criar o recurso Ambiente do Serviço de Aplicativo v3 e uma nova sub-rede usando o método de sua escolha.

As alterações de rede entre o Ambiente do Serviço de Aplicativo v1/v2 e o Ambiente do Serviço de Aplicativo v3 envolvem endereços IP novos (e, para ambientes voltados para a Internet, adicionais). Você precisa atualizar qualquer infraestrutura que dependa desses IPs. Certifique-se de levar em conta as alterações de dependência de entrada, como a porta do Balanceador de Carga do Azure.

Vários ambientes do Serviço de Aplicativo não podem existir em uma única sub-rede. Se precisar usar a sub-rede existente para o novo recurso do Ambiente do Serviço de Aplicativo v3, exclua o Ambiente do Serviço de Aplicativo existente antes de criar um novo. Para esse cenário, recomendamos que você faça backup de seus aplicativos e, em seguida, restaure-os no novo ambiente depois de criar e configurar o ambiente. Esse processo causa tempo de inatividade do aplicativo devido ao tempo necessário para:

Exclua o ambiente antigo.
Crie o recurso Ambiente do Serviço de Aplicativo v3.
Configure qualquer infraestrutura e recursos conectados para trabalhar com o novo ambiente.
Implante seus aplicativos no novo ambiente.

Lista de verificação antes de migrar aplicativos

Crie um recurso do Ambiente do Serviço de Aplicativo v3 .
Atualize todas as dependências de rede com os endereços IP associados ao novo ambiente.
Planeje o tempo de inatividade (se aplicável).
Decida sobre um processo para recriar seus aplicativos em seu novo ambiente.

Dimensionar e dimensionar o ambiente

O Ambiente do Serviço de Aplicativo v3 usa planos do Serviço de Aplicativo do Azure Isolados v2 com preços e tamanhos diferentes dos planos Isolados. Analise os detalhes de preços para entender como o novo ambiente precisa ser dimensionado e dimensionado para garantir a capacidade adequada. Não há diferença na forma como você cria planos do Serviço de Aplicativo para o Ambiente do Serviço de Aplicativo v3 em comparação com as versões anteriores.

Avalie o backup e a restauração

Você pode usar o recurso de backup e restauração para manter a configuração do aplicativo, o conteúdo do arquivo e o banco de dados conectados ao aplicativo quando estiver migrando para o novo ambiente.

Você deve configurar backups personalizados para seus aplicativos para restaurá-los no Ambiente do Serviço de Aplicativo v3. O backup automático não oferece suporte à restauração em diferentes versões do Ambiente do Serviço de Aplicativo. Para obter mais informações sobre backups personalizados, consulte Backups automáticos versus personalizados. Captura de tela que mostra opções para configurar backups personalizados para um aplicativo do Serviço de Aplicativo.

Você pode selecionar um backup personalizado e restaurá-lo para o Serviço de Aplicativo no recurso do Ambiente do Serviço de Aplicativo v3. Você deve criar o plano do Serviço de Aplicativo para o qual será restaurado antes de restaurar o aplicativo. Você pode optar por restaurar o backup para o slot de produção, um slot existente ou um novo slot criado durante o processo de restauração.

Captura de tela que mostra como usar um backup para restaurar um aplicativo do Serviço de Aplicativo no Ambiente do Serviço de Aplicativo v3.

Benefícios	Limitações
Rápido - deve levar apenas 5 a 10 minutos por aplicativo.	O suporte é limitado a determinados tipos de banco de dados.
Você pode restaurar vários aplicativos ao mesmo tempo. (Você precisa configurar a restauração para cada aplicativo individualmente.)	O ambiente antigo, o novo ambiente e os recursos de suporte (por exemplo, aplicativos, bancos de dados, contas de armazenamento e contêineres) devem estar todos na mesma assinatura.
Os bancos de dados MySQL no aplicativo são automaticamente copiados sem qualquer configuração.	Os backups podem ter até 10 GB de conteúdo de aplicativo e banco de dados. Até 4 GB desse conteúdo pode ser o backup do banco de dados. Se o tamanho do backup exceder esse limite, você receberá um erro.
Você pode restaurar o aplicativo para um instantâneo de um estado anterior.	Não há suporte para o uso de uma conta de armazenamento habilitada para firewall como destino dos backups.
Você pode integrar com o Azure Traffic Manager e o Azure Application Gateway para distribuir o tráfego entre ambientes antigos e novos.	Não há suporte para o uso de uma conta de armazenamento com pontos de extremidade privados para backup e restauração.
Você pode criar aplicativos Web vazios para restaurar em seu novo ambiente antes de começar a restaurar, para acelerar o processo.	Apenas backups personalizados são suportados.

Clone seu aplicativo no Ambiente do Serviço de Aplicativo v3

A clonagem de seus aplicativos é outro recurso que você pode usar para colocar seus aplicativos do Windows no Ambiente do Serviço de Aplicativo v3. As limitações para clonar aplicativos são as mesmas do recurso de backup do Serviço de Aplicativo. Para obter mais informações, consulte Fazer backup de um aplicativo no Serviço de Aplicativo do Azure.

Nota

A clonagem de aplicativos é compatível apenas com planos do Serviço de Aplicativo no Windows.

Recomendamos essa solução para usuários que estão usando o Serviço de Aplicativo no Windows e não podem migrar usando o recurso de migração. Você precisa configurar seu novo recurso do Ambiente do Serviço de Aplicativo v3 antes de clonar qualquer aplicativo. A clonagem de um aplicativo pode levar até 30 minutos para ser concluída.

Para clonar um aplicativo usando o PowerShell, consulte as instruções.

Para clonar um aplicativo usando o portal do Azure:

No portal do Azure, vá para seu plano existente do Serviço de Aplicativo. Em Ferramentas de Desenvolvimento, selecione Clone App.
Preencha os campos obrigatórios usando os detalhes do seu novo recurso do Ambiente do Serviço de Aplicativo v3:
1. Em Grupo de Recursos, selecione um grupo de recursos existente ou crie um novo.
2. Em Nome, dê um nome ao seu aplicativo. Esse nome pode ser o mesmo do aplicativo antigo, mas a URL padrão do site para o novo ambiente será diferente. Você precisa atualizar qualquer DNS personalizado ou recursos conectados para apontar para a nova URL.
3. Para Região, use o nome do Ambiente do Serviço de Aplicativo v3.
4. Se você quiser clonar sua fonte de implantação, marque a caixa de seleção Clonar fonte de implantação.
5. Para o Plano do Windows, você pode usar um plano existente do Serviço de Aplicativo do seu novo ambiente, se já tiver criado um, ou pode criar um novo plano. Os planos do Serviço de Aplicativo disponíveis em seu novo recurso Ambiente do Serviço de Aplicativo v3 aparecem na lista suspensa.
6. Para Sku e tamanho, modifique a memória e a CPU conforme necessário usando uma das opções Isolado v2 se você estiver criando um novo plano do Serviço de Aplicativo. O Ambiente do Serviço de Aplicativo v3 usa planos Isolados v2, que têm mais memória e CPU por tamanho de instância correspondente em comparação com os planos Isolados. Para obter mais informações, consulte os detalhes de preços do Ambiente do Serviço de Aplicativo v3.

Captura de tela que mostra opções para clonar um aplicativo para o Ambiente do Serviço de Aplicativo v3 usando o portal.

Benefícios	Limitações
Você pode automatizar a clonagem usando o PowerShell.	Suportado apenas para planos do Serviço de Aplicativo no Windows.
Você pode clonar vários aplicativos ao mesmo tempo. (A clonagem precisa ser configurada para cada aplicativo individualmente ou por meio de um script.)	O suporte é limitado a determinados tipos de banco de dados.
Você pode integrar com o Azure Traffic Manager e o Azure Application Gateway para distribuir o tráfego entre ambientes antigos e novos.	O ambiente antigo, o novo ambiente e os recursos de suporte (por exemplo, aplicativos, bancos de dados, contas de armazenamento e contêineres) devem estar todos na mesma assinatura.

Crie manualmente seus aplicativos no Ambiente do Serviço de Aplicativo v3

Se o recurso de migração não oferecer suporte aos seus aplicativos ou se você quiser seguir uma rota mais manual, poderá implantar seus aplicativos seguindo o mesmo processo usado para o Ambiente do Serviço de Aplicativo existente.

Você pode exportar modelos do Azure Resource Manager (modelos ARM) de seus aplicativos existentes, planos do Serviço de Aplicativo e quaisquer outros recursos com suporte e implantá-los em ou com seu novo ambiente. Para exportar um modelo apenas para um aplicativo, acesse seu plano do Serviço de Aplicativo. Em Automação, selecione Exportar modelo.

Captura de ecrã da opção para exportar um modelo no painel esquerdo do portal do Azure.

Você também pode exportar modelos para vários recursos diretamente do seu grupo de recursos. Aceda ao seu grupo de recursos, selecione os recursos para os quais pretende um modelo e, em seguida, selecione Exportar modelo.

Captura de tela da opção para exportar um modelo para recursos de um grupo de recursos.

As seguintes alterações iniciais em seus modelos ARM são necessárias para colocar seus aplicativos no Ambiente do Serviço de Aplicativo v3:

Atualize sku os parâmetros de um plano do Serviço de Aplicativo para um plano v2 Isolado:

"type": "Microsoft.Web/serverfarms",
"apiVersion": "2021-02-01",
"name": "[parameters('serverfarm_name')]",
"location": "East US",
"sku": {
    "name": "I1v2",
    "tier": "IsolatedV2",
    "size": "I1v2",
    "family": "Iv2",
    "capacity": 1
},

Atualize o parâmetro do plano do Serviço de Aplicativo (serverfarm) no qual o aplicativo será implantado no plano associado ao Ambiente do Serviço de Aplicativo v3.
Atualize o parâmetro de perfil do ambiente de hospedagem (hostingEnvironmentProfile) para a nova ID de recurso do Ambiente do Serviço de Aplicativo v3.

Uma exportação de modelo ARM inclui todas as propriedades que os provedores de recursos expõem para os recursos. Remova todas as propriedades não necessárias, como propriedades que apontam para o domínio do aplicativo antigo. Por exemplo, você pode simplificar o sites recurso para o seguinte exemplo:

"type": "Microsoft.Web/sites",
"apiVersion": "2021-02-01",
"name": "[parameters('site_name')]",
"location": "East US",
"dependsOn": [
    "[resourceId('Microsoft.Web/serverfarms', parameters('serverfarm_name'))]"
],
"properties": {
    "serverFarmId": "[resourceId('Microsoft.Web/serverfarms', parameters('serverfarm_name'))]",
    "siteConfig": {
        "linuxFxVersion": "NODE|14-lts"
     },
    "hostingEnvironmentProfile": {
        "id": "[parameters('hostingEnvironments_externalid')]"
    }
}

Outras alterações podem ser necessárias, dependendo de como você configurou seu aplicativo. Por exemplo, se você usar identidades gerenciadas atribuídas ao sistema e os mesmos nomes de aplicativo para seus ambientes antigos e novos, poderá entrar em conflitos. Para resolver esse conflito e evitar tempo de inatividade, você pode usar uma identidade gerenciada atribuída pelo usuário.

Você pode implantar modelos ARM usando o portal do Azure, a CLI do Azure ou o PowerShell.

Migrar manualmente

O recurso de migração in-loco automatiza a migração para o Ambiente do Serviço de Aplicativo v3 e transfere todos os seus aplicativos para o novo ambiente. Há cerca de uma hora de inatividade durante essa migração. Se seus aplicativos não puderem ter tempo de inatividade, recomendamos que você use o recurso de migração lado a lado, que é uma opção de migração sem tempo de inatividade, já que o novo ambiente é criado em uma sub-rede diferente. Se você também optar por não usar o recurso de migração lado a lado, poderá usar uma das opções manuais para recriar seus aplicativos no Ambiente do Serviço de Aplicativo v3.

Você pode distribuir o tráfego entre seus ambientes antigos e novos usando o Application Gateway. Se você estiver usando um Ambiente de Serviço de Aplicativo do ILB (balanceador de carga interno), crie uma instância do Gateway de Aplicativo do Azure com um pool de back-end extra para distribuir o tráfego entre seus ambientes. Para obter informações sobre ambientes de serviço de aplicativo ILB e ambientes de serviço de aplicativo voltados para a Internet, consulte Integração de gateway de aplicativo.

Você também pode usar serviços como o Azure Front Door, a Rede de Entrega de Conteúdo do Azure e o Gerenciador de Tráfego do Azure para distribuir o tráfego entre ambientes. O uso desses serviços permite testar seu novo ambiente de forma controlada e ajuda você a se mover para o novo ambiente no seu próprio ritmo.

Após a conclusão da migração e de qualquer teste com o novo ambiente, exclua o Ambiente do Serviço de Aplicativo antigo, os aplicativos que estão nele e todos os recursos de suporte de que você não precisa mais. Você continua a ser cobrado por quaisquer recursos que não excluir.

Perguntas mais frequentes

Como sei se devo migrar para o Ambiente do Serviço de Aplicativo v3 usando uma das opções manuais?
Para obter ajuda para decidir qual opção de migração é ideal para você, consulte Árvore de decisão de caminho de migração. Se seu ambiente atender aos critérios descritos na árvore de decisão do caminho de migração, considere usar um dos recursos de migração automatizada para um caminho mais rápido para o Ambiente do Serviço de Aplicativo v3. A migração manual é recomendada se você precisar mover lentamente seus aplicativos para o novo ambiente e validar durante todo o processo.
Irei deparar-me com tempo de inatividade durante a migração?
O tempo de inatividade depende do seu processo de migração. Se você tiver um Ambiente do Serviço de Aplicativo diferente para o qual possa apontar o tráfego durante a migração ou se puder usar uma sub-rede diferente para criar seu novo ambiente, não terá tempo de inatividade. Se você precisar usar a mesma sub-rede, haverá tempo de inatividade enquanto você exclui o ambiente antigo, cria o recurso Ambiente do Serviço de Aplicativo v3, cria os novos planos do Serviço de Aplicativo, recria os aplicativos e atualiza todos os recursos que usam os novos endereços IP.
Preciso alterar alguma coisa em meus aplicativos para que eles sejam executados no Ambiente do Serviço de Aplicativo v3?
N.º Os aplicativos executados no Ambiente do Serviço de Aplicativo v1 e v2 não devem precisar de modificações para serem executados no Ambiente do Serviço de Aplicativo v3. Se você estiver usando IP SSL, deverá remover as associações IP SSL antes de migrar.
E se o meu Ambiente do Serviço de Aplicações tiver um sufixo de domínio personalizado?
O funcionalidade de migração suporta este cenário de migração. Você pode migrar usando um método manual se não quiser usar o recurso de migração. Você pode configurar seu sufixo de domínio personalizado ao criar seu recurso do Ambiente do Serviço de Aplicativo v3 ou a qualquer momento depois.
E se meu recurso do Ambiente do Serviço de Aplicativo v2 estiver fixo na zona?
A fixação de zona não é um recurso suportado no Ambiente do Serviço de Aplicativo v3. Você pode optar por habilitar a redundância de zona ao criar seu recurso Ambiente do Serviço de Aplicativo v3.
Quais propriedades do meu Ambiente do Serviço de Aplicativo serão alteradas?
Analise as diferenças de recursos entre o Ambiente do Serviço de Aplicativo v3 e as versões anteriores. Para ambientes ILB App Service, você mantém o mesmo endereço IP ILB. Para ambientes do Serviço de Aplicativo voltados para a Internet, o endereço IP público e o endereço IP de saída são alterados.

Para ambientes de serviço de aplicativo voltados para a Internet, anteriormente havia 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.
A cópia de segurança e o restauro são suportados para mover aplicações do Ambiente do Serviço de Aplicações v2 para o v3? O recurso de backup e restauração oferece suporte à restauração de aplicativos entre versões do Ambiente do Serviço de Aplicativo, desde que você use um backup personalizado para a restauração. O backup automático não oferece suporte à restauração para diferentes versões do Ambiente do Serviço de Aplicativo.
O que acontecerá com meus recursos do Ambiente do Serviço de Aplicativo v1 e v2 após 31 de agosto de 2024?
Após 31 de agosto de 2024, se você não tiver migrado para o Ambiente do Serviço de Aplicativo v3, seus recursos do Ambiente do Serviço de Aplicativo v1 e v2 e os aplicativos implantados neles não estarão mais disponíveis.

O Ambiente do Serviço de Aplicativo v1 e v2 são hospedados em unidades de escala do Serviço de Aplicativo que são executadas na arquitetura (clássica) dos Serviços de Nuvem do Azure. Como essa arquitetura será desativada em 31 de agosto de 2024, o Ambiente do Serviço de Aplicativo v1 e v2 não estará disponível após essa data. Migre para o Ambiente do Serviço de Aplicativo v3 para manter seus aplicativos em execução ou salve ou faça backup de quaisquer recursos ou dados que você precise manter.