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

Polecenia w tej lekcji są wyświetlane w celu zilustrowania pojęć. 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 podajesz wartości parametrów w pliku Bicep. Pliki parametrów są tworzone przy użyciu języka JavaScript Object Notation (JSON). Podczas wdrażania szablonu Bicep można podać plik parametrów. Oto jak wygląda plik parametrów:

{
  "$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 to właściwość, 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 plik parametrów o nazwie main.parameters.dev.json dla środowiska deweloperskiego i jeden o nazwie main.parameters.production.json dla środowiska produkcyjnego.

Uwaga

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 za pomocą az deployment group create polecenia można określić nazwę pliku parametrów, którego chcesz użyć z argumentem --parameters :

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

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

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

Zastępowanie 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.

Diagram that shows the order of precedence for parameter values. Parameter files override default values, and command-line parameter values override parameter files.

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 przesłonić jako własną wartość:

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

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

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

Przyjrzyjmy się wartościom.

Parametr 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 tierPremiumV3. 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.