Partager via

Comprendre la structure et la syntaxe des modèles ARM

  • Article

Cet article décrit la structure d’un modèle ARM (Azure Resource Manager). Il présente les différentes sections d''un modèle et les propriétés disponibles dans ces sections.

Cet article est destiné aux utilisateurs qui possèdent des connaissances sur les modèles ARM. Il fournit des informations détaillées sur la structure du modèle. Pour obtenir un didacticiel pas à pas vous guidant tout au long du processus de création d’un modèle, consultez :Totoriel : Créer et déployer votre premier modèle ARM. Pour découvrir les modèles ARM via un ensemble guidé de modules Learn, consultez Déployer et gérer des ressources dans Azure à l’aide de modèles ARM.

Conseil

Bicep est un nouveau langage qui offre les mêmes fonctionnalités que les modèles ARM, mais avec une syntaxe plus facile à utiliser. Si vous considérez des options d’infrastructure en tant que code, nous vous recommandons de vous pencher sur Bicep.

Pour plus d’informations sur les différents éléments d’un fichier Bicep, consultez Présentation de la structure et de la syntaxe des fichiers Bicep.

Format de modèle

Dans sa structure la plus simple, un modèle a les éléments suivants :

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "languageVersion": "",
  "contentVersion": "",
  "apiProfile": "",
  "definitions": { },
  "parameters": { },
  "variables": { },
  "functions": [ ],
  "resources": [ ], /* or "resources": { } with languageVersion 2.0 */
  "outputs": { }
}
Nom de l'élément Obligatoire Description
$schema Oui Emplacement du fichier de schéma JavaScript Object Notation (JSON) qui décrit la version du langage du modèle. Le numéro de version que vous utilisez dépend de l’étendue du déploiement et de votre éditeur JSON.

Si vous utilisez Visual Studio Code avec l’extension des outils Azure Resource Manager, utilisez la version la plus récente pour les déploiements de groupes de ressources :
https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#

Il se peut que d’autres éditeurs (dont Visual Studio) ne puissent pas traiter ce schéma. Pour ces éditeurs, utilisez :
https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#

Pour les déploiements d’abonnements, utilisez :
https://schema.management.azure.com/schemas/2018-05-01/subscriptionDeploymentTemplate.json#

Pour les déploiements de groupes d’administration, utilisez :
https://schema.management.azure.com/schemas/2019-08-01/managementGroupDeploymentTemplate.json#

Pour les déploiements de locataires, utilisez :
https://schema.management.azure.com/schemas/2019-08-01/tenantDeploymentTemplate.json#
languageVersion Non Version linguistique du modèle. Pour afficher les améliorations apportées à languageVersion 2.0, consultez languageVersion 2.0.
contentVersion Oui Version du modèle (par exemple, 1.0.0.0). Vous pouvez fournir n’importe quelle valeur pour cet élément. Utilisez cette valeur pour documenter les modifications importantes dans votre modèle. Quand vous déployez des ressources à l'aide du modèle, cette valeur permet de vous assurer que le bon modèle est utilisé.
apiProfile Non Une version d’API qui sert de collection de versions d’API pour les types de ressources. Utilisez cette valeur pour éviter d’avoir à spécifier les versions d’API pour chaque ressource dans le modèle. Lorsque vous spécifiez une version de profil d’API et que vous ne spécifiez pas une version d’API pour le type de ressource, Resource Manager utilise la version d’API pour ce type de ressource qui est définie dans le profil.

La propriété de profil d’API est particulièrement utile lorsque vous déployez un modèle dans différents environnements, comme Azure Stack et Azure global. Utilisez la version de profil d’API pour vous assurer que votre modèle utilise automatiquement des versions prises en charge dans les deux environnements. Pour une liste des versions de profil d’API actuelles et les versions d’API définies dans le profil de ressources, consultez Profil d’API.

