Определение дочерних ресурсов

Завершено

Некоторые ресурсы имеет смысл развертывать только в контексте их родительского ресурса. Эти ресурсы называются дочерними ресурсами. В Azure существует множество дочерних ресурсов. Вот несколько таких случаев.

Имя. Тип ресурса
Подсети виртуальной сети Microsoft.Network/virtualNetworks/subnets
Конфигурация Службы приложений Microsoft.Web/sites/config
базы данных SQL; Microsoft.Sql/servers/databases
Расширения виртуальных машин Microsoft.Compute/virtualMachines/extensions
Контейнеры BLOB-объектов в службе хранилища Microsoft.Storage/storageAccounts/blobServices/containers
Контейнеры Azure Cosmos DB Microsoft.DocumentDB/databaseAccounts/sqlDatabases/containers

Например, рассмотрим контейнер BLOB-объектов в службе хранилища. Контейнер BLOB-объектов должен быть развернут в учетной записи хранения, и не имеет смысла размещать контейнер за ее пределами.

Типы дочерних ресурсов имеют более длинные имена и состоят из нескольких компонентов. Полное имя типа контейнера BLOB-объектов в службе хранилища: Microsoft.Storage/storageAccounts/blobServices/containers. Идентификатор ресурса для контейнера BLOB-объектов включает в себя имя учетной записи хранения, содержащей контейнер, и имя контейнера.

Примечание.

Некоторые типы дочерних ресурсов могут иметь одинаковые имена, но относиться к разным родительским ресурсам. Например, containers является дочерним типом для учетных записей хранения и баз данных Azure Cosmos DB. Имена совпадают, но они представляют разные ресурсы, а их полные имена типов различаются.

Как определяются дочерние ресурсы?

С помощью Bicep можно объявить дочерние ресурсы несколькими способами. Каждый способ имеет свои преимущества, и каждый из них подходит для одних ситуаций, но не подходит для других. Давайте рассмотрим каждый подход.

Совет

Все приведенные ниже подходы обеспечивают одинаковые действия по развертыванию в Azure. Вы можете выбрать подход, который лучше всего соответствует вашим потребностям, не беспокоясь о том, что что-то пойдет не так. Вы всегда можете обновить шаблон и изменить подход, который вы используете.

Вложенные ресурсы

Одним из способов определения дочернего ресурса является вложение дочернего ресурса в родительский ресурс. Ниже приведен пример шаблона Bicep, который развертывает виртуальную машину и расширение виртуальной машины. Расширение виртуальной машины — это дочерний ресурс, обеспечивающий дополнительные операции для виртуальной машины. В этом случае расширение запускает настраиваемый скрипт на виртуальной машине после развертывания.

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

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

Обратите внимание на то, что вложенный ресурс имеет более простой тип ресурса, чем обычный ресурс. Хотя полное имя типа — Microsoft.Compute/virtualMachines/extensions, вложенный ресурс автоматически наследует тип родительского ресурса, поэтому необходимо указать только тип дочернего ресурса, extensions.

Также обратите внимание на то, что для вложенного ресурса не указана версия API. Bicep предполагает, что вы хотите использовать ту же версию API, что и для родительского ресурса, хотя вы можете переопределить версию API, если хотите.

Вы можете указать ссылку на вложенный ресурс с помощью оператора ::. Например, можно создать выходные данные, возвращающие полный идентификатор ресурса расширения:

output childResourceId string = vm::installCustomScriptExtension.id

Вложение ресурсов — это простой способ объявления дочерних ресурсов. Вложение ресурсов также делает связь между родительскими и дочерними ресурсами очевидной для любого пользователя, читающего шаблон. Однако при наличии большого количества вложенных ресурсов или нескольких уровней вложенности шаблоны могут оказаться трудными для чтения. Кроме того, вкладывать ресурсы можно только до пяти уровней.

Свойство parent

Второй подход — объявить дочерний ресурс без вложения. Затем используйте parent свойство, чтобы сообщить Bicep о связи родительского-дочернего объекта:

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: {
    // ...
  }
}

Обратите внимание на то, что дочерний ресурс использует свойство parent для указания символического имени своего родительского ресурса.

