Actualización de un recurso en una plantilla de Azure Resource Manager
Puede haber ocasiones en las que necesite actualizar un recurso durante una implementación, como cuando no se pueden especificar todas las propiedades de un recurso hasta que se creen otros recursos dependientes. Por ejemplo, si crea un grupo de back-end para un equilibrador de carga, puede actualizar los adaptadores de red en sus máquinas virtuales (VM) para incluirlos en el grupo de back-end. Resource Manager admite la actualización de recursos durante la implementación, pero debe diseñar su plantilla correctamente para evitar errores y garantizar que la implementación se trate como una actualización.
Cuando cree un recurso y lo actualice más adelante, hará referencia a él dos veces. Primero hará referencia a ella en la plantilla que la crea. Más adelante, cuando actualice el recurso, hará referencia a él con el mismo nombre. Sin embargo, si dos recursos tienen el mismo nombre en una plantilla, Resource Manager genera una excepción. Para evitar este error, especifique el recurso actualizado en una segunda plantilla que haya vinculado o incluido como una subplantilla que usa el tipo de recurso Microsoft.Resources/deployments.
En la segunda plantilla, debe especificar el nombre de la propiedad existente para cambiar o proporcionar un nombre nuevo para una propiedad que se va a agregar. También debe especificar los nombres y los valores originales de las propiedades que no cambian. Si no especifica una o más de las propiedades originales, Resource Manager asume que desea crear un nuevo recurso y elimina el original.
Plantilla de ejemplo
Echemos un vistazo a una plantilla de ejemplo que muestra la técnica. La plantilla implementa una red virtual llamada firstVNet, que tiene una subred llamada firstSubnet. A continuación, implementa un adaptador de red (NIC) denominado nic1 y lo asocia a la subred. Un recurso de implementación llamado updateVNet incluye una plantilla anidada que actualiza firstVNet mediante la adición de una segunda subred llamada 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": {}
}
Considere el objeto de recurso para nuestro recurso firstVNet. Observe que volvemos a especificar la configuración de nuestro recurso firstVNet en una plantilla anidada. Esto es porque Resource Manager no permite el mismo nombre de implementación en la misma plantilla, y las plantillas anidadas se consideran plantillas diferentes. Al volver a especificar los valores de nuestro recurso firstSubnet, indicamos a Resource Manager que actualice el recurso existente en lugar de eliminarlo y volver a implementarlo. Por último, se recoge la nueva configuración de secondSubnet durante esta actualización.
Prueba de la plantilla
GitHub tiene una plantilla de ejemplo a su disposición. Para implementar la plantilla, ejecute los siguientes comandos de la CLI de Azure:
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
Cuando haya finalizado la implementación, abra el grupo de recursos especificado en el portal. Verá una red virtual llamada firstVNet y una NIC llamada nic1. Haga clic en firstVNet y luego en subnets. Verá el firstSubnet que se creó originalmente, y verá el secondSubnet que se agregó en el recurso updateVNet.
A continuación, vuelva al grupo de recursos y haga clic en nic1; después, haga clic en IP configurations. En la sección IP configurations, subnet se configura en firstSubnet (10.0.0.0/24).
El firstVNet original se actualizó en lugar de crearse de nuevo. Si firstVNet se hubiera creado de nuevo, nic1 no se asociaría con firstVNet.
Pasos siguientes
- Azure Resource Manager
- ¿Qué son las plantillas de Resource Manager?
- Tutorial: Creación e implementación de su primera plantilla de Resource Manager
- Tutorial: Incorporación de un recurso a la plantilla de Resource Manager
- Procedimientos recomendados para plantilla de Resource Manager
- Documentación de Azure Resource Manager
- Documentación de las plantillas de Resource Manager