ARM-sjablonen ontwikkelen voor cloudconsistentie

  • Artikel

Belangrijk

Als u deze Azure-functie van PowerShell wilt gebruiken, moet de AzureRM-module zijn geïnstalleerd. Dit is een oudere module die alleen beschikbaar is voor Windows PowerShell 5.1, dat geen nieuwe functies meer ontvangt. De modules Az en AzureRM zijn niet compatibel als ze voor dezelfde versies van PowerShell worden geïnstalleerd. Als u beide versies nodig hebt:

  1. De Az-module verwijderen vanuit een PowerShell 5.1-sessie.
  2. De AzureRM-module installeren vanuit een PowerShell 5.1-sessie.
  3. PowerShell Core 6.x of nieuwer downloaden en installeren.
  4. De Az-module installeren in een PowerShell Core-sessie.

Een belangrijk voordeel van Azure is consistentie. Ontwikkelingsinvesteringen voor de ene locatie kunnen op een andere locatie opnieuw worden gebruikt. Met een Azure Resource Manager-sjabloon (ARM-sjabloon) kunt u uw implementaties consistent en herhaalbaar maken in omgevingen, waaronder de wereldwijde Azure, onafhankelijke Azure-clouds en Azure Stack. Als u sjablonen in clouds wilt hergebruiken, moet u echter rekening houden met cloudspecifieke afhankelijkheden, zoals in deze handleiding wordt uitgelegd.

