Aktualizowanie zasobu w szablonie usługi Azure Resource Manager
Czasami trzeba zaktualizować zasób podczas wdrażania, na przykład wtedy, gdy nie można określić wszystkich właściwości zasobu do momentu utworzenia innych zasobów zależnych. Jeśli na przykład tworzysz pulę zaplecza dla modułu równoważenia obciążenia, możesz zaktualizować interfejsy sieciowe (karty sieciowe) na maszynach wirtualnych, aby uwzględnić je w puli zaplecza. Resource Manager obsługuje aktualizowanie zasobów podczas wdrażania, ale należy poprawnie zaprojektować szablon, aby uniknąć błędów i upewnić się, że wdrożenie jest obsługiwane jako aktualizacja.
Podczas tworzenia zasobu i aktualizowania go później należy się do niego odwoływać dwa razy. Odwołujesz się do niego najpierw w szablonie, który go tworzy. Później po zaktualizowaniu zasobu należy się do niego odwoływać przy użyciu tej samej nazwy. Jeśli jednak dwa zasoby mają taką samą nazwę w szablonie, Resource Manager zgłasza wyjątek. Aby uniknąć tego błędu, określ zaktualizowany zasób w drugim szablonie, który jest połączony lub dołączony jako podplatforma używająca Microsoft.Resources/deployments typu zasobu.
W drugim szablonie należy określić nazwę właściwości, która ma zostać zmieniona, lub nową nazwę właściwości do dodania. Należy również określić nazwy i oryginalne wartości właściwości, które nie ulegają zmianie. Jeśli nie określisz co najmniej jednej oryginalnej właściwości, Resource Manager zakłada, że chcesz utworzyć nowy zasób i usunąć oryginalny.
Przykładowy szablon
Przyjrzyjmy się przykładowej szablonowi, który demonstruje technikę. Szablon wdraża sieć wirtualną o nazwie firstVNet , która ma jedną podsieć o nazwie firstSubnet. Następnie wdraża wirtualny interfejs sieciowy o nazwie nic1 i kojarzy kartę sieciową z podsiecią. Zasób wdrożenia o nazwie updateVNet zawiera zagnieżdżony szablon, który jest aktualizowany firstVNet przez dodanie drugiej podsieci o nazwie 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": {}
}
Rozważmy obiekt zasobu dla naszego firstVNet zasobu. Zwróć uwagę, że ponownie określamy ustawienia dla szablonu firstVNet zagnieżdżonego — jest to spowodowane tym, że Resource Manager nie zezwala na tę samą nazwę wdrożenia w tym samym szablonie, a szablony zagnieżdżone są uważane za inny szablon. Ponownie określając nasze wartości dla naszego firstSubnet zasobu, informujemy, Resource Manager zaktualizować istniejący zasób zamiast go usunąć i ponownie wdrożyć. Na koniec nasze nowe ustawienia są secondSubnet pobierane podczas tej aktualizacji.
Wypróbuj szablon
Przykładowy szablon jest dostępny w witrynie GitHub. Aby wdrożyć szablon, uruchom następujące polecenia interfejsu wiersza polecenia platformy 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
Po zakończeniu wdrażania otwórz grupę zasobów określoną w portalu. Zostanie wyświetlona sieć wirtualna o nazwie firstVNet i karta sieciowa o nazwie nic1. Kliknij pozycję firstVNet, a następnie kliknij pozycję subnets. Zostanie wyświetlony firstSubnet element, który został pierwotnie utworzony, i zobaczysz secondSubnet element, który został dodany w zasobie updateVNet .
Następnie wróć do grupy zasobów i kliknij pozycję nic1, a następnie kliknij pozycję IP configurations.
IP configurations W sekcji subnet parametr jest ustawiony na firstSubnet (10.0.0.0/24)wartość .
Oryginał firstVNet został zaktualizowany zamiast ponownie utworzony. Jeśli firstVNet polecenie zostało utworzone ponownie, nic1 nie byłoby skojarzone z firstVNet.
Następne kroki
- Azure Resource Manager
- Co to są szablony usługi ARM?
- Samouczek: tworzenie i wdrażanie pierwszego szablonu usługi ARM
- Samouczek: dodawanie zasobu do szablonu usługi ARM
- Najlepsze rozwiązania dotyczące szablonu usługi ARM
- Dokumentacja usługi Azure Resource Manager
- Dokumentacja szablonów usługi ARM