Gruppér relaterede ressourcer ved hjælp af moduler

Fuldført

Du er begyndt at bruge Bicep-skabeloner til nogle af de seneste produktlanceringer, og de har været vellykkede. Da du har erklæret dine ressourcer i en skabelonfil, kan du hurtigt udrulle ressourcerne til nye legetøjsstarter uden at skulle konfigurere ressourcer manuelt på Azure Portal.

It-chefen kan se, at din Bicep-kode bliver mere kompleks og har defineret et stigende antal ressourcer, så de har spurgt, om du kan gøre koden mere modulariseret. Du kan oprette individuelle Bicep-filer, kaldet moduler, til forskellige dele af installationen. Den primære Bicep-skabelon kan referere til disse moduler. I baggrunden overføres moduler til en enkelt JSON-skabelon til udrulning.

Moduler er også en måde at gøre Bicep-kode endnu mere genbrugelig på. Du kan have et enkelt Bicep-modul, som mange andre Bicep-skabeloner bruger.

Du skal også ofte udsende output fra Bicep-modulerne og -skabelonerne. Output er en måde for din Bicep-kode at sende data tilbage til den person eller det, der startede udrulningen. Lad os først se på output.

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.

Udgange

En person kan installere Bicep-skabeloner manuelt, eller en eller anden form for automatiseret udgivelsesproces kan udrulle dem. I begge tilfælde er det almindeligt at have nogle data fra den skabelon, du skal sende tilbage til den person eller det, der udfører udrulningen af skabelonen.

Her er nogle eksempelscenarier, hvor du muligvis skal hente oplysninger fra udrulningen af skabelonen:

  • Du opretter en Bicep-skabelon, der udruller en virtuel maskine, og du skal hente den offentlige IP-adresse, så du kan SSH ind på maskinen.
  • Du opretter en Bicep-skabelon, der accepterer et sæt parametre, f.eks. et miljønavn og et programnavn. Skabelonen bruger et udtryk til at navngive en Azure App Service-app, som den installerer. Du skal skrive appens navn, som skabelonen har installeret, så du kan bruge den i en udrulningspipeline til at publicere de binære programfiler.

Du kan bruge output til disse scenarier. Hvis du vil definere et output i en Bicep-skabelon, skal du bruge nøgleordet output som dette:

output appServiceAppName string = appServiceAppName

Outputdefinitionen indeholder et par vigtige dele:

  • Nøgleordet output fortæller Bicep, at du definerer et output.
  • appServiceAppName er outputtets navn. Når en person installerer skabelonen korrekt, indeholder outputværdierne det navn, du har angivet, så de kan få adgang til de værdier, de forventer.
  • string er outputtypen. Bicep-output understøtter de samme typer som parametre.
  • Der skal angives en værdi for hvert output. I modsætning til parametre skal output altid have værdier. Outputværdier kan være udtryk, referencer til parametre eller variabler eller egenskaber for ressourcer, der er installeret i filen.

Drikkepenge

Output kan bruge de samme navne som variabler og parametre. Denne konvention kan være nyttig, hvis du konstruerer et komplekst udtryk i en variabel, der skal bruges i skabelonens ressourcer, og du også skal vise variablens værdi som et output.

Her er et andet eksempel på et output. Denne får sin værdi angivet til det fuldt kvalificerede domænenavn (FQDN) for en offentlig IP-adresseressource.

output ipFqdn string = publicIPAddress.properties.dnsSettings.fqdn

Drikkepenge

Prøv at bruge ressourceegenskaber som output i stedet for at angive forudsætninger for, hvordan ressourcer skal fungere. Hvis du f.eks. har brug for et output til App Service-appens URL-adresse, skal du bruge appens egenskab defaultHostName i stedet for selv at oprette en streng til URL-adressen. Nogle gange er disse forudsætninger ikke gyldige i forskellige miljøer, eller den måde, ressourcen fungerer på, ændres, så det er sikrere at få ressourcen til at fortælle dig sine egne egenskaber.

Forsigtighed

Opret ikke output til hemmelige værdier, f.eks. forbindelsesstrenge eller nøgler. Alle med adgang til din ressourcegruppe kan læse output fra skabeloner. Der er andre metoder, du kan bruge til at få adgang til hemmelige ressourceegenskaber, som vi gennemgår i et senere modul.

Definer et modul