Microsoft biedt intelligente, bedrijfsklare cloudservices op veel locaties, waaronder:

  • Het wereldwijde Azure-platform dat wordt ondersteund door een groeiend netwerk van door Microsoft beheerde datacenters in regio's over de hele wereld.
  • Geïsoleerde onafhankelijke clouds zoals Azure Duitsland, Azure Government en Microsoft Azure beheerd door 21Vianet. Onafhankelijke clouds bieden een consistent platform met de meeste van dezelfde geweldige functies waartoe wereldwijde Azure-klanten toegang hebben.
  • Azure Stack, een hybride cloudplatform waarmee u Azure-services kunt leveren vanuit het datacenter van uw organisatie. Ondernemingen kunnen Azure Stack instellen in hun eigen datacenters of Azure-services van serviceproviders gebruiken en Azure Stack uitvoeren in hun faciliteiten (ook wel gehoste regio's genoemd).

Azure Resource Manager vormt de kern van al deze clouds en biedt een API waarmee een breed scala aan gebruikersinterfaces kan communiceren met het Azure-platform. Deze API biedt u krachtige infrastructure-as-code-mogelijkheden. Elk type resource dat beschikbaar is op het Azure-cloudplatform kan worden geïmplementeerd en geconfigureerd met Azure Resource Manager. Met één sjabloon kunt u uw volledige toepassing implementeren en configureren naar een operationele eindstatus.

Diagram van verschillende Azure-omgevingen, waaronder wereldwijde Azure, onafhankelijke clouds en Azure Stack.

De consistentie van globale Azure, de onafhankelijke clouds, gehoste clouds en een cloud in uw datacenter helpt u te profiteren van Azure Resource Manager. U kunt uw ontwikkelingsinvesteringen in deze clouds opnieuw gebruiken wanneer u de implementatie en configuratie van resources op basis van sjablonen instelt.

Hoewel de wereldwijde, onafhankelijke, gehoste en hybride clouds consistente services bieden, zijn niet alle clouds identiek. Als gevolg hiervan kunt u een sjabloon maken met afhankelijkheden van functies die alleen beschikbaar zijn in een specifieke cloud.

In de rest van deze handleiding worden de gebieden beschreven die u moet overwegen bij het plannen van het ontwikkelen van nieuwe of het bijwerken van bestaande ARM-sjablonen voor Azure Stack. In het algemeen moet uw controlelijst de volgende items bevatten:

  • Controleer of de functies, eindpunten, services en andere resources in uw sjabloon beschikbaar zijn op de doelimplementatielocaties.
  • Geneste sjablonen en configuratieartefacten opslaan op toegankelijke locaties, zodat toegang tot clouds wordt gegarandeerd.
  • Gebruik dynamische verwijzingen in plaats van koppelingen en elementen vast te schrijven.
  • Zorg ervoor dat de sjabloonparameters die u gebruikt, werken in de doelclouds.
  • Controleer of resourcespecifieke eigenschappen beschikbaar zijn in de doelclouds.

Zie Sjabloonimplementatie voor een inleiding tot ARM-sjablonen.

Zorg ervoor dat sjabloonfuncties werken

De basissyntaxis van een ARM-sjabloon is JSON. Sjablonen maken gebruik van een superset van JSON, waardoor de syntaxis wordt uitgebreid met expressies en functies. De sjabloontaalprocessor wordt regelmatig bijgewerkt om aanvullende sjabloonfuncties te ondersteunen. Zie ARM-sjabloonfuncties voor een gedetailleerde uitleg van de beschikbare sjabloonfuncties.

Nieuwe sjabloonfuncties die worden geïntroduceerd in Azure Resource Manager zijn niet onmiddellijk beschikbaar in de onafhankelijke clouds of Azure Stack. Als u een sjabloon wilt implementeren, moeten alle functies waarnaar in de sjabloon wordt verwezen, beschikbaar zijn in de doelcloud.

De mogelijkheden van Azure Resource Manager worden altijd eerst geïntroduceerd in het wereldwijde Azure. U kunt het volgende PowerShell-script gebruiken om te controleren of nieuw geïntroduceerde sjabloonfuncties ook beschikbaar zijn in Azure Stack:

  1. Maak een kloon van de GitHub-opslagplaats: https://github.com/marcvaneijk/arm-template-functions.

  2. Zodra u een lokale kloon van de opslagplaats hebt, maakt u verbinding met de Azure Resource Manager van de bestemming met PowerShell.

  3. Importeer de psm1-module en voer de cmdlet Test-AzureRmTemplateFunctions uit:

    # Import the module
Import-module <path to local clone>\AzTemplateFunctions.psm1

# Execute the Test-AzureRmTemplateFunctions cmdlet
Test-AzureRmTemplateFunctions -path <path to local clone>

Met het script worden meerdere, geminimaliseerde sjablonen geïmplementeerd, die elk alleen unieke sjabloonfuncties bevatten. De uitvoer van het script rapporteert de ondersteunde en niet-beschikbare sjabloonfuncties.

Werken met gekoppelde artefacten

Een sjabloon kan verwijzingen naar gekoppelde artefacten bevatten en een implementatieresource bevatten die is gekoppeld aan een andere sjabloon. De gekoppelde sjablonen (ook wel geneste sjabloon genoemd) worden tijdens runtime opgehaald door Resource Manager. Een sjabloon kan ook verwijzingen bevatten naar artefacten voor extensies van virtuele machines (VM's). Deze artefacten worden opgehaald door de VM-extensie die in de VM wordt uitgevoerd voor de configuratie van de VM-extensie tijdens de implementatie van de sjabloon.

In de volgende secties worden overwegingen beschreven voor cloudconsistentie bij het ontwikkelen van sjablonen die artefacten bevatten die buiten de hoofdimplementatiesjabloon vallen.

Geneste sjablonen gebruiken in verschillende regio's

Sjablonen kunnen worden opgesplitst in kleine, herbruikbare sjablonen, die elk een specifiek doel hebben en opnieuw kunnen worden gebruikt in implementatiescenario's. Als u een implementatie wilt uitvoeren, geeft u één sjabloon op die de hoofd- of hoofdsjabloon wordt genoemd. Hiermee worden de resources opgegeven die moeten worden geïmplementeerd, zoals virtuele netwerken, VM's en web-apps. De hoofdsjabloon kan ook een koppeling naar een andere sjabloon bevatten, wat betekent dat u sjablonen kunt nesten. Op dezelfde manier kan een geneste sjabloon koppelingen naar andere sjablonen bevatten. U kunt maximaal vijf niveaus diep nesten.

De volgende code laat zien hoe de parameter templateLink verwijst naar een geneste sjabloon:

"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 evalueert de hoofdsjabloon tijdens runtime en haalt elke geneste sjabloon op en evalueert deze. Nadat alle geneste sjablonen zijn opgehaald, wordt de sjabloon afgevlakt en wordt verdere verwerking gestart.

Gekoppelde sjablonen toegankelijk maken in clouds

Overweeg waar en hoe u gekoppelde sjablonen opslaat die u gebruikt. Tijdens runtime haalt Azure Resource Manager alle gekoppelde sjablonen op en vereist deze daarom directe toegang tot. Het is gebruikelijk om GitHub te gebruiken om de geneste sjablonen op te slaan. Een GitHub-opslagplaats kan bestanden bevatten die openbaar toegankelijk zijn via een URL. Hoewel deze techniek goed werkt voor de openbare cloud en de onafhankelijke clouds, kan een Azure Stack-omgeving zich op een bedrijfsnetwerk bevinden of op een niet-verbonden externe locatie, zonder uitgaande internettoegang. In die gevallen kan Azure Resource Manager de geneste sjablonen niet ophalen.

Een betere procedure voor cloudimplementaties is om uw gekoppelde sjablonen op te slaan op een locatie die toegankelijk is voor de doelcloud. Idealiter worden alle implementatieartefacten onderhouden in en geïmplementeerd vanuit een CI/CD-pijplijn (continue integratie/continue ontwikkeling). U kunt ook geneste sjablonen opslaan in een blob-opslagcontainer, waaruit Azure Resource Manager ze kunt ophalen.

Omdat de blob-opslag in elke cloud een andere FQDN (Fully Qualified Domain Name) voor eindpunten gebruikt, configureert u de sjabloon met de locatie van de gekoppelde sjablonen met twee parameters. Parameters kunnen gebruikersinvoer accepteren tijdens de implementatie. Sjablonen worden meestal geschreven en gedeeld door meerdere personen, dus het is een best practice om een standaardnaam te gebruiken voor deze parameters. Naamconventies helpen sjablonen herbruikbaar te maken in regio's, clouds en auteurs.

In de volgende code _artifactsLocation wordt gebruikt om te verwijzen naar één locatie, die alle implementatie-gerelateerde artefacten bevat. U ziet dat er een standaardwaarde is opgegeven. Als tijdens de implementatie geen invoerwaarde is opgegeven voor _artifactsLocation, wordt de standaardwaarde gebruikt. De _artifactsLocationSasToken wordt gebruikt als invoer voor de sasToken. De standaardwaarde moet een lege tekenreeks zijn voor scenario's waarin de _artifactsLocation niet is beveiligd, bijvoorbeeld een openbare GitHub-opslagplaats.

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

In de sjabloon worden koppelingen gegenereerd door de basis-URI (van de _artifactsLocation parameter) te combineren met een artefact-relatief pad en de _artifactsLocationSasToken. De volgende code laat zien hoe u de koppeling naar de geneste sjabloon opgeeft met behulp van de URI-sjabloonfunctie:

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

Met deze methode wordt de standaardwaarde voor de _artifactsLocation parameter gebruikt. Als de gekoppelde sjablonen moeten worden opgehaald van een andere locatie, kan de parameterinvoer tijdens de implementatie worden gebruikt om de standaardwaarde te overschrijven. Er is geen wijziging in de sjabloon zelf nodig.

Gebruik _artifactsLocation in plaats van hardcoderingskoppelingen

De URL in de _artifactsLocation parameter wordt niet alleen gebruikt voor geneste sjablonen, maar wordt ook gebruikt als basis voor alle gerelateerde artefacten van een implementatiesjabloon. Sommige VM-extensies bevatten een koppeling naar een script dat buiten de sjabloon is opgeslagen. Voor deze extensies moet u de koppelingen niet hardcoderen. De extensies Custom Script en PowerShell DSC kunnen bijvoorbeeld worden gekoppeld aan een extern script op GitHub, zoals wordt weergegeven:

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

Door de koppelingen naar het script vast te coderen, voorkomt u mogelijk dat de sjabloon op een andere locatie kan worden geïmplementeerd. Tijdens de configuratie van de VM-resource initieert de VM-agent die in de VM wordt uitgevoerd, een download van alle scripts die zijn gekoppeld in de VM-extensie en slaat de scripts vervolgens op de lokale schijf van de VM op. Deze benadering werkt zoals de geneste sjabloonkoppelingen die eerder zijn uitgelegd in de sectie Geneste sjablonen gebruiken in verschillende regio's.

Resource Manager haalt geneste sjablonen op tijdens runtime. Voor VM-extensies wordt het ophalen van externe artefacten uitgevoerd door de VM-agent. Naast de verschillende initiator van het ophalen van het artefact, is de oplossing in de sjabloondefinitie hetzelfde. Gebruik de parameter _artifactsLocation met een standaardwaarde van het basispad waar alle artefacten worden opgeslagen (inclusief de VM-extensiescripts) en de _artifactsLocationSasToken parameter voor de invoer voor het 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": ""
  }
}