Данный подход с использованием ссылки на родительский объект — еще один простой способ объявления дочернего ресурса. Bicep понимает связь между родительским и дочерним ресурсами, поэтому вам не нужно указывать полное имя ресурса или задавать зависимость между этими ресурсами. Этот подход также позволяет избежать слишком большого количества вложений, которые могут усложнить чтение шаблона. Однако каждый раз при определении дочернего ресурса с помощью свойства parent необходимо явно указывать полный тип ресурса и версию API.

Чтобы ссылаться на дочерний ресурс, объявленный свойством parent , используйте его символьное имя, как и обычный родительский ресурс:

output childResourceId string = installCustomScriptExtension.id

Составление имени ресурса

В некоторых случаях невозможно использовать вложенные ресурсы или ключевое слово parent. Например, когда вы объявляете дочерние ресурсы в цикле for или когда необходимо использовать сложные выражения для динамического выбора родительского ресурса для дочернего ресурса. В таких ситуациях можно развернуть дочерний ресурс, вручную создав его имя, чтобы оно включало в себя имя родительского ресурса, как показано ниже:

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: {
    // ...
  }
}

Обратите внимание на то, что в этом примере используется интерполяция строк для добавления свойства name ресурса виртуальной машины к имени дочернего ресурса. Bicep понимает, что между дочерним и родительским ресурсами существует зависимость. Вместо этого можно объявить имя дочернего ресурса с помощью переменной vmName. Если это сделать, возможно, развертывание может завершиться ошибкой, так как Bicep не понимает, что родительский ресурс необходимо развернуть перед дочерним ресурсом:

Чтобы устранить эту ситуацию, можно вручную сообщить Bicep о зависимости с помощью dependsOn ключевое слово, как показано ниже:

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
  ]
  //...
}

Совет

Обычно лучше избегать составления имен ресурсов, так как вы теряете множество преимуществ, которые Bicep может предоставить, если понимает связи между ресурсами. Используйте этот вариант только в том случае, если невозможно использовать другой способ объявления дочерних ресурсов.

Идентификаторы дочерних ресурсов

Чтобы создать идентификатор дочернего ресурса, необходимо к идентификатору родительского ресурса добавить тип и имя дочернего ресурса. Например, рассмотрим учетную запись Azure Cosmos DB с именем toyrnd. Поставщик ресурсов Azure Cosmos DB предоставляет тип databaseAccounts, который использует развертываемый родительский ресурс:

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

Ниже приведено визуальное представление того же идентификатора ресурса:

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

Если мы добавим базу данных в эту учетную запись, можно использовать дочерний sqlDatabases тип ресурса. Давайте добавим базу данных FlightTests в нашу учетную запись Azure Cosmos DB и взглянем на идентификатор дочернего ресурса:

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

Вот его визуальное представление:

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

Можно определить несколько уровней дочерних ресурсов. Ниже приведен пример идентификатора ресурса, который содержит учетную запись хранения с двумя уровнями дочерних ресурсов:

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

Вот визуальное представление того же идентификатора ресурса:

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

Этот идентификатор ресурса содержит несколько компонентов:

  • Все до secrettoys — это идентификатор родительского ресурса.

  • blobServices указывает, что ресурс относится к типу дочернего ресурса blobServices.

    Примечание.

    Вам не нужно самостоятельно создавать ресурсы blobServices. Поставщик ресурсов Microsoft.Storage автоматически создает этот ресурс при создании учетной записи хранения. Этот тип ресурса иногда называют неявным ресурсом. Они не слишком распространены, но вы сможете найти их в Azure.

  • default — имя дочернего ресурса blobServices.

    Примечание.

    В некоторых случаях разрешается использовать только один экземпляр дочернего ресурса. Этот тип экземпляра называется отдельным, и ему часто присваивается имя default.

  • containers указывает, что ресурс относится к типу дочернего ресурса containers.

  • glitterspecs — имя контейнера BLOB-объектов.

При работе с дочерними ресурсами идентификаторы ресурсов могут стать длинными и сложными. Однако если вы разбиваете идентификатор ресурса на его компоненты, проще понять, как структурирован ресурс. Идентификатор ресурса также позволяет получить важные сведения о том, как именно ведет себя ресурс.