Tworzenie szablonów ARM w celu zapewnienia spójności w chmurze

Kluczową zaletą platformy Azure jest spójność. Nakłady na rozwój dla jednej lokalizacji można wykorzystać ponownie w innej lokalizacji. Szablon usługi Azure Resource Manager (ARM) sprawia, że wdrożenia są spójne i powtarzalne w różnych środowiskach, w tym w globalnych chmurach platformy Azure, suwerennych chmurach platformy Azure i usłudze Azure Stack. Aby ponownie używać szablonów w chmurach, należy jednak wziąć pod uwagę zależności specyficzne dla chmury, jak wyjaśniono w tym przewodniku.

Firma Microsoft oferuje inteligentne, gotowe do użycia usługi w chmurze w wielu lokalizacjach, w tym:

• Globalna platforma Azure obsługiwana przez rosnącą sieć zarządzanych przez firmę Microsoft centrów danych w regionach na całym świecie.
• Odizolowane suwerenne chmury, takie jak Azure (Niemcy), Azure Government i Microsoft Azure obsługiwane przez firmę 21Vianet. Suwerenne chmury zapewniają spójną platformę z większością tych samych wspaniałych funkcji, do których mają dostęp globalni klienci platformy Azure.
• Azure Stack to hybrydowa platforma w chmurze, która umożliwia dostarczanie usług platformy Azure z centrum danych organizacji. Przedsiębiorstwa mogą skonfigurować usługę Azure Stack we własnych centrach danych lub korzystać z usług platformy Azure od dostawców usług, uruchamiając usługę Azure Stack w swoich obiektach (czasami nazywanych hostowanymi regionami).

W ramach wszystkich tych chmur usługa Azure Resource Manager udostępnia interfejs API, który umożliwia szeroką gamę interfejsów użytkownika do komunikowania się z platformą Azure. Ten interfejs API zapewnia zaawansowane możliwości tworzenia infrastruktury jako kodu. Dowolnego typu zasobu dostępnego na platformie Azure w chmurze można wdrożyć i skonfigurować za pomocą usługi Azure Resource Manager. Przy użyciu jednego szablonu można wdrożyć i skonfigurować całą aplikację do w pełni działającego stanu końcowego.

Spójność globalnej platformy Azure, suwerennych chmur, hostowanych chmur i chmury w centrum danych pomaga korzystać z usługi Azure Resource Manager. Możesz ponownie wykorzystać nakłady na prace programistyczne w tych środowiskach chmurowych, gdy skonfigurujesz wdrażanie i konfigurowanie zasobów na podstawie szablonów.

Jednak mimo że globalne, suwerenne, hostowane i hybrydowe chmury zapewniają spójne usługi, nie wszystkie chmury są identyczne. W związku z tym można utworzyć szablon z zależnościami dotyczącymi funkcji dostępnych tylko w określonej chmurze.

W pozostałej części tego przewodnika opisano obszary, które należy wziąć pod uwagę podczas planowania tworzenia nowych lub aktualizowania istniejących szablonów usługi ARM dla usługi Azure Stack. Ogólnie rzecz biorąc, lista kontrolna powinna zawierać następujące elementy:

• Sprawdź, czy funkcje, punkty końcowe, usługi i inne zasoby w szablonie są dostępne w docelowych lokalizacjach wdrażania.
• Przechowuj zagnieżdżone szablony i artefakty konfiguracyjne w łatwo dostępnych lokalizacjach, zapewniając dostęp z różnych chmur.
• Używaj odwołań dynamicznych zamiast linków i elementów zakodowanych na stałe.
• Upewnij się, że parametry szablonu, których używasz, działają w chmurach docelowych.
• Sprawdź, czy właściwości specyficzne dla zasobów są dostępne w chmurach docelowych.

Wprowadzenie do szablonów ARM zawiera temat Wdrażanie szablonów.

Upewnij się, że funkcje szablonu działają

Podstawowa składnia szablonu usługi ARM to JSON. Szablony korzystają z nadzbioru formatu JSON, rozszerzając składnię za pomocą wyrażeń i funkcji. Procesor języka szablonu jest często aktualizowany w celu obsługi dodatkowych funkcji szablonu. Aby uzyskać szczegółowe informacje o dostępnych funkcjach szablonu, zobacz funkcje szablonu ARM.

Nowe funkcje szablonu wprowadzone w usłudze Azure Resource Manager nie są natychmiast dostępne w suwerennych chmurach ani w usłudze Azure Stack. Aby pomyślnie wdrożyć szablon, wszystkie funkcje, do których odwołuje się szablon, muszą być dostępne w chmurze docelowej.

Funkcje usługi Azure Resource Manager zawsze będą wprowadzane do globalnej platformy Azure. Możesz użyć następującego skryptu programu PowerShell, aby sprawdzić, czy nowo wprowadzone funkcje szablonu są również dostępne w usłudze Azure Stack:

1. Sklonuj repozytorium GitHub: https://github.com/marcvaneijk/arm-template-functions.

2. Po utworzeniu lokalnej kopii repozytorium połącz się z usługą Azure Resource Manager dla miejsca docelowego za pomocą programu PowerShell.

3. Zaimportuj moduł psm1 i wykonaj polecenie cmdlet Test-AzureRmTemplateFunctions:

   # Import the module
   Import-module <path to local clone>\AzTemplateFunctions.psm1
   
   # Execute the Test-AzureRmTemplateFunctions cmdlet
   Test-AzureRmTemplateFunctions -path <path to local clone>
   

Skrypt wdraża wiele, zminimalizowanych szablonów, z których każdy zawiera tylko unikatowe funkcje szablonu. Dane wyjściowe skryptu zgłasza obsługiwane i niedostępne funkcje szablonu.

Praca z połączonymi artefaktami

