Föregående

Nästa

Gruppera relaterade resurser med hjälp av moduler

Slutförd

Du har börjat använda Bicep-mallar för några senaste produktlanseringar och de har lyckats. Eftersom du har deklarerat dina resurser i en mallfil kan du snabbt distribuera resurserna för nya leksaksstarter utan att behöva konfigurera resurser manuellt i Azure-portalen.

IT-chefen kan se att din Bicep-kod blir mer komplex och har ett ökande antal resurser definierade, så de har frågat om du kan göra koden mer modulariserad. Du kan skapa enskilda Bicep-filer, så kallade moduler, för olika delar av distributionen. Den huvudsakliga Bicep-mallen kan referera till dessa moduler. I bakgrunden överförs moduler till en enda JSON-mall för distribution.

Moduler är också ett sätt att göra Bicep-koden ännu mer återanvändbar. Du kan ha en enda Bicep-modul som många andra Bicep-mallar använder.

Du behöver också ofta generera utdata från Bicep-modulerna och mallarna. Utdata är ett sätt för din Bicep-kod att skicka tillbaka data till den eller det som startade distributionen. Nu ska vi titta på utdata först.

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.

Outputs (Utdata)

Bicep-mallar kan distribueras manuellt av en människa, eller så kan de distribueras av någon form av automatiserad lanseringsprocess. Hur som helst är det vanligt att ha vissa data från mallen som du behöver skicka tillbaka till den eller det som kör malldistributionen.

Här följer några exempelscenarier där du kan behöva hämta information från malldistributionen:

• Du skapar en Bicep-mall som distribuerar en virtuell dator och du måste hämta den offentliga IP-adressen så att du kan SSH till datorn.
• Du skapar en Bicep-mall som accepterar en uppsättning parametrar, till exempel ett miljönamn och ett programnamn. Mallen använder ett uttryck för att namnge en Azure App Service-app som den distribuerar. Du måste mata ut appens namn som mallen har distribuerat så att du kan använda den i en distributionspipeline för att publicera programbinärfilerna.

Du kan använda utdata för dessa scenarier. Om du vill definiera utdata i en Bicep-mall använder du nyckelordet output så här:

output appServiceAppName string = appServiceAppName

Utdatadefinitionen innehåller några viktiga delar:

• Nyckelordet output anger för Bicep att du definierar utdata.
• appServiceAppName är utdatanamnet. När någon distribuerar mallen innehåller utdatavärdena det namn som du har angett så att de kan komma åt de värden som de förväntar sig.
• string är utdatatypen. Bicep-utdata stöder samma typer som parametrar.
• Ett värde måste anges för varje utdata. Till skillnad från parametrar måste utdata alltid ha värden. Utdatavärden kan vara uttryck, referenser till parametrar eller variabler eller egenskaper för resurser som distribueras i filen.

Dricks

Utdata kan använda samma namn som variabler och parametrar. Den här konventionen kan vara användbar om du skapar ett komplext uttryck i en variabel som ska användas i mallens resurser, och du även behöver exponera variabelns värde som utdata.

Här är ett annat exempel på utdata. Den här får sitt värde inställt på det fullständigt kvalificerade domännamnet (FQDN) för en offentlig IP-adressresurs.

output ipFqdn string = publicIPAddress.properties.dnsSettings.fqdn

Dricks

Försök att använda resursegenskaper som utdata i stället för att göra antaganden om hur resurser ska bete sig. Om du till exempel behöver ha utdata för App Service-appens URL använder du appens defaultHostName egenskap i stället för att skapa en sträng för URL:en själv. Ibland är de här antagandena inte giltiga i olika miljöer, eller hur resursen fungerar, så det är säkrare att låta resursen berätta sina egna egenskaper.

Varning

Skapa inte utdata för hemliga värden som anslutningssträng eller nycklar. Alla som har åtkomst till resursgruppen kan läsa utdata från mallar. Det finns andra metoder som du kan använda för att få åtkomst till hemliga resursegenskaper, som vi tar upp i en senare modul.

