Utveckla ARM-mallar för molnkonsekvens

Viktigt!

Om du använder den här Azure-funktionen från PowerShell måste modulen AzureRM vara installerad. Det här är en äldre modul som bara är tillgänglig för Windows PowerShell 5.1 som inte längre tar emot nya funktioner. Modulerna Az och AzureRM är inte kompatibla när de installeras för samma versioner av PowerShell. Om du behöver båda versionerna:

1. Avinstallera Az-modulen från en PowerShell 5.1-session.
2. Installera AzureRM-modulen från en PowerShell 5.1-session.
3. Ladda ned och installera PowerShell Core 6.x eller senare.
4. Installera Az-modulen i en PowerShell Core-session.

En viktig fördel med Azure är konsekvens. Utvecklingsinvesteringar för en plats kan återanvändas i en annan. En Azure Resource Manager-mall (ARM-mall) gör dina distributioner konsekventa och repeterbara i olika miljöer, inklusive globala Azure-, Azure-nationella moln och Azure Stack. Om du vill återanvända mallar mellan moln måste du dock överväga molnspecifika beroenden som beskrivs i den här guiden.

Microsoft erbjuder intelligenta, företagsklara molntjänster på många platser, inklusive:

• Den globala Azure-plattformen som stöds av ett växande nätverk av Microsoft-hanterade datacenter i regioner runt om i världen.
• Isolerade nationella moln som Azure Tyskland, Azure Government och Microsoft Azure som drivs av 21Vianet. Nationella moln ger en konsekvent plattform med de flesta av samma fantastiska funktioner som globala Azure-kunder har åtkomst till.
• Azure Stack, en hybridmolnplattform som låter dig leverera Azure-tjänster från din organisations datacenter. Företag kan konfigurera Azure Stack i sina egna datacenter eller använda Azure-tjänster från tjänsteleverantörer och köra Azure Stack i sina anläggningar (kallas ibland värdbaserade regioner).

Azure Resource Manager är kärnan i alla dessa moln och tillhandahåller ett API som gör att en mängd olika användargränssnitt kan kommunicera med Azure-plattformen. Det här API:et ger dig kraftfulla funktioner för infrastruktur som kod. Alla typer av resurser som är tillgängliga på Azure-molnplattformen kan distribueras och konfigureras med Azure Resource Manager. Med en enda mall kan du distribuera och konfigurera hela programmet till ett driftsluttillstånd.

Konsekvensen i globala Azure, nationella moln, värdbaserade moln och ett moln i ditt datacenter hjälper dig att dra nytta av Azure Resource Manager. Du kan återanvända dina utvecklingsinvesteringar i dessa moln när du konfigurerar mallbaserad resursdistribution och konfiguration.

Men även om de globala, nationella, värdbaserade och hybridmoln som tillhandahåller konsekventa tjänster, är inte alla moln identiska. Därför kan du skapa en mall med beroenden för funktioner som endast är tillgängliga i ett visst moln.

Resten av den här guiden beskriver de områden du bör tänka på när du planerar att utveckla nya eller uppdatera befintliga ARM-mallar för Azure Stack. I allmänhet bör checklistan innehålla följande:

• Kontrollera att funktionerna, slutpunkterna, tjänsterna och andra resurser i mallen är tillgängliga på måldistributionsplatserna.
• Lagra kapslade mallar och konfigurationsartefakter på tillgängliga platser, vilket säkerställer åtkomst mellan moln.
• Använd dynamiska referenser i stället för hårdkodande länkar och element.
• Se till att de mallparametrar som du använder fungerar i målmoln.
• Kontrollera att resursspecifika egenskaper är tillgängliga för målmoln.

En introduktion till ARM-mallar finns i Malldistribution.

Se till att mallfunktioner fungerar

