Podawanie wartości przy użyciu plików parametrów

Ukończone

W poprzednich lekcjach podano wartości parametrów w wierszu polecenia podczas tworzenia wdrożenia. Takie podejście działa dobrze podczas pisania i testowania plików Bicep, ale nie działa dobrze, gdy masz wiele parametrów lub gdy trzeba zautomatyzować wdrożenia. W tej lekcji dowiesz się więcej o różnych sposobach określenia wartości parametrów.

Uwaga / Notatka

Polecenia w tej jednostce są przedstawione, aby zilustrować pojęcia. Nie uruchamiaj jeszcze poleceń. Będziesz ćwiczyć to, czego nauczysz się tutaj wkrótce.

Tworzenie plików parametrów

Pliki parametrów ułatwiają określanie wartości parametrów razem jako zestawu. W pliku parametrów podaj wartości parametrów w pliku Bicep. pliki parametrów są tworzone przy użyciu pliku parametrów Bicep z rozszerzeniem pliku .bicepparam lub pliku parametrów JSON, który zawiera wartości parametrów. Podczas wdrażania szablonu Bicep można podać plik parametrów. Oto jak wygląda plik parametrów JSON:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentParameters.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "appServicePlanInstanceCount": {
      "value": 3
    },
    "appServicePlanSku": {
      "value": {
        "name": "P1v3",
        "tier": "PremiumV3"
      }
    },
    "cosmosDBAccountLocations": {
      "value": [
        {
          "locationName": "australiaeast"
        },
        {
          "locationName": "southcentralus"
        },
        {
          "locationName": "westeurope"
        }
      ]
    }
  }
}

Przyjrzyjmy się dokładniej każdej części pliku parametrów:

• $schema pomaga usłudze Azure Resource Manager zrozumieć, że ten plik jest plikiem parametrów.
• contentVersion jest właściwością, której można użyć do śledzenia znaczących zmian w pliku parametrów, jeśli chcesz. Zazwyczaj jest ona ustawiona na wartość domyślną 1.0.0.0.
• W parameters sekcji wymieniono każdy parametr i wartość, której chcesz użyć. Wartość parametru musi być określona jako obiekt. Obiekt ma właściwość o nazwie value , która definiuje rzeczywistą wartość parametru do użycia.

Ogólnie rzecz biorąc, utworzysz plik parametrów dla każdego środowiska. Dobrym rozwiązaniem jest uwzględnienie nazwy środowiska w nazwie pliku parametrów. Na przykład możesz mieć plik parametrów o nazwie main.parameters.dev.json dla środowiska deweloperskiego i jeden o nazwie main.parameters.production.json dla środowiska produkcyjnego.

Uwaga / Notatka

Upewnij się, że określono tylko wartości parametrów, które istnieją w szablonie Bicep. Podczas tworzenia wdrożenia platforma Azure sprawdza parametry i wyświetla błąd, jeśli podjęto próbę określenia wartości parametru, który nie znajduje się w pliku Bicep.

Używanie plików parametrów w czasie wdrażania

Podczas tworzenia nowego wdrożenia przy użyciu polecenia az deployment group create można określić nazwę pliku parametrów, którego chcesz użyć z argumentem --parameters:

az deployment group create \
  --name main \
  --template-file main.bicep \
  --parameters main.parameters.json

Podczas tworzenia nowego wdrożenia przy użyciu polecenia cmdlet New-AzResourceGroupDeployment można określić nazwę pliku parametrów, którego chcesz użyć z argumentem -TemplateParameterFile:

New-AzResourceGroupDeployment `
  -Name main `
  -TemplateFile main.bicep `
  -TemplateParameterFile main.parameters.json

Zastąp wartości parametrów

Znasz już trzy sposoby określania wartości parametrów: wartości domyślne, wiersz polecenia i pliki parametrów. Często używa się różnych metod określania różnych wartości dla tego samego parametru. To podejście było już widoczne podczas pracy z wartościami domyślnymi. Podczas tworzenia wartości domyślnej dla parametru, ale następnie określ inną wartość przy użyciu wiersza polecenia, wartość wiersza polecenia ma pierwszeństwo. Przyjrzyjmy się temu, jak pliki parametrów mieszczą się w tej kolejności pierwszeństwa.

Widać, że pliki parametrów zastępują wartości domyślne, a wartości parametrów wiersza polecenia zastępują pliki parametrów.

Zobaczmy, jak działa to podejście. Oto przykładowy plik Bicep, który definiuje trzy parametry, z których każdy ma wartości domyślne:

param location string = resourceGroup().location
param appServicePlanInstanceCount int = 1
param appServicePlanSku object = {
  name: 'F1'
  tier: 'Free'
}

Przyjrzyjmy się plikowi parametrów, który zastępuje wartość dwóch parametrów, ale nie określa wartości parametru location:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentParameters.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "appServicePlanInstanceCount": {
      "value": 3
    },
    "appServicePlanSku": {
      "value": {
        "name": "P1v3",
        "tier": "PremiumV3"
      }
    }
  }
}

Podczas tworzenia wdrożenia zastąpimy również wartość parametru appServicePlanInstanceCount. Podobnie jak w przypadku plików parametrów, należy użyć argumentu --parameters, ale dodajesz wartość, którą chcesz zastąpić jako własną wartość:

az deployment group create \
  --name main \
  --template-file main.bicep \
  --parameters main.parameters.json \
               appServicePlanInstanceCount=5

Podczas tworzenia wdrożenia zastąpisz wartość jednego z parametrów. Należy określić nazwę parametru tak, jakby był to argument polecenia cmdlet:

New-AzResourceGroupDeployment `
  -Name main `
  -TemplateFile main.bicep `
  -TemplateParameterFile main.parameters.json `
  -appServicePlanInstanceCount 5

Przyjrzyjmy się wartościom.

Parameter	Wartość	Wyjaśnienie
location	Lokalizacja grupy zasobów.	Plik Bicep określa ten parametr jako wartość domyślną i nie jest zastępowany.
appServicePlanSku	Obiekt z właściwością ustawioną name na P1v3 i z tier na PremiumV3.	Wartość domyślna w pliku Bicep jest zastępowana przez plik parametrów.
appServicePlanInstanceCount	5	Wartość określona w czasie wdrażania zastępuje wartość domyślną i wartość w pliku parametrów.

Używając kombinacji metod określania wartości parametrów, można uniknąć konieczności duplikowania wartości parametrów w wielu miejscach, jednocześnie zapewniając elastyczność zastępowania miejsca, w którym jest to konieczne.