Udostępnij za pośrednictwem


Operacja analizy warunkowej wdrożenia Bicep

Przed wdrożeniem pliku Bicep można wyświetlić podgląd zmian, które zostaną wprowadzone. Usługa Azure Resource Manager udostępnia operację analizy co-jeżeli, aby zobaczyć, jak zasoby zmienią się w przypadku wdrożenia pliku Bicep. Operacja warunkowa nie wprowadza żadnych zmian w istniejących zasobach. Zamiast tego przewiduje zmiany w przypadku wdrożenia określonego pliku Bicep.

Możesz użyć operacji analizy co-jeżeli z operacjami programu Visual Studio Code, programu Azure PowerShell, interfejsu wiersza polecenia platformy Azure lub interfejsu API REST. Analiza "co, jeśli" jest obsługiwana w przypadku wdrożeń na poziomie grupy zasobów, subskrypcji, grup zarządzania i dzierżawy.

Podczas operacji co-jeśli ocena i rozszerzenie templateLink nie są obsługiwane. W związku z tym wszystkie zasoby wdrożone przy użyciu linków szablonów w zagnieżdżonych wdrożeniach, w tym odwołania do specyfikacji szablonu, nie będą widoczne w wynikach operacji What-If.

Zasoby szkoleniowe

Jeśli wolisz dowiedzieć się więcej na temat operacji analizy co-jeżeli, korzystając ze wskazówek krok po kroku, zobacz Podgląd zmian wdrażania platformy Azure przy użyciu analizy co-jeżeli.

Wymagane uprawnienia