Den grundläggande syntaxen för en ARM-mall är JSON. Mallar använder en superuppsättning med JSON, vilket utökar syntaxen med uttryck och funktioner. Mallspråkprocessorn uppdateras ofta för att stödja ytterligare mallfunktioner. En detaljerad förklaring av tillgängliga mallfunktioner finns i ARM-mallfunktioner.

Nya mallfunktioner som introduceras i Azure Resource Manager är inte omedelbart tillgängliga i nationella moln eller Azure Stack. Om du vill distribuera en mall måste alla funktioner som refereras i mallen vara tillgängliga i målmolnet.

Azure Resource Manager-funktioner introduceras alltid i den globala Azure först. Du kan använda följande PowerShell-skript för att kontrollera om nyligen introducerade mallfunktioner också är tillgängliga i Azure Stack:

1. Gör en klon av GitHub-lagringsplatsen: https://github.com/marcvaneijk/arm-template-functions.

2. När du har en lokal klon av lagringsplatsen ansluter du till målets Azure Resource Manager med PowerShell.

3. Importera psm1-modulen och kör cmdleten 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>
   

Skriptet distribuerar flera minimerade mallar som var och en endast innehåller unika mallfunktioner. Utdata från skriptet rapporterar de mallfunktioner som stöds och inte är tillgängliga.

Arbeta med länkade artefakter

En mall kan innehålla referenser till länkade artefakter och innehålla en distributionsresurs som länkar till en annan mall. De länkade mallarna (kallas även kapslad mall) hämtas av Resource Manager vid körning. En mall kan också innehålla referenser till artefakter för tillägg för virtuella datorer . Dessa artefakter hämtas av vm-tillägget som körs i den virtuella datorn för konfiguration av VM-tillägget under malldistributionen.

I följande avsnitt beskrivs överväganden för molnkonsekvens när du utvecklar mallar som innehåller artefakter som är externa till huvuddistributionsmallen.

Använda kapslade mallar mellan regioner

Mallar kan delas upp i små, återanvändbara mallar, som var och en har ett specifikt syfte och kan återanvändas i olika distributionsscenarier. Om du vill köra en distribution anger du en enda mall som kallas huvudmallen eller huvudmallen. Den anger vilka resurser som ska distribueras, till exempel virtuella nätverk, virtuella datorer och webbappar. Huvudmallen kan också innehålla en länk till en annan mall, vilket innebär att du kan kapsla mallar. På samma sätt kan en kapslad mall innehålla länkar till andra mallar. Du kan kapsla upp till fem nivåer djupt.

Följande kod visar hur parametern templateLink refererar till en kapslad mall:

"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 utvärderar huvudmallen vid körning och hämtar och utvärderar varje kapslad mall. När alla kapslade mallar har hämtats plattas mallen ut och ytterligare bearbetning initieras.

Gör länkade mallar tillgängliga i moln

Överväg var och hur du lagrar länkade mallar som du använder. Vid körning hämtar Azure Resource Manager – och kräver därför direkt åtkomst till – alla länkade mallar. En vanlig metod är att använda GitHub för att lagra de kapslade mallarna. En GitHub-lagringsplats kan innehålla filer som är tillgängliga offentligt via en URL. Även om den här tekniken fungerar bra för det offentliga molnet och de nationella molnen kan en Azure Stack-miljö finnas i ett företagsnätverk eller på en frånkopplad fjärrplats, utan utgående Internetåtkomst. I dessa fall skulle Azure Resource Manager inte kunna hämta de kapslade mallarna.

En bättre metod för distributioner mellan moln är att lagra dina länkade mallar på en plats som är tillgänglig för målmolnet. Helst underhålls alla distributionsartefakter i och distribueras från en CI/CD-pipeline (kontinuerlig integrering/kontinuerlig utveckling). Du kan också lagra kapslade mallar i en bloblagringscontainer, från vilken Azure Resource Manager kan hämta dem.

