Flexibiliteit toevoegen met behulp van parameters en variabelen

Voltooid

Sjablonen zijn krachtig vanwege hun herbruikbaarheid. U kunt Bicep gebruiken om sjablonen te schrijven die meerdere omgevingen of kopieën van uw resources implementeren.

Uw speelgoedbedrijf start regelmatig nieuwe producten en u moet de Bicep-sjablonen gebruiken om de Azure-resources te maken die nodig zijn voor elke productlancering. U moet voorkomen dat u vaste resourcenamen gebruikt. Veel typen Azure-resources hebben unieke namen nodig, dus het insluiten van namen in uw sjabloon betekent dat u de sjabloon niet opnieuw kunt gebruiken voor meerdere productlanceringen. U moet de resources ook op verschillende locaties implementeren, afhankelijk van waar het speelgoed wordt gestart. Dit betekent dat u de resourcelocaties niet in uw sjabloon kunt insluiten.

In deze les krijgt u informatie over parameters en variabelen. Dit zijn twee Bicep-functies waarmee uw sjablonen flexibel en herbruikbaar kunnen worden. U krijgt ook kennis met expressies.

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.

Parameters en variabelen

Met een parameter kunt u waarden van buiten het sjabloonbestand ophalen. Als u de sjabloon bijvoorbeeld handmatig implementeert met behulp van de Azure CLI of Azure PowerShell, wordt u gevraagd waarden op te geven voor elke parameter. U kunt ook een parameterbestand maken, waarin alle parameters en waarden worden vermeld die u voor de implementatie wilt gebruiken. Als de sjabloon wordt geïmplementeerd vanuit een geautomatiseerd proces zoals een implementatiepijplijn, kan de pijplijn de parameterwaarden opgeven.

Er wordt een variabele gedefinieerd en ingesteld in de sjabloon. Met variabelen kunt u belangrijke informatie op één plaats opslaan en ernaar verwijzen in de sjabloon zonder deze te hoeven kopiëren en plakken.

Het is meestal een goed idee om parameters te gebruiken voor zaken die tussen elke implementatie veranderen, zoals:

• Resourcenamen die uniek moeten zijn.
• Locaties waarin de resources moeten worden geïmplementeerd.
• Instellingen die van invloed zijn op de prijzen van resources, zoals hun SKU's, prijscategorieën en aantal exemplaren.
• Referenties en informatie die nodig zijn voor toegang tot andere systemen die niet in de sjabloon zijn gedefinieerd.

Variabelen zijn meestal een goede optie wanneer u voor elke implementatie dezelfde waarden gebruikt, maar u een waarde herbruikbaar wilt maken in de sjabloon of wanneer u expressies wilt gebruiken om een complexe waarde te maken. U kunt ook variabelen gebruiken voor resources die geen unieke namen nodig hebben.

Tip

Het is belangrijk om goede naamgeving te gebruiken voor parameters en variabelen, zodat uw sjablonen gemakkelijk te lezen en te begrijpen zijn. Zorg ervoor dat u duidelijke, beschrijvende en consistente namen gebruikt.

Een parameter toevoegen

In Bicep kunt u een parameter als volgt definiëren:

param appServiceAppName string

Laten we eens kijken hoe elk onderdeel van deze definitie werkt:

• param vertelt Bicep dat u een parameter definieert.
• appServiceAppName is de naam van de parameter. Als u de sjabloon handmatig implementeert, wordt u mogelijk gevraagd een waarde in te voeren, dus het is belangrijk dat de naam duidelijk en begrijpelijk is. De naam is ook hoe u verwijst naar de parameterwaarde in de sjabloon, net zoals bij symbolische namen van resources.
• string is het type van de parameter. U kunt verschillende typen opgeven voor Bicep-parameters, waaronder string voor tekst, int voor getallen en bool voor Booleaanse waarden waar of onwaar. U kunt ook complexere parameters doorgeven met behulp van de array en object typen.

Tip

Probeer sjablonen niet te generaliseren met te veel parameters. U moet het minimale aantal parameters gebruiken dat u nodig hebt voor uw bedrijfsscenario. Houd er rekening mee dat u sjablonen in de toekomst altijd kunt wijzigen als uw vereisten veranderen.

