Compartilhar via

Definir o nome e o tipo dos recursos filhos no Bicep

Recursos filhos 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 recursos está disponível na referência de recurso Bicep.

Este artigo mostra diferentes maneiras de declarar um recurso filho.

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, continue repetindo os nomes dos pais:

{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 um a mais 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 no tipo de recurso pai, formata-se 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 para default e seu tipo é definido para fileServices. O nome do compartilhamento de arquivos está definido exampleshare e seu tipo é definido como shares.

resource storage 'Microsoft.Storage/storageAccounts@2025-06-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 da API usando a sintaxe <segment>@<version>. Caso o recurso aninhado omita a versão da API, será utilizada a versão da API do recurso pai. Se o recurso aninhado especificar uma versão da API, a versão da 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 não pode acessar as propriedades dos recursos que ele contém, pois isso 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ê poderá usar essa abordagem se o recurso pai não estiver 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 definidos no nível raiz.

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

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

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

Fazer referência ao nome simbólico do recurso filho opera da mesma forma que fazer referência ao 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@2025-06-01' = {
  name: 'examplestorage'
  location: resourceGroup().location
  kind: 'StorageV2'
  sku: {
    name: 'Standard_LRS'
  }
}

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

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

Importante

Definir o nome e o tipo de recurso completos 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

  • Last updated on