Eftersom bloblagringen i varje moln använder ett annat fullständigt domännamn för slutpunkten (FQDN) konfigurerar du mallen med platsen för de länkade mallarna med två parametrar. Parametrar kan acceptera användarindata vid distributionstillfället. Mallar skapas och delas vanligtvis av flera personer, så bästa praxis är att använda ett standardnamn för dessa parametrar. Namngivningskonventioner hjälper till att göra mallar mer återanvändbara i regioner, moln och författare.

I följande kod _artifactsLocation används för att peka på en enda plats som innehåller alla distributionsrelaterade artefakter. Observera att ett standardvärde anges. Om inget indatavärde har angetts för _artifactsLocationvid distributionen används standardvärdet. _artifactsLocationSasToken Används som indata för sasToken. Standardvärdet ska vara en tom sträng för scenarier där _artifactsLocation inte skyddas , till exempel en offentlig GitHub-lagringsplats.

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

I hela mallen genereras länkar genom att kombinera bas-URI :n (från parametern _artifactsLocation ) med en artefaktrelativ sökväg och _artifactsLocationSasToken. Följande kod visar hur du anger länken till den kapslade mallen med hjälp av URI-mallfunktionen:

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

Med den här metoden används standardvärdet för parametern _artifactsLocation . Om de länkade mallarna behöver hämtas från en annan plats kan parameterindata användas vid distributionstillfället för att åsidosätta standardvärdet– ingen ändring av själva mallen behövs.

Använd _artifactsLocation i stället för hårdkodningslänkar

Förutom att användas för kapslade mallar används URL:en i parametern _artifactsLocation som bas för alla relaterade artefakter i en distributionsmall. Vissa VM-tillägg innehåller en länk till ett skript som lagras utanför mallen. För dessa tillägg bör du inte hårdkoda länkarna. Till exempel kan anpassade skript- och PowerShell DSC-tillägg länka till ett externt skript på GitHub enligt följande:

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

Genom att hårdkoda länkarna till skriptet kan det förhindra att mallen distribueras till en annan plats. Under konfigurationen av vm-resursen initierar VM-agenten som körs i den virtuella datorn en nedladdning av alla skript som är länkade i VM-tillägget och lagrar sedan skripten på den virtuella datorns lokala disk. Den här metoden fungerar som de kapslade malllänkarna som beskrevs tidigare i avsnittet "Använd kapslade mallar mellan regioner".

Resource Manager hämtar kapslade mallar vid körning. För VM-tillägg utförs hämtningen av externa artefakter av VM-agenten. Förutom den olika initieraren av artefakthämtningen är lösningen i malldefinitionen densamma. Använd parametern _artifactsLocation med ett standardvärde för bassökvägen där alla artefakter lagras (inklusive skript för VM-tillägg) och parametern _artifactsLocationSasToken för indata för 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": ""
  }
}

För att konstruera den absoluta URI:n för en artefakt är den föredragna metoden att använda URI-mallfunktionen i stället för funktionen för sammanlänkningsmall. Genom att ersätta hårdkodade länkar till skripten i VM-tillägget med URI-mallfunktionen konfigureras den här funktionen i mallen för molnkonsekvens.

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

Med den här metoden kan alla distributionsartefakter, inklusive konfigurationsskript, lagras på samma plats som själva mallen. Om du vill ändra platsen för alla länkar behöver du bara ange en annan bas-URL för parametrarna artifactsLocation.

Faktor i olika regionala funktioner

Med den flexibla utvecklingen och det kontinuerliga flödet av uppdateringar och nya tjänster som introduceras i Azure kan regionerna skilja sig åt i tillgängligheten för tjänster eller uppdateringar. Efter rigorös intern testning introduceras vanligtvis nya tjänster eller uppdateringar av befintliga tjänster för en liten målgrupp av kunder som deltar i ett valideringsprogram. Efter lyckad kundverifiering görs tjänsterna eller uppdateringarna tillgängliga i en delmängd av Azure-regioner, introduceras sedan i fler regioner, distribueras till de nationella molnen och görs potentiellt tillgängliga även för Azure Stack-kunder.

