Metodtips för Bicep

  • Artikel
  • 5 minuter för att läsa

Den här artikeln rekommenderar metoder att följa när du utvecklar dina Bicep-filer. Dessa metoder gör din Bicep-fil lättare att förstå och använda.

Microsoft Learn

Mer information om bästa praxis för Bicep och praktisk vägledning finns i Strukturera din Bicep-kod för samarbete på Microsoft Learn.

Parametrar

  • Använd bra namngivning för parameterdeklarationer. Bra namn gör dina mallar lätta att läsa och förstå. Se till att du använder tydliga, beskrivande namn och konsekventa namn.

  • Tänk noga på de parametrar som mallen använder. Försök att använda parametrar för inställningar som ändras mellan distributioner. Variabler och hårdkodade värden kan användas för inställningar som inte ändras mellan distributioner.

  • Ha i åtanke de standardvärden som du använder. Kontrollera att standardvärdena är säkra för alla som ska distribueras. Överväg till exempel att använda prisnivåer och SKU:er till låg kostnad så att någon som distribuerar mallen till en testmiljö inte medför en stor kostnad i onödan.

  • Använd @allowed decorator sparingly. Om du använder den här decorator för brett kan du blockera giltiga distributioner. När Azure-tjänster lägger till SKU:er och storlekar kanske listan över tillåtna inte är uppdaterad. Att till exempel bara tillåta Premium v3-SKU:er kan vara meningsfullt i produktion, men det förhindrar att du använder samma mall i icke-produktionsmiljöer.

  • Det är en bra idé att ange beskrivningar för dina parametrar. Försök att göra beskrivningarna användbara och ange viktig information om vad mallen kräver att parametervärdena är.

    Du kan också använda // kommentarer för viss information.

  • Du kan placera parameterdeklarationer var som helst i mallfilen, även om det vanligtvis är en bra idé att placera dem överst i filen så att bicep-koden är lätt att läsa.

  • Det är en bra idé att ange den minsta och högsta teckenlängden för parametrar som kontrollerar namngivning. Dessa begränsningar hjälper till att undvika fel senare under distributionen.

Mer information om Bicep-parametrar finns i Parametrar i Bicep.

Variabler

  • När du definierar en variabel behövs inte datatypen. Variabler härlar typen från lösningsvärdet.

  • Du kan använda Bicep-funktioner för att skapa en variabel.

  • När en variabel har definierats i bicep-filen refererar du till värdet med variabelns namn.

Mer information om Bicep-variabler finns i Variables in Bicep.

Namn

  • Använd gemener av kamel gemener för namn, myVariableName till exempel eller myResource .

  • Funktionen uniqueString() är användbar för att skapa globalt unika resursnamn. När du anger samma parametrar returneras samma sträng varje gång. Om du skickar resursgrupps-ID:t innebär det att strängen är samma för varje distribution till samma resursgrupp, men olika när du distribuerar till olika resursgrupper eller prenumerationer.

  • Ibland skapar uniqueString() 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 här kravet innebär att det är en bra idé att använda stränginterpolation för att skapa resursnamn. Du kan lägga till ett prefix i den unika strängen.

  • Det är ofta en bra idé att använda malluttryck för att skapa resursnamn. Många Azure-resurstyper har regler för tillåtna tecken och längden på deras namn. Inbäddning av resursnamn i mallen innebär att alla som använder mallen inte behöver komma ihåg att följa de här reglerna själva.

  • Undvik att använda name i ett symboliskt namn. Det symboliska namnet representerar resursen, inte resursens namn. Till exempel, i stället för detta:

    resource cosmosDBAccountName 'Microsoft.DocumentDB/databaseAccounts@2021-04-15' = {

    använd följande:

    resource cosmosDBAccount 'Microsoft.DocumentDB/databaseAccounts@2021-04-15' = {

  • Undvik att särskilja variabler och parametrar med hjälp av suffix.

Resursdefinitioner

  • Använd variabler som innehåller uttrycken i stället för att bädda in komplexa uttryck direkt i resursegenskaper. Den här metoden gör din Bicep-fil lättare att läsa och förstå. Det undviker oreda i resursdefinitionerna med logik.

  • Försök att använda resursegenskaper som utdata i stället för att göra antaganden om hur resurser beter sig. Om du till exempel behöver mata ut URL:en till en App Service-app använder du egenskapen defaultHostname för appen i stället för att skapa en sträng för URL:en själv. Ibland stämmer inte dessa antaganden i olika miljöer eller resurserna ändrar hur de fungerar. Det är säkrare att få resursen att berätta sina egna egenskaper.

  • Det är en bra idé att använda en nyligen genomförd API-version för varje resurs. Nya funktioner i Azure-tjänster är ibland bara tillgängliga i nyare API-versioner.

  • Undvik att använda referens- och resourceId-funktionerna i bicep-filen när det är möjligt. Du kan komma åt alla resurser i Bicep med hjälp av det symboliska namnet. Om du till exempel definierar ett lagringskonto med det symboliska namnet toyDesignDocumentsStorageAccount kan du komma åt dess resurs-ID med hjälp av uttrycket toyDesignDocumentsStorageAccount.id . Genom att använda det symboliska namnet skapar du ett implicit beroende mellan resurser.

  • Använd gärna implicita beroenden framför explicita beroenden. Även om resursegenskapen gör att du kan deklarera ett explicit beroende mellan resurser, är det vanligtvis möjligt att använda den andra resursens egenskaper med hjälp av dependsOn dess symboliska namn. Detta skapar ett implicit beroende mellan de två resurserna och gör att Bicep kan hantera själva relationen.

  • Om resursen inte har distribuerats i Bicep-filen kan du fortfarande få en symbolisk referens till resursen med hjälp av existing nyckelordet .

Underordnade resurser

  • Undvik att kapsla för många lager. För mycket kapsling gör din Bicep-kod svårare att läsa och arbeta med.

  • Undvik att skapa resursnamn för underordnade resurser. Du förlorar de fördelar som Bicep ger när den förstår relationerna mellan dina resurser. Använd egenskapen parent eller kapsling i stället.

Utdata

  • Se till att du inte skapar utdata för känsliga data. Utdatavärden kan nås av alla som har åtkomst till distributionshistoriken. De är inte lämpliga för att hantera hemligheter.

  • I stället för att skicka egenskapsvärden runt via utdata använder du det befintliga nyckelordet för att söka efter egenskaper för resurser som redan finns. Det är bästa praxis att söka efter nycklar från andra resurser på det här sättet i stället för att skicka runt dem via utdata. Du får alltid de mest uppdaterade data.

Mer information om Bicep-utdata finns i Utdata i Bicep.

Klientorganisationsomfång

Du kan inte skapa principer eller rolltilldelningar i klientorganisationsomfånget. Men om du behöver bevilja åtkomst eller tillämpa principer i hela organisationen kan du distribuera dessa resurser till rothanteringsgruppen.

Nästa steg