Verbundene Ressourcen sind schwer zu pflegen? Verwende Referenzen und Abhängigkeiten

Das CloudTrips-Speicherkonto ist vorhanden, die Anwendung benötigt jedoch auch einen privaten Container für hochgeladene Dateien. Vollständige Ressourcennamen manuell zusammenzusetzen und eine separate Bereitstellungsreihenfolge zu pflegen, macht verbundene Ressourcen fehleranfällig.

Beschreibe diese Hierarchie mit Bicep-Referenzen:

Speicherkonto
└── Blob-Dienst: default
    └── Privater Container: uploads

Bicep leitet ab, dass das Speicherkonto vor dem Blob-Dienst und der Blob-Dienst vor dem Container vorhanden sein muss.

Container-Eingabe hinzufügen

Füge diesen Parameter zu main.bicep hinzu:

@description('Private blob container used for application uploads.')
@minLength(3)
@maxLength(63)
param containerName string = 'uploads'

Durch den Standardwert erhält jede Umgebung einen uploads-Container. Eine Parameterdatei kann den Wert später überschreiben, ohne die Ressourcendefinition zu ändern.

Verbundene Ressourcen hinzufügen

Füge diese Ressourcen nach storageAccount ein:

resource blobService 'Microsoft.Storage/storageAccounts/blobServices@2025-06-01' = {
  parent: storageAccount
  name: 'default'
  properties: {
    containerDeleteRetentionPolicy: {
      enabled: true
      days: 7
    }
    deleteRetentionPolicy: {
      enabled: true
      days: 7
    }
  }
}

resource uploadsContainer 'Microsoft.Storage/storageAccounts/blobServices/containers@2025-06-01' = {
  parent: blobService
  name: containerName
  properties: {
    publicAccess: 'None'
  }
}

Füge eine neue Ausgabe hinzu:

output containerId string = uploadsContainer.id

Die symbolischen Referenzen legen Beziehung und Reihenfolge fest:

• parent: storageAccount verbindet den Blob-Dienst mit dem Speicherkonto
• parent: blobService verbindet den Container mit dem Blob-Dienst
• uploadsContainer.id gibt die ID der bereitgestellten untergeordneten Ressource zurück

Ein expliziter dependsOn-Block ist nicht erforderlich. Da die untergeordneten Ressourcen ihre Parent-Ressourcen direkt referenzieren, erstellt Bicep die Abhängigkeiten automatisch.

Abgeleitete Abhängigkeiten ohne gespeichertes JSON untersuchen

Kompiliere die Bicep-Datei und zeige Ressourcen mit generierten Abhängigkeiten:

az bicep build \
  --file main.bicep \
  --stdout |
  jq '.resources[] | select(.dependsOn != null) | {type, dependsOn}'

Dieser Befehl erstellt keine JSON-Datei. --stdout übergibt das generierte ARM-JSON direkt an jq. jq filtert es und zeigt das Ergebnis im Terminal an.

Die gefilterte Terminalausgabe sollte zeigen, dass der Blob-Dienst vom Speicherkonto und der Container vom Blob-Dienst abhängt.

Verwende ein explizites dependsOn nur, wenn eine Ressource auf eine andere warten muss und Bicep diese Beziehung nicht aus einer symbolischen Referenz ableiten kann.

TEST-Änderung anzeigen

Wähle das CloudTrips-TEST-Abonnement:

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

Führe What-if mit der vorhandenen TEST-Parameterdatei aus:

az deployment group what-if \
  --resource-group rg-cloudtrips-bicep-test-weu \
  --parameters environments/test.bicepparam

Bestätige, dass die Vorschau das vorhandene Speicherkonto beibehält und die verbundenen Blob-Ressourcen vorschlägt. Der uploads-Container muss Folgendes besitzen:

publicAccess: None

Verbundene Ressourcen bereitstellen

Wende die geprüfte Bereitstellung an:

az deployment group create \
  --name deploy-cloudtrips-storage-test-dependencies \
  --resource-group rg-cloudtrips-bicep-test-weu \
  --parameters environments/test.bicepparam \
  --query "properties.{state:provisioningState,outputs:outputs}" \
  --output yaml

Bestätige den Status Succeeded und kopiere den zurückgegebenen containerId.

Untergeordnete Ressource überprüfen

Prüfe den Container über Azure Resource Manager mit der Ausgabe:

container_id="<containerId-Ausgabe>"

az resource show \
  --ids "$container_id" \
  --api-version 2025-06-01 \
  --query "{name:name,type:type,publicAccess:properties.publicAccess}" \
  --output table

Überprüfe:

Name: uploads
Type: Microsoft.Storage/storageAccounts/blobServices/containers
PublicAccess: None

Öffne im Azure-Portal das TEST-Speicherkonto und gehe zu:

Datenspeicher > Container

Bestätige, dass uploads vorhanden und die anonyme Zugriffsebene Privat ist.

Die verbundenen Ressourcen verwenden nun symbolische Referenzen statt wiederholter Ressourcennamen. Bicep verwaltet ihre Hierarchie und Bereitstellungsreihenfolge. Eine Änderung der Benennungsregel für das Speicherkonto erfordert daher keine Reparatur jedes untergeordneten Ressourcennamens.