Prévisualiser les modifications apportées à la pile de déploiement à l’aide de What-If

Avant de créer ou de mettre à jour une pile de déploiement Azure, prévisualisez les modifications effectuées par la pile en utilisant l’opération « et si ». L’opération de simulation n’apporte aucune modification aux ressources existantes. En revanche, il prédit les modifications qui se produiraient si vous appliquiez la pile avec le modèle et les paramètres spécifiés. Parce qu’une pile de déploiement gère un ensemble de ressources comme une unité unique, il est particulièrement utile de prévisualiser les modifications à l’aide de what-if. Vous pouvez confirmer quelles ressources ont été créées, mises à jour ou laissées inchangées. Vous pouvez aussi capturer des ressources qui deviennent non gérées (détachées ou supprimées) avant d’appliquer le changement.

Opération what-if pour les déploiements Bicep

L’opération « et si » est une fonctionnalité des déploiements de modèles Azure Resource Manager qui prévisualise les modifications apportées par un déploiement avant que vous ne les appliquez. Il est disponible pour les déploiements Bicep standards et pour les piles de déploiement. Pour une description complète du fonctionnement de l’opération, des types de changements qu’elle rapporte et de ses limitations, voir Aperçu des changements de déploiement de Bicep en utilisant le « et si ». Le reste de cet article porte sur l’utilisation de what-if avec les piles de déploiement.

Différences entre les résultats What-If d’une pile et ceux d’un déploiement

Si vous passez des déploiements aux piles de déploiement, la différence la plus importante réside dans l’emplacement où se trouve le résultat.

Pour un déploiement standard, le « et si » est une opération. Vous l’exécutez, Azure renvoie les changements prédits, et rien n’est stocké ensuite.

Pour une pile de déploiement, What-If crée une ressource de résultat What-If. Le résultat est une ressource Azure autonome de type Microsoft.Resources/deploymentStacksWhatIfResults que vous nommez vous-même, et qui fait référence à la pile contre laquelle elle a été évaluée plutôt qu’à une opération sur cette pile. Parce que le résultat est une ressource à part entière, vous pouvez la récupérer, partager son identifiant de ressource, puis la supprimer plus tard.

Caractéristique Simulation de déploiement Pile de déploiement What-If
Formulaire Une opération qui retourne un résultat Une ressource que vous créez
Name Non nommé Tu donnes un nom
Type de ressource Sans objet Microsoft.Resources/deploymentStacksWhatIfResults
Lien vers la pile Sans objet properties.deploymentStackResourceId fait référence à la pile
Persévérance Non stocké Stocké pour l’intervalle de rétention que vous avez défini

Un résultat possède un identifiant de ressource sous cette forme :

/subscriptions/{subscription-id}/resourceGroups/{resource-group-name}/providers/Microsoft.Resources/deploymentStacksWhatIfResults/{what-if-result-name}

Le stack que vous avez évalué n’a pas encore besoin d’exister. Si ce n’est pas le cas, what-if rapporte la pile elle-même comme une nouvelle ressource, ce qui vous permet de prévisualiser la première exécution d’une pile avant de la créer.

Limitations

La fonctionnalité What-If pour les piles de déploiement présente les mêmes limitations de What-If sous-jacentes que les déploiements de modèles Azure Resource Manager, notamment en ce qui concerne la précision des résultats pour certains types de ressources et certaines propriétés. Examinez toujours attentivement les modifications prévues avant d’appliquer une pile, en particulier lorsque actionOnUnmanage est défini sur une option de suppression.

  • La réduction du bruit ne supprime pas toutes les différences. Le « et si » filtre de nombreuses différences courantes qui ne sont pas de réels changements, mais il ne les filtre pas toutes. Pour plus d’informations, voir Réduction du bruit.
  • Les résultats stockés persistent jusqu’à la fin de leur intervalle de rétention. Chaque résultat hypothétique est une ressource dans le champ d’application où vous le créez, et il compte dans les limites de ressources de ce périmètre. Un résultat qui utilise un intervalle de rétention plus long que PT3H celui n’est pas supprimé automatiquement, donc supprime les résultats dont vous n’avez plus besoin. Pour plus d’informations, voir Récupérer et supprimer les résultats stockés.

Comment fonctionne What-If avec les piles de déploiement