Standaardwaarden opgeven

U kunt desgewenst een standaardwaarde opgeven voor een parameter. Wanneer u een standaardwaarde opgeeft, wordt de parameter optioneel. De persoon die de sjabloon implementeert, kan desgewenst een waarde opgeven, maar als dat niet zo is, gebruikt Bicep de standaardwaarde.

U kunt als volgt een standaardwaarde toevoegen:

param appServiceAppName string = 'toy-product-launch-1'

Notitie

In dit voorbeeld heeft de naam van de Azure-app Service-app een in code vastgelegde standaardwaarde. Dit is geen goed idee, omdat App Service-apps unieke namen nodig hebben. U lost dit binnenkort op.

Parameterwaarden gebruiken in de sjabloon

Nadat u een parameter hebt gedeclareerd, kunt u ernaar verwijzen in de rest van de sjabloon. Laten we eens kijken hoe u de nieuwe parameter in de resourcedefinitie kunt gebruiken:

resource appServiceApp 'Microsoft.Web/sites@2023-12-01' = {
  name: appServiceAppName
  location: 'eastus'
  properties: {
    serverFarmId: appServicePlan.id
    httpsOnly: true
  }
}

U ziet dat de sjabloon nu de parameterwaarde gebruikt om de resourcenaam voor de app-resource in te stellen in plaats van een in code vastgelegde waarde.

Tip

In de Bicep-extensie voor Visual Studio Code ziet u visuele indicatoren om u te laten weten wanneer u geen aanbevolen procedures volgt. U wordt bijvoorbeeld gewaarschuwd als u een parameter definieert die u niet gebruikt. De Bicep linter voert deze controles continu uit terwijl u werkt.

Een variabele toevoegen

U kunt een variabele als volgt definiëren:

var appServicePlanName = 'toy-product-launch-plan'

Variabelen worden op een vergelijkbare manier gedefinieerd als parameters, maar er zijn enkele verschillen:

• Gebruik het var trefwoord om Bicep te laten weten dat u een variabele declareren.
• U moet een waarde opgeven voor een variabele.
• Variabelen hebben geen typen nodig. Bicep kan het type bepalen op basis van de waarde die u instelt.

Expressies

Wanneer u sjablonen schrijft, wilt u vaak geen codewaarden gebruiken of zelfs vragen of ze moeten worden opgegeven in een parameter. In plaats daarvan wilt u waarden detecteren wanneer de sjabloon wordt uitgevoerd. U wilt bijvoorbeeld waarschijnlijk alle resources in een sjabloon implementeren in één Azure-regio: de regio waarin u de resourcegroep hebt gemaakt. U kunt ook automatisch een unieke naam voor een resource maken op basis van een bepaalde naamgevingsstrategie die uw bedrijf gebruikt.

Expressies in Bicep zijn een krachtige functie waarmee u allerlei interessante scenario's kunt afhandelen. Laten we eens kijken naar een aantal plaatsen waar u expressies in een Bicep-sjabloon kunt gebruiken.

Resourcelocaties

Wanneer u een sjabloon schrijft en implementeert, hoeft u vaak niet de locatie van elke resource afzonderlijk op te geven. In plaats daarvan hebt u mogelijk een eenvoudige bedrijfsregel die standaard alle resources implementeert op dezelfde locatie waarop de resourcegroep is gemaakt.

In Bicep kunt u een parameter maken met de naam locationen vervolgens een expressie gebruiken om de waarde ervan in te stellen:

param location string = resourceGroup().location

Bekijk de standaardwaarde van die parameter. Er wordt een functie gebruikt resourceGroup() die u toegang geeft tot informatie over de resourcegroep waarin de sjabloon wordt geïmplementeerd. In dit voorbeeld gebruikt de sjabloon de location eigenschap. Het is gebruikelijk om deze benadering te gebruiken om uw resources te implementeren in dezelfde Azure-regio als de resourcegroep.

Als iemand deze sjabloon implementeert, kan de gebruiker ervoor kiezen om hier de standaardwaarde te overschrijven en een andere locatie te gebruiken.

Notitie

Sommige resources in Azure kunnen alleen op bepaalde locaties worden geïmplementeerd. Mogelijk hebt u afzonderlijke parameters nodig om de locaties van deze resources in te stellen.

