Partage via

Utilisation des modèles de déploiement Azure Resource Manager (ARM) avec Azure CLI

  • Article

Cet article explique comment utiliser Azure CLI avec des modèles Resource Manager pour déployer vos ressources dans Azure. Si vous n’avez pas une bonne connaissance des concepts de déploiement et de gestion des solutions Azure, consultez Vue d’ensemble du déploiement de modèles.

Les commandes de déploiement ont changé dans la version 2.2.0 d’Azure CLI. Les exemples de cet article nécessitent la Azure CLI version 2.20.0 ou une version ultérieure.

Pour exécuter cet exemple, installez la dernière version d’Azure CLI. Pour démarrer, exécutez az login pour créer une connexion avec Azure.

Des exemples pour l’interface CLI sont écrits pour l’interpréteur de commandes bash. Pour exécuter cet exemple dans Windows PowerShell ou à une invite de commandes, vous devrez peut-être modifier certains éléments du script.

Si Azure CLI n’est pas installé, vous pouvez utiliser Azure Cloud Shell. Pour plus d’informations, consultez Déployer des modèles Azure Resource Manager à partir d’Azure Cloud Shell.

Conseil

Nous recommandons Bicep, parce qu’il offre les mêmes fonctionnalités que les modèles ARM et que la syntaxe est plus facile d’utilisation. Pour en savoir plus, consultez Comment déployer des ressources à l'aide de Bicep et d'Azure CLI.

Autorisations requises

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.

Étendue du déploiement

Vous pouvez cibler votre modèle de déploiement Azure au niveau d’un groupe de ressources, d’un abonnement, d’un groupe d’administration ou d’un locataire. Les commandes à utiliser diffèrent en fonction de l’étendue du déploiement.

Pour chaque étendue, l’utilisateur qui déploie le modèle doit disposer des autorisations nécessaires pour créer des ressources.

Déployer un modèle local

Vous pouvez déployer un modèle ARM à partir de votre ordinateur local ou d’un modèle stocké en externe. Cette section décrit le déploiement d’un modèle local.

Si vous effectuez un déploiement vers un groupe de ressources qui n’existe pas, vous devez commencer par créer ce dernier. Le nom du groupe de ressources ne peut contenir que des caractères alphanumériques, des points, des traits de soulignement, des traits d'union et des parenthèses. Il peut comprendre jusqu’à 90 caractères. Le nom ne peut pas se terminer par un point.

az group create --name ExampleGroup --location "Central US"

Pour déployer un modèle local, utilisez le paramètre --template-file dans la commande de déploiement. L’exemple suivant montre également comment définir une valeur de paramètre.

az deployment group create \
  --name ExampleDeployment \
  --resource-group ExampleGroup \
  --template-file <path-to-template> \
  --parameters storageAccountType=Standard_GRS

La valeur du paramètre --template-file doit être un fichier Bicep ou un fichier .json ou .jsonc. L’extension de fichier .jsonc indique que le fichier peut contenir des commentaires de style //. Le système ARM accepte les commentaires // dans les fichiers .json. Il ne s’intéresse pas à l’extension de fichier. Pour plus d’informations sur les commentaires et les métadonnées, consultez Comprendre la structure et la syntaxe des modèles ARM.

Le déploiement d’un modèle Azure peut prendre plusieurs minutes. Au terme, vous voyez un message qui inclut le résultat :

"provisioningState": "Succeeded",

Déployer un modèle distant

Au lieu de stocker des modèles ARM sur votre machine locale, vous pouvez les stocker dans un emplacement externe. Vous pouvez stocker des modèles dans un dépôt de contrôle de code source (par exemple, GitHub). Vous pouvez aussi les stocker dans un compte de stockage Azure pour mettre en place un accès partagé dans votre organisation.

Notes

Pour déployer un modèle ou référencer un modèle lié qui est stocké dans un référentiel GitHub privé, consultez une solution personnalisée documentée dans Création d’une offre personnalisée et sécurisée de portail Azure. Il est possible de créer une fonction Azure qui extrait le jeton GitHub d’Azure Key Vault.

Si vous effectuez un déploiement vers un groupe de ressources qui n’existe pas, vous devez commencer par créer ce dernier. Le nom du groupe de ressources ne peut contenir que des caractères alphanumériques, des points, des traits de soulignement, des traits d'union et des parenthèses. Il peut comprendre jusqu’à 90 caractères. Le nom ne peut pas se terminer par un point.

az group create --name ExampleGroup --location "Central US"

Pour déployer un modèle externe, utilisez le paramètre template-uri.

az deployment group create \
  --name ExampleDeployment \
  --resource-group ExampleGroup \
  --template-uri "https://raw.githubusercontent.com/Azure/azure-quickstart-templates/master/quickstarts/microsoft.storage/storage-account-create/azuredeploy.json" \
  --parameters storageAccountType=Standard_GRS