Voor het samenstellen van de absolute URI van een artefact is de voorkeursmethode het gebruik van de sjabloonfunctie URI in plaats van de sjabloonfunctie voor samenvoegen. Door vastgelegde koppelingen naar de scripts in de VM-extensie te vervangen door de URI-sjabloonfunctie, wordt deze functionaliteit in de sjabloon geconfigureerd voor cloudconsistentie.

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

Met deze benadering kunnen alle implementatieartefacten, inclusief configuratiescripts, worden opgeslagen op dezelfde locatie als de sjabloon zelf. Als u de locatie van alle koppelingen wilt wijzigen, hoeft u alleen een andere basis-URL op te geven voor de parameters artifactsLocation.

Houd rekening met verschillende regionale mogelijkheden

Met de flexibele ontwikkeling en continue stroom van updates en nieuwe services die in Azure zijn geïntroduceerd, kunnen regio's verschillen in beschikbaarheid van services of updates. Na grondige interne tests worden nieuwe services of updates van bestaande services meestal geïntroduceerd bij een klein publiek van klanten die deelnemen aan een validatieprogramma. Na een geslaagde klantvalidatie worden de services of updates beschikbaar gesteld binnen een subset van Azure-regio's, vervolgens geïntroduceerd in meer regio's, geïmplementeerd in de onafhankelijke clouds en mogelijk ook beschikbaar gesteld voor Azure Stack-klanten.

