Tilføj fleksibilitet ved hjælp af parametre og variabler

Fuldført

Skabeloner er effektive på grund af deres genbrugelighed. Du kan bruge Bicep til at skrive skabeloner, der udruller flere miljøer eller kopier af dine ressourcer.

Dit legetøjsfirma starter jævnligt nye produkter, og du skal bruge Bicep-skabelonerne til at oprette de Azure-ressourcer, der kræves til hver produktlancering. Du skal undgå at bruge faste ressourcenavne. Mange typer Azure-ressourcer skal bruge entydige navne, så integrering af navne i skabelonen betyder, at du ikke kan genbruge skabelonen til flere produktstarter. Du skal også udrulle ressourcerne forskellige steder, afhængigt af hvor legetøjet startes, hvilket betyder, at du heller ikke kan integrere ressourceplaceringerne i skabelonen.

I dette undermodul får du mere at vide om parametre og variabler, som er to Bicep-funktioner, der kan gøre dine skabeloner fleksible og genbrugelige. Du bliver også introduceret til udtryk.

Seddel

Kommandoerne i dette undermodul vises for at illustrere begreber. Kør ikke kommandoerne endnu. Du skal snart øve dig i det, du lærer her.

Parametre og variabler

Med en parameter kan du hente værdier uden for skabelonfilen. Hvis du f.eks. udruller skabelonen manuelt ved hjælp af Kommandolinjegrænsefladen i Azure eller Azure PowerShell, bliver du bedt om at angive værdier for hver parameter. Du kan også oprette en parameterfil, som viser alle de parametre og værdier, du vil bruge til installationen. Hvis skabelonen installeres fra en automatiseret proces, f.eks. en udrulningspipeline, kan pipelinen levere parameterværdierne.

En variabel defineres og angives i skabelonen. Med variabler kan du gemme vigtige oplysninger ét sted og referere til dem i hele skabelonen uden at skulle kopiere og indsætte dem.

Det er normalt en god idé at bruge parametre til ting, der ændres mellem hver udrulning, f.eks.:

  • Ressourcenavne, der skal være entydige.
  • Placeringer, hvor ressourcerne skal installeres.
  • Indstillinger, der påvirker prisfastsættelsen af ressourcer, f.eks. deres SKU'er, prisniveauer og antal forekomster.
  • Legitimationsoplysninger og oplysninger, der er nødvendige for at få adgang til andre systemer, der ikke er defineret i skabelonen.

Variabler er normalt en god indstilling, når du skal bruge de samme værdier for hver installation, men du vil gøre en værdi genbrugelig i skabelonen, eller når du vil bruge udtryk til at oprette en kompleks værdi. Du kan også bruge variabler til ressourcer, der ikke har brug for entydige navne.

Drikkepenge

Det er vigtigt at bruge god navngivning for parametre og variabler, så dine skabeloner er nemme at læse og forstå. Sørg for, at du bruger tydelige, beskrivende og ensartede navne.

Tilføj en parameter

I Bicep kan du definere en parameter som denne:

param appServiceAppName string

Lad os se på, hvordan hver del af denne definition fungerer:

  • param fortæller Bicep, at du definerer en parameter.
  • appServiceAppName er navnet på parameteren. Hvis du udruller skabelonen manuelt, bliver du muligvis bedt om at angive en værdi, så det er vigtigt, at navnet er klart og forståeligt. Navnet er også den måde, du refererer til parameterværdien i skabelonen på samme måde som med ressourcesymboliske navne.
  • string er parameterens type. Du kan angive flere forskellige typer for Bicep-parametre, herunder string til tekst, int for tal og bool for booleske true- eller false-værdier. Du kan også overføre mere komplekse parametre ved hjælp af typerne array og object.

Drikkepenge

Prøv ikke at over generalisere skabeloner ved hjælp af for mange parametre. Du skal bruge det mindste antal parametre, du skal bruge til dit forretningsscenarie. Husk, at du altid kan ændre skabeloner i fremtiden, hvis dine krav ændres.

Angiv standardværdier

Du kan eventuelt angive en standardværdi for en parameter. Når du angiver en standardværdi, bliver parameteren valgfri. Den person, der udruller skabelonen, kan angive en værdi, hvis vedkommende vil, men hvis de ikke gør det, bruger Bicep standardværdien.

Sådan tilføjer du en standardværdi:

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

Seddel

I dette eksempel har appnavnet på Azure App Service en hard-coded standardværdi. Det er ikke en god idé, fordi App Service-apps skal bruge entydige navne. Du skal løse dette om lidt.

Brug parameterværdier i skabelonen

Når du har erklæret en parameter, kan du referere til den i resten af skabelonen. Lad os se, hvordan du kan bruge din nye parameter i ressourcedefinitionen:

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

Bemærk, at skabelonen nu bruger parameterværdien til at angive ressourcenavnet for appressourcen i stedet for en hard-coded værdi.

Drikkepenge

