Definiera underordnade resurser

5 minuter

Det är klokt att distribuera vissa resurser endast inom ramen för deras överordnade. Dessa resurser kallas underordnade resurser. Det finns många underordnade resurstyper i Azure. Några exempel:

Name	Resurstyp
Undernät för virtuellt nätverk	`Microsoft.Network/virtualNetworks/subnets`
App Service-konfiguration	`Microsoft.Web/sites/config`
SQL-databaser	`Microsoft.Sql/servers/databases`
Tillägg för virtuella datorer	`Microsoft.Compute/virtualMachines/extensions`
Lagringsblobcontainrar	`Microsoft.Storage/storageAccounts/blobServices/containers`
Azure Cosmos DB-containrar	`Microsoft.DocumentDB/databaseAccounts/sqlDatabases/containers`

Låt oss till exempel överväga en lagringsblobcontainer. En blobcontainer måste distribueras till ett lagringskonto och det är inte meningsfullt att en container finns utanför ett lagringskonto.

Underordnade resurstyper har längre namn med flera delar till sig. En lagringsblobcontainer har det här fullständigt kvalificerade typnamnet: Microsoft.Storage/storageAccounts/blobServices/containers. Resurs-ID:t för en blobcontainer innehåller namnet på lagringskontot som innehåller containern och containerns namn.

Kommentar

Vissa underordnade resurser kan ha samma namn som andra underordnade resurstyper från olika överordnade. Är till exempel containers en underordnad typ av både lagringskonton och Azure Cosmos DB-databaser. Namnen är desamma, men de representerar olika resurser och deras fullständigt kvalificerade typnamn skiljer sig åt.

Hur definieras underordnade resurser?

Med Bicep kan du deklarera underordnade resurser på flera olika sätt. Varje sätt har sina egna fördelar, och var och en är lämplig för vissa situationer och inte för andra. Nu ska vi titta på varje metod.

Dricks

Alla följande metoder resulterar i samma distributionsaktiviteter i Azure. Du kan välja den metod som bäst passar dina behov utan att behöva oroa dig för att bryta något. Och du kan uppdatera mallen och ändra den metod som du använder.

Kapslade resurser

En metod för att definiera en underordnad resurs är att kapsla den underordnade resursen i den överordnade resursen. Här är ett exempel på en Bicep-mall som distribuerar en virtuell dator och ett tillägg för virtuella datorer. Ett tillägg för virtuella datorer är en underordnad resurs som ger extra beteende för en virtuell dator. I det här fallet kör tillägget ett anpassat skript på den virtuella datorn efter distributionen.

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

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

Observera att den kapslade resursen har en enklare resurstyp än normalt. Även om det fullständigt kvalificerade typnamnet är Microsoft.Compute/virtualMachines/extensions, ärver den kapslade resursen automatiskt den överordnade resurstypen, så du behöver bara ange den underordnade resurstypen, extensions.

Observera också att ingen API-version har angetts för den kapslade resursen. Bicep förutsätter att du vill använda samma API-version som den överordnade resursen, även om du kan åsidosätta API-versionen om du vill.

Du kan referera till en kapslad resurs med hjälp av operatorn :: . Du kan till exempel skapa utdata som returnerar det fullständiga resurs-ID:t för tillägget:

output childResourceId string = vm::installCustomScriptExtension.id

Kapsling av resurser är ett enkelt sätt att deklarera en underordnad resurs. Kapslingsresurser gör även relationen mellan överordnad och underordnad uppenbar för alla som läser mallen. Men om du har många kapslade resurser eller flera kapslingslager kan mallar bli svårare att läsa. Du kan också kapsla resurser endast upp till fem lager djupt.

Överordnad egenskap

En andra metod är att deklarera den underordnade resursen utan kapsling. Använd parent sedan egenskapen för att berätta för Bicep om relationen mellan överordnad och underordnad:

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

Observera att den underordnade resursen parent använder egenskapen för att referera till det symboliska namnet på den överordnade resursen.

