Een resource bijwerken in een Azure Resource Manager-sjabloon
Het kan gebeuren dat u een resource tijdens een implementatie moet bijwerken, bijvoorbeeld wanneer u niet alle eigenschappen voor een resource kunt opgeven voordat andere, afhankelijke resources zijn gemaakt. Als u bijvoorbeeld een back-endpool voor een load balancer maakt, kunt u de netwerkinterfaces (NIC's) op uw virtuele machines (VM's) bijwerken om ze op te nemen in de back-endpool. Resource Manager ondersteunt het bijwerken van resources tijdens de implementatie, maar u moet uw sjabloon correct ontwerpen om fouten te voorkomen en ervoor te zorgen dat de implementatie wordt verwerkt als een update.
Wanneer u een resource maakt en deze later bijwerkt, verwijst u er twee keer naar. U verwijst er eerst naar in de sjabloon waarmee deze wordt gemaakt. Later, wanneer u de resource bijwerkt, verwijst u ernaar onder dezelfde naam. Als twee resources echter dezelfde naam hebben in een sjabloon, genereert Resource Manager een uitzondering. Als u deze fout wilt voorkomen, geeft u de bijgewerkte resource op in een tweede sjabloon die is gekoppeld of is opgenomen als subtemplate die gebruikmaakt van het Microsoft.Resources/deployments resourcetype.
In de tweede sjabloon moet u de naam opgeven van de eigenschap die u wilt wijzigen of een nieuwe naam voor een eigenschap die u wilt toevoegen. U moet ook de namen en oorspronkelijke waarden opgeven van de eigenschappen die niet worden gewijzigd. Als u een of meer van de oorspronkelijke eigenschappen niet opgeeft, gaat Resource Manager ervan uit dat u een nieuwe resource wilt maken en verwijdert u de oorspronkelijke.
Voorbeeldsjabloon
Laten we eens kijken naar een voorbeeldsjabloon die de techniek laat zien. De sjabloon implementeert een virtueel netwerk met de naam firstVNet met één subnet met de naam firstSubnet. Vervolgens wordt een virtuele netwerkinterface (NIC) met de naam geïmplementeerd nic1 en wordt de NIC gekoppeld aan het subnet. Een implementatieresource met de naam updateVNet bevat een geneste sjabloon die wordt bijgewerkt firstVNet door een tweede subnet met de naam secondSubnettoe te voegen.
{
"$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": {}
}
Overweeg het resourceobject voor onze firstVNet resource. U ziet dat we de instellingen voor onze firstVNet opnieuw opgeven in een geneste sjabloon. Dit komt omdat Resource Manager niet dezelfde implementatienaam in dezelfde sjabloon toestaat en geneste sjablonen als een andere sjabloon worden beschouwd. Door opnieuw de waarden voor onze firstSubnet resource op te geven, laten we Resource Manager de bestaande resource bijwerken in plaats van deze te verwijderen en opnieuw te implementeren. Ten slotte worden onze nieuwe instellingen voor secondSubnet opgehaald tijdens deze update.
Probeer de sjabloon
Er is een voorbeeldsjabloon beschikbaar op GitHub. Voer de volgende Azure CLI-opdrachten uit om de sjabloon te implementeren:
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
Nadat de implementatie is voltooid, opent u de resourcegroep die u in de portal hebt opgegeven. U ziet een virtueel netwerk met de naam firstVNet en een NIC met de naam nic1. Klik op firstVNeten klik vervolgens op subnets. U ziet de firstSubnet die oorspronkelijk is gemaakt en u ziet de secondSubnet die is toegevoegd in de updateVNet resource.
Ga vervolgens terug naar de resourcegroep, klik op nic1en klik vervolgens op IP configurations. In de IP configurations sectie is de subnet ingesteld op firstSubnet (10.0.0.0/24).
Het origineel firstVNet is bijgewerkt in plaats van opnieuw gemaakt. Als firstVNet opnieuw was gemaakt, nic1 zou niet worden gekoppeld aan firstVNet.
Volgende stappen
- Azure Resource Manager
- Wat zijn ARM-sjablonen?
- Zelfstudie: uw eerste ARM-sjabloon maken en implementeren
- Zelfstudie: Een resource aan uw ARM-sjabloon toevoegen
- Best practices voor ARM-sjablonen
- Documentatie voor Azure Resource Manager
- Documentatie voor ARM-sjablonen