Lägg till flexibilitet med hjälp av parametrar och variabler
Mallar är kraftfulla på grund av deras återanvändning. Du kan använda Bicep för att skriva mallar som distribuerar flera miljöer eller kopior av dina resurser.
Leksaksföretaget lanserar nya produkter regelbundet och du måste använda Bicep-mallarna för att skapa de Azure-resurser som krävs för varje produktlansering. Du måste undvika att använda fasta resursnamn. Många typer av Azure-resurser behöver unika namn, så att bädda in namn i mallen innebär att du inte kan återanvända mallen för flera produktlanseringar. Du måste också distribuera resurserna på olika platser beroende på var leksakerna ska startas, vilket innebär att du inte heller kan bädda in resursplatserna i mallen.
I den här lektionen får du lära dig mer om parametrar och variabler, som är två Bicep-funktioner som kan göra dina mallar flexibla och återanvändbara. Du kommer också att introduceras för uttryck.
Kommentar
Kommandona i den här enheten visas för att illustrera begrepp. Kör inte kommandona än. Du kommer att öva på det du lär dig här snart.
Parametrar och variabler
Med en parameter kan du hämta värden utanför mallfilen. Om du till exempel distribuerar mallen manuellt med hjälp av Azure CLI eller Azure PowerShell uppmanas du att ange värden för varje parameter. Du kan också skapa en parameterfil som visar alla parametrar och värden som du vill använda för distributionen. Om mallen distribueras från en automatiserad process som en distributionspipeline kan pipelinen ange parametervärdena.
En variabel definieras och anges i mallen. Med variabler kan du lagra viktig information på ett ställe och referera till den i hela mallen utan att behöva kopiera och klistra in den.
Det är vanligtvis en bra idé att använda parametrar för saker som ändras mellan varje distribution, till exempel:
- Resursnamn som måste vara unika.
- Platser där resurserna ska distribueras.
- Inställningar som påverkar prissättningen för resurser, till exempel deras SKU:er, prisnivåer och antal instanser.
- Autentiseringsuppgifter och information som behövs för åtkomst till andra system som inte har definierats i mallen.
Variabler är vanligtvis ett bra alternativ när du använder samma värden för varje distribution, men du vill göra ett värde återanvändbart i mallen, eller när du vill använda uttryck för att skapa ett komplext värde. Du kan också använda variabler för resurser som inte behöver unika namn.
Dricks
Det är viktigt att använda bra namngivning för parametrar och variabler, så att dina mallar är lätta att läsa och förstå. Kontrollera att du använder tydliga, beskrivande och konsekventa namn.
Lägga till en parameter
I Bicep kan du definiera en parameter som den här:
param appServiceAppName string
Nu ska vi titta på hur varje del av den här definitionen fungerar:
param
talar om för Bicep att du definierar en parameter.appServiceAppName
är namnet på parametern. Om du distribuerar mallen manuellt kan du bli ombedd att ange ett värde, så det är viktigt att namnet är tydligt och begripligt. Namnet är också hur du refererar till parametervärdet i mallen, precis som med symboliska resursnamn.string
är parametertypen. Du kan ange flera olika typer för Bicep-parametrar, inklusivestring
för text,int
för tal ochbool
för booleska sanna eller falska värden. Du kan också skicka in mer komplexa parametrar med hjälp av typernaarray
ochobject
.
Dricks
Försök att inte över generalisera mallar med för många parametrar. Du bör använda det minsta antalet parametrar som du behöver för ditt affärsscenario. Kom ihåg att du alltid kan ändra mallar i framtiden om dina krav ändras.
Ange standardvärden
Du kan också ange ett standardvärde för en parameter. När du anger ett standardvärde blir parametern valfri. Den person som distribuerar mallen kan ange ett värde om de vill, men om de inte gör det använder Bicep standardvärdet.
Så här kan du lägga till ett standardvärde:
param appServiceAppName string = 'toy-product-launch-1'
Kommentar
I det här exemplet har Azure App Service-appnamnet ett hårdkodat standardvärde. Det här är ingen bra idé eftersom App Service-appar behöver unika namn. Du kommer snart att åtgärda det här.
Använda parametervärden i mallen
När du har deklarerat en parameter kan du referera till den i resten av mallen. Nu ska vi se hur du kan använda den nya parametern i resursdefinitionen:
resource appServiceApp 'Microsoft.Web/sites@2023-12-01' = {
name: appServiceAppName
location: 'eastus'
properties: {
serverFarmId: appServicePlan.id
httpsOnly: true
}
}
Observera att mallen nu använder parametervärdet för att ange resursnamnet för appresursen i stället för ett hårdkodat värde.
Dricks
Bicep-tillägget för Visual Studio Code visar visuella indikatorer som meddelar dig när du inte följer rekommenderade metoder. Den varnar dig till exempel om du definierar en parameter som du inte använder. Bicep-lintern kör kontinuerligt dessa kontroller medan du arbetar.
Lägga till en variabel
Du kan definiera en variabel som den här:
var appServicePlanName = 'toy-product-launch-plan'
Variabler definieras på ett liknande sätt som parametrar, men det finns några skillnader:
- Använd nyckelordet
var
för att berätta för Bicep att du deklarerar en variabel. - Du måste ange ett värde för en variabel.
- Variabler behöver inte typer. Bicep kan fastställa typen baserat på det värde som du anger.
Uttryck
När du skriver mallar vill du ofta inte hårdkoda värden eller ens be om att de ska anges i en parameter. I stället vill du identifiera värden när mallen körs. Du vill till exempel förmodligen distribuera alla resurser i en mall till en enda Azure-region: den region där du har skapat resursgruppen. Eller så kanske du vill skapa ett unikt namn för en resurs automatiskt baserat på en viss namngivningsstrategi som företaget använder.
Uttryck i Bicep är en kraftfull funktion som hjälper dig att hantera alla möjliga intressanta scenarier. Låt oss ta en titt på några platser där du kan använda uttryck i en Bicep-mall.
Resursplatser
När du skriver och distribuerar en mall behöver du ofta inte ange platsen för varje resurs individuellt. I stället kan du ha en enkel affärsregel som säger att du som standard distribuerar alla resurser till samma plats där resursgruppen skapades.
I Bicep kan du skapa en parameter med namnet location
och sedan använda ett uttryck för att ange dess värde:
param location string = resourceGroup().location
Titta på standardvärdet för parametern. Den använder en funktion med namnet resourceGroup()
som ger dig åtkomst till information om den resursgrupp som mallen distribueras till. I det här exemplet använder mallen location
egenskapen . Det är vanligt att använda den här metoden för att distribuera dina resurser till samma Azure-region som resursgruppen.
Om någon distribuerar den här mallen kan de välja att åsidosätta standardvärdet här och använda en annan plats.
Kommentar
Vissa resurser i Azure kan bara distribueras till vissa platser. Du kan behöva separata parametrar för att ange platserna för dessa resurser.
Nu kan du använda resursplatsparametern i mallen, så här:
resource appServiceApp 'Microsoft.Web/sites@2023-12-01' = {
name: appServiceAppName
location: location
properties: {
serverFarmId: appServicePlan.id
httpsOnly: true
}
}
Resursnamn
Många Azure-resurser behöver unika namn. I ditt scenario har du två resurser som behöver unika namn: lagringskontot och App Service-appen. Att be om att dessa värden ska anges som parametrar kan göra det svårt för den som använder mallen, eftersom de måste hitta ett namn som ingen annan har använt.
Bicep har en annan funktion som heter uniqueString()
som är praktisk när du skapar resursnamn. När du använder den här funktionen måste du ange ett startvärde, som bör skilja sig mellan olika distributioner, men konsekvent för alla distributioner för samma resurser.
Om du väljer ett bra startvärde kan du få samma namn varje gång du distribuerar samma uppsättning resurser, men du får ett annat namn när du distribuerar en annan uppsättning resurser med hjälp av samma mall. Nu ska vi titta på hur du kan använda uniqueString()
funktionen:
param storageAccountName string = uniqueString(resourceGroup().id)
Den här parameterns standardvärde använder resourceGroup()
funktionen igen, precis som när du angav resursplatsen. Men den här gången får du ID:t för en resursgrupp. Så här ser ett resursgrupps-ID ut:
/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MyResourceGroup
Resursgrupps-ID:t innehåller Azure-prenumerations-ID (aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e
) och resursgruppsnamnet (MyResourceGroup
). Resursgrupps-ID:t är ofta en bra kandidat för ett startvärde för resursnamn, eftersom:
- Varje gång du distribuerar samma resurser hamnar de i samma resursgrupp. Funktionen
uniqueString()
returnerar samma värde varje gång. - Om du distribuerar till två olika resursgrupper i Azure-prenumerationen
resourceGroup().id
blir värdet annorlunda eftersom resursgruppsnamnen skiljer sig åt. FunktionenuniqueString()
ger olika värden för varje uppsättning resurser. - Om du distribuerar till två olika Azure-prenumerationer, även om du använder samma resursgruppsnamn,
resourceGroup().id
blir värdet annorlunda eftersom Azure-prenumerations-ID:t skiljer sig. FunktionenuniqueString()
ger återigen olika värden för varje uppsättning resurser.
Dricks
Det är ofta en bra idé att använda malluttryck för att skapa resursnamn. Många Azure-resurstyper har regler om tillåtna tecken och längden på deras namn. Att bädda in skapandet av resursnamn i mallen innebär att alla som använder mallen inte behöver komma ihåg att följa dessa regler själva.
Kombinerade strängar
Om du bara använder uniqueString()
funktionen för att ange resursnamn får du förmodligen unika namn, men de är inte meningsfulla. Ett bra resursnamn bör också vara beskrivande, så att det är tydligt vad resursen är till för. Du vill ofta skapa ett namn genom att kombinera ett beskrivande ord eller en sträng med ett unikt värde. På så sätt har du resurser som har både meningsfulla och unika namn.
Bicep har en funktion som kallas stränginterpolation som gör att du kan kombinera strängar. Nu ska vi se hur det fungerar:
param storageAccountName string = 'toylaunch${uniqueString(resourceGroup().id)}'
Standardvärdet för parametern storageAccountName
har nu två delar:
toylaunch
är en hårdkodad sträng som hjälper alla som tittar på den distribuerade resursen i Azure att förstå lagringskontots syfte.${uniqueString(resourceGroup().id)}
är ett sätt att tala om för Bicep att utvärdera funktionensuniqueString(resourceGroup().id)
utdata och sedan sammanfoga den i strängen.
Dricks
uniqueString()
Ibland skapar funktionen strängar som börjar med ett tal. Vissa Azure-resurser, till exempel lagringskonton, tillåter inte att deras namn börjar med siffror. Det innebär att det är en bra idé att använda stränginterpolation för att skapa resursnamn, som i föregående exempel.
Välja SKU:er för resurser
De andra medlemmarna i ditt team är imponerade av den Bicep-kod som du har skapat hittills. Du har bestämt dig tillsammans för att använda mallen för att distribuera resurserna för att stödja alla dina nya leksakslanseringar.
En av dina kollegor har föreslagit att du skapar icke-produktionsmiljöer för varje produktlansering för att hjälpa marknadsföringsteamet att testa webbplatserna innan de är tillgängliga för kunder. Men du vill se till att du inte spenderar för mycket pengar på dina icke-produktionsmiljöer, så du bestämmer dig för vissa principer tillsammans:
- I produktionsmiljöer distribueras lagringskonton på
Standard_GRS
SKU:n (geo-redundant lagring) för hög återhämtning. App Service-planer kommer att distribueras på SKU:nP2v3
för höga prestanda. - I icke-produktionsmiljöer distribueras lagringskonton på SKU:
Standard_LRS
n (lokalt redundant lagring). App Service-planer distribueras på den kostnadsfriaF1
SKU:n.
Ett sätt att implementera dessa affärskrav är att använda parametrar för att ange varje SKU. Det kan dock bli svårt att ange varje SKU som en parameter, särskilt när du har större mallar. Ett annat alternativ är att bädda in affärsreglerna i mallen med hjälp av en kombination av parametrar, variabler och uttryck.
Först kan du ange en parameter som anger om distributionen gäller för en produktions- eller icke-produktionsmiljö:
@allowed([
'nonprod'
'prod'
])
param environmentType string
Observera att den här koden använder en ny syntax för att ange en lista över tillåtna värden för parametern environmentType
. Bicep tillåter inte att någon distribuerar mallen om de inte anger något av dessa värden.
Sedan kan du skapa variabler som avgör vilka SKU:er som ska användas för lagringskontot och App Service-planen baserat på miljön:
var storageAccountSkuName = (environmentType == 'prod') ? 'Standard_GRS' : 'Standard_LRS'
var appServicePlanSkuName = (environmentType == 'prod') ? 'P2V3' : 'F1'
Observera även en ny syntax här. Nu ska vi dela upp det:
(environmentType == 'prod')
utvärderas till ett booleskt värde (sant eller falskt) beroende på vilket tillåtet värde som används förenvironmentType
parametern.?
kallas för en ternary-operator och utvärderar enif/then
-instruktion. Värdet efter att operatorn?
används om uttrycket är sant. Om uttrycket utvärderas till false används värdet efter kolonet (:
).
Vi kan översätta dessa regler till:
- Om parametern
environmentType
är inställd påprod
för variabelnstorageAccountSkuName
använder du SKU:nStandard_GRS
. Annars använder du SKU:nStandard_LRS
. - Om parametern
environmentType
är inställdprod
på för variabelnappServicePlanSkuName
använder duP2V3
SKU:n ochPremiumV3
nivån. Annars använder du SKU:nF1
.
Dricks
När du skapar flerpartsuttryck som detta är det bäst att använda variabler i stället för att bädda in uttrycken direkt i resursegenskaperna. Detta gör dina mallar enklare att läsa och förstå, eftersom de undviker att störa dina resursdefinitioner med logik.
När du använder parametrar, variabler och uttryck i mallen kan du återanvända mallen och snabbt distribuera en ny uppsättning resurser. Varje gång din marknadsföringsavdelning till exempel ber dig att distribuera en ny webbplats för nästa leksaksstart anger du nya parametervärden för varje miljö som du distribuerar, så kommer du att ställas in!