Compartir por

Establecimiento del nombre y el tipo de los recursos secundarios en Bicep

  • Artigo

Los recursos secundarios son recursos que solo existen en el contexto de otro recurso. Por ejemplo, una extensión de máquina virtual no puede existir sin una máquina virtual. El recurso de extensión es un elemento secundario de la máquina virtual.

Cada recurso primario solo acepta determinados tipos de recursos como recursos secundarios. La jerarquía de tipos de recursos está disponible en el artículo de referencia de recursos de Bicep.

En este artículo se muestran distintas formas de declarar un recurso secundario.

Recursos de aprendizaje

Si prefiere información sobre los recursos secundarios a través de una guía paso a paso, consulte Implementación de recursos secundarios y de extensión mediante el uso de Bicep.

Patrón de nombre y de tipo

En Bicep, puede especificar el recurso secundario dentro del recurso primario o fuera de él. Los valores proporcionados para el nombre y el tipo de recurso varían en función de cómo se declara el recurso secundario. Pero el nombre completo y el tipo siempre se resuelven con el mismo patrón.

El nombre completo del recurso secundario usa el patrón:

{parent-resource-name}/{child-resource-name}

Si tienes más de dos niveles en la jerarquía, sigue repitiendo los nombres primarios:

{parent-resource-name}/{child-level1-resource-name}/{child-level2-resource-name}

El tipo completo del recurso secundario usa el patrón:

{resource-provider-namespace}/{parent-resource-type}/{child-resource-type}

Si tiene más de dos niveles en la jerarquía, siga repitiendo tipos de recursos primarios:

{resource-provider-namespace}/{parent-resource-type}/{child-level1-resource-type}/{child-level2-resource-type}

Si cuenta los segmentos entre los caracteres /, el número de segmentos del tipo siempre es uno más que el número de segmentos del nombre.

Dentro del recurso primario

En el ejemplo siguiente se muestra el recurso secundario incluido en la propiedad resources del recurso primario.

resource <parent-resource-symbolic-name> '<resource-type>@<api-version>' = {
  <parent-resource-properties>

  resource <child-resource-symbolic-name> '<child-resource-type>' = {
    <child-resource-properties>
  }
}

Debe aparecer una declaración de recursos anidada en el nivel superior de sintaxis del recurso primario. Las declaraciones pueden anidarse a una profundidad arbitraria, siempre y cuando cada nivel sea un tipo secundario de su recurso primario.

Cuando el recurso secundario se define dentro del tipo de recurso primario, los valores type y name se indican como un solo segmento sin barras diagonales. En el ejemplo siguiente se muestra una cuenta de almacenamiento con un recurso secundario para el servicio de archivos, y el servicio de archivos tiene un recurso secundario para el recurso compartido de archivos. El nombre del servicio de archivos se establece en default y su tipo en fileServices. El nombre del recurso compartido de archivos se establece en exampleshare y su tipo en shares.

resource storage 'Microsoft.Storage/storageAccounts@2023-04-01' = {
  name: 'examplestorage'
  location: resourceGroup().location
  kind: 'StorageV2'
  sku: {
    name: 'Standard_LRS'
  }

  resource service 'fileServices' = {
    name: 'default'

    resource share 'shares' = {
      name: 'exampleshare'
    }
  }
}

Los tipos de recurso completos siguen siendo Microsoft.Storage/storageAccounts/fileServices y Microsoft.Storage/storageAccounts/fileServices/shares. No se proporciona Microsoft.Storage/storageAccounts/ porque se supone que viene del tipo y versión del recurso primario. El recurso anidado puede declarar opcionalmente una versión de API mediante la sintaxis <segment>@<version>. Si el recurso anidado omite la versión de API, se usa la versión de API del recurso primario. Si el recurso anidado especifica una versión de API, se usa la versión de API especificada.

Los nombres de recursos secundarios se establecen en default y exampleshare, pero los nombres completos incluyen los nombres primarios. No se proporciona examplestorage ni default porque se asume a partir del recurso primario.

Un recurso anidado puede acceder a las propiedades de su recurso primario. Otros recursos declarados dentro del cuerpo del mismo recurso primario pueden hacerse referencia entre sí mediante los nombres simbólicos. Es posible que un recurso primario no tenga acceso a las propiedades de los recursos que contiene. Este intento provocaría una dependencia cíclica.

Para hacer referencia a un recurso anidado fuera del recurso primario, debe completarse con el nombre del recurso contenedor y el operador ::. Por ejemplo, para generar una propiedad desde un recurso secundario:

output childAddressPrefix string = VNet1::VNet1_Subnet1.properties.addressPrefix

Fuera del recurso primario

En el ejemplo siguiente se muestra el recurso secundario fuera del recurso primario. Este enfoque puede usarse si el recurso primario no está implementado en la misma plantilla o si quiere usar un bucle para crear más de un recurso secundario. Especifique la propiedad primaria en el elemento secundario con el valor establecido en el nombre simbólico del elemento primario. Con esta sintaxis, todavía debe declarar el tipo de recurso completo, pero el nombre del recurso secundario es solo el nombre del elemento secundario.

resource <parent-resource-symbolic-name> '<resource-type>@<api-version>' = {
  name: 'myParent'
  <parent-resource-properties>
}

resource <child-resource-symbolic-name> '<child-resource-type>@<api-version>' = {
  parent: <parent-resource-symbolic-name>
  name: 'myChild'
  <child-resource-properties>
}

Cuando el recurso secundario se define fuera del recurso primario, los valores type y name se indican con barras diagonales para incluir el tipo y el nombre primarios.

En el ejemplo siguiente se muestra una cuenta de almacenamiento, un servicio de archivos y un recurso compartido de archivos que se definen en el nivel raíz.

resource storage 'Microsoft.Storage/storageAccounts@2023-04-01' = {
  name: 'examplestorage'
  location: resourceGroup().location
  kind: 'StorageV2'
  sku: {
    name: 'Standard_LRS'
  }
}

resource service 'Microsoft.Storage/storageAccounts/fileServices@2023-04-01' = {
  name: 'default'
  parent: storage
}

resource share 'Microsoft.Storage/storageAccounts/fileServices/shares@2023-04-01' = {
  name: 'exampleshare'
  parent: service
}

Hacer referencia al nombre simbólico del recurso secundario funciona igual que hacer referencia al elemento primario.

Nombre completo del recurso fuera del elemento primario

También se puede usar el nombre completo y el tipo completo del recurso al declarar el recurso secundario fuera del elemento primario. No se debe establecer la propiedad primaria en el recurso secundario. Dado que la dependencia no se puede inferir, se debe establecer explícitamente.

resource storage 'Microsoft.Storage/storageAccounts@2023-04-01' = {
  name: 'examplestorage'
  location: resourceGroup().location
  kind: 'StorageV2'
  sku: {
    name: 'Standard_LRS'
  }
}

resource service 'Microsoft.Storage/storageAccounts/fileServices@2023-04-01' = {
  name: 'examplestorage/default'
  dependsOn: [
    storage
  ]
}

resource share 'Microsoft.Storage/storageAccounts/fileServices/shares@2023-04-01' = {
  name: 'examplestorage/default/exampleshare'
  dependsOn: [
    service
  ]
}

Importante

No se recomienda establecer el nombre completo y el tipo completo del recurso. No es tan seguro como usar cualquiera de los otros enfoques. Para obtener más información, consulte Regla de Linter: uso de la propiedad primaria.

Pasos siguientes