Definición de recursos secundarios

  • 5 minutos

Es lógico implementar algunos recursos únicamente dentro del contexto de su elemento primario. Estos recursos se denominan recursos secundarios. Existen numerosos tipos de recursos secundarios en Azure. Estos son algunos ejemplos:

Nombre Tipo de recurso
Subredes de la red virtual Microsoft.Network/virtualNetworks/subnets
Configuración de App Service Microsoft.Web/sites/config
Bases de datos SQL Microsoft.Sql/servers/databases
Extensiones de máquina virtual Microsoft.Compute/virtualMachines/extensions
Contenedores de blobs de almacenamiento Microsoft.Storage/storageAccounts/blobServices/containers
Contenedores de Azure Cosmos DB Microsoft.DocumentDB/databaseAccounts/sqlDatabases/containers

Por ejemplo, veamos un contenedor de blobs de almacenamiento. Un contenedor de blobs debe implementarse en una cuenta de almacenamiento, y no tiene sentido que exista un contenedor fuera de una cuenta de almacenamiento.

Los tipos de recursos secundarios tienen nombres más largos con varias partes. Un contenedor de blobs de almacenamiento tiene este nombre de tipo completo: Microsoft.Storage/storageAccounts/blobServices/containers. El identificador de recurso de un contenedor de blobs incluye el nombre de la cuenta de almacenamiento que contiene el contenedor y el nombre del contenedor.

Nota:

Algunos recursos secundarios pueden tener el mismo nombre que otros tipos de recursos secundarios de distintos elementos principales. Por ejemplo, containers es un tipo secundario de cuentas de almacenamiento y bases de datos de Azure Cosmos DB. Los nombres son los mismos, pero representan recursos diferentes y sus nombres de tipo completos son diferentes.

¿Cómo se definen los recursos secundarios?

Con Bicep, puede declarar recursos secundarios de varias maneras diferentes. Cada una de ellas tiene sus propias ventajas y cada una de ellas es adecuada para algunas situaciones y no para otras. Se describirán los dos enfoques.

Sugerencia

Todos los enfoques siguientes tienen como resultado las mismas actividades de implementación en Azure. Puede elegir el enfoque que mejor se adapte a sus necesidades sin tener que preocuparse por estropear algo. Además, puede actualizar la plantilla y cambiar el enfoque que está usando.

Recursos anidados

Un enfoque para definir un recurso secundario es anidar el recurso secundario dentro del elemento primario. Este es un ejemplo de una plantilla de Bicep que implementa una máquina virtual y una extensión de máquina virtual. Una extensión de máquina virtual es un recurso secundario que proporciona un comportamiento adicional para una máquina virtual. En este caso, la extensión ejecuta un script personalizado en la máquina virtual después de la implementación.

resource vm 'Microsoft.Compute/virtualMachines@2020-06-01' = {
  name: vmName
  location: location
  properties: {
    // ...
  }

  resource installCustomScriptExtension 'extensions' = {
    name: 'InstallCustomScript'
    location: location
    properties: {
      // ...
    }
  }
}

Observe que el recurso anidado tiene un tipo de recurso más sencillo de lo normal. Aunque el nombre de tipo completo es Microsoft.Compute/virtualMachines/extensions, el recurso anidado hereda automáticamente el tipo de recurso del elemento primario, por lo que solo debe especificar el tipo de recurso secundario, extensions.

Observe también que no hay ninguna versión de API especificada para el recurso anidado. Bicep supone que quiere usar la misma versión de API que el recurso primario, aunque puede invalidar la versión de la API si lo desea.

Puede hacer referencia a un recurso anidado mediante el operador ::. Por ejemplo, puede crear una salida que devuelva el identificador de recurso completo de la extensión:

output childResourceId string = vm::installCustomScriptExtension.id

Anidar recursos es una manera sencilla de declarar un recurso secundario. El anidamiento de recursos también hace que la relación de elementos primarios y secundarios resulte evidente para cualquier persona que lea la plantilla. Sin embargo, si tiene muchos recursos anidados o varias capas de anidamiento, las plantillas pueden ser más difíciles de leer. También puede anidar recursos de hasta cinco capas de profundidad.

Propiedad primaria

También puede declarar el recurso secundario sin anidamiento. A continuación, use la propiedad parent para indicar a Bicep la relación primario-secundario:

resource vm 'Microsoft.Compute/virtualMachines@2020-06-01' = {
  name: vmName
  location: location
  properties: {
    // ...
  }
}

resource installCustomScriptExtension 'Microsoft.Compute/virtualMachines/extensions@2020-06-01' = {
  parent: vm
  name: 'InstallCustomScript'
  location: location
  properties: {
    // ...
  }
}

Observe que el recurso secundario usa la propiedad parent para hacer referencia al nombre simbólico de su elemento primario.

Este enfoque para hacer referencia al elemento primario es otra manera fácil de declarar un recurso secundario. Bicep entiende la relación entre los recursos primario y secundario, por lo que no es necesario especificar el nombre completo del recurso ni configurar una dependencia entre los recursos. El enfoque también evita tener demasiado anidamiento, lo que puede resultar difícil de leer. Sin embargo, debe especificar explícitamente el tipo de recurso completo y la versión de API cada vez que defina un recurso secundario mediante la propiedad parent.

