Atualizar um recurso em um modelo do Azure Resource Manager
Pode haver momentos em que você precisa atualizar um recurso durante uma implantação, como quando não é possível especificar todas as propriedades de um recurso até que outros recursos dependentes sejam criados. Por exemplo, se você criar um pool de back-end para um balanceador de carga, poderá atualizar as NICs (adaptadores de rede) nas VMs (máquinas virtuais) para incluí-las no pool de back-end. O Resource Manager dá suporte à atualização de recursos durante a implantação, mas é necessário criar o modelo corretamente para evitar erros e garantir que a implantação é tratada como uma atualização.
Ao criar um recurso e atualizá-lo posteriormente, você o referencia duas vezes. Você faz referência a ele primeiro no modelo que o cria. Posteriormente, ao atualizar o recurso, você o referencia pelo mesmo nome. No entanto, se dois recursos tiverem o mesmo nome em um modelo, o Resource Manager gerará uma exceção. Para evitar esse erro, especifique o recurso atualizado em um segundo modelo que está vinculado ou incluído como um submodelo que usa o tipo de recurso Microsoft.Resources/deployments.
No segundo modelo, você deve especificar o nome da propriedade existente a ser alterado ou um novo nome de uma propriedade a ser adicionado. Você também deve especificar os nomes e os valores originais das propriedades que não são alteradas. Se você não especificar uma ou mais propriedades originais, o Resource Manager considerará que você deseja criar um novo recurso e excluirá o recurso original.
Modelo de exemplo
Vamos examinar um modelo de exemplo que demonstra a técnica. O modelo implanta uma rede virtual chamada firstVNet que tem uma sub-rede chamada firstSubnet. Em seguida, ele implanta uma NIC (interface de rede virtual) chamada nic1 e a associa à sub-rede. Um recurso de implantação denominado updateVNet inclui um modelo aninhado que atualiza firstVNet ao adicionar uma segunda sub-rede denominada 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 o objeto de recurso para o nosso recurso firstVNet. Observe que especificamos novamente as configurações para nosso firstVNet em um modelo aninhado. Isso ocorre porque o Resource Manager não permite que o mesmo nome de implantação no mesmo modelo e modelos aninhados sejam considerados como um modelo diferente. Ao especificarmos novamente nossos valores para o nosso recurso firstSubnet, estamos informando o Resource Manager para atualizar o recurso existente, em vez de excluí-lo e reimplantá-lo. Por fim, nossas novas configurações para secondSubnet são selecionadas durante essa atualização.
Experimentar o modelo
Um modelo de exemplo está disponível no GitHub. Para implantar o modelo, execute os seguintes comandos da CLI do 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
Depois que a implantação for concluída, abra o grupo de recursos que você especificou no portal. Você vê uma rede virtual denominada firstVNet e uma NIC denominada nic1. Clique em firstVNet e, depois, em subnets. Você verá a firstSubnet que foi originalmente criada e a secondSubnet que foi adicionada ao recurso updateVNet.
Depois, retorne ao grupo de recursos e clique em nic1. Em seguida, clique em IP configurations. Na seção IP configurations, a subnet é definida como firstSubnet (10.0.0.0/24).
A firstVNet original foi atualizada em vez de recriada. Se firstVNet tivesse sido recriada, a nic1 não seria associada a firstVNet.
Próximas etapas
- Azure Resource Manager
- O que são modelos do ARM?
- Tutorial: Criar e implantar seu primeiro modelo do Resource Manager
- Tutorial: Adicionar um recurso ao modelo do ARM
- Práticas recomendadas para modelos do ARM
- Documentação do Azure Resource Manager
- Documentação do modelo ARM