Szablon może zawierać odwołania do połączonych artefaktów i zawiera zasób wdrożenia, który łączy się z innym szablonem. Połączone szablony (zwane także szablonami zagnieżdżonymi) są pobierane przez usługę Resource Manager w czasie wykonywania. Szablon może również zawierać odwołania do artefaktów dla rozszerzeń maszyn wirtualnych. Te artefakty są pobierane przez rozszerzenie maszyny wirtualnej uruchomione wewnątrz maszyny wirtualnej na potrzeby konfiguracji rozszerzenia maszyny wirtualnej podczas wdrażania szablonu.

W poniższych sekcjach opisano zagadnienia dotyczące spójności chmury podczas opracowywania szablonów zawierających artefakty zewnętrzne od głównego szablonu wdrażania.

Używaj szablonów zagnieżdżonych w różnych regionach

Szablony można rozdzielić na małe szablony wielokrotnego użytku, z których każdy ma określony cel i może być ponownie używany w różnych scenariuszach wdrażania. Aby wykonać wdrożenie, należy wskazać pojedynczy szablon, zwany szablonem głównym lub nadrzędnym. Określa zasoby do wdrożenia, takie jak sieci wirtualne, maszyny wirtualne i aplikacje internetowe. Główny szablon może również zawierać link do innego szablonu, co oznacza, że można zagnieżdżać szablony. Podobnie zagnieżdżony szablon może zawierać linki do innych szablonów. Można zagnieżdżać maksymalnie pięć poziomów głębokości.

Poniższy kod pokazuje, jak parametr templateLink odwołuje się do szablonu zagnieżdżonego:

"resources": [
  {
     "type": "Microsoft.Resources/deployments",
     "apiVersion": "2025-04-01",
     "name": "linkedTemplate",
     "properties": {
       "mode": "incremental",
       "templateLink": {
          "uri":"https://mystorageaccount.blob.core.windows.net/AzureTemplates/vNet.json",
          "contentVersion":"1.0.0.0"
       }
     }
  }
]

Usługa Azure Resource Manager ocenia główny szablon w czasie wykonywania i pobiera i ocenia każdy zagnieżdżony szablon. Po pobraniu wszystkich zagnieżdżonych szablonów następuje spłaszczenie szablonu, a następnie rozpoczyna się dalsze przetwarzanie.

Udostępnianie połączonych szablonów w chmurach

Zastanów się, gdzie i jak przechowywać używane szablony połączone. W czasie wykonywania usługa Azure Resource Manager pobiera i dlatego wymaga bezpośredniego dostępu do dowolnych połączonych szablonów. Typowym rozwiązaniem jest użycie usługi GitHub do przechowywania zagnieżdżonych szablonów. Repozytorium GitHub może zawierać pliki, które są dostępne publicznie za pośrednictwem adresu URL. Mimo że ta technika działa dobrze w przypadku chmury publicznej i suwerennych chmur, środowisko usługi Azure Stack może znajdować się w sieci firmowej lub w rozłączonej lokalizacji zdalnej, bez żadnego wychodzącego dostępu do Internetu. W takich sytuacjach usługa Azure Resource Manager nie zdołałaby pobrać zagnieżdżonych szablonów.

Lepszym rozwiązaniem w przypadku wdrożeń między chmurami jest przechowywanie połączonych szablonów w lokalizacji dostępnej dla chmury docelowej. Najlepiej, aby wszystkie artefakty wdrożeniowe były utrzymywane w potoku ciągłej integracji/ciągłego dostarczania (CI/CD) i z niego wdrażane. Alternatywnie, można przechowywać zagnieżdżone szablony w kontenerze usługi Blob Storage, z którego Azure Resource Manager może je pobrać.

Ponieważ magazyn obiektów blob w każdej chmurze używa innej w pełni kwalifikowanej nazwy domeny punktu końcowego (FQDN), skonfiguruj w szablonie lokalizację szablonów połączonych za pomocą dwóch parametrów. Parametry mogą akceptować dane wejściowe użytkownika w czasie wdrażania. Szablony są zwykle tworzone i udostępniane przez wiele osób, dlatego najlepszym rozwiązaniem jest użycie standardowej nazwy tych parametrów. Konwencje nazewnictwa ułatwiają tworzenie szablonów wielokrotnego użytku w różnych regionach, chmurach i autorach.

W poniższym kodzie _artifactsLocation służy do wskazywania pojedynczej lokalizacji zawierającej wszystkie artefakty związane z wdrażaniem. Zwróć uwagę, że podano wartość domyślną. W czasie wdrażania, jeśli dla parametru nie określono _artifactsLocationżadnej wartości wejściowej, zostanie użyta wartość domyślna. Parametr _artifactsLocationSasToken jest używany jako dane wejściowe dla elementu sasToken. Wartość domyślna powinna być pustym ciągiem dla scenariuszy, w których _artifactsLocation nie jest zabezpieczony — na przykład publiczne repozytorium GitHub.

"parameters": {
  "_artifactsLocation": {
    "type": "string",
    "metadata": {
      "description": "The base URI where artifacts required by this template are located."
    },
    "defaultValue": "https://raw.githubusercontent.com/Azure/azure-quickstart-templates/master/quickstarts/microsoft.compute/vm-custom-script-windows/"
  },
  "_artifactsLocationSasToken": {
    "type": "securestring",
    "metadata": {
      "description": "The sasToken required to access _artifactsLocation."
    },
    "defaultValue": ""
  }
}

W całym szablonie linki są generowane poprzez połączenie bazowego identyfikatora URI (z parametru _artifactsLocation) ze ścieżką względną artefaktu oraz _artifactsLocationSasToken. Poniższy kod pokazuje, jak określić odwołanie do zagnieżdżonego szablonu przy użyciu funkcji szablonu URI:

"resources": [
  {
    "type": "Microsoft.Resources/deployments",
    "apiVersion": "2025-04-01",
    "name": "shared",
    "properties": {
      "mode": "Incremental",
      "templateLink": {
        "uri": "[uri(parameters('_artifactsLocation'), concat('nested/vnet.json', parameters('_artifactsLocationSasToken')))]",
        "contentVersion": "1.0.0.0"
      }
    }
  }
]