Als u weet dat Azure-regio's en clouds in hun beschikbare services kunnen verschillen, kunt u een aantal proactieve beslissingen nemen over uw sjablonen. Een goede plek om te beginnen is door de beschikbare resourceproviders voor een cloud te onderzoeken. Een resourceprovider informeert u over de set resources en bewerkingen die beschikbaar zijn voor een Azure-service.

Met een sjabloon worden resources geïmplementeerd en geconfigureerd. Een resourcetype wordt geleverd door een resourceprovider. De rekenresourceprovider (Microsoft.Compute) biedt bijvoorbeeld meerdere resourcetypen, zoals virtualMachines en availabilitySets. Elke resourceprovider biedt een API voor Azure Resource Manager gedefinieerd door een gemeenschappelijk contract, waardoor een consistente, uniforme ontwerpervaring mogelijk is voor alle resourceproviders. Een resourceprovider die beschikbaar is in wereldwijde Azure, is echter mogelijk niet beschikbaar in een onafhankelijke cloud of een Azure Stack-regio.

Diagram waarin de relatie tussen resourceproviders, resourcetypen en API-versies wordt geïllustreerd.

Voer het volgende script uit in de Azure CLI om de resourceproviders te controleren die beschikbaar zijn in een bepaalde cloud:

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

U kunt ook de volgende PowerShell-cmdlet gebruiken om beschikbare resourceproviders weer te geven:

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

De versie van alle resourcetypen controleren

Een set eigenschappen is gemeenschappelijk voor alle resourcetypen, maar elke resource heeft ook zijn eigen specifieke eigenschappen. Nieuwe functies en gerelateerde eigenschappen worden soms toegevoegd aan bestaande resourcetypen via een nieuwe API-versie. Een resource in een sjabloon heeft een eigen API-versie-eigenschap: apiVersion. Deze versiebeheer zorgt ervoor dat een bestaande resourceconfiguratie in een sjabloon niet wordt beïnvloed door wijzigingen op het platform.

Nieuwe API-versies die zijn geïntroduceerd in bestaande resourcetypen in wereldwijde Azure, zijn mogelijk niet onmiddellijk beschikbaar in alle regio's, onafhankelijke clouds of Azure Stack. Als u een lijst wilt weergeven van de beschikbare resourceproviders, resourcetypen en API-versies voor een cloud, kunt u ResourceVerkenner gebruiken in Azure Portal. Zoek naar Resource Explorer in het menu Alle services. Vouw het knooppunt Providers in Resourceverkenner uit om alle beschikbare resourceproviders, hun resourcetypen en API-versies in die cloud te retourneren.

Voer het volgende script uit om de beschikbare API-versie voor alle resourcetypen in een bepaalde cloud in Azure CLI weer te geven:

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

U kunt ook de volgende PowerShell-cmdlet gebruiken:

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

Raadpleeg resourcelocaties met een parameter

Een sjabloon wordt altijd geïmplementeerd in een resourcegroep die zich in een regio bevindt. Naast de implementatie zelf heeft elke resource in een sjabloon ook een locatie-eigenschap die u gebruikt om de regio op te geven waarin u wilt implementeren. Als u uw sjabloon voor cloudconsistentie wilt ontwikkelen, hebt u een dynamische manier nodig om naar resourcelocaties te verwijzen, omdat elke Azure Stack unieke locatienamen kan bevatten. Meestal worden resources geïmplementeerd in dezelfde regio als de resourcegroep, maar ter ondersteuning van scenario's zoals de beschikbaarheid van toepassingen in meerdere regio's, kan het handig zijn om resources over regio's te spreiden.

Hoewel u de regionamen kunt vastleggen bij het opgeven van de resource-eigenschappen in een sjabloon, garandeert deze benadering niet dat de sjabloon kan worden geïmplementeerd in andere Azure Stack-omgevingen, omdat de regionaam daar waarschijnlijk niet bestaat.

Voor verschillende regio's voegt u een locatie van de invoerparameter toe aan de sjabloon met een standaardwaarde. De standaardwaarde wordt gebruikt als er tijdens de implementatie geen waarde is opgegeven.

De sjabloonfunctie [resourceGroup()] retourneert een object dat de volgende sleutel-waardeparen bevat:

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

Door te verwijzen naar de locatiesleutel van het object in de defaultValue van de invoerparameter, vervangt Azure Resource Manager tijdens runtime de [resourceGroup().location] sjabloonfunctie door de naam van de locatie van de resourcegroep waarin de sjabloon is geïmplementeerd.

