Problèmes connus liés aux piles de déploiement

Cet article répertorie les limitations connues et les problèmes connus pour les piles de déploiement Azure, ainsi que les solutions de contournement recommandées lorsqu’elles sont disponibles.

Limitations connues

  • Vous pouvez créer jusqu’à 800 piles de ressources déployées dans une même portée.
  • Vous pouvez avoir jusqu’à 2 000 attributions de refus pour une étendue donnée.
  • La pile de déploiement ne gère pas les ressources créées implicitement. Par conséquent, vous ne pouvez pas utiliser deny-assignments ni l’opération de nettoyage pour ces ressources.
  • Les affectations de refus ne prennent pas en charge les balises.
  • Les affectations de refus ne sont pas prises en charge au niveau de l’étendue du groupe d’administration. Toutefois, ils sont pris en charge dans une pile de groupes d’administration lorsque le déploiement est pointé vers l’étendue de l’abonnement.
  • Les piles de déploiement ne peuvent pas supprimer les secrets Key Vault. Si vous supprimez les secrets Key Vault d’un modèle, exécutez également la commande de mise à jour ou de suppression de la pile de déploiement avec le mode detach. Les dernières versions de Azure PowerShell et de Azure CLI incluent une option permettant de détacher des ressources non déletables, ce qui empêche les défaillances accidentelles.

Problèmes connus

  • La suppression d’un groupe de ressources contourne les attributions de refus. Les piles de déploiement créées dans l'étendue du groupe de ressources ne gèrent pas le groupe de ressources parent, car le groupe de ressources n'est pas défini dans le fichier Bicep. Par conséquent, même si la pile de déploiement crée des affectations de refus, vous pouvez toujours supprimer le groupe de ressources. La suppression du groupe de ressources supprime la pile de déploiement et ses ressources managées. Il est recommandé de déployer au niveau de l’abonnement et d’inclure le groupe de ressources dans le fichier Bicep. Sinon, si un verrou est actif sur une ressource du groupe, l’opération de suppression échoue.
  • Le déplacement d’une ressource gérée supprime sa protection de la stack. Les affectations de refus sont évaluées au niveau du groupe de ressources pour les opérations de déplacement, et non au niveau de la ressource individuelle. Par conséquent, une ressource peut être déplacée hors de son groupe de ressources même lorsqu’une attribution de refus protège cette ressource en particulier, et les protections d’une pile de déploiement ne sont pas transférées avec elle une fois la ressource déplacée. La ressource déplacée n’est plus protégée par la pile et peut être gérée en dehors de sa limite d’origine. En guise d’atténuation intermédiaire, appliquez un verrou en lecture seule sur le groupe de ressources pour bloquer les opérations de déplacement. Les opérations sur les piles de déploiement continuent de fonctionner malgré la présence du verrou en lecture seule. Par exemple, la lecture de la pile et sa protection contre la suppression continuent de fonctionner. Pour mettre à jour la pile, supprimez temporairement le verrou pendant la durée de la modification et réappliquez-le par la suite.
  • Une pile attribuée à un groupe d’administration ne peut pas être déployée sur un autre groupe d’administration. Elle peut uniquement être déployée dans le groupe d’administration de la pile elle-même, ou dans un abonnement enfant.
  • DeleteResourcesAndResourceGroups la valeur est supprimée. L’aide de la commande Azure PowerShell répertorie une valeur DeleteResourcesAndResourceGroups pour le commutateur ActionOnUnmanage. Lorsque vous utilisez cette valeur, la commande détache les ressources managées et les groupes de ressources. Cette valeur est supprimée dans une prochaine mise à jour. N’utilisez pas cette valeur.
  • Erreur de validation de modèle générique. Dans certains cas, les applets de commande Azure PowerShell New-* et Set-* peuvent renvoyer une erreur générique de validation de modèle qui n’indique pas clairement la marche à suivre. Si l’erreur n’est pas claire, réexécutez l’applet de commande en mode débogage pour afficher une erreur plus détaillée dans la réponse brute.
  • Le fournisseur Microsoft Graph n'est pas pris en charge. Le fournisseur Microsoft Graph ne prend pas en charge les piles de déploiement.
  • What-if n’est pas encore disponible. L’opération de simulation n’est pas encore prise en charge pour les piles de déploiement.

Gérer l’erreur de désynchronisation de pile

Lors de la mise à jour ou de la suppression d’une pile de déploiement, vous pouvez rencontrer une erreur indiquant que la pile n’est pas synchronisée, signalant que la liste des ressources de la pile n’est pas correctement synchronisée :

The deployment stack '{0}' might not have an accurate list of managed resources. To prevent resources from being accidentally deleted, check that the managed resource list doesn't have any additional values. If there is any uncertainty, it's recommended to redeploy the stack with the same template and parameters as the current iteration. To bypass this warning, specify the 'BypassStackOutOfSyncError' flag.

Passez en revue la liste des ressources managées à partir du portail Azure ou redéployez le fichier Bicep actuellement déployé avec les mêmes paramètres pour obtenir la liste des ressources managées. Après avoir vérifié la liste, réexécutez la commande avec le BypassStackOutOfSyncError commutateur dans Azure PowerShell (ou --bypass-stack-out-of-sync-error dans Azure CLI). Utilisez ce commutateur uniquement après avoir examiné minutieusement la liste des ressources. Ne l’utilisez pas par défaut.

Étapes suivantes

  • Last updated on