Om du vet att Azure-regioner och moln kan skilja sig åt i sina tillgängliga tjänster kan du fatta några proaktiva beslut om dina mallar. Ett bra ställe att börja på är att undersöka tillgängliga resursprovidrar för ett moln. En resursprovider anger vilken uppsättning resurser och åtgärder som är tillgängliga för en Azure-tjänst.

En mall distribuerar och konfigurerar resurser. En resurstyp tillhandahålls av en resursprovider. Till exempel tillhandahåller beräkningsresursprovidern (Microsoft.Compute) flera resurstyper som virtualMachines och availabilitySets. Varje resursprovider tillhandahåller ett API till Azure Resource Manager som definieras av ett gemensamt kontrakt, vilket möjliggör en konsekvent, enhetlig redigeringsupplevelse för alla resursprovidrar. En resursprovider som är tillgänglig i globala Azure kanske inte är tillgänglig i ett nationellt moln eller i en Azure Stack-region.

Kontrollera vilka resursprovidrar som är tillgängliga i ett visst moln genom att köra följande skript i Azure CLI:

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

Du kan också använda följande PowerShell-cmdlet för att se tillgängliga resursprovidrar:

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

Verifiera versionen av alla resurstyper

En uppsättning egenskaper är gemensamma för alla resurstyper, men varje resurs har också sina egna specifika egenskaper. Nya funktioner och relaterade egenskaper läggs ibland till i befintliga resurstyper via en ny API-version. En resurs i en mall har en egen API-versionegenskap – apiVersion. Den här versionshantering säkerställer att en befintlig resurskonfiguration i en mall inte påverkas av ändringar på plattformen.

Nya API-versioner som introducerats för befintliga resurstyper i globala Azure kanske inte omedelbart är tillgängliga i alla regioner, nationella moln eller Azure Stack. Om du vill visa en lista över tillgängliga resursprovidrar, resurstyper och API-versioner för ett moln kan du använda Resource Explorer i Azure-portalen. Sök efter Resource Explorer på menyn Alla tjänster. Expandera noden Providers i Resource Explorer för att returnera alla tillgängliga resursprovidrar, deras resurstyper och API-versioner i molnet.

Kör följande skript för att lista den tillgängliga API-versionen för alla resurstyper i ett visst moln i Azure CLI:

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

Du kan också använda följande PowerShell-cmdlet:

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

Se resursplatser med en parameter

En mall distribueras alltid till en resursgrupp som finns i en region. Förutom själva distributionen har varje resurs i en mall också en platsegenskap som du använder för att ange den region som ska distribueras i. Om du vill utveckla mallen för molnkonsekvens behöver du ett dynamiskt sätt att referera till resursplatser eftersom varje Azure Stack kan innehålla unika platsnamn. Vanligtvis distribueras resurser i samma region som resursgruppen, men för att stödja scenarier som programtillgänglighet mellan regioner kan det vara användbart att sprida resurser mellan regioner.

Även om du kan hårdkoda regionnamnen när du anger resursegenskaperna i en mall garanterar inte den här metoden att mallen kan distribueras till andra Azure Stack-miljöer, eftersom regionnamnet troligen inte finns där.

För att hantera olika regioner lägger du till en indataparameterplats i mallen med ett standardvärde. Standardvärdet används om inget värde anges under distributionen.

Mallfunktionen [resourceGroup()] returnerar ett objekt som innehåller följande nyckel/värde-par:

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

Genom att referera till platsnyckeln för objektet i defaultValue för indataparametern ersätter [resourceGroup().location] Azure Resource Manager vid körning mallfunktionen med namnet på platsen för den resursgrupp som mallen distribueras till.

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

