Onderliggende resources definiëren

  • 5 minuten

Het is zinvol om bepaalde resources alleen binnen de context van het bovenliggende item te implementeren. Deze resources worden onderliggende resources genoemd. Er zijn veel onderliggende resourcetypen in Azure. Enkele voorbeelden:

Naam Brontype
Virtueel netwerk-subnetten Microsoft.Network/virtualNetworks/subnets
App Service-configuratie Microsoft.Web/sites/config
SQL-databases Microsoft.Sql/servers/databases
Extensies voor virtuele machines Microsoft.Compute/virtualMachines/extensions
Opslagblobcontainers Microsoft.Storage/storageAccounts/blobServices/containers
Azure Cosmos DB-containers Microsoft.DocumentDB/databaseAccounts/sqlDatabases/containers

Laten we bijvoorbeeld een opslagblobcontainer overwegen. Een blobcontainer moet worden geïmplementeerd in een opslagaccount en het is niet logisch dat een container buiten een opslagaccount bestaat.

Onderliggende resourcetypen hebben langere namen met meerdere onderdelen. Een opslagblobcontainer heeft deze volledig gekwalificeerde typenaam: Microsoft.Storage/storageAccounts/blobServices/containers. De resource-id voor een blobcontainer bevat de naam van het opslagaccount dat de container bevat en de naam van de container.

Notitie

Sommige onderliggende resources hebben mogelijk dezelfde naam als andere onderliggende resourcetypen van verschillende bovenliggende resources. Is bijvoorbeeld containers een onderliggend type opslagaccounts en Azure Cosmos DB-databases. De namen zijn hetzelfde, maar ze vertegenwoordigen verschillende resources en hun volledig gekwalificeerde typenamen zijn verschillend.

Hoe worden onderliggende resources gedefinieerd?

Met Bicep kunt u onderliggende resources op verschillende manieren declareren. Elke manier heeft zijn eigen voordelen en elk is geschikt voor sommige situaties en niet voor anderen. Laten we eens kijken naar elke benadering.

Tip

Alle volgende benaderingen resulteren in dezelfde implementatieactiviteiten in Azure. U kunt de aanpak kiezen die het beste bij uw behoeften past zonder dat u zich zorgen hoeft te maken over het breken van iets. En u kunt uw sjabloon bijwerken en de methode wijzigen die u gebruikt.

Geneste resources

Een benadering voor het definiëren van een onderliggende resource is het nesten van de onderliggende resource in het bovenliggende item. Hier volgt een voorbeeld van een Bicep-sjabloon waarmee een virtuele machine en een extensie voor virtuele machines worden geïmplementeerd. Een extensie voor virtuele machines is een onderliggende resource die extra gedrag biedt voor een virtuele machine. In dit geval voert de extensie na de implementatie een aangepast script uit op de virtuele machine.

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

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

U ziet dat de geneste resource een eenvoudiger resourcetype heeft dan normaal. Hoewel de volledig gekwalificeerde typenaam isMicrosoft.Compute/virtualMachines/extensions, neemt de geneste resource automatisch het resourcetype van het bovenliggende item over. U moet dus alleen het onderliggende resourcetype opgeven. extensions

U ziet ook dat er geen API-versie is opgegeven voor de geneste resource. Bicep gaat ervan uit dat u dezelfde API-versie als de bovenliggende resource wilt gebruiken, hoewel u desgewenst de API-versie kunt overschrijven.

U kunt naar een geneste resource verwijzen met behulp van de :: operator. U kunt bijvoorbeeld een uitvoer maken die de volledige resource-id van de extensie retourneert:

output childResourceId string = vm::installCustomScriptExtension.id

Het nesten van resources is een eenvoudige manier om een onderliggende resource te declareren. Het nesten van resources maakt ook de relatie tussen bovenliggende en onderliggende elementen duidelijk voor iedereen die de sjabloon leest. Als u echter veel geneste resources of meerdere nestlagen hebt, kunnen sjablonen moeilijker te lezen zijn. U kunt resources ook slechts tot vijf lagen diep nesten.

Bovenliggende eigenschap

Een tweede benadering is het declareren van de onderliggende resource zonder nesten. Gebruik vervolgens de parent eigenschap om Bicep te vertellen over de relatie tussen bovenliggende en onderliggende items:

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

U ziet dat de onderliggende resource de parent eigenschap gebruikt om te verwijzen naar de symbolische naam van de bovenliggende resource.

Deze benadering om naar het bovenliggende item te verwijzen, is een andere eenvoudige manier om een onderliggende resource te declareren. Bicep begrijpt de relatie tussen bovenliggende en onderliggende resources, dus u hoeft niet de volledig gekwalificeerde resourcenaam op te geven of een afhankelijkheid tussen de resources in te stellen. De aanpak voorkomt ook dat er te veel nesten is, wat moeilijk te lezen kan worden. U moet echter expliciet het volledige resourcetype en de API-versie opgeven telkens wanneer u een onderliggende resource definieert met behulp van de parent eigenschap.

Als u wilt verwijzen naar een onderliggende resource die is gedeclareerd met de parent eigenschap, gebruikt u de symbolische naam zoals u zou doen met een normale bovenliggende resource:

output childResourceId string = installCustomScriptExtension.id

De resourcenaam samenstellen

Er zijn enkele omstandigheden waarin u geen geneste resources of het parent trefwoord kunt gebruiken. Voorbeelden zijn wanneer u onderliggende resources binnen een for lus declareert of wanneer u complexe expressies moet gebruiken om dynamisch een bovenliggende resource voor een onderliggend item te selecteren. In deze situaties kunt u een onderliggende resource implementeren door handmatig de naam van de onderliggende resource samen te stellen, zodat deze de naam van de bovenliggende resource bevat, zoals hier wordt weergegeven:

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

In dit voorbeeld wordt tekenreeksinterpolatie gebruikt om de resource-eigenschap name van de virtuele machine toe te voegen aan de naam van de onderliggende resource. Bicep begrijpt dat er een afhankelijkheid is tussen uw kind en bovenliggende resources. U kunt in plaats daarvan de onderliggende resourcenaam declareren met behulp van de vmName variabele. Als u dit doet, kan uw implementatie echter mislukken omdat Bicep niet begrijpt dat de bovenliggende resource moet worden geïmplementeerd vóór de onderliggende resource:

Om deze situatie op te lossen, kunt u Bicep handmatig vertellen over de afhankelijkheid met behulp van het dependsOn trefwoord, zoals hier wordt weergegeven:

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

Tip

Het is over het algemeen het beste om resourcenamen te maken, omdat u veel voordelen verliest die Bicep kan bieden wanneer deze de relaties tussen uw resources begrijpt. Gebruik deze optie alleen als u geen van de andere benaderingen kunt gebruiken voor het declareren van onderliggende resources.

Onderliggende resource-id's

U begint met het maken van een onderliggende resource-id door de resource-id van het bovenliggende item op te slaan en vervolgens het onderliggende resourcetype en de naam toe te voegen. Laten we bijvoorbeeld een Azure Cosmos DB-account met de naam toyrndoverwegen. De Azure Cosmos DB-resourceprovider toont een type met de naam databaseAccounts, de bovenliggende resource die u implementeert:

/subscriptions/A123b4567c-1234-1a2b-2b1a-1234abc12345/resourceGroups/ToyDevelopment/providers/Microsoft.DocumentDB/databaseAccounts/toyrnd

Hier volgt een visuele weergave van dezelfde resource-id:

Resource-id voor een Azure Cosmos DB-account, gesplitst met het sleutel-waardepaar op een afzonderlijke regel.

Als we een database aan dit account toevoegen, kunnen we het sqlDatabases onderliggende resourcetype gebruiken. Laten we een database met de naam FlightTests toevoegen aan ons Azure Cosmos DB-account en de onderliggende resource-id bekijken:

/subscriptions/A123b4567c-1234-1a2b-2b1a-1234abc12345/resourceGroups/ToyDevelopment/providers/Microsoft.DocumentDB/databaseAccounts/toyrnd/sqlDatabases/FlightTests

Hier volgt een visuele weergave:

Onderliggende resource-id voor een Azure Cosmos DB-database, gesplitst met het sleutel-waardepaar op een afzonderlijke regel.

U kunt meerdere niveaus van onderliggende resources hebben. Hier volgt een voorbeeld van een resource-id met een opslagaccount met twee onderliggende niveaus:

/subscriptions/A123b4567c-1234-1a2b-2b1a-1234abc12345/resourceGroups/ToyDevelopment/providers/Microsoft.Storage/storageAccounts/secrettoys/blobServices/default/containers/glitterspecs

Hier volgt een visuele weergave van dezelfde resource-id:

Onderliggende resource-id voor een opslagaccount met blobcontainer, gesplitst met het sleutel-waardepaar op een afzonderlijke regel.

Deze resource-id heeft verschillende onderdelen:

  • Alles is secrettoys de bovenliggende resource-id.

  • blobServices geeft aan dat de resource zich binnen een onderliggend resourcetype bevindt met de naam blobServices.

    Notitie

    U hoeft zelf geen resources te maken blobServices . De Microsoft.Storage resourceprovider maakt deze resource automatisch voor u wanneer u een opslagaccount maakt. Dit type resource wordt ook wel een impliciete resource genoemd. Ze zijn vrij ongebruikelijk, maar u vindt ze overal in Azure.

  • default is de naam van de blobServices onderliggende resource.

    Notitie

    Soms is slechts één exemplaar van een onderliggende resource toegestaan. Dit type exemplaar wordt een singleton genoemd en wordt vaak de naam defaultgegeven.

  • containers geeft aan dat de resource zich binnen een onderliggend resourcetype bevindt met de naam containers.

  • glitterspecs is de naam van de blobcontainer.

Wanneer u met onderliggende resources werkt, kunnen resource-id's lang worden en er ingewikkeld uitzien. Als u echter een resource-id opsplitst in de onderdelen ervan, is het eenvoudiger om te begrijpen hoe de resource is gestructureerd. Een resource-id kan u ook belangrijke aanwijzingen geven over hoe de resource zich gedraagt.