Korzystając z tego podejścia, jest używana wartość domyślna parametru _artifactsLocation . Jeśli połączone szablony muszą zostać pobrane z innej lokalizacji, dane wejściowe parametru mogą być używane w czasie wdrażania w celu zastąpienia domyślnej wartości bez zmiany w samym szablonie.

Użyj _artifactsLocation zamiast wpisywać linki na sztywno

Oprócz zastosowania w szablonach zagnieżdżonych adres URL w parametrze _artifactsLocation jest używany jako podstawa wszystkich powiązanych artefaktów szablonu wdrożenia. Niektóre rozszerzenia maszyn wirtualnych zawierają link do skryptu przechowywanego poza szablonem. W przypadku tych rozszerzeń nie należy kodować linków na stałe. Na przykład rozszerzenia Custom Script i PowerShell DSC mogą zawierać odwołanie do zewnętrznego skryptu w serwisie GitHub, jak pokazano:

"properties": {
  "publisher": "Microsoft.Compute",
  "type": "CustomScriptExtension",
  "typeHandlerVersion": "1.9",
  "autoUpgradeMinorVersion": true,
  "settings": {
    "fileUris": [
      "https://raw.githubusercontent.com/Microsoft/dotnet-core-sample-templates/master/dotnet-core-music-windows/scripts/configure-music-app.ps1"
    ]
  }
}

Zakodowanie na stałe linków do skryptu może uniemożliwić pomyślne wdrożenie szablonu w innej lokalizacji. Podczas konfigurowania zasobu maszyny wirtualnej agent maszyny wirtualnej uruchomiony wewnątrz maszyny wirtualnej inicjuje pobieranie wszystkich skryptów połączonych w rozszerzeniu maszyny wirtualnej, a następnie przechowuje skrypty na dysku lokalnym maszyny wirtualnej. To podejście działa podobnie jak linki do szablonów zagnieżdżonych opisane wcześniej w sekcji „Używanie szablonów zagnieżdżonych w wielu regionach”.

Usługa Resource Manager pobiera zagnieżdżone szablony w czasie wykonywania. W przypadku rozszerzeń maszyn wirtualnych pobieranie wszystkich artefaktów zewnętrznych jest wykonywane przez agenta maszyny wirtualnej. Oprócz innego inicjatora pobierania artefaktu rozwiązanie w definicji szablonu jest takie samo. Użyj parametru _artifactsLocation z domyślną wartością wskazującą ścieżkę bazową, w której są przechowywane wszystkie artefakty (w tym skrypty rozszerzenia maszyny wirtualnej), oraz parametru _artifactsLocationSasToken jako danych wejściowych dla tokenu SAS.

"parameters": {
  "_artifactsLocation": {
    "type": "string",
    "metadata": {
      "description": "The base URI where artifacts required by this template are located."
    },
    "defaultValue": "https://raw.githubusercontent.com/Microsoft/dotnet-core-sample-templates/master/dotnet-core-music-windows/"
  },
  "_artifactsLocationSasToken": {
    "type": "securestring",
    "metadata": {
      "description": "The sasToken required to access _artifactsLocation."
    },
    "defaultValue": ""
  }
}

Aby utworzyć bezwzględny identyfikator URI artefaktu, preferowaną metodą jest użycie funkcji szablonu identyfikatora URI zamiast funkcji szablonu concat. Zastępując zakodowane na stałe linki do skryptów w rozszerzeniu maszyny wirtualnej funkcją szablonu identyfikatora URI, ta funkcja w szablonie jest skonfigurowana pod kątem spójności w chmurze.

"properties": {
  "publisher": "Microsoft.Compute",
  "type": "CustomScriptExtension",
  "typeHandlerVersion": "1.9",
  "autoUpgradeMinorVersion": true,
  "settings": {
    "fileUris": [
      "[uri(parameters('_artifactsLocation'), concat('scripts/configure-music-app.ps1', parameters('_artifactsLocationSasToken')))]"
    ]
  }
}

Dzięki temu podejściu wszystkie artefakty wdrażania, w tym skrypty konfiguracji, mogą być przechowywane w tej samej lokalizacji z samym szablonem. Aby zmienić lokalizację wszystkich linków, wystarczy podać inny bazowy adres URL dla parametrów artifactsLocation.

Współczynnik różnych możliwości regionalnych

Dzięki elastycznemu programowi i ciągłemu przepływowi aktualizacji i nowych usług wprowadzonych na platformie Azure regiony mogą różnić się dostępnością usług lub aktualizacji. Po rygorystycznym testowaniu wewnętrznym nowe usługi lub aktualizacje istniejących usług są zwykle wprowadzane do małych odbiorców klientów uczestniczących w programie weryfikacji. Po pomyślnej weryfikacji klienta usługi lub aktualizacje są udostępniane w podzestawie regionów platformy Azure, a następnie wprowadzane do większej liczby regionów, wdrażane w suwerennych chmurach i potencjalnie udostępniane klientom usługi Azure Stack.

Wiedząc, że regiony i chmury platformy Azure mogą się różnić w ich dostępnych usługach, możesz podejmować aktywne decyzje dotyczące szablonów. Dobrym miejscem do rozpoczęcia jest sprawdzenie dostępnych dostawców zasobów dla chmury. Dostawca zasobów informuje o zestawie zasobów i operacji dostępnych dla usługi platformy Azure.

Szablon wdraża i konfiguruje zasoby. Typ zasobu jest dostarczany przez dostawcę zasobów. Na przykład dostawca zasobów obliczeniowych (Microsoft.Compute) udostępnia wiele typów zasobów, takich jak virtualMachines i availabilitySets. Każdy dostawca zasobów udostępnia interfejs API do usługi Azure Resource Manager zdefiniowany przez wspólną umowę, umożliwiając spójne, ujednolicone środowisko tworzenia dla wszystkich dostawców zasobów. Jednak dostawca zasobów dostępny w globalnej platformie Azure może nie być dostępny w suwerennej chmurze lub regionie usługi Azure Stack.

