Compartilhar via

Replicar recursos usando o replicador de assinatura do Azure Stack Hub

  • Artigo

Você pode usar o script do PowerShell replicador de assinatura do Azure Stack Hub para copiar os recursos entre assinaturas do Azure Stack Hub, entre selos do Azure Stack Hub ou entre o Azure Stack Hub e o Azure. O script do replicador lê e recompila os recursos do Azure Resource Manager de diferentes assinaturas do Azure e do Azure Stack Hub. Este artigo analisa como o script funciona, como você pode usar o script e fornece uma referência para operações de script.

Você pode encontrar os scripts usados neste artigo no repositório GitHub de Padrões de Borda Inteligente do Azure . Os scripts estão na pasta replicador de assinatura .

Visão geral do replicador de assinatura

O replicador de assinatura do Azure foi projetado para ser modular. Essa ferramenta usa um processador principal que orquestra a replicação de recursos. Além disso, a ferramenta dá suporte a processadores personalizáveis que atuam como modelos para copiar diferentes tipos de recursos.

O processador principal é composto pelos três scripts a seguir:

  • resource_retriever.ps1

    • Gera pastas para armazenar arquivos de saída.

    • Define o contexto para a assinatura de origem.

    • Recupera os recursos e os passa para resource_processor.ps1.

  • resource_processor.ps1

    • Processa o recurso passado por resource_retriever.ps1.

    • Determina qual processador personalizado usar e passa os recursos.

  • post_process.ps1

    • Post processa a saída gerada pelo processador personalizado para prepará-la para ser implantada na assinatura de destino.

    • Gera o código de implantação para implantar os recursos na assinatura de destino.

Os três scripts controlam o fluxo de informações de maneira padrão para permitir maior flexibilidade. Adicionar suporte para recursos adicionais, por exemplo, não exige que você altere nenhum código no processador principal.

Processadores personalizados, que foram mencionados acima, são ps1 arquivos que determinam como um determinado tipo de recurso deve ser processado. O nome de um processador personalizado é sempre nomeado usando os dados de tipo em um recurso. Por exemplo, supondo que $vm contenha um objeto de máquina virtual, executando $vm. O tipo produziria Microsoft.Compute/virtualMachines. Isso significa que um processador para uma máquina virtual seria chamado virtualMachines_processor.ps1, o nome deve ser exatamente como aparece nos metadados do recurso, pois é assim que o processador principal determina qual processador personalizado usar.

Um processador personalizado determina como um recurso deve ser replicado determinando quais informações são importantes e ditando como essas informações devem ser extraídas dos metadados do recurso. Em seguida, o processador personalizado usa todos os dados extraídos e os usa para gerar um arquivo de parâmetros que será usado em conjunto com um modelo de Resource Manager do Azure para implantar o recurso na assinatura de destino. Esse arquivo de parâmetros é armazenado no Parameter_Files depois de ser pós-processado por post_process.ps1.

Há uma pasta na estrutura de arquivos do Replicador chamada Standardized_ARM_Templates. Dependendo do ambiente de origem, as implantações usarão um desses modelos padronizados do Azure Resource Manager ou um modelo de Resource Manager do Azure personalizado precisará ser gerado. Nesse caso, um processador personalizado deve chamar um gerador de modelo de Resource Manager do Azure. No exemplo iniciado anteriormente, o nome de um gerador de modelo de Resource Manager do Azure para máquinas virtuais seria nomeado virtualMachines_ARM_Template_Generator.ps1. O gerador de modelo de Resource Manager do Azure é responsável por criar um modelo personalizado do Azure Resource Manager com base em quais informações estão nos metadados de um recurso. Por exemplo, se o recurso de máquina virtual tiver metadados especificando que ele é membro de um conjunto de disponibilidade, o gerador de modelo do Azure Resource Manager criará um modelo de Resource Manager do Azure com código especificando a ID do conjunto de disponibilidade do qual a máquina virtual faz parte. Dessa forma, quando a máquina virtual é implantada na nova assinatura, ela é adicionada automaticamente ao conjunto de disponibilidade após a implantação. Esses modelos personalizados do Azure Resource Manager são armazenados na pasta Custom_ARM_Templates localizada dentro da pasta Standardized_ARM_Templates. O post_processor.ps1 é responsável por determinar se uma implantação deve usar um modelo de Resource Manager do Azure padronizado ou personalizado e gerar o código de implantação correspondente.

