Vývoj šablon ARM pro konzistenci cloudu

Článek
10/16/2024

Důležité

Použití této funkce Azure z PowerShellu AzureRM vyžaduje nainstalovaný modul. Toto je starší modul dostupný jenom pro Windows PowerShell 5.1, který už nepřijímá nové funkce. Moduly Az nejsou AzureRM kompatibilní při instalaci pro stejné verze PowerShellu. Pokud potřebujete obě verze:

Odinstalujte modul Az z relace PowerShellu 5.1.
Nainstalujte modul AzureRM z relace PowerShellu 5.1.
Stáhněte a nainstalujte PowerShell Core 6.x nebo novější.
Nainstalujte modul Az v relaci PowerShellu Core.

Klíčovou výhodou Azure je konzistence. Investice do vývoje pro jedno místo jsou opakovaně použitelné v jiné. Šablona Azure Resource Manageru (šablona ARM) zajišťuje konzistentní a opakovatelná nasazení napříč prostředími, včetně globálních cloudů Azure, suverénních cloudů Azure a Azure Stacku. Pokud ale chcete použít šablony napříč cloudy, musíte zvážit závislosti specifické pro cloud, jak vysvětluje tento průvodce.

Microsoft nabízí inteligentní cloudové služby připravené pro podniky v mnoha umístěních, mezi které patří:

Globální platforma Azure podporovaná rostoucí sítí datacenter spravovaných Microsoftem v oblastech po celém světě.
Izolované suverénní cloudy, jako jsou Azure Germany, Azure Government a Microsoft Azure provozované společností 21Vianet. Suverénní cloudy poskytují konzistentní platformu s většinou stejných skvělých funkcí, ke kterým mají přístup globální zákazníci Azure.
Azure Stack, hybridní cloudová platforma, která umožňuje dodávat služby Azure z datacentra vaší organizace. Podniky můžou službu Azure Stack nastavit ve svých vlastních datacentrech nebo využívat služby Azure od poskytovatelů služeb, které běží ve svých zařízeních (někdy označované jako hostované oblasti).

V jádru všech těchto cloudů poskytuje Azure Resource Manager rozhraní API, které umožňuje širokou škálu uživatelských rozhraní ke komunikaci s platformou Azure. Toto rozhraní API poskytuje výkonné funkce infrastruktury jako kódu. Jakýkoli typ prostředku, který je k dispozici na cloudové platformě Azure, je možné nasadit a nakonfigurovat pomocí Azure Resource Manageru. Pomocí jedné šablony můžete nasadit a nakonfigurovat kompletní aplikaci do provozního stavu.

Diagram různých prostředí Azure, včetně globálních Azure, suverénních cloudů a služby Azure Stack

Konzistence globálního Azure, suverénních cloudů, hostovaných cloudů a cloudu ve vašem datacentru vám pomůže využívat Azure Resource Manager. Při nastavování nasazení a konfigurace prostředků založených na šablonách můžete znovu využít investice do vývoje v těchto cloudech.

I když globální, suverénní, hostovaný a hybridní cloud poskytují konzistentní služby, ne všechny cloudy jsou identické. V důsledku toho můžete vytvořit šablonu se závislostmi na funkcích dostupných pouze v konkrétním cloudu.

Zbývající část tohoto průvodce popisuje oblasti, které je potřeba vzít v úvahu při plánování vývoje nových nebo aktualizací existujících šablon ARM pro Azure Stack. Kontrolní seznam by obecně měl obsahovat následující položky:

Ověřte, že jsou funkce, koncové body, služby a další prostředky ve vaší šabloně dostupné v cílových umístěních nasazení.
Ukládejte vnořené šablony a artefakty konfigurace do přístupných umístění a zajistěte tak přístup napříč cloudy.
Místo pevně zakódovaných odkazů a prvků používejte dynamické odkazy.
Ujistěte se, že parametry šablony, které používáte, fungují v cílových cloudech.
Ověřte, že jsou v cílových cloudech dostupné vlastnosti specifické pro prostředky.

Úvod do šablon ARM najdete v tématu Nasazení šablon.

Zajištění fungování funkcí šablony

Základní syntaxe šablony ARM je JSON. Šablony používají nadmnožinu JSON, která rozšiřuje syntaxi pomocí výrazů a funkcí. Procesor jazyka šablony se často aktualizuje, aby podporoval další funkce šablon. Podrobné vysvětlení dostupných funkcí šablon najdete v tématu Funkce šablony ARM.

Nové funkce šablon, které jsou zavedeny do Azure Resource Manageru, nejsou okamžitě dostupné v suverénních cloudech ani ve službě Azure Stack. Pokud chcete šablonu úspěšně nasadit, musí být všechny funkce odkazované v šabloně dostupné v cílovém cloudu.

Funkce Azure Resource Manageru se vždy zavádějí do globálního Azure. Pomocí následujícího skriptu PowerShellu můžete ověřit, jestli jsou nově zavedené funkce šablony dostupné také ve službě Azure Stack:

Vytvořte klon úložiště GitHub: https://github.com/marcvaneijk/arm-template-functions.
Jakmile budete mít místní klon úložiště, připojte se k Azure Resource Manageru cíle pomocí PowerShellu.

Naimportujte modul psm1 a spusťte rutinu 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>

Skript nasadí několik minimalizovaných šablon, z nichž každý obsahuje pouze jedinečné funkce šablon. Výstup skriptu hlásí podporované a nedostupné funkce šablony.

Práce s propojenými artefakty

Šablona může obsahovat odkazy na propojené artefakty a obsahovat prostředek nasazení, který odkazuje na jinou šablonu. Propojené šablony (označované také jako vnořené šablony) načítají Resource Manager za běhu. Šablona může také obsahovat odkazy na artefakty pro rozšíření virtuálního počítače. Tyto artefakty se načítají rozšířením virtuálního počítače spuštěným uvnitř virtuálního počítače pro konfiguraci rozšíření virtuálního počítače během nasazení šablony.

Následující části popisují aspekty konzistence cloudu při vývoji šablon, které obsahují artefakty, které jsou externí pro hlavní šablonu nasazení.

Použití vnořených šablon napříč oblastmi

Šablony se dají rozdělit do malých opakovaně použitelných šablon, z nichž každá má konkrétní účel a dá se znovu použít v různých scénářích nasazení. Pokud chcete spustit nasazení, zadáte jednu šablonu, která se označuje jako hlavní nebo hlavní šablona. Určuje prostředky, které se mají nasadit, jako jsou virtuální sítě, virtuální počítače a webové aplikace. Hlavní šablona může také obsahovat odkaz na jinou šablonu, což znamená, že můžete vnořit šablony. Podobně může vnořená šablona obsahovat odkazy na jiné šablony. Do hloubky můžete vnořit až pět úrovní.

Následující kód ukazuje, jak parametr templateLink odkazuje na vnořenou šablonu:

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

Azure Resource Manager vyhodnotí hlavní šablonu za běhu a načte a vyhodnotí každou vnořenou šablonu. Po načtení všech vnořených šablon je šablona zploštěná a zahájí se další zpracování.

Zpřístupnění propojených šablon napříč cloudy

Zvažte, kde a jak ukládat všechny propojené šablony, které používáte. Za běhu načte Azure Resource Manager ( a proto vyžaduje přímý přístup ke všem propojeným šablonám). Běžným postupem je použití GitHubu k ukládání vnořených šablon. Úložiště GitHubu může obsahovat soubory, které jsou veřejně přístupné prostřednictvím adresy URL. I když tato technika funguje dobře pro veřejný cloud a suverénní cloudy, prostředí Azure Stack se může nacházet v podnikové síti nebo v odpojené vzdálené lokalitě bez odchozího přístupu k internetu. V takových případech se Azure Resource Manageru nepodaří načíst vnořené šablony.

Lepším postupem pro nasazení napříč cloudy je ukládat propojené šablony do umístění, které je přístupné pro cílový cloud. V ideálním případě jsou všechny artefakty nasazení udržovány a nasazeny z kanálu kontinuální integrace nebo průběžného vývoje (CI/CD). Alternativně můžete ukládat vnořené šablony do kontejneru úložiště objektů blob, ze kterého je Azure Resource Manager dokáže načíst.

Vzhledem k tomu, že úložiště objektů blob v každém cloudu používá jiný plně kvalifikovaný název domény koncového bodu, nakonfigurujte šablonu s umístěním propojených šablon se dvěma parametry. Parametry můžou přijímat vstup uživatele v době nasazení. Šablony jsou obvykle vytvořené a sdílené více lidmi, takže osvědčeným postupem je použít pro tyto parametry standardní název. Zásady vytváření názvů pomáhají vytvářet šablony opakovaně použitelné napříč oblastmi, cloudy a autory.

V následujícím kódu _artifactsLocation se používá odkaz na jedno umístění, které obsahuje všechny artefakty související s nasazením. Všimněte si, že je zadaná výchozí hodnota. Pokud v době nasazení není zadána _artifactsLocationžádná vstupní hodnota , použije se výchozí hodnota. Slouží _artifactsLocationSasToken jako vstup pro sasToken. Výchozí hodnota by měla být prázdný řetězec pro scénáře, kdy _artifactsLocation není zabezpečená – například veřejné úložiště 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": ""
  }
}

V celé šabloně se odkazy generují kombinací základního identifikátoru URI (z parametru _artifactsLocation ) s relativní cestou artefaktu a cestou _artifactsLocationSasToken. Následující kód ukazuje, jak pomocí funkce šablony URI určit odkaz na vnořenou šablonu:

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

Při použití tohoto přístupu se použije výchozí hodnota parametru _artifactsLocation . Pokud je potřeba načíst propojené šablony z jiného umístění, je možné vstup parametrů použít v době nasazení k přepsání výchozí hodnoty – není potřeba žádná změna samotné šablony.

Použití _artifactsLocation místo pevných odkazů

Kromě použití pro vnořené šablony se adresa URL v parametru _artifactsLocation používá jako základ pro všechny související artefakty šablony nasazení. Některá rozšíření virtuálních počítačů obsahují odkaz na skript uložený mimo šablonu. U těchto rozšíření byste propojení neměli pevně zakódovat. Například vlastní skript a rozšíření PowerShell DSC můžou odkazovat na externí skript na GitHubu, jak je znázorněno níže:

"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"
    ]
  }
}

Pevně zakódování odkazů na skript potenciálně zabrání úspěšnému nasazení šablony do jiného umístění. Během konfigurace prostředku virtuálního počítače zahájí agent virtuálního počítače spuštěný uvnitř virtuálního počítače stažení všech skriptů propojených v rozšíření virtuálního počítače a pak uloží skripty na místní disk virtuálního počítače. Tento přístup funguje podobně jako odkazy vnořené šablony popsané výše v části Použití vnořených šablon napříč oblastmi.

Resource Manager načte vnořené šablony za běhu. U rozšíření virtuálních počítačů provádí načítání jakýchkoli externích artefaktů agent virtuálního počítače. Kromě jiného iniciátoru načítání artefaktů je řešení v definici šablony stejné. Použijte parametr _artifactsLocation s výchozí hodnotou základní cesty, kde jsou uloženy všechny artefakty (včetně skriptů rozšíření virtuálního počítače) a _artifactsLocationSasToken parametr pro vstup sasTokenu.

"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": ""
  }
}

K vytvoření absolutního identifikátoru URI artefaktu je upřednostňovanou metodou použití funkce šablony identifikátoru URI místo funkce zřetězení šablony. Nahrazením pevně zakódovaných odkazů na skripty v rozšíření virtuálního počítače funkcí šablony URI se tato funkce v šabloně konfiguruje pro konzistenci cloudu.

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

Díky tomuto přístupu se všechny artefakty nasazení, včetně konfiguračních skriptů, dají uložit do stejného umístění se samotnou šablonou. Pokud chcete změnit umístění všech odkazů, stačí zadat jinou základní adresu URL parametrů artifactsLocation.

Faktor v různých regionálních možnostech

Díky agilnímu vývoji a průběžnému toku aktualizací a nových služeb zavedených v Azure se oblasti můžou lišit v dostupnosti služeb nebo aktualizací. Po důkladném interním testování se nové služby nebo aktualizace stávajících služeb obvykle zavádějí malým cílovým skupinám zákazníků, kteří se účastní ověřovacího programu. Po úspěšném ověření zákazníka se služby nebo aktualizace zpřístupní v podmnožině oblastí Azure, pak se představí v dalších oblastech, nasadí se do suverénních cloudů a potenciálně zpřístupní i zákazníkům azure Stacku.

Když víte, že oblasti a cloudy Azure se můžou v dostupných službách lišit, můžete se aktivně rozhodovat o svých šablonách. Dobrým místem, kde začít, je prozkoumání dostupných poskytovatelů prostředků pro cloud. Poskytovatel prostředků vám řekne sadu prostředků a operací, které jsou k dispozici pro službu Azure.

Šablona nasadí a nakonfiguruje prostředky. Typ prostředku poskytuje poskytovatel prostředků. Například poskytovatel výpočetních prostředků (Microsoft.Compute) poskytuje více typů prostředků, jako jsou virtualMachines a availabilitySets. Každý poskytovatel prostředků poskytuje rozhraní API pro Azure Resource Manager definovaný společným kontraktem, což umožňuje konzistentní jednotné prostředí pro vytváření napříč všemi poskytovateli prostředků. Poskytovatel prostředků, který je k dispozici v globálním Azure, ale nemusí být dostupný v suverénním cloudu nebo v oblasti Služby Azure Stack.

Diagram znázorňující vztah mezi poskytovateli prostředků, typy prostředků a verzemi rozhraní API

Pokud chcete ověřit poskytovatele prostředků, kteří jsou v daném cloudu k dispozici, spusťte v Azure CLI následující skript:

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

K zobrazení dostupných poskytovatelů prostředků můžete použít také následující rutinu PowerShellu:

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

Ověření verze všech typů prostředků

Sada vlastností je společná pro všechny typy prostředků, ale každý prostředek má také své vlastní specifické vlastnosti. Nové funkce a související vlastnosti se v současné době přidávají do existujících typů prostředků prostřednictvím nové verze rozhraní API. Prostředek v šabloně má vlastní vlastnost verze rozhraní API – apiVersion. Tato správa verzí zajišťuje, že změny na platformě neovlivní existující konfiguraci prostředků v šabloně.

Nové verze rozhraní API zavedené pro existující typy prostředků v globálním Azure nemusí být okamžitě dostupné ve všech oblastech, suverénních cloudech nebo ve službě Azure Stack. Pokud chcete zobrazit seznam dostupných poskytovatelů prostředků, typů prostředků a verzí rozhraní API pro cloud, můžete použít Průzkumníka prostředků na webu Azure Portal. V nabídce Všechny služby vyhledejte Průzkumníka prostředků. Rozbalte uzel Poskytovatelé v Průzkumníku prostředků a vraťte všechny dostupné poskytovatele prostředků, jejich typy prostředků a verze rozhraní API v daném cloudu.

Pokud chcete zobrazit seznam dostupných verzí rozhraní API pro všechny typy prostředků v daném cloudu v Azure CLI, spusťte následující skript:

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

Můžete také použít následující rutinu PowerShellu:

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

Odkaz na umístění prostředků s parametrem

Šablona se vždy nasadí do skupiny prostředků, která se nachází v oblasti. Kromě samotného nasazení má každý prostředek v šabloně také vlastnost umístění, kterou použijete k určení oblasti, do které se má nasadit. Pokud chcete vytvořit šablonu pro konzistenci cloudu, potřebujete dynamický způsob odkazování na umístění prostředků, protože každá služba Azure Stack může obsahovat jedinečné názvy umístění. Prostředky se obvykle nasazují ve stejné oblasti jako skupina prostředků, ale pro podporu scénářů, jako je dostupnost aplikací napříč oblastmi, může být užitečné prostředky rozložit mezi oblasti.

I když byste při zadávání vlastností prostředku v šabloně mohli pevně zakódovat názvy oblastí, tento přístup nezaručuje nasazení šablony do jiných prostředí služby Azure Stack, protože název oblasti tam pravděpodobně neexistuje.

Pokud chcete přizpůsobit různé oblasti, přidejte do šablony umístění vstupního parametru s výchozí hodnotou. Výchozí hodnota se použije, pokud během nasazení není zadána žádná hodnota.

Funkce [resourceGroup()] šablony vrátí objekt, který obsahuje následující páry klíč/hodnota:

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

Odkazováním na klíč umístění objektu ve výchozí hodnotě vstupního parametru azure Resource Manager nahradí [resourceGroup().location] za běhu funkci šablony názvem umístění skupiny prostředků, do které se šablona nasadí.

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

Pomocí této funkce šablony můžete šablonu nasadit do libovolného cloudu, aniž byste předem znali názvy oblastí. Umístění pro konkrétní prostředek v šabloně se navíc může lišit od umístění skupiny prostředků. V tomto případě ho můžete nakonfigurovat pomocí dalších vstupních parametrů pro daný prostředek, zatímco ostatní prostředky ve stejné šabloně stále používají vstupní parametr počátečního umístění.

Sledování verzí pomocí profilů rozhraní API

Může být velmi náročné sledovat všechny dostupné poskytovatele prostředků a související verze rozhraní API, které jsou přítomné ve službě Azure Stack. Například v době psaní tohoto článku je 2018-04-01nejnovější verze rozhraní API pro Microsoft.Compute/availabilitySets v Azure, zatímco dostupná verze rozhraní API společná pro Azure a Azure Stack je 2016-03-30. Běžná verze rozhraní API pro Microsoft.Storage/storageAccounts sdílená mezi všemi umístěními Azure a Azure Stack je 2016-01-01, zatímco nejnovější verze rozhraní API v Azure je 2018-02-01.

Z tohoto důvodu Resource Manager zavedl do šablon koncept profilů rozhraní API. Bez profilů rozhraní API je každý prostředek v šabloně nakonfigurovaný pomocí apiVersion elementu, který popisuje verzi rozhraní API pro daný prostředek.

{
  "$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": "2016-01-01",
      "name": "mystorageaccount",
      "location": "[parameters('location')]",
      "properties": {
        "accountType": "Standard_LRS"
      }
    },
    {
      "type": "Microsoft.Compute/availabilitySets",
      "apiVersion": "2016-03-30",
      "name": "myavailabilityset",
      "location": "[parameters('location')]",
      "properties": {
        "platformFaultDomainCount": 2,
        "platformUpdateDomainCount": 2
      }
    }
  ],
  "outputs": {}
}

Verze profilu rozhraní API funguje jako alias pro jednu verzi rozhraní API podle typu prostředku, který je společný pro Azure a Azure Stack. Místo zadání verze rozhraní API pro každý prostředek v šabloně zadáte pouze verzi profilu rozhraní API v novém kořenovém elementu volaného apiProfile a vynecháte apiVersion prvek pro jednotlivé prostředky.

{
    "$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 rozhraní API zajišťuje, že jsou verze rozhraní API dostupné napříč umístěními, takže nemusíte ručně ověřovat verze apiVersion, které jsou k dispozici v určitém umístění. Aby se zajistilo, že verze rozhraní API, na které odkazuje váš profil rozhraní API, existují v prostředí Služby Azure Stack, musí operátoři služby Azure Stack udržovat řešení v aktualizovaném stavu na základě zásad podpory. Pokud je systém zastaralý více než šest měsíců, považuje se za nedodržování předpisů a prostředí se musí aktualizovat.

Profil rozhraní API není požadovaným prvkem v šabloně. I když přidáte prvek, použije se pouze pro prostředky, pro které není zadán žádný apiVersion . Tento prvek umožňuje postupné změny, ale nevyžaduje žádné změny existujících šablon.

{
    "$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": "2016-01-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": {}
}

Kontrola odkazů na koncové body

Prostředky můžou mít odkazy na jiné služby na platformě. Veřejná IP adresa může mít například přiřazený veřejný název DNS. Veřejný cloud, suverénní cloudy a řešení Azure Stack mají vlastní jedinečné obory názvů koncových bodů. Ve většině případů prostředek vyžaduje pouze předponu jako vstup v šabloně. Během běhu azure Resource Manager připojí k němu hodnotu koncového bodu. Některé hodnoty koncového bodu musí být explicitně zadány v šabloně.

Poznámka:

Pokud chcete vyvíjet šablony pro konzistenci cloudu, nezakódujte obory názvů koncových bodů pevně.

Následující dva příklady jsou běžné obory názvů koncových bodů, které je potřeba explicitně zadat při vytváření prostředku:

Účty úložiště (objekty blob, fronta, tabulka a soubor)
Připojovací řetězce pro databáze a Azure Cache for Redis

Obory názvů koncových bodů se dají použít také ve výstupu šablony jako informace pro uživatele po dokončení nasazení. Tady jsou běžné příklady:

Účty úložiště (objekty blob, fronta, tabulka a soubor)
Připojovací řetězce (MySql, SQLServer, SQLAzure, Custom, NotificationHub, ServiceBus, EventHub, ApiHub, DocDb, RedisCache, PostgreSQL)
Traffic Manager
domainNameLabel veřejné IP adresy
Cloudové služby

Obecně platí, že se v šabloně vyhněte pevně zakódovaným koncovým bodům. Osvědčeným postupem je dynamicky načíst koncové body pomocí funkce referenční šablony. Nejčastěji zakódovaný koncový bod je například obor názvů koncového bodu pro účty úložiště. Každý účet úložiště má jedinečný plně kvalifikovaný název domény vytvořený zřetězením názvu účtu úložiště s oborem názvů koncového bodu. Účet úložiště objektů blob s názvem mystorageaccount1 vede k různým plně kvalifikovaným názvům domén v závislosti na cloudu:

mystorageaccount1.blob.core.windows.net při vytváření v globálním cloudu Azure.
mystorageaccount1.blob.core.chinacloudapi.cn při vytváření v Azure provozovaném cloudem 21Vianet.

Následující referenční funkce šablony načte obor názvů koncového bodu od poskytovatele prostředků úložiště:

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

Nahrazením pevně zakódované hodnoty koncového bodu reference účtu úložiště funkcí šablony můžete stejnou šablonu použít k úspěšnému nasazení do různých prostředí bez provedení jakýchkoli změn odkazu na koncový bod.

Odkaz na existující prostředky podle jedinečného ID

Můžete také odkazovat na existující prostředek ze stejné nebo jiné skupiny prostředků a v rámci stejného předplatného nebo jiného předplatného ve stejném tenantovi ve stejném cloudu. Pokud chcete načíst vlastnosti prostředku, musíte použít jedinečný identifikátor samotného prostředku. Funkce resourceId šablony načte jedinečné ID prostředku, jako je SQL Server, jak ukazuje následující kód:

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

Potom můžete funkci uvnitř reference funkce šablony použít resourceId k načtení vlastností databáze. Návratový objekt obsahuje fullyQualifiedDomainName vlastnost, která obsahuje úplnou hodnotu koncového bodu. Tato hodnota se načte za běhu a poskytuje obor názvů koncového bodu specifického pro cloudové prostředí. Pokud chcete definovat připojovací řetězec bez pevného kódování oboru názvů koncového bodu, můžete odkazovat na vlastnost návratového objektu přímo v připojovací řetězec, jak je znázorněno na obrázku:

"[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;')]"

Zvážení vlastností prostředku

Konkrétní prostředky v prostředích Azure Stack mají jedinečné vlastnosti, které je nutné vzít v úvahu ve své šabloně.

Ujistěte se, že jsou k dispozici image virtuálních počítačů.

Azure nabízí bohatý výběr imagí virtuálních počítačů. Tyto image se vytvářejí a připraví pro nasazení microsoftem a partnery. Image tvoří základ pro virtuální počítače na platformě. Šablona konzistentní s cloudem by ale měla odkazovat pouze na dostupné parametry – zejména vydavatele, nabídky a skladové položky imagí virtuálních počítačů, které jsou dostupné pro globální Azure, suverénní cloudy Azure nebo řešení Azure Stack.

Pokud chcete načíst seznam dostupných imagí virtuálních počítačů v umístění, spusťte následující příkaz Azure CLI:

az vm image list -all

Stejný seznam můžete načíst pomocí rutiny Azure PowerShell Get-AzureRmVMImagePublisher a zadat požadované umístění pomocí parametru -Location . Příklad:

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

Vrácení všech dostupných imagí v oblasti Západní Evropa globálního cloudu Azure trvá několik minut.

Pokud jste tyto image virtuálních počítačů zpřístupnili službě Azure Stack, bude využito veškeré dostupné úložiště. Azure Stack umožňuje vybrat image, které chcete přidat do prostředí, aby vyhovovala i nejmenší jednotce škálování.

Následující ukázka kódu ukazuje konzistentní přístup k odkazování na parametry vydavatele, nabídky a skladové položky v šablonách ARM:

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

Kontrola velikostí místních virtuálních počítačů

Pokud chcete vytvořit šablonu pro konzistenci cloudu, musíte zajistit, aby byla požadovaná velikost virtuálního počítače dostupná ve všech cílových prostředích. Velikosti virtuálních počítačů jsou seskupením charakteristik a možností výkonu. Některé velikosti virtuálních počítačů závisí na hardwaru, na kterém je virtuální počítač spuštěný. Pokud například chcete nasadit virtuální počítač optimalizovaný pro GPU, musí mít hardware, na kterém běží hypervisor, hardwarové GPU.

Když Microsoft zavádí novou velikost virtuálního počítače, která má určité hardwarové závislosti, je velikost virtuálního počítače obvykle dostupná jako první v malé podmnožině oblastí v cloudu Azure. Později se zpřístupní pro další oblasti a cloudy. Abyste měli jistotu, že velikost virtuálního počítače existuje v každém cloudu, na který nasadíte, můžete získat dostupné velikosti pomocí následujícího příkazu Azure CLI:

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

Pokud používáte Azure PowerShell, použijte:

Get-AzureRmVMSize -Location "West Europe"

Úplný seznam dostupných služeb najdete v tématu Produkty dostupné v jednotlivých oblastech.

Kontrola použití služby Azure Spravované disky ve službě Azure Stack

Spravované disky zpracovávají úložiště pro tenanta Azure. Místo explicitního vytvoření účtu úložiště a zadání identifikátoru URI pro virtuální pevný disk (VHD) můžete použít spravované disky k implicitní provádění těchto akcí při nasazování virtuálního počítače. Spravované disky zvyšují dostupnost umístěním všech disků z virtuálních počítačů do stejné skupiny dostupnosti do různých jednotek úložiště. Kromě toho je možné stávající virtuální pevné disky převést z úložiště Úrovně Standard na Premium s výrazně menším výpadkem.

I když jsou spravované disky v plánu pro Azure Stack, v současné době se nepodporují. Dokud nebudou, můžete vyvíjet šablony konzistentní s cloudem pro Azure Stack tím, že explicitně zadáte virtuální pevné disky pomocí vhd elementu v šabloně pro prostředek virtuálního počítače, jak je znázorněno na obrázku:

"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"
  }
}

Pokud chcete v šabloně zadat konfiguraci spravovaného disku, odeberte vhd prvek z konfigurace disku.

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

Stejné změny také používají datové disky.

Ověření dostupnosti rozšíření virtuálních počítačů ve službě Azure Stack

Dalším aspektem konzistence cloudu je použití rozšíření virtuálních počítačů ke konfiguraci prostředků ve virtuálním počítači. Ve službě Azure Stack nejsou dostupná všechna rozšíření virtuálních počítačů. Šablona může určit prostředky vyhrazené pro rozšíření virtuálního počítače a vytvořit závislosti a podmínky v rámci šablony.

Pokud například chcete nakonfigurovat virtuální počítač s Microsoft SQL Serverem, může rozšíření virtuálního počítače nakonfigurovat SQL Server jako součást nasazení šablony. Zvažte, co se stane, pokud šablona nasazení obsahuje také aplikační server nakonfigurovaný k vytvoření databáze na virtuálním počítači s SQL Serverem. Kromě použití rozšíření virtuálního počítače pro aplikační servery můžete nakonfigurovat závislost aplikačního serveru na úspěšném vrácení prostředku rozšíření virtuálního počítače s SQL Serverem. Tento přístup zajišťuje, že je virtuální počítač s SQL Serverem nakonfigurovaný a dostupný, když je aplikační server instruován k vytvoření databáze.

Deklarativní přístup šablony umožňuje definovat koncový stav prostředků a jejich vzájemné závislosti, zatímco platforma se postará o logiku potřebnou pro závislosti.

Zkontrolujte, jestli jsou dostupná rozšíření virtuálních počítačů.

Existuje mnoho typů rozšíření virtuálních počítačů. Při vývoji šablony pro konzistenci cloudu nezapomeňte použít pouze rozšíření, která jsou k dispozici ve všech oblastech, na které šablona cílí.

Pokud chcete načíst seznam rozšíření virtuálních počítačů, která jsou k dispozici pro konkrétní oblast (v tomto příkladu myLocation), spusťte následující příkaz Azure CLI:

az vm extension image list --location myLocation

Můžete také spustit rutinu Get-AzureRmVmImagePublisher Azure PowerShellu a použít -Location k určení umístění image virtuálního počítače. Příklad:

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

Ujistěte se, že jsou dostupné verze.

Vzhledem k tomu, že rozšíření virtuálních počítačů jsou prostředky Resource Manageru první strany, mají vlastní verze rozhraní API. Jak ukazuje následující kód, typ rozšíření virtuálního počítače je vnořený prostředek v poskytovateli prostředků Microsoft.Compute.

{
    "type": "Microsoft.Compute/virtualMachines/extensions",
    "apiVersion": "2015-06-15",
    "name": "myExtension",
    "location": "[parameters('location')]",
    ...

Verze rozhraní API prostředku rozšíření virtuálního počítače musí být k dispozici ve všech umístěních, na která chcete cílit se šablonou. Závislost umístění funguje podobně jako dostupnost verze rozhraní API poskytovatele prostředků, která je popsána dříve v části Ověření verze všech typů prostředků.

Pokud chcete načíst seznam dostupných verzí rozhraní API pro prostředek rozšíření virtuálního počítače, použijte rutinu Get-AzureRmResourceProvider s poskytovatelem prostředků Microsoft.Compute , jak je znázorněno níže:

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

Rozšíření virtuálních počítačů můžete použít také ve škálovacích sadách virtuálních počítačů. Platí stejné podmínky umístění. Pokud chcete vytvořit šablonu pro konzistenci cloudu, ujistěte se, že jsou verze rozhraní API dostupné ve všech umístěních, do kterých plánujete nasazení. Pokud chcete načíst verze rozhraní API prostředku rozšíření virtuálního počítače pro škálovací sady, použijte stejnou rutinu jako předtím, ale zadejte typ prostředku škálovacích sad virtuálních počítačů, jak je znázorněno:

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

Každé konkrétní rozšíření je také verze. Tato verze se zobrazuje ve typeHandlerVersion vlastnosti rozšíření virtuálního počítače. Ujistěte se, že verze zadaná v typeHandlerVersion elementu rozšíření virtuálních počítačů šablony jsou k dispozici v umístěních, kde plánujete šablonu nasadit. Například následující kód určuje verzi 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",
        ...

Pokud chcete načíst seznam dostupných verzí pro konkrétní rozšíření virtuálního počítače, použijte rutinu Get-AzureRmVMExtensionImage . Následující příklad načte dostupné verze rozšíření virtuálního počítače PowerShell DSC (Desired State Configuration) z myLocation:

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

Pokud chcete získat seznam vydavatelů, použijte příkaz Get-AzureRmVmImagePublisher . Pokud chcete požádat o typ, použijte rutinu Get-AzureRmVMExtensionImageType .

Tipy pro testování a automatizaci

Při vytváření šablony je náročné sledovat všechna související nastavení, možnosti a omezení. Běžným přístupem je vývoj a testování šablon v jednom cloudu před cílem jiných umístění. Dříve, než se ale testy provádějí v procesu vytváření, bude nutné méně řešit potíže a přepisovat kód, který váš vývojový tým musí provést. Nasazení, která selžou kvůli závislostem umístění, můžou být časově náročná pro řešení potíží. Proto doporučujeme automatizované testování co nejdříve v cyklu vytváření. V konečném důsledku budete potřebovat méně času vývoje a méně prostředků a artefakty konzistentní s cloudem budou ještě cennější.

Následující obrázek znázorňuje typický příklad vývojového procesu pro tým pomocí integrovaného vývojového prostředí (IDE). V různých fázích časové osy se provádějí různé typy testů. V tomto případě pracují dva vývojáři na stejném řešení, ale tento scénář platí stejně pro jednoho vývojáře nebo velkého týmu. Každý vývojář obvykle vytvoří místní kopii centrálního úložiště, která každému z nich umožní pracovat na místní kopii, aniž by to mělo vliv na ostatní, kteří můžou pracovat na stejných souborech.

Diagram znázorňující paralelní testy jednotek a integrační testy v místních prostředích ID, sloučení do vývojového toku CI/CD s testy jednotek, integračními testy, testovacím nasazením a konečným nasazením

Zvažte následující tipy pro testování a automatizaci:

Využijte testovací nástroje. Visual Studio Code a Visual Studio například obsahují IntelliSense a další funkce, které vám můžou pomoct s ověřením šablon.
Pokud chcete zlepšit kvalitu kódu během vývoje v místním integrovaném vývojovém prostředí ( IDE), proveďte statickou analýzu kódu pomocí testů jednotek a integračních testů.
Pro ještě lepší prostředí během počátečního vývoje by testy jednotek a integrační testy měly varovat pouze v případě nalezení problému a pokračování v testech. Tímto způsobem můžete identifikovat problémy, které se mají vyřešit, a určit jejich prioritu pořadí, označované také jako testovací nasazení (TDD).
Mějte na paměti, že některé testy je možné provádět bez připojení k Azure Resource Manageru. Jiné, například testování nasazení šablony, vyžadují, aby Resource Manager prováděl určité akce, které nelze provést offline.
Testování šablony nasazení pomocí ověřovacího rozhraní API se nerovná skutečnému nasazení. I když nasadíte šablonu z místního souboru, všechny odkazy na vnořené šablony v šabloně se načtou přímo Resource Managerem a artefakty, na které odkazují rozšíření virtuálních počítačů, načte agent virtuálního počítače spuštěný uvnitř nasazeného virtuálního počítače.

Sdílet prostřednictvím