Vývoj šablon ARM pro cloudovou konzistenci

Důležité

Použití této funkce Azure z PowerShellu vyžaduje, aby byl AzureRM nainstalovaný modul. Toto je starší modul, který je dostupný jenom pro Windows PowerShell 5,1, který už nepřijímá nové funkce. AzModuly a AzureRM nejsou kompatibilní , pokud jsou nainstalované pro stejné verze prostředí PowerShell. Pokud potřebujete obě verze:

  1. Odinstalujte modul AZ Module z relace powershellu 5,1.
  2. Nainstalujte modul AzureRM z relace powershellu 5,1.
  3. Stáhněte a nainstalujte PowerShell Core 6. x nebo novější.
  4. Nainstalujte modul AZ Module do relace PowerShellu Core.

Klíčovou výhodou Azure je konzistence. Investice do vývoje pro jedno umístění se znovu používají v jiné. Šablona Azure Resource Manager (šablona ARM) umožňuje nasazení konzistentně a opakovaně v různých prostředích, včetně globálního cloudu Azure, Azure svrchovaného cloudu a Azure Stack. Aby bylo možné opakovaně používat šablony napříč cloudy, je třeba vzít v úvahu, že v této příručce jsou vysvětleny specifické závislosti cloudu.

Microsoft nabízí inteligentní cloudové služby připravené pro podnikové prostředí v mnoha umístěních, včetně těchto:

  • Globální platforma Azure podporovaná rostoucí sítí datových center spravovaných Microsoftem v oblastech po celém světě.
  • Izolované svrchované cloudy, jako je Azure Německo, Azure Government a Azure Čína 21Vianet. Svrchované cloudy poskytují konzistentní platformu s většinou stejných skvělých funkcí, ke kterým mají globální zákazníci Azure přístup.
  • Azure Stack, hybridní cloudová platforma, která vám umožní poskytovat služby Azure z datového centra vaší organizace. Podniky můžou nastavit Azure Stack ve svých vlastních datacentrech nebo využívat služby Azure od poskytovatelů služeb a spouštět je Azure Stack ve svých zařízeních (někdy označované jako hostované oblasti).

V jádru všech těchto cloudů Azure Resource Manager poskytuje rozhraní API, které umožňuje komunikaci s platformou Azure širokou škálu uživatelských rozhraní. Toto rozhraní API poskytuje výkonné možnosti infrastruktury jako kódu. Jakýkoli typ prostředku, který je dostupný na cloudové platformě Azure, se dá nasadit a nakonfigurovat s Azure Resource Manager. S jedinou šablonou můžete nasadit a nakonfigurovat kompletní aplikaci do provozního koncového stavu.

Prostředí Azure

Výhodou Azure Resource Manager je konzistence globálních Azure, cloudů z svrchovaného prostředí, hostovaných cloudů a cloudového datového centra. Při nastavování nasazení a konfigurace prostředků založených na šablonách můžete znovu použít své investice do vývoje napříč těmito cloudy.

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

Zbytek této příručky popisuje oblasti, které je potřeba vzít v úvahu při plánování vývoje nových nebo aktualizovaných existujících šablon ARM pro Azure Stack. Kontrolní seznam by měl obecně zahrnovat následující položky:

  • Ověřte, zda jsou funkce, koncové body, služby a další prostředky v šabloně k dispozici v cílových umístěních nasazení.
  • Vnořené šablony a konfigurační artefakty ukládejte v dostupných umístěních a zajistěte tak přístup mezi cloudy.
  • Používejte dynamické odkazy namísto odkazů a prvků pevného kódování.
  • Zajistěte, aby parametry šablony používané v cílových cloudech pracovaly.
  • Ověřte, zda jsou pro cílové cloudy k dispozici vlastnosti specifické pro daný prostředek.

Úvod do šablon ARM najdete v tématu template Deployment.

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 pomocí výrazů a funkcí. Procesor šablon jazyka se často aktualizuje pro podporu dalších funkcí šablon. Podrobné vysvětlení dostupných funkcí šablon najdete v tématu funkce šablon ARM.

Nové funkce šablon, které se zavádějí do Azure Resource Manager nejsou hned dostupné v cloudech svrchovan nebo Azure Stack. Aby bylo možné šablonu nasadit úspěšně, musí být všechny funkce odkazované v této šabloně k dispozici v cílovém cloudu.

