Partilhar via

Replicar recursos com o replicador de subscrição do Azure Stack Hub

  • Artigo

Pode utilizar o script do PowerShell do replicador de subscrição do Azure Stack Hub para copiar os recursos entre as subscrições do Azure Stack Hub, os selos do Azure Stack Hub ou entre o Azure Stack Hub e o Azure. O script do 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 analisa como funciona o script, como pode utilizar o script e fornece uma referência para operações de script.

Pode encontrar os scripts utilizados neste artigo no repositório do GitHub padrões do Azure Intelligent Edge . Os scripts estão na pasta do replicador de subscrição .

Descrição geral do replicador de subscrição

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

O processador principal é composto por três scripts seguintes:

  • resource_retriever.ps1

    • Gera pastas para armazenar ficheiros de saída.

    • Define o contexto para a subscrição de origem.

    • Obtém os recursos e transmite-os para resource_processor.ps1.

  • resource_processor.ps1

    • Processa o recurso transmitido por resource_retriever.ps1.

    • Determina o processador personalizado a utilizar e transmite os recursos.

  • post_process.ps1

    • Após processar a saída gerada pelo processador personalizado para prepará-la para ser implementada na subscrição de destino.

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

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

Os processadores personalizados, que foram mencionados acima, são ps1 ficheiros que ditam a forma como um determinado tipo de recurso deve ser processado. O nome de um processador personalizado tem sempre o nome com o tipo de dados num recurso. Por exemplo, assumindo que contém $vm um objeto de máquina virtual, executando $vm. O tipo produziria Microsoft.Compute/virtualMachines. Isto significa que um processador para uma máquina virtual teria o nome virtualMachines_processor.ps1, o nome tem de ser exatamente como aparece nos metadados de recursos, uma vez que é assim que o processador principal determina o processador personalizado a utilizar.

Um processador personalizado dita a forma como um recurso deve ser replicado ao determinar que informações são importantes e ditar a forma como essas informações devem ser retiradas dos metadados do recurso. Em seguida, o processador personalizado utiliza todos os dados extraídos e utiliza-os para gerar um ficheiro de parâmetros que será utilizado em conjunto com um modelo de Resource Manager do Azure para implementar o recurso na subscrição de destino. Este ficheiro de parâmetros é armazenado no Parameter_Files depois de ser processado por post_process.ps1.

Existe uma pasta na estrutura de ficheiros do Replicator denominada Standardized_ARM_Templates. Consoante o ambiente de origem, as implementações utilizarão um destes modelos de Resource Manager do Azure padronizados ou um modelo de Resource Manager do Azure personalizado terá de ser gerado. Neste caso, um processador personalizado tem de chamar um gerador de modelos Resource Manager do Azure. No exemplo iniciado anteriormente, o nome de um gerador de modelos do Azure Resource Manager para máquinas virtuais teria o nome virtualMachines_ARM_Template_Generator.ps1. O gerador de modelos Resource Manager do Azure é responsável pela criação de um modelo personalizado do Azure Resource Manager com base nas informações que estão nos metadados de um recurso. Por exemplo, se o recurso da máquina virtual tiver metadados que especifiquem que é membro de um conjunto de disponibilidade, o gerador de modelos do Azure Resource Manager criará um modelo de Resource Manager do Azure com código que especifica o ID do conjunto de disponibilidade do qual a máquina virtual faz parte. Dessa forma, quando a máquina virtual é implementada na nova subscrição, é automaticamente adicionada ao conjunto de disponibilidade após a implementação. Estes modelos de Resource Manager do Azure personalizados 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 implementação deve utilizar um modelo de Resource Manager do Azure padronizado ou um modelo personalizado e gerar o código de implementação correspondente.

O script post-process.ps1 é responsável por limpar os ficheiros de parâmetros e criar os scripts que o utilizador utilizará para implementar os novos recursos. Durante a fase de limpeza, o script substitui todas as referências ao ID da subscrição de origem, ao ID do inquilino e à localização pelos valores de destino correspondentes. Em seguida, exporta o ficheiro de parâmetros para a pasta Parameter_Files . Em seguida, determina se o recurso que está a ser processado utiliza ou não um modelo de Resource Manager do Azure personalizado e gera o código de implementação correspondente, que utiliza o cmdlet New-AzResourceGroupDeployment. Em seguida, o código de implementação é adicionado ao ficheiro com o nomeDeployResources.ps1 armazenado na pasta Deployment_Files . Por último, 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 implementação para implementar esse grupo de recursos já existe. Se não for o caso, adicionará código a esse script para implementar o grupo de recursos, se não fizer nada.

Obtenção de API Dinâmica

A ferramenta tem a obtenção de API dinâmica incorporada para que a versão mais recente da API do fornecedor de recursos disponível na subscrição de origem seja utilizada para implementar os recursos na subscrição de destino:

Obtenção da API de Figura

Obtenção da API de Figura no resource_processor.ps1.

No entanto, existe a possibilidade de a versão da API do fornecedor de recursos da subscrição de destino ser mais antiga do que a da subscrição de origem e não suportar a versão fornecida a partir da subscrição de origem. Neste caso, será gerado um erro quando a implementação for executada. Para resolver este problema, atualize os fornecedores de recursos na subscrição de destino para corresponder aos da subscrição de origem.