O script post-process.ps1 é responsável por limpar os arquivos de parâmetros e criar os scripts que o usuário usará para implantar os novos recursos. Durante a fase de limpeza, o script substitui todas as referências à ID da assinatura de origem, à ID do locatário e ao local pelos valores de destino correspondentes. Em seguida, ele gera o arquivo de parâmetros para a pasta Parameter_Files . Em seguida, ele determina se o recurso que está sendo processado usa um modelo de Resource Manager do Azure personalizado ou não e gera o código de implantação correspondente, que utiliza o cmdlet New-AzResourceGroupDeployment. Em seguida, o código de implantação é adicionado ao arquivo chamado DeployResources.ps1 armazenado na pasta Deployment_Files . Por fim, o script determina o grupo de recursos ao qual o recurso pertence e verifica o script DeployResourceGroups.ps1 para ver se o código de implantação para implantar esse grupo de recursos já existe. Se isso não acontecer, ele adicionará código a esse script para implantar o grupo de recursos, se ele fizer isso, não fará nada.

Recuperação de API dinâmica

A ferramenta tem recuperação de API dinâmica interna para que a versão mais recente da API do provedor de recursos disponível na assinatura de origem seja usada para implantar os recursos na assinatura de destino:

Recuperação de API de Figura

Recuperação de API de figura em resource_processor.ps1.

No entanto, há a possibilidade de que a versão da API do provedor de recursos da assinatura de destino seja mais antiga que a da assinatura de origem e não dê suporte à versão que está sendo fornecida da assinatura de origem. Nesse caso, um erro será gerado quando a implantação for executada. Para resolve isso, atualize os provedores de recursos na assinatura de destino para corresponder aos da assinatura de origem.

Implantações paralelas

A ferramenta requer um parâmetro chamado parallel. Esse parâmetro usa um valor booliano que especifica se os recursos recuperados devem ou não ser implantados em paralelo ou não. Se o valor for definido como true, cada chamada para New-AzResourceGroupDeployment terá o sinalizador -asJob e blocos de código para aguardar a conclusão de trabalhos paralelos serão adicionados entre conjuntos de implantações de recursos com base nos tipos de recurso. Ele garante que todos os recursos de um tipo tenham sido implantados antes da implantação do próximo tipo de recurso. Se o valor do parâmetro paralelo for definido como false, todos os recursos serão implantados em série.

Adicionar tipos de recursos adicionais

Adicionar novos tipos de recursos é simples. O desenvolvedor deve criar um processador personalizado e um modelo de Resource Manager do Azure ou um gerador de modelo de Resource Manager do Azure. Depois que isso for concluído, o desenvolvedor deverá adicionar o tipo de recurso ao ValidateSet para o parâmetro $resourceType e a matriz $resourceTypes em resource_retriever.ps1. Ao adicionar o tipo de recurso à matriz $resourceTypes , ele deve ser adicionado na ordem correta. A ordem da matriz determina a ordem em que os recursos serão implantados, portanto, tenha as dependências em mente. Por fim, se o processador personalizado utilizar um gerador de modelo de Resource Manager do Azure, ele deverá adicionar o nome do tipo de recurso à matriz $customTypes em post_process.ps1.

Executar o replicador de assinatura do Azure

Para executar a ferramenta replicador de assinatura do Azure (v3), você precisará iniciar resource_retriever.ps1, fornecendo todos os parâmetros. O parâmetro resourceType , há uma opção para escolher Todos em vez de um tipo de recurso. Se Tudo estiver selecionado, resource_retriever.ps1 processará todos os recursos em uma ordem para que, quando a implantação for executada, os recursos dependentes sejam implantados primeiro. Por exemplo, as VNets são implantadas antes das máquinas virtuais, pois as máquinas virtuais exigem que uma VNet esteja em vigor para que elas sejam implantadas corretamente.

Quando o script terminar de ser executado, haverá três novas pastas, Deployment_Files, Parameter_Files e Custom_ARM_Templates.

Observação

Antes de executar qualquer um dos scripts gerados, você deve definir o ambiente certo e fazer logon para a assinatura de destino (no novo Azure Stack Hub, por exemplo) e definir o diretório de trabalho como a pasta Deployment_Files .

