Mettre à jour une ressource dans un modèle Azure Resource Manager
Il peut arriver que vous deviez mettre à jour une ressource pendant un déploiement, par exemple lorsque vous ne pouvez pas spécifier toutes les propriétés d’une ressource tant que d’autres ressources dépendantes n’ont pas été créées. Par exemple, si vous créez un pool principal pour un équilibrage de charge, vous pouvez mettre à jour les interfaces réseau (NIC) sur vos machines virtuelles pour les inclure dans le pool principal. Resource Manager prend en charge la mise à jour des ressources lors du déploiement, mais vous devez concevoir votre modèle correctement pour éviter les erreurs et garantir que le déploiement est traité comme une mise à jour.
Lorsque vous créez une ressource et la mettez à jour ultérieurement, vous la référencez deux fois. Vous la référencez d’abord dans le modèle qui la crée. Plus tard, lorsque vous mettez à jour la ressource, vous la référencez par le même nom. Toutefois, si deux ressources ont le même nom dans un modèle, Resource Manager lève une exception. Pour éviter cette erreur, spécifiez la ressource mise à jour dans un second modèle qui est lié ou inclus en tant que sous-modèle à l’aide du type de ressource Microsoft.Resources/deployments.
Dans le deuxième modèle, vous devez spécifier le nom de la propriété à modifier ou un nouveau nom de propriété à ajouter. Vous devez également spécifier les noms et les valeurs d’origine des propriétés qui ne changent pas. Si vous ne spécifiez pas une ou plus de propriétés d’origine, Resource Manager part du principe que vous souhaitez créer une nouvelle ressource et supprime la ressource initiale.
Exemple de modèle
Examinons un exemple de modèle illustrant cette technique. Le modèle déploie un réseau virtuel nommé firstVNet et qui comporte un sous-réseau appelé firstSubnet. Il déploie ensuite une interface réseau virtuelle (NIC) nommée nic1 et associe le NIC au sous-réseau. Une ressource de déploiement nommée updateVNet inclut un modèle imbriqué qui met à jour firstVNet en ajoutant un second sous-réseau appelé secondSubnet.
{
"$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {},
"resources": [
{
"apiVersion": "2020-05-01",
"name": "firstVNet",
"location": "[resourceGroup().location]",
"type": "Microsoft.Network/virtualNetworks",
"properties": {
"addressSpace": {
"addressPrefixes": [
"10.0.0.0/22"
]
},
"subnets": [
{
"name": "firstSubnet",
"properties": {
"addressPrefix": "10.0.0.0/24"
}
}
]
}
},
{
"apiVersion": "2020-05-01",
"type": "Microsoft.Network/networkInterfaces",
"name": "nic1",
"location": "[resourceGroup().location]",
"dependsOn": [
"firstVNet"
],
"properties": {
"ipConfigurations": [
{
"name": "ipconfig1",
"properties": {
"privateIPAllocationMethod": "Dynamic",
"subnet": {
"id": "[resourceId('Microsoft.Network/virtualNetworks/subnets', 'firstVNet', 'firstSubnet')]"
}
}
}
]
}
},
{
"apiVersion": "2020-06-01",
"type": "Microsoft.Resources/deployments",
"name": "updateVNet",
"dependsOn": [
"nic1"
],
"properties": {
"mode": "Incremental",
"parameters": {},
"template": {
"$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.1",
"parameters": {},
"variables": {},
"resources": [
{
"apiVersion": "2020-05-01",
"name": "firstVNet",
"location": "[resourceGroup().location]",
"type": "Microsoft.Network/virtualNetworks",
"properties": {
"addressSpace": "[reference('firstVNet').addressSpace]",
"subnets": [
{
"name": "[reference('firstVNet').subnets[0].name]",
"properties": {
"addressPrefix": "[reference('firstVNet').subnets[0].properties.addressPrefix]"
}
},
{
"name": "secondSubnet",
"properties": {
"addressPrefix": "10.0.1.0/24"
}
}
]
}
}
],
"outputs": {}
}
}
}
],
"outputs": {}
}
Considérez l’objet de ressource pour notre ressourcefirstVNet. Notez que nous spécifions de nouveau les paramètres de notre ressource firstVNet dans un modèle imbriqué, parce que Resource Manager n’autorise pas l’utilisation du même nom de déploiement dans le même modèle, et que les modèles imbriqués sont considérés comme des modèles distincts. En spécifiant une nouvelle fois nos valeurs pour notre ressource firstSubnet, nous indiquons à Resource Manager de mettre à jour la ressource existante au lieu de la supprimer et de la redéployer. Pour finir, nos nouveaux paramètres pour secondSubnet sont sélectionnés dans le cadre de cette mise à jour.
Essayer le modèle
Un exemple de modèle est disponible sur GitHub. Pour déployer le modèle, exécutez les commandes Azure CLI suivantes :
az group create --location <location> --name <resource-group-name>
az deployment group create -g <resource-group-name> \
--template-uri https://raw.githubusercontent.com/mspnp/template-examples/master/example1-update/deploy.json
Une fois le déploiement terminé, ouvrez le groupe de ressources que vous avez spécifié dans le portail. Vous voyez un réseau virtuel nommé firstVNet et une interface de réseau virtuel appelée nic1. Cliquez sur firstVNet, puis sur subnets. Vous voyez firstSubnet qui a été créé à l’origine et vous voyez secondSubnet qui a été ajouté dans la ressource updateVNet.
Ensuite, revenez au groupe de ressources, cliquez sur nic1, puis cliquez sur IP configurations. Dans la section IP configurations, subnet est défini sur firstSubnet (10.0.0.0/24).
Le firstVNet d’origine a été mis à jour au lieu d’être recréé. Si firstVNet avait été recréé, nic1 ne serait pas être associé à firstVNet.
Étapes suivantes
- Azure Resource Manager
- Que sont les modèles ARM ?
- Tutoriel : Créer et déployer votre premier modèle Resource Manager
- Tutoriel : Ajouter une ressource à votre modèle ARM
- Bonnes pratiques de modèle ARM
- Documentation Azure Resource Manager
- Documentation sur les modèles ARM