Pour plus d’informations, consultez Suivre les versions à l’aide de profils d’API.
définitions Non Schémas utilisés pour valider des valeurs de tableau et d’objet. Les définitions sont uniquement prises en charge dans languageVersion 2.0.
parameters Non Valeurs fournies lors de l'exécution du déploiement pour personnaliser le déploiement des ressources.
variables Non Valeurs utilisées en tant que fragments JSON dans le modèle pour simplifier les expressions du langage du modèle.
functions Non Fonctions définies par l’utilisateur et disponibles dans le modèle.
resources Oui Types de ressource déployés ou mis à jour dans un groupe de ressources ou un abonnement.
outputs Non Valeurs retournées après le déploiement.

Chaque élément a des propriétés que vous pouvez définir. Cet article décrit les sections du modèle de manière plus approfondie.

Définitions

Dans la section definitions du modèle, spécifiez les schémas utilisés pour valider les valeurs de tableau et d’objet. Definitions ne peut être utilisé qu’avec languageVersion 2.0.

"definitions": {
  "<definition-name": {
    "type": "<data-type-of-definition>",
    "allowedValues": [ "<array-of-allowed-values>" ],
    "minValue": <minimum-value-for-int>,
    "maxValue": <maximum-value-for-int>,
    "minLength": <minimum-length-for-string-or-array>,
    "maxLength": <maximum-length-for-string-or-array>,
    "prefixItems": <schema-for-validating-array>,
    "items": <schema-for-validating-array-or-boolean>,
    "properties": <schema-for-validating-object>,
    "additionalProperties": <schema-for-validating-object-or-boolean>,
    "discriminator": <schema-to-apply>,
    "nullable": <boolean>,
    "metadata": {
      "description": "<description-of-the-type-definition>"
    }
  }
}
Nom de l'élément Obligatoire Description
definition-name Oui Nom de la définition de type. Doit être un identificateur JavaScript valide.
type Oui Type de la définition de type. Les types et valeurs autorisés sont : string, secureString, int, bool, object, secureObject et array. Consultez Types de données dans les modèles ARM.
allowedValues Non Tableau des valeurs autorisées dans la définition de type pour vous assurer que la bonne valeur a bien été fournie.
minValue Non Valeur minimale des définitions de type int, cette valeur est inclusive.
maxValue Non Valeur maximale des définitions de type int, cette valeur est inclusive.
minLength Non Longueur minimale des définitions de type chaîne, chaîne sécurisée et tableau. Cette valeur est inclusive.
maxLength Non Longueur maximale des définitions de type chaîne, chaîne sécurisée et tableau. Cette valeur est inclusive.
prefixItems Non Schéma de validation de l’élément d’un tableau au même index.
items Non Schéma appliqué à tous les éléments du tableau dont l’index est supérieur à l’index le plus grand de la contrainte prefixItems, ou booléen de contrôle des éléments du tableau dont l’index est supérieur à l’index le plus grand de la contrainte prefixItems.
properties Non Schéma de validation de l’objet.
additionalProperties Non Schéma appliqué à toutes les propriétés non mentionnées dans la contrainte properties, ou booléen d’acceptation de toute propriété non définie dans la contrainte properties.
discriminator Non Schéma à appliquer en fonction d’une propriété de discriminateur.
nullable Non Booléen indiquant que la valeur peut être nulle ou omise.
description Non Description de la définition de type qui apparaît aux utilisateurs dans le portail. Pour plus d’informations, consultez Commentaires dans les modèles.

Pour obtenir des exemples d’utilisation des définitions de type, consultez Définitions de type dans les modèles ARM.

Dans Bicep, consultez Types de données définis par l’utilisateur.

Paramètres

Dans la section parameters du modèle, vous spécifiez les valeurs que vous pouvez saisir lors du déploiement des ressources. Vous êtes limité à 256 paramètres dans un modèle. Vous pouvez réduire le nombre de paramètres en utilisant des objets contenant plusieurs propriétés.

Les propriétés disponibles pour un paramètre sont :