Aby sprawdzić dostawców zasobów, którzy są dostępni w danej chmurze, uruchom następujący skrypt w interfejsie wiersza polecenia platformy Azure:

az provider list --query "[].{Provider:namespace, Status:registrationState}" --out table

Możesz również użyć następującego polecenia cmdlet programu PowerShell, aby wyświetlić dostępnych dostawców zasobów:

Get-AzureRmResourceProvider -ListAvailable | Select-Object ProviderNamespace, RegistrationState

Weryfikowanie wersji wszystkich typów zasobów

Zestaw właściwości jest wspólny dla wszystkich typów zasobów, ale każdy zasób ma również własne właściwości. Nowe funkcje i powiązane właściwości są dodawane do istniejących typów zasobów czasami za pośrednictwem nowej wersji interfejsu API. Zasób w szablonie ma własną właściwość wersji interfejsu API — apiVersion. Takie przechowywanie wersji gwarantuje, że istniejąca konfiguracja zasobów w szablonie nie ma wpływu na zmiany na platformie.

Nowe wersje interfejsu API wprowadzone do istniejących typów zasobów na globalnej platformie Azure mogą nie być natychmiast dostępne we wszystkich regionach, suwerennych chmurach lub usłudze Azure Stack. Aby wyświetlić listę dostępnych dostawców zasobów, typów zasobów i wersji interfejsu API dla chmury, możesz użyć Eksploratora zasobów w witrynie Azure Portal. Wyszukaj pozycję „Eksplorator zasobów” w menu „Wszystkie usługi”. Rozwiń węzeł Dostawcy w Eksploratorze zasobów, aby zwrócić wszystkich dostępnych dostawców zasobów, ich typy zasobów i wersje interfejsu API w tej chmurze.

Aby wyświetlić listę dostępnych wersji interfejsu API dla wszystkich typów zasobów w danej chmurze w interfejsie wiersza polecenia platformy Azure, uruchom następujący skrypt:

az provider list --query "[].{namespace:namespace, resourceType:resourceType[]}"

Możesz również użyć następującego polecenia cmdlet programu PowerShell:

Get-AzureRmResourceProvider | select-object ProviderNamespace -ExpandProperty ResourceTypes | ft ProviderNamespace, ResourceTypeName, ApiVersions

Odwołuj się do lokalizacji zasobów za pomocą parametru

Szablon jest zawsze wdrażany w grupie zasobów, która znajduje się w regionie. Oprócz samego wdrożenia każdy zasób w szablonie ma również właściwość lokalizacji, która służy do określania regionu do wdrożenia. Aby opracować szablon na potrzeby spójności chmury, potrzebny jest dynamiczny sposób odwoływania się do lokalizacji zasobów, ponieważ każda usługa Azure Stack może zawierać unikatowe nazwy lokalizacji. Zwykle zasoby są wdrażane w tym samym regionie co grupa zasobów, ale w celu obsługi scenariuszy, takich jak dostępność aplikacji między regionami, przydatne może być rozłożenie zasobów między regionami.

Mimo że nazwy regionów można zakodować na stałe podczas określania właściwości zasobu w szablonie, takie podejście nie gwarantuje, że szablon można wdrożyć w innych środowiskach usługi Azure Stack, ponieważ nazwa regionu najprawdopodobniej tam nie istnieje.

Aby pomieścić różne regiony, dodaj lokalizację parametru wejściowego do szablonu z wartością domyślną. Wartość domyślna będzie używana, jeśli podczas wdrażania nie określono żadnej wartości.

Funkcja [resourceGroup()] szablonu zwraca obiekt zawierający następujące pary klucz/wartość:

{
  "id": "/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}",
  "name": "{resourceGroupName}",
  "location": "{resourceGroupLocation}",
  "tags": {
  },
  "properties": {
    "provisioningState": "{status}"
  }
}

Odwołując się do klucza lokalizacji obiektu w wartości defaultValue parametru wejściowego, usługa Azure Resource Manager w czasie wykonywania zastąpi funkcję szablonu [resourceGroup().location] nazwą lokalizacji grupy zasobów, do której wdrażany jest szablon.

"parameters": {
  "location": {
    "type": "string",
    "metadata": {
      "description": "Location the resources will be deployed to."
    },
    "defaultValue": "[resourceGroup().location]"
  }
},
"resources": [
  {
    "type": "Microsoft.Storage/storageAccounts",
    "apiVersion": "2025-06-01",
    "name": "storageaccount1",
    "location": "[parameters('location')]",
    ...

Ta funkcja szablonu umożliwia wdrożenie szablonu w dowolnej chmurze bez wcześniejszej znajomości nazw regionów. Ponadto lokalizacja określonego zasobu w szablonie może różnić się od lokalizacji grupy zasobów. W takim przypadku można ją skonfigurować przy użyciu dodatkowych parametrów wejściowych dla tego konkretnego zasobu, podczas gdy inne zasoby w tym samym szablonie nadal używają parametru wejściowego lokalizacji początkowej.

Śledź wersje za pomocą profili API

Śledzenie wszystkich dostępnych dostawców zasobów i powiązanych wersji interfejsu API dostępnych w usłudze Azure Stack może być bardzo trudne. Na przykład w chwili pisania najnowsza wersja interfejsu API dla Microsoft.Compute/availabilitySets na platformie Azure to 2018-04-01, natomiast dostępna wersja interfejsu API wspólna dla platform Azure i Azure Stack to 2016-03-30. Typowa wersja interfejsu API dla usługi Microsoft.Storage/storageAccounts współdzielona między wszystkimi lokalizacjami platformy Azure i usługi Azure Stack to 2016-01-01, natomiast najnowsza wersja interfejsu API na platformie Azure to 2018-02-01.

Z tego powodu usługa Resource Manager wprowadziła koncepcję profilów interfejsu API do szablonów. Bez profilów interfejsu API każdy zasób w szablonie jest skonfigurowany przy użyciu elementu opisującego apiVersion wersję interfejsu API dla tego konkretnego zasobu.

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "location": {
      "type": "string",
      "metadata": {
          "description": "Location the resources will be deployed to."
      },
      "defaultValue": "[resourceGroup().location]"
    }
  },
  "variables": {},
  "resources": [
    {
      "type": "Microsoft.Storage/storageAccounts",
      "apiVersion": "2025-06-01",
      "name": "mystorageaccount",
      "location": "[parameters('location')]",
      "properties": {
        "accountType": "Standard_LRS"
      }
    },
    {
      "type": "Microsoft.Compute/availabilitySets",
      "apiVersion": "2025-04-01",
      "name": "myavailabilityset",
      "location": "[parameters('location')]",
      "properties": {
        "platformFaultDomainCount": 2,
        "platformUpdateDomainCount": 2
      }
    }
  ],
  "outputs": {}
}

