Opération de simulation du déploiement Bicep

  • Article

Avant de déployer un modèle, vous pouvez obtenir un aperçu des modifications qui se produiront. Azure Resource Manager met à votre disposition l’opération de simulation, qui vous permet de voir comment les ressources changent si vous déployez le fichier Bicep. L’opération de simulation n’apporte aucune modification aux ressources existantes. Au lieu de cela, elle prédit les modifications si le fichier Bicep spécifié est déployé.

Vous pouvez utiliser l’opération de simulation avec des opérations d’Azure PowerShell, d’Azure CLI ou d’API REST. La simulation est prise en charge pour les déploiements de groupe de ressources, d’abonnement et de niveau locataire.

Pendant les opérations What-If, l’évaluation et l’expansion de templateLink ne sont pas prises en charge. Par conséquent, toutes les ressources déployées à l’aide de liens de modèle dans des déploiements imbriqués, y compris les références de spécifications de modèle, ne sont pas visibles dans les résultats de l’opération What-If.

Ressources de formation

Si vous préférez découvrir les opérations de simulation via des instructions d’aide pas à pas, consultez Prévisualiser les changements du déploiement Azure à l’aide de simulations.

Autorisations requises

Pour déployer un fichier Bicep ou un modèle ARM, vous devez disposer d’un accès en écriture aux ressources que vous déployez et un accès à toutes les opérations sur le type de ressource Microsoft.Resources/deployments. Par exemple, pour déployer une machine virtuelle, vous avez besoin des autorisations Microsoft.Compute/virtualMachines/write et Microsoft.Resources/deployments/*. L’opération de simulation présente les mêmes exigences d’autorisation.

Pour obtenir la liste des rôles et autorisations, consultez Rôles intégrés Azure.

Limites de la simulation

Une simulation développe des modèles imbriqués jusqu’à ce que ces limites soient atteintes :

  • 500 modèles imbriqués.
  • 800 groupes de ressources dans un déploiement inter-groupes de ressources.
  • 5 minutes pour développer les modèles imbriqués.

Lorsque l’une des limites est atteinte, le type de modification des ressources restantes est défini sur Ignorer.

Installer le module Azure PowerShell

Pour utiliser une simulation dans PowerShell, vous devez disposer de la version 4.2 ou d’une version ultérieure du module Az.

Pour installer le module, utilisez :

Install-Module -Name Az -Force

Pour plus d’informations sur l’installation des modules, consultez Installer Azure PowerShell.

Installer le module Azure CLI

Pour utiliser une simulation dans Azure CLI, vous devez disposer d’Azure CLI 2.14.0 ou d’une version ultérieure. Si nécessaire, installez la dernière version d’Azure CLI.

Afficher les résultats

Lorsque vous utilisez une simulation dans PowerShell ou Azure CLI, la sortie comprend des résultats à code de couleurs qui vous permettent de distinguer les différents types de modifications.

Opération de simulation de déploiement Bicep : charge utile de ressource complète et types de modification

La sortie de texte est :

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.

Notes

L’opération de simulation ne peut pas résoudre la fonction de référence. Chaque fois que vous définissez une propriété sur une expression de modèle qui inclut la fonction de référence, les rapports de simulation de la propriété changent. Ce comportement se produit parce que la simulation compare la valeur actuelle de la propriété (telle que true ou false pour une valeur booléenne) à l’expression de modèle non résolue. Évidemment, ces valeurs ne correspondent pas. Lorsque vous déployez le fichier Bicep, la propriété change uniquement lorsque la résolution de l’expression de modèle produit une valeur différente.

Commandes de simulation

Azure PowerShell

Pour afficher un aperçu des modifications avant de déployer un fichier Bicep, utilisez la commande New-AzResourceGroupDeployment ou New-AzSubscriptionDeployment. Ajoutez le paramètre de commutateur -Whatif à la commande de déploiement.

  • New-AzResourceGroupDeployment -Whatif pour des déploiements de groupes de ressources
  • New-AzSubscriptionDeployment -Whatif et New-AzDeployment -Whatif pour des déploiements au niveau de l’abonnement

Vous pouvez utiliser le paramètre de commutateur -Confirm pour afficher un aperçu des modifications et être invité à poursuivre le déploiement.

  • New-AzResourceGroupDeployment -Confirm pour des déploiements de groupes de ressources
  • New-AzSubscriptionDeployment -Confirm et New-AzDeployment -Confirm pour des déploiements au niveau de l’abonnement

Les commandes précédentes retournent un résumé sous forme de texte que vous pouvez inspecter manuellement. Pour obtenir un objet dont vous pouvez inspecter les modifications par programmation, utilisez la commande AzResourceGroupDeploymentWhatIfResult ou AzSubscriptionDeploymentWhatIfResult.

  • $results = Get-AzResourceGroupDeploymentWhatIfResult pour des déploiements de groupes de ressources
  • $results = Get-AzSubscriptionDeploymentWhatIfResult ou $results = Get-AzDeploymentWhatIfResult pour des déploiements au niveau de l’abonnement

Azure CLI

Pour afficher un aperçu des modifications avant de déployer un fichier Bicep, utilisez :

Vous pouvez utiliser le commutateur --confirm-with-what-if (ou sa forme courte -c) pour afficher un aperçu des modifications et être invité à poursuivre le déploiement. Ajoutez ce commutateur à :

Par exemple, utilisez az deployment group create --confirm-with-what-if ou -c pour des déploiements de groupe de ressources.

Les commandes précédentes retournent un résumé sous forme de texte que vous pouvez inspecter manuellement. Pour obtenir un objet JSON que vous pouvez inspecter par programme pour y détecter des modifications, utilisez le commutateur --no-pretty-print. Par exemple, utilisez az deployment group what-if --no-pretty-print pour des déploiements de groupe de ressources.

Si vous souhaitez retourner les résultats sans couleurs, ouvrez votre fichier de configuration d’Azure CLI. Définissez no_color sur Oui.

API REST Azure

Pour l’API REST, utilisez :

Types de modification

L’opération de simulation liste sept types différents de modifications :

  • Create : la ressource n’existe pas actuellement, mais elle est définie dans le fichier Bicep. La ressource est créée.
  • Delete : ce type de modification s’applique uniquement lorsque vous utilisez le mode complet pour le déploiement de modèle JSON. la ressource existe, mais elle n’est pas définie dans le fichier Bicep. En mode Complete, la ressource est supprimée. Seules les ressources qui prennent en charge la suppression en mode Complete sont incluses dans ce type de modification.
  • Ignore : la ressource existe, mais elle n’est pas définie dans le fichier Bicep. La ressource n’est pas déployée ou modifiée. Lorsque vous atteignez les limites de développement des modèles imbriqués, vous rencontrez ce type de modification. Si vous souhaitez en savoir plus, veuillez consulter la rubrique Limites de la simulation.
  • NoChange : la ressource existe et est définie dans le fichier Bicep. La ressource est redéployée, mais ses propriétés ne changent pas. Ce type de modification est retourné quand ResultFormat est défini sur FullResourcePayloads, qui est la valeur par défaut.
  • NoEffect : la propriété est en lecture seule et sera ignorée par le service. Par exemple, la propriété sku.tier est toujours définie pour correspondre sku.name dans l’espace de noms Microsoft.ServiceBus.
  • Modify : la ressource existe et est définie dans le fichier Bicep. La ressource est redéployée et ses propriétés changent. Ce type de modification est retourné quand ResultFormat est défini sur FullResourcePayloads, qui est la valeur par défaut.
  • Deploy : la ressource existe et est définie dans le fichier Bicep. La ressource est redéployée. Il est possible que les propriétés de la ressource changent. L’opération retourne ce type de modification quand elle ne dispose pas de suffisamment d’informations pour déterminer si des propriétés changeront. Vous n’observez cette condition que si ResultFormat est défini sur ResourceIdOnly.

Format de résultat

Vous pouvez contrôler le niveau de détail retourné sur les modifications prédites. Deux options s'offrent à vous :

  • FullResourcePayloads retourne la liste des ressources qui changeront et des détails sur les propriétés qui changeront.
  • ResourceIdOnly retourne la liste des ressources qui seront modifiées.

La valeur par défaut est FullResourcePayloads.

Pour les commandes de déploiement PowerShell, utilisez le paramètre -WhatIfResultFormat. Dans les commandes d’objet programmatique, utilisez le paramètre ResultFormat.

Pour Azure CLI, utilisez le paramètre --result-format.

Les résultats suivants illustrent les deux formats de sortie :

  • Charges utiles de ressources complètes

    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.

  • ID de ressource uniquement

    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.

Exécuter l’opération de simulation

Configurer l’environnement

Pour voir comment fonctionne la simulation, nous allons exécuter des tests. Tout d’abord, déployez un fichier Bicep qui crée un réseau virtuel. Vous utiliserez ce réseau virtuel pour tester dans quelle mesure les modifications sont signalées par l’opération de simulation. Téléchargez une copie du fichier 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'
        }
      }
    ]
  }
}

Pour déployer le fichier Bicep, utilisez :

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

Modification de test

Une fois le déploiement terminé, vous êtes prêt à tester l’opération de simulation. Cette fois, vous déployez un fichier Bicep qui modifie le réseau virtuel. Il manque une des balises d’origine, un sous-réseau a été supprimé et le préfixe de l’adresse a changé. Téléchargez une copie du fichier Bicep.

resource vnet 'Microsoft.Network/virtualNetworks@2023-11-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'
        }
      }
    ]
  }
}

Pour afficher les modifications, utilisez :

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

La sortie de simulation ressemble à ceci :

Sortie de l’opération de simulation du déploiement Bicep

La sortie de texte est :

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.

Notez que, en haut de la sortie, les couleurs sont définies pour indiquer le type de modifications.

Au bas de la sortie apparaît la balise indiquant que le propriétaire a été supprimé. Le préfixe d’adresse est passé de 10.0.0.0/16 à 10.0.0.0/15. Le sous-réseau nommé subnet001 a été supprimé. N’oubliez pas que ces modifications n’ont pas été déployées. Vous voyez un aperçu des modifications qui se produiront si vous déployez le fichier Bicep.

Certaines des propriétés répertoriées comme supprimées ne seront pas modifiées. Les propriétés peuvent être incorrectement signalées comme supprimées lorsqu’elles ne sont pas dans le fichier Bicep, mais elles sont automatiquement définies comme valeurs par défaut lors du déploiement. Ce résultat est considéré comme du « bruit » dans la réponse de simulation. La ressource déployée finale aura les valeurs définies pour les propriétés. À mesure que l’opération de simulation évolue, ces propriétés sont exclues du résultat.

Évaluer par programmation les résultats de l’opération de simulation

À présent, nous allons évaluer par programmation les résultats de l’opération de simulation en définissant la commande sur une variable.

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

Vous pouvez voir un résumé de chaque modification.

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

Confirmer la suppression

Pour afficher un aperçu des modifications avant de déployer un fichier Bicep, utilisez le paramètre de commutateur de confirmation avec la commande de déploiement. Si les modifications sont bien celles que vous attendiez, répondez que vous souhaitez que le déploiement s’accomplisse.

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

Sortie de l’opération de simulation du déploiement Bicep - Mode déploiement terminé

La sortie de texte est :

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"):

Vous voyez les modifications attendues et pouvez confirmer que vous souhaitez que le déploiement s’exécute.

Nettoyer les ressources

Lorsque vous n’avez plus besoin des exemples de ressources, utilisez Azure CLI ou Azure PowerShell pour supprimer le groupe de ressources.

az group delete --name ExampleGroup

Kits SDK

Vous pouvez utiliser l’opération de simulation par le biais des Kits de développement logiciel (SDK) Azure.

Étapes suivantes