Bicep-moduler giver dig mulighed for at organisere og genbruge din Bicep-kode ved at oprette mindre enheder, der kan sammensættes i en skabelon. Enhver Bicep-skabelon kan bruges som et modul af en anden skabelon. I hele dette læringsmodul har du oprettet Bicep-skabeloner. Det betyder, at du allerede har oprettet filer, der kan bruges som Bicep-moduler!

Forestil dig, at du har en Bicep-skabelon, der installerer program-, database- og netværksressourcer til løsning A. Du kan opdele denne skabelon i tre moduler, som hver især fokuserer på sit eget sæt ressourcer. Som en bonus kan du nu også genbruge modulerne i andre skabeloner til andre løsninger. så når du udvikler en skabelon til løsning B, som har samme netværkskrav som løsning A, kan du genbruge netværksmodulet.

diagram, der viser en skabelon til løsning En reference til tre moduler: program, database og netværk. Netværksmodulet genbruges derefter i en anden skabelon til løsning B.

Når skabelonen skal indeholde en reference til en modulfil, skal du bruge nøgleordet module. En moduldefinition ligner en ressourceerklæring, men i stedet for at inkludere en ressourcetype og API-version, skal du bruge modulets filnavn:

module myModule 'modules/mymodule.bicep' = {
  name: 'MyModule'
  params: {
    location: location
  }
}

Lad os se nærmere på nogle vigtige dele af denne moduldefinition:

  • Nøgleordet module fortæller Bicep, at du er ved at bruge en anden Bicep-fil som et modul.
  • På samme måde som med ressourcer skal moduler have et symbolsk navn som myModule. Du skal bruge det symbolske navn, når du refererer til modulets output i andre dele af skabelonen.
  • modules/mymodule.bicep er stien til modulfilen i forhold til skabelonfilen. Husk, at en modulfil kun er en almindelig Bicep-fil.
  • På samme måde som med ressourcer er egenskaben name obligatorisk. Azure bruger modulnavnet, fordi det opretter en separat installation for hvert modul i skabelonfilen. Disse installationer har navne, du kan bruge til at identificere dem.
  • Du kan angive parametre af modulet ved hjælp af nøgleordet params. Når du angiver værdierne for hver parameter i skabelonen, kan du bruge udtryk, skabelonparametre, variabler, egenskaber for ressourcer, der er installeret i skabelonen, og output fra andre moduler. Bicep forstår automatisk afhængighederne mellem ressourcerne.

Moduler og output

På samme måde som med skabeloner kan Bicep-moduler definere output. Det er almindeligt at sammenkæde moduler i en skabelon. I dette tilfælde kan outputtet fra ét modul være en parameter for et andet modul. Når du bruger moduler og output sammen, kan du oprette effektive Bicep-filer, der kan genbruges.

Design dine moduler

Et godt Bicep-modul følger nogle af de vigtigste principper:

  • Et modul skal have et klart formål. Du kan bruge moduler til at definere alle de ressourcer, der er relateret til en bestemt del af din løsning. Du kan f.eks. oprette et modul, der indeholder alle de ressourcer, der bruges til at overvåge dit program. Du kan også bruge et modul til at definere et sæt ressourcer, der hører sammen, ligesom alle dine databaseservere og databaser.

  • Placer ikke alle ressourcer i deres eget modul. Du bør ikke oprette et separat modul for hver ressource, du udruller. Hvis du har en ressource, der har mange komplekse egenskaber, kan det give mening at placere denne ressource i sit eget modul, men generelt er det bedre, at moduler kombinerer flere ressourcer.

  • Et modul skal have tydelige parametre og output, der giver mening. Overvej formålet med modulet. Tænk på, om modulet skal manipulere parameterværdier, eller om den overordnede skabelon skal håndtere det, og derefter overføre en enkelt værdi til modulet. På samme måde skal du overveje, hvilke output et modul skal returnere, og sørg for, at de er nyttige for de skabeloner, der bruger modulet.

  • Et modul skal være så selvstændigt som muligt. Hvis et modul skal bruge en variabel til at definere en del af et modul, skal variablen generelt inkluderes i modulfilen i stedet for i den overordnede skabelon.

  • Et modul må ikke skrive hemmeligheder. På samme måde som med skabeloner skal du ikke oprette moduloutput for hemmelige værdier, f.eks. forbindelsesstrenge eller nøgler.