"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')]",
    ...

Met deze sjabloonfunctie kunt u uw sjabloon in elke cloud implementeren zonder de regionamen van tevoren te kennen. Bovendien kan een locatie voor een specifieke resource in de sjabloon verschillen van de locatie van de resourcegroep. In dit geval kunt u deze configureren met behulp van aanvullende invoerparameters voor die specifieke resource, terwijl de andere resources in dezelfde sjabloon nog steeds de initiële locatie-invoerparameter gebruiken.

Versies bijhouden met API-profielen

Het kan erg lastig zijn om alle beschikbare resourceproviders en gerelateerde API-versies bij te houden die aanwezig zijn in Azure Stack. Op het moment van schrijven is 2018-04-01de nieuwste API-versie voor Microsoft.Compute/availabilitySets in Azure bijvoorbeeld , terwijl de beschikbare API-versie die voor Azure en Azure Stack wordt gebruikt, is2016-03-30. De algemene API-versie voor Microsoft.Storage/storageAccounts die wordt gedeeld tussen alle Azure- en Azure Stack-locaties is 2016-01-01, terwijl de nieuwste API-versie in Azure is 2018-02-01.

Daarom heeft Resource Manager het concept van API-profielen geïntroduceerd in sjablonen. Zonder API-profielen wordt elke resource in een sjabloon geconfigureerd met een apiVersion element dat de API-versie voor die specifieke resource beschrijft.

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

Een API-profielversie fungeert als een alias voor één API-versie per resourcetype dat gebruikelijk is voor Azure en Azure Stack. In plaats van een API-versie op te geven voor elke resource in een sjabloon, geeft u alleen de API-profielversie op in een nieuw hoofdelement met de naam apiProfile en laat u het apiVersion element voor de afzonderlijke resources weg.

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

Het API-profiel zorgt ervoor dat de API-versies beschikbaar zijn op verschillende locaties, zodat u de apiVersions die beschikbaar zijn op een specifieke locatie niet handmatig hoeft te controleren. Om ervoor te zorgen dat de API-versies waarnaar wordt verwezen door uw API-profiel aanwezig zijn in een Azure Stack-omgeving, moeten de Azure Stack-operators de oplossing up-to-date houden op basis van het beleid voor ondersteuning. Als een systeem meer dan zes maanden verouderd is, wordt het als niet-conform beschouwd en moet de omgeving worden bijgewerkt.

Het API-profiel is geen vereist element in een sjabloon. Zelfs als u het element toevoegt, wordt het alleen gebruikt voor resources waarvoor geen apiVersion is opgegeven. Dit element maakt geleidelijke wijzigingen mogelijk, maar vereist geen wijzigingen in bestaande sjablonen.

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

Eindpuntverwijzingen controleren

Resources kunnen verwijzingen hebben naar andere services op het platform. Aan een openbaar IP-adres kan bijvoorbeeld een openbare DNS-naam zijn toegewezen. De openbare cloud, de onafhankelijke clouds en Azure Stack-oplossingen hebben hun eigen afzonderlijke eindpuntnaamruimten. In de meeste gevallen vereist een resource alleen een voorvoegsel als invoer in de sjabloon. Tijdens runtime voegt Azure Resource Manager de eindpuntwaarde eraan toe. Sommige eindpuntwaarden moeten expliciet worden opgegeven in de sjabloon.

Notitie

Als u sjablonen voor cloudconsistentie wilt ontwikkelen, moet u eindpuntnaamruimten niet hardcoderen.

De volgende twee voorbeelden zijn algemene eindpuntnaamruimten die expliciet moeten worden opgegeven bij het maken van een resource:

  • Opslagaccounts (blob, wachtrij, tabel en bestand)
  • Verbindingsreeksen voor databases en Azure Cache voor Redis

Eindpuntnaamruimten kunnen ook worden gebruikt in de uitvoer van een sjabloon als informatie voor de gebruiker wanneer de implementatie is voltooid. Hier volgen veelvoorkomende voorbeelden:

  • Opslagaccounts (blob, wachtrij, tabel en bestand)
  • Verbindingsreeksen (MySql, SQLServer, SQLAzure, Custom, NotificationHub, ServiceBus, EventHub, ApiHub, DocDb, RedisCache, PostgreSQL)
  • Traffic Manager
  • domainNameLabel van een openbaar IP-adres
  • Cloud services