L’exemple précédent nécessite un URI accessible publiquement pour le modèle, ce qui convient pour la plupart des scénarios, sachant que votre modèle ne doit pas inclure de données sensibles. Si vous avez besoin de spécifier des données sensibles (par exemple, un mot de passe d’administrateur), passez cette valeur en tant que paramètre sécurisé. Toutefois, si vous souhaitez gérer l’accès au modèle, envisagez d’utiliser des spécifications de modèle.

Pour déployer des modèles liés à distance avec un chemin d’accès relatif et qui sont stockés dans un compte de stockage, utilisez query-string pour spécifier le jeton SAP :

az deployment group create \
  --name linkedTemplateWithRelativePath \
  --resource-group myResourceGroup \
  --template-uri "https://stage20210126.blob.core.windows.net/template-staging/mainTemplate.json" \
  --query-string $sasToken

Pour plus d’informations, consultez Utiliser le chemin d’accès relatif pour les modèles liés.

Nom du modèle de déploiement Azure

Lors du déploiement d’un modèle ARM, vous pouvez attribuer un nom au modèle de déploiement Azure. Ce nom peut vous aider à récupérer le déploiement à partir de l’historique de déploiement. Si vous n’attribuez pas de nom au déploiement, le nom du fichier de modèle est utilisé. Par exemple, si vous déployez un modèle nommé azuredeploy.json et que vous ne spécifiez pas de nom de déploiement, le déploiement est nommé azuredeploy.

Chaque fois que vous exécutez un déploiement, une entrée est ajoutée à l’historique de déploiement du groupe de ressources avec le nom du déploiement. Si vous exécutez un autre déploiement et que vous lui attribuez le même nom, l’entrée précédente est remplacée par le déploiement actuel. Si vous souhaitez conserver des entrées uniques dans l’historique de déploiement, attribuez un nom unique à chaque déploiement.

Pour créer un nom unique, vous pouvez assigner un numéro aléatoire.

deploymentName='ExampleDeployment'$RANDOM

Vous pouvez aussi ajouter une valeur de date.

deploymentName='ExampleDeployment'$(date +"%d-%b-%Y")

Si vous exécutez des déploiements simultanés dans le même groupe de ressources avec le même nom de déploiement, seul le dernier déploiement aboutit. Les déploiements de même nom qui n’arrivent pas à terme sont remplacés par le dernier déploiement. Par exemple, si vous exécutez un déploiement nommé newStorage qui déploie un compte de stockage nommé storage1 et que, dans le même temps, vous exécutez un autre déploiement nommé newStorage qui déploie un compte de stockage nommé storage2, vous ne déployez qu’un seul compte de stockage. Le compte de stockage qui en résulte est nommé storage2.

En revanche, si vous exécutez un déploiement nommé newStorage qui déploie un compte de stockage nommé storage1 et que, aussitôt terminé, vous exécutez un autre déploiement nommé newStorage qui déploie un compte de stockage nommé storage2, vous disposez de deux comptes de stockage : un nommé storage1 et l’autre nommé storage2. Cependant, l’historique de déploiement ne présente qu’une seule entrée.

Quand vous spécifiez un nom unique pour chaque déploiement, vous pouvez les exécuter simultanément sans conflit. Si vous exécutez un déploiement nommé newStorage1 qui déploie un compte de stockage nommé storage1 et que, dans le même temps, vous exécutez un autre déploiement nommé newStorage2 qui déploie un compte de stockage nommé storage2, vous disposez de deux comptes de stockage et l’historique de déploiement présente deux entrées.

Pour éviter les conflits lors de déploiements simultanés et faire en sorte que l’historique de déploiement présente des entrées uniques, attribuez un nom unique à chaque déploiement.

Déployer une spec de modèle

Au lieu de déployer un modèle local ou distant, vous pouvez créer une spécification de modèle. La spécification de modèle est une ressource de votre abonnement Azure qui contient un modèle ARM. Elle facilite le partage sécurisé du modèle avec les utilisateurs de votre organisation. Vous utilisez le contrôle d’accès Azure en fonction du rôle (Azure RBAC) pour accorder l’accès à la spécification de modèle. Actuellement, cette fonctionnalité est uniquement disponible en tant que version préliminaire.

Les exemples suivants montrent comment créer et déployer une spécification de modèle.

Tout d’abord, créez la spécification de modèle en fournissant le modèle ARM.

az ts create \
  --name storageSpec \
  --version "1.0" \
  --resource-group templateSpecRG \
  --location "westus2" \
  --template-file "./mainTemplate.json"

Ensuite, recevez l’ID de la spécification de modèle et déployez-le.

id = $(az ts show --name storageSpec --resource-group templateSpecRG --version "1.0" --query "id")

az deployment group create \
  --resource-group demoRG \
  --template-spec $id

Pour plus d’informations, consultez Specs de modèle Azure Resource Manager.

Prévisualiser les modifications

Avant de déployer votre modèle ARM, vous pouvez prévisualiser les modifications que le modèle apporte à votre environnement. Utilisez l’opération de simulation pour vérifier que le modèle apporte les changements prévus. Cette opération vérifie aussi que le modèle est exempt d’erreurs.

Paramètres

