Einige Ressourcen liegen oberhalb der Ressourcengruppe? Bereitstellungsbereiche verwenden

Die CloudTrips-Storage-Vorlage beginnt auf Ressourcengruppenebene. Deshalb muss die Zielressourcengruppe bereits vorhanden sein. Wird sie separat mit az group create erstellt, kann Bicep die vollständige Umgebung noch immer nicht von Grund auf bereitstellen.

Eine Ressourcengruppe gehört zu einem Abonnement und nicht zu einer anderen Ressourcengruppe. Erstelle einen Einstiegspunkt auf Abonnementebene für diese höherrangige Ressource und stelle den vorhandenen Workload anschließend über ein Modul in der Ressourcengruppe bereit.

Bereichsgrenze verstehen

targetScope teilt Azure Resource Manager mit, wo eine Bicep-Bereitstellung beginnt und welche Ressourcentypen die Datei direkt deklarieren darf.

targetScope	Typische Verantwortung	Azure-CLI-Befehl
resourceGroup	Speicherkonten, Schlüsseltresore und Anwendungsressourcen	az deployment group
subscription	Ressourcengruppen und abonnementweite Governance	az deployment sub
managementGroup	Gemeinsame Governance für mehrere Abonnements	az deployment mg
tenant	Mandantenweite Ressourcen wie Verwaltungsgruppen	az deployment tenant

Eine Bicep-Datei hat genau einen Zielbereich. Ein Modul kann über seine Eigenschaft scope einen anderen Bereich ansprechen.

Einstiegspunkt für das Abonnement erstellen

Erstelle subscription.bicep neben main.bicep:

targetScope = 'subscription'

@allowed([
  'dev'
  'test'
  'prod'
])
param environment string

param location string = deployment().location
param resourceGroupName string
param storageSku string = 'Standard_LRS'
param owner string
param costCenter string
param containerNames array = [
  'uploads'
]
param deployAuditContainer bool = false
param applicationName string = 'CloudTrips'

var commonTags = {
  Application: applicationName
  CostCenter: costCenter
  Environment: toUpper(environment)
  ManagedBy: 'Bicep'
  Owner: owner
}

resource workloadResourceGroup 'Microsoft.Resources/resourceGroups@2025-04-01' = {
  name: resourceGroupName
  location: location
  tags: commonTags
}

module workload './main.bicep' = {
  name: '${deployment().name}-workload'
  scope: workloadResourceGroup
  params: {
    applicationName: applicationName
    containerNames: containerNames
    costCenter: costCenter
    deployAuditContainer: deployAuditContainer
    environment: environment
    location: location
    owner: owner
    storageSku: storageSku
  }
}

output resourceGroupId string = workloadResourceGroup.id
output storageAccountName string = workload.outputs.storageAccountName
output storageAccountId string = workload.outputs.storageAccountId
output blobEndpoint string = workload.outputs.blobEndpoint
output containerIds array = workload.outputs.containerIds
output auditContainerId string? = workload.outputs.?auditContainerId

Die Ressourcengruppe wird direkt deklariert, weil sie zum Abonnementbereich gehört. main.bicep bleibt auf die Ressourcengruppe ausgerichtet. Mit scope: workloadResourceGroup führt Azure dieses Modul innerhalb der Ressourcengruppe aus und erstellt zugleich eine implizite Abhängigkeit von ihr.

TEST-Bereichsparameter hinzufügen

Erstelle environments/test.subscription.bicepparam:

using '../subscription.bicep'

param environment = 'test'
param location = 'westeurope'
param resourceGroupName = 'rg-cloudtrips-bicep-test-weu'
param storageSku = 'Standard_LRS'
param owner = 'DmytroKlymenko@cloudtrips.onmicrosoft.com'
param costCenter = 'CC-TEST-100'
param containerNames = [
  'uploads'
  'exports'
]
param deployAuditContainer = true

Diese Datei verweist auf den neuen Abonnement-Einstiegspunkt und behält die TEST-Workload-Werte aus den vorherigen Trips bei.

Beide Bereiche validieren und in der Vorschau prüfen

Führe im Verzeichnis cloudtrips-bicep Folgendes aus:

az bicep lint \
  --file subscription.bicep

az bicep build-params \
  --file environments/test.subscription.bicepparam \
  --stdout > /dev/null

az account set \
  --subscription "<Name oder ID des CloudTrips-TEST-Abonnements>"

az deployment sub what-if \
  --name deploy-cloudtrips-test-scope \
  --location westeurope \
  --parameters environments/test.subscription.bicepparam

Da die TEST-Ressourcengruppe bereits vorhanden ist, sollte die Vorschau sie nur aktualisieren, wenn ihre Tags abweichen. Sie darf weder die Ressourcengruppe noch das Speicherkonto, den Blob-Dienst oder die Container löschen oder neu erstellen. Die im vorherigen Trip erkannten Standardwerte des Storage-Anbieters können weiterhin als What-if-Rauschen erscheinen.

Vom Abonnement aus bereitstellen

Führe die Abonnementbereitstellung aus:

az deployment sub create \
  --name deploy-cloudtrips-test-scope \
  --location westeurope \
  --parameters environments/test.subscription.bicepparam \
  --query "properties.{state:provisioningState,outputs:outputs}" \
  --output yaml

--location ist erforderlich, weil Azure die Metadaten einer Abonnementbereitstellung in einer Region speichert. Der Bereich ändert sich dadurch nicht. Wird derselbe Bereitstellungsname später erneut verwendet, muss auch derselbe Metadatenstandort verwendet werden.

Bestätige den Status Succeeded und dass die Ausgaben die Werte für Ressourcengruppe und Storage enthalten.

Bereitstellungskette überprüfen

Ein Befehl erstellt nun drei Bereitstellungseinträge:

1. deploy-cloudtrips-test-scope auf Abonnementebene
2. deploy-cloudtrips-test-scope-workload in der Ressourcengruppe
3. deploy-cloudtrips-test-scope-workload-storage für das Storage-Modul

Die Endungen stammen aus den name-Ausdrücken der Module. Die Einträge zeigen die Bereichswechsel; sie stellen nicht drei Kopien der Ressourcen bereit.

Prüfe die übergeordnete Bereitstellung:

az deployment sub show \
  --name deploy-cloudtrips-test-scope \
  --query "properties.provisioningState" \
  --output tsv

Liste anschließend die Ressourcengruppenbereitstellungen auf:

az deployment group list \
  --resource-group rg-cloudtrips-bicep-test-weu \
  --query "[?starts_with(name, 'deploy-cloudtrips-test-scope')].{name:name,state:properties.provisioningState}" \
  --output table

CloudTrips kann nun die Ressourcengruppengrenze und ihren Workload über einen Bicep-Einstiegspunkt bereitstellen. Ressourcen auf höherer Ebene bleiben im Abonnementbereich, während die vorhandenen Anwendungsressourcen weiterhin korrekt in ihrer Ressourcengruppe isoliert sind.