Partilhar via


Alterações pós-migração

A implantação de Serviços de Nuvem (clássica) é convertida em uma implantação de Serviços de Nuvem (suporte estendido). Para obter mais informações, consulte a documentação dos Serviços de Nuvem (suporte estendido).

Alterações nos arquivos de implantação

Pequenas alterações são feitas no arquivo .csdef e .cscfg do cliente para tornar os arquivos de implantação compatíveis com os requisitos do Azure Resource Manager e dos Serviços de Nuvem (suporte estendido). A pós-migração recupera seus novos arquivos de implantação ou atualiza os arquivos existentes, que são necessários para operações de atualização/exclusão.

  • A Rede Virtual usa a ID de recurso completa do Azure Resource Manager em vez de apenas o nome do recurso na seção NetworkConfiguration do arquivo .cscfg. Por exemplo, /subscriptions/subscription-id/resourceGroups/resource-group-name/providers/Microsoft.Network/virtualNetworks/vnet-name. Para redes virtuais pertencentes ao mesmo grupo de recursos que o serviço de nuvem, você pode optar por atualizar o arquivo .cscfg de volta para usar apenas o nome da rede virtual.

  • Tamanhos clássicos como Pequeno, Grande e ExtraGrande são substituídos por seus novos nomes de tamanho, Standard_A*. Os nomes de tamanho precisam ser alterados para seus novos nomes no arquivo .csdef. Para obter mais informações, consulte Pré-requisitos de implantação dos Serviços de Nuvem (suporte estendido)

  • Use a API Get para obter a cópia mais recente dos arquivos de implantação.

Atualizando a configuração do Gerenciador de Tráfego do Azure após a migração do serviço de nuvem

Depois de migrar seus Serviços de Nuvem (Clássico) para Serviços de Nuvem (Suporte Estendido), você pode encontrar problemas com a atualização ou exclusão de configurações de ponto de extremidade no Gerenciador de Tráfego do Azure. Isso ocorre devido a problemas de sincronização de ID de recurso, em que o ponto de extremidade do Gerenciador de Tráfego ainda aponta para a ID de recurso antiga para Serviços de Nuvem (clássica), mas a implantação de Serviços de Nuvem (suporte estendido) tem uma nova ID de Recurso. Para resolver este problema, siga estes passos:

  1. Migrar tráfego Ponto de extremidade temporário: migre o tráfego do Azure Traffic Manager para um ponto de extremidade secundário.
  2. Remover pontos de extremidade de computação clássica no Gerenciador de Tráfego do Azure: Quando o tráfego estiver sendo direcionado para um ponto de extremidade temporário, exclua o ponto de extremidade de computação clássico do perfil do Gerenciador de Tráfego.
  3. Migrar para Serviços de Nuvem (suporte estendido): Migre o recurso de Serviço de Nuvem para Serviços de Nuvem (suporte estendido).
  4. Adicionar novos pontos de extremidade no ATM: crie novos pontos de extremidade em seu perfil do Gerenciador de Tráfego para o recurso de Serviços de Nuvem migrado (Suporte estendido). Este ponto de extremidade tem a nova ID de recurso para o Serviço de Nuvem migrado.
  5. Retomar o tráfego para o ponto de extremidade dos Serviços de Nuvem Primária (suporte estendido): o ponto de extremidade secundário pode ser excluído ou ajustado para um peso menor. O tráfego será servido para o novo recurso (suporte estendido). Esse processo garante que o Gerenciador de Tráfego esteja alinhado corretamente com as IDs de recursos atualizadas e evita problemas de configuração que podem atrasar projetos.

Alterações na automação do cliente, pipeline de CI/CD, scripts personalizados, painéis personalizados, ferramentas personalizadas, etc.

Os clientes precisam atualizar suas ferramentas e automação para começar a usar as novas APIs / comandos para gerenciar sua implantação. O cliente pode facilmente adotar novos recursos e capacidades do Azure Resource Manager/Serviços de Nuvem (suporte estendido) como parte dessa alteração.

  • Alterações nos nomes de Recursos e Grupos de Recursos após a migração

    • Como parte da migração, os nomes de alguns recursos, como o serviço de nuvem, endereços IP públicos, etc. mudam. Essas alterações podem precisar ser refletidas nos arquivos de implantação antes da atualização do Serviço de Nuvem. Saiba mais sobre os nomes dos recursos que estão mudando.
  • Recriar regras e políticas necessárias para gerenciar e dimensionar serviços de nuvem

    • As regras de Dimensionamento Automático não são migradas. Após a migração, recrie as regras de dimensionamento automático.
    • Os alertas não são migrados. Após a migração, recrie os alertas.
    • O Cofre da Chave é criado sem políticas de acesso. Para exibir ou gerenciar seus certificados, crie políticas apropriadas no Cofre da Chave. Os certificados são visíveis em configurações na guia chamada segredos.

Alterações no gerenciamento de certificados pós-migração

Como prática padrão para gerenciar seus certificados, todos os arquivos de certificado .pfx válidos devem ser adicionados ao armazenamento de certificados no Cofre da Chave e a atualização funcionaria perfeitamente bem através de qualquer cliente - Portal, PowerShell ou API REST.

Atualmente, o portal do Azure faz uma validação para você verificar se todos os certificados necessários são carregados no armazenamento de certificados no Cofre da Chave e avisa se um certificado não for encontrado. No entanto, se você estiver planejando usar Certificados como segredos, esses certificados não poderão ser validados para sua impressão digital e qualquer operação de atualização que envolva adição de segredos falhará via Portal. Recomenda-se que os clientes usem o PowerShell ou a RestAPI para continuar as atualizações que envolvem Segredos.

Alterações para atualização via Visual Studio

Se você publicou atualizações diretamente por meio do Visual Studio, primeiro precisará baixar o arquivo CSCFG mais recente da sua pós-migração de implantação. Use esse arquivo como referência para adicionar detalhes de configuração de rede ao seu arquivo CSCFG atual no projeto do Visual Studio. Em seguida, crie a solução e publique-a. Poderá ter de escolher o Cofre da Chave e o Grupo de Recursos para esta atualização.

Próximos passos