Replicación de recursos mediante el replicador de suscripciones de Azure Stack Hub

Puede usar el script de PowerShell del replicador de suscripciones de Azure Stack Hub para copiar recursos entre suscripciones de Azure Stack Hub, entre sellos de Azure Stack Hub o entre Azure Stack Hub y Azure. El script del replicador lee y vuelve a generar los recursos de Azure Resource Manager de distintas suscripciones de Azure y Azure Stack Hub. En este artículo se explica cómo funciona el script, cómo puede usar el script y se proporciona una referencia para las operaciones de script.

Puede encontrar los scripts usados en este artículo en el repositorio GitHub patrones de Intelligent Edge Azure. Los scripts se encuentran en la carpeta del replicador de suscripciones .

Introducción al replicador de suscripciones

El replicador de suscripciones Azure es modular. Esta herramienta usa un procesador principal que organiza la replicación de recursos. Además, la herramienta admite procesadores personalizables que actúan como plantillas para copiar diferentes tipos de recursos.

El procesador principal consta de los tres scripts siguientes:

• resource_retriever.ps1

  • Genera carpetas para almacenar archivos de salida.

  • Establece el contexto en la suscripción de origen.

  • Recupera los recursos y los pasa a resource_processor.ps1.

• resource_processor.ps1

  • Procesa el recurso pasado por resource_retriever.ps1.

  • Determina qué procesador personalizado se va a usar y pasa los recursos.

• post_process.ps1

  • Post procesa la salida generada por el procesador personalizado para prepararla para implementarla en la suscripción de destino.

  • Genera código de implementación para implementar los recursos en la suscripción de destino.

Los tres scripts controlan el flujo de información de una manera estándar para permitir una mayor flexibilidad. Agregar compatibilidad con recursos adicionales, por ejemplo, no requiere cambiar ningún código en el procesador principal.

Los procesadores personalizados, mencionados anteriormente, son ps1 archivos que dictan cómo se debe procesar un determinado tipo de recurso. El nombre de un procesador personalizado siempre usa los datos de tipo en un recurso. Por ejemplo, suponiendo que $vm contiene un objeto de máquina virtual, ejecutando $vm. El tipo produce Microsoft.Compute/virtualMachines. Esto significa que un procesador para una máquina virtual se denomina virtualMachines_processor.ps1. El nombre debe ser exactamente como aparece en los metadatos del recurso, ya que el procesador principal lo usa para determinar qué procesador personalizado se va a usar.

Un procesador personalizado determina cómo se debe replicar un recurso al determinar qué información es importante y dicta cómo se debe extraer esa información de los metadatos del recurso. A continuación, el procesador personalizado toma todos los datos extraídos y lo usa para generar un archivo de parámetros que funcione con una plantilla de Azure Resource Manager para implementar el recurso en la suscripción de destino. El script post_process.ps1 almacena este archivo de parámetros en la carpeta Parameter_Files después de procesarlo.

Hay una carpeta en la estructura de archivos replicadores denominada Standardized_ARM_Templates. En función del entorno de origen, las implementaciones usan una de estas plantillas de Resource Manager estandarizadas o es posible que tenga que generar una plantilla de Resource Manager personalizada. En este caso, un procesador personalizado debe llamar a un generador de plantillas de plantilla de Resource Manager. En el ejemplo iniciado anteriormente, el nombre de un generador de plantillas de Resource Manager para máquinas virtuales es virtualMachines_ARM_Template_Generator.ps1. El generador de plantillas de Resource Manager es responsable de crear una plantilla de Resource Manager personalizada basada en qué información se encuentra en los metadatos de un recurso. Por ejemplo, si el recurso de máquina virtual tiene metadatos que especifican que es miembro de un conjunto de disponibilidad, el generador de plantillas de Resource Manager crea una plantilla de Resource Manager con código que especifica el identificador del conjunto de disponibilidad del que forma parte la máquina virtual. De este modo, cuando la máquina virtual se implementa en la nueva suscripción, se agrega automáticamente al conjunto de disponibilidad tras la implementación. Estas plantillas de Resource Manager personalizadas se almacenan en la carpeta Custom_ARM_Templates ubicada dentro de la carpeta Standardized_ARM_Templates. El script depost_processor.ps1 es responsable de determinar si se supone que una implementación debe usar una plantilla de Resource Manager estandarizada o una personalizada y generar el código de implementación correspondiente.

