Delen via

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 zijn herbruikbaar in een andere locatie. Een Azure Resource Manager-sjabloon (ARM-sjabloon) maakt uw implementaties consistent en herhaalbaar in omgevingen, waaronder de wereldwijde Azure- en soevereine Azure-clouds en Azure Stack. Als u sjablonen in clouds opnieuw wilt gebruiken, 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, Azure Stack uitvoeren in hun faciliteiten (ook wel gehoste regio's genoemd).

In de kern van al deze clouds biedt Azure Resource Manager een API waarmee een groot aantal gebruikersinterfaces kan communiceren met het Azure-platform. Deze API biedt krachtige mogelijkheden voor infrastructuur als code. 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 in een operationele eindstatus.

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

De consistentie van wereldwijde 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 op sjablonen gebaseerde resource-implementatie en -configuratie 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 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.
  • Sla geneste sjablonen en configuratieartefacten op toegankelijke locaties op en zorg voor toegang tot clouds.
  • Gebruik dynamische verwijzingen in plaats van hardcoderingskoppelingen en -elementen.
  • Zorg ervoor dat de sjabloonparameters die u gebruikt, werken in de doelclouds.
  • Controleer of resourcespecifieke eigenschappen beschikbaar zijn voor de doelclouds.

Zie Sjabloonimplementatie voor een inleiding tot ARM-sjablonen.

Controleren of sjabloonfuncties werken

De basissyntaxis van een ARM-sjabloon is JSON. Sjablonen gebruiken een superset van JSON, waarmee de syntaxis wordt uitgebreid met expressies en functies. De taalprocessor voor sjablonen wordt regelmatig bijgewerkt ter ondersteuning van aanvullende sjabloonfuncties. Zie ARM-sjabloonfuncties voor een gedetailleerde uitleg van de beschikbare sjabloonfuncties.

Nieuwe sjabloonfuncties die zijn geïntroduceerd in Azure Resource Manager, zijn niet direct 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.

Azure Resource Manager-mogelijkheden worden altijd geïntroduceerd in de wereldwijde Azure-wereld. 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 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 VM-extensies (virtuele machines). Deze artefacten worden opgehaald door de VM-extensie die binnen de VM wordt uitgevoerd voor de configuratie van de VM-extensie tijdens de sjabloonimplementatie.

In de volgende secties worden overwegingen beschreven voor cloudconsistentie bij het ontwikkelen van sjablonen met artefacten die extern zijn voor de hoofdimplementatiesjabloon.

Geneste sjablonen gebruiken in verschillende regio's

Sjablonen kunnen worden opgesplitst in kleine, herbruikbare sjablonen, die elk een specifiek doel hebben en kunnen worden hergebruikt in implementatiescenario's. Als u een implementatie wilt uitvoeren, geeft u één sjabloon op die de hoofd- of hoofdsjabloon wordt genoemd. Hiermee geeft u de resources op 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 rechtstreeks toegang tot alle gekoppelde sjablonen op. 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, bevindt een Azure Stack-omgeving zich mogelijk op een bedrijfsnetwerk 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 implementaties in meerdere clouds is het opslaan van uw gekoppelde sjablonen op een locatie die toegankelijk is voor de doelcloud. In het ideale voorbeeld worden alle implementatieartefacten onderhouden en geïmplementeerd vanuit een CI/CD-pijplijn (continuous integration/continuous development). U kunt geneste sjablonen ook opslaan in een blobopslagcontainer, waaruit Azure Resource Manager ze kan ophalen.

Aangezien de blobopslag in elke cloud gebruikmaakt van een andere FQDN (Fully Qualified Domain Name) voor eindpunten, configureert u de sjabloon met de locatie van de gekoppelde sjablonen met twee parameters. Parameters kunnen gebruikersinvoer accepteren tijdens de implementatie. Sjablonen worden doorgaans door meerdere personen geschreven en gedeeld, dus het wordt aanbevolen om een standaardnaam voor deze parameters te gebruiken. Naamconventies helpen sjablonen herbruikbaar te maken in regio's, clouds en auteurs.

In de volgende code _artifactsLocation wordt gebruikt om naar één locatie te verwijzen, met alle implementatiegerelateerde artefacten. U ziet dat er een standaardwaarde wordt opgegeven. Als er tijdens de implementatie geen invoerwaarde is opgegeven _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 waarde 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 het _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"
      }
    }
  }
]

Door deze methode te gebruiken, 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