Med den här mallfunktionen kan du distribuera mallen till alla moln utan att ens känna till regionnamnen i förväg. Dessutom kan en plats för en specifik resurs i mallen skilja sig från resursgruppens plats. I det här fallet kan du konfigurera den med hjälp av ytterligare indataparametrar för den specifika resursen, medan de andra resurserna i samma mall fortfarande använder den inledande platsindataparametern.

Spåra versioner med HJÄLP av API-profiler

Det kan vara mycket svårt att hålla reda på alla tillgängliga resursprovidrar och relaterade API-versioner som finns i Azure Stack. I skrivande stund är 2018-04-01till exempel den senaste API-versionen för Microsoft.Compute/availabilitySets i Azure , medan den tillgängliga API-versionen som är gemensam för Azure och Azure Stack är 2016-03-30. Den vanliga API-versionen för Microsoft.Storage/storageAccounts som delas mellan alla Azure- och Azure Stack-platser är 2016-01-01, medan den senaste API-versionen i Azure är 2018-02-01.

Därför introducerade Resource Manager begreppet API-profiler till mallar. Utan API-profiler konfigureras varje resurs i en mall med ett apiVersion element som beskriver API-versionen för den specifika resursen.

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

En API-profilversion fungerar som ett alias för en enda API-version per resurstyp som är gemensam för Azure och Azure Stack. I stället för att ange en API-version för varje resurs i en mall anger du endast API-profilversionen i ett nytt rotelement som heter apiProfile och utelämnar elementet apiVersion för de enskilda resurserna.

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

API-profilen ser till att API-versionerna är tillgängliga på flera platser, så du behöver inte manuellt verifiera de apiVersioner som är tillgängliga på en viss plats. För att säkerställa att API-versionerna som refereras av DIN API-profil finns i en Azure Stack-miljö måste Azure Stack-operatorerna hålla lösningen uppdaterad baserat på principen för support. Om ett system är inaktuellt i mer än sex månader anses det vara inaktuellt och miljön måste uppdateras.

API-profilen är inte ett obligatoriskt element i en mall. Även om du lägger till elementet används det bara för resurser som inget apiVersion har angetts för. Det här elementet tillåter gradvisa ändringar men kräver inga ändringar i befintliga mallar.

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

Kontrollera slutpunktsreferenser

Resurser kan ha referenser till andra tjänster på plattformen. En offentlig IP-adress kan till exempel ha tilldelats ett offentligt DNS-namn. Det offentliga molnet, de nationella molnen och Azure Stack-lösningarna har egna distinkta slutpunktsnamnområden. I de flesta fall kräver en resurs endast ett prefix som indata i mallen. Under körning lägger Azure Resource Manager till slutpunktsvärdet till det. Vissa slutpunktsvärden måste uttryckligen anges i mallen.

Kommentar

Om du vill utveckla mallar för molnkonsekvens ska du inte hårdkoda slutpunktsnamnområden.

Följande två exempel är vanliga slutpunktsnamnområden som uttryckligen måste anges när du skapar en resurs:

• Lagringskonton (blob, kö, tabell och fil)
• Anslutningssträngar för databaser och Azure Cache for Redis

Slutpunktsnamnområden kan också användas i utdata från en mall som information för användaren när distributionen är klar. Följande är vanliga exempel:

• Lagringskonton (blob, kö, tabell och fil)
• Anslutningssträngar (MySql, SQLServer, SQLAzure, Custom, NotificationHub, ServiceBus, EventHub, ApiHub, DocDb, RedisCache, PostgreSQL)
• Traffic Manager
• domainNameLabel för en offentlig IP-adress
• Molntjänster

Undvik i allmänhet hårdkodade slutpunkter i en mall. Det bästa sättet är att använda referensmallfunktionen för att hämta slutpunkterna dynamiskt. Slutpunkten som oftast hårdkodas är till exempel slutpunktsnamnområdet för lagringskonton. Varje lagringskonto har ett unikt FQDN som skapas genom att sammanlänka namnet på lagringskontot med slutpunktsnamnområdet. Ett bloblagringskonto med namnet mystorageaccount1 resulterar i olika FQDN beroende på molnet:

• mystorageaccount1.blob.core.windows.net när det skapas i det globala Azure-molnet.
• mystorageaccount1.blob.core.chinacloudapi.cn när den skapas i Azure som drivs av 21Vianet-molnet.

Följande referensmallsfunktion hämtar slutpunktsnamnområdet från lagringsresursprovidern:

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

Genom att ersätta det hårdkodade värdet för lagringskontots slutpunkt med reference mallfunktionen kan du använda samma mall för att distribuera till olika miljöer utan att göra några ändringar i slutpunktsreferensen.

Se befintliga resurser efter unikt ID

Du kan också referera till en befintlig resurs från samma eller en annan resursgrupp och inom samma prenumeration eller en annan prenumeration inom samma klientorganisation i samma moln. Om du vill hämta resursegenskaperna måste du använda den unika identifieraren för själva resursen. Mallfunktionen resourceId hämtar det unika ID:t för en resurs, till exempel SQL Server, som följande kod visar:

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

Du kan sedan använda resourceId funktionen i reference mallfunktionen för att hämta egenskaperna för en databas. Returobjektet innehåller egenskapen fullyQualifiedDomainName som innehåller det fullständiga slutpunktsvärdet. Det här värdet hämtas vid körning och tillhandahåller molnmiljöspecifikt slutpunktsnamnområde. Om du vill definiera niska veze utan att hårdkoda slutpunktsnamnområdet kan du referera till egenskapen för returobjektet direkt i niska veze enligt följande:

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

Överväg resursegenskaper

Specifika resurser i Azure Stack-miljöer har unika egenskaper som du måste tänka på i mallen.

Se till att VM-avbildningar är tillgängliga

Azure tillhandahåller ett omfattande urval av VM-avbildningar. Dessa avbildningar skapas och förbereds för distribution av Microsoft och partner. Bilderna utgör grunden för virtuella datorer på plattformen. En molnkonsekvent mall bör dock endast referera till tillgängliga parametrar – i synnerhet utgivare, erbjudande och SKU för de VM-avbildningar som är tillgängliga för de globala Azure-, Azure-nationella molnen eller en Azure Stack-lösning.

Om du vill hämta en lista över tillgängliga VM-avbildningar på en plats kör du följande Azure CLI-kommando:

az vm image list -all

Du kan hämta samma lista med Azure PowerShell-cmdleten Get-AzureRmVMImagePublisher och ange den plats som du vill använda med parametern -Location . Till exempel:

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

Det tar några minuter att returnera alla tillgängliga avbildningar i regionen Europa, västra i det globala Azure-molnet.

Om du gjorde dessa VM-avbildningar tillgängliga för Azure Stack skulle all tillgänglig lagring förbrukas. För att hantera även den minsta skalningsenheten kan du med Azure Stack välja de bilder som du vill lägga till i en miljö.

Följande kodexempel visar en konsekvent metod för att referera till parametrarna utgivare, erbjudande och SKU i ARM-mallarna:

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

Kontrollera storlekarna för lokala virtuella datorer

Om du vill utveckla mallen för molnkonsekvens måste du se till att den vm-storlek som du vill ha är tillgänglig i alla målmiljöer. VM-storlekar är en gruppering av prestandaegenskaper och funktioner. Vissa VM-storlekar beror på vilken maskinvara den virtuella datorn körs på. Om du till exempel vill distribuera en GPU-optimerad virtuell dator måste maskinvaran som kör hypervisor-programmet ha maskinvaru-GPU:er.

När Microsoft introducerar en ny storlek på den virtuella datorn som har vissa maskinvaruberoenden görs den virtuella datorns storlek vanligtvis tillgänglig först i en liten delmängd av regioner i Azure-molnet. Senare görs den tillgänglig för andra regioner och moln. För att se till att vm-storleken finns i varje moln som du distribuerar till kan du hämta de tillgängliga storlekarna med följande Azure CLI-kommando:

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