"parameters": {
  "<parameter-name>" : {
    "type" : "<type-of-parameter-value>",
    "defaultValue": "<default-value-of-parameter>",
    "allowedValues": [ "<array-of-allowed-values>" ],
    "minValue": <minimum-value-for-int>,
    "maxValue": <maximum-value-for-int>,
    "minLength": <minimum-length-for-string-or-array>,
    "maxLength": <maximum-length-for-string-or-array>,
    "prefixItems": <schema-for-validating-array>,
    "items": <schema-for-validating-array-or-boolean>,
    "properties": <schema-for-validating-object>,
    "additionalProperties": <schema-for-validating-object-or-boolean>,
    "discriminator": <schema-to-apply>,
    "nullable": <boolean>,
    "metadata": {
      "description": "<description-of-the parameter>"
    }
  }
}
Nom de l'élément Obligatoire Description
parameter-name Oui Nom du paramètre. Doit être un identificateur JavaScript valide.
type Oui Type de la valeur du paramètre. Les types et valeurs autorisés sont : string, secureString, int, bool, object, secureObject et array. Consultez Types de données dans les modèles ARM.
defaultValue Non Valeur par défaut du paramètre, si aucune valeur n'est fournie pour le paramètre.
allowedValues Non Tableau des valeurs autorisées pour le paramètre afin de vous assurer que la bonne valeur a bien été fournie.
minValue Non Valeur minimale pour les paramètres de type int, cette valeur est inclusive.
maxValue Non Valeur maximale pour les paramètres de type int. Cette valeur est inclusive.
minLength Non Valeur minimale pour les paramètres de type string, secure string et array. Cette valeur est inclusive.
maxLength Non Valeur maximale pour les paramètres de type string, secure string et array. Cette valeur est inclusive.
prefixItems Non Type de définition de validation de l’élément d’un tableau au même index. prefixItems est uniquement pris en charge dans languageVersion 2.0.
items Non Schéma appliqué à tous les éléments du tableau dont l’index est supérieur à l’index le plus grand de la contrainte prefixItems, ou booléen de contrôle des éléments du tableau dont l’index est supérieur à l’index le plus grand de la contrainte prefixItems. items est uniquement pris en charge dans languageVersion 2.0.
properties Non Schéma de validation de l’objet. properties est uniquement pris en charge dans languageVersion 2.0.
additionalProperties Non Schéma appliqué à toutes les propriétés non mentionnées dans la contrainte properties, ou booléen d’acceptation de toute propriété non définie dans la contrainte properties. additionalProperties est uniquement pris en charge dans languageVersion 2.0.
discriminator Non Schéma à appliquer en fonction d’une propriété de discriminateur. discriminator est uniquement pris en charge dans languageVersion 2.0.
nullable Non Booléen indiquant que la valeur peut être nulle ou omise. nullable est uniquement pris en charge dans languageVersion 2.0.
description Non Description du paramètre qui apparaît aux utilisateurs dans le portail. Pour plus d’informations, consultez Commentaires dans les modèles.

Pour obtenir des exemples d’utilisation des paramètres, consultez Paramètres dans les modèles ARM.

Dans Bicep, consultez paramètres.

Variables

Dans la section variables, vous définissez les valeurs qui peuvent être utilisées dans votre modèle. Vous n’êtes pas obligé de définir des variables, mais elles simplifient souvent votre modèle en réduisant les expressions complexes. Le format de chaque variable correspond à l’un des types de données. Vous êtes limité à 256 variables dans un modèle.

L’exemple suivant montre les options disponibles pour la définition d’une variable :

"variables": {
  "<variable-name>": "<variable-value>",
  "<variable-name>": {
    <variable-complex-type-value>
  },
  "<variable-object-name>": {
    "copy": [
      {
        "name": "<name-of-array-property>",
        "count": <number-of-iterations>,
        "input": <object-or-value-to-repeat>
      }
    ]
  },
  "copy": [
    {
      "name": "<variable-array-name>",
      "count": <number-of-iterations>,
      "input": <object-or-value-to-repeat>
    }
  ]
}

Pour plus d’informations sur l’utilisation de copy pour créer plusieurs valeurs pour une variable, consultez copy.