Implementações paralelas

A ferramenta requer um parâmetro com o nome parallel. Este parâmetro utiliza um valor booleano que especifica se os recursos obtidos devem ou não ser implementados em paralelo. Se o valor estiver definido como verdadeiro, cada chamada para New-AzResourceGroupDeployment terá o sinalizador -asJob e os blocos de código a aguardar que as tarefas paralelas terminem serão adicionados entre conjuntos de implementações de recursos com base nos tipos de recursos. Garante que todos os recursos de um tipo foram todos implementados antes de implementar o próximo tipo de recurso. Se o valor do parâmetro paralelo estiver definido como falso, todos os recursos serão implementados em série.

Adicionar tipos de recursos adicionais

É simples adicionar novos tipos de recursos. O programador tem de criar um processador personalizado e um modelo do Azure Resource Manager ou um gerador de modelos do Azure Resource Manager. Depois de concluído, o programador tem de adicionar o tipo de recurso ao ValidateSet para o parâmetro $resourceType e à matriz de $resourceTypes no resource_retriever.ps1. Ao adicionar o tipo de recurso à matriz $resourceTypes , tem de ser adicionado pela ordem correta. A ordem da matriz determina a ordem pela qual os recursos serão implementados, por isso, tenha em atenção as dependências. Por fim, se o processador personalizado utilizar um gerador de modelos Resource Manager do Azure, terá de adicionar o nome do tipo de recurso à matriz de $customTypes no post_process.ps1.

Executar o replicador de subscrição do Azure

Para executar a ferramenta de replicação de subscrição do Azure (v3), terá de iniciar resource_retriever.ps1, fornecendo todos os parâmetros. O parâmetro resourceType , existe uma opção para escolher Todos em vez de um tipo de recurso. Se Tudo estiver selecionado, resource_retriever.ps1 processará todos os recursos numa ordem para que, quando a implementação for executada, os recursos dependentes sejam implementados primeiro. Por exemplo, as VNets são implementadas antes das máquinas virtuais, uma vez que as máquinas virtuais necessitam de uma VNet para que sejam implementadas corretamente.

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

Nota

Antes de executar qualquer um dos scripts gerados, tem de definir o ambiente certo e iniciar sessão na subscrição de destino (no novo Azure Stack Hub, por exemplo) e definir o diretório de trabalho para a pasta Deployment_Files .

Deployment_Files irá conter dois ficheiros DeployResourceGroups.ps1 e DeployResources.ps1. Executar DeployResourceGroups.ps1 irá implementar os grupos de recursos. Executar DeployResources.ps1 implementará todos os recursos que foram processados. No caso de a ferramenta ter sido executada com Todos ou Microsoft.Compute/virtualMachines como o tipo de recurso, DeployResources.ps1 irá pedir ao utilizador para introduzir uma palavra-passe de administrador de máquina virtual que será utilizada para criar todas as máquinas virtuais.

Exemplo

  1. Execute o script.

    Executar o script

    Nota

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

  2. Reveja as pastas recém-criadas:

    Rever as pastas

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

    Configurar e iniciar a implementação

  4. Execute Get-Job para verificar o estado. Get-Job | Receive-Job irá devolver os resultados.

Limpeza

Dentro da pasta replicatorV3, existe um ficheiro com o nome cleanup_generated_items.ps1 . Irá remover as pastas Deployment_Files, Parameter_Files e Custom_ARM_Templates e todos os respetivos conteúdos.

Operações do replicador de subscrição

O replicador de subscrição do Azure (v3) pode atualmente 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 Todos como o tipo de recurso, será seguida a seguinte ordem ao replicar e implementar (na parte abaixo, todos os recursos têm a configuração replicada, ou seja, sku, oferta, etc.):

  • Microsoft.Network/virtualNetworks

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

  • Microsoft.Network/virtualNetworkGateways

    • Replica: – Configuração do IP público – Configuração da 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 do endereço IP público – Configuração da 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 operativo
      - Configuração da conta de armazenamento de diagnóstico
      - Configuração de IP público
      - Interface 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

Nota

Apenas cria discos geridos para discos de dados e discos de SO. Atualmente, não existe suporte para a utilização de contas de armazenamento

Limitações

A ferramenta pode replicar recursos de uma subscrição para outra, desde que os fornecedores de recursos da subscrição de destino suportem todos os recursos e opções que estão a ser replicados a partir 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 de destino correspondem às da subscrição de origem.

Ao replicar do Azure comercial para o Azure comercial ou de uma subscrição no Azure Stack Hub para outra subscrição no mesmo Azure Stack Hub, haverá problemas ao replicar contas de armazenamento. Tal deve-se ao requisito de nomenclatura da conta de armazenamento de que todos os nomes de contas de armazenamento são exclusivos em todo o Azure comercial ou em todas as subscrições numa instância/região do Azure Stack Hub. A replicação de contas de armazenamento em diferentes instâncias do Azure Stack Hub será bem-sucedida, uma vez que as Pilhas são regiões/instâncias separadas.

Passos seguintes

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