Vermijd over het algemeen vastgelegde eindpunten in een sjabloon. De aanbevolen procedure is om de functie referentiesjabloon te gebruiken om de eindpunten dynamisch op te halen. Het eindpunt dat het vaakst is vastgelegd, is bijvoorbeeld de eindpuntnaamruimte voor opslagaccounts. Elk opslagaccount heeft een unieke FQDN die wordt samengesteld door de naam van het opslagaccount samen te voegen met de eindpuntnaamruimte. Een blob-opslagaccount met de naam mystorageaccount1 resulteert in verschillende FQDN's, afhankelijk van de cloud:

  • mystorageaccount1.blob.core.windows.net wanneer deze is gemaakt in de globale Azure-cloud.
  • mystorageaccount1.blob.core.chinacloudapi.cn gemaakt in de Azure-cloud beheerd door 21Vianet.

Met de volgende referentiesjabloonfunctie wordt de eindpuntnaamruimte opgehaald uit de opslagresourceprovider:

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

Door de vastgelegde waarde van het eindpunt van het opslagaccount te vervangen door de reference sjabloonfunctie, kunt u dezelfde sjabloon gebruiken om te implementeren in verschillende omgevingen zonder wijzigingen aan te brengen in de eindpuntverwijzing.

Raadpleeg bestaande resources op unieke id

U kunt ook verwijzen naar een bestaande resource uit dezelfde of een andere resourcegroep en binnen hetzelfde abonnement of een ander abonnement, binnen dezelfde tenant in dezelfde cloud. Als u de resource-eigenschappen wilt ophalen, moet u de unieke id voor de resource zelf gebruiken. De resourceId sjabloonfunctie haalt de unieke id van een resource op, zoals SQL Server zoals in de volgende code wordt weergegeven:

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

Vervolgens kunt u de resourceId functie in de reference sjabloonfunctie gebruiken om de eigenschappen van een database op te halen. Het retourobject bevat de fullyQualifiedDomainName eigenschap die de volledige eindpuntwaarde bevat. Deze waarde wordt opgehaald tijdens runtime en biedt de naamruimte van het cloudomgevingsspecifieke eindpunt. Als u de connection string wilt definiëren zonder de naamruimte van het eindpunt vast te leggen, kunt u rechtstreeks in de connection string verwijzen naar de eigenschap van het retourobject, zoals wordt weergegeven:

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

Resource-eigenschappen overwegen

Specifieke resources in Azure Stack-omgevingen hebben unieke eigenschappen die u in uw sjabloon moet overwegen.

Zorg ervoor dat VM-installatiekopieën beschikbaar zijn

Azure biedt een uitgebreide selectie vm-installatiekopieën. Deze installatiekopieën worden gemaakt en voorbereid voor implementatie door Microsoft en partners. De installatiekopieën vormen de basis voor VM's op het platform. Een cloudconsistente sjabloon mag echter alleen verwijzen naar beschikbare parameters, met name de uitgever, aanbieding en SKU van de VM-installatiekopieën die beschikbaar zijn voor de globale Azure-, Onafhankelijke Azure-clouds of een Azure Stack-oplossing.

Voer de volgende Azure CLI-opdracht uit om een lijst met de beschikbare VM-installatiekopieën op een locatie op te halen:

az vm image list -all

U kunt dezelfde lijst ophalen met de Azure PowerShell cmdlet Get-AzureRmVMImagePublisher en de gewenste locatie opgeven met de -Location parameter . Bijvoorbeeld:

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

Met deze opdracht duurt het enkele minuten om alle beschikbare installatiekopieën in de regio Europa - west van de wereldwijde Azure-cloud te retourneren.

Als u deze VM-installatiekopieën beschikbaar maakt voor Azure Stack, wordt alle beschikbare opslag verbruikt. Als u zelfs de kleinste schaaleenheid wilt gebruiken, kunt u met Azure Stack de installatiekopieën selecteren die u aan een omgeving wilt toevoegen.

In het volgende codevoorbeeld ziet u een consistente benadering om te verwijzen naar de parameters uitgever, aanbieding en SKU in uw ARM-sjablonen:

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

Lokale VM-grootten controleren

Als u uw sjabloon voor cloudconsistentie wilt ontwikkelen, moet u ervoor zorgen dat de gewenste VM-grootte beschikbaar is in alle doelomgevingen. VM-grootten zijn een groepering van prestatiekenmerken en -mogelijkheden. Sommige VM-grootten zijn afhankelijk van de hardware waarop de VM wordt uitgevoerd. Als u bijvoorbeeld een voor GPU geoptimaliseerde VM wilt implementeren, moet de hardware waarop de hypervisor wordt uitgevoerd, beschikken over de hardware-GPU's.

Wanneer Microsoft een nieuwe vm-grootte introduceert met bepaalde hardwareafhankelijkheden, wordt de VM-grootte meestal eerst beschikbaar gesteld in een kleine subset van regio's in de Azure-cloud. Later wordt het beschikbaar gemaakt voor andere regio's en clouds. Om ervoor te zorgen dat de VM-grootte bestaat in elke cloud waarin u implementeert, kunt u de beschikbare grootten ophalen met de volgende Azure CLI-opdracht:

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

