Replicar recursos usando o replicador por subscrição do Azure Stack Hub

Pode usar o script replicador de subscrição PowerShell do Azure Stack Hub para copiar recursos entre subscrições do Azure Stack Hub, através de carimbos do Azure Stack Hub, ou entre o Azure Stack Hub e o Azure. O script replicador lê e reconstrói os recursos do Azure Resource Manager a partir de diferentes subscrições do Azure e do Azure Stack Hub. Este artigo explica como funciona o script, como pode usá-lo e fornece uma referência para operações de script.

Pode encontrar os scripts usados neste artigo no repositório Azure Intelligent Edge Patterns GitHub. Os scripts estão na pasta replicadora por subscrição .

Visão geral do replicador por subscrição

O replicador por subscrição do Azure é modular. Esta ferramenta utiliza um processador central que orquestra a replicação de recursos. Além disso, a ferramenta suporta processadores personalizáveis que funcionam como modelos para copiar diferentes tipos de recursos.

O processador central consiste nos seguintes três scripts:

• resource_retriever.ps1

  • Gera pastas para armazenar ficheiros de saída.

  • Define o contexto da subscrição de código-fonte.

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

• resource_processor.ps1

  • Processa o recurso passado por resource_retriever.ps1.

  • Determina qual o processador personalizado a usar e passa os recursos.

• post_process.ps1

  • O pós-processamento processa a saída gerada pelo processador personalizado para a preparar para ser implementada na subscrição alvo.

  • Gera código de implementação para implementar os recursos na subscrição alvo.

Os três scripts controlam o fluxo de informação de forma padrão para permitir maior flexibilidade. Adicionar suporte para recursos adicionais, por exemplo, não requer alterar qualquer código no processador principal.

Processadores personalizados, mencionados anteriormente, são ps1 ficheiros que ditam como um determinado tipo de recurso deve ser processado. O nome de um processador personalizado utiliza sempre os dados de tipo num recurso. Por exemplo, assumindo que $vm detém um objeto de máquina virtual, executando $vm. O tipo produz Microsoft.Compute/virtualMachines. Isto significa que um processador para uma máquina virtual é chamado virtualMachines_processor.ps1. O nome deve ser exatamente como aparece nos metadados do recurso, pois o processador central o utiliza para determinar qual o processador personalizado a utilizar.

Um processador personalizado dita como um recurso deve ser replicado, determinando que informação é importante e ditando como essa informação deve ser extraída dos metadados do recurso. O processador personalizado então recolhe todos os dados extraídos e usa-os para gerar um ficheiro de parâmetros que funciona com um template do Azure Resource Manager para implementar o recurso na subscrição alvo. O scriptpost_process.ps1 armazena este ficheiro de parâmetros na pasta Parameter_Files depois de ser pós-processado.

Há uma pasta na estrutura de ficheiros Replicator chamada Standardized_ARM_Templates. Dependendo do ambiente de origem, as implementações utilizam um destes modelos padronizados do Resource Manager, ou poderá ser necessário gerar um modelo personalizado do Resource Manager. Neste caso, um processador personalizado deve chamar um gerador de templates do Resource Manager. No exemplo iniciado anteriormente, o nome de um gerador de templates de Resource Manager para máquinas virtuais é virtualMachines_ARM_Template_Generator.ps1. O gerador de templates do Resource Manager é responsável por criar um modelo personalizado do Resource Manager com base na informação presente nos metadados de um recurso. Por exemplo, se o recurso da máquina virtual tiver metadados que especificam que pertence a um conjunto de disponibilidade, o gerador de templates do Resource Manager cria um template Resource Manager com código que especifica o ID do conjunto de disponibilidade do qual a máquina virtual faz parte. Assim, quando a máquina virtual é implementada na nova subscrição, é automaticamente adicionada ao conjunto de disponibilidade durante a implementação. Estes modelos de Resource Manager personalizados são armazenados na pasta Custom_ARM_Templates localizada dentro da pasta Standardized_ARM_Templates. O scriptpost_processor.ps1 é responsável por determinar se uma implementação deve usar um modelo de Resource Manager padronizado ou personalizado e gerar o código de implementação correspondente.

O scriptpost-process.ps1 é responsável por limpar os ficheiros de parâmetros e criar os scripts que o utilizador utiliza para implementar os novos recursos. Durante a fase de limpeza, o script substitui todas as referências ao ID de subscrição de origem, ID de inquilino e localização pelos valores-alvo correspondentes. Depois, ele envia o ficheiro de parâmetros para a pasta Parameter_Files . Determina então se o recurso a ser processado utiliza ou não um modelo personalizado do Resource Manager e gera o código de implementação correspondente, que utiliza o cmdlet New-AzResourceGroupDeployment. O código de implementação é então adicionado ao ficheiro 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 deDeployResourceGroups.ps1 para ver se o código de implementação para implementar esse grupo de recursos já existe. Se não fizer, o script adiciona código a esse script para implementar o grupo de recursos. Se fizer, o guião não faz nada.

Recuperação dinâmica de APIs

A ferramenta inclui recuperação dinâmica da API, pelo que utiliza a versão mais recente da API do fornecedor de recursos disponível na subscrição de origem para implementar os recursos na subscrição alvo:

No entanto, a subscrição alvo pode ter uma versão mais antiga da API do fornecedor de recursos que não suporta a versão que a subscrição de origem fornece. Neste caso, ocorre um erro quando executa a implantação. Para resolver este erro, atualize os fornecedores de recursos na subscrição alvo para corresponderem aos da subscrição de origem.

Desdobramentos paralelos