Definiera en modul

Med Bicep-moduler kan du organisera och återanvända Bicep-koden genom att skapa mindre enheter som kan skapas i en mall. Alla Bicep-mallar kan användas som en modul av en annan mall. I den här utbildningsmodulen har du skapat Bicep-mallar. Det innebär att du redan har skapat filer som kan användas som Bicep-moduler!

Anta att du har en Bicep-mall som distribuerar program-, databas- och nätverksresurser för lösning A. Du kan dela upp den här mallen i tre moduler, som var och en fokuserar på sin egen uppsättning resurser. Som en bonus kan du nu återanvända modulerna i andra mallar för andra lösningar också. så när du utvecklar en mall för lösning B, som har liknande nätverkskrav som lösning A, kan du återanvända nätverksmodulen.

Använd nyckelordet när du vill att mallen ska innehålla en referens till en modulfil module . En moduldefinition ser ut ungefär som en resursdeklaration, men i stället för att inkludera en resurstyp och API-version använder du modulens filnamn:

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

Nu ska vi titta närmare på några viktiga delar i den här moduldefinitionen:

• Nyckelordet module talar om för Bicep att du ska använda en annan Bicep-fil som en modul.
• Precis som resurser behöver moduler ett symboliskt namn som myModule. Du använder det symboliska namnet när du refererar till modulens utdata i andra delar av mallen.
• modules/mymodule.bicep är sökvägen till modulfilen i förhållande till mallfilen. Kom ihåg att en modulfil bara är en vanlig Bicep-fil.
• Precis som resurser är egenskapen name obligatorisk. Azure använder modulnamnet eftersom det skapar en separat distribution för varje modul i mallfilen. Dessa distributioner har namn som du kan använda för att identifiera dem.
• Du kan ange valfria parametrar för modulen med hjälp av nyckelordet params . När du anger värdena för varje parameter i mallen kan du använda uttryck, mallparametrar, variabler, egenskaper för resurser som distribueras i mallen och utdata från andra moduler. Bicep kommer automatiskt att förstå beroendena mellan resurserna.

Moduler och utdata

Precis som mallar kan Bicep-moduler definiera utdata. Det är vanligt att länka ihop moduler i en mall. I så fall kan utdata från en modul vara en parameter för en annan modul. Genom att använda moduler och utdata tillsammans kan du skapa kraftfulla och återanvändbara Bicep-filer.

Utforma dina moduler

En bra Bicep-modul följer några viktiga principer:

• En modul bör ha ett tydligt syfte. Du kan använda moduler för att definiera alla resurser som är relaterade till en viss del av din lösning. Du kan till exempel skapa en modul som innehåller alla resurser som används för att övervaka ditt program. Du kan också använda en modul för att definiera en uppsättning resurser som hör ihop, som alla dina databasservrar och databaser.

• Placera inte varje resurs i en egen modul. Du bör inte skapa en separat modul för varje resurs som du distribuerar. Om du har en resurs som har många komplexa egenskaper kan det vara klokt att placera resursen i en egen modul, men i allmänhet är det bättre för moduler att kombinera flera resurser.

• En modul bör ha tydliga parametrar och utdata som är meningsfulla. Överväg syftet med modulen. Fundera på om modulen ska ändra parametervärden eller om den överordnade mallen ska hantera det och skicka sedan ett enda värde till modulen. På samma sätt bör du tänka på de utdata som en modul ska returnera och se till att de är användbara för de mallar som ska använda modulen.

• En modul ska vara så självständig som möjligt. Om en modul behöver använda en variabel för att definiera en del av en modul bör variabeln vanligtvis ingå i modulfilen i stället för i den överordnade mallen.

• En modul bör inte mata ut hemligheter. Precis som mallar skapar du inte modulutdata för hemliga värden som anslutningssträng eller nycklar.

Fortsätt