Lorsque vous exécutez un « et si » contre une pile de déploiement, l’opération évalue le modèle par rapport à l’état actuel des ressources gérées par la pile et rapporte chaque ressource comme l’un des types de changement suivants :

Type de modification Description
Créer La ressource n’existe pas et est créée.
Modifier La ressource existe et certaines propriétés changent.
Aucun changement La ressource existe et n’est pas modifiée.
Supprimer S’applique lorsque actionOnUnmanage est défini sur Supprimer. La ressource est retirée de la pile et supprimée.
Détacher S’applique lorsque actionOnUnmanage est défini sur détaché. La ressource est retirée de la gestion de la pile, mais n’est pas supprimée d’Azure.
Unsupported La ressource n’est pas prise en charge pour l’évaluation What-If.

Note

Lorsque le fournisseur de ressources ignore une propriété en lecture seule (par exemple, sku.tier définie pour correspondre sku.name à certains types de ressources), le « et si » rapporte cette propriété comme NoEffect. Certains clients affichent NoEffect comme NoChange. Cette différence n’affecte que l’affichage, sans affecter les modifications qu’applique la stack.

Le « et si » fait également apparaître des ressources détachées de la pile (qui ne sont plus gérées) en fonction du actionOnUnmanage comportement, afin de confirmer qu’aucune ressource gérée n’est supprimée involontairement.

Réduction du bruit

What-if compare votre modèle à l’état actuel des ressources gérées par la pile. Toutes les différences qu’il constate ne sont pas un changement que vous avez fait. Les fournisseurs de ressources ajoutent et normalisent des valeurs après le déploiement d’une ressource, donc une propriété peut différer de votre modèle même si rien de significatif n’a changé. Ces différences sont du bruit, et elles rendent un résultat plus difficile à lire.

Les piles de déploiement filtrent ce bruit pour vous. Lorsque vous déployez ou mettez à jour une pile, Azure évalue le « et si » pour la pile à ce moment-là et garde le résultat comme référence. Lorsque vous exécutez ultérieurement l’opération what-if sur la pile, toute propriété qui est inchangée entre cette base de référence et l’évaluation actuelle est supprimée du résultat, car considérée comme du bruit. Ce qui reste est plus proche de l’ensemble des changements que votre modèle introduit réellement.

Étant donné que la référence est enregistrée lors du déploiement de la pile, la réduction du bruit s’applique aux piles qui ont été créées ou mises à jour après la mise à disposition de la fonctionnalité. Si une pile n’a pas été déployée ou mise à jour depuis, ses résultats What-If contiennent toujours du bruit. Déployez ou mettez à jour la pile une fois pour établir la base de référence.

Note

La réduction du bruit supprime de nombreuses différences courantes, mais elle ne les supprime pas toutes. Examinez les changements rapportés plutôt que de supposer que chaque différence est un vrai changement.

Effectuez une simulation avant de créer ou de mettre à jour une stack

Lance la commande « et si » pour prévisualiser les changements sans les appliquer. Vous identifiez la pile cible par son identifiant de ressource : utilisez --stack-id dans Azure CLI ou -StackResourceId dans Azure PowerShell. La --name valeur (Azure CLI) ou -Name (Azure PowerShell) nomme le résultat « et si » stocké, et l’opération conserve ce résultat pour l’intervalle de rétention que vous avez défini afin que vous puissiez le récupérer plus tard.

L’intervalle de conservation utilise le format ISO 8601 de durée, par exemple PT3H pendant trois heures ou P7D sept jours.

Conseil / Astuce

Réglez l’intervalle de rétention à PT3H ou moins. Les résultats qui nécessitent un intervalle de rétention plus long ne sont pas supprimés automatiquement, donc vous devez les supprimer vous-même lorsque vous n’en avez plus besoin.

Pour afficher un aperçu des modifications d’une pile de groupe de ressources, utilisez la commande suivante :

az stack-whatif group create \
  --name "<what-if-result-name>" \
  --resource-group "<resource-group-name>" \
  --stack-id "<deployment-stack-resource-id>" \
  --template-file "<bicep-file-name>" \
  --action-on-unmanage "detachAll" \
  --deny-settings-mode "none" \
  --retention-interval "PT3H"