Naast gebruik voor geneste sjablonen wordt de URL in de _artifactsLocation parameter 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 voor aangepaste scripts en PowerShell DSC kunnen bijvoorbeeld een koppeling maken naar 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 hard te coderen, voorkomt u mogelijk dat de sjabloon wordt geïmplementeerd op een andere locatie. Tijdens de configuratie van de VM-resource start de VM-agent die in de VIRTUELE machine wordt uitgevoerd een download van alle scripts die zijn gekoppeld aan de VM-extensie en slaat de scripts vervolgens op de lokale schijf van de VIRTUELE machine op. Deze benadering werkt zoals de geneste sjabloonkoppelingen die eerder in de sectie Geneste sjablonen in verschillende regio's worden uitgelegd.

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 artefacten is de oplossing in de sjabloondefinitie hetzelfde. Gebruik de parameter _artifactsLocation met een standaardwaarde van het basispad waarin alle artefacten worden opgeslagen (inclusief de scripts voor de VM-extensie) 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": ""
  }
}

Als u de absolute URI van een artefact wilt maken, is de voorkeursmethode om de URI-sjabloonfunctie te gebruiken in plaats van de functie voor samenvoegingssjablonen. Door in code 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 met 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.

Factor in verschillende regionale mogelijkheden

Met de flexibele ontwikkeling en continue stroom van updates en nieuwe services die zijn geïntroduceerd in Azure, kunnen regio's verschillen in de beschikbaarheid van services of updates. Na strenge interne tests worden nieuwe services of updates voor bestaande services meestal geïntroduceerd bij een kleine doelgroep 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 enkele proactieve beslissingen nemen over uw sjablonen. Een goede plek om te beginnen is door de beschikbare resourceproviders voor een cloud te onderzoeken. Een resourceprovider vertelt u 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 die is gedefinieerd door een gemeenschappelijk contract, waardoor een consistente, uniforme ontwerpervaring mogelijk is voor alle resourceproviders. Een resourceprovider die beschikbaar is in globale Azure, is mogelijk niet beschikbaar in een onafhankelijke cloud of een Azure Stack-regio.

Diagram met de relatie tussen resourceproviders, resourcetypen en API-versies.

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 gebruikelijk 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-versieeigenschap - 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 globale Azure, zijn mogelijk niet onmiddellijk beschikbaar in alle regio's, onafhankelijke clouds of Azure Stack. Als u een lijst wilt weergeven met de beschikbare resourceproviders, resourcetypen en API-versies voor een cloud, kunt u Resource Explorer in Azure Portal gebruiken. Zoek naar Resource Explorer in het menu Alle services. Vouw het knooppunt Providers in Resource Explorer uit om alle beschikbare resourceproviders, hun resourcetypen en API-versies in die cloud te retourneren.

Als u de beschikbare API-versie wilt weergeven voor alle resourcetypen in een bepaalde cloud in Azure CLI, voert u het volgende script uit:

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

Verwijzen naar 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. Voor het ontwikkelen van uw sjabloon voor cloudconsistentie hebt u een dynamische manier nodig om te verwijzen naar resourcelocaties, 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 beschikbaarheid van toepassingen in meerdere regio's, kan het handig zijn om resources over regio's te verdelen.

Hoewel u de regionamen kunt coderen 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 er waarschijnlijk niet bestaat.

Als u ruimte wilt maken voor verschillende regio's, voegt u een locatie van de invoerparameter toe aan de sjabloon met een standaardwaarde. De standaardwaarde wordt gebruikt als er geen waarde wordt opgegeven tijdens de implementatie.

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 waarnaar 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 implementeren in elke cloud zonder dat u vooraf de regionamen hoeft te kennen. Daarnaast 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 parameter voor locatieinvoer gebruiken.

Versies bijhouden met API-profielen

Het kan erg lastig zijn om alle beschikbare resourceproviders en gerelateerde API-versies die aanwezig zijn in Azure Stack bij te houden. Op het moment van schrijven is bijvoorbeeld de nieuwste API-versie voor Microsoft.Compute/availabilitySets in Azure 2018-04-01, terwijl de beschikbare API-versie gebruikelijk is 2016-03-30voor Azure en Azure Stack. 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 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 die 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 dat wordt aangeroepen apiProfile en laat u het apiVersion element weg voor de afzonderlijke resources.