Funkce Azure Resource Manager se vždycky do globálního Azure nasadí dřív. Pomocí následujícího skriptu prostředí PowerShell můžete ověřit, zda nově zavedené funkce šablony jsou také k dispozici v Azure Stack:

  1. vytvořte klon úložiště GitHub: https://github.com/marcvaneijk/arm-template-functions .

  2. Jakmile budete mít místní klon úložiště, připojte se k Azure Resource Manager cíle pomocí PowerShellu.

  3. 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 obsahovat prostředek nasazení, který odkazuje na jinou šablonu. Propojené šablony (označované také jako vnořená šablona) jsou načteny Správce prostředků za běhu. Šablona může také obsahovat odkazy na artefakty pro rozšíření virtuálních počítačů (VM). Tyto artefakty jsou načteny rozšířením virtuálního počítače spuštěným uvnitř virtuálního počítače za účelem konfigurace rozšíření virtuálního počítače během nasazování šablony.

Následující části popisují požadavky na konzistenci 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 do malých, opakovaně použitelných šablon, z nichž každá má konkrétní účel a dá se použít v rámci scénářů nasazení. Chcete-li spustit nasazení, zadejte jednu šablonu známou jako hlavní nebo hlavní šablonu. Určuje prostředky pro nasazení, 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řovat šablony. Podobně vnořená šablona může obsahovat odkazy na jiné šablony. Můžete vnořit až pět úrovní do 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 vyhodnocuje 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 sloučí a iniciuje se další zpracování.

Zpřístupnění propojených šablon v cloudech

Zvažte, kde a jak uložit všechny propojené šablony, které používáte. Za běhu Azure Resource Manager načíst, a proto vyžaduje přímý přístup k – všem propojeným šablonám. běžný postup je použít GitHub 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 cloudy v svrchovaném prostředí, může se Azure Stack prostředí nacházet v podnikové síti nebo na odpojeném vzdáleném umístění bez jakéhokoli odchozího internetového přístupu. V těchto případech by Azure Resource Manager nepodařilo načíst vnořené šablony.

Lepším postupem při nasazení mezi několika cloudy je uložení vašich propojených šablon 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 v a nasazeny z kanálu průběžné integrace nebo průběžného vývoje (CI/CD). Případně můžete vnořené šablony Uložit do kontejneru úložiště objektů blob, ze kterého Azure Resource Manager je mohou načíst.

Vzhledem k tomu, že úložiště objektů BLOB v jednotlivých cloudech používá jiný koncový bod plně kvalifikovaný název domény (FQDN), nakonfigurujte šablonu s umístěním propojených šablon se dvěma parametry. Parametry můžou přijímat vstupy uživatele v době nasazení. Šablony jsou obvykle vytvořené a sdílené více lidmi, proto doporučujeme pro tyto parametry použít standardní název. Zásady pojmenování usnadňují použití šablon v různých oblastech, cloudech a tvůrcích.

V následujícím kódu _artifactsLocation se používá k odkazování na jedno umístění, které obsahuje všechny artefakty související s nasazením. Všimněte si, že je zadána výchozí hodnota. Pokud v době nasazení není zadána žádná vstupní hodnota pro _artifactsLocation , je použita výchozí hodnota. _artifactsLocationSasTokenSlouží jako vstup pro sasToken . výchozí hodnota by měla být prázdný řetězec pro scénáře, ve kterých _artifactsLocation není zabezpečený – například úložiště veřejné 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 rámci šablony jsou odkazy generovány kombinací základního identifikátoru URI (z _artifactsLocation parametru) s cestou relativního artefaktu a _artifactsLocationSasToken . Následující kód ukazuje, jak zadat odkaz na vnořenou šablonu pomocí funkce šablony identifikátoru 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 _artifactsLocation je použita výchozí hodnota parametru. Pokud je potřeba načíst propojené šablony z jiného umístění, můžete zadat vstup parametru v době nasazení, aby se potlačila výchozí hodnota – nemusíte dělat žádné změny samotné šablony.

Kromě použití pro vnořené šablony se adresa URL v _artifactsLocation parametru používá jako základ pro všechny související artefakty šablony nasazení. Některá rozšíření virtuálních počítačů zahrnují odkaz na skript uložený mimo šablonu. Pro tato rozšíření byste neměli nekódujte pevně odkazy. například vlastní skript a rozšíření PowerShell DSC se můžou připojit k externímu skriptu na GitHub, 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"
    ]
  }
}

