Partilhar via

Definir nome e tipo para recursos subordinados no Bicep

  • Artigo

Os recursos subordinados são recursos que existem apenas no contexto de outro recurso. Por exemplo, uma extensão de máquina virtual não pode existir sem uma máquina virtual. O recurso de extensão é um elemento subordinado da máquina virtual.

Cada recurso principal aceita apenas determinados tipos de recursos como recursos subordinados. A hierarquia de tipos de recursos está disponível na referência de recursos do Bicep.

Este artigo mostra diferentes formas de declarar um recurso subordinado.

Recursos de preparação

Se preferir saber mais sobre os recursos subordinados através da orientação passo a passo, veja Implementar recursos subordinados e de extensão com o Bicep.

Padrão de nome e tipo

No Bicep, pode especificar o recurso subordinado no recurso principal ou fora do recurso principal. Os valores fornecidos para o nome do recurso e o tipo de recurso variam com base na forma como declara o recurso subordinado. No entanto, o nome completo e o tipo resolvem sempre para o mesmo padrão.

O nome completo do recurso subordinado utiliza o padrão:

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

Se tiver mais de dois níveis na hierarquia, continue a repetir os nomes principais:

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

O tipo completo do recurso subordinado utiliza o padrão:

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

Se tiver mais de dois níveis na hierarquia, continue a repetir os tipos de recursos principais:

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

Se contar os segmentos entre / carateres, o número de segmentos no tipo é sempre mais um do que o número de segmentos no nome.

No recurso principal

O exemplo seguinte mostra o recurso subordinado incluído na propriedade resources do recurso principal.

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

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

Tem de aparecer uma declaração de recursos aninhado no nível superior de sintaxe do recurso principal. As declarações podem ser aninhadas arbitrariamente profundas, desde que cada nível seja um tipo subordinado do recurso principal.

Quando definido no tipo de recurso principal, formatará os valores de tipo e nome como um único segmento sem barras. O exemplo seguinte mostra uma conta de armazenamento com um recurso subordinado para o serviço de ficheiros e o serviço de ficheiros tem um recurso subordinado para a partilha de ficheiros. O nome do serviço de ficheiros está definido como default e o respetivo tipo está definido como fileServices. O nome da partilha de ficheiros está definido exampleshare e o respetivo tipo está definido como 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'
    }
  }
}

Os tipos de recursos completos ainda Microsoft.Storage/storageAccounts/fileServices são e Microsoft.Storage/storageAccounts/fileServices/shares. Não fornece Microsoft.Storage/storageAccounts/ porque é assumido a partir do tipo de recurso principal e da versão. Opcionalmente, o recurso aninhado pode declarar uma versão da API com a sintaxe <segment>@<version>. Se o recurso aninhado omitir a versão da API, é utilizada a versão da API do recurso principal. Se o recurso aninhado especificar uma versão da API, é utilizada a versão da API especificada.

Os nomes dos recursos subordinados estão definidos como default e, no e, no e exampleshare , os nomes completos incluem os nomes principais. Não fornece examplestorage ou default porque são assumidos a partir do recurso principal.

Um recurso aninhado pode aceder às propriedades do recurso principal. Outros recursos declarados dentro do corpo do mesmo recurso principal podem referenciar-se mutuamente com os nomes simbólicos. Um recurso principal pode não aceder às propriedades dos recursos que contém. Esta tentativa causaria uma dependência cíclica.

Para referenciar um recurso aninhado fora do recurso principal, tem de ser qualificado com o nome do recurso e o :: operador. Por exemplo, para exportar uma propriedade de um recurso subordinado:

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

Recurso principal externo

O exemplo seguinte mostra o recurso subordinado fora do recurso principal. Poderá utilizar esta abordagem se o recurso principal não estiver implementado no mesmo modelo ou se quiser utilizar um ciclo para criar mais do que um recurso subordinado. Especifique a propriedade principal no subordinado com o valor definido como o nome simbólico do elemento principal. Com esta sintaxe, ainda tem de declarar o tipo de recurso completo, mas o nome do recurso subordinado é apenas o nome do menor.

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>
}

Quando definido fora do recurso principal, formatará o tipo e com barras para incluir o tipo e o nome principais.

O exemplo seguinte mostra uma conta de armazenamento, um serviço de ficheiros e uma partilha de ficheiros que estão todos definidos ao nível da raiz.

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
}

Referenciar o nome simbólico do recurso subordinado funciona da mesma forma que referenciar o principal.

Nome completo do recurso fora do principal

Também pode utilizar o nome e o tipo de recurso completos ao declarar o recurso subordinado fora do principal. Não define a propriedade principal no recurso subordinado. Uma vez que a dependência não pode ser inferida, tem de a definir explicitamente.

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

Definir o nome e o tipo de recurso completos não é a abordagem recomendada. Não é tão seguro como utilizar uma das outras abordagens. Para obter mais informações, veja Regra do Linter: utilizar a propriedade principal.

Passos seguintes