Pour obtenir des exemples d’utilisation des variables, consultez Variables dans un modèle ARM.

Dans Bicep, consultez variables.

Fonctions

Dans votre modèle, vous pouvez créer vos propres fonctions. Ces fonctions peuvent être utilisées dans votre modèle. En règle générale, vous définissez des expressions complexes que vous ne voulez pas répéter tout au long de votre modèle. Vous créez les fonctions définies par l’utilisateur à partir d’expressions et de fonctions prises en charge dans les modèles.

La définition d’une fonction utilisateur est soumise à certaines restrictions :

  • La fonction ne peut pas accéder aux variables.
  • La fonction ne peut utiliser que des paramètres définis dans l’autre fonction. Quand vous utilisez la fonction parameters dans une fonction définie par l’utilisateur, vous êtes limité aux paramètres de cette fonction.
  • La fonction ne peut pas appeler d’autres fonctions définies par l’utilisateur.
  • La fonction ne peut pas utiliser la fonction de référence.
  • Les paramètres de la fonction ne peuvent pas avoir de valeur par défaut.
"functions": [
  {
    "namespace": "<namespace-for-functions>",
    "members": {
      "<function-name>": {
        "parameters": [
          {
            "name": "<parameter-name>",
            "type": "<type-of-parameter-value>"
          }
        ],
        "output": {
          "type": "<type-of-output-value>",
          "value": "<function-return-value>"
        }
      }
    }
  }
],
Nom de l'élément Obligatoire Description
espace de noms Oui Espace de noms pour les fonctions personnalisées. Utilisez pour éviter les conflits de noms avec les fonctions de modèle.
function-name Oui Nom de la fonction personnalisée. Lors de l’appel de la fonction, associez le nom de la fonction à l’espace de noms. Par exemple, pour appeler une fonction nommée uniqueName dans l’espace de noms contoso, utilisez "[contoso.uniqueName()]".
parameter-name Non Nom du paramètre à utiliser dans la fonction personnalisée.
parameter-value Non Type de la valeur du paramètre. Les types et valeurs autorisés sont : string, secureString, int, bool, object, secureObject et array.
output-type Oui Type de la valeur de sortie. Les valeurs de sortie prennent en charge les mêmes types que les paramètres d'entrée de la fonction.
output-value Oui Expression du langage du modèle évaluée et retournée à partir de la fonction.

Pour obtenir des exemples d’utilisation des fonctions personnalisées, consultez Fonctions définies par l’utilisateur dans un modèle ARM.

Dans Bicep, les fonctions définies par l’utilisateur ne sont pas prises en charge. Bicep prend en charge différentes fonctions et différents opérateurs.

Ressources

Dans la section resources, vous définissez les ressources déployées ou mises à jour. Vous êtes limité à 800 ressources dans un modèle.

Vous définissez des ressources avec la structure suivante :