Bicep-udvidelsen til Visual Studio Code viser dig visuelle indikatorer, så du får besked, når du ikke følger anbefalede fremgangsmåder. Den advarer dig f.eks., hvis du definerer en parameter, du ikke bruger. Bicep linter- kører løbende disse kontroller, mens du arbejder.

Tilføj en variabel

Du kan definere en variabel som denne:

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

Variabler defineres på samme måde som parametre, men der er et par forskelle:

  • Brug nøgleordet var til at fortælle Bicep, at du erklærer en variabel.
  • Du skal angive en værdi for en variabel.
  • Variabler behøver ikke typer. Bicep kan bestemme typen baseret på den værdi, du angiver.

Udtryk

Når du skriver skabeloner, vil du ofte ikke have hard-code-værdier eller endda bede om, at de angives i en parameter. Du vil i stedet finde værdier, når skabelonen kører. Det kan f.eks. være, at du vil udrulle alle ressourcerne i en skabelon i et enkelt Azure-område: det område, hvor du har oprettet ressourcegruppen. Det kan også være en god idé automatisk at oprette et entydigt navn til en ressource baseret på en bestemt navngivningsstrategi, som din virksomhed bruger.

Expressions i Bicep er en effektiv funktion, der hjælper dig med at håndtere alle mulige interessante scenarier. Lad os se på et par steder, hvor du kan bruge udtryk i en Bicep-skabelon.

Ressourceplaceringer

Når du skriver og udruller en skabelon, behøver du ofte ikke at angive placeringen af hver ressource individuelt. I stedet kan du have en simpel forretningsregel, hvor der står, som standard, udrulle alle ressourcer på den samme placering, hvor ressourcegruppen blev oprettet.

I Bicep kan du oprette en parameter med navnet locationog derefter bruge et udtryk til at angive værdien:

param location string = resourceGroup().location

Se standardværdien for parameteren. Den bruger en funktion kaldet resourceGroup(), der giver dig adgang til oplysninger om den ressourcegruppe, skabelonen udrulles i. I dette eksempel bruger skabelonen egenskaben location. Det er almindeligt at bruge denne fremgangsmåde til at udrulle dine ressourcer i det samme Azure-område som ressourcegruppen.

Hvis en person installerer denne skabelon, kan vedkommende vælge at tilsidesætte standardværdien her og bruge en anden placering.

Seddel

Nogle ressourcer i Azure kan kun udrulles på bestemte placeringer. Du skal muligvis bruge separate parametre for at angive placeringen af disse ressourcer.

Du kan nu bruge ressourceplaceringsparameteren i skabelonen på følgende måde:

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

Ressourcenavne

Mange Azure-ressourcer skal bruge entydige navne. I dit scenarie har du to ressourcer, der skal bruge entydige navne: lagerkontoen og appen App Service. Hvis du beder om, at disse værdier angives som parametre, kan det gøre det svært for den person, der bruger skabelonen, fordi de skal finde et navn, som ingen andre har brugt.

Bicep har en anden funktion kaldet uniqueString(), der er praktisk, når du opretter ressourcenavne. Når du bruger denne funktion, skal du angive en seedværdi, som skal være forskellig på tværs af forskellige installationer, men ensartet på tværs af alle udrulninger for de samme ressourcer.

Hvis du vælger en god seedværdi, kan du få det samme navn, hver gang du installerer det samme sæt ressourcer, men du får et andet navn, hver gang du installerer et andet sæt ressourcer ved hjælp af den samme skabelon. Lad os se på, hvordan du kan bruge funktionen uniqueString():

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

Denne parameters standardværdi bruger funktionen resourceGroup() igen, som du gjorde, da du indstillede ressourceplaceringen. Denne gang får du dog id'et for en ressourcegruppe. Sådan ser et ressourcegruppe-id ud:

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

Ressourcegruppe-id'et indeholder Azure-abonnements-id'et (aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e) og navnet på ressourcegruppen (MyResourceGroup). Ressourcegruppe-id'et er ofte en god kandidat til en seedværdi for ressourcenavne, fordi:

  • Hver gang du udruller de samme ressourcer, går de ind i den samme ressourcegruppe. Funktionen uniqueString() returnerer den samme værdi hver gang.
  • Hvis du udruller i to forskellige ressourcegrupper i Azure-abonnementet, vil den resourceGroup().id værdi være anderledes, fordi navnene på ressourcegruppen vil være forskellige. Funktionen uniqueString() giver forskellige værdier for hvert sæt ressourcer.
  • Hvis du udruller i to forskellige Azure-abonnementer, selvom du bruger det samme ressourcegruppenavn, vil den resourceGroup().id værdi være anderledes, fordi Azure-abonnements-id'et vil være anderledes. Funktionen uniqueString() giver igen forskellige værdier for hvert sæt ressourcer.

Drikkepenge