U kunt nu de resourcelocatieparameter in de sjabloon gebruiken, zoals deze:

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

Resourcenamen

Veel Azure-resources hebben unieke namen nodig. In uw scenario hebt u twee resources die unieke namen nodig hebben: het opslagaccount en de App Service-app. Als u vraagt om deze waarden in te stellen als parameters, kan het lastig zijn voor wie de sjabloon gebruikt, omdat ze een naam moeten vinden die niemand anders heeft gebruikt.

Bicep heeft een andere functie uniqueString() die handig is wanneer u resourcenamen maakt. Wanneer u deze functie gebruikt, moet u een seed-waarde opgeven, die anders moet zijn voor verschillende implementaties, maar consistent zijn voor alle implementaties voor dezelfde resources.

Als u een goede seed-waarde kiest, kunt u elke keer dezelfde naam krijgen wanneer u dezelfde set resources implementeert, maar u krijgt een andere naam wanneer u een andere set resources implementeert met behulp van dezelfde sjabloon. Laten we eens kijken hoe u de uniqueString() functie kunt gebruiken:

param storageAccountName string = uniqueString(resourceGroup().id)

De standaardwaarde van deze parameter gebruikt de resourceGroup() functie opnieuw, zoals u hebt gedaan bij het instellen van de resourcelocatie. Deze keer krijgt u echter de id voor een resourcegroep. Hier ziet u hoe een resourcegroep-id eruitziet:

/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MyResourceGroup

De resourcegroep-id bevat de Azure-abonnements-id (aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e) en de naam van de resourcegroep (MyResourceGroup). De resourcegroep-id is vaak een goede kandidaat voor een seed-waarde voor resourcenamen, omdat:

• Telkens wanneer u dezelfde resources implementeert, gaan ze naar dezelfde resourcegroep. De uniqueString() functie retourneert elke keer dezelfde waarde.
• Als u in twee verschillende resourcegroepen in het Azure-abonnement implementeert, is de resourceGroup().id waarde anders, omdat de namen van de resourcegroepen anders zijn. De uniqueString() functie geeft verschillende waarden voor elke set resources.
• Als u in twee verschillende Azure-abonnementen implementeert, zelfs als u dezelfde resourcegroepnaam gebruikt, is de resourceGroup().id waarde anders omdat de Azure-abonnements-id anders is. De uniqueString() functie geeft opnieuw verschillende waarden voor elke set resources.

Tip

Het is vaak een goed idee om sjabloonexpressies te gebruiken om resourcenamen te maken. Veel Azure-resourcetypen hebben regels over de toegestane tekens en de lengte van hun namen. Het insluiten van resourcenamen in de sjabloon betekent dat iedereen die de sjabloon gebruikt, deze regels zelf niet hoeft te volgen.

Gecombineerde tekenreeksen

Als u alleen de uniqueString() functie gebruikt om resourcenamen in te stellen, krijgt u waarschijnlijk unieke namen, maar ze zijn niet zinvol. Een goede resourcenaam moet ook beschrijvend zijn, zodat het duidelijk is waarvoor de resource is bedoeld. U wilt vaak een naam maken door een zinvol woord of een tekenreeks te combineren met een unieke waarde. Op deze manier hebt u resources met zowel betekenisvolle als unieke namen.

Bicep heeft een functie genaamd tekenreeksinterpolatie waarmee u tekenreeksen kunt combineren. Laten we eens kijken hoe het werkt:

param storageAccountName string = 'toylaunch${uniqueString(resourceGroup().id)}'

De standaardwaarde voor de storageAccountName parameter bevat nu twee delen:

• toylaunch is een in code vastgelegde tekenreeks waarmee iedereen die de geïmplementeerde resource in Azure bekijkt, kan begrijpen wat het doel van het opslagaccount is.
• ${uniqueString(resourceGroup().id)} is een manier om Bicep te vertellen de uitvoer van de uniqueString(resourceGroup().id) functie te evalueren en deze vervolgens samen te voegen in de tekenreeks.

Tip

