Definir o nome e o tipo dos recursos filhos no Bicep

  • Artigo

Recursos filho 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 é filho da máquina virtual.

Cada recurso pai aceita somente determinados tipos de recurso como recursos filho. A hierarquia de tipos de recurso está disponível na referência de recurso Bicep.

Este artigo mostra diferentes maneiras de declarar um recurso filho.

Recursos de treinamento

Se você preferir aprender sobre os recursos de elemento filho através de diretrizes passo a passo, veja Implantar recursos filho e de extensão usando o Bicep.

Padrão de nome e tipo

No Bicep, você pode especificar o recurso filho dentro do recurso pai ou fora do recurso pai. Os valores que você fornece para o nome e o tipo de recurso variam com base no modo como você declara o recurso filho. No entanto, o nome completo e o tipo sempre são resolvidos para o mesmo padrão.

O nome completo do recurso filho usa o padrão:

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

Se você tiver mais de dois níveis na hierarquia, mantenha os nomes pai repetidos:

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

O tipo completo do recurso filho usa o padrão:

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

Se você tiver mais dois níveis na hierarquia, mantenha tipos de recurso pai repetidos:

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

Se você contar os segmentos entre os caracteres /, o número de segmentos no tipo será sempre mais um do que o número de segmentos no nome.

Dentro do recurso pai

O exemplo a seguir mostra o recurso filho incluído na propriedade do recurso pai.

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

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

Uma declaração de recurso aninhada deve aparecer no nível superior de sintaxe do recurso pai. As declarações podem ser aninhadas arbitrariamente em profundidade, desde que cada nível seja um tipo filho de seu recurso pai.

Quando definido dentro do tipo de recurso pai, você formata os valores de tipo e nome como um único segmento sem barras. O exemplo a seguir mostra uma conta de armazenamento com um recurso filho para o serviço de arquivo, e o serviço de arquivo tem um recurso filho para o compartilhamento de arquivos. O nome do serviço de arquivo é definido como default, e seu tipo é definido como fileServices. O nome do arquivo é definido como exampleshare, e seu tipo é definido como shares.

resource storage 'Microsoft.Storage/storageAccounts@2022-09-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 são Microsoft.Storage/storageAccounts/fileServices e Microsoft.Storage/storageAccounts/fileServices/shares. Você não fornece Microsoft.Storage/storageAccounts/ porque ele é presumido do tipo de recurso pai e da versão. O recurso aninhado pode, opcionalmente, declarar uma versão de API usando a sintaxe <segment>@<version>. Se o recurso aninhado omitir a versão de API, a versão de API do recurso pai será usada. Se o recurso aninhado especificar uma versão de API, a versão de API especificada será usada.

Os nomes dos recursos filhos são definidos como default e exampleshare, mas os nomes completos incluem os nomes pais. Você não fornece examplestorage ou default porque esses valores são assumidos por meio do recurso pai.

Um recurso aninhado pode acessar as propriedades de seu recurso pai. Outros recursos declarados dentro do corpo do mesmo recurso pai podem fazer referência entre si usando os nomes simbólicos. Um recurso pai pode não acessar as propriedades dos recursos que ele contém, essa tentativa causaria uma dependência cíclica.

Para fazer referência a um recurso aninhado fora do recurso pai, ele deve ser qualificado com o nome do recurso de contenção e o operador ::. Por exemplo, para gerar uma propriedade de um recurso filho:

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

Recurso pai externo

O exemplo a seguir mostra o recurso filho fora do recurso pai. Você pode usar essa abordagem se o recurso pai não for implantado no mesmo modelo ou se quiser usar um loop para criar mais de um recurso filho. Especifique a propriedade pai no filho com o valor definido como o nome simbólico do pai. Com essa sintaxe, você ainda precisará declarar o tipo de recurso completo, mas o nome do recurso filho é apenas o nome do filho.

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 pai, você formata o tipo e com barras para incluir o tipo e nome pai.

O exemplo a seguir mostra uma conta de armazenamento, um serviço de arquivo e um compartilhamento de arquivos que são todos definidos no nível de raiz.

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

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

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

Referenciar o nome simbólico do recurso filho funciona da mesma forma que referenciar o pai.

Nome completo do recurso fora do pai

Você também pode usar o nome e o tipo completo do recurso ao declarar o recurso filho fora do pai. Você não define a propriedade do pai no recurso filho. Como a dependência não pode ser inferida, você deve defini-la explicitamente.

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

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

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

Importante

Definir o nome e o tipo de recurso completo não é a abordagem recomendada. Ela não é tão segura quanto usar uma das outras abordagens. Para obter mais informações, consulte aRegra de Linter: use a propriedade pai.

Próximas etapas