El script post-process.ps1 es responsable de limpiar los archivos de parámetros y crear los scripts que el usuario usa para implementar los nuevos recursos. Durante la fase de limpieza, el script reemplaza todas las referencias al identificador de suscripción de origen, el identificador de inquilino y la ubicación por los valores de destino correspondientes. A continuación, genera el archivo de parámetros en la carpeta Parameter_Files . A continuación, determina si el recurso que se está procesando usa una plantilla de Resource Manager personalizada o no y genera el código de implementación correspondiente, que usa el cmdlet New-AzResourceGroupDeployment. A continuación, el código de implementación se agrega al archivo denominado DeployResources.ps1 almacenado en la carpeta Deployment_Files . Por último, el script determina el grupo de recursos al que pertenece el recurso y comprueba el script deDeployResourceGroups.ps1 para ver si el código de implementación para implementar ese grupo de recursos ya existe. Si no es así, el script agrega código a ese script para implementar el grupo de recursos. Si lo hace, el script no hace nada.

Recuperación dinámica de API

La herramienta incluye recuperación de API dinámica, por lo que usa la versión de API del proveedor de recursos más reciente disponible en la suscripción de origen para implementar los recursos en la suscripción de destino:

Sin embargo, la suscripción de destino puede tener una versión de API del proveedor de recursos anterior que no admite la versión que proporciona la suscripción de origen. En este caso, se produce un error al ejecutar la implementación. Para resolver este error, actualice los proveedores de recursos de la suscripción de destino para que coincidan con los de la suscripción de origen.

Implementaciones paralelas

La herramienta requiere un parámetro denominado parallel. Este parámetro toma un valor booleano que especifica si se van a implementar los recursos recuperados en paralelo. Si establece el valor en true, cada llamada a New-AzResourceGroupDeployment incluye la marca -asJob . El proceso agrega bloques de código que esperan a que los trabajos paralelos finalicen entre conjuntos de implementaciones de recursos en función de los tipos de recursos. Garantiza que todos los recursos de un tipo se implementan antes de implementar el siguiente tipo de recurso. Si establece el valor del parámetro paralelo en false, los recursos se implementan en serie.

Adición de tipos de recursos adicionales

Agregar nuevos tipos de recursos es sencillo. Cree un procesador personalizado y una plantilla de Resource Manager o un generador de plantillas de Resource Manager. Después de completar esos pasos, agregue el tipo de recurso al ValidateSet para el parámetro $resourceType y la matriz de $resourceTypes en resource_retriever.ps1. Al agregar el tipo de recurso a la matriz de $resourceTypes , agréguelo en el orden correcto. El orden de la matriz determina el orden en que se implementan los recursos, por lo que debe tener en cuenta las dependencias. Por último, si el procesador personalizado usa un generador de plantillas de Resource Manager, agregue el nombre del tipo de recurso a la matriz de $customTypes en post_process.ps1.

Ejecución del replicador de suscripciones de Azure

Para ejecutar la herramienta replicador de suscripciones (v3) de Azure, inicie resource_retriever.ps1 y proporcione todos los parámetros. Para el parámetro resourceType , puede elegir Todo en lugar de un tipo de recurso. Si selecciona Todo, resource_retriever.ps1 procesa todos los recursos en un orden para que, cuando se ejecute la implementación, los recursos dependientes se implementen primero. Por ejemplo, las redes virtuales se implementan antes de que las máquinas virtuales como máquinas virtuales requieran que se implemente correctamente una red virtual.

Cuando el script termine de ejecutarse, hay tres carpetas nuevas: Deployment_Files, Parameter_Files y Custom_ARM_Templates.

