Migrar para o Ambiente do Serviço de Aplicativo v3
Observação
Existem dois recursos de migração automatizados disponíveis para ajudar você a fazer upgrade 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 é ideal para você, confira a Árvore de decisão do caminho de migração. Pense em adotar uma das opções automatizadas para obter 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 usar os recursos de migração automatizados se o ambiente atender aos critérios descritos na árvore de decisão do caminho de migração.
Se o Ambiente do Serviço de Aplicativo não tiver suporte para o recurso de migração, você precisará 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 que é executado no Ambiente do Serviço de Aplicativo v1 ou 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 automatizados, você precisa criar o recurso do 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 novos endereços IP (e para ambientes voltados para a Internet, endereços adicionais). Você precisa atualizar toda infraestrutura baseada nesses IPs. Certifique-se de considerar as alterações de dependência de entrada, como a porta do Azure Load Balancer.
Vários Ambientes do Serviço de Aplicativo não podem existir em uma única sub-rede. Se você precisar usar sua sub-rede existente para o novo recurso do Ambiente do Serviço de Aplicativo v3, deverá excluir o Ambiente do Serviço de Aplicativo existente antes de criar um novo. Para esse cenário, recomendamos fazer backup de seus aplicativos e restaurá-los no novo ambiente depois de criar e configurar o ambiente. Esse processo causa tempo de inatividade no aplicativo devido ao tempo que é necessário para:
- Excluir o ambiente antigo.
- Criar o recurso do Ambiente do Serviço de Aplicativo v3.
- Configurar infraestruturas e recursos conectados para trabalhar com o novo ambiente.
- Implantar os seus aplicativos no novo ambiente.
Lista de verificação antes de migrar aplicativos
- Recurso Criar um Ambiente do Serviço de Aplicativo v3.
- Atualize as dependências de rede com os endereços IP associados ao novo ambiente.
- Planeje-se para o tempo de inatividade (se aplicável).
- Decida sobre um processo para recriar os seus aplicativos em seu novo ambiente.
Dimensionar e escalar o ambiente
O Ambiente do Serviço de Aplicativo v3 usa planos Isolados do Serviço de Aplicativo do Azure v2 que são precificados e dimensionados de forma diferente dos planos Isolados. Examine os detalhes de preços para entender como o seu novo ambiente precisa ser dimensionado e colocado em escala para garantir a capacidade apropriada. Não há nenhuma diferença na maneira de criar planos do Serviço de Aplicativo no Ambiente do Serviço de Aplicativo v3 em comparação com as versões anteriores.
Avaliar backup e restauração
Você pode usar o recurso de backup e restauração para manter a configuração, o conteúdo de arquivos e o banco de dados do aplicativo conectados ao aplicativo quando estiver migrando para o novo ambiente.
Você deve configurar backups personalizados para os seus aplicativos para restaurá-los no Ambiente do Serviço de Aplicativo v3. O backup automático não dá suporte à restauração em versões de Ambiente do Serviço de Aplicativo diferentes. Para obter mais informações sobre backups personalizados, confira Backups automáticos versus personalizados.
Você pode selecionar um backup personalizado e restaurá-lo no Serviço de Aplicativo em seu recurso do Ambiente do Serviço de Aplicativo v3. Você deve criar o plano do Serviço de Aplicativo no qual você fará a restauração 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.
Benefícios | Limitações |
---|---|
Rápido – deve levar apenas de 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. |
O backup de bancos de dados MySQL no aplicativo é feito automaticamente, sem nenhuma configuração. | Backups podem ter até 10 GB de conteúdo do aplicativo e do banco de dados. Até 4 GB desse conteúdo podem ser o backup do banco de dados. Se o tamanho do backup ultrapassar 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 para seus backups. |
Você pode integrar ao Gerenciador de Tráfego do Azure e ao Gateway de Aplicativo do Azure para distribuir o tráfego em 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. | Há suporte apenas para backups personalizados. |
Clonar seu aplicativo no Ambiente do Serviço de Aplicativo v3
A clonagem de 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 clonagem de aplicativos são as mesmas do recurso de backup do Serviço de Aplicativo. Para obter mais informações, confira Fazer backup de um aplicativo no Serviço de Aplicativo do Azure.
Observação
Há suporte para clonagem de aplicativos somente para Planos do Serviço de Aplicativo no Windows.
Recomendamos esta solução para usuários que estejam usando o Serviço de Aplicativo no Windows e não possam 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, confira as instruções.
Para clonar um aplicativo usando o portal do Azure:
No portal do Azure, vá para o Plano do Serviço de Aplicativo existente. Em Ferramentas de desenvolvimento, selecione Clonar aplicativo.
Preencha os campos necessários usando os detalhes do novo recurso do Ambiente do Serviço de Aplicativo v3:
- Em Grupo de recursos, selecione um grupo de recursos existente ou crie um novo.
- Em Nome, dê um nome ao seu aplicativo. Esse nome pode ser o mesmo que o 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.
- Em Região, use o nome do Ambiente do Serviço de Aplicativo v3.
- Se você quiser clonar a origem da implantação, marque a caixa de seleção Clonar o código-fonte da implantação.
- Em Plano do Windows, você pode usar um plano do Serviço de Aplicativo existente do seu novo ambiente se já tiver criado um ou criar um novo plano. Os Planos do Serviço de Aplicativo disponíveis em seu novo recurso do Ambiente do Serviço de Aplicativo v3 aparecem na lista suspensa.
- Em SKU e tamanho, modifique a memória e a CPU conforme necessário usando uma das opções Isoladas 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, confira os detalhes de preços do Ambiente do Serviço de Aplicativo v3.
Benefícios | Limitações |
---|---|
Você pode automatizar a clonagem usando o PowerShell. | Com suporte 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 ao Gerenciador de Tráfego do Azure e ao Gateway de Aplicativo do Azure para distribuir o tráfego em 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. |
Criar manualmente seus aplicativos no Ambiente do Serviço de Aplicativo v3
Se o recurso de migração não der suporte aos seus aplicativos ou se você quiser fazer uma rota mais manual, você 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 do ARM) de seus aplicativos existentes, planos do Serviço de Aplicativo e quaisquer outros recursos com suporte e implantá-los em seu novo ambiente ou com ele. Para exportar um modelo para um único aplicativo, acesse o seu Plano do Serviço de Aplicativo. Em Automação, selecione Exportar modelo.
Você também pode exportar modelos para vários recursos diretamente do seu grupo de recursos. Vá para o grupo de recursos, selecione os recursos para os quais deseja um modelo e selecione Exportar modelo.
As seguintes alterações iniciais nos modelos do ARM são necessárias para colocar seus aplicativos no Ambiente do Serviço de Aplicativo v3:
Atualize parâmetros
sku
de um Plano do Serviço de Aplicativo para um plano Isolado v2:"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 de 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 de ambiente de hospedagem (
hostingEnvironmentProfile
) para a nova ID do recurso do Ambiente do Serviço de Aplicativo v3.Uma exportação de modelo do 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 recurso
sites
para a seguinte amostra:"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 pelo sistema e os mesmos nomes de aplicativos para seus ambientes antigos e novos, poderá encontrar conflitos. Para resolver esse conflito e evitar o tempo de inatividade, você pode usar uma identidade gerenciada atribuída pelo usuário.
Você pode implantar modelos do ARM usando o portal do Azure, a CLI do Azure ou o PowerShell.
Migrar manualmente
O recurso de migração instalado 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 tempo de inatividade durante essa migração. Se os 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 com zero 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 Gateway de Aplicativo. Se você estiver usando um Ambiente do Serviço de Aplicativo de balanceador de carga interno (ILB), crie uma instância do Gateway de Aplicativo do Azure com um pool de back-end extra para distribuir o tráfego entre os seus ambientes. Para obter informações sobre ambientes do Serviço de Aplicativo ILB e Ambientes do Serviço de Aplicativo voltados para a Internet, confira Integração do Gateway de Aplicativo.
Você também pode usar serviços como o Azure Front Door, a Rede de Distribuição de Conteúdo do Microsoft Azure e o Gerenciador de Tráfego do Azure para distribuir o tráfego entre ambientes. O uso desses serviços permite testar o seu novo ambiente de maneira controlada e ajuda você a migrar para o seu novo ambiente em seu próprio ritmo.
Depois que a migração e todos os testes com o seu novo ambiente forem concluídos, exclua o ambiente antigo do Serviço de Aplicativo, os aplicativos que estão nele e todos os recursos de suporte que você não precisa mais. Você continuará sendo cobrado por todos os recursos que não excluir.
Perguntas frequentes
Como faço para saber 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ê, confira a Árvore de decisão do caminho de migração. Se o seu ambiente atender aos critérios descritos na árvore de decisão do caminho de migração, pense em usar um dos recursos de migração automatizados para obter um caminho mais rápido para o Ambiente do Serviço de Aplicativo v3. A migração manual é recomendada se você precisar migrar seus aplicativos para o seu novo ambiente lentamente e validar ao longo de todo o processo.Haverá tempo de inatividade durante a migração?
O tempo de inatividade depende do processo de migração. Se você tiver um Ambiente de Serviço de Aplicativo diferente para o qual pode apontar o tráfego durante a migração, ou se puder usar uma sub-rede diferente para criar o seu novo ambiente, não terá tempo de inatividade. Se você precisar usar a mesma sub-rede, haverá tempo de inatividade enquanto você estiver excluindo o ambiente antigo, criando o recurso Ambiente do Serviço de Aplicativo v3, criando os novos planos do Serviço de Aplicativo, recriando os aplicativos e atualizando todos os recursos que usam os novos endereços IP.Preciso alterar algo em meus aplicativos para que eles sejam executados no Ambiente do Serviço de Aplicativo v3?
Não. 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 o IP SSL, deverá remover as associações IP SSL antes de migrar.E se meu Ambiente do Serviço de Aplicativo tiver um sufixo de domínio personalizado?
O recurso de migração dá suporte a esse 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 o sufixo de domínio personalizado ao criar o recurso do Ambiente do Serviço de Aplicativo v3 ou a qualquer momento depois.E se o meu recurso do Ambiente do Serviço de Aplicativo v2 estiver fixado na zona?
A fixação de zona não é um recurso com suporte no Ambiente do Serviço de Aplicativo v3. Você pode optar por habilitar a redundância de zona ao criar o seu recurso do Ambiente do Serviço de Aplicativo v3.Quais propriedades de meu Ambiente do Serviço de Aplicativo serão alteradas?
Examine as diferenças de recursos entre o Ambiente do Serviço de Aplicativo v3 e as versões anteriores. Para ambientes do Serviço de Aplicativo do ILB, você mantém o mesmo endereço IP do 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 do Serviço de Aplicativo voltados à Internet, anteriormente havia um único IP para entrada e saída. Para o Ambiente do Serviço de Aplicativo v3, eles são separados. Para saber mais, confira Rede do Ambiente do Serviço de Aplicativo v3.
Há suporte de backup e restauração para mover aplicativos do Ambiente do Serviço de Aplicativo v2 para v3? O recurso de backup e restauração dá 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 dá suporte à restauração para versões de Ambiente do Serviço de Aplicativo diferentes.
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, os 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 dos Serviços de Nuvem do Azure (clássico). Como essa arquitetura será desativada em 31 de agosto de 2024, o Ambiente do Serviço de Aplicativo v1 e v2 não estarão disponíveis após essa data. Migre para o Ambiente do Serviço de Aplicativo v3 para manter os seus aplicativos em execução ou salve ou faça backup de todos os recursos ou dados que você precisar manter.