Pour prévisualiser les modifications d’une pile d’abonnement, utilisez la commande suivante :

az stack-whatif sub create \
  --name "<what-if-result-name>" \
  --location "<location>" \
  --stack-id "<deployment-stack-resource-id>" \
  --template-file "<bicep-file-name>" \
  --action-on-unmanage "detachAll" \
  --deny-settings-mode "none" \
  --retention-interval "PT3H"

Pour prévisualiser les modifications apportées à une pile de groupe d’administration, utilisez la commande suivante :

az stack-whatif mg create \
  --name "<what-if-result-name>" \
  --management-group-id "<management-group-id>" \
  --location "<location>" \
  --stack-id "<deployment-stack-resource-id>" \
  --template-file "<bicep-file-name>" \
  --action-on-unmanage "detachAll" \
  --deny-settings-mode "none" \
  --retention-interval "PT3H"

Pour prévisualiser l’effet d’une mise à jour sur une pile existante, exécutez la même commande « et si » et passez l’identifiant de ressource de cette pile. Dans Azure PowerShell, vous pouvez aussi utiliser les cmdlets correspondantsSet-Az*DeploymentStackWhatIfResult.

Récupérer et supprimer les résultats stockés

Étant donné que chaque résultat What-If constitue une ressource distincte, vous pouvez répertorier, récupérer et supprimer les résultats à n’importe quelle étendue. Supprimez les résultats dont vous n’avez plus besoin, surtout lorsque vous fixez un intervalle de rétention plus long que PT3H.

# List the what-if results in a resource group
az stack-whatif group list --resource-group "<resource-group-name>"

# Get a single result
az stack-whatif group show --name "<what-if-result-name>" --resource-group "<resource-group-name>"

# Get a single result by resource ID
az stack-whatif group show --id "<what-if-result-resource-id>"

# Delete a result
az stack-whatif group delete --name "<what-if-result-name>" --resource-group "<resource-group-name>" --yes

Utilisation az stack-whatif sub et az stack-whatif mg pour les catégories d’abonnement et de gestion des groupes.

Obtenir des changements au niveau des ressources ou des propriétés

Un résultat hypothétique contient des changements à deux niveaux de détail : quelles ressources changent, et quelles propriétés individuelles changent sur ces ressources.

Lorsque vous créez un résultat What-If, la sortie inclut les changements au niveau de la propriété. Lorsque vous récupérez un résultat stocké, la sortie inclut uniquement les modifications au niveau de la ressource. Pour inclure les changements au niveau de la propriété lors de la récupération d’un résultat, utilisez --with-property-changes Azure CLI ou -WithPropertyChanges Azure PowerShell.

az stack-whatif group show \
  --name "<what-if-result-name>" \
  --resource-group "<resource-group-name>" \
  --with-property-changes true

Récupérer un résultat sans l’option indique que la ressource change, mais pas ce qui change dessus :

Azure
  ~ /subscriptions/<subscription-id>/resourceGroups/demo-rg/providers/Microsoft.Storage/storageAccounts/examplestorage
    ~ Management Status: "notManaged" => "managed"
    = Deny Status: "none"

L’obtention du même résultat grâce à cette option permet d’ajouter les modifications individuelles des propriétés :

Azure
  ~ /subscriptions/<subscription-id>/resourceGroups/demo-rg/providers/Microsoft.Storage/storageAccounts/examplestorage [2023-01-01]
    ~ Management Status: "notManaged" => "managed"
    = Deny Status: "none"
    ~ sku.name: "Standard_LRS" => "Standard_GRS"
    - tags.myTag: "myValue"
    + tags.env: "demo"

L’option s’applique lorsque vous récupérez un seul résultat. La liste des résultats ne renvoie pas les modifications de propriétés.

Confirmez avant de postuler

Utilisez le « et si » comme étape de confirmation lors des sessions interactives et dans les pipelines :

  • De façon interactive, exécutez la commande « et si », examinez les changements prédits, puis exécutez la commande stack create pour les appliquer.
  • En automatisation, capturez le résultat hypothétique et bloquez l’étape de candidature lors de la révision ou de l’approbation. Cette étape est précieuse pour les stacks car une mise à jour peut détacher ou supprimer des ressources selon le actionOnUnmanage réglage.
  • Last updated on