För Azure PowerShell, använd:

Get-AzureRmVMSize -Location "West Europe"

En fullständig lista över tillgängliga tjänster finns i Produkter tillgängliga per region.

Kontrollera användningen av Azure Managed Disks i Azure Stack

Hanterade diskar hanterar lagringen för en Azure-klientorganisation. I stället för att uttryckligen skapa ett lagringskonto och ange URI för en virtuell hårddisk (VHD) kan du använda hanterade diskar för att implicit utföra dessa åtgärder när du distribuerar en virtuell dator. Hanterade diskar förbättrar tillgängligheten genom att placera alla diskar från virtuella datorer i samma tillgänglighetsuppsättning i olika lagringsenheter. Dessutom kan befintliga virtuella hårddiskar konverteras från Standard till Premium-lagring med betydligt mindre stilleståndstid.

Även om hanterade diskar finns med i översikten för Azure Stack stöds de för närvarande inte. Tills de är det kan du utveckla molnkonsekventa mallar för Azure Stack genom att uttryckligen ange virtuella hårddiskar med elementet vhd i mallen för den virtuella datorresursen enligt följande:

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

Om du däremot vill ange en konfiguration av hanterade diskar i en mall tar du bort elementet vhd från diskkonfigurationen.

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

Samma ändringar gäller även datadiskar.

Kontrollera att VM-tillägg är tillgängliga i Azure Stack

Ett annat övervägande för molnkonsekvens är användningen av tillägg för virtuella datorer för att konfigurera resurserna i en virtuell dator. Alla VM-tillägg är inte tillgängliga i Azure Stack. En mall kan ange de resurser som är dedikerade till VM-tillägget och skapa beroenden och villkor i mallen.

Om du till exempel vill konfigurera en virtuell dator som kör Microsoft SQL Server kan VM-tillägget konfigurera SQL Server som en del av malldistributionen. Tänk på vad som händer om distributionsmallen även innehåller en programserver som har konfigurerats för att skapa en databas på den virtuella dator som kör SQL Server. Förutom att använda ett VM-tillägg för programservrarna kan du konfigurera beroendet av programservern vid lyckad retur av SQL Server VM-tilläggsresursen. Den här metoden säkerställer att den virtuella dator som kör SQL Server är konfigurerad och tillgänglig när programservern instrueras att skapa databasen.

Med mallens deklarativa metod kan du definiera sluttillståndet för resurserna och deras beroenden, medan plattformen tar hand om den logik som krävs för beroendena.

Kontrollera att VM-tillägg är tillgängliga

Det finns många typer av VM-tillägg. När du utvecklar mallen för molnkonsekvens bör du bara använda tilläggen som är tillgängliga i alla regioner som mallmålen är.

Om du vill hämta en lista över de VM-tillägg som är tillgängliga för en viss region (i det här exemplet myLocation) kör du följande Azure CLI-kommando:

az vm extension image list --location myLocation

Du kan också köra cmdleten Azure PowerShell Get-AzureRmVmImagePublisher och använda -Location för att ange platsen för den virtuella datorbilden. Till exempel:

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

Kontrollera att versioner är tillgängliga

Eftersom VM-tillägg är Resource Manager-resurser från första part har de egna API-versioner. Som följande kod visar är vm-tilläggstypen en kapslad resurs i Microsoft.Compute-resursprovidern.

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

API-versionen av VM-tilläggsresursen måste finnas på alla platser som du planerar att rikta in dig på med mallen. Platsberoendet fungerar som tillgängligheten för resursproviderns API-version som beskrevs tidigare i avsnittet "Verifiera versionen av alla resurstyper".

Om du vill hämta en lista över tillgängliga API-versioner för VM-tilläggsresursen använder du cmdleten Get-AzureRmResourceProvider med Resursprovidern Microsoft.Compute enligt följande:

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