Den här metoden för att referera till den överordnade är ett annat enkelt sätt att deklarera en underordnad resurs. Bicep förstår relationen mellan överordnade och underordnade resurser, så du behöver inte ange det fullständigt kvalificerade resursnamnet eller konfigurera ett beroende mellan resurserna. Metoden undviker också att ha för mycket kapsling, vilket kan bli svårt att läsa. Du måste dock uttryckligen ange den fullständiga resurstypen och API-versionen varje gång du definierar en underordnad resurs med hjälp av parent egenskapen .

Om du vill referera till en underordnad resurs som deklarerats parent med egenskapen använder du dess symboliska namn som med en normal överordnad resurs:

output childResourceId string = installCustomScriptExtension.id

Skapa resursnamnet

Det finns vissa omständigheter där du inte kan använda kapslade resurser eller nyckelordet parent . Exempel är när du deklarerar underordnade resurser i en for loop eller när du behöver använda komplexa uttryck för att dynamiskt välja en överordnad resurs för ett underordnat objekt. I dessa situationer kan du distribuera en underordnad resurs genom att manuellt konstruera det underordnade resursnamnet så att det innehåller dess överordnade resursnamn, enligt följande:

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

Observera att det här exemplet använder stränginterpolation för att lägga till resursegenskapen name för den virtuella datorn i det underordnade resursnamnet. Bicep förstår att det finns ett beroende mellan dina underordnade och överordnade resurser. Du kan deklarera det underordnade resursnamnet med hjälp av variabeln vmName i stället. Om du gör det kan distributionen eventuellt misslyckas eftersom Bicep inte förstår att den överordnade resursen måste distribueras före den underordnade resursen:

För att lösa den här situationen kan du manuellt berätta för Bicep om beroendet med hjälp av nyckelordet dependsOn , som du ser här:

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

Dricks

Det är vanligtvis bäst att undvika att skapa resursnamn, eftersom du förlorar många av de fördelar som Bicep kan ge när det förstår relationerna mellan dina resurser. Använd bara det här alternativet när du inte kan använda någon av de andra metoderna för att deklarera underordnade resurser.

Underordnade resurs-ID:t

Du börjar skapa ett underordnat resurs-ID genom att inkludera dess överordnade resurs-ID och sedan lägga till den underordnade resurstypen och namnet. Låt oss till exempel överväga ett Azure Cosmos DB-konto med namnet toyrnd. Azure Cosmos DB-resursprovidern exponerar en typ med namnet databaseAccounts, som är den överordnade resurs som du distribuerar:

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

Här är en visuell skildring av samma resurs-ID:

Resurs-ID för ett Azure Cosmos DB-konto, delat med nyckel/värde-paret på en separat rad.

Om vi lägger till en databas i det här kontot kan vi använda den sqlDatabases underordnade resurstypen. Nu ska vi lägga till en databas med namnet FlightTests till vårt Azure Cosmos DB-konto och ta en titt på det underordnade resurs-ID:t:

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

Här är en visuell representation:

Underordnat resurs-ID för en Azure Cosmos DB-databas, delat med nyckel/värde-paret på en separat rad.

Du kan ha flera nivåer av underordnade resurser. Här är ett exempel på ett resurs-ID som visar ett lagringskonto med två underordnade nivåer:

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

Här är en visuell representation av samma resurs-ID:

Underordnat resurs-ID för ett lagringskonto med blobcontainer, delat med nyckel/värde-paret på en separat rad.

Det här resurs-ID:t har flera komponenter:

Allt upp till secrettoys är det överordnade resurs-ID:t.
blobServices anger att resursen ligger inom en underordnad resurstyp med namnet blobServices.

Kommentar

Du behöver inte skapa blobServices resurser själv. Resursprovidern Microsoft.Storage skapar automatiskt den här resursen åt dig när du skapar ett lagringskonto. Den här typen av resurs kallas ibland för en implicit resurs. De är ganska ovanliga, men du hittar dem i hela Azure.
default är namnet på den underordnade resursen blobServices .

Kommentar

Ibland tillåts endast en enda instans av en underordnad resurs. Den här typen av instans kallas för en singleton och får ofta namnet default.
containers anger att resursen ligger inom en underordnad resurstyp med namnet containers.
glitterspecs är namnet på blobcontainern.