Deployment_Files contiene dos archivos: DeployResourceGroups.ps1 y DeployResources.ps1. Al ejecutar DeployResourceGroups.ps1, implementa los grupos de recursos. Al ejecutar DeployResources.ps1, implementa todos los recursos procesados. Si ejecuta la herramienta con Todos o Microsoft. Compute/virtualMachines como tipo de recurso, DeployResources.ps1 le pedirá que escriba una contraseña de administrador de máquina virtual que usa para crear todas las máquinas virtuales.

Ejemplo

1. Ejecute el script.

   

   Note

   No olvide configurar el entorno de origen y el contexto de suscripción para la instancia de PS.

2. Revise las carpetas recién creadas:

   

3. Establezca el contexto en la suscripción de destino, cambie la carpeta a Deployment_Files, implemente los grupos de recursos (ejecute el DeployResourceGroups.ps1 script) e inicie la implementación de recursos (ejecute el DeployResources.ps1 script).

   

4. Ejecute Get-Job para comprobar el estado. Get-Job | Receive-Job devolverá los resultados.

Limpieza

Dentro de la replicatorV3 carpeta , el archivo cleanup_generated_items.ps1 quita las carpetas Deployment_Files, Parameter_Files y Custom_ARM_Templates y todo su contenido.

Operaciones del replicador de suscripciones

El replicador de suscripciones de Azure (v3) puede replicar actualmente los siguientes 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

Al ejecutar la herramienta con All como tipo de recurso, sigue el orden de la lista siguiente al replicar e implementar. En la lista siguiente, todos los recursos tienen su configuración replicada, como sku, oferta y otras opciones:

• Microsoft.Network/virtualNetworks

  • Replica: - Todos los espacios de direcciones - Todas las subredes

• Microsoft.Network/virtualNetworkGateways

  • Replica: - Configuración de IP pública - Configuración de subred - Tipo de VPN - Tipo de puerta de enlace

• Microsoft.Network/routeTables

• Microsoft.Network/networkSecurityGroups

  • Replica: - Todas las reglas de seguridad entrantes y salientes

• Microsoft.Network/publicIPAddresses

• Microsoft.Network/loadBalancers

  • Replica: - Direcciones IP privadas - Configuración de direcciones IP públicas - Configuración de subred

• Microsoft.Compute/availabilitySets

  • Replica: - Número de dominios de error: número de dominios de actualización

• Microsoft.Storage/storageAccounts

• Microsoft. Compute/virtualMachines

  • Replica:
    - Discos de datos (sin datos)
    - Tamaño de máquina virtual
    - Sistema operativo
    - Configuración de la cuenta de almacenamiento de diagnóstico
    - Configuración de ip pública
    - Interfaz de red
    - Dirección IP privada de la interfaz de red
    - Configuración del grupo de seguridad de red
    - Configuración del conjunto de disponibilidad

Limitations

La herramienta puede replicar recursos de una suscripción a otra siempre que la suscripción de destino admita todos los tipos de recursos y opciones que va a replicar desde la suscripción de origen. Para garantizar la replicación correcta, asegúrese de que las versiones del proveedor de recursos de la suscripción de destino coincidan con las de la suscripción de origen.

Para garantizar la replicación correcta, asegúrese de que las versiones del proveedor de recursos de la suscripción de destino coincidan con las de la suscripción de origen.

Al replicar recursos de Azure comerciales en Azure comerciales o desde una suscripción dentro de Azure Stack Hub a otra en la misma Azure Stack Hub, se producen problemas al replicar cuentas de almacenamiento. Este problema se produce porque los nombres de cuenta de almacenamiento deben ser únicos en todas las Azure comerciales o en todas las suscripciones de una región o instancia de Azure Stack Hub. Puede replicar correctamente las cuentas de almacenamiento en diferentes instancias de Azure Stack Hub porque las pilas son regiones o instancias independientes.

Pasos siguientes

Diferencias y consideraciones para las redes de Azure Stack Hub