Wersja profilu interfejsu API działa jako alias pojedynczej wersji interfejsu API dla typu zasobu wspólnego dla Azure i Azure Stack. Zamiast określać wersję interfejsu API dla każdego zasobu w szablonie, należy określić tylko wersję profilu interfejsu API w nowym elemenie głównym o nazwie apiProfile i pominąć apiVersion element dla poszczególnych zasobów.

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "apiProfile": "2018-03-01-hybrid",
  "parameters": {
    "location": {
      "type": "string",
      "metadata": {
        "description": "Location the resources will be deployed to."
      },
      "defaultValue": "[resourceGroup().location]"
    }
  },
  "variables": {},
  "resources": [
    {
      "type": "Microsoft.Storage/storageAccounts",
      "name": "mystorageaccount",
      "location": "[parameters('location')]",
      "properties": {
        "accountType": "Standard_LRS"
      }
    },
    {
      "type": "Microsoft.Compute/availabilitySets",
      "name": "myavailabilityset",
      "location": "[parameters('location')]",
      "properties": {
        "platformFaultDomainCount": 2,
        "platformUpdateDomainCount": 2
      }
    }
  ],
  "outputs": {}
}

Profil API zapewnia, że wersje API są dostępne we wszystkich lokalizacjach, więc nie trzeba ręcznie sprawdzać, które elementy `apiVersions` są dostępne w danej lokalizacji. Aby upewnić się, że wersje interfejsu API, do których odwołuje się Profil interfejsu API, znajdują się w środowisku usługi Azure Stack, operatorzy usługi Azure Stack muszą zachować aktualność rozwiązania na podstawie zasad pomocy technicznej. Jeśli system nie był aktualizowany od ponad sześciu miesięcy, uznaje się go za niezgodny, a środowisko musi zostać zaktualizowane.

Profil interfejsu API nie jest wymaganym elementem w szablonie. Nawet jeśli dodasz element, będzie on używany tylko dla zasobów, dla których nie określono apiVersion. Ten element umożliwia stopniowe zmiany, ale nie wymaga żadnych zmian w istniejących szablonach.

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "apiProfile": "2018-03-01-hybrid",
  "parameters": {
    "location": {
      "type": "string",
      "metadata": {
        "description": "Location the resources will be deployed to."
      },
      "defaultValue": "[resourceGroup().location]"
    }
  },
  "variables": {},
  "resources": [
    {
      "type": "Microsoft.Storage/storageAccounts",
      "apiVersion": "2025-06-01",
      "name": "mystorageaccount",
      "location": "[parameters('location')]",
      "properties": {
        "accountType": "Standard_LRS"
      }
    },
    {
      "type": "Microsoft.Compute/availabilitySets",
      "name": "myavailabilityset",
      "location": "[parameters('location')]",
      "properties": {
        "platformFaultDomainCount": 2,
        "platformUpdateDomainCount": 2
      }
    }
  ],
  "outputs": {}
}

Sprawdź odwołania do punktów końcowych

Zasoby mogą zawierać odwołania do innych usług na platformie. Na przykład publiczny adres IP może mieć przypisaną publiczną nazwę DNS. Chmura publiczna, suwerenne chmury i rozwiązania usługi Azure Stack mają własne odrębne przestrzenie nazw punktów końcowych. W większości przypadków zasób wymaga tylko prefiksu jako danych wejściowych w szablonie. Podczas działania usługa Azure Resource Manager dołącza do niego wartość punktu końcowego. Niektóre wartości punktu końcowego muszą być jawnie określone w szablonie.

Następujące dwa przykłady to typowe przestrzenie nazw punktów końcowych, które należy jawnie określić podczas tworzenia zasobu:

• Konta magazynu (obiekt blob, kolejka, tabela i plik)
• Parametry połączenia dla baz danych i usługi Redis zarządzanej Azure

Przestrzenie nazw punktów końcowych mogą być również używane w danych wyjściowych szablonu jako informacja dla użytkownika po zakończeniu wdrożenia. Poniżej przedstawiono typowe przykłady:

• Konta magazynu (obiekt blob, kolejka, tabela i plik)
• Parametry połączenia (MySql, SQLServer, SQLAzure, Custom, NotificationHub, ServiceBus, EventHub, ApiHub, DocDb, RedisCache, PostgreSQL)
• Menedżer ruchu
• domainNameLabel dla publicznego adresu IP
• Usługi w chmurze

Ogólnie rzecz biorąc, unikaj zakodowanych na stałe punktów końcowych w szablonie. Najlepszym rozwiązaniem jest użycie funkcji szablonu referencyjnego w celu dynamicznego pobierania punktów końcowych. Na przykład najczęściej trwale kodowanym punktem końcowym jest przestrzeń nazw punktów końcowych dla kont magazynu. Każde konto magazynowania ma unikatową nazwę domenową FQDN, która jest tworzona przez połączenie nazwy konta magazynowania z przestrzenią nazw punktu końcowego. Konto usługi Blob Storage o nazwie mystorageaccount1 skutkuje różnymi nazwami FQDN w zależności od chmury:

• mystorageaccount1.blob.core.windows.net utworzony w globalnej chmurze Azure.
• mystorageaccount1.blob.core.chinacloudapi.cn po utworzeniu w chmurze Azure obsługiwanej przez firmę 21Vianet.

Następująca funkcja szablonu referencyjnego pobiera przestrzeń nazw punktu końcowego od dostawcy zasobów magazynu:

"diskUri":"[concat(reference(resourceId('Microsoft.Storage/storageAccounts', variables('storageAccountName'))).primaryEndpoints.blob, 'container/myosdisk.vhd')]"

Zastępując zakodowaną na stałe wartość punktu końcowego konta magazynu funkcją szablonu reference, możesz użyć tego samego szablonu, aby pomyślnie wdrażać go w różnych środowiskach bez wprowadzania zmian w odwołaniu do punktu końcowego.

Odwołuj się do istniejących zasobów za pomocą unikatowego identyfikatora

Możesz również odwołać się do istniejącego zasobu w tej samej lub innej grupie zasobów oraz w tej samej lub innej subskrypcji, w obrębie tej samej dzierżawy i tej samej chmury. Aby pobrać właściwości zasobu, musisz użyć unikatowego identyfikatora samego zasobu. Funkcja resourceId szablonu pobiera unikatowy identyfikator zasobu, takiego jak program SQL Server, jak pokazano w poniższym kodzie:

"outputs": {
  "resourceId":{
    "type": "string",
    "value": "[resourceId('otherResourceGroup', 'Microsoft.Sql/servers', parameters('serverName'))]"
  }
}

Następnie możesz użyć resourceId funkcji wewnątrz funkcji szablonu reference , aby pobrać właściwości bazy danych. Obiekt zwracany fullyQualifiedDomainName zawiera właściwość, która zawiera pełną wartość punktu końcowego. Ta wartość jest pobierana w czasie wykonywania i udostępnia przestrzeń nazw punktu końcowego specyficzną dla środowiska chmurowego. Aby zdefiniować parametry połączenia bez wpisywania przestrzeni nazw punktu końcowego na sztywno, możesz odwołać się bezpośrednio w parametrach połączenia do właściwości zwracanego obiektu, jak pokazano poniżej:

"[concat('Server=tcp:', reference(resourceId('sql', 'Microsoft.Sql/servers', parameters('test')), '2015-05-01-preview').fullyQualifiedDomainName, ',1433;Initial Catalog=', parameters('database'),';User ID=', parameters('username'), ';Password=', parameters('pass'), ';Encrypt=True;')]"

Rozważ właściwości zasobu

Określone zasoby w środowiskach usługi Azure Stack mają unikatowe właściwości, które należy wziąć pod uwagę w szablonie.

Upewnij się, że obrazy maszyn wirtualnych są dostępne

Platforma Azure oferuje bogaty wybór obrazów maszyn wirtualnych. Te obrazy są tworzone i przygotowywane do wdrożenia przez firmę Microsoft i partnerów. Obrazy tworzą podstawę dla maszyn wirtualnych na platformie. Jednak szablon spójny z chmurą powinien odnosić się tylko do dostępnych parametrów — w szczególności wydawcy, oferty i jednostki SKU obrazów maszyn wirtualnych dostępnych dla globalnych chmur platformy Azure, suwerennych chmur platformy Azure lub rozwiązania usługi Azure Stack.

Aby pobrać listę dostępnych obrazów maszyn wirtualnych w lokalizacji, uruchom następujące polecenie interfejsu wiersza polecenia platformy Azure:

az vm image list -all

Tę samą listę można pobrać za pomocą polecenia cmdlet programu Azure PowerShell Get-AzureRmVMImagePublisher i określić odpowiednią lokalizację za pomocą parametru -Location . Na przykład:

Get-AzureRmVMImagePublisher -Location "West Europe" | Get-AzureRmVMImageOffer | Get-AzureRmVMImageSku | Get-AzureRmVMImage

Zwrócenie wszystkich dostępnych obrazów w regionie Europa Zachodnia globalnej chmury Azure za pomocą tego polecenia zajmuje kilka minut.

Jeśli te obrazy maszyn wirtualnych zostaną udostępnione usłudze Azure Stack, zostanie użyty cały dostępny magazyn. Aby pomieścić nawet najmniejszą jednostkę skalowania, usługa Azure Stack umożliwia wybranie obrazów, które chcesz dodać do środowiska.

Poniższy przykład kodu przedstawia spójny sposób odwoływania się do parametrów publisher, offer i SKU w szablonach ARM:

"storageProfile": {
    "imageReference": {
    "publisher": "MicrosoftWindowsServer",
    "offer": "WindowsServer",
    "sku": "2016-Datacenter",
    "version": "latest"
    }
}

Sprawdzanie rozmiarów lokalnych maszyn wirtualnych

Aby opracować szablon na potrzeby spójności chmury, upewnij się, że żądany rozmiar maszyny wirtualnej jest dostępny we wszystkich środowiskach docelowych. Rozmiary maszyn wirtualnych to grupa cech wydajności i możliwości. Niektóre rozmiary maszyn wirtualnych zależą od sprzętu, na jakim działa maszyna wirtualna. Jeśli na przykład chcesz wdrożyć maszynę wirtualną zoptymalizowaną pod kątem GPU, sprzęt, na którym działa hiperwizor, musi mieć fizyczne procesory graficzne.

Gdy firma Microsoft wprowadza nowy rozmiar maszyny wirtualnej, która ma pewne zależności sprzętowe, rozmiar maszyny wirtualnej jest zwykle udostępniany jako pierwszy w małym podzestawie regionów w chmurze platformy Azure. Później jest ona udostępniana innym regionom i chmurom. Aby upewnić się, że rozmiar maszyny wirtualnej istnieje w każdej wdrożonej chmurze, możesz pobrać dostępne rozmiary za pomocą następującego polecenia interfejsu wiersza polecenia platformy Azure:

az vm list-sizes --location "West Europe"

W przypadku programu Azure PowerShell użyj polecenia:

Get-AzureRmVMSize -Location "West Europe"

Aby uzyskać pełną listę dostępnych usług, zobacz Dostępność produktów według regionów.

Sprawdź użycie dysków zarządzanych platformy Azure w usłudze Azure Stack

Dyski zarządzane obsługują magazynowanie dla dzierżawcy usługi Azure. Zamiast jawnie tworzyć konto magazynowe i określać adres URI wirtualnego dysku twardego (VHD), możesz użyć dysków zarządzanych, aby te czynności były wykonywane automatycznie podczas wdrażania maszyny wirtualnej. Dyski zarządzane zwiększają dostępność dzięki umieszczeniu wszystkich dysków z maszyn wirtualnych należących do tego samego zestawu dostępności w różnych jednostkach magazynowych. Ponadto istniejące dyski VHD można przekonwertować z magazynu Standard do magazynu Premium przy znacznie krótszym przestoju.

Mimo że dyski zarządzane znajdują się w harmonogramie działania usługi Azure Stack, nie są one obecnie obsługiwane. Do tego czasu możesz tworzyć szablony zgodne z chmurą dla usługi Azure Stack, jawnie określając dyski VHD przy użyciu elementu vhd w szablonie zasobu maszyny wirtualnej, jak pokazano:

"storageProfile": {
  "imageReference": {
    "publisher": "MicrosoftWindowsServer",
    "offer": "WindowsServer",
    "sku": "[parameters('windowsOSVersion')]",
    "version": "latest"
  },
  "osDisk": {
    "name": "osdisk",
    "vhd": {
      "uri": "[concat(reference(resourceId('Microsoft.Storage/storageAccounts/', variables('storageAccountName')), '2015-06-15').primaryEndpoints.blob, 'vhds/osdisk.vhd')]"
    },
    "caching": "ReadWrite",
    "createOption": "FromImage"
  }
}

Natomiast aby określić konfigurację dysku zarządzanego w szablonie, usuń vhd element z konfiguracji dysku.

"storageProfile": {
  "imageReference": {
    "publisher": "MicrosoftWindowsServer",
    "offer": "WindowsServer",
    "sku": "[parameters('windowsOSVersion')]",
    "version": "latest"
  },
  "osDisk": {
    "caching": "ReadWrite",
    "createOption": "FromImage"
  }
}

Te same zmiany dotyczą również dysków danych.

Sprawdź, czy rozszerzenia maszyn wirtualnych są dostępne w usłudze Azure Stack

Inną kwestią dotyczącą spójności chmury jest użycie rozszerzeń maszyn wirtualnych do konfigurowania zasobów wewnątrz maszyny wirtualnej. Nie wszystkie rozszerzenia maszyn wirtualnych są dostępne w usłudze Azure Stack. Szablon może określać zasoby przeznaczone dla rozszerzenia maszyny wirtualnej, tworząc zależności i warunki w szablonie.

Jeśli na przykład chcesz skonfigurować maszynę wirtualną z uruchomionym programem Microsoft SQL Server, rozszerzenie maszyny wirtualnej może skonfigurować program SQL Server w ramach wdrożenia szablonu. Rozważ, co się stanie, jeśli szablon wdrożenia zawiera również serwer aplikacji skonfigurowany do utworzenia bazy danych na maszynie wirtualnej z uruchomionym programem SQL Server. Oprócz używania rozszerzenia maszyny wirtualnej dla serwerów aplikacji można skonfigurować zależność serwera aplikacji po pomyślnym powrocie zasobu rozszerzenia maszyny wirtualnej programu SQL Server. Takie podejście zapewnia, że maszyna wirtualna z uruchomionym programem SQL Server jest skonfigurowana i dostępna, gdy serwer aplikacji zostanie poinstruowany o utworzeniu bazy danych.

Deklaratywne podejście szablonu umożliwia zdefiniowanie stanu końcowego zasobów i ich zależności, podczas gdy platforma zajmuje się logiką wymaganą dla zależności.

Sprawdź, czy rozszerzenia maszyn wirtualnych są dostępne

Istnieje wiele typów rozszerzeń maszyn wirtualnych. Podczas tworzenia szablonu spójności w chmurze upewnij się, że używasz tylko rozszerzeń, które są dostępne we wszystkich regionach docelowych szablonów.

Aby pobrać listę rozszerzeń maszyn wirtualnych dostępnych dla określonego regionu (w tym przykładzie myLocation), uruchom następujące polecenie interfejsu wiersza polecenia platformy Azure:

az vm extension image list --location myLocation

Możesz również uruchomić polecenie cmdlet programu Azure PowerShell Get-AzureRmVmImagePublisher i użyć -Location, aby określić lokalizację obrazu maszyny wirtualnej. Na przykład:

Get-AzureRmVmImagePublisher -Location myLocation | Get-AzureRmVMExtensionImageType | Get-AzureRmVMExtensionImage | Select Type, Version

Upewnij się, że wersje są dostępne

Ponieważ rozszerzenia maszyn wirtualnych są zasobami usługi Resource Manager innych firm, mają własne wersje interfejsu API. Jak pokazano w poniższym kodzie, typ rozszerzenia maszyny wirtualnej jest zasobem zagnieżdżonym u dostawcy zasobów Microsoft.Compute.

{
    "type": "Microsoft.Compute/virtualMachines/extensions",
    "apiVersion": "2025-04-01",
    "name": "myExtension",
    "location": "[parameters('location')]",
    ...

Wersja interfejsu API zasobu rozszerzenia maszyny wirtualnej musi być dostępna we wszystkich lokalizacjach, na które chcesz kierować wdrożenie za pomocą szablonu. Zależność lokalizacji działa podobnie jak dostępność wersji interfejsu API dostawcy zasobów omówiona wcześniej w sekcji "Weryfikowanie wersji wszystkich typów zasobów".

Aby pobrać listę dostępnych wersji interfejsu API dla zasobu rozszerzenia maszyny wirtualnej, użyj polecenia cmdlet Get-AzureRmResourceProvider z dostawcą zasobów Microsoft.Compute, jak pokazano poniżej:

Get-AzureRmResourceProvider -ProviderNamespace "Microsoft.Compute" | Select-Object -ExpandProperty ResourceTypes | Select ResourceTypeName, Locations, ApiVersions | where {$_.ResourceTypeName -eq "virtualMachines/extensions"}

Można również używać rozszerzeń maszyn wirtualnych w zestawach skalowania maszyn wirtualnych. Mają zastosowanie te same warunki lokalizacji. Aby opracować szablon na potrzeby spójności w chmurze, upewnij się, że wersje interfejsu API są dostępne we wszystkich lokalizacjach, w których planujesz wdrożenie. Aby pobrać wersje interfejsu API zasobu rozszerzenia maszyny wirtualnej dla zestawów skalowania, użyj tego samego polecenia cmdlet co poprzednio, ale określ typ zasobu zestawów skalowania maszyn wirtualnych, jak pokazano poniżej:

Get-AzureRmResourceProvider -ProviderNamespace "Microsoft.Compute" | Select-Object -ExpandProperty ResourceTypes | Select ResourceTypeName, Locations, ApiVersions | where {$_.ResourceTypeName -eq "virtualMachineScaleSets/extensions"}

Każde określone rozszerzenie jest również wersjonowane. Ta wersja jest wyświetlana we właściwości typeHandlerVersion rozszerzenia maszyny wirtualnej. Upewnij się, że wersja określona w typeHandlerVersion elemekcie rozszerzeń maszyn wirtualnych szablonu jest dostępna w lokalizacjach, w których planujesz wdrożyć szablon. Na przykład następujący kod określa wersję 1.7:

{
    "type": "extensions",
    "apiVersion": "2016-03-30",
    "name": "MyCustomScriptExtension",
    "location": "[parameters('location')]",
    "dependsOn": [
        "[concat('Microsoft.Compute/virtualMachines/myVM', copyindex())]"
    ],
    "properties": {
        "publisher": "Microsoft.Compute",
        "type": "CustomScriptExtension",
        "typeHandlerVersion": "1.7",
        ...

Aby pobrać listę dostępnych wersji dla określonego rozszerzenia maszyny wirtualnej, użyj polecenia cmdlet Get-AzureRmVMExtensionImage . Poniższy przykład pobiera dostępne wersje rozszerzenia maszyny wirtualnej PowerShell DSC (Desired State Configuration) z lokalizacji myLocation:

Get-AzureRmVMExtensionImage -Location myLocation -PublisherName Microsoft.PowerShell -Type DSC | FT

Aby uzyskać listę wydawców, użyj polecenia Get-AzureRmVmImagePublisher . Aby zażądać typu, użyj polecenia Get-AzureRmVMExtensionImageType .

Porady dotyczące testowania i automatyzacji

Jest to wyzwanie, aby śledzić wszystkie powiązane ustawienia, możliwości i ograniczenia podczas tworzenia szablonu. Typowym podejściem jest opracowywanie i testowanie szablonów w jednej chmurze przed ukierunkowaniem innych lokalizacji. Jednak wcześniej, gdy testy są wykonywane w procesie tworzenia, tym mniej będzie konieczne rozwiązywanie problemów i ponowne zapisywanie kodu przez zespół deweloperów. Wdrożenia, które kończą się niepowodzeniem z powodu zależności lokalizacji, mogą być czasochłonne do rozwiązywania problemów. Dlatego zalecamy automatyczne testowanie tak szybko, jak to możliwe w cyklu tworzenia. Ostatecznie będziesz potrzebować mniej czasu programowania i mniej zasobów, a artefakty spójne z chmurą staną się jeszcze bardziej cenne.

Na poniższej ilustracji przedstawiono typowy przykład procesu programowania dla zespołu przy użyciu zintegrowanego środowiska projektowego (IDE). Na różnych etapach na osi czasu są wykonywane różne typy testów. W tym miejscu dwóch deweloperów pracuje nad tym samym rozwiązaniem, ale ten scenariusz ma zastosowanie w równym stopniu do jednego dewelopera lub dużego zespołu. Każdy deweloper zwykle tworzy lokalną kopię centralnego repozytorium, umożliwiając każdemu z nich pracę nad kopią lokalną bez wpływu na inne osoby, które mogą pracować nad tymi samymi plikami.

Rozważ następujące wskazówki dotyczące testowania i automatyzacji:

• Należy używać narzędzi do testowania. Na przykład programy Visual Studio Code i Visual Studio obejmują funkcję IntelliSense i inne funkcje, które mogą pomóc w weryfikowaniu szablonów.
• Aby poprawić jakość kodu podczas programowania w lokalnym środowisku IDE, przeprowadź analizę kodu statycznego przy użyciu testów jednostkowych i testów integracji.
• Aby zapewnić jeszcze lepsze wrażenia na początkowym etapie tworzenia, testy jednostkowe i testy integracyjne powinny jedynie generować ostrzeżenie po wykryciu problemu i kontynuować wykonywanie testów. W ten sposób można zidentyfikować problemy, które należy rozwiązać i określić kolejność zmian, nazywanych również wdrażaniem opartym na testach (TDD).
• Należy pamiętać, że niektóre testy można wykonać bez połączenia z usługą Azure Resource Manager. Inne, takie jak testowanie wdrożenia szablonu, wymagają usługi Resource Manager do wykonywania pewnych akcji, których nie można wykonać w trybie offline.
• Testowanie szablonu wdrożenia względem interfejsu API weryfikacji nie jest równe rzeczywistemu wdrożeniu. Ponadto nawet w przypadku wdrożenia szablonu z pliku lokalnego wszystkie odwołania do zagnieżdżonych szablonów w szablonie są pobierane bezpośrednio przez usługę Resource Manager, a artefakty przywoływane przez rozszerzenia maszyn wirtualnych są pobierane przez agenta maszyny wirtualnej działającego wewnątrz wdrożonej maszyny wirtualnej.

Następne kroki

• Zagadnienia dotyczące szablonu usługi Azure Resource Manager
• Najlepsze praktyki dotyczące szablonów ARM