Voor Azure PowerShell gebruikt u:

Get-AzureRmVMSize -Location "West Europe"

Zie Beschikbare producten per regio voor een volledige lijst met beschikbare services.

Gebruik van Azure Managed Disks in Azure Stack controleren

Beheerde schijven verwerken de opslag voor een Azure-tenant. In plaats van expliciet een opslagaccount te maken en de URI voor een virtuele harde schijf (VHD) op te geven, kunt u beheerde schijven gebruiken om deze acties impliciet uit te voeren wanneer u een virtuele machine implementeert. Beheerde schijven verbeteren de beschikbaarheid door alle schijven van VM's in dezelfde beschikbaarheidsset in verschillende opslageenheden te plaatsen. Bovendien kunnen bestaande VHD's met aanzienlijk minder downtime van Standard naar Premium-opslag worden geconverteerd.

Hoewel beheerde schijven op de roadmap voor Azure Stack staan, worden ze momenteel niet ondersteund. Totdat ze zijn, kunt u cloudconsistente sjablonen voor Azure Stack ontwikkelen door expliciet VHD's op te geven met behulp van het vhd element in de sjabloon voor de VM-resource, zoals wordt weergegeven:

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

Als u daarentegen een beheerde schijfconfiguratie in een sjabloon wilt opgeven, verwijdert u het vhd element uit de schijfconfiguratie.

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

Dezelfde wijzigingen zijn ook van toepassing op gegevensschijven.

Controleren of VM-extensies beschikbaar zijn in Azure Stack

Een andere overweging voor cloudconsistentie is het gebruik van extensies voor virtuele machines om de resources in een VM te configureren. Niet alle VM-extensies zijn beschikbaar in Azure Stack. Een sjabloon kan de resources opgeven die zijn toegewezen aan de VM-extensie, waardoor afhankelijkheden en voorwaarden in de sjabloon worden gemaakt.

Als u bijvoorbeeld een VM met Microsoft SQL Server wilt configureren, kan de VM-extensie SQL Server configureren als onderdeel van de sjabloonimplementatie. Overweeg wat er gebeurt als de implementatiesjabloon ook een toepassingsserver bevat die is geconfigureerd voor het maken van een database op de VM waarop SQL Server wordt uitgevoerd. Naast het gebruik van een VM-extensie voor de toepassingsservers, kunt u ook de afhankelijkheid van de toepassingsserver configureren voor het succesvol retourneren van de SQL Server VM-extensieresource. Deze aanpak zorgt ervoor dat de VM die wordt uitgevoerd SQL Server wordt geconfigureerd en beschikbaar is wanneer de toepassingsserver wordt geïnstrueerd om de database te maken.

Met de declaratieve benadering van de sjabloon kunt u de eindstatus van de resources en hun onderlinge afhankelijkheden definiëren, terwijl het platform zorgt voor de logica die vereist is voor de afhankelijkheden.

Controleren of VM-extensies beschikbaar zijn

Er bestaan veel typen VM-extensies. Wanneer u een sjabloon voor cloudconsistentie ontwikkelt, moet u ervoor zorgen dat u alleen de extensies gebruikt die beschikbaar zijn in alle regio's waarop de sjabloon is gericht.

Voer de volgende Azure CLI-opdracht uit om een lijst op te halen van de VM-extensies die beschikbaar zijn voor een specifieke regio (in dit voorbeeld myLocation):

az vm extension image list --location myLocation

U kunt ook de cmdlet Azure PowerShell Get-AzureRmVmImagePublisher uitvoeren en gebruiken -Location om de locatie van de installatiekopie van de virtuele machine op te geven. Bijvoorbeeld:

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

Zorg ervoor dat er versies beschikbaar zijn

Omdat VM-extensies eigen Resource Manager resources zijn, hebben ze hun eigen API-versies. Zoals in de volgende code wordt weergegeven, is het type VM-extensie een geneste resource in de resourceprovider Microsoft.Compute.

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

De API-versie van de VM-extensieresource moet aanwezig zijn op alle locaties waarop u zich wilt richten met uw sjabloon. De locatieafhankelijkheid werkt zoals de beschikbaarheid van de API-versie van de resourceprovider die eerder is besproken in de sectie 'De versie van alle resourcetypen controleren'.

Als u een lijst met de beschikbare API-versies voor de VM-extensieresource wilt ophalen, gebruikt u de cmdlet Get-AzureRmResourceProvider met de resourceprovider Microsoft.Compute , zoals weergegeven:

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