Para hacer referencia a un recurso secundario declarado con la propiedad parent, use su nombre simbólico como lo haría con un recurso primario normal:

output childResourceId string = installCustomScriptExtension.id

Construcción del nombre del recurso

Hay algunas circunstancias en las que no se pueden usar recursos anidados ni la palabra clave parent. Algunos ejemplos son cuando se declaran recursos secundarios dentro de un bucle for o cuando se necesitan expresiones complejas para seleccionar dinámicamente un recurso primario para un elemento secundario. En estas situaciones, puede implementar un recurso secundario mediante la construcción manual del nombre del recurso secundario para que incluya su nombre de recurso primario, como se muestra aquí:

resource vm 'Microsoft.Compute/virtualMachines@2020-06-01' = {
  name: vmName
  location: location
  properties: {
    // ...
  }
}

resource installCustomScriptExtension 'Microsoft.Compute/virtualMachines/extensions@2020-06-01' = {
  name: '${vm.name}/InstallCustomScript'
  location: location
  properties: {
    // ...
  }
}

Observe que en este ejemplo se usa la interpolación de cadenas para anexar la propiedad name del recurso de máquina virtual al nombre del recurso secundario. Bicep entiende que hay una dependencia entre los recursos secundario y primario. Puede declarar el nombre del recurso secundario mediante la variable vmName en su lugar. Sin embargo, si lo hace, la implementación podría producir un error porque Bicep no entendería que el recurso primario debe implementarse antes del recurso secundario:

Para resolver esta situación, puede indicar manualmente a Bicep la dependencia mediante la palabra clave dependsOn, como se muestra aquí:

resource vm 'Microsoft.Compute/virtualMachines@2020-06-01' = {
  name: vmName
  location: location
  properties: {
    // ...
  }
}

resource installCustomScriptExtension 'Microsoft.Compute/virtualMachines/extensions@2020-06-01' = {
  name: '${vmName}/InstallCustomScript'
  dependsOn: [
    vm
  ]
  //...
}

Sugerencia

Por lo general, es mejor evitar la construcción de nombres de recursos, ya que se pierden muchas de las ventajas que Bicep puede proporcionar cuando comprende las relaciones entre los recursos. Use esta opción solo cuando no pueda usar uno de los otros enfoques para declarar recursos secundarios.

Identificadores de recursos secundarios

Para empezar a crear un identificador de recurso secundario, incluya el identificador de recurso de su elemento primario y, a continuación, anexe el nombre y el tipo de recurso secundario. Por ejemplo, veamos una cuenta de Azure Cosmos DB denominada toyrnd. El proveedor de recursos de Azure Cosmos DB expone un tipo llamado databaseAccounts, que es el recurso primario que implementa:

/subscriptions/f0750bbe-ea75-4ae5-b24d-a92ca601da2c/resourceGroups/ToyDevelopment/providers/Microsoft.DocumentDB/databaseAccounts/toyrnd

Esta es una representación visual del mismo identificador de recurso:

Resource ID for an Azure Cosmos DB account, split with the key-value pair on a separate line.

Si agregamos una base de datos a esta cuenta, usaremos el tipo de recurso secundario sqlDatabases. Vamos a agregar una base de datos denominada FlightTests a la cuenta de Azure Cosmos DB y echemos un vistazo al identificador de recurso secundario:

/subscriptions/f0750bbe-ea75-4ae5-b24d-a92ca601da2c/resourceGroups/ToyDevelopment/providers/Microsoft.DocumentDB/databaseAccounts/toyrnd/sqlDatabases/FlightTests

Esta es una representación visual:

Child resource ID for an Azure Cosmos DB database, split with the key-value pair on a separate line.

Puede tener varios niveles de recursos secundarios. Este es un identificador de recurso de ejemplo que muestra una cuenta de almacenamiento con dos niveles de recursos secundarios:

/subscriptions/f0750bbe-ea75-4ae5-b24d-a92ca601da2c/resourceGroups/ToyDevelopment/providers/Microsoft.Storage/storageAccounts/secrettoys/blobServices/default/containers/glitterspecs

Esta es una representación visual del mismo identificador de recurso:

Child resource ID for a storage account with blob container, split with the key-value pair on a separate line.

Este identificador de recurso tiene varios componentes:

  • Todo hasta secrettoys es el identificador de recurso primario.

  • blobServices indica que el recurso está dentro de un tipo de recurso secundario denominado blobServices.

    Nota:

    No tiene que crear recursos blobServices manualmente. El proveedor de recursos Microsoft.Storage crea automáticamente este recurso al crear una cuenta de almacenamiento. Este tipo de recurso a veces se denomina recurso implícito. Son bastante poco comunes, pero los encontrará en Azure.

  • default es el nombre del recurso secundario blobServices.

    Nota:

    A veces, solo se permite una única instancia de un recurso secundario. Este tipo de instancia se denomina singleton y a menudo se le da el nombre default.

  • containers indica que el recurso está dentro de un tipo de recurso secundario denominado containers.

  • glitterspecs es el nombre del contenedor de blobs.

Cuando se trabaja con recursos secundarios, los identificadores de recursos pueden ser largos y tener un aspecto complicado. Sin embargo, si divide un identificador de recurso en sus partes componentes, le será más fácil comprender cómo se estructura el recurso. Un identificador de recurso también puede proporcionar pistas importantes sobre cómo se comporta el recurso.