Aby wdrożyć plik Bicep lub szablon ARM, potrzebujesz uprawnień do zapisu dla zasobów, które wdrażasz, oraz dostępu do wszystkich operacji na typie zasobu Microsoft.Resources/deployments. Na przykład, aby wdrożyć maszynę wirtualną, potrzebujesz uprawnień Microsoft.Compute/virtualMachines/write i Microsoft.Resources/deployments/*. Operacja "co-jeśli" ma te same wymagania dotyczące uprawnień.

Aby uzyskać listę ról i uprawnień, zobacz Role wbudowane platformy Azure.

Limity hipotetyczne

Co-jeżeli rozszerza zagnieżdżone szablony do momentu osiągnięcia tych limitów:

  • 500 zagnieżdżonych szablonów.
  • 800 grup zasobów w wdrożeniu międzygrupowym zasobów.
  • 5 minut zajęło wykonanie rozszerzenia zagnieżdżonych szablonów.

Po osiągnięciu jednego z limitów pozostały typ zmiany zasobów jest ustawiony na Ignoruj.

Instalowanie modułu programu Azure PowerShell

Aby użyć opcji what-if w PowerShell, musisz mieć moduł Az w wersji 4.2 lub nowszej.

Aby zainstalować moduł, użyj:

Install-Module -Name Az -Force

Aby uzyskać więcej informacji na temat instalowania modułów, zobacz Instalowanie programu Azure PowerShell.

Instalowanie modułu interfejsu wiersza polecenia platformy Azure

Aby użyć funkcji 'what-if' w Azure CLI, musisz mieć Azure CLI w wersji 2.14.0 lub nowszej. W razie potrzeby zainstaluj najnowszą wersję interfejsu wiersza polecenia platformy Azure.

Zobacz wyniki

W przypadku korzystania z analizy co-jeżeli w programie PowerShell lub interfejsie wiersza polecenia platformy Azure dane wyjściowe zawierają wyniki kodowane kolorami, które ułatwiają wyświetlanie różnych typów zmian.

Operacja typu

Dane wyjściowe tekstu to:

Resource and property changes are indicated with these symbols:
  - Delete
  + Create
  ~ Modify

The deployment will update the following scope:

Scope: /subscriptions/./resourceGroups/ExampleGroup

  ~ Microsoft.Network/virtualNetworks/vnet-001 [2018-10-01]
    - tags.Owner: "Team A"
    ~ properties.addressSpace.addressPrefixes: [
      - 0: "10.0.0.0/16"
      + 0: "10.0.0.0/15"
      ]
    ~ properties.subnets: [
      - 0:

          name:                     "subnet001"
          properties.addressPrefix: "10.0.0.0/24"

      ]

Resource changes: 1 to modify.

Uwaga

Operacja analizy co-jeżeli nie może rozpoznać funkcji odwołania. Za każdym razem, gdy ustawiasz właściwość na wyrażenie szablonu zawierające funkcję referencyjną, raport what-if zgłasza, że właściwość się zmieni. To zachowanie występuje, ponieważ analiza what-if porównuje bieżącą wartość właściwości (np. true lub false dla wartości logicznej) z nierozwiązanym wyrażeniem szablonu. Oczywiście te wartości nie będą zgodne. Podczas wdrażania pliku Bicep właściwość zmieni się tylko wtedy, gdy wyrażenie szablonu zostanie rozpoznane na inną wartość.

Polecenia warunkowe

Azure PowerShell

Aby wyświetlić podgląd zmian przed wdrożeniem pliku Bicep, użyj polecenia New-AzResourceGroupDeployment lub New-AzSubscriptionDeployment. Dodaj parametr przełącznika -Whatif do polecenia wdrożenia.

  • New-AzResourceGroupDeployment -Whatif w przypadku wdrożeń grup zasobów
  • New-AzSubscriptionDeployment -Whatif i New-AzDeployment -Whatif dla wdrożeń na poziomie subskrypcji

Możesz użyć parametru przełącznika -Confirm, aby wyświetlić podgląd zmian i otrzymać komunikat z pytaniem o kontynuowanie wdrażania.

  • New-AzResourceGroupDeployment -Confirm w przypadku wdrożeń grup zasobów
  • New-AzSubscriptionDeployment -Confirm i New-AzDeployment -Confirm dla wdrożeń na poziomie subskrypcji

Powyższe polecenia zwracają podsumowanie tekstowe, które można ręcznie sprawdzić. Aby uzyskać obiekt, który można programowo sprawdzić pod kątem zmian, użyj polecenia Get-AzResourceGroupDeploymentWhatIfResult lub Get-AzSubscriptionDeploymentWhatIfResult.

  • $results = Get-AzResourceGroupDeploymentWhatIfResult w przypadku wdrożeń grup zasobów
  • $results = Get-AzSubscriptionDeploymentWhatIfResult lub $results = Get-AzDeploymentWhatIfResult w przypadku wdrożeń na poziomie subskrypcji

Interfejs wiersza polecenia platformy Azure

Aby wyświetlić podgląd zmian przed wdrożeniem pliku Bicep, użyj:

Możesz użyć przełącznika --confirm-with-what-if (lub jego krótszej wersji -c), aby wyświetlić podgląd zmian i wyświetlić monit o kontynuowanie wdrażania. Dodaj ten przełącznik do:

Na przykład użyj polecenia az deployment group create --confirm-with-what-if lub -c w przypadku wdrożeń grup zasobów.

Powyższe polecenia zwracają podsumowanie tekstowe, które można ręcznie sprawdzić. Aby uzyskać obiekt JSON, który można programowo sprawdzić pod kątem zmian, użyj przełącznika --no-pretty-print . Na przykład użyj az deployment group what-if --no-pretty-print dla wdrożeń grup zasobów.

Jeśli chcesz zwrócić wyniki bez kolorów, otwórz plik konfiguracji interfejsu wiersza polecenia platformy Azure. Ustaw no_color na tak.

Interfejs REST API Azure

W przypadku interfejsu API REST użyj:

Typy zmian

Operacja analizy co-jeżeli zawiera listę siedmiu różnych typów zmian:

  • Utwórz: zasób nie istnieje obecnie, ale jest zdefiniowany w pliku Bicep. Zasób zostanie utworzony.
  • Usuń: ten typ zmiany ma zastosowanie tylko w przypadku korzystania z trybu pełnego wdrożenia szablonu JSON. Zasób istnieje, ale nie jest zdefiniowany w pliku Bicep. W przypadku trybu pełnego zasób zostanie usunięty. Tylko zasoby, które obsługują usuwanie w trybie pełnym są uwzględniane w ramach tego typu zmian.
  • Ignoruj: zasób istnieje, ale nie jest zdefiniowany w pliku Bicep. Zasób nie zostanie wdrożony ani zmodyfikowany. Gdy osiągniesz limity rozszerzania zagnieżdżonych szablonów, wystąpi ten typ zmiany. Zobacz Limity warunkowe.
  • NoChange: zasób istnieje i jest zdefiniowany w pliku Bicep. Zasób zostanie wdrożony ponownie, ale właściwości zasobu nie ulegną zmianie. Ten typ zmiany jest zwracany, gdy parametr ResultFormat jest ustawiony na FullResourcePayloadswartość , która jest wartością domyślną.
  • NoEffect: właściwość jest gotowa i zostanie zignorowana przez usługę. Na przykład właściwość sku.tier jest zawsze ustawiona tak, aby odpowiadała sku.name w przestrzeni nazw Microsoft.ServiceBus.
  • Modyfikuj: zasób istnieje i jest zdefiniowany w pliku Bicep. Zasób zostanie wdrożony ponownie i właściwości zasobu ulegną zmianie. Ten typ zmiany jest zwracany, gdy parametr ResultFormat jest ustawiony na FullResourcePayloadswartość , która jest wartością domyślną.
  • Wdrażanie: zasób istnieje i jest zdefiniowany w pliku Bicep. Zasób zostanie wdrożony ponownie. Właściwości zasobu mogą, ale nie muszą ulec zmianie. Operacja zwraca ten typ zmiany, jeśli nie ma wystarczających informacji, aby określić, czy jakieś właściwości ulegną zmianie. Ten warunek jest widoczny tylko wtedy, gdy parametr ResultFormat jest ustawiony na ResourceIdOnlywartość .

Format wyniku

Ty kontrolujesz poziom szczegółowości, który jest zwracany dotyczący przewidywanych zmian. Dostępne są dwie opcje:

  • FullResourcePayloads — zwraca listę zasobów, które zmienią się i szczegółowe informacje o właściwościach, które zostaną zmienione
  • ResourceIdOnly — zwraca listę zasobów, które zostaną zmienione

Wartość domyślna to FullResourcePayloads.

W przypadku poleceń wdrażania programu PowerShell użyj parametru -WhatIfResultFormat . W poleceniach obiektu programowego użyj parametru ResultFormat .

W przypadku interfejsu wiersza polecenia platformy Azure użyj parametru --result-format .

W poniższych wynikach przedstawiono dwa różne formaty danych wyjściowych:

  • Pełne ładunki zasobów

    Resource and property changes are indicated with these symbols:
      - Delete
      + Create
      ~ Modify
    
    The deployment will update the following scope:
    
    Scope: /subscriptions/./resourceGroups/ExampleGroup
    
      ~ Microsoft.Network/virtualNetworks/vnet-001 [2018-10-01]
        - tags.Owner: "Team A"
        ~ properties.addressSpace.addressPrefixes: [
          - 0: "10.0.0.0/16"
          + 0: "10.0.0.0/15"
          ]
        ~ properties.subnets: [
          - 0:
    
            name:                     "subnet001"
            properties.addressPrefix: "10.0.0.0/24"
    
          ]
    
    Resource changes: 1 to modify.
    
  • Tylko identyfikator zasobu

    Resource and property changes are indicated with this symbol:
      ! Deploy
    
    The deployment will update the following scope:
    
    Scope: /subscriptions/./resourceGroups/ExampleGroup
    
      ! Microsoft.Network/virtualNetworks/vnet-001
    
    Resource changes: 1 to deploy.
    

Uruchom operację co-jeżeli

Konfigurowanie środowiska

Aby zobaczyć, jak działa strategia co-jeżeli, uruchomimy kilka testów. Najpierw wdróż plik Bicep, który tworzy sieć wirtualną. Użyjesz tej sieci wirtualnej, aby przetestować sposób raportowania zmian według analizy co-jeżeli. Pobierz kopię pliku Bicep.

resource vnet 'Microsoft.Network/virtualNetworks@2023-11-01' = {
  name: 'vnet-001'
  location: resourceGroup().location
  tags: {
    CostCenter: '12345'
    Owner: 'Team A'
  }
  properties: {
    addressSpace: {
      addressPrefixes: [
        '10.0.0.0/16'
      ]
    }
    enableVmProtection: false
    enableDdosProtection: false
    subnets: [
      {
        name: 'subnet001'
        properties: {
          addressPrefix: '10.0.0.0/24'
        }
      }
      {
        name: 'subnet002'
        properties: {
          addressPrefix: '10.0.1.0/24'
        }
      }
    ]
  }
}

Aby wdrożyć plik Bicep, użyj:

New-AzResourceGroup `
  -Name ExampleGroup `
  -Location centralus
New-AzResourceGroupDeployment `
  -ResourceGroupName ExampleGroup `
  -TemplateFile "what-if-before.bicep"

Modyfikacja testowa

Po zakończeniu wdrażania możesz przetestować operację analizy warunkowej. Tym razem wdrożysz plik Bicep, który zmienia sieć wirtualną. Brakuje jednego z oryginalnych tagów, usunięto podsieć i zmieniono prefiks adresu. Pobierz kopię pliku Bicep.

resource vnet 'Microsoft.Network/virtualNetworks@2024-05-01' = {
  name: 'vnet-001'
  location: resourceGroup().location
  tags: {
    CostCenter: '12345'
  }
  properties: {
    addressSpace: {
      addressPrefixes: [
        '10.0.0.0/15'
      ]
    }
    enableVmProtection: false
    enableDdosProtection: false
    subnets: [
      {
        name: 'subnet002'
        properties: {
          addressPrefix: '10.0.1.0/24'
        }
      }
    ]
  }
}

Aby wyświetlić zmiany, użyj:

New-AzResourceGroupDeployment `
  -Whatif `
  -ResourceGroupName ExampleGroup `
  -TemplateFile "what-if-after.bicep"

Wynik scenariusza "co-jeśli" wygląda podobnie do poniższego:

Dane wyjściowe operacji analizy warunkowej wdrożenia Bicep

Dane wyjściowe tekstu to:

Resource and property changes are indicated with these symbols:
  - Delete
  + Create
  ~ Modify

The deployment will update the following scope:

Scope: /subscriptions/./resourceGroups/ExampleGroup

  ~ Microsoft.Network/virtualNetworks/vnet-001 [2018-10-01]
    - tags.Owner:                    "Team A"
    + properties.enableVmProtection: false
    ~ properties.addressSpace.addressPrefixes: [
      - 0: "10.0.0.0/16"
      + 0: "10.0.0.0/15"
      ]
    ~ properties.subnets: [
      - 0:

          name:                     "subnet001"
          properties.addressPrefix: "10.0.0.0/24"

      ]

Resource changes: 1 to modify.

Zwróć uwagę u góry danych wyjściowych, że kolory są zdefiniowane, aby wskazywać typ zmian.

Na dole danych wyjściowych jest wyświetlane, że tag Właściciel został usunięty. Prefiks adresu został zmieniony z 10.0.0.0/16 na 10.0.0.0/15. Usunięto podsieć o nazwie subnet001. Pamiętaj, że te zmiany nie zostały wdrożone. Zostanie wyświetlony podgląd zmian, które wystąpią w przypadku wdrożenia pliku Bicep.

Niektóre właściwości wymienione jako usunięte nie zostaną rzeczywiście zmienione. Właściwości mogą być niepoprawnie zgłaszane jako usunięte, gdy nie znajdują się w pliku Bicep, ale są automatycznie ustawiane podczas wdrażania jako wartości domyślne. Ten wynik jest uznawany za "szum" w odpowiedzi warunkowej. Ostatni wdrożony zasób będzie miał wartości ustawione dla właściwości. W miarę dojrzewania operacji analizy co-jeżeli te właściwości zostaną odfiltrowane z wyniku.

Programowe ocenianie wyników analizy warunkowej

Teraz programowo oceńmy wyniki analizy co-jeżeli, ustawiając polecenie jako zmienną.

$results = Get-AzResourceGroupDeploymentWhatIfResult `
  -ResourceGroupName ExampleGroup `
  --template-file "what-if-after.bicep"

Możesz wyświetlić podsumowanie każdej zmiany.

foreach ($change in $results.Changes)
{
  $change.Delta
}

Potwierdź usunięcie

Aby wyświetlić podgląd zmian przed wdrożeniem pliku Bicep, użyj przełącznika potwierdzenia w poleceniu wdrożenia. Jeśli zmiany są zgodnie z oczekiwaniami, odpowiedz, że wdrożenie ma zostać ukończone.

New-AzResourceGroupDeployment `
  -ResourceGroupName ExampleGroup `
  -Confirm `
  -TemplateFile "what-if-after.bicep"

Tryb wdrażania Bicep dla operacji typu

Dane wyjściowe tekstu to:

Resource and property changes are indicated with these symbols:
  - Delete
  + Create
  ~ Modify

The deployment will update the following scope:

Scope: /subscriptions/./resourceGroups/ExampleGroup

  ~ Microsoft.Network/virtualNetworks/vnet-001 [2018-10-01]
    - tags.Owner:                    "Team A"
    + properties.enableVmProtection: false
    ~ properties.addressSpace.addressPrefixes: [
      - 0: "10.0.0.0/16"
      + 0: "10.0.0.0/15"
      ]
    ~ properties.subnets: [
      - 0:

          name:                     "subnet001"
          properties.addressPrefix: "10.0.0.0/24"

      ]

Resource changes: 1 to modify.

Are you sure you want to execute the deployment?
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is "Y"):

Zobaczysz oczekiwane zmiany i możesz potwierdzić, że wdrożenie ma zostać uruchomione.

Czyszczenie zasobów

Jeśli nie potrzebujesz już przykładowych zasobów, użyj interfejsu wiersza polecenia platformy Azure lub programu Azure PowerShell, aby usunąć grupę zasobów.

az group delete --name ExampleGroup

SDK

Możesz użyć operacji analizy co-jeżeli za pomocą zestawów SDK platformy Azure.

Następne kroki