U kunt ook VM-extensies gebruiken in virtuele-machineschaalsets. Dezelfde locatievoorwaarden zijn van toepassing. Als u uw sjabloon voor cloudconsistentie wilt ontwikkelen, moet u ervoor zorgen dat de API-versies beschikbaar zijn op alle locaties waarop u wilt implementeren. Als u de API-versies van de VM-extensieresource voor schaalsets wilt ophalen, gebruikt u dezelfde cmdlet als voorheen, maar geeft u het resourcetype van de virtuele-machineschaalsets op zoals wordt weergegeven:

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

Elke specifieke extensie is ook geversied. Deze versie wordt weergegeven in de typeHandlerVersion eigenschap van de VM-extensie. Zorg ervoor dat de versie die is opgegeven in het element van de typeHandlerVersion VM-extensies van uw sjabloon beschikbaar is op de locaties waar u de sjabloon wilt implementeren. De volgende code geeft bijvoorbeeld versie 1.7 op:

{
    "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",
        ...

Als u een lijst met de beschikbare versies voor een specifieke VM-extensie wilt ophalen, gebruikt u de cmdlet Get-AzureRmVMExtensionImage . In het volgende voorbeeld worden de beschikbare versies voor de VM-extensie PowerShell DSC (Desired State Configuration) opgehaald uit myLocation:

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

Gebruik de opdracht Get-AzureRmVmImagePublisher om een lijst met uitgevers op te halen. Gebruik de opdracht Get-AzureRmVMExtensionImageType om het type aan te vragen.

Tips voor testen en automatisering

Het is een uitdaging om alle gerelateerde instellingen, mogelijkheden en beperkingen bij te houden tijdens het ontwerpen van een sjabloon. De algemene aanpak is het ontwikkelen en testen van sjablonen op basis van één cloud voordat andere locaties worden gericht. Hoe eerder er echter tests worden uitgevoerd in het ontwerpproces, hoe minder probleemoplossing en codeherschrijven uw ontwikkelteam hoeft te doen. Implementaties die mislukken vanwege locatieafhankelijkheden, kunnen tijdrovend zijn om problemen op te lossen. Daarom raden we u aan om zo vroeg mogelijk in de ontwerpcyclus geautomatiseerd te testen. Uiteindelijk hebt u minder ontwikkeltijd en minder resources nodig en worden uw cloudconsistente artefacten nog waardevoller.

In de volgende afbeelding ziet u een typisch voorbeeld van een ontwikkelingsproces voor een team dat gebruikmaakt van een IDE (Integrated Development Environment). In verschillende fasen in de tijdlijn worden verschillende testtypen uitgevoerd. Hier werken twee ontwikkelaars aan dezelfde oplossing, maar dit scenario is evenzeer van toepassing op één ontwikkelaar of een groot team. Elke ontwikkelaar maakt doorgaans een lokale kopie van een centrale opslagplaats, zodat elke opslagplaats aan de lokale kopie kan werken zonder dat dit van invloed is op de anderen die mogelijk aan dezelfde bestanden werken.

Diagram met parallelle eenheidstests en integratietests in lokale IDE's, samenvoeging in CI/CD-ontwikkelingsstroom met eenheidstests, integratietests, testimplementatie en uiteindelijke implementatie.

Bekijk de volgende tips voor testen en automatisering:

  • Maak wel gebruik van testhulpprogramma's. Visual Studio Code en Visual Studio bevatten bijvoorbeeld IntelliSense en andere functies waarmee u uw sjablonen kunt valideren.
  • Als u de codekwaliteit tijdens de ontwikkeling op de lokale IDE wilt verbeteren, voert u statische codeanalyse uit met eenheidstests en integratietests.
  • Voor een nog betere ervaring tijdens de eerste ontwikkeling moeten eenheidstests en integratietests alleen waarschuwen wanneer er een probleem wordt gevonden en doorgaan met de tests. Op die manier kunt u de problemen identificeren die moeten worden opgelost en prioriteit geven aan de volgorde van de wijzigingen, ook wel testgestuurde implementatie (TDD) genoemd.
  • Houd er rekening mee dat sommige tests kunnen worden uitgevoerd zonder dat ze zijn verbonden met Azure Resource Manager. Andere, zoals het testen van sjabloonimplementatie, vereisen dat Resource Manager bepaalde acties uitvoert die niet offline kunnen worden uitgevoerd.
  • Het testen van een implementatiesjabloon op basis van de validatie-API is niet gelijk aan een werkelijke implementatie. Zelfs als u een sjabloon implementeert vanuit een lokaal bestand, worden alle verwijzingen naar geneste sjablonen in de sjabloon rechtstreeks door Resource Manager opgehaald en worden artefacten waarnaar wordt verwezen door VM-extensies opgehaald door de VM-agent die wordt uitgevoerd in de geïmplementeerde VM.

Volgende stappen