Contrôle préliminaire : validation du serveur avant le déploiement

Dans Azure Resource Manager (ARM), la validation côté serveur se compose de deux parties distinctes :

• Validation statique, avec laquelle les développeurs d’opérations interagissent.
• Validation préliminaire du fournisseur de ressources, qui est la phase de validation interne du fournisseur de ressources.

La validation statique vérifie les aspects du modèle que ARM peut évaluer sans appeler des fournisseurs de ressources, tels que :

• Structure du modèle et exactitude du schéma
• Définitions de paramètres et contraintes de valeur de base
• Évaluation des expressions et cohérence des modèles

Ces vérifications garantissent que le modèle est syntactiquement et structurellement valide avant la validation plus approfondie.

La validation préliminaire est un processus interne Azure Resource Manager (ARM) exécuté pendant la phase de validation. Son objectif est d’accélérer la détection des erreurs en empêchant les déploiements connus d’échouer. Au cours de cette étape, ARM appelle les fournisseurs de ressources appropriés pour vérifier que le déploiement est réalisable, sans créer ou modifier de ressources. Cette partie valide :

• Conflits de nommage des ressources : pendant la prévérification, ARM évalue les noms de ressources finaux, résolus et vérifie s'ils violent l'exigence d'unicité ou les règles de nommage appliquées par le fournisseur. Cette vérification se produit après que des expressions comme concat() ou uniqueString() sont résolues. La validation préliminaire échoue généralement quand :

  • Un nom global unique (par exemple, un nom de compte de stockage) est déjà pris
  • Un nom de ressource enfreint les contraintes d’affectation de noms propres au fournisseur

• Correction de l’étendue : la validation préliminaire garantit que les ressources sont déployées dans une étendue valide et que la commande de déploiement correspond aux types de ressources déclarés dans le modèle. Cette validation inclut les éléments suivants :

  • Indique si l’étendue de déploiement (groupe de ressources, abonnement, groupe d’administration, locataire) est compatible avec les types de ressources
  • Indique si les étendues parentes requises existent. Par exemple, le déploiement d’une ressource ayant une portée limitée à un groupe de ressources au niveau de l’abonnement, sans utiliser de groupe de ressources.

• Autorisations RBAC (concernant la capacité à déployer ces types de ressources) : pendant la vérification préalable, ARM vérifie que l’appelant dispose d’autorisations suffisantes au niveau de l’étendue de déploiement pour créer ou modifier les ressources demandées. Si l’identité ne dispose pas d’autorisations, le déploiement est rejeté avant l’exécution. Les échecs d’autorisation préliminaires classiques sont les suivants :

  • Autorisations d’écriture manquantes pour un type de ressource
  • Autorisations insuffisantes au niveau de l’étendue cible
  • Fournisseurs de ressources requis non inscrits

• Compatibilité du fournisseur de base et de l’API : la validation préliminaire confirme que :

  • Les fournisseurs de ressources référencés sont inscrits
  • Les versions d’API spécifiées sont valides et prises en charge
  • Le type de ressource est reconnu par Azure Resource Manager

  Si un fournisseur n’est pas inscrit ou si la version de l’API n’est pas valide, ARM échoue le déploiement à la vérification préalable.

Si l’une de ces vérifications échoue, le déploiement ne démarre jamais.

Limites

La validation préliminaire est un processus d'effort maximal et n'intercepte pas toutes les erreurs survenant lors du déploiement. Il ne peut pas détecter les échecs d’exécution (par exemple, les erreurs au sein d’une extension de script personnalisé pendant l’exécution) et sa validation peut être incomplète lorsque les ressources dépendent de valeurs qui ne sont pas encore disponibles, telles que les propriétés générées dynamiquement à partir d’autres ressources.

Autorisations RBAC héritées par le biais de groupes d’administration

Lorsque la validation préalable est effectuée pour des ressources à l’échelle du locataire ou du groupe d’administration, Azure Resource Manager évalue les autorisations à l’étendue de la demande de validation. Dans certains cas, ARM ne résout pas la chaîne ancêtre du groupe d’administration complet pendant cette évaluation. Par conséquent, les attributions de rôles RBAC héritées via la hiérarchie des groupes d’administration risquent de ne pas être reconnues lors de la validation préalable, même si ces mêmes autorisations sont bien prises en compte lors du déploiement réel.

Ce comportement peut entraîner l’échec de la vérification préalable avec une erreur d’autorisation (HTTP 401 ou 403) pour les identités disposant d’autorisations suffisantes via l’héritage du groupe de gestion. Le déploiement réel du même modèle réussit, car le pipeline de création de ressources standard évalue entièrement les autorisations héritées.

Solution de contournement : attribuez le rôle requis (par exemple, Contributeur ou Propriétaire) directement à l’étendue de l’abonnement ou du groupe de ressources plutôt que de vous appuyer uniquement sur les autorisations héritées du groupe d’administration. Vous pouvez également utiliser le commutateur --validation-level Template (Azure CLI 2.76.0+) ou -ValidationLevel Template (Azure PowerShell 13.4.0+) avec les commandes what-if et validate pour ignorer les vérifications préalables des autorisations.

Exécuter le pré-vol

La validation préliminaire s’exécute automatiquement lorsque vous utilisez des commandes de validation de déploiement ou de type 'what-if'. Par exemple, ces opérations exécutent la validation préliminaire :

• Validation de JSON ARM ou de Bicep via Azure CLI ou PowerShell

  • Azure CLI
  • PowerShell

  az deployment group validate \
    --resource-group myResourceGroup \
    --template-file main.bicep
  

• Azure portail Review + create étape

  Actuellement, le portail Azure prend uniquement en charge le déploiement de modèles JSON ARM. Pour plus d’informations, consultez Déployer des modèles ARM avec le portail Azure.

• Et si

  « What-if comprend des vérifications préliminaires avant de calculer les changements, sauf si vous le configurez pour ignorer ces vérifications préliminaires. » Pour plus d’informations, consultez Exécution de l’opération de simulation.

Les erreurs de préversion apparaissent dans le journal d’activité, mais pas dans l’historique des déploiements, car le déploiement n’a jamais commencé.

Étapes suivantes

• Pour utiliser l’opération de simulation, consultez Bicep What-If : Aperçu des modifications avant le déploiement.