Det er ofte en god idé at bruge skabelonudtryk til at oprette ressourcenavne. Mange Azure-ressourcetyper har regler for de tilladte tegn og længden af deres navne. Integrering af oprettelsen af ressourcenavne i skabelonen betyder, at alle, der bruger skabelonen, ikke behøver at huske selv at følge disse regler.

Kombinerede strenge

Hvis du bare bruger funktionen uniqueString() til at angive ressourcenavne, får du sandsynligvis entydige navne, men de giver ikke mening. Et godt ressourcenavn skal også være beskrivende, så det er tydeligt, hvad ressourcen er til. Du vil ofte oprette et navn ved at kombinere et sigende ord eller en meningsfuld streng med en entydig værdi. På denne måde har du ressourcer, der både har meningsfulde og entydige navne.

Bicep har en funktion, der kaldes strenginterpolering, der gør det muligt at kombinere strenge. Lad os se, hvordan det fungerer:

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

Standardværdien for parameteren storageAccountName har nu to dele:

  • toylaunch er en hard-coded streng, der hjælper alle, der kigger på den udrullede ressource i Azure, med at forstå formålet med lagerkontoen.
  • ${uniqueString(resourceGroup().id)} er en måde at få Bicep til at evaluere outputtet af funktionen uniqueString(resourceGroup().id) og derefter sammenkæde den i strengen.

Drikkepenge

Nogle gange opretter funktionen uniqueString() strenge, der starter med et tal. Nogle Azure-ressourcer, f.eks. lagerkonti, tillader ikke, at deres navne starter med tal. Det betyder, at det er en god idé at bruge strenginterpolering til at oprette ressourcenavne, f.eks. i det foregående eksempel.

Valg af SKU'er til ressourcer

De andre medlemmer af dit team er imponerede over den Bicep-kode, du har bygget indtil videre. I har sammen besluttet, at I vil bruge skabelonen til at udrulle ressourcerne til at understøtte alle dine nye lanceringer af legetøj.

En af dine kollegaer har foreslået, at du opretter ikke-produktionsmiljøer for hver produktlancering for at hjælpe marketingteamet med at teste webstederne, før de er tilgængelige for kunder. Du vil dog sikre dig, at du ikke bruger for mange penge på dine ikke-produktionsmiljøer, så du beslutter dig for nogle politikker sammen:

  • I produktionsmiljøer udrulles lagerkonti på sku'en for Standard_GRS (geo redundant lager) for at opnå høj robusthed. App Service-planer udrulles på P2v3 SKU'en for at opnå høj ydeevne.
  • I ikke-produktionsmiljøer udrulles lagerkonti på sku'en Standard_LRS (lokalt redundant lager). App Service-planer udrulles på den gratis F1 SKU.

En måde at implementere disse forretningskrav på er ved at bruge parametre til at angive hver SKU. Det kan dog blive svært at administrere alle SKU'er som en parameter, især når du har større skabeloner. En anden mulighed er at integrere forretningsreglerne i skabelonen ved hjælp af en kombination af parametre, variabler og udtryk.

Først kan du angive en parameter, der angiver, om udrulningen er til et produktions- eller ikke-produktionsmiljø:

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

Bemærk, at denne kode bruger en ny syntaks til at angive en liste over tilladte værdier, der for parameteren environmentType. Bicep lader ikke nogen installere skabelonen, medmindre de angiver en af disse værdier.

Derefter kan du oprette variabler, der bestemmer, hvilke SKU'er der skal bruges til lagerkontoen og App Service-planen baseret på miljøet:

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

Bemærk også en ny syntaks her. Lad os opdele det:

  • (environmentType == 'prod') evalueres til en boolesk værdi (sand eller falsk), afhængigt af hvilken tilladt værdi der bruges til environmentType parameter.
  • ? kaldes en ternær operator, og den evaluerer en if/then-sætning. Værdien efter operatoren ? bruges, hvis udtrykket er true. Hvis udtrykket evalueres til falsk, bruges værdien efter kolonet (:).

Vi kan oversætte disse regler til:

  • Hvis parameteren environmentType er angivet til prodfor variablen storageAccountSkuName, skal du bruge sku'en Standard_GRS. Ellers skal du bruge den Standard_LRS SKU.
  • Hvis parameteren environmentType for variablen appServicePlanSkuName er angivet til prod, skal du bruge P2V3 SKU og niveauet PremiumV3. Ellers skal du bruge den F1 SKU.

Drikkepenge

Når du opretter udtryk med flere dele som denne, er det bedst at bruge variabler i stedet for at integrere udtrykkene direkte i ressourceegenskaberne. Det gør det nemmere at læse og forstå dine skabeloner, da det undgår at rode dine ressourcedefinitioner med logik.

Når du bruger parametre, variabler og udtryk i skabelonen, kan du genbruge skabelonen og hurtigt udrulle et nyt sæt ressourcer. Hver gang marketingafdelingen f.eks. beder dig om at udrulle et nyt websted til næste lancering af legetøjet, skal du angive nye parameterværdier for hvert miljø, du udruller, og du vil blive angivet!