Resursdeklaration i Bicep

  • Artikel
  • 6 minuter för att läsa

I den här artikeln beskrivs den syntax som du använder för att lägga till en resurs i bicep-filen.

Förklaring

Lägg till en resursdeklaration med hjälp av resource nyckelordet . Du anger ett symboliskt namn för resursen. Det symboliska namnet är inte samma som resursnamnet. Du använder det symboliska namnet för att referera till resursen i andra delar av bicep-filen.

resource <symbolic-name> '<full-type-name>@<api-version>' = {
  <resource-properties>
}

Därför kan en deklaration för ett lagringskonto börja med:

resource stg 'Microsoft.Storage/storageAccounts@2021-04-01' = {
  ...
}

Symboliska namn är fallkänsliga. De kan innehålla bokstäver, siffror och understreck ( _ ). De kan inte börja med ett tal. En resurs kan inte ha samma namn som en parameter, variabel eller modul.

Information om tillgängliga resurstyper och versioner finns i Bicep-resursreferens. Bicep stöder inte apiProfile , som finns i JSON Azure Resource Manager (ARM-mallar).

Om du vill distribuera en resurs villkorligt använder du if syntaxen . Mer information finns i Villkorlig distribution i Bicep.

resource <symbolic-name> '<full-type-name>@<api-version>' = if (condition) {
  <resource-properties>
}

Om du vill distribuera fler än en instans av en resurs använder du for syntaxen . Du kan använda batchSize målaren för att ange om instanserna ska distribueras seriellt eller parallellt. Mer information finns i Iterativa loopar i Bicep.

@batchSize(int) // optional decorator for serial deployment
resource <symbolic-name> '<full-type-name>@<api-version>' = [for <item> in <collection>: {
  <properties-to-repeat>
}]

Du kan också använda for syntaxen för resursegenskaperna för att skapa en matris.

resource <symbolic-name> '<full-type-name>@<api-version>' = {
  properties: {
    <array-property>: [for <item> in <collection>: <value-to-repeat>]
  }
}

Resursnamn

Varje resurs har ett namn. När du anger resursnamnet bör du vara uppmärksam på reglerna och begränsningarna för resursnamn .

resource stg 'Microsoft.Storage/storageAccounts@2019-06-01' = {
  name: 'examplestorage'
  ...
}

Vanligtvis anger du namnet till en parameter så att du kan skicka olika värden under distributionen.

@minLength(3)
@maxLength(24)
param storageAccountName string

resource stg 'Microsoft.Storage/storageAccounts@2019-06-01' = {
  name: storageAccountName
  ...
}

Location

Många resurser kräver en plats. Du kan avgöra om resursen behöver en plats antingen via IntelliSense eller mallreferensen. I följande exempel läggs en platsparameter till som används för lagringskontot.

resource stg 'Microsoft.Storage/storageAccounts@2019-06-01' = {
  name: 'examplestorage'
  location: 'eastus'
  ...
}

Vanligtvis anger du plats till en parameter så att du kan distribuera till olika platser.

param location string = resourceGroup().location

resource stg 'Microsoft.Storage/storageAccounts@2019-06-01' = {
  name: 'examplestorage'
  location: location
  ...
}

Olika resurstyper stöds på olika platser. Information om hur du hämtar de platser som stöds för en Azure-tjänst finns i Produkt tillgängliga efter region. Om du vill hämta platser som stöds för en resurstyp använder du Azure PowerShell eller Azure CLI.