{
    "$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, dus u hoeft de apiVersions die beschikbaar zijn op een specifieke locatie niet handmatig te verifiëren. 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 langer dan zes maanden verouderd is, wordt het beschouwd als niet-conform en moet de omgeving worden bijgewerkt.

Het API-profiel is geen vereist element in een sjabloon. Zelfs als u het element toevoegt, wordt dit alleen gebruikt voor resources waarvoor er 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 is voor een resource alleen een voorvoegsel als invoer in de sjabloon vereist. 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, hoeft u geen eindpuntnaamruimten te 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 enkele 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
  • Cloudservices

Vermijd in 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 is samengesteld door de naam van het opslagaccount samen te voegen met de eindpuntnaamruimte. Een blob storage-account met de naam mystorageaccount1 resulteert in verschillende FQDN's, afhankelijk van de cloud:

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

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

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

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

Verwijzen naar 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. Met resourceId de sjabloonfunctie wordt de unieke id van een resource, zoals SQL Server, opgehaald, 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 tijdens runtime opgehaald en biedt de naamruimte voor het eindpunt in de cloudomgeving. Als u de verbindingsreeks wilt definiëren zonder de eindpuntnaamruimte te coderen, kunt u rechtstreeks in de verbindingsreeks 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.

Controleren of VM-installatiekopieën beschikbaar zijn

Azure biedt een uitgebreide selectie van 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 moet echter alleen verwijzen naar beschikbare parameters, met name de uitgever, aanbieding en SKU van de VM-installatiekopieën die beschikbaar zijn voor de wereldwijde Azure-, soevereine 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. Voorbeeld:

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

Het duurt enkele minuten voordat deze opdracht alle beschikbare installatiekopieën retourneert in de regio Europa - west van de wereldwijde Azure-cloud.

Als u deze VM-installatiekopieën beschikbaar hebt gemaakt voor Azure Stack, wordt alle beschikbare opslag verbruikt. Voor zelfs de kleinste schaaleenheid 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 uitgevers-, aanbiedings- en SKU-parameters 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 grootte introduceert van een virtuele machine 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. Als u wilt controleren of 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 Producten beschikbaar per regio voor een volledige lijst met beschikbare services.

Het 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. Daarnaast kunnen bestaande VHD's worden geconverteerd van Standard naar Premium-opslag met aanzienlijk minder downtime.

Hoewel beheerde schijven op de roadmap voor Azure Stack staan, worden ze momenteel niet ondersteund. Totdat dit zo is, 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 configuratie van een beheerde schijf 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 passen ook gegevensschijven toe.

Controleer of VM-extensies beschikbaar zijn in Azure Stack

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

Als u bijvoorbeeld een VIRTUELE machine met Microsoft SQL Server wilt configureren, kan de VM-extensie SQL Server configureren als onderdeel van de sjabloonimplementatie. Bedenk wat er gebeurt als de implementatiesjabloon ook een toepassingsserver bevat die is geconfigureerd voor het maken van een database op de virtuele machine waarop SQL Server wordt uitgevoerd. Naast het gebruik van een VM-extensie voor de toepassingsservers, kunt u de afhankelijkheid van de toepassingsserver configureren bij het succesvol retourneren van de SQL Server VM-extensieresource. Deze aanpak zorgt ervoor dat de VM waarop SQL Server wordt uitgevoerd, is geconfigureerd en beschikbaar 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.

Controleer 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 die de sjabloondoelen hebben.

Als u een lijst wilt ophalen van de VM-extensies die beschikbaar zijn voor een specifieke regio (in dit voorbeeld myLocation), voert u de volgende Azure CLI-opdracht uit:

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. Voorbeeld:

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

Controleren of 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 Microsoft.Compute-resourceprovider.

{
    "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 in de sectie 'Controleer de versie van alle resourcetypen' is besproken.

Als u een lijst met de beschikbare API-versies voor de VM-extensieresource wilt ophalen, gebruikt u de cmdlet Get-AzureRmResourceProvider met de Microsoft.Compute-resourceprovider , zoals wordt 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 van plan bent te 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 voor 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 wordt 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 zijn op de locaties waar u de sjabloon wilt implementeren. Met de volgende code wordt bijvoorbeeld versie 1.7 opgegeven:

{
    "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 opgehaald voor de VM-extensie PowerShell DSC (Desired State Configuration) van 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 aanbeveling Get-AzureRmVMExtensionImageType om het type aanvraag 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 tests worden uitgevoerd in het ontwerpproces, hoe minder probleemoplossing en code herschrijven uw ontwikkelteam moet doen. Implementaties die mislukken vanwege locatieafhankelijkheden, kunnen tijdrovend zijn om problemen op te lossen. Daarom raden we geautomatiseerde tests zo vroeg mogelijk aan in de ontwerpcyclus. 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 met behulp 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 kan werken aan de lokale kopie 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, samenvoegen in CI/CD-ontwikkelingsstroom met eenheidstests, integratietests, testimplementatie en uiteindelijke implementatie.

Bekijk de volgende tips voor testen en automatisering:

  • Maak 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 verbinding te maken met Azure Resource Manager. Voor andere, zoals het testen van sjabloonimplementatie, moet Resource Manager bepaalde acties uitvoeren 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 verwijzingen naar geneste sjablonen in de sjabloon rechtstreeks opgehaald door Resource Manager en worden artefacten waarnaar wordt verwezen door VM-extensies opgehaald door de VM-agent die wordt uitgevoerd binnen de geïmplementeerde VM.

Volgende stappen