"resources": [
  {
    "condition": "<true-to-deploy-this-resource>",
    "type": "<resource-provider-namespace/resource-type-name>",
    "apiVersion": "<api-version-of-resource>",
    "name": "<name-of-the-resource>",
    "comments": "<your-reference-notes>",
    "location": "<location-of-resource>",
    "dependsOn": [
        "<array-of-related-resource-names>"
    ],
    "tags": {
        "<tag-name1>": "<tag-value1>",
        "<tag-name2>": "<tag-value2>"
    },
    "identity": {
      "type": "<system-assigned-or-user-assigned-identity>",
      "userAssignedIdentities": {
        "<resource-id-of-identity>": {}
      }
    },
    "sku": {
        "name": "<sku-name>",
        "tier": "<sku-tier>",
        "size": "<sku-size>",
        "family": "<sku-family>",
        "capacity": <sku-capacity>
    },
    "kind": "<type-of-resource>",
    "scope": "<target-scope-for-extension-resources>",
    "copy": {
        "name": "<name-of-copy-loop>",
        "count": <number-of-iterations>,
        "mode": "<serial-or-parallel>",
        "batchSize": <number-to-deploy-serially>
    },
    "plan": {
        "name": "<plan-name>",
        "promotionCode": "<plan-promotion-code>",
        "publisher": "<plan-publisher>",
        "product": "<plan-product>",
        "version": "<plan-version>"
    },
    "properties": {
        "<settings-for-the-resource>",
        "copy": [
            {
                "name": ,
                "count": ,
                "input": {}
            }
        ]
    },
    "resources": [
        "<array-of-child-resources>"
    ]
  }
]
Nom de l'élément Obligatoire Description
condition Non Valeur booléenne qui indique si la ressource est approvisionnée pendant ce déploiement. Quand la valeur est true, la ressource est créée pendant le déploiement. Quand la valeur est false, la ressource est ignorée pour ce déploiement. Voir condition.
type Oui Type de la ressource. Cette valeur est une combinaison de l’espace de noms du fournisseur de ressources et du type de ressource (comme Microsoft.Storage/storageAccounts). Pour déterminer les valeurs disponibles, consultez référence de modèle. Pour une ressource enfant, le format du type dépend de si elle est imbriquée dans la ressource parente ou définie en dehors de la ressource parente. Consultez Définition du nom et du type des ressources enfants.
apiVersion Oui La version de l'API REST à utiliser pour la création de la ressource. Lorsque vous créez un nouveau modèle, définissez cette valeur sur la dernière version de la ressource que vous déployez. Tant que le modèle fonctionne en fonction des besoins, continuez à utiliser la même version d’API. En continuant à utiliser la même version d’API, vous réduisez le risque qu’une nouvelle version d’API modifie le fonctionnement de votre modèle. Envisagez de mettre à jour la version de l’API uniquement lorsque vous souhaitez utiliser une nouvelle fonctionnalité introduite dans une version ultérieure. Pour déterminer les valeurs disponibles, consultez référence de modèle.
name Oui Nom de la ressource. Le nom doit respecter les restrictions de composant d'URI définies dans le document RFC3986. Les services Azure qui exposent le nom de la ressource à des parties externes valident le nom pour vérifier qu’il ne s’agit pas d’une tentative d’usurpation d’identité. Pour une ressource enfant, le format du nom dépend de si elle est imbriquée dans la ressource parente ou définie en dehors de la ressource parente. Consultez Définition du nom et du type des ressources enfants.
comments Non Vos commentaires pour documenter les ressources dans votre modèle. Pour plus d’informations, consultez Commentaires dans les modèles.
location Variable Emplacements géographiques de la ressource fournie pris en charge. Vous pouvez sélectionner l’un des emplacements disponibles, mais en général, il est judicieux de choisir celui qui est proche de vos utilisateurs. En règle générale, il est également judicieux de placer dans la même région les ressources qui interagissent entre elles. La plupart des types de ressources nécessitent un emplacement, mais certains types (comme une attribution de rôle) n’ont pas besoin d’emplacement. Voir Définir l’emplacement des ressources.
dependsOn Non Les ressources qui doivent être déployées avant le déploiement de cette ressource. Resource Manager évalue les dépendances entre les ressources et les déploie dans le bon ordre. Quand les ressources ne dépendent pas les unes des autres, elles sont déployées en parallèle. La valeur peut être une liste séparée par des virgules de noms de ressource ou d’identificateurs de ressource uniques. Répertoriez uniquement les ressources qui sont déployées dans ce modèle. Les ressources qui ne sont pas définies dans ce modèle doivent déjà exister. Évitez d’ajouter des dépendances inutiles, car cela risque de ralentir votre déploiement et de créer des dépendances circulaires. Pour obtenir des conseils sur la définition des dépendances, consultez Définir l’ordre de déploiement des ressources dans les modèles ARM.
tags Non Balises associées à la ressource. Appliquer des balises pour organiser logiquement des ressources dans votre abonnement.
identité No Certaines ressources prennent en charge des identités managées pour les ressources Azure. Ces ressources ont un objet Identité au niveau racine de la déclaration de ressource. Vous pouvez définir si l’identité est affectée par l’utilisateur ou affectée par le système. Pour les identités affectées par l’utilisateur, fournissez une liste d’ID de ressource pour les identités. Définissez la clé sur l’ID de ressource et la valeur sur un objet vide. Pour plus d’informations, consultez Configurer des identités managées pour les ressources Azure sur une machine virtuelle Azure en utilisant des modèles.
sku Non Certaines ressources autorisent les valeurs qui définissent la référence SKU à déployer. Par exemple, vous pouvez spécifier le type de redondance pour un compte de stockage.
kind Non Certaines ressources autorisent une valeur qui définit le type de ressource que vous déployez. Par exemple, vous pouvez spécifier le type d’instance Azure Cosmos DB à créer.
scope Non La propriété scope est uniquement disponible pour les types de ressources d’extension. Utilisez-la lorsque vous spécifiez une étendue différente de celle du déploiement. Voir Définition de l’étendue pour les ressources d’extension dans les modèles Resource Manager.
copy Non Si plusieurs instances sont nécessaires, le nombre de ressources à créer. Le mode par défaut est parallèle. Spécifiez le mode série si vous ne voulez pas que toutes les ressources soient déployées en même temps. Pour plus d’informations, consultez Créer plusieurs instances de ressources dans Azure Resource Manager.
Plan Non Certaines ressources autorisent les valeurs qui définissent le plan à déployer. Par exemple, vous pouvez spécifier l’image de marketplace pour une machine virtuelle.
properties Non Paramètres de configuration spécifiques aux ressources. Les valeurs de propriétés sont identiques à celles que vous fournissez dans le corps de la requête pour l’opération d’API REST (méthode PUT) pour créer la ressource. Vous pouvez aussi spécifier une copie en groupe pour créer plusieurs instances d’une propriété. Pour déterminer les valeurs disponibles, consultez référence de modèle.
les ressources Non Ressources enfants qui dépendent de la ressource qui est définie. Fournissez uniquement des types de ressources qui sont autorisés par le schéma de la ressource parente. La dépendance sur la ressource parente n’est pas induite. Vous devez la définir explicitement. Consultez Définition du nom et du type des ressources enfants.