Du kan också använda VM-tillägg i VM-skalningsuppsättningar. Samma platsvillkor gäller. Om du vill utveckla mallen för molnkonsekvens kontrollerar du att API-versionerna är tillgängliga på alla platser som du planerar att distribuera till. Om du vill hämta API-versionerna av VM-tilläggsresursen för skalningsuppsättningar använder du samma cmdlet som tidigare, men anger resurstypen vm-skalningsuppsättningar enligt följande:

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

Varje specifikt tillägg är också versionshanterat. Den här versionen visas i typeHandlerVersion egenskapen för VM-tillägget. Kontrollera att den version som anges i elementet i mallens typeHandlerVersion VM-tillägg är tillgängliga på de platser där du planerar att distribuera mallen. Följande kod anger till exempel version 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",
        ...

Om du vill hämta en lista över tillgängliga versioner för ett specifikt VM-tillägg använder du cmdleten Get-AzureRmVMExtensionImage . I följande exempel hämtas de tillgängliga versionerna för vm-tillägget PowerShell DSC (Desired State Configuration) från myLocation:

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

Om du vill hämta en lista över utgivare använder du kommandot Get-AzureRmVmImagePublisher . Om du vill begära typ använder du lovordet Get-AzureRmVMExtensionImageType .

Tips för testning och automatisering

Det är en utmaning att hålla reda på alla relaterade inställningar, funktioner och begränsningar när du redigerar en mall. Den vanliga metoden är att utveckla och testa mallar mot ett enda moln innan andra platser riktas in. Men ju tidigare tester som utförs i redigeringsprocessen, desto mindre behöver felsökning och kodskrivning av utvecklingsteamet göra. Distributioner som misslyckas på grund av platsberoenden kan vara tidskrävande att felsöka. Därför rekommenderar vi automatiserad testning så tidigt som möjligt i redigeringscykeln. I slutändan behöver du mindre utvecklingstid och färre resurser, och dina molnkonsekventa artefakter blir ännu mer värdefulla.

Följande bild visar ett typiskt exempel på en utvecklingsprocess för ett team som använder en integrerad utvecklingsmiljö (IDE). I olika steg i tidslinjen körs olika testtyper. Här arbetar två utvecklare med samma lösning, men det här scenariot gäller lika för en enskild utvecklare eller ett stort team. Varje utvecklare skapar vanligtvis en lokal kopia av en central lagringsplats, vilket gör att var och en kan arbeta med den lokala kopian utan att påverka de andra som kanske arbetar med samma filer.

Överväg följande tips för testning och automatisering:

• Använd testverktyg. Visual Studio Code och Visual Studio innehåller till exempel IntelliSense och andra funktioner som kan hjälpa dig att verifiera dina mallar.
• För att förbättra kodkvaliteten under utvecklingen på den lokala IDE:en utför du statisk kodanalys med enhetstester och integreringstester.
• För en ännu bättre upplevelse under den inledande utvecklingen bör enhetstester och integreringstester bara varna när ett problem hittas och fortsätta med testerna. På så sätt kan du identifiera de problem som ska åtgärdas och prioritera ordningen på ändringarna, även kallat testdriven distribution (TDD).
• Tänk på att vissa tester kan utföras utan att vara anslutna till Azure Resource Manager. Andra, som att testa malldistribution, kräver att Resource Manager utför vissa åtgärder som inte kan utföras offline.
• Att testa en distributionsmall mot validerings-API:et är inte lika med en faktisk distribution. Även om du distribuerar en mall från en lokal fil hämtas alla referenser till kapslade mallar i mallen direkt av Resource Manager, och artefakter som refereras till av VM-tillägg hämtas av VM-agenten som körs på den distribuerade virtuella datorn.

Nästa steg

• Överväganden för Azure Resource Manager-mallar
• Metodtips för ARM-mallar