A ferramenta requer um parâmetro chamado paralelo. Este parâmetro assume um valor booleano que especifica se deve implementar os recursos recuperados em paralelo. Se definires o valor como true, cada chamada para New-AzResourceGroupDeployment inclui a flag -asJob . O processo adiciona blocos de código que aguardam que trabalhos paralelos terminem entre conjuntos de implementações de recursos consoante os tipos de recursos. Assegura que todos os recursos de um tipo são implementados antes de implantar o próximo tipo de recurso. Se definires o valor do parâmetro paralelo para false, os recursos são implementados em serial.

Adicionar tipos de recursos adicionais

Adicionar novos tipos de recursos é simples. Crie um processador personalizado e um modelo Resource Manager ou um gerador de templates Resource Manager. Depois de completares esses passos, adiciona o tipo de recurso ao ValidateSet para o parâmetro $resourceType e ao array $resourceTypes em resource_retriever.ps1. Quando adicionares o tipo de recurso ao $resourceTypes array, adiciona-o na ordem correta. A ordem do array determina a ordem em que os recursos são implementados, por isso tenha em mente as dependências. Por fim, se o processador personalizado usar um gerador de templates de Resource Manager, adicione o nome do tipo de recurso ao array de $customTypes em post_process.ps1.

Run Azure subscription replicator

Para executar a ferramenta replicador de subscrição Azure (v3), inicie resource_retriever.ps1 e forneça todos os parâmetros. Para o parâmetro resourceType , podes escolher Todos em vez de um tipo de recurso. Se selecionares Todos, resource_retriever.ps1 processa todos os recursos numa ordem para que, quando a implementação seja executada, os recursos dependentes sejam implementados primeiro. Por exemplo, os VNets são implementados antes das máquinas virtuais, pois as máquinas virtuais exigem que um VNet esteja no local para serem implementados corretamente.

Quando o script termina de ser executado, há três novas pastas: Deployment_Files, Parameter_Files e Custom_ARM_Templates.

Deployment_Files contém dois ficheiros: DeployResourceGroups.ps1 e DeployResources.ps1. Quando executasDeployResourceGroups.ps1, ele implementa os grupos de recursos. Quando executasDeployResources.ps1, ele implementa todos os recursos que foram processados. Se executares a ferramenta com All ou Microsoft. Compute/virtualMachines como tipo de recurso, DeployResources.ps1 pede para introduzir uma palavra-passe de administrador de máquina virtual que utiliza para criar todas as máquinas virtuais.

Exemplo

1. Executa o script.

   

   Note

   Não te esqueças de configurar o ambiente de origem e o contexto de subscrição para a instância PS.

2. Revise as pastas recém-criadas:

   

3. Defina o contexto para a subscrição de destino, mude a pasta para Deployment_Files, implemente os grupos de recursos (execute o DeployResourceGroups.ps1 script) e depois inicie a implementação de recursos (execute o DeployResources.ps1 script).

   

4. Corre Get-Job para verificar o estado. Get-Job | Receive-Job devolverei os resultados.

Limpeza

Dentro da replicatorV3 pasta, o ficheirocleanup_generated_items.ps1 remove as pastas Deployment_Files, Parameter_Files e Custom_ARM_Templates e todo o seu conteúdo.

Operações de replicadores por subscrição

O replicador de subscrição do Azure (v3) pode atualmente replicar os seguintes tipos de recursos:

• Microsoft.Compute/availabilitySets

• Microsoft. Computação/Máquinas Virtuais

• Microsoft.Network/loadBalancers

• Microsoft.Network/gruposDeSegurançaDeRede

• Microsoft.Network/publicIPAddresses

• Microsoft.Network/routeTables

• Microsoft.Network/virtualNetworks

• Microsoft.Network/virtualNetworkGateways

• Microsoft.Storage/storageContas

Quando executa a ferramenta com All como tipo de recurso, ela segue a ordem da lista seguinte ao replicar e implementar. Na lista seguinte, todos os recursos têm a sua configuração replicada, como sku, offer e outras definições:

• Microsoft.Network/virtualNetworks

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

• Microsoft.Network/virtualNetworkGateways

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

• Microsoft.Network/routeTables

• Microsoft.Network/gruposDeSegurançaDeRede

  • 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ços IP públicos - Configuração de sub-redes

• Microsoft.Compute/availabilitySets

  • Replicações: - Número de domínios de falha - Número de domínios de atualização

• Microsoft.Storage/storageContas

• Microsoft. Computação/Máquinas Virtuais

  • Replicas:
    - Discos de dados (sem dados)
    - Tamanho da máquina virtual
    - Sistema operativo
    - Configuração da conta de armazenamento de diagnóstico
    - Configuração do IP público
    - Interface de Rede
    - Endereço IP privado da Interface de Rede
    - Configuração do Network Security Group
    - Configuração do conjunto de disponibilidade

Limitações

A ferramenta pode replicar recursos de uma subscrição para outra, desde que a subscrição alvo suporte todos os tipos de recursos e opções que está a replicar da subscrição de origem. Para garantir uma replicação bem-sucedida, certifique-se de que as versões do fornecedor de recursos da subscrição alvo correspondem às da subscrição de origem.

Para garantir uma replicação bem-sucedida, certifique-se de que as versões do fornecedor de recursos da subscrição alvo correspondem às da subscrição de origem.

Quando replica recursos do Azure comercial para o Azure comercial, ou de uma subscrição dentro do Azure Stack Hub para outra subscrição dentro do mesmo Azure Stack Hub, encontra problemas ao replicar contas de armazenamento. Este problema ocorre porque os nomes das contas de armazenamento têm de ser únicos em todo o Azure comercial ou em todas as subscrições numa região ou instância do Azure Stack Hub. Pode replicar com sucesso contas de armazenamento em diferentes instâncias do Azure Stack Hub porque as pilhas são regiões ou instâncias separadas.

Passos seguintes

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