Итак, у меня есть файл развертывания бицепса, который создает подписку и передает идентификатор подписки в другой файл бицепса, который предназначен для области группы управления для развертывания группы ресурсов и другого ресурса.
когда я запускаю вопрос «что, если», чтобы увидеть изменения, я вижу только изменения в области файла бицепса, который развертывает подписку.
az deployment mg what-if --name 'name' --management-group-id '$(mgmtgroupid)' --location"$(location)" -- template-file '.A.bicep'
бицепс выглядит так
** А.бицепс**
targetScope = 'managementGroup'
module subAlias './modules/subscription.bicep' = {
name: 'create-${subscriptionAlias}'
params: {
billingAccount: billingAccount
subscriptionAlias: subscriptionAlias
subscriptionDisplayName: subscriptionDisplayName
subscriptionWorkload: environmentconfigurationMap[environment].subscriptionWorkload
}
}
module createResourceGroupStorage 'B.bicep' = {
name: 'nested-createResources-${subscriptionDisplayName}'
params:{
subID : subAlias.output.subscriptionID
}
Б.бицепс
targetScope = 'managementGroup'
{{other modules that deploy resourcesgroup and other resources}}
Ожидается, что изменения от вложенного развертывания произойдут в B.bicep, а не только в A.bicep.
пример приведен ниже, но это развертывание на уровне подписки.
ты действительно задействовал файлы своих бицепсов? не думаю, что это сработает успешно
Я сделал. Он работает отлично. На портале я вижу развертывания в соответствующих группах управления, группах ресурсов и т. д. Но когда я пытаюсь обновить свойство ресурса и запустить команду «что если», я не вижу изменений, которые должны быть внесены, и это вызывает беспокойство и ненадежный.
а что, если не очень надежно, если честно: stackoverflow.com/a/73760427/4167200
Привет @kossytony, если запустить команду az deployment mg what-if локально, результаты будут такими же?
@ Элвин, технически все должно быть то же самое. Но я попробую.
Привет @kossytony, да, я согласен. Сообщите нам результаты локального тестирования, чтобы помочь нам определить причину проблемы, поскольку вы обращаетесь к подсообществу Azure DevOps. Спасибо.
Привет @kossytony, в своем ответе ниже я воспроизвел вашу проблему с помощью некоторых упрощенных шаблонов. Проблема, скорее всего, не связана со средой агента конвейера Azure DevOps или областью авторизации подключения службы ARM. Надеюсь, полученные результаты помогут решить ваши проблемы, изложенные в этом посте. Спасибо.
@AlvinZhao-MSFT попробовал ответить, жестко запрограммировав субидентификатор в B.bicep, и это сработало. Теперь вопрос в том, как передать значение вывода модуля подписки в B.bicep в качестве значения параметра?
@kossytony, согласно вашему последующему запросу, могу ли я предположить, что вы решили создать новую подписку для 1-го развертывания, и после завершения 1-го фактического развертывания вы сможете получить фактический результат subID для предварительного просмотра другого развертывания с командой az deployment mg what if?
@kossytony, я обновил ответ на ваш вопрос, как передать значение вывода модуля подписки в B.bicep в качестве значения параметра. Надеюсь, это поможет решить проблему в этом посте. Удачи и хороших выходных.
Спасибо @AlvinZhao-MSFT.. И тебе хороших выходных. Я использую конвейер yaml, который сначала запускает задачу «что, если», а затем запускает задачу развертывания. Помните, что создание подписки происходит в том же бицепсе, в котором есть модуль, который использует идентификатор подписки при выполнении сценария «что, если».
@kossytony, вспомните информацию в моем ответе: команда what-if не может сгенерировать действительный субидентификатор для последующего модуля, поскольку она может только предварительно просмотреть развертывание, а не вносить какие-либо изменения в существующие ресурсы; однако для развертывания в B.bicep требуется действительный субидентификатор для предварительного просмотра, что является основной причиной проблемы, заключающейся в том, что вы не можете видеть новые ресурсы, которые будут развернуты, с учетом исходного шаблона бицепса. И еще раз обратите внимание, что это поведение одинаково, независимо от того, запускаете ли вы what-if в локальной PowerShell или в задаче конвейера.
Таким образом, из-за ограничений команды what-if вы не можете предварительно просмотреть развертывание нового подпроекта и других зависимых ресурсов в одном шаблоне. Нам необходимо получить действительный субидентификатор после успешного создания подписки, чтобы команда what-if могла просмотреть ресурсы, которые будут развернуты в B.bicep.
Именно поэтому я предложил вам рассмотреть возможность разделения рабочего процесса на два развертывания; запустить mg what-if для предварительного просмотра создания подпрограммы -> создать новую подпрограмму для первого развертывания и вывести subscriptionId; затем снова запустить mg what-if, передав значение вывода subscriptionId в качестве параметра subID для завершения последующего предварительного просмотра и развертывания. Я не настолько знаком с Azure CLI, как с Azure DevOps, но надеюсь, что полученные результаты могут помочь. Ваше здоровье.
@AlvinZhao-MSFT спасибо. вы указали мне правильное направление. ваше предложение решит мою проблему.


По вашему последующему запросу
Попробовал ответить, жестко закодировав
subIDв бицепсе, и это сработало; теперь вопрос в том, как передать значение вывода модуля подписки в B.bicep в качестве значения параметра?
Если вы предпочитаете инструмент Azure CLI, то после того, как вам удастся создать новую подписку с помощью модуля подписки, вы можете использовать команду az deployment mg show, чтобы получить действительные выходные данные subscriptionId из 1stARMDeployment-CreateNewSub, а затем передать их в B.bicep в качестве значения параметра для 2ndARMDeployment-CreateResourcesFromB.
Добавьте output subscriptionId string = subAlias.outputs.subscriptionId в A.bicep;
targetScope = 'managementGroup'
module subAlias './modules/subscription.bicep' = {
name: 'create-${subscriptionAlias}'
params: {
billingAccount: billingAccount
subscriptionAlias: subscriptionAlias
subscriptionDisplayName: subscriptionDisplayName
subscriptionWorkload: environmentconfigurationMap[environment].subscriptionWorkload
}
}
output subscriptionId string = subAlias.outputs.subscriptionId
PowerShell
$newSubID = $(az deployment mg show --name '1stARMDeployment-CreateNewSub' --management-group-id 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx' --query properties.outputs.subscriptionId.value)
az deployment mg what-if --name '2ndARMDeployment-CreateResourcesFromB' --management-group-id 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx' --location "southeast asia" --template-file 'B.bicep' --parameters subID=$newSubID
Судя по вашему описанию, мне удалось воспроизвести проблему через локальную PowerShell с помощью приведенных ниже примеров шаблонов бицепсов.
А.бицепс
param subscriptionDisplayName string = 'Azure Subscription ARM1'
param subscriptionAlias string = 'subARM1'
param billingAccount string = '/providers/Microsoft.Billing/billingAccounts/123456/enrollmentAccounts/654321'
param environment string = 'Prod'
param environmentconfigurationMap object= {
Prod: {
subscriptionWorkload: 'Production'
}
}
targetScope = 'managementGroup'
module subAlias './modules/subscription.bicep' = {
name: 'create-${subscriptionAlias}'
params: {
billingAccount: billingAccount
subscriptionAlias: subscriptionAlias
subscriptionDisplayName: subscriptionDisplayName
subscriptionWorkload: environmentconfigurationMap[environment].subscriptionWorkload
}
}
module createResourceGroupStorage 'B.bicep' = {
name: 'nested-createResources-${subscriptionDisplayName}'
params:{
subID : subAlias.outputs.subscriptionId // Require a valid subID
}
}
/modules/subscription.bicep
targetScope = 'managementGroup'
@description('BillingAccount used for subscription billing')
param billingAccount string
@description('Alias to assign to the subscription')
param subscriptionAlias string
@description('Display name for the subscription')
param subscriptionDisplayName string
@description('Workload type for the subscription')
param subscriptionWorkload string
resource alias 'Microsoft.Subscription/aliases@2020-09-01' = {
scope: tenant()
name: subscriptionAlias
properties: {
workload: subscriptionWorkload
displayName: subscriptionDisplayName
billingScope: billingAccount
}
}
output subscriptionId string = alias.properties.subscriptionId
Б.бицепс
targetScope = 'managementGroup'
@description('subscriptionId for the deployment')
param subID string
@description('Name of the resourceGroup, will be created in the same location as the deployment.')
param resourceGroupName string = 'rg-armdemo'
@description('Location for the deployments and the resources')
param location string = deployment().location
// deploy to the subscription and create the resourceGroup
module rg './modules/resourcegroup.bicep' = {
scope: subscription(subID)
name: 'create-${resourceGroupName}'
params: {
resourceGroupName: resourceGroupName
location: location
}
}
/modules/resourcegroup.bicep
targetScope = 'subscription'
@description('Name of the resourceGroup.')
param resourceGroupName string
param location string = deployment().location
resource rg 'Microsoft.Resources/resourceGroups@2021-04-01' = {
name: resourceGroupName
location: location
}
Если напрямую использовать строку subID вместо выходных данных восходящего модуля, команда what-if сможет просмотреть ресурсы, которые будут развернуты в B.bicep. Такое поведение является задуманным, поскольку команда what-if может только просматривать изменения в развертывании, а не вносить какие-либо изменения в существующие ресурсы. Кроме того, ресурс для развертывания в B.bicep требует использования действующего subID, а команда what-if не выводит такое значение.
Что касается проблемы Scope, она должна соответствовать области развертывания каждого развертываемого ресурса. Например, если использовать приведенный ниже шаблон C.bicep для создания новой группы управления, его область действия была такой же, как у новой подписки в A.bicep, но отличалась от области действия новой группы ресурсов в B.bicep.
В какой области авторизации было установлено подключение к службе ARM, подписка или группа управления? Используете ли вы задачу Azure CLI для развертывания шаблонов бицепсов? Можете ли вы поделиться минимальным воспроизводимым определением конвейера YAML и шаблонами бицепсов, чтобы помочь понять ваш рабочий процесс? пожалуйста, не забудьте удалить любую конфиденциальную или частную информацию, такую как токен, пароль, сертификат, IP-адрес и т. д., поскольку сообщество доступно всем. Спасибо.