Partager via


Déployer des ressources à l’aide de modèles Resource Manager et d’Azure PowerShell

Cet article explique comment utiliser Azure PowerShell avec les modèles Azure Resource Manager (ARM) 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.

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 Déployer des ressources à l'aide de Bicep et d'Azure PowerShell.

Prérequis

Il vous faut un modèle à déployer. Si vous n’en avez pas déjà un, téléchargez et enregistrez un exemple de modèle à partir du référentiel de modèles de démarrage rapide Azure. Le nom de fichier local utilisé dans cet article est C:\MyTemplates\azuredeploy.json.

Vous devez installer Azure PowerShell et vous connecter à Azure :

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

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 déploiement 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.

Nom du déploiement

Lors du déploiement d’un modèle ARM, vous pouvez attribuer un nom au déploiement. 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.

$suffix = Get-Random -Maximum 1000
$deploymentName = "ExampleDeployment" + $suffix

Vous pouvez aussi ajouter une valeur de date.

$today=Get-Date -Format "MM-dd-yyyy"
$deploymentName="ExampleDeployment"+"$today"

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 un modèle local

Vous pouvez déployer un modèle à 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.

New-AzResourceGroup -Name ExampleGroup -Location "Central US"

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

New-AzResourceGroupDeployment `
  -Name ExampleDeployment `
  -ResourceGroupName ExampleGroup `
  -TemplateFile <path-to-template>

Le déploiement peut prendre plusieurs minutes.

Déployer un modèle distant

Au lieu de stocker les modèles Resource Manager sur votre ordinateur local, 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.

New-AzResourceGroup -Name ExampleGroup -Location "Central US"

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

New-AzResourceGroupDeployment `
  -Name remoteTemplateDeployment `
  -ResourceGroupName ExampleGroup `
  -TemplateUri https://raw.githubusercontent.com/Azure/azure-quickstart-templates/master/quickstarts/microsoft.storage/storage-account-create/azuredeploy.json

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 QueryString pour spécifier le jeton SAP :

New-AzResourceGroupDeployment `
  -Name linkedTemplateWithRelativePath `
  -ResourceGroupName "myResourceGroup" `
  -TemplateUri "https://stage20210126.blob.core.windows.net/template-staging/mainTemplate.json" `
  -QueryString "$sasToken"

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

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.

New-AzTemplateSpec `
  -Name storageSpec `
  -Version 1.0 `
  -ResourceGroupName templateSpecsRg `
  -Location westus2 `
  -TemplateJsonFile ./mainTemplate.json

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

$id = (Get-AzTemplateSpec -Name storageSpec -ResourceGroupName templateSpecsRg -Version 1.0).Versions.Id

New-AzResourceGroupDeployment `
  -ResourceGroupName demoRG `
  -TemplateSpecId $id

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

Prévisualiser les modifications

Avant de déployer votre modèle, vous pouvez afficher un aperçu des modifications que le modèle apportera à 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.

Passer les valeurs de paramètre

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 les paramètres inline, indiquez les noms des paramètres au moyen de la commande New-AzResourceGroupDeployment. Par exemple, pour passer une chaîne et un tableau à un modèle, utilisez :

$arrayParam = "value1", "value2"
New-AzResourceGroupDeployment -ResourceGroupName testgroup `
  -TemplateFile <path-to-template> `
  -exampleString "inline string" `
  -exampleArray $arrayParam

Vous pouvez utiliser le paramètre TemplateParameterObject pour passer une table de hachage qui contient les paramètres du modèle.

$params = @{
  exampleString = "inline string"
  exampleArray = "value1", "value2"
}

New-AzResourceGroupDeployment -ResourceGroupName testgroup `
  -TemplateFile <path-to-bicep> `
  -TemplateParameterObject $params

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

$arrayParam = "value1", "value2"
New-AzResourceGroupDeployment -ResourceGroupName testgroup `
  -TemplateFile <path-to-template> `
  -exampleString $(Get-Content -Path c:\MyTemplates\stringcontent.txt -Raw) `
  -exampleArray $arrayParam

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.

Si vous avez besoin de transmettre un tableau d’objets, créez des tables de hachage dans PowerShell et ajoutez-les à un tableau. Transmettez ce tableau en tant que paramètre lors du déploiement.

$hash1 = @{ Name = "firstSubnet"; AddressPrefix = "10.0.0.0/24"}
$hash2 = @{ Name = "secondSubnet"; AddressPrefix = "10.0.1.0/24"}
$subnetArray = $hash1, $hash2
New-AzResourceGroupDeployment -ResourceGroupName testgroup `
  -TemplateFile <path-to-template> `
  -exampleArray $subnetArray

Fichiers de paramètres JSON

Au lieu de passer des paramètres en tant que valeurs inline dans votre script, il peut s’avérer plus facile d’utiliser un fichier JSON qui contient les valeurs des paramètres. Le fichier de paramètres peut être un fichier local ou un fichier externe avec un URI accessible.

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

Pour transmettre un fichier de paramètres local, utilisez le paramètre TemplateParameterFile :

New-AzResourceGroupDeployment `
  -Name ExampleDeployment `
  -ResourceGroupName ExampleResourceGroup `
  -TemplateFile <path-to-template> `
  -TemplateParameterFile c:\MyTemplates\storage.parameters.json

Pour transmettre un fichier de paramètres externe, utilisez le paramètre TemplateParameterUri :

New-AzResourceGroupDeployment `
  -Name ExampleDeployment `
  -ResourceGroupName ExampleResourceGroup `
  -TemplateUri https://raw.githubusercontent.com/Azure/azure-quickstart-templates/master/quickstarts/microsoft.storage/storage-account-create/azuredeploy.json `
  -TemplateParameterUri https://raw.githubusercontent.com/Azure/azure-quickstart-templates/master/quickstarts/microsoft.storage/storage-account-create/azuredeploy.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 PowerShell version 10.4.0 ou ultérieure et l’interface CLI Bicep version 0.22.6 ou ultérieure, vous pouvez déployer un fichier de modèle ARM 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 -TemplateFile quand vous spécifiez un fichier de paramètres Bicep pour le commutateur -TemplateParameterFile.

L’exemple suivant montre un fichier de paramètres nommé storage.bicepparam. Le fichier se trouve dans le même répertoire que celui dans lequel la commande est exécutée.

New-AzResourceGroupDeployment `
  -Name ExampleDeployment `
  -ResourceGroupName ExampleResourceGroup `
  -TemplateParameterFile storage.bicepparam

Pour obtenir plus d’informations sur le fichier de paramètres Bicep, consultez Fichier de paramètres Bicep.

Étapes suivantes