Zakódujeme odkazy na skript potenciálně brání tomu, aby se šablona mohla úspěšně nasazovat 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 v rámci virtuálního počítače stahování všech skriptů propojených v rozšíření virtuálního počítače a potom tyto skripty uloží na místní disk virtuálního počítače. Tento přístup funguje podobně jako vnořené odkazy na šablony popsané dříve v části použití vnořených šablon napříč oblastmi.

Správce prostředků načte vnořené šablony za běhu. Pro rozšíření virtuálních počítačů se k načtení všech externích artefaktů provede agent virtuálního počítače. Kromě jiného iniciátoru načtení artefaktu 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 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": ""
  }
}

Chcete-li vytvořit absolutní identifikátor URI artefaktu, upřednostňovanou metodou je použít funkci šablony identifikátoru URI namísto funkce Concat Template. Pokud nahradíte pevně zakódované odkazy na skripty v rozšíření virtuálního počítače pomocí funkce šablony identifikátoru URI, je tato funkce v šabloně nakonfigurovaná na 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')))]"
    ]
  }
}

S tímto přístupem můžete všechny artefakty nasazení, včetně konfiguračních skriptů, ukládat ve stejném umístění se šablonou samotné. Chcete-li změnit umístění všech odkazů, stačí zadat jinou základní adresu URL pro parametry artifactsLocation.

Faktor v závislosti na rozdílný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 do Azure se oblasti mohou lišit v dostupnosti služeb nebo aktualizací. Po důkladném interním testování jsou nové služby nebo aktualizace stávajících služeb obvykle zavedeny malé cílové skupině zákazníků, kteří se účastní programu ověřování. Po úspěšném ověření zákazníka jsou služby nebo aktualizace dostupné v rámci podmnožiny oblastí Azure, následně zavedené do dalších oblastí, zavedené do suverénních cloudů a potenciálně dostupné i pro Azure Stack zákazníky.

Když víte, že se oblasti a cloudy Azure mohou v dostupných službách lišit, můžete se o šablonách 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 nasadí a nakonfiguruje 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ů, například virtualMachines a availabilitySets. Každý poskytovatel prostředků poskytuje rozhraní API pro Azure Resource Manager definované běžným kontraktem, které umožňuje konzistentní jednotné prostředí pro vytváření obsahu 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 Azure Stack oblasti.

Poskytovatelé prostředků

Pokud chcete ověřit poskytovatele prostředků, kteří jsou k dispozici v daném cloudu, spusťte v rozhraní příkazového řádku 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 občas přidávají k existujícím typům prostředků prostřednictvím nové verze rozhraní API. Prostředek v šabloně má vlastní vlastnost verze rozhraní API – apiVersion . Tato verze zajišťuje, aby stávající konfigurace prostředků v šabloně nebyla ovlivněna změnami na platformě.

Nové verze rozhraní API zavedené do existujících typů prostředků v globálním Azure nemusí být okamžitě dostupné ve všech oblastech, suverénních cloudech nebo 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ů. 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 tomto 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

Odkazování na umístění prostředků pomocí parametru

Šablona se vždy nasazovat 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í nasazovat. K vývoji šablony pro konzistenci cloudu potřebujete dynamický způsob odkazování na umístění prostředků, protože každý Azure Stack může obsahovat jedinečné názvy umístění. Prostředky se obvykle nasadí ve stejné oblasti jako skupina prostředků, ale pro podporu scénářů, jako je dostupnost aplikací mezi oblastmi, může být užitečné prostředky rozložit napříč oblastmi.

I když byste při zadávání vlastností prostředku v šabloně mohli pevně zakódovat názvy oblastí, nezaručuje tento přístup, že se šablona může nasadit do jiných prostředí 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. Pokud během nasazování není zadaná žádná hodnota, použije se výchozí hodnota.

Funkce šablony [resourceGroup()] 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 defaultValue vstupního parametru nahradí Azure Resource Manager za běhu funkci šablony názvem umístění skupiny prostředků, do které je šablona [resourceGroup().location] 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 věděli názvy oblastí. Umístění konkrétního prostředku v šabloně se navíc 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 tento 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é jsou k dispozici v Azure Stack, může být velmi Azure Stack. Například v době psaní tohoto článku je nejnovější verzí rozhraní API pro Microsoft.Compute/availabilitySets v Azure , zatímco dostupná verze rozhraní API společná pro 2018-04-01 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 , zatímco nejnovější verze rozhraní 2016-01-01 API v Azure je 2018-02-01 .