Soms maakt de uniqueString() functie tekenreeksen die beginnen met een getal. Sommige Azure-resources, zoals opslagaccounts, staan niet toe dat hun namen beginnen met getallen. Dit betekent dat het een goed idee is om tekenreeksinterpolatie te gebruiken om resourcenamen te maken, zoals in het vorige voorbeeld.

SKU's voor resources selecteren

De andere leden van uw team zijn onder de indruk van de Bicep-code die u tot nu toe hebt gemaakt. U hebt samen besloten dat u uw sjabloon gaat gebruiken om de resources te implementeren ter ondersteuning van al uw nieuwe speelgoedlanceringen.

Een van uw collega's heeft voorgesteld om niet-productieomgevingen te maken voor elke productlancering om het marketingteam te helpen de sites te testen voordat ze beschikbaar zijn voor klanten. U wilt er echter zeker van zijn dat u niet te veel geld uitgeeft aan uw niet-productieomgevingen, dus u besluit samen een aantal beleidsregels:

• In productieomgevingen worden opslagaccounts geïmplementeerd in de Standard_GRS SKU (geografisch redundante opslag) voor hoge tolerantie. App Service-plannen worden geïmplementeerd in de P2v3 SKU voor hoge prestaties.
• In niet-productieomgevingen worden opslagaccounts geïmplementeerd in de Standard_LRS SKU (lokaal redundante opslag). App Service-plannen worden geïmplementeerd op de gratis F1 SKU.

Een manier om deze zakelijke vereisten te implementeren, is door parameters te gebruiken om elke SKU op te geven. Het opgeven van elke SKU als parameter kan echter moeilijk worden beheerd, met name wanneer u grotere sjablonen hebt. Een andere optie is het insluiten van de bedrijfsregels in de sjabloon met behulp van een combinatie van parameters, variabelen en expressies.

Eerst kunt u een parameter opgeven die aangeeft of de implementatie voor een productie- of niet-productieomgeving is:

@allowed([
  'nonprod'
  'prod'
])
param environmentType string

U ziet dat deze code een aantal nieuwe syntaxis gebruikt om een lijst met toegestane waarden voor de environmentType parameter op te geven. Bicep laat niemand de sjabloon implementeren, tenzij ze een van deze waarden opgeven.

Vervolgens kunt u variabelen maken die bepalen welke SKU's moeten worden gebruikt voor het opslagaccount en App Service-plan op basis van de omgeving:

var storageAccountSkuName = (environmentType == 'prod') ? 'Standard_GRS' : 'Standard_LRS'
var appServicePlanSkuName = (environmentType == 'prod') ? 'P2V3' : 'F1'

U ziet hier ook enkele nieuwe syntaxis. Laten we het opsplitsen:

• (environmentType == 'prod') evalueert naar een Booleaanse waarde (waar of onwaar), afhankelijk van welke toegestane waarde wordt gebruikt voor environmentType de parameter.
• ? wordt een ternaire operator genoemd en evalueert een if/then instructie. De waarde na de ? operator wordt gebruikt als de expressie waar is. Als de expressie onwaar oplevert, wordt de waarde na de dubbele punt (:) gebruikt.

We kunnen deze regels vertalen naar:

• Als de environmentType parameter is ingesteld prodop de storageAccountSkuName variabele, gebruikt u de Standard_GRS SKU. Gebruik anders de Standard_LRS SKU.
• Als de parameter is ingesteld prodop de appServicePlanSkuName environmentType variabele, gebruikt u de P2V3 SKU en de PremiumV3 laag. Gebruik anders de F1 SKU.

Tip

Wanneer u dergelijke expressies met meerdere onderdelen maakt, kunt u het beste variabelen gebruiken in plaats van de expressies rechtstreeks in de resource-eigenschappen in te sluiten. Dit maakt uw sjablonen gemakkelijker te lezen en te begrijpen, omdat hiermee wordt voorkomen dat uw resourcedefinities met logica onoverzichtelijk worden.

Wanneer u parameters, variabelen en expressies in uw sjabloon gebruikt, kunt u de sjabloon opnieuw gebruiken en snel een nieuwe set resources implementeren. Telkens wanneer uw marketingafdeling u bijvoorbeeld vraagt om een nieuwe website te implementeren voor de volgende lancering, geeft u nieuwe parameterwaarden op voor elke omgeving die u implementeert en wordt u ingesteld.