Pour prendre en charge le nom symbolique Bicep dans les modèles JSON ARM, ajoutez languageVersion avec la version 2.0 ou une version plus récente, et modifiez la définition de ressource d’un tableau à un objet.

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "languageVersion": "2.0",
  "contentVersion": "1.0.0.0",
  "resources": {
    "<name-of-the-resource>": {
      ...
    }
  }
}

Pour plus d’informations, consultez Ressources.

Dans Bicep, consultez ressources.

Sorties

Dans la section outputs, vous spécifiez les valeurs qui sont retournées par le déploiement. En règle générale, vous retournez des valeurs de ressources qui ont été déployées. Vous êtes limité à 64 sorties dans un modèle.

L'exemple suivant illustre la structure de la définition d'une sortie :

"outputs": {
  "<output-name>": {
    "condition": "<boolean-value-whether-to-output-value>",
    "type": "<type-of-output-value>",
    "value": "<output-value-expression>",
    "copy": {
      "count": <number-of-iterations>,
      "input": <values-for-the-variable>
    }
  }
}
Nom de l'élément Obligatoire Description
output-name Oui Nom de la valeur de sortie. Doit être un identificateur JavaScript valide.
condition Non Valeur booléenne qui indique si cette valeur de sortie est retournée. Si elle est égale à true, cela signifie que la valeur est incluse dans la sortie pour le déploiement. Si elle est égale à false, la valeur de sortie est ignorée pour ce déploiement. Lorsqu’elle n’est pas spécifiée, la valeur par défaut est true.
type Oui Type de la valeur de sortie. Les valeurs de sortie prennent en charge les mêmes types que les paramètres d'entrée du modèle. Si vous spécifiez securestring pour le type de sortie, la valeur n’est pas affichée dans l’historique de déploiement et ne peut pas être récupérée à partir d’un autre modèle. Pour utiliser une valeur secrète dans plusieurs modèles, stockez la clé secrète dans un coffre de clés et référencez la clé secrète dans le fichier de paramètres. Pour plus d’informations, consultez l’article Utiliser Azure Key Vault pour transmettre une valeur de paramètre sécurisée pendant le déploiement.
value Non Expression du langage du modèle évaluée et retournée sous forme de valeur de sortie. Spécifiez valueou copy.
copy Non Utilisé pour retourner plusieurs valeurs pour une sortie. Spécifiez valueou copy. Pour plus d’informations, voir Itération de sorties dans des modèles ARM.