Z tohoto důvodu Resource Manager představili koncept profilů rozhraní API do šablon. Bez profilů rozhraní API je každý prostředek v šabloně nakonfigurovaný s elementem, který popisuje verzi apiVersion rozhraní API pro tento 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 pro každý typ prostředku společný pro Azure a Azure Stack. Místo určení verze rozhraní API pro každý prostředek v šabloně zadáte v novém kořenovém elementu s názvem pouze verzi profilu rozhraní API a vynecháte element pro apiProfile apiVersion 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 verze rozhraní API jsou dostupné napříč umístěními, takže není nutné ručně ověřovat apiVersions, 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, jsou přítomné v prostředí Azure Stack, musí operátory Azure Stack udržovat řešení aktuální v závislosti na zásadách podpory. Pokud je systém starší než šest měsíců, považuje se za systém, který není v souladu s předpisy, a prostředí se musí aktualizovat.

Profil rozhraní API není povinným prvkem v šabloně. I když přidáte element , bude použit pouze pro prostředky, pro které není apiVersion zadána hodnota . 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 mohou mít odkazy na jiné služby na platformě. Například veřejná IP adresa může mít přiřazený veřejný název DNS. Veřejný cloud, suverénní cloudy a Azure Stack řešení mají své vlastní samostatné 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 Azure Resource Manager připojí hodnotu koncového bodu. Některé hodnoty koncových bodů je potřeba explicitně zadat v šabloně.

Poznámka