Pour passer des valeurs de paramètre, vous pouvez utiliser des paramètres inline ou un fichier de paramètres. Le fichier de paramètres peut être un fichier de paramètres Bicep ou un fichier de paramètres JSON.

Paramètres inline

Pour passer des paramètres inline, indiquez les valeurs dans parameters. Par exemple, pour transmettre une chaîne et un tableau à un modèle dans un interpréteur de commandes Bash, utilisez :

az deployment group create \
  --resource-group testgroup \
  --template-file <path-to-template> \
  --parameters exampleString='inline string' exampleArray='("value1", "value2")'

Si vous utilisez l’interface de ligne de commande Azure avec l’invite de commandes Windows (CMD) ou PowerShell, transmettez le tableau au format : exampleArray="['value1','value2']".

Vous pouvez également récupérer le contenu d’un fichier et fournir ce contenu en tant que paramètre inline.

az deployment group create \
  --resource-group testgroup \
  --template-file <path-to-template> \
  --parameters exampleString=@stringContent.txt exampleArray=@arrayContent.json

Obtenir une valeur de paramètre à partir d’un fichier est utile lorsque vous devez fournir des valeurs de configuration. Par exemple, vous pouvez fournir des valeurs cloud-init pour une machine virtuelle Linux.

Le format arrayContent.json est :

[
  "value1",
  "value2"
]

Pour passer un objet en entrée, par exemple pour définir des balises, utilisez JSON. Par exemple, votre modèle peut inclure un paramètre comme celui-ci :

"resourceTags": {
  "type": "object",
  "defaultValue": {
    "Cost Center": "IT Department"
  }
}

Dans ce cas, vous pouvez passer une chaîne JSON pour définir le paramètre comme indiqué dans le script bash suivant :

tags='{"Owner":"Contoso","Cost Center":"2345-324"}'
az deployment group create --name addstorage  --resource-group myResourceGroup \
--template-file $templateFile \
--parameters resourceName=abcdef4556 resourceTags="$tags"

Utilisez des guillemets doubles autour du JSON que vous voulez passer à l’objet.

Vous pouvez utiliser une variable pour contenir les valeurs de paramètre. Dans Bash, définissez la variable sur toutes les valeurs de paramètre et ajoutez-la à la commande de déploiement.

params="prefix=start suffix=end"

az deployment group create \
  --resource-group testgroup \
  --template-file <path-to-template> \
  --parameters $params

Toutefois, si vous utilisez Azure CLI avec l’invite de commandes (CMD) Windows ou PowerShell, définissez la variable sur une chaîne JSON. Échappez les guillemets : $params = '{ \"prefix\": {\"value\":\"start\"}, \"suffix\": {\"value\":\"end\"} }'.

Fichiers de paramètres JSON

Plutôt que de passer des paramètres comme des valeurs inline dans votre script, vous pouvez utiliser un fichier de paramètres, un fichier .bicepparam ou un fichier de paramètres JSON, qui contient les valeurs de paramètre. Le fichier de paramètres doit être un fichier local. Les fichiers de paramètres externes ne sont pas pris en charge avec Azure CLI.

az deployment group create \
  --name ExampleDeployment \
  --resource-group ExampleGroup \
  --template-file storage.json \
  --parameters 'storage.parameters.json'

Pour plus d’informations sur le fichier de paramètres, consultez Créer un fichier de paramètres Resource Manager.

Fichiers de paramètres Bicep

Avec Azure CLI version 2.53.0 ou ultérieure, et l’interface CLI Bicep version 0.22.6 ou ultérieure, vous pouvez déployer un fichier Bicep en utilisant un fichier de paramètres Bicep. Avec l’instruction using dans le fichier de paramètres Bicep, vous n’avez pas besoin de fournir le commutateur --template-file quand vous spécifiez un fichier de paramètres Bicep pour le commutateur --parameters. L’inclusion du commutateur --template-file entraîne l’erreur « Seul un modèle .bicep est autorisé avec un fichier .bicepparam ».

az deployment group create \
  --name ExampleDeployment \
  --resource-group ExampleGroup \
  --parameters storage.bicepparam

Le fichier de paramètres doit être un fichier local. Les fichiers de paramètres externes ne sont pas pris en charge avec Azure CLI. Pour plus d’informations sur le fichier de paramètres, consultez Créer un fichier de paramètres Resource Manager.

Commentaires et format JSON étendu

Vous pouvez inclure des commentaires de style // dans votre fichier de paramètres, mais vous devez nommer le fichier avec une extension .jsonc.

az deployment group create \
  --name ExampleDeployment \
  --resource-group ExampleGroup \
  --template-file storage.json \
  --parameters '@storage.parameters.jsonc'

Pour plus d’informations sur les commentaires et les métadonnées, consultez Comprendre la structure et la syntaxe des modèles ARM.

Si vous utilisez Azure CLI avec la version 2.3.0 ou antérieure, vous pouvez déployer un modèle avec des chaînes ou des commentaires multilignes à l’aide du commutateur --handle-extended-json-format. Par exemple :

{
  "type": "Microsoft.Compute/virtualMachines",
  "apiVersion": "2018-10-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'))]"
  ],

Étapes suivantes