Patrón de parámetro lógico

Use parámetros para especificar la definición lógica de un recurso o incluso de varios recursos. El archivo bicep convierte el parámetro lógico en definiciones de recursos que se pueden implementar. Si sigue este patrón, puede separar lo que se implementa de cómo se implementa.

Contexto y problema

En implementaciones complejas, se usan parámetros y bucles de matriz para crear un conjunto de recursos o propiedades de recursos. Si crea un parámetro que define los detalles de un recurso, cree parámetros difíciles de entender y trabajar con.

Solución

Defina parámetros que acepten valores simplificados o valores específicos del dominio empresarial en lugar de específicos del recurso de Azure. Cree lógica en el archivo de Bicep para convertir los valores simplificados en definiciones de recursos de Azure.

A menudo, usará un bucle para traducir los valores lógicos definidos en parámetros a los valores de propiedad esperados por la definición de recurso.

Al usar este patrón, puede aplicar fácilmente valores predeterminados para las propiedades que no necesitan cambiar entre recursos. También puede usar variables y funciones para determinar los valores de las propiedades de recursos automáticamente en función de sus propias reglas de negocio.

Mediante el patrón de parámetro lógico, puede implementar conjuntos complejos de recursos a la vez que mantiene los parámetros de la plantilla sencillos y fáciles de trabajar.

Ejemplo 1: Subredes de red virtual

En este ejemplo se muestra cómo puede usar el patrón para simplificar la definición de nuevas subredes y para agregar lógica de negocios que determine la configuración del recurso.

En este ejemplo, se define un parámetro que especifica la lista de subredes que se deben crear en una red virtual. La definición de cada subred también incluye una propiedad denominada allowRdp. Esta propiedad indica si la subred debe estar asociada a un grupo de seguridad de red que permita el tráfico entrante de Escritorio remoto:

param subnets array = [
  {
    name: 'Web'
    addressPrefix: '10.0.0.0/24'
    allowRdp: false
  }
  {
    name: 'JumpBox'
    addressPrefix: '10.0.1.0/24'
    allowRdp: true
  }
]

A continuación, el archivo bicep define una variable para convertir cada una de las definiciones de subred lógica en la definición de subred requerida por Azure. El grupo de seguridad de red se asigna a la subred cuando la propiedad allowRdp está establecida en true.

var subnetsToCreate = [for item in subnets: {
  name: item.name
  properties: {
    addressPrefix: item.addressPrefix
    networkSecurityGroup: item.allowRdp ? {
       id: nsgAllowRdp.id
    } : null
  }
}]

Por último, el archivo de Bicep define la red virtual y usa la variable para configurar las subredes:

resource virtualNetwork 'Microsoft.Network/virtualNetworks@2022-11-01' = {
  name: virtualNetworkName
  location: location
  properties: {
    addressSpace: {
      addressPrefixes: [
        virtualNetworkAddressPrefix
      ]
    }
    subnets: subnetsToCreate
  }
}

Consulte el ejemplo completo.

Ejemplo 2: cola de Service Bus

En este ejemplo se muestra cómo puede usar el patrón para aplicar un conjunto coherente de configuración en varios recursos definidos en función de un parámetro.

En este ejemplo, se define un parámetro con una lista de nombres de cola para una cola de Azure Service Bus:

param queueNames array = [
  'queue1'
  'queue2'
]

Después, defina los recursos de la cola utilizando un bucle y configure cada cola para reenviar automáticamente mensajes con letra muerta a otra cola centralizada.

resource queues 'Microsoft.ServiceBus/namespaces/queues@2022-10-01-preview' = [for queueName in queueNames: {
  parent: serviceBusNamespace
  name: queueName
  properties: {
    forwardDeadLetteredMessagesTo: deadLetterFirehoseQueueName
  }
}]

Consulte el ejemplo completo.

Ejemplo 3: Recursos para una solución multiinquilino

En este ejemplo se muestra cómo puede usar el patrón al desarrollar una solución de multitenencia. La implementación de Bicep crea conjuntos complejos de recursos basados en una lista lógica de inquilinos y usa módulos para simplificar la creación de recursos compartidos y específicos del inquilino. Cada inquilino obtiene su propia base de datos en Azure SQL y su propio dominio personalizado configurado en Azure Front Door.

En este ejemplo, se define un parámetro que especifica la lista de inquilinos. La definición de un inquilino es simplemente el identificador de inquilino y su nombre de dominio personalizado:

param tenants array = [
  {
    id: 'fabrikam'
    domainName: 'fabrikam.com'
  }
  {
    id: 'contoso'
    domainName: 'contoso.com'
  }
]

El archivo Bicep principal define los recursos compartidos y, después, usa un módulo para recorrer en bucle los inquilinos:

module tenantResources 'tenant-resources.bicep' = [for tenant in tenants: {
  name: 'tenant-${tenant.id}' 
  params: {
    location: location
    tenant: tenant
    sqlServerName: sqlServerName
    frontDoorProfileName: frontDoorProfileName
  }
}]

En el módulo, se implementan los recursos específicos del inquilino.

Consulte el ejemplo completo.

Consideraciones

• Cuando esté desarrollando o depurando el archivo Bicep, considere la posibilidad de crear la variable de asignación sin definir un recurso. A continuación, defina una salida con el valor de la variable para que pueda ver el resultado del mapeo.
• Puede usar condiciones para implementar recursos de forma selectiva en función de los valores de parámetro lógico.
• Al crear nombres de recursos dinámicamente, asegúrese de que los nombres cumplen los requisitos del recurso que va a implementar. Es posible que tenga que generar un nombre para algunos recursos en lugar de aceptar nombres directamente a través de parámetros.

Pasos siguientes

Más información sobre el patrón de archivo de variables compartido.