Resources definiëren

  • 5 minuten

Bicep-sjablonen zijn de bestanden die u ontwerpt waarmee de Azure-resources worden gedefinieerd die moeten worden geïmplementeerd.

Uw speelgoedbedrijf moet u een herbruikbare Bicep-sjabloon maken voor productlanceringen. De sjabloon moet een Azure-opslagaccount en Azure-app Service-resources implementeren, die worden gebruikt voor de marketing van elk nieuw product tijdens de lancering.

In deze les leert u hoe u een resource definieert in een Bicep-sjabloon, hoe resourcenamen werken en hoe u resources kunt maken die zich met elkaar verhouden.

Notitie

De opdrachten in deze les worden weergegeven om concepten te illustreren. Voer de opdrachten nog niet uit. U oefent wat u hier binnenkort leert.

Een resource definiëren

Het belangrijkste wat u met Bicep-sjablonen gaat doen, is het definiëren van uw Azure-resources. Hier volgt een voorbeeld van hoe een typische resourcedefinitie eruitziet in Bicep. In dit voorbeeld wordt een opslagaccount gemaakt met de naam toylaunchstorage.

resource storageAccount 'Microsoft.Storage/storageAccounts@2023-05-01' = {
  name: 'toylaunchstorage'
  location: 'westus3'
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
  properties: {
    accessTier: 'Hot'
  }
}

Laten we eens kijken naar enkele belangrijke onderdelen van deze resourcedefinitie:

  • Het resource trefwoord aan het begin vertelt Bicep dat u een resource gaat definiëren.

  • Vervolgens geeft u de resource een symbolische naam. In het voorbeeld is storageAccountde symbolische naam van de resource. Symbolische namen worden in Bicep gebruikt om te verwijzen naar de resource, maar ze worden nooit weergegeven in Azure.

  • Microsoft.Storage/storageAccounts@2022-09-01is het resourcetype en de API-versie van de resource. Microsoft.Storage/storageAccounts vertelt Bicep dat u een Azure-opslagaccount declareren. De datum 2022-09-01 is de versie van de Azure Storage-API die Bicep gebruikt bij het maken van de resource.

    Tip

    Met de Bicep-extensie voor Visual Studio Code kunt u de resourcetypen en API-versies vinden voor de resources die u maakt. Als u bekend bent met ARM-sjablonen, moet u er rekening mee houden dat de API-versie ook overeenkomt met de versie die u daar zou gebruiken.

  • U moet een resourcenaam declareren. Dit is de naam die aan het opslagaccount wordt toegewezen in Azure. U stelt een resourcenaam in met behulp van het name trefwoord.

    Belangrijk

    Symbolische namen worden alleen gebruikt in de Bicep-sjabloon en worden niet weergegeven in Azure. Resourcenamen worden wel weergegeven in Azure.

  • Vervolgens stelt u andere details van de resource in, zoals de locatie, de SKU (prijscategorie) en het soort. Er zijn ook eigenschappen die u kunt definiëren die verschillen voor elk resourcetype. Verschillende API-versies kunnen ook verschillende eigenschappen introduceren. In dit voorbeeld stellen we de toegangslaag van het opslagaccount in op Hot.

Tip

Resourcenamen hebben vaak regels die u moet volgen, zoals maximale lengte, toegestane tekens en uniekheid in heel Azure. De vereisten voor resourcenamen verschillen voor elk Azure-resourcetype. Zorg ervoor dat u de naamgevingsbeperkingen en vereisten begrijpt voordat u ze aan uw sjabloon toevoegt.

Wat gebeurt er wanneer resources afhankelijk zijn van elkaar?

Een Bicep-sjabloon bevat meestal verschillende resources. Vaak hebt u een resource nodig om afhankelijk te zijn van een andere resource. Mogelijk moet u bepaalde gegevens uit de ene resource extraheren om een andere te kunnen definiëren. Als u een webtoepassing implementeert, moet u de serverinfrastructuur maken voordat u er een toepassing aan kunt toevoegen. Deze relaties worden afhankelijkheden genoemd.

U moet een App Service-app implementeren voor de sjabloon waarmee het speelgoedproduct kan worden gestart, maar om een App Service-app te maken, moet u eerst een App Service-plan maken. Het App Service-plan vertegenwoordigt de resources voor serverhosting en wordt gedeclareerd als in dit voorbeeld:

resource appServicePlan 'Microsoft.Web/serverFarms@2023-12-01' = {
  name: 'toy-product-launch-plan'
  location: 'westus3'
  sku: {
    name: 'F1'
  }
}

Deze resourcedefinitie vertelt Bicep dat u een App Service-plan met het resourcetype Microsoft.Web/serverFarmswilt implementeren. De planresource heeft de naam toy-product-launch-planen wordt geïmplementeerd in de regio VS - west 3. Er wordt een prijs-SKU van F1 gebruikt. Dit is de gratis laag van App Service.

Nu u het App Service-plan hebt gedeclareerd, is de volgende stap het declareren van de app:

resource appServiceApp 'Microsoft.Web/sites@2023-12-01' = {
  name: 'toy-product-launch-1'
  location: 'westus3'
  properties: {
    serverFarmId: appServicePlan.id
    httpsOnly: true
  }
}

Met deze sjabloon wordt Azure geïnstrueerd om de app te hosten op het plan dat u hebt gemaakt. U ziet dat de definitie van het plan de symbolische naam van het App Service-plan op deze regel bevat: serverFarmId: appServicePlan.id. Deze regel betekent dat Bicep de resource-id van het App Service-plan opkrijgt met behulp van de id eigenschap. Het zegt in feite: de serverfarm-id van deze app is de id van het App Service-plan dat eerder is gedefinieerd.

Tip

In Azure is een resource-id een unieke id voor elke resource. De resource-id bevat de Azure-abonnements-id, de naam van de resourcegroep en de resourcenaam, samen met enkele andere informatie.

Door de app-resource te declareren met een eigenschap die verwijst naar de symbolische naam van het plan, begrijpt Azure de impliciete afhankelijkheid tussen de App Service-app en het plan. Wanneer de resources worden geïmplementeerd, zorgt Azure ervoor dat het plan volledig wordt geïmplementeerd voordat de app wordt geïmplementeerd.