Pour obtenir des exemples d’utilisation des sorties, consultez Sorties dans un modèle ARM.

Dans Bicep, consultez sorties.

Commentaires et métadonnées

Vous avez quelques options permettant d’ajouter des commentaires et des métadonnées à votre modèle.

Commentaires

Pour les commentaires inclus, vous pouvez utiliser // ou /* ... */. Dans Visual Studio Code, enregistrez les fichiers de paramètres avec des commentaires en tant que type de fichier JSONC (JSON avec commentaires), sinon vous recevez un message d’erreur indiquant « Commentaires non autorisés dans JSON ».

Remarque

Lorsque vous utilisez Azure CLI pour déployer des modèles avec des commentaires, utilisez la version 2.3.0 ou ultérieure et spécifiez le commutateur --handle-extended-json-format.

{
  "type": "Microsoft.Compute/virtualMachines",
  "apiVersion": "2023-03-01",
  "name": "[variables('vmName')]", // to customize name, change it in variables
  "location": "[parameters('location')]", //defaults to resource group location
  "dependsOn": [ /* storage account and network interface must be deployed first */
    "[resourceId('Microsoft.Storage/storageAccounts/', variables('storageAccountName'))]",
    "[resourceId('Microsoft.Network/networkInterfaces/', variables('nicName'))]"
  ],

Dans Visual Studio Code, l’extension Azure Resource Manager Tools peut détecter automatiquement un modèle ARM et modifier le mode de langage. Si Modèle Azure Resource Manager s’affiche dans l’angle inférieur droit de Visual Studio Code, vous pouvez utiliser les commentaires inclus. Les commentaires inclus ne sont plus signalés comme étant non valides.

Capture d’écran du mode de modèle Visual Studio Code dans Azure Resource Manager.

Dans Bicep, consultez commentaires.

Métadonnées

Vous pouvez ajouter un objet metadata presque n’importe où dans votre modèle. Resource Manager ignore l’objet, mais votre éditeur JSON peut vous avertir que la propriété n’est pas valide. Dans l’objet, définissez les propriétés dont vous avez besoin.

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "metadata": {
    "comments": "This template was developed for demonstration purposes.",
    "author": "Example Name"
  },

Pour parameters, ajoutez un objet metadata avec une propriété description.

"parameters": {
  "adminUsername": {
    "type": "string",
    "metadata": {
      "description": "User name for the Virtual Machine."
    }
  },

Lorsque vous déployez le modèle par le biais du portail, le texte que vous fournissez dans la description est automatiquement utilisé comme une info-bulle pour ce paramètre.

Capture d’écran montrant des conseils de paramètre dans le portail Azure.

Pour resources, ajoutez un élément comments ou un objet metadata. L’exemple suivant montre à la fois un élément comments et un objet metadata.

"resources": [
  {
    "type": "Microsoft.Storage/storageAccounts",
    "apiVersion": "2022-09-01",
    "name": "[format('{0}{1}', 'storage', uniqueString(resourceGroup().id))]",
    "comments": "Storage account used to store VM disks",
    "location": "[parameters('location')]",
    "metadata": {
      "comments": "These tags are needed for policy compliance."
    },
    "tags": {
      "Dept": "[parameters('deptName')]",
      "Environment": "[parameters('environment')]"
    },
    "sku": {
      "name": "Standard_LRS"
    },
    "kind": "Storage",
    "properties": {}
  }
]

Pour outputs, ajoutez un objet metadata à la valeur de sortie.

"outputs": {
  "hostname": {
    "type": "string",
    "value": "[reference(variables('publicIPAddressName')).dnsSettings.fqdn]",
    "metadata": {
      "comments": "Return the fully qualified domain name"
    }
  },

Vous ne pouvez pas ajouter d’objet metadata aux fonctions définies par l’utilisateur.

Chaînes à lignes multiples

Vous pouvez scinder une chaîne en plusieurs lignes. Par exemple, voir la propriété location et l’un des commentaires dans l’exemple JSON suivant.

Notes

Pour déployer des modèles avec des chaînes multilignes, utilisez Azure PowerShell ou Azure CLI. Pour l’interface CLI, utilisez la version 2.3.0 ou ultérieure et spécifiez le commutateur --handle-extended-json-format.

Les chaînes multilignes ne sont pas prises en charge lorsque vous déployez le modèle via le portail Azure, d’un pipeline de DevOps ou l’API REST.

{
  "type": "Microsoft.Compute/virtualMachines",
  "apiVersion": "2023-03-01",
  "name": "[variables('vmName')]", // to customize name, change it in variables
  "location": "[
    parameters('location')
    ]", //defaults to resource group location
  /*
    storage account and network interface
    must be deployed first
  */
  "dependsOn": [
    "[resourceId('Microsoft.Storage/storageAccounts/', variables('storageAccountName'))]",
    "[resourceId('Microsoft.Network/networkInterfaces/', variables('nicName'))]"
  ],

Dans Bicep, consultez chaînes multilignes.

languageVersion 2.0

Remarque

L’utilisation d’un languageVersion qui se termine en -experimental n’est pas recommandée dans les environnements de production, car les fonctionnalités expérimentales peuvent être modifiées à tout moment.

Remarque

La version actuelle de l’extension Azure Resource Manager Tools pour Visual Studio Code ne reconnaît pas les améliorations apportées à languageVersion 2.0.

Pour utiliser languageVersion 2.0, ajoutez "languageVersion": "2.0" à votre modèle :

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "languageVersion": "2.0",
  "contentVersion": "1.0.0.0",
  "resources": {
    "<name-of-the-resource>": {
      ...
    }
  }
}

Améliorations et modifications apportées à languageVersion 2.0 :

  • Utiliser un nom symbolique dans un modèle ARM JSON. Pour plus d’informations, consultez Utiliser un nom symbolique.
  • Utiliser un nom symbolique dans des boucles de copie de ressources. Consultez Utiliser un nom symbolique.
  • Utiliser un nom symbolique dans les tableaux dependsOn. Consultez Depend de et Dépend des ressources dans une boucle.
  • Utiliser un nom symbolique au lieu d’un nom de ressource dans la fonction reference. Consultez la référence.
  • Une fonction de référence qui retourne un tableau d’objets représentant les états d’exécution d’une collection de ressources. Consultez Références.
  • Utiliser la propriété de ressource « existant » pour signaler des ressources existantes afin qu’ARM lise une ressource au lieu de la déployer. Consultez Signaler des ressources existantes.
  • Créer des types définis par l’utilisateur. Consultez Définition de type.
  • Contraintes de validation de type d’agrégat supplémentaires à utiliser dans les paramètres et les sorties.
  • La valeur par défaut de la propriété expressionEvaluationOptions est inner. La valeur outer est bloquée. Consultez Étendue de l’évaluation d’expressions dans les modèles imbriqués.
  • La fonction deployment retourne un sous-ensemble limité de propriétés. Consultez Déploiement.
  • Si la ressource Déploiements est utilisée dans le déploiement d’un nom symbolique, utilisez apiVersion 2020-09-01 ou une version plus récente.
  • Dans la définition de ressource, il n’est plus nécessaire de prévoir un double échappement pour les valeurs au sein d’une expression. Consultez Caractères d’échappement.

L’utilisation de l’une des fonctionnalités Bicep suivantes active automatiquement la génération de code version 2.0 du langage :

Étapes suivantes