Vývoj šablon ARM pro konzistenci cloudu

Článek
03/20/2024

Důležité

Použití této funkce Azure z PowerShellu vyžaduje, aby byl AzureRM modul nainstalovaný. Toto je starší modul, který je k dispozici pouze pro Windows PowerShell 5.1, který už nedostává nové funkce. Moduly Az a AzureRMnejsou při instalaci pro stejné verze PowerShellu kompatibilní. 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 rozvoje pro jednu lokalitu jsou opakovaně použitelné v jiném umístění. Šablona Azure Resource Manager (šablona ARM) zajišťuje konzistentní a opakovatelná nasazení napříč prostředími, včetně globálního Azure, suverénních cloudů Azure a služby Azure Stack. Pokud ale chcete opakovaně používat šablony napříč cloudy, musíte vzít v úvahu závislosti specifické pro cloud, jak je vysvětleno v tomto průvodci.

Microsoft nabízí inteligentní cloudové služby připravené pro podniky na mnoha místech, včetně následujících:

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ě skvělých funkcí, ke kterým mají přístup globální zákazníci Azure.
Azure Stack, hybridní cloudová platforma, která umožňuje doručovat služby Azure z datacentra vaší organizace. Podniky můžou službu Azure Stack nastavovat ve svých vlastních datacentrech nebo využívat služby Azure od poskytovatelů služeb, kteří službu Azure Stack provozují ve svých zařízeních (někdy označovaných jako hostované oblasti).

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

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

Výhody Azure Resource Manager vám usnadní konzistence globálního Azure, suverénních cloudů, hostovaných cloudů a cloudu ve vašem datacentru. Při nastavování nasazení a konfigurace prostředků založených na šabloně můžete opakovaně používat investice do vývoje napříč těmito cloudy.

I když globální, suverénní, hostované a hybridní cloudy poskytují konzistentní služby, nejsou všechny cloudy 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 této příručky popisuje oblasti, které je potřeba zvážit při plánování vývoje nových nebo aktualizací existujících šablon ARM pro Azure Stack. Obecně platí, že kontrolní seznam by měl obsahovat následující položky:

Ověřte, že funkce, koncové body, služby a další prostředky ve vaší šabloně jsou dostupné v cílových umístěních nasazení.
Ukládejte vnořené šablony a artefakty konfigurace na přístupných umístěních 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 k dispozici vlastnosti specifické pro prostředky.

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

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

Základní syntaxí šablony ARM je JSON. Šablony používají nadmnožinu JSON a rozšiřují syntaxi o výrazy a funkce. Procesor jazyka šablon 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 Manager, 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, na které šablona odkazuje, dostupné v cílovém cloudu.

Funkce Azure Resource Manager budou v globálním Azure vždy představeny jako první. 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 cílovému Resource Manager Azure pomocí PowerShellu.

Importujte 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 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ích počítačů. Tyto artefakty načítá rozšíření virtuálního počítače spuštěné uvnitř virtuálního počítače pro konfiguraci rozšíření virtuálního počítače během nasazování š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 je možné rozložit na malé opakovaně použitelné šablony, z nichž každá má konkrétní účel a je možné je opakovaně používat ve scénářích nasazení. Pokud chcete provést nasazení, zadejte 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 šablony vnořit. Podobně může vnořená šablona obsahovat odkazy na jiné šablony. Můžete vnořit až pět úrovní hloubky.

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 se šablona zploštěla a zahájí se další zpracování.

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

Zvažte, kam a jak ukládat propojené šablony, které používáte. Za běhu Azure Resource Manager načte (a proto vyžaduje přímý přístup) všechny propojené šablony. Běžným postupem je použití GitHubu k uložení vnořených šablon. Úložiště GitHub 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í Služby 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 těchto případech by se Resource Manager Azure nepodařilo načíst vnořené šablony.