((Get-AzResourceProvider -ProviderNamespace Microsoft.Batch).ResourceTypes `
  | Where-Object ResourceTypeName -eq batchAccounts).Locations

Taggar

Du kan använda taggar för en resurs under distributionen. Taggar hjälper dig att organisera dina distribuerade resurser logiskt. Exempel på olika sätt att ange taggarna finns i ARM-malltaggar.

Hanterade identiteter för Azure-resurser

Vissa resurser stöder hanterade identiteter för Azure-resurser. Dessa resurser har ett identitetsobjekt på resursdeklarationens rotnivå.

Du kan använda system-tilldelade eller användar tilldelade identiteter.

I följande exempel visas hur du konfigurerar en system tilldelad identitet för Azure Kubernetes Service kluster.

resource aks 'Microsoft.ContainerService/managedClusters@2020-09-01' = {
  name: clusterName
  location: location
  tags: tags
  identity: {
    type: 'SystemAssigned'
  }

I nästa exempel visas hur du konfigurerar en användar tilldelad identitet för en virtuell dator.

param userAssignedIdentity string

resource vm 'Microsoft.Compute/virtualMachines@2020-06-01' = {
  name: vmName
  location: location
  identity: {
    type: 'UserAssigned'
    userAssignedIdentities: {
      '${userAssignedIdentity}': {}
    }
  }

Resursspecifika egenskaper

Föregående egenskaper är allmänna för de flesta resurstyper. När du har angett dessa värden måste du ange de egenskaper som är specifika för den resurstyp som du distribuerar.

Använd IntelliSense- eller Bicep-resursreferens för att avgöra vilka egenskaper som är tillgängliga och vilka som krävs. I följande exempel anges de återstående egenskaperna för ett lagringskonto.

resource stg 'Microsoft.Storage/storageAccounts@2019-06-01' = {
  name: 'examplestorage'
  location: 'eastus'
  sku: {
    name: 'Standard_LRS'
    tier: 'Standard'
  }
  kind: 'StorageV2'
  properties: {
    accessTier: 'Hot'
  }
}

Beroenden

När du distribuerar resurser kan du behöva kontrollera att vissa resurser finns före andra resurser. Du behöver till exempel en logisk server SQL innan du distribuerar en databas. Du upprättar den här relationen genom att markera en resurs som beroende av den andra resursen. Ordningen på resursdistributionen kan påverkas på två sätt: implicit beroende och explicit beroende

Azure Resource Manager utvärderar beroenden mellan resurser och distribuerar dem i beroende ordning. När resurserna inte är beroende av varandra distribuerar Resource Manager dem parallellt. Du behöver bara definiera beroenden för resurser som distribueras i samma Bicep-fil.

Implicit beroende

Ett implicit beroende skapas när en resursdeklaration refererar till en annan resurs i samma distribution. DnsZone refereras till exempel av den andra resursdefinitionen i följande exempel:

resource dnsZone 'Microsoft.Network/dnszones@2018-05-01' = {
  name: 'myZone'
  location: 'global'
}

resource otherResource 'Microsoft.Example/examples@2020-06-01' = {
  name: 'exampleResource'
  properties: {
    // get read-only DNS zone property
    nameServers: dnsZone.properties.nameServers
  }
}

En kapslad resurs har också ett implicit beroende på dess innehållande resurs.

resource myParent 'My.Rp/parentType@2020-01-01' = {
  name: 'myParent'
  location: 'West US'

  // depends on 'myParent' implicitly
  resource myChild 'childType' = {
    name: 'myChild'
  }
}

När det finns ett implicit beroende ska du inte lägga till ett explicit beroende.

Mer information om kapslade resurser finns i Ange namn och typ för underordnade resurser i Bicep.

Explicit beroende

Ett explicit beroende deklareras med dependsOn egenskapen . Egenskapen accepterar en matris med resursidentifierare, så du kan ange fler än ett beroende.

I följande exempel visas en DNS-zon med otherZone namnet som är beroende av en DNS-zon med namnet dnsZone :

resource dnsZone 'Microsoft.Network/dnszones@2018-05-01' = {
  name: 'demoeZone1'
  location: 'global'
}

resource otherZone 'Microsoft.Network/dnszones@2018-05-01' = {
  name: 'demoZone2'
  location: 'global'
  dependsOn: [
    dnsZone
  ]
}

Även om du kanske är frestad att använda för att mappa relationer mellan dina resurser, är det dependsOn viktigt att förstå varför du gör det. Att till exempel dokumentera hur resurser är sammankopplade dependsOn är inte rätt metod. Du kan inte fråga vilka resurser som definierades i dependsOn elementet efter distributionen. Att ange onödiga beroenden gör distributionstiden långsammare eftersom Resource Manager inte kan distribuera resurserna parallellt.

Även om explicita beroenden ibland krävs är behovet av dem ovanligt. I de flesta fall kan du använda ett symboliskt namn för att ange beroendet mellan resurser. Om du ställer in explicita beroenden bör du överväga om det finns något sätt att ta bort det.

Visualisera beroenden

Visual Studio Code är ett verktyg för att visualisera beroendena. Öppna en Bicep-fil Visual Studio Kod och välj sedan visualiseringsknappen i det övre vänstra hörnet. Följande skärmbild visar beroenden för en virtuell dator.

Skärmbild av Visual Studio Code Bicep-resurs visualiserare

Befintliga resurser

Om du vill referera till en resurs som ligger utanför den aktuella Bicep-filen använder du existing nyckelordet i en resursdeklaration.

När du använder existing nyckelordet anger name du för resursen. I följande exempel hämtar ett befintligt lagringskonto i samma resursgrupp som den aktuella distributionen.

resource stg 'Microsoft.Storage/storageAccounts@2019-06-01' existing = {
  name: 'examplestorage'
}

output blobEndpoint string = stg.properties.primaryEndpoints.blob

Du kan också ange egenskapen för scope att få åtkomst till en resurs i ett annat omfång. I följande exempel refereras ett befintligt lagringskonto i en annan resursgrupp.

resource stg 'Microsoft.Storage/storageAccounts@2019-06-01' existing = {
  name: 'examplestorage'
  scope: resourceGroup(exampleRG)
}

output blobEndpoint string = stg.properties.primaryEndpoints.blob

Om du försöker referera till en resurs som inte finns får du NotFound felet och distributionen misslyckas.

Mer information om hur du anger omfånget finns i Omfångsfunktioner för Bicep.

Föregående exempel distribuerar inte lagringskontot. I stället kan du komma åt egenskaper för den befintliga resursen med hjälp av det symboliska namnet.

Nästa steg