Определение дочерних ресурсов
Некоторые ресурсы имеет смысл развертывать только в контексте их родительского ресурса. Эти ресурсы называются дочерними ресурсами. В 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@2024-07-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@2024-07-01' = {
name: vmName
location: location
properties: {
// ...
}
}
resource installCustomScriptExtension 'Microsoft.Compute/virtualMachines/extensions@2024-07-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@2024-07-01' = {
name: vmName
location: location
properties: {
// ...
}
}
resource installCustomScriptExtension 'Microsoft.Compute/virtualMachines/extensions@2024-07-01' = {
name: '${vm.name}/InstallCustomScript'
location: location
properties: {
// ...
}
}
Обратите внимание на то, что в этом примере используется интерполяция строк для добавления свойства name
ресурса виртуальной машины к имени дочернего ресурса. Bicep понимает, что между дочерним и родительским ресурсами существует зависимость. Вместо этого можно объявить имя дочернего ресурса с помощью переменной vmName
. Если это сделать, возможно, развертывание может завершиться ошибкой, так как Bicep не понимает, что родительский ресурс необходимо развернуть перед дочерним ресурсом:
Чтобы устранить эту ситуацию, можно вручную сообщить Bicep о зависимости с помощью dependsOn
ключевое слово, как показано ниже:
resource vm 'Microsoft.Compute/virtualMachines@2024-07-01' = {
name: vmName
location: location
properties: {
// ...
}
}
resource installCustomScriptExtension 'Microsoft.Compute/virtualMachines/extensions@2024-07-01' = {
name: '${vmName}/InstallCustomScript'
dependsOn: [
vm
]
//...
}
Совет
Обычно лучше избегать составления имен ресурсов, так как вы теряете множество преимуществ, которые Bicep может предоставить, если понимает связи между ресурсами. Используйте этот вариант только в том случае, если невозможно использовать другой способ объявления дочерних ресурсов.
Идентификаторы дочерних ресурсов
Чтобы создать идентификатор дочернего ресурса, необходимо к идентификатору родительского ресурса добавить тип и имя дочернего ресурса. Например, рассмотрим учетную запись Azure Cosmos DB с именем toyrnd
. Поставщик ресурсов Azure Cosmos DB предоставляет тип databaseAccounts
, который использует развертываемый родительский ресурс:
/subscriptions/A123b4567c-1234-1a2b-2b1a-1234abc12345/resourceGroups/ToyDevelopment/providers/Microsoft.DocumentDB/databaseAccounts/toyrnd
Ниже приведено визуальное представление того же идентификатора ресурса:
Если мы добавим базу данных в эту учетную запись, можно использовать дочерний sqlDatabases
тип ресурса. Давайте добавим базу данных FlightTests
в нашу учетную запись Azure Cosmos DB и взглянем на идентификатор дочернего ресурса:
/subscriptions/A123b4567c-1234-1a2b-2b1a-1234abc12345/resourceGroups/ToyDevelopment/providers/Microsoft.DocumentDB/databaseAccounts/toyrnd/sqlDatabases/FlightTests
Вот его визуальное представление:
Можно определить несколько уровней дочерних ресурсов. Ниже приведен пример идентификатора ресурса, который содержит учетную запись хранения с двумя уровнями дочерних ресурсов:
/subscriptions/A123b4567c-1234-1a2b-2b1a-1234abc12345/resourceGroups/ToyDevelopment/providers/Microsoft.Storage/storageAccounts/secrettoys/blobServices/default/containers/glitterspecs
Вот визуальное представление того же идентификатора ресурса:
Этот идентификатор ресурса содержит несколько компонентов:
Все до
secrettoys
— это идентификатор родительского ресурса.blobServices
указывает, что ресурс относится к типу дочернего ресурсаblobServices
.Примечание.
Вам не нужно самостоятельно создавать ресурсы
blobServices
. Поставщик ресурсовMicrosoft.Storage
автоматически создает этот ресурс при создании учетной записи хранения. Этот тип ресурса иногда называют неявным ресурсом. Они не слишком распространены, но вы сможете найти их в Azure.default
— имя дочернего ресурсаblobServices
.Примечание.
В некоторых случаях разрешается использовать только один экземпляр дочернего ресурса. Этот тип экземпляра называется отдельным, и ему часто присваивается имя
default
.containers
указывает, что ресурс относится к типу дочернего ресурсаcontainers
.glitterspecs
— имя контейнера BLOB-объектов.
При работе с дочерними ресурсами идентификаторы ресурсов могут стать длинными и сложными. Однако если вы разбиваете идентификатор ресурса на его компоненты, проще понять, как структурирован ресурс. Идентификатор ресурса также позволяет получить важные сведения о том, как именно ведет себя ресурс.