Opération de simulation du déploiement Bicep
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.
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.
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.
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.
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.
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.
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.
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.
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 ressourcesNew-AzSubscriptionDeployment -Whatif
etNew-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 ressourcesNew-AzSubscriptionDeployment -Confirm
etNew-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
Pour afficher un aperçu des modifications avant de déployer un fichier Bicep, utilisez :
- az deployment group what-if pour les déploiements de groupes de ressources
- az deployment sub what-if pour les déploiements au niveau de l’abonnement
- az deployment mg what-if pour les déploiements de groupes de gestion
- az deployment tenant what-if pour les déploiements de locataires
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 à :
- az deployment group create
- az deployment sub create.
- az deployment mg create
- az deployment tenant create
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.
Pour l’API REST, utilisez :
- Déploiements – Simulation pour les déploiements de groupes de ressources
- Déploiements – Simulation au niveau de l’étendue d’abonnement pour les déploiements d’abonnements
- Déploiements What If au niveau de l’étendue du groupe d’administration pour les déploiements de groupes d’administration
- Déploiements What If au niveau de l’étendue du locataire pour les déploiements de locataires.
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 correspondresku.name
dans l’espace de nomsMicrosoft.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
.
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.
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"
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 :
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.
À 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
}
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"
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.
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
Vous pouvez utiliser l’opération de simulation par le biais des Kits de développement logiciel (SDK) Azure.
Pour Python, utilisez what-if (simulation).
Pour Java, utilisez DeploymentWhatIf Class.
Pour .NET, utilisez DeploymentWhatIf Class.
- Pour utiliser l’opération de simulation dans un pipeline, consultez Test ARM templates with What-If in a pipeline.
- Si vous constatez que l’opération de simulation génère des résultats incorrects, signalez les problèmes via https://aka.ms/whatifissues.
- Pour suivre un module Learn qui illustre l’utilisation des simulations, consultez les informations relatives à la prévisualisation des changements et validation des ressources Azure à l’aide de simulations et du kit de ressources de test de modèles ARM.