Při vývoji šablon pro konzistenci cloudu nekódováte 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:

  • Storage účty (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:

  • Storage účty (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 v šabloně nepoužívejte pevně zakódované koncové body. Osvědčeným postupem je použít funkci referenční šablony k dynamickému načtení koncových bodů. Nejčastěji pevně kó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ězovacím názvem účtu úložiště s oborem názvů koncového bodu. Účet úložiště objektů blob s názvem mystorageaccount1 má za výsledek různé FQDN v závislosti na cloudu:

  • 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 China 21Vianet cloudu.

Následující referenční funkce šablony načte obor názvů koncového bodu z 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 účtu úložiště funkcí šablony můžete stejnou šablonu použít k úspěšnému nasazení do různých prostředí bez nutnosti provádět jakékoli změny v referenčních reference bodech.

Odkazování 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 pro samotný prostředek. Funkce šablony načte jedinečné ID prostředku, například resourceId SQL Server, jak ukazuje následující kód:

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

Potom můžete použít resourceId funkci uvnitř funkce šablony k načtení reference vlastností databáze. Návratový objekt obsahuje fullyQualifiedDomainName vlastnost, která obsahuje úplnou hodnotu koncového bodu. Tato hodnota se načítá 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 zakodová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 níže:

"[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ředků

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

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

Azure nabízí bohatý výběr imagí virtuálních počítače. Tyto image jsou vytvořeny a připraveny k nasazení microsoftem a partnery. Image tvoří základ pro virtuální počítače na platformě. Šablona konzistentní vzhledem ke cloudu by ale měla odkazovat jenom na dostupné parametry – zejména na vydavatele, nabídku a SKU imagí virtuálních počítače dostupných pro globální Azure, suverénní cloudy Azure nebo Azure Stack řešení.

Pokud chcete načíst seznam dostupných imagí virtuálních počítače 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 zadat umístění, které -Location chcete. Příklad:

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

Tento příkaz několik minut trvá, než vrátí všechny dostupné image v Západní Evropa oblasti globálního cloudu Azure.

Pokud byste tyto image virtuálních Azure Stack k dispozici, spotřebuje se veškeré dostupné úložiště. Aby bylo možné přizpůsobit i nejmenší jednotku škálování, Azure Stack umožňuje vybrat obrázky, které chcete přidat do prostředí.

Následující ukázka kódu ukazuje konzistentní přístup k odkazování na parametry vydavatele, nabídky a SKU 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čů

Při vývoji šablony pro konzistenci cloudu je potřeba zajistit, aby ve všech cílových prostředích byla dostupná velikosti požadovaného virtuálního počítače. 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ý virtuální počítač běží. Pokud například chcete nasadit virtuální počítač optimalizovaný pro GPU, musí hardware, na který běží hypervisor, mít hardwarové GPU.

Když Microsoft zavádí novou velikost virtuálního počítače s určitými hardwarovými závislostmi, je velikost virtuálního počítače obvykle nejprve dostupná v malé podmnožině oblastí v cloudu Azure. Později bude dostupná pro další oblasti a cloudy. Pokud chcete zajistit, aby velikost virtuálního počítače existovala v každém cloudu, do který nasazujete, můžete dostupné velikosti načíst pomocí následujícího příkazu Azure CLI:

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

Pro Azure PowerShell použijte:

Get-AzureRmVMSize -Location "West Europe"

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

Kontrola použití azure Spravované disky v Azure Stack

Spravované disky spravují ú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 spravované disky použít k implicitnímu provádění těchto akcí při nasazování virtuálního počítače. Spravované disky vylepšují dostupnost tím, že umístí všechny disky 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í disky převést ze standardu na Premium úložiště s výrazně menšími výpadky.

Přestože jsou spravované disky v plánu Azure Stack, v současné době se nepodporují. Dokud ne, můžete vyvíjet šablony konzistentní s cloudem pro Azure Stack explicitním zadáním virtuálních prostředků pomocí elementu v šabloně pro prostředek virtuálního počítače, jak je vhd znázorněno níže:

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

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

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

Stejné změny také aplikují datové disky.

Ověřte, že jsou rozšíření virtuálních 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. Ne všechna rozšíření virtuálních Azure Stack. Š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č se systémem Microsoft SQL Server, rozšíření virtuálního počítače můž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 se spuštěnou 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í virtuálního SQL Server virtuálního počítače. Tento přístup zajišťuje, že je virtuální počítač SQL Server 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 požadovanou pro závislosti.

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

Existuje mnoho typů rozšíření virtuálního počítače. 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ího počítače, 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 Azure PowerShell Get-AzureRmVmImagePublisher a pomocí příkazu určit umístění image -Location 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 Resource Manager vlastní 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ý 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 ve všech umístěních, na která chcete pomocí šablony cílit. Závislost na umístění funguje stejně 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 verze rozhraní API jsou dostupné ve všech umístěních, do které 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í sady virtuálních počítačů, jak je znázorněno níže:

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é verzi. Tato verze se zobrazuje typeHandlerVersion ve vlastnosti rozšíření virtuálního počítače. Ujistěte se, že verze zadaná v elementu rozšíření virtuálního počítače šablony je dostupná v umístěních, kam plánujete typeHandlerVersion š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 pro rozšíření virtuálního počítače PowerShell DSC (Desired State Configuration) z umístění 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 commend Get-AzureRmVMExtensionImageType.

Tipy pro testování a automatizaci

Při vytváření šablony je výzvou sledovat všechna související nastavení, možnosti a omezení. Běžným přístupem je vývoj a testování šablon pro jeden cloud před cílem jiných umístění. Čím dříve se ale testy provádějí v procesu vytváření, tím méně bude muset váš vývojový tým vyřešit potíže a přepis kódu. Řešení potíží s nasazeními, 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í. Nakonec budete potřebovat méně času na vývoj a méně prostředků a artefakty konzistentní s cloudem budou ještě cennější.

Následující obrázek ukazuje typický příklad procesu vývoje pro tým, který používá integrované vývojové 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ý tým. 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ří mohou pracovat na stejných souborech.

Diagram znázorňuje dvě sady testů jednotek a integrační testy paralelně na místních ID E, které se slučují v toku vývoje C I/C D do testů jednotek, pak integrační testy, pak testovací nasazení a pak nasazení.

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

  • Využijte testovací nástroje. Například funkce Visual Studio Code a Visual Studio 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í, 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 integrační testy měly upozornit pouze na nalezený problém a pokračovat v testech. Tímto způsobem můžete identifikovat problémy, které se mají řešit, a určit prioritu pořadí změn, které se také označují jako testovací nasazení (TDD).
  • Uvědomte si, že některé testy je možné provádět bez připojení k Azure Resource Manager. Jiné, jako je například testování nasazení šablony, Resource Manager k provádění určitých akcí, které nelze provést offline.
  • Testování šablony nasazení s ověřovacím rozhraním API se nerovná skutečnému nasazení. I když nasadíte šablonu z místního souboru, agent virtuálního počítače spuštěný uvnitř nasazeného virtuálního počítače načte všechny odkazy na vnořené šablony v šabloně přímo Resource Manager artefakty, na které odkazují rozšíření virtuálního počítače.

Další kroky