Deployment_Files conterá dois arquivos DeployResourceGroups.ps1 e DeployResources.ps1. Executar DeployResourceGroups.ps1 implantará os grupos de recursos. A execução de DeployResources.ps1 implantará todos os recursos que foram processados. Caso a ferramenta tenha sido executada com All ou Microsoft.Compute/virtualMachines como o tipo de recurso, DeployResources.ps1 solicitará que o usuário insira uma senha de administrador de máquina virtual que será usada para criar todas as máquinas virtuais.

Exemplo

  1. Execute o script.

    Executar o script

    Observação

    Não se esqueça de configurar o ambiente de origem e o contexto de assinatura para a instância do PS.

  2. Examine as pastas recém-criadas:

    Examinar as pastas

  3. Defina o contexto como a assinatura de destino, altere a pasta para Deployment_Files, implante os grupos de recursos (execute o script DeployResourceGroups.ps1) e inicie a implantação do recurso (execute o script DeployResources.ps1).

    Configurar e iniciar a implantação

  4. Execute Get-Job para marcar o status. Get-Job | Receive-Job retornará os resultados.

Limpar

Dentro da pasta replicatorV3, há um arquivo chamado cleanup_generated_items.ps1 – ele removerá as pastas Deployment_Files, Parameter_Files e Custom_ARM_Templates e todo o conteúdo.

Operações do replicador de assinatura

Atualmente, o replicador de assinatura do Azure (v3) pode replicar os seguintes tipos de recursos:

  • Microsoft.Compute/availabilitySets

  • Microsoft.Compute/virtualMachines

  • Microsoft.Network/loadBalancers

  • Microsoft.Network/networkSecurityGroups

  • Microsoft.Network/publicIPAddresses

  • Microsoft.Network/routeTables

  • Microsoft.Network/virtualNetworks

  • Microsoft.Network/virtualNetworkGateways

  • Microsoft.Storage/storageAccounts

Ao executar a ferramenta com All como o tipo de recurso, a seguinte ordem será seguida ao replicar e implantar (no abaixo, todos os recursos têm sua configuração replicada, ou seja, sku, oferta etc.):

  • Microsoft.Network/virtualNetworks

    • Replica: - Todos os espaços de endereço - Todas as sub-redes

  • Microsoft.Network/virtualNetworkGateways

    • Replica: – Configuração de IP público – Configuração de sub-rede – Tipo de VPN – Tipo de gateway

  • Microsoft.Network/routeTables

  • Microsoft.Network/networkSecurityGroups

    • Replica: – Todas as regras de segurança de entrada e saída

  • Microsoft.Network/publicIPAddresses

  • Microsoft.Network/loadBalancers

    • Replica: – Endereços IP privados – Configuração de endereço IP público – Configuração de sub-rede

  • Microsoft.Compute/availabilitySets

    • Replica: – Número de domínios de falha – Número de domínios de atualização

  • Microsoft.Storage/storageAccounts

  • Microsoft.Compute/virtualMachines

    • Replica:
      – Discos de dados (sem dados)
      - Tamanho da máquina virtual
      -Sistema Operacional
      – Configuração da conta de armazenamento de diagnóstico
      – Configuração de IP público
      – Adaptador de rede
      – Endereço IP privado da Interface de Rede
      – Configuração do Grupo de Segurança de Rede
      – Configuração do conjunto de disponibilidade

Observação

Cria apenas discos gerenciados para discos de dados e discos do sistema operacional. Atualmente, não há suporte para o uso de contas de armazenamento

Limitações

A ferramenta pode replicar recursos de uma assinatura para outra, desde que os provedores de recursos da assinatura de destino ofereçam suporte a todos os recursos e opções que estão sendo replicados da assinatura de origem.

Para garantir a replicação bem-sucedida, verifique se as versões do provedor de recursos da assinatura de destino correspondem às da assinatura de origem.

Ao replicar do Azure comercial para o Azure comercial ou de uma assinatura no Azure Stack Hub para outra assinatura no mesmo Azure Stack Hub, haverá problemas ao replicar contas de armazenamento. Isso ocorre devido ao requisito de nomenclatura da conta de armazenamento de que todos os nomes de conta de armazenamento sejam exclusivos em todo o Azure comercial ou em todas as assinaturas em uma região/instância do Azure Stack Hub. A replicação de contas de armazenamento em diferentes instâncias do Azure Stack Hub terá êxito, pois as Pilhas são regiões/instâncias separadas.

Próximas etapas

Diferenças e considerações para a rede do Azure Stack Hub