Een resource bijwerken in een Azure Resource Manager sjabloon
Er zijn enkele scenario's waarin u een resource moet bijwerken tijdens een implementatie. Dit scenario kan optreden wanneer u niet alle eigenschappen voor een resource kunt opgeven totdat 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. En hoewel Resource Manager het bijwerken van resources tijdens de implementatie ondersteunt, moet u uw sjabloon correct ontwerpen om fouten te voorkomen en ervoor te zorgen dat de implementatie wordt verwerkt als een update.
Eerst moet u eenmaal in de sjabloon naar de resource verwijzen om deze te maken en vervolgens met dezelfde naam naar de resource verwijzen om deze later bij te werken. Als twee resources echter dezelfde naam hebben in een sjabloon, Resource Manager een uitzondering. Om deze fout te voorkomen, geeft u de bijgewerkte resource op in een tweede sjabloon die is gekoppeld of is opgenomen als een subtemplate met behulp van Microsoft.Resources/deployments het resourcetype.
Ten tweede moet u de naam opgeven van de bestaande eigenschap die u wilt wijzigen of een nieuwe naam voor een eigenschap die u wilt toevoegen aan de geneste sjabloon. U moet ook de oorspronkelijke eigenschappen en de oorspronkelijke waarden opgeven. Als u de oorspronkelijke eigenschappen en waarden niet op geeft, Resource Manager ervan uit dat u een nieuwe resource wilt maken en de oorspronkelijke resource verwijdert.
Voorbeeldsjabloon
Laten we eens kijken naar een voorbeeldsjabloon die dit laat zien. Met onze sjabloon wordt een virtueel netwerk met de firstVNet naam geïmplementeerd met één subnet met de naam firstSubnet . Vervolgens wordt een virtuele netwerkinterface (NIC) met de naam geïmplementeerd nic1 en aan ons subnet koppelt. Vervolgens bevat een implementatieresource met de naam een geneste sjabloon die onze resource bij werkt door een tweede subnet met de updateVNet firstVNet naam toe te secondSubnet 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": {}
}
Laten we eerst eens kijken naar het resourceobject voor firstVNet onze resource. U ziet dat we opnieuw de instellingen voor onze opgeven in een geneste sjabloon. Dit komt doordat Resource Manager niet dezelfde implementatienaam in dezelfde sjabloon toestaat en geneste sjablonen worden beschouwd als een firstVNet — andere sjabloon. Door opnieuw onze waarden voor onze resource op te geven, vertellen we Resource Manager de bestaande resource bij te werken in plaats van deze te verwijderen en opnieuw firstSubnet teployeren. Ten slotte worden de nieuwe secondSubnet instellingen voor opgehaald tijdens deze update.
De sjabloon uitproberen
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 hebt opgegeven in de portal. U ziet een virtueel netwerk met de firstVNet naam en een NIC met de naam nic1 . Klik firstVNet op en klik vervolgens op subnets . U ziet de die oorspronkelijk is gemaakt en u ziet de firstSubnet die is toegevoegd aan de secondSubnet updateVNet resource.
Ga vervolgens terug naar de resourcegroep en klik nic1 op IP configurations . In de IP configurations sectie is ingesteld op subnet firstSubnet (10.0.0.0/24) .
Het origineel firstVNet is bijgewerkt in plaats van opnieuw te worden gemaakt. Als firstVNet opnieuw is gemaakt, wordt niet gekoppeld aan nic1 firstVNet .
Volgende stappen
- Meer informatie over het gebruik van een -object als parameter in een Azure Resource Manager sjabloon.