Atualizar um recurso num modelo de Resource Manager do Azure
Pode haver alturas em que precisa de atualizar um recurso durante uma implementação, como quando não pode especificar todas as propriedades de um recurso até que sejam criados outros recursos dependentes. Por exemplo, se criar um conjunto de back-end para um balanceador de carga, poderá atualizar as interfaces de rede (NICs) nas máquinas virtuais (VMs) para as incluir no conjunto de back-end. Resource Manager suporta a atualização de recursos durante a implementação, mas tem de estruturar o modelo corretamente para evitar erros e para garantir que a implementação é processada como uma atualização.
Quando cria um recurso e o atualiza mais tarde, referencia-o duas vezes. Pode referenciá-lo primeiro no modelo que o cria. Mais tarde, quando atualizar o recurso, referencia-o pelo mesmo nome. No entanto, se dois recursos tiverem o mesmo nome num modelo, Resource Manager gera uma exceção. Para evitar este erro, especifique o recurso atualizado num segundo modelo que esteja ligado ou incluído como uma subtemplata que utilize o Microsoft.Resources/deployments tipo de recurso.
No segundo modelo, tem de especificar o nome da propriedade a alterar ou um novo nome para uma propriedade a adicionar. Também tem de especificar os nomes e os valores originais das propriedades que não são alteradas. Se não especificar uma ou mais das propriedades originais, Resource Manager parte do princípio de que pretende criar um novo recurso e elimina o original.
Modelo de exemplo
Vamos ver um modelo de exemplo que demonstra a técnica. O modelo implementa uma rede virtual com o nome firstVNet que tem uma sub-rede chamada firstSubnet. Em seguida, implementa uma interface de rede virtual (NIC) com o nome nic1 e associa a NIC à sub-rede. Um recurso de implementação com o nome updateVNet inclui um modelo aninhado que é atualizado firstVNet ao adicionar uma segunda sub-rede com o nome 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 firstVNet recurso. Repare que especificamos novamente as definições para o nosso firstVNet num modelo aninhado— isto deve-se ao facto de Resource Manager não permitir o mesmo nome de implementação no mesmo modelo e os modelos aninhados serem considerados um modelo diferente. Ao especificar novamente os nossos valores para o nosso firstSubnet recurso, indicamos ao Resource Manager para atualizar o recurso existente em vez de o eliminar e reimplementar. Por fim, as nossas novas definições para secondSubnet são recolhidas durante esta atualização.
Experimentar o modelo
Está disponível um modelo de exemplo no GitHub. Para implementar 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
Após a conclusão da implementação, abra o grupo de recursos que especificou no portal. Verá uma rede virtual com o nome firstVNet e um NIC com o nome nic1. Clique firstVNetem e, em seguida, clique em subnets. Verá o firstSubnet que foi originalmente criado e verá o secondSubnet que foi adicionado no updateVNet recurso.
Em seguida, volte ao grupo de recursos, clique em nic1e, em seguida, clique em IP configurations.
IP configurations Na secção , o subnet está definido como firstSubnet (10.0.0.0/24).
O original firstVNet foi atualizado em vez de recriado. Se firstVNet tivesse sido recriado, nic1 não seria associado firstVNeta .
Passos seguintes
- Azure Resource Manager
- O que são modelos do ARM?
- Tutorial: Criar e implementar o seu primeiro modelo do ARM
- Tutorial: Adicionar um recurso ao modelo do ARM
- Melhores práticas do modelo arm
- Documentação do Azure Resource Manager
- Documentação do modelo do ARM