Dela via

Distribuera resurser med Bicep och Azure CLI

  • Artikel

Den här artikeln beskriver hur du använder Azure CLI med Bicep-filer för att distribuera dina resurser till Azure. Om du inte är bekant med begreppen att distribuera och hantera dina Azure-lösningar kan du läsa översikten över Bicep.

Förutsättningar

Du behöver en Bicep-fil för att distribuera. Filen måste vara lokal.

Du behöver Azure CLI och vara ansluten till Azure:

  • Installera Azure CLI-kommandon på den lokala datorn. För att distribuera Bicep-filer behöver du Azure CLI version 2.20.0 eller senare.
  • Anslut till Azure med az login. Om du har flera Azure-prenumerationer kan du också behöva köra az account set.

Exempel för Azure CLI skrivs för bash gränssnittet. Om du vill köra det här exemplet i Windows PowerShell eller kommandotolken kan du behöva ändra element i skriptet.

Om du inte har Installerat Azure CLI kan du använda Azure Cloud Shell. Mer information finns i Distribuera Bicep-filer från Azure Cloud Shell.

Behörigheter som krävs

Om du vill distribuera en Bicep-fil eller en ARM-mall måste du ha skrivåtkomst till de resurser som du distribuerar och åtkomst till alla åtgärder i resurstypen Microsoft.Resources/deployments. Om du till exempel vill distribuera en virtuell dator behöver Microsoft.Compute/virtualMachines/write du och Microsoft.Resources/deployments/* behörigheter. Konsekvensåtgärden har samma behörighetskrav.

Det finns en lista med roller och behörigheter i Inbyggda roller i Azure.

Distributionsomfång

Du kan rikta distributionen mot en resursgrupp, prenumeration, hanteringsgrupp eller klientorganisation. Beroende på omfånget för distributionen använder du olika kommandon.

För varje omfång måste användaren som distribuerar Bicep-filen ha de behörigheter som krävs för att skapa resurser.

Distribuera lokal Bicep-fil

Du kan distribuera en Bicep-fil från den lokala datorn eller en som lagras externt. I det här avsnittet beskrivs hur du distribuerar en lokal Bicep-fil.

Om du distribuerar till en resursgrupp som inte finns skapar du resursgruppen. Namnet på resursgruppen kan bara innehålla alfanumeriska tecken, punkter, understreck, bindestreck och parenteser. Det kan vara upp till 90 tecken. Namnet kan inte sluta i en punkt.

az group create --name ExampleGroup --location "Central US"

Om du vill distribuera en lokal Bicep-fil använder du växeln --template-file i distributionskommandot. I följande exempel visas också hur du anger ett parametervärde.

az deployment group create \
  --name ExampleDeployment \
  --resource-group ExampleGroup \
  --template-file <path-to-bicep> \
  --parameters storageAccountType=Standard_GRS

Det kan ta några minuter att slutföra distributionen. När det är klart visas ett meddelande som innehåller resultatet:

"provisioningState": "Succeeded",

Distribuera fjärr-Bicep-fil

För närvarande stöder Inte Azure CLI distribution av fjärranslutna Bicep-filer. Du kan använda Bicep CLI för att skapa Bicep-filen till en JSON-mall och sedan läsa in JSON-filen till fjärrplatsen. Mer information finns i Distribuera ARM JSON-fjärrmallar.

Parametrar

Om du vill skicka parametervärden kan du använda antingen infogade parametrar eller en parameterfil. Parameterfilen kan vara antingen en Bicep-parameterfil eller en JSON-parameterfil.

Infogade parametrar

Om du vill skicka infogade parametrar anger du värdena i parameters. Om du till exempel vill skicka en sträng och matris till en Bicep-fil i ett Bash-gränssnitt använder du:

az deployment group create \
  --resource-group testgroup \
  --template-file <path-to-bicep> \
  --parameters exampleString='inline string' exampleArray='["value1", "value2"]'

Om du använder Azure CLI med Windows-kommandotolken (CMD) eller PowerShell skickar du matrisen i formatet: exampleArray="['value1','value2']".

Du kan också hämta innehållet i filen och ange innehållet som en infogad parameter. Förorda filnamnet med @.

az deployment group create \
  --resource-group testgroup \
  --template-file <path-to-bicep> \
  --parameters exampleString=@stringContent.txt exampleArray=@arrayContent.json

Det är praktiskt att hämta ett parametervärde från en fil när du behöver ange konfigurationsvärden. Du kan till exempel ange cloud-init-värden för en virtuell Linux-dator.

Formatet arrayContent.json är:

[
  "value1",
  "value2"
]

Om du till exempel vill skicka in ett objekt för att ange taggar använder du JSON. Bicep-filen kan till exempel innehålla en parameter som den här:

"resourceTags": {
  "type": "object",
  "defaultValue": {
    "Cost Center": "IT Department"
  }
}

I det här fallet kan du skicka in en JSON-sträng för att ange parametern enligt följande Bash-skript:

tags='{"Owner":"Contoso","Cost Center":"2345-324"}'
az deployment group create --name addstorage  --resource-group myResourceGroup \
--template-file $bicepFile \
--parameters resourceName=abcdef4556 resourceTags="$tags"

Använd dubbla citattecken runt den JSON som du vill skicka till objektet.

Om du använder Azure CLI med Windows-kommandotolken (CMD) eller PowerShell skickar du objektet i följande format:

$tags="{'Owner':'Contoso','Cost Center':'2345-324'}"
az deployment group create --name addstorage  --resource-group myResourceGroup \
--template-file $bicepFile \
--parameters resourceName=abcdef4556 resourceTags=$tags

Du kan använda en variabel för att innehålla parametervärdena. I Bash anger du variabeln till alla parametervärden och lägger till den i distributionskommandot.

params="prefix=start suffix=end"

az deployment group create \
  --resource-group testgroup \
  --template-file <path-to-bicep> \
  --parameters $params

Men om du använder Azure CLI med Windows Command Prompt (CMD) eller PowerShell anger du variabeln till en JSON-sträng. Undvik citattecknen: $params = '{ \"prefix\": {\"value\":\"start\"}, \"suffix\": {\"value\":\"end\"} }'.

Utvärderingen av parametrar följer en sekventiell ordning, vilket innebär att om ett värde tilldelas flera gånger används endast det senast tilldelade värdet. För att säkerställa rätt parametertilldelning rekommenderar vi att du anger parameterfilen initialt och selektivt åsidosätter specifika parametrar med hjälp av KEY=VALUE-syntaxen . Det är viktigt att nämna att om du anger en bicepparam parameterfil kan du bara använda det här argumentet en gång.

Bicep-parameterfiler

I stället för att skicka parametrar som infogade värden i skriptet kan det vara enklare att använda en parameterfil, antingen en Bicep-parameterfil eller en JSON-parameterfil som innehåller parametervärdena. Parameterfilen måste vara en lokal fil. Externa parameterfiler stöds inte med Azure CLI. Mer information om parameterfilen finns i Skapa Resource Manager-parameterfil.

Med Azure CLI version 2.53.0 eller senare och Bicep CLI version 0.22.X eller senare kan du distribuera en Bicep-fil genom att använda en Bicep-parameterfil. Med -instruktionen using i Bicep-parameterfilen behöver du inte ange växeln --template-file när du anger en Bicep-parameterfil för växeln --parameters . Om du inkluderar växeln --template-file resulterar det i felet "Endast en .bicep-mall tillåts med en .bicepparam-fil".

I följande exempel visas en parameterfil med namnet storage.bicepparam. Filen finns i samma katalog där kommandot körs.

az deployment group create \
  --name ExampleDeployment \
  --resource-group ExampleGroup \
  --parameters storage.bicepparam

JSON-parameterfiler

I följande exempel visas en parameterfil med namnet storage.parameters.json. Filen finns i samma katalog där kommandot körs.

az deployment group create \
  --name ExampleDeployment \
  --resource-group ExampleGroup \
  --template-file storage.bicep \
  --parameters '@storage.parameters.json'

Mer information om parameterfilen finns i Skapa Resource Manager-parameterfil.

Du kan använda infogade parametrar och en platsparametrarfil i samma distributionsåtgärd. Mer information finns i Parameterprioret.

Förhandsgranska ändringar

Innan du distribuerar Bicep-filen kan du förhandsgranska de ändringar som Bicep-filen kommer att göra i din miljö. Använd konsekvensåtgärden för att kontrollera att Bicep-filen gör de ändringar som du förväntar dig. What-if validerar även Bicep-filen för fel.

Distribuera mallspecifikationer

För närvarande har Azure CLI inte stöd för att skapa mallspecifikationer genom att tillhandahålla Bicep-filer. Du kan dock skapa en Bicep-fil med resursen Microsoft.Resources/templateSpecs för att distribuera en mallspecifikation. Exemplet på specifikationen Skapa mall visar hur du skapar en mallspecifikation i en Bicep-fil. Du kan också skapa Bicep-filen till JSON med hjälp av Bicep CLI och sedan skapa en mallspecifikation med JSON-mallen.

Distributionsnamnet

När du distribuerar en Bicep-fil kan du ge distributionen ett namn. Det här namnet kan hjälpa dig att hämta distributionen från distributionshistoriken. Om du inte anger något namn för distributionen används namnet på Bicep-filen. Om du till exempel distribuerar en Bicep-fil med namnet main.bicep och inte anger något distributionsnamn, heter maindistributionen .

Varje gång du kör en distribution läggs en post till i resursgruppens distributionshistorik med distributionsnamnet. Om du kör en annan distribution och ger den samma namn ersätts den tidigare posten med den aktuella distributionen. Om du vill behålla unika poster i distributionshistoriken ger du varje distribution ett unikt namn.

Om du vill skapa ett unikt namn kan du tilldela ett slumptal.

deploymentName='ExampleDeployment'$RANDOM

Eller lägg till ett datumvärde.

deploymentName='ExampleDeployment'$(date +"%d-%b-%Y")

Om du kör samtidiga distributioner till samma resursgrupp med samma distributionsnamn slutförs endast den senaste distributionen. Alla distributioner med samma namn som inte har slutförts ersätts av den senaste distributionen. Om du till exempel kör en distribution med namnet newStorage som distribuerar ett lagringskonto med namnet storage1och samtidigt kör en annan distribution med namnet newStorage som distribuerar ett lagringskonto med namnet storage2distribuerar du bara ett lagringskonto. Det resulterande lagringskontot heter storage2.

Men om du kör en distribution med namnet newStorage som distribuerar ett lagringskonto med namnet storage1och omedelbart efter att den har slutförts kör du en annan distribution med namnet newStorage som distribuerar ett lagringskonto med namnet storage2, så har du två lagringskonton. Den ena heter storage1och den andra heter storage2. Men du har bara en post i distributionshistoriken.

När du anger ett unikt namn för varje distribution kan du köra dem samtidigt utan konflikter. Om du kör en distribution med namnet newStorage1 som distribuerar ett lagringskonto med namnet storage1och samtidigt kör en annan distribution med namnet newStorage2 som distribuerar ett lagringskonto med namnet storage2, har du två lagringskonton och två poster i distributionshistoriken.

För att undvika konflikter med samtidiga distributioner och för att säkerställa unika poster i distributionshistoriken ger du varje distribution ett unikt namn.

Nästa steg