Lepším postupem pro nasazení mezi cloudy je ukládat propojené šablony do umístění, které je přístupné pro cílový cloud. V ideálním případě se všechny artefakty nasazení uchovávají v kanálu kontinuální integrace nebo průběžného vývoje (CI/CD) a nasazují se z kanálu. Případně můžete vnořené šablony uložit do kontejneru úložiště objektů blob, ze kterého je azure Resource Manager můž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 (FQDN) koncového bodu, nakonfigurujte v šabloně umístění propojených šablon se dvěma parametry. Parametry můžou přijímat vstup uživatele v době nasazení. Šablony obvykle vytváří a sdílí více lidí, takže osvědčeným postupem je použít pro tyto parametry standardní název. Zásady vytváření názvů pomáhají zajistit, aby šablony byly lépe opakovaně použitelné napříč oblastmi, cloudy a autory.

V následujícím kódu _artifactsLocation se používá k nasměrování 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í pro zadaná _artifactsLocationžádná vstupní hodnota, použije se výchozí hodnota. Slouží _artifactsLocationSasToken jako vstup pro sasToken. Výchozí hodnotou by měl být prázdný řetězec pro scénáře, ve kterých _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 cestou relativní k artefaktu _artifactsLocationSasTokena . Následující kód ukazuje, jak zadat odkaz na vnořenou šablonu pomocí funkce šablony URI:

"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 propojené šablony načíst z jiného umístění, je možné použít vstup parametru v době nasazení k přepsání výchozí hodnoty – není potřeba žádná změna samotné šablony.

Použití _artifactsLocation místo pevného kódování 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 neměli pevně kódovat odkazy. Například rozšíření Vlastní skript a 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 skripty uloží na místní disk virtuálního počítače. Tento přístup funguje stejně jako odkazy na 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čů načítá všechny externí artefakty agent virtuálního počítače. Kromě jiného iniciátora načítání artefaktů je řešení v definici šablony stejné. Použijte _artifactsLocation parametr 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 parametrem pro vstup pro sasToken.

"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 URI místo funkce concat šablony. Když nahradíte pevně zakódované odkazy na skripty v rozšíření virtuálního počítače funkcí šablony URI, nakonfiguruje se tato funkce v šabloně pro konzistenci v 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')))]"
    ]
  }
}

Při tomto přístupu mohou být všechny artefakty nasazení, včetně konfiguračních skriptů, uloženy ve stejném umístění se samotnou šablonou. Pokud chcete změnit umístění všech odkazů, stačí zadat jinou základní adresu URL pro parametry artifactsLocation.

Faktor různých regionálních schopností

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 dostupností 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é cílové skupině 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 zavedou do dalších oblastí, zavedou se do suverénních cloudů a potenciálně se zpřístupní i zákazníkům služby Azure Stack.

S vědomím, že se oblasti a cloudy Azure můžou v dostupných službách lišit, můžete se ohledně šablon aktivně rozhodovat. 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 nasazuje a konfiguruje prostředky. Typ prostředku poskytuje poskytovatel prostředků. Například poskytovatel výpočetních prostředků (Microsoft.Compute) poskytuje několik 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í a jednotné prostředí pro vytváření obsahu u všech poskytovatelů prostředků. Poskytovatel prostředků dostupný v globálním Azure ale nemusí být dostupný v suverénním cloudu nebo oblasti 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. K existujícím typům prostředků se občas přidávají nové funkce a související vlastnosti 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 představené 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ů v Azure Portal. V nabídce Všechny služby vyhledejte Průzkumník prostředků. Rozbalením uzlu Poskytovatelé v Průzkumníku prostředků vrátíte všechny dostupné poskytovatele prostředků, jejich typy prostředků a verze rozhraní API v daném cloudu.

Pokud chcete zobrazit dostupnou verzi 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

Projděte si 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, ve které se má nasazení provést. K vývoji šablony 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 kvůli podpoře scénářů, jako je dostupnost aplikací napříč oblastmi, může být užitečné prostředky rozprostřít mezi oblasti.

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

Pokud chcete pojmout různé oblasti, přidejte do šablony umístění vstupního parametru s výchozí hodnotou. Pokud během nasazení nezadáte žádnou hodnotu, použije se výchozí 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 v hodnotě defaultValue vstupního parametru azure Resource Manager za běhu nahradí [resourceGroup().location] funkci šablony názvem umístění skupiny prostředků, do které je šablona nasazená.

"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í. Kromě toho se umístění konkrétního prostředku v šabloně může lišit od umístění skupiny prostředků. V takovém případě ho můžete nakonfigurovat pomocí dalších vstupních parametrů pro daný konkrétní prostředek, zatímco ostatní prostředky ve stejné šabloně stále používají počáteční vstupní parametr umístění.

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

Sledování všech dostupných poskytovatelů prostředků a souvisejících verzí rozhraní API, které se nacházejí ve službě Azure Stack, může být velmi náročné. 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. Společ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 do šablon zavedl koncept profilů rozhraní API. Bez profilů rozhraní API je každý prostředek v šabloně nakonfigurovaný pomocí elementu apiVersion , který popisuje verzi rozhraní API pro daný konkrétní 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 na typ prostředku, který je společný pro Azure a Azure Stack. Místo určení verze rozhraní API pro každý prostředek v šabloně zadáte pouze verzi profilu rozhraní API v novém kořenovém elementu s názvem apiProfile a vynecháte apiVersion element 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, aby byly verze rozhraní API dostupné napříč umístěními, takže není nutné ručně ověřovat verze apiVersion, které jsou k dispozici v konkrétní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í aktuální na základě zásad podpory. Pokud je systém zastaralý více než šest měsíců, považuje se za nevyhovující a prostředí se musí aktualizovat.

Profil rozhraní API není povinným prvkem v šabloně. I když přidáte prvek, použije se pouze pro prostředky, pro které není zadáno žá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 obsahovat 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í své vlastní jedinečné obory názvů koncových bodů. Ve většině případů vyžaduje prostředek jako vstup v šabloně pouze předponu. Během běhu k ní Azure Resource Manager připojí hodnotu koncového bodu. Některé hodnoty koncových bodů je potřeba explicitně zadat v šabloně.

Poznámka

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

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ě (objekt blob, fronta, tabulka a soubor)
Připojovací řetězce pro databáze a Azure Cache for Redis

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

Účty úložiště (objekt 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
Cloud Services

Obecně platí, že se v šabloně vyhněte pevně kódovaným koncovým bodům. Osvědčeným postupem je dynamické načtení koncových bodů 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, který se vytvoří 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 má v závislosti na cloudu různé plně kvalifikované názvy domén:

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

Následující funkce referenční š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')]"

Pokud nahradíte pevně zakódovanou hodnotu 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í, aniž byste museli provádět změny odkazu na koncový bod.

Odkazovat 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 v rámci stejného tenanta 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, například SQL Server, jak ukazuje následující kód:

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

Pak můžete použít resourceId funkci uvnitř reference funkce šablony k načtení vlastností databáze. Vrácený 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 zakódování oboru názvů koncového bodu, můžete odkazovat na vlastnost návratového objektu přímo v připojovacím řetězci, 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;')]"

Zvažte vlastnosti prostředku.

Konkrétní prostředky v prostředích služby Azure Stack mají jedinečné vlastnosti, které musíte v šabloně zvážit.

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

Azure nabízí bohatý výběr imagí virtuálních počítačů. Tyto image vytváří a připravuje k nasazení Microsoft a partneři. Image tvoří základ virtuálních počítačů na platformě. Šablona konzistentní vzhledem k cloudu by však měla odkazovat pouze na dostupné parametry – zejména vydavatele, nabídku a skladovou položku imagí virtuálních počítačů dostupných 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 pomocí parametru -Location zadat požadované umístění. 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 byste tyto image virtuálních počítačů zpřístupnili službě Azure Stack, spotřebovalo by se veškeré dostupné úložiště. Azure Stack umožňuje vybrat image, které chcete přidat do prostředí, abyste pojali i nejmenší jednotku š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 cloudovou konzistenci, musíte zajistit, aby požadovaná velikost virtuálního počítače byla dostupná ve všech cílových prostředích. Velikosti virtuálních počítačů představují seskupení charakteristik a možností výkonu. Některé velikosti virtuálních počítačů závisí na hardwaru, na kterém virtuální počítač běží. Pokud například chcete nasadit virtuální počítač optimalizovaný pro GPU, musí hardware, na kterém běží hypervisor, obsahovat hardwarové GPU.

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

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 Dostupné produkty v jednotlivých oblastech.

Kontrola použití 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 tyto akce implicitně provádět při nasazování virtuálního počítače pomocí spravovaných disků. 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 ze služby Storage ú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 tomu tak není, můžete vyvíjet šablony konzistentní s cloudem pro Azure Stack explicitním zadáním virtuálních pevných disků pomocí elementu vhd 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"
  }
}

Naopak pokud chcete v šabloně zadat konfiguraci spravovaného disku, odeberte vhd element z konfigurace disku.

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

Stejné změny platí i pro datové disky.

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

Dalším aspektem konzistence cloudu je použití rozšíření virtuálních počítačů ke konfiguraci prostředků uvnitř virtuálního počítače. 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 vytvářet závislosti a podmínky v rámci šablony.

Pokud například chcete nakonfigurovat virtuální počítač se systémem Microsoft SQL Server, 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ý pro vytvoření databáze na virtuálním počítači, na kterém běží SQL Server. 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í SQL Server virtuálního počítače. Tento přístup zajistí, že virtuální počítač, na kterém běží SQL Server, je nakonfigurovaný a dostupný, když má aplikační server pokyn k vytvoření databáze.

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

Kontrola dostupnosti rozšíření virtuálních počítačů

Existuje mnoho typů rozšíření virtuálních počítačů. Při vývoji šablony pro cloudovou konzistenci 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 ), myLocationspusťte následující příkaz Azure CLI:

az vm extension image list --location myLocation

Můžete také spustit rutinu Azure PowerShell Get-AzureRmVmImagePublisher 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 vlastními Resource Manager prostředky, mají vlastní verze rozhraní API. Jak ukazuje následující kód, typ rozšíření virtuálního počítače je vnořeným prostředkem 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 ve všech umístěních, na která chcete pomocí šablony cílit. Závislost umístění funguje stejně jako dostupnost verze rozhraní API poskytovatele prostředků, která je popsána výše 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 na obrázku:

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 cloudovou konzistenci, 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 na obrázku:

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

Každé konkrétní rozšíření má 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 prvku rozšíření virtuálních počítačů vaší šablony je dostupná v umístěních, kam 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 obtížné sledovat všechna související nastavení, možnosti a omezení. Běžným přístupem je vyvíjet a testovat šablony v jednom cloudu před cílem jiných umístění. Čím dříve se ale testy v procesu vytváření provádějí, tím méně bude muset váš vývojový tým řešit potíže a přepisovat kód. Řešení potíží s nasazením, která selžou kvůli závislostem umístění, může být časově náročné. Proto doporučujeme automatizované testování co nejdříve v cyklu vytváření obsahu. Nakonec budete potřebovat méně času na vývoj a méně prostředků a vaše artefakty konzistentní vzhledem k cloudu budou ještě cennější.

Následující obrázek ukazuje typický příklad procesu vývoje pro tým používající integrované vývojové prostředí (IDE). V různých fázích časové osy se provádějí různé typy testů. Tady dva vývojáři pracují na stejném řešení, ale tento scénář platí stejně pro jednoho vývojáře nebo velký tým. Každý vývojář obvykle vytvoří místní kopii centrálního úložiště, aby každý z nich mohl pracovat s místní kopií, aniž by to mělo vliv na ostatní, kteří mohou pracovat se stejnými soubory.

Diagram znázorňující paralelní testy jednotek a integrační testy v místních prostředích IME, které se slučují 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. Například Visual Studio Code a Visual Studio 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 analýzu statického 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 testy integrace měly varovat pouze při zjištění problému a pokračovat v testech. Tímto způsobem můžete identifikovat problémy, které se mají vyřešit, a určit prioritu pořadí změn, označované také jako testovací nasazení (TDD).
Mějte na paměti, že některé testy je možné provést bez připojení k Azure Resource Manager. Jiné, například testování nasazení šablon, vyžadují Resource Manager k provádění určitých akcí, 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ě načtou přímo Resource Manager a artefakty, na které odkazují rozšíření virtuálních počítačů, načte agent virtuálního počítače spuštěný v nasazeném virtuálním počítači.