ARM-sablonok fejlesztése a felhők konzisztenciájához

Fontos

A PowerShellből származó Azure-funkció használatához telepíteni kell a modult AzureRM . Ez egy régebbi modul, amely csak a Windows PowerShell 5.1-hez érhető el, és már nem kap új funkciókat. A Az modulok és AzureRM a modulok nem kompatibilisek, ha a PowerShell ugyanazon verzióira vannak telepítve. Ha mindkét verzióra szüksége van:

1. Távolítsa el az Az modult egy PowerShell 5.1-munkamenetből.
2. Telepítse az AzureRM modult egy PowerShell 5.1-munkamenetből.
3. Töltse le és telepítse a PowerShell Core 6.x vagy újabb verzióját.
4. Telepítse az Az modult egy PowerShell Core-munkamenetben.

Az Azure egyik fő előnye a konzisztencia. Az egyik hely fejlesztési beruházásai újra felhasználhatók egy másik helyen. Egy Azure Resource Manager-sablon (ARM-sablon) konzisztenssé és megismételhetővé teszi az üzemelő példányokat a környezetekben, beleértve a globális Azure-t, az Azure szuverén felhőit és az Azure Stacket. A sablonok felhők közötti újrafelhasználásához azonban figyelembe kell vennie a felhőspecifikus függőségeket az útmutatóban leírtak szerint.

A Microsoft számos helyen kínál intelligens, nagyvállalati használatra kész felhőszolgáltatásokat, többek között az alábbiakat:

• A globális Azure-platformot a Microsoft által felügyelt adatközpontok egyre növekvő hálózata támogatja a világ különböző régióiban.
• A 21Vianet által üzemeltetett elkülönített szuverén felhők, például az Azure Germany, az Azure Government és a Microsoft Azure. A szuverén felhők konzisztens platformot biztosítanak a globális Azure-ügyfelek számára elérhető legtöbb nagyszerű funkcióval.
• Az Azure Stack egy hibrid felhőplatform, amellyel Azure-szolgáltatásokat biztosíthat a szervezet adatközpontjából. A nagyvállalatok saját adatközpontjaikban állíthatják be az Azure Stacket, vagy használhatják a szolgáltatókTól származó Azure-szolgáltatásokat, és az Azure Stacket a létesítményeikben (más néven üzemeltetett régiókban) futtathatják.

Ezeknek a felhőknek a középpontjában az Azure Resource Manager egy OLYAN API-t biztosít, amellyel számos felhasználói felület kommunikálhat az Azure-platformmal. Ez az API hatékony, kódként nyújtott infrastruktúra-képességeket biztosít. Az Azure-felhőplatformon elérhető bármilyen típusú erőforrás üzembe helyezhető és konfigurálható az Azure Resource Managerrel. Egyetlen sablonnal üzembe helyezheti és konfigurálhatja a teljes alkalmazást működési végállapotba.

A globális Azure, a szuverén felhők, az üzemeltetett felhők és az adatközpontban lévő felhők konzisztenciája segít az Azure Resource Manager előnyeinek kihasználásában. A sablonalapú erőforrás-telepítés és -konfiguráció beállításakor felhasználhatja a fejlesztési beruházásokat ezeken a felhőkön.

Annak ellenére azonban, hogy a globális, szuverén, üzemeltetett és hibrid felhők konzisztens szolgáltatásokat nyújtanak, nem minden felhő azonos. Ennek eredményeképpen létrehozhat egy sablont, amely csak egy adott felhőben elérhető funkcióktól függ.

Az útmutató további része azokat a területeket ismerteti, amelyeket figyelembe kell venni az Azure Stack új vagy meglévő ARM-sablonjainak fejlesztésekor. Az ellenőrzőlistának általában a következő elemeket kell tartalmaznia:

• Ellenőrizze, hogy a sablonban található függvények, végpontok, szolgáltatások és egyéb erőforrások elérhetők-e a céltelepítési helyeken.
• Beágyazott sablonokat és konfigurációs összetevőket akadálymentes helyeken tárol, biztosítva a felhők közötti hozzáférést.
• Használjon dinamikus hivatkozásokat a kemény kódolású hivatkozások és elemek helyett.
• Győződjön meg arról, hogy a sablonparaméterek a célfelhőkben működnek.
• Ellenőrizze, hogy az erőforrás-specifikus tulajdonságok elérhetők-e a célfelhőkben.

Az ARM-sablonokról a sablon üzembe helyezéséről olvashat.

A sablonfüggvények működésének biztosítása

Az ARM-sablon alapszintaxisa a JSON. A sablonok a JSON egy szuperhalmazát használják, amely kifejezésekkel és függvényekkel bővíti a szintaxist. A sablonnyelv-feldolgozó gyakran frissül a további sablonfüggvények támogatásához. Az elérhető sablonfüggvények részletes ismertetését az ARM-sablonfüggvények között találja.

Az Azure Resource Managerben bevezetett új sablonfüggvények nem érhetők el azonnal a szuverén felhőkben vagy az Azure Stackben. A sablon sikeres üzembe helyezéséhez a sablonban hivatkozott összes függvénynek elérhetőnek kell lennie a célfelhőben.

Az Azure Resource Manager képességei mindig először a globális Azure-ban lesznek bevezetve. Az alábbi PowerShell-szkripttel ellenőrizheti, hogy az újonnan bevezetett sablonfüggvények elérhetők-e az Azure Stackben is:

1. A GitHub-adattár klónozása: https://github.com/marcvaneijk/arm-template-functions.

2. Miután rendelkezik az adattár helyi klónjával, csatlakozzon a cél Azure Resource Manageréhez a PowerShell-lel.

3. Importálja a psm1 modult, és hajtsa végre a Test-AzureRmTemplateFunctions parancsmagot:

   # Import the module
   Import-module <path to local clone>\AzTemplateFunctions.psm1
   
   # Execute the Test-AzureRmTemplateFunctions cmdlet
   Test-AzureRmTemplateFunctions -path <path to local clone>
   

A szkript több, kisméretű sablont helyez üzembe, amelyek mindegyike csak egyedi sablonfüggvényeket tartalmaz. A szkript kimenete a támogatott és nem elérhető sablonfüggvényeket jelenti.

Csatolt összetevők használata

A sablonok hivatkozásokat tartalmazhatnak a csatolt összetevőkre, és tartalmazhatnak egy üzembehelyezési erőforrást, amely egy másik sablonra hivatkozik. A csatolt sablonokat (más néven beágyazott sablonokat) a Resource Manager futásidőben kéri le. A sablonok virtuálisgép-bővítmények összetevőire mutató hivatkozásokat is tartalmazhatnak. Ezeket az összetevőket a virtuális gépen belül futó virtuálisgép-bővítmény kéri le a virtuálisgép-bővítmény konfigurálásához a sablon üzembe helyezése során.

A következő szakaszok a felhőkonzisztenciával kapcsolatos szempontokat ismertetik a fő üzembehelyezési sablonon kívüli összetevőket tartalmazó sablonok fejlesztésekor.

Beágyazott sablonok használata régiók között

A sablonok kis, újrafelhasználható sablonokra bonthatók, amelyek mindegyike meghatározott céllal rendelkezik, és az üzembe helyezési forgatókönyvek során újra felhasználható. Az üzembe helyezés végrehajtásához egyetlen sablont kell megadnia, más néven fő vagy fő sablont. Meghatározza az üzembe helyezendő erőforrásokat, például a virtuális hálózatokat, a virtuális gépeket és a webalkalmazásokat. A fő sablon egy másik sablonra mutató hivatkozást is tartalmazhat, ami azt jelenti, hogy sablonokat ágyazhat be. Hasonlóképpen, a beágyazott sablonok más sablonokra mutató hivatkozásokat is tartalmazhatnak. Legfeljebb öt szint mélyre fészkelhet.

Az alábbi kód bemutatja, hogy a templateLink paraméter hogyan hivatkozik beágyazott sablonra:

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

Az Azure Resource Manager futásidőben kiértékeli a fő sablont, és lekéri és kiértékeli az egyes beágyazott sablonokat. Az összes beágyazott sablon lekérése után a sablon összesimul, és a rendszer további feldolgozást kezdeményez.

Csatolt sablonok akadálymentesítése felhőkben

Gondolja át, hol és hogyan tárolhatja a használt csatolt sablonokat. Futásidőben az Azure Resource Manager lekéri a csatolt sablonokat, ezért közvetlen hozzáférést igényel. Gyakori eljárás, hogy a GitHub használatával tárolja a beágyazott sablonokat. A GitHub-adattárak url-címen keresztül nyilvánosan elérhető fájlokat tartalmazhatnak. Bár ez a technika jól működik a nyilvános felhő és a szuverén felhők esetében, előfordulhat, hogy egy Azure Stack-környezet egy vállalati hálózaton vagy egy leválasztott távoli helyen található, kimenő internet-hozzáférés nélkül. Ezekben az esetekben az Azure Resource Manager nem tudja lekérni a beágyazott sablonokat.

A felhők közötti üzemelő példányok jobb gyakorlata, ha a csatolt sablonokat a célfelhő számára elérhető helyen tárolja. Ideális esetben az összes üzembehelyezési összetevő megmarad és üzembe helyezhető egy folyamatos integrációs/folyamatos fejlesztési (CI/CD) folyamatból. Másik lehetőségként beágyazott sablonokat is tárolhat egy blobtárolóban, amelyből az Azure Resource Manager lekérheti őket.

Mivel az egyes felhők blobtárolója egy másik végpont teljes tartománynevet (FQDN) használ, konfigurálja a sablont a csatolt sablonok helyével két paraméterrel. A paraméterek az üzembe helyezéskor fogadhatják el a felhasználói bemenetet. A sablonokat általában többen készítik és osztják meg, ezért ajánlott szabványos nevet használni ezekhez a paraméterekhez. Az elnevezési konvenciók segítenek a sablonok régiók, felhők és szerzők közötti újrafelhasználhatóságában.

Az alábbi kódban _artifactsLocation egyetlen helyre mutatunk, amely az összes üzembe helyezéssel kapcsolatos összetevőt tartalmazza. Figyelje meg, hogy egy alapértelmezett érték van megadva. Üzembe helyezéskor, ha nincs megadva _artifactsLocationbemeneti érték, a rendszer az alapértelmezett értéket használja. A _artifactsLocationSasToken rendszer bemenetként használja a sasToken. Az alapértelmezett értéknek egy üres sztringnek kell lennie olyan forgatókönyvek esetében, ahol nincs biztosítva a _artifactsLocation védelem – például egy nyilvános GitHub-adattár.

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

A sablonban a hivatkozások úgy jönnek létre, hogy az alap URI -t (a _artifactsLocation paraméterből) kombinálják egy összetevő relatív elérési útjával és a _artifactsLocationSasToken. Az alábbi kód bemutatja, hogyan adhatja meg a beágyazott sablonra mutató hivatkozást az uri sablonfüggvény használatával:

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

Ezzel a módszerrel a paraméter alapértelmezett értékét _artifactsLocation használja a rendszer. Ha a csatolt sablonokat más helyről kell lekérni, a paraméter bemenete az üzembe helyezéskor használható az alapértelmezett érték felülbírálásához – nincs szükség a sablon módosítására.

A _artifactsLocation használata hardcoding hivatkozások helyett

A beágyazott sablonok használata mellett a _artifactsLocation paraméter URL-címe is alapul szolgál az üzembehelyezési sablon összes kapcsolódó összetevőjéhez. Egyes virtuálisgép-bővítmények a sablonon kívül tárolt parancsfájlra mutató hivatkozást tartalmaznak. Ezekben a bővítményekben nem szabad a hivatkozásokat keményen kódolni. Az egyéni szkript és a PowerShell DSC-bővítmények például egy külső szkriptre hivatkozhatnak a GitHubon az alábbi módon:

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

A szkriptre mutató hivatkozások megkettőzésével megakadályozhatja, hogy a sablon sikeresen üzembe legyen helyezve egy másik helyen. A virtuálisgép-erőforrás konfigurálása során a virtuális gépen futó virtuálisgép-ügynök kezdeményezi a virtuálisgép-bővítményben csatolt szkriptek letöltését, majd tárolja a szkripteket a virtuális gép helyi lemezén. Ez a megközelítés a "Beágyazott sablonok használata régiók között" című szakaszban ismertetett beágyazott sablonhivatkozásokhoz hasonlóan működik.

A Resource Manager futásidőben kéri le a beágyazott sablonokat. A virtuálisgép-bővítmények esetében a külső összetevők lekérését a virtuálisgép-ügynök végzi. Az összetevő lekérésének különböző kezdeményezője mellett a sablondefinícióban lévő megoldás ugyanaz. Használja a _artifactsLocation paramétert annak az alapútvonalnak az alapértelmezett értékével, amelyben az összes összetevőt tárolja (beleértve a virtuálisgép-bővítményszkripteket) és a _artifactsLocationSasToken sasToken bemenetének paraméterét.

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

Egy összetevő abszolút URI-jának létrehozásához az előnyben részesített módszer az uri sablonfüggvény használata az összefűző sablonfüggvény helyett. Ha a virtuálisgép-bővítmény szkriptjeire mutató, kemény kóddal ellátott hivatkozásokat az uri sablonfüggvényre cseréli, ez a funkció a sablonban a felhőkonzisztenciához van konfigurálva.

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

Ezzel a módszerrel az összes üzembehelyezési összetevő, beleértve a konfigurációs szkripteket is, ugyanazon a helyen tárolható a sablonnal együtt. Az összes hivatkozás helyének módosításához csak egy másik alap URL-címet kell megadnia az artifactsLocation paraméterekhez.

Eltérő regionális képességek tényezője

Az Azure-ban bevezetett agilis fejlesztéssel és folyamatos frissítési folyamattal és új szolgáltatásokkal a régiók eltérőek lehetnek a szolgáltatások vagy frissítések rendelkezésre állásában. A szigorú belső tesztelést követően az érvényesítési programban részt vevő ügyfelek kis csoportja általában új szolgáltatásokat vagy meglévő szolgáltatások frissítéseit vezeti be. Az ügyfelek sikeres érvényesítése után a szolgáltatások vagy frissítések elérhetővé válnak az Azure-régiók egy részhalmazában, majd több régióban vezetik be, bevezetik a szuverén felhőkbe, és potenciálisan elérhetővé válnak az Azure Stack-ügyfelek számára is.

Tudva, hogy az Azure-régiók és a felhők eltérőek lehetnek az elérhető szolgáltatásaikban, proaktív döntéseket hozhat a sablonokkal kapcsolatban. Első lépésként érdemes megvizsgálni a felhőhöz elérhető erőforrás-szolgáltatókat. Az erőforrás-szolgáltató ismerteti az Azure-szolgáltatásokhoz elérhető erőforrásokat és műveleteket.

Egy sablon üzembe helyezi és konfigurálja az erőforrásokat. Egy erőforrástípust egy erőforrás-szolgáltató biztosít. A számítási erőforrás-szolgáltató (Microsoft.Compute) például több erőforrástípust is biztosít, például virtualMachines és availabilitySets. Minden erőforrás-szolgáltató biztosít egy API-t az Azure Resource Managerhez, amelyet egy közös szerződés határoz meg, így egységes, egységes szerzői élményt biztosít az összes erőforrás-szolgáltató számára. Előfordulhat azonban, hogy a globális Azure-ban elérhető erőforrás-szolgáltató nem érhető el szuverén felhőben vagy Azure Stack-régióban.

Az adott felhőben elérhető erőforrás-szolgáltatók ellenőrzéséhez futtassa a következő szkriptet az Azure CLI-ben:

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

A következő PowerShell-parancsmaggal is megtekintheti az elérhető erőforrás-szolgáltatókat:

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

Az összes erőforrástípus verziójának ellenőrzése

A tulajdonságok halmaza minden erőforrástípus esetében gyakori, de mindegyik erőforrás saját adott tulajdonságokkal is rendelkezik. Az új funkciók és a kapcsolódó tulajdonságok időnként új API-verzióval lesznek hozzáadva a meglévő erőforrástípusokhoz. A sablonban lévő erőforrások saját API-verziótulajdonságsal rendelkeznek – apiVersion. Ez a verziószámozás biztosítja, hogy a sablon meglévő erőforrás-konfigurációját ne befolyásolják a platform változásai.

Előfordulhat, hogy a globális Azure-ban a meglévő erőforrástípusokhoz bevezetett új API-verziók nem lesznek azonnal elérhetők minden régióban, szuverén felhőben vagy az Azure Stackben. A felhőben elérhető erőforrás-szolgáltatók, erőforrástípusok és API-verziók listájának megtekintéséhez használhatja a Resource Explorert az Azure Portalon. Keresse meg az Erőforrás-kezelőt a Minden szolgáltatás menüben. Bontsa ki a Szolgáltatók csomópontot a Resource Explorerben az összes elérhető erőforrás-szolgáltató, erőforrástípus és API-verzió visszaadásához a felhőben.

Az Azure CLI-ben egy adott felhőben található összes erőforrástípushoz elérhető API-verzió listázásához futtassa a következő szkriptet:

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

A következő PowerShell-parancsmagot is használhatja:

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

Tekintse meg a paraméterrel rendelkező erőforráshelyeket

A sablonokat mindig egy régióban található erőforráscsoportba helyezik üzembe. Az üzembe helyezés mellett a sablon minden erőforrása rendelkezik egy helytulajdonságokkal is, amelyekkel megadhatja a régiót, amelyben üzembe helyezhető. A felhőkonzisztencia sablonjának fejlesztéséhez dinamikusan kell hivatkoznia az erőforrás-helyekre, mivel minden Azure Stack egyedi helyneveket tartalmazhat. Az erőforrások általában ugyanabban a régióban vannak üzembe helyezve, mint az erőforráscsoport, de az olyan forgatókönyvek támogatásához, mint például a régiók közötti alkalmazás rendelkezésre állása, hasznos lehet az erőforrások régiók közötti elterjesztése.

Annak ellenére, hogy egy sablon erőforrás-tulajdonságainak megadásakor a régióneveket meg tudta határozni, ez a módszer nem garantálja, hogy a sablon más Azure Stack-környezetekben is üzembe helyezhető, mivel a régió neve valószínűleg nem létezik ott.

A különböző régiók elhelyezéséhez adjon hozzá egy bemeneti paraméter helyét a sablonhoz egy alapértelmezett értékkel. Az alapértelmezett érték akkor lesz használva, ha az üzembe helyezés során nincs megadva érték.

A sablonfüggvény [resourceGroup()] egy objektumot ad vissza, amely a következő kulcs-érték párokat tartalmazza:

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

Ha az objektum helykulcsára hivatkozik a bemeneti paraméter defaultValue elemében, az Azure Resource Manager futásidőben lecseréli a [resourceGroup().location] sablonfüggvényt annak az erőforráscsoportnak a nevére, amelyre a sablon telepítve van.

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

Ezzel a sablonfüggvénnyel bármilyen felhőben üzembe helyezheti a sablont anélkül, hogy előre ismerné a régióneveket. Emellett egy adott erőforrás helye a sablonban eltérhet az erőforráscsoport helyétől. Ebben az esetben konfigurálhatja az adott erőforráshoz tartozó további bemeneti paraméterekkel, míg az ugyanabban a sablonban lévő többi erőforrás továbbra is a kezdeti hely bemeneti paraméterét használja.

Verziók nyomon követése API-profilokkal

Nagyon nehéz lehet nyomon követni az Azure Stackben található összes elérhető erőforrás-szolgáltatót és kapcsolódó API-verziót. Az íráskor például a Microsoft.Compute/availabilitySets legújabb API-verziója az 2018-04-01Azure-ban, míg az Azure-ban és az Azure Stackben 2016-03-30gyakran használt API-verzió. A Microsoft.Storage/StorageAccounts általános API-verziója az összes Azure- és Azure Stack-hely között megosztva, 2016-01-01míg az Azure legújabb API-verziója.2018-02-01

Ezért a Resource Manager bevezette az API-profilok fogalmát a sablonokba. API-profilok nélkül a sablon minden erőforrása egy apiVersion olyan elemet tartalmaz, amely leírja az adott erőforrás API-verzióját.

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

Az API-profilok verziója az Azure-ban és az Azure Stackben gyakran használt erőforrástípusonként egyetlen API-verzió aliasaként működik. Ahelyett, hogy api-verziót adná meg egy sablon minden erőforrásához, csak az API-profil verzióját kell megadnia egy új gyökérelemben, amelyet meghív, apiProfile és kihagyja az apiVersion egyes erőforrások elemét.

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

Az API-profil biztosítja, hogy az API-verziók elérhetőek legyenek a különböző helyeken, így nem kell manuálisan ellenőriznie az adott helyen elérhető apiVersion-okat. Ahhoz, hogy az API-profil által hivatkozott API-verziók megjelenjenek egy Azure Stack-környezetben, az Azure Stack-operátoroknak naprakészen kell tartaniuk a megoldást a támogatási szabályzat alapján. Ha egy rendszer több mint hat hónappal elavult, akkor a rendszer nem megfelelőnek minősül, és a környezetet frissíteni kell.

Az API-profil nem kötelező elem a sablonban. Még ha hozzáadja is az elemet, az csak olyan erőforrásokhoz lesz felhasználva, amelyekhez nincs apiVersion megadva. Ez az elem lehetővé teszi a fokozatos módosításokat, de nem igényel módosításokat a meglévő sablonokon.

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

Végponthivatkozások ellenőrzése

Az erőforrások hivatkozhatnak más szolgáltatásokra a platformon. Egy nyilvános IP-címhez például nyilvános DNS-név rendelhető. A nyilvános felhő, a szuverén felhők és az Azure Stack-megoldások saját különálló végpontnévterekkel rendelkeznek. Az erőforrások legtöbb esetben csak előtagot igényelnek bemenetként a sablonban. Futásidőben az Azure Resource Manager hozzáfűzi a végpont értékét. Bizonyos végpontértékeket explicit módon kell megadni a sablonban.

Feljegyzés

A felhők konzisztenciáját szolgáló sablonok fejlesztéséhez ne kódolja a végpontok névtereit.

Az alábbi két példa olyan gyakori végpontnévtereket mutat be, amelyeket explicit módon kell megadni egy erőforrás létrehozásakor:

• Tárfiókok (blob, üzenetsor, tábla és fájl)
• Kapcsolati sztringek adatbázisokhoz és Azure Cache for Redishez

A végpontnévterek a sablon kimenetében is használhatók információként a felhasználó számára az üzembe helyezés befejezésekor. A következő gyakori példák:

• Tárfiókok (blob, üzenetsor, tábla és fájl)
• Kapcsolati sztringek (MySql, SQLServer, SQLAzure, Custom, NotificationHub, ServiceBus, EventHub, ApiHub, DocDb, RedisCache, PostgreSQL)
• Traffic Manager
• domainNameLabel nyilvános IP-címhez
• Felhőszolgáltatások

Általában kerülje a sablonban a merevlemezes végpontokat. Az ajánlott eljárás a referenciasablon függvény használata a végpontok dinamikus lekéréséhez. A leggyakrabban rögzített végpont például a tárfiókok végpontnévtere. Minden tárfiók egyedi teljes tartománynévvel rendelkezik, amely a tárfiók nevének és a végpontnévtér összefűzésével jön létre. A mystorageaccount1 nevű Blob Storage-fiók a felhőtől függően különböző teljes tartományneveket eredményez:

• mystorageaccount1.blob.core.windows.net a globális Azure-felhőben való létrehozásakor.
• mystorageaccount1.blob.core.chinacloudapi.cn amikor a 21Vianet-felhő által üzemeltetett Azure-ban jön létre.

A következő referenciasablonfüggvény lekéri a végpontnévteret a tárolóerőforrás-szolgáltatótól:

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

Ha lecseréli a tárfiókvégpont merevlemezes értékét a reference sablonfüggvényre, ugyanazt a sablont használhatja a különböző környezetekben való sikeres üzembe helyezéshez anélkül, hogy módosítanák a végponthivatkozást.

Meglévő erőforrások hivatkozása egyedi azonosító alapján

Hivatkozhat egy meglévő erőforrásra ugyanabból vagy egy másik erőforráscsoportból, valamint ugyanazon előfizetésből vagy egy másik előfizetésből, ugyanazon a felhőbeli bérlőn belül. Az erőforrás tulajdonságainak lekéréséhez magának az erőforrásnak az egyedi azonosítót kell használnia. A resourceId sablonfüggvény lekéri egy erőforrás egyedi azonosítóját, például az SQL Servert, ahogy az alábbi kód mutatja:

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

Ezután a resourceId sablonfüggvényen belüli reference függvény használatával lekérheti az adatbázis tulajdonságait. A visszatérési objektum a fullyQualifiedDomainName teljes végpont értékét tartalmazó tulajdonságot tartalmazza. Ez az érték futásidőben lesz lekérve, és biztosítja a felhőkörnyezetre jellemző végpontnévteret. Ha úgy szeretné definiálni a kapcsolati sztring, hogy nem kell a végpontnévteret bekonfigurálnia, a visszatérési objektum tulajdonságára közvetlenül a kapcsolati sztring hivatkozhat az ábrán látható módon:

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

Erőforrástulajdonságok figyelembe vévee

Az Azure Stack-környezetekben lévő egyes erőforrások egyedi tulajdonságokkal rendelkeznek, amelyeket figyelembe kell vennie a sablonban.

Győződjön meg arról, hogy a virtuálisgép-rendszerképek elérhetők

Az Azure számos virtuálisgép-rendszerképet kínál. Ezeket a rendszerképeket a Microsoft és a partnerek hozzák létre és készítik elő az üzembe helyezéshez. A képek alkotják a platformon lévő virtuális gépek alapját. A felhőkonzisztens sablonnak azonban csak a rendelkezésre álló paraméterekre kell hivatkoznia – különösen a globális Azure, az Azure szuverén felhők vagy egy Azure Stack-megoldás számára elérhető virtuálisgép-rendszerképek közzétevője, ajánlata és termékváltozata.

Az elérhető virtuálisgép-rendszerképek listájának lekéréséhez futtassa a következő Azure CLI-parancsot:

az vm image list -all

Ugyanezt a listát lekérheti a Get-AzureRmVMImagePublisher Azure PowerShell-parancsmaggal, és megadhatja a paraméterrel -Location a kívánt helyet. Példa:

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

Ez a parancs néhány percet vesz igénybe a globális Azure-felhő nyugat-európai régiójában elérhető összes kép visszaadásához.

Ha ezeket a virtuálisgép-rendszerképeket elérhetővé tette az Azure Stack számára, a rendszer az összes rendelkezésre álló tárterületet felhasználja. A legkisebb méretezési egység elhelyezéséhez az Azure Stack lehetővé teszi a környezethez hozzáadni kívánt rendszerképek kiválasztását.

Az alábbi kódminta konzisztens megközelítést mutat be az ARM-sablonok közzétevői, ajánlati és termékváltozat-paramétereire való hivatkozáshoz:

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

Helyi virtuálisgép-méretek ellenőrzése

A felhőkonzisztencia sablonjának fejlesztéséhez meg kell győződnie arról, hogy a kívánt virtuálisgép-méret minden célkörnyezetben elérhető. A virtuálisgép-méretek a teljesítmény jellemzőinek és képességeinek csoportosítását képezik. Egyes virtuális gépek mérete a virtuális gép által futtatott hardvertől függ. Ha például GPU-ra optimalizált virtuális gépet szeretne üzembe helyezni, a hipervizort futtató hardvernek rendelkeznie kell a hardver GPU-kkal.

Amikor a Microsoft olyan új méretű virtuális gépet vezet be, amely bizonyos hardverfüggőségekkel rendelkezik, a virtuális gép mérete általában először elérhetővé válik az Azure-felhő régióinak egy kis részhalmazában. Később más régiókban és felhőkben is elérhetővé válik. Ha meg szeretné győződni arról, hogy a virtuális gép mérete minden egyes üzembe helyezett felhőben létezik, az alábbi Azure CLI-paranccsal lekérheti az elérhető méreteket:

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

Azure PowerShell esetén használja a következőt:

Get-AzureRmVMSize -Location "West Europe"

Az elérhető szolgáltatások teljes listájáért tekintse meg a régiónként elérhető termékeket.

Az Azure Managed Disks használatának ellenőrzése az Azure Stackben

A felügyelt lemezek kezelik az Azure-bérlők tárhelyét. Ahelyett, hogy explicit módon hoz létre tárfiókot, és megadja egy virtuális merevlemez (VHD) URI-ját, felügyelt lemezek használatával implicit módon hajthatja végre ezeket a műveleteket a virtuális gépek üzembe helyezésekor. A felügyelt lemezek úgy növelik a rendelkezésre állást, hogy a virtuális gépekről származó összes lemezt ugyanabban a rendelkezésre állási csoportban helyezik el különböző tárolóegységekbe. Emellett a meglévő virtuális merevlemezek standardról prémium szintű tárolóvá alakíthatók, lényegesen kevesebb állásidővel.

Bár a felügyelt lemezek az Azure Stack ütemtervében szerepelnek, jelenleg nem támogatottak. Amíg nem lesznek, az Azure Stack felhőkonzisztens sablonjait úgy fejlesztheti ki, hogy explicit módon megadja a virtuális merevlemezeket a vhd virtuálisgép-erőforrás sablonjának elemével, az ábrán látható módon:

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

Ezzel szemben a felügyelt lemezkonfiguráció sablonban való megadásához távolítsa el az elemet a vhd lemezkonfigurációból.

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

Ugyanezek a módosítások adatlemezeket is alkalmaznak.

Ellenőrizze, hogy a virtuálisgép-bővítmények elérhetők-e az Azure Stackben

A felhőkonzisztencia másik szempontja a virtuálisgép-bővítmények használata a virtuális gépen belüli erőforrások konfigurálásához. Nem minden virtuálisgép-bővítmény érhető el az Azure Stackben. Egy sablon megadhatja a virtuálisgép-bővítményhez dedikált erőforrásokat, és függőségeket és feltételeket hozhat létre a sablonon belül.

Ha például egy Microsoft SQL Servert futtató virtuális gépet szeretne konfigurálni, a virtuálisgép-bővítmény konfigurálhatja az SQL Servert a sablontelepítés részeként. Gondolja át, mi történik, ha az üzembehelyezési sablon tartalmaz egy, az SQL Servert futtató virtuális gépen adatbázis létrehozására konfigurált alkalmazáskiszolgálót is. Amellett, hogy az alkalmazáskiszolgálókhoz virtuálisgép-bővítményt is használ, konfigurálhatja az alkalmazáskiszolgáló függőségét az SQL Server virtuálisgép-bővítmény erőforrásának sikeres visszatéréséhez. Ez a megközelítés biztosítja, hogy az SQL Servert futtató virtuális gép konfigurálva legyen és elérhető legyen, amikor az alkalmazáskiszolgálót arra utasítják, hogy hozza létre az adatbázist.

A sablon deklaratív megközelítése lehetővé teszi az erőforrások és azok függőségek közötti állapotának meghatározását, míg a platform gondoskodik a függőségekhez szükséges logikáról.

Ellenőrizze, hogy elérhetők-e virtuálisgép-bővítmények

Számos virtuálisgép-bővítmény létezik. A felhőkonzisztenciához készült sablon fejlesztésekor ügyeljen arra, hogy csak azokat a bővítményeket használja, amelyek a sablon által célként megadott összes régióban elérhetők.

Egy adott régióhoz elérhető virtuálisgép-bővítmények listájának lekéréséhez (ebben a példában myLocation) futtassa a következő Azure CLI-parancsot:

az vm extension image list --location myLocation

Az Azure PowerShell Get-AzureRmVmImagePublisher parancsmagot is végrehajthatja, és -Location megadhatja a virtuális gép lemezképének helyét. Példa:

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

Győződjön meg arról, hogy a verziók elérhetők

Mivel a virtuálisgép-bővítmények belső Resource Manager-erőforrások, saját API-verziókkal rendelkeznek. Ahogy az alábbi kód is mutatja, a virtuálisgép-bővítmény típusa beágyazott erőforrás a Microsoft.Compute erőforrás-szolgáltatóban.

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

A virtuálisgép-bővítményerőforrás API-verziójának jelen kell lennie a sablonnal megcélzott összes helyen. A helyfüggőség úgy működik, mint az erőforrás-szolgáltató API-verziójának rendelkezésre állása, amelyet korábban az "Összes erőforrástípus verziójának ellenőrzése" című szakaszban tárgyaltak.

A virtuálisgép-bővítményerőforráshoz elérhető API-verziók listájának lekéréséhez használja a Get-AzureRmResourceProvider parancsmagot a Microsoft.Compute erőforrás-szolgáltatóval az alábbi módon:

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

Virtuálisgép-bővítményeket virtuálisgép-méretezési csoportokban is használhat. Ugyanezek a helyfeltételek érvényesek. A felhőkonzisztenciához készült sablon fejlesztéséhez győződjön meg arról, hogy az API-verziók minden olyan helyen elérhetők, ahol üzembe kíván helyezni. Ha le szeretné kérni a virtuálisgép-bővítmény erőforrásának API-verzióit a méretezési csoportokhoz, használja ugyanazt a parancsmagot, mint korábban, de adja meg a virtuálisgép-méretezési csoportok erőforrástípusát az alábbi módon:

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

Az egyes bővítmények is verziószámozottak. Ez a verzió a typeHandlerVersion virtuálisgép-bővítmény tulajdonságában jelenik meg. Győződjön meg arról, hogy a typeHandlerVersion sablon virtuálisgép-bővítményeinek elemében megadott verzió elérhető azokban a helyeken, ahol üzembe szeretné helyezni a sablont. A következő kód például az 1.7-es verziót adja meg:

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

Ha le szeretné kérni egy adott virtuálisgép-bővítmény elérhető verzióinak listáját, használja a Get-AzureRmVMExtensionImage parancsmagot. Az alábbi példa lekéri a PowerShell DSC (Desired State Configuration) virtuálisgép-bővítmény elérhető verzióit a myLocation-ból:

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

A közzétevők listájának lekéréséhez használja a Get-AzureRmVmImagePublisher parancsot. Típus kéréséhez használja a Get-AzureRmVMExtensionImageType dicséretet.

Tippek teszteléshez és automatizáláshoz

Kihívást jelent az összes kapcsolódó beállítás, képesség és korlátozás nyomon követése sablon készítése közben. A gyakori megközelítés az, hogy sablonokat fejlesztünk és tesztelünk egyetlen felhőn, mielőtt más helyeket célozunk meg. Azonban minél korábban végeznek teszteket a szerzői folyamatban, annál kevesebb hibaelhárítást és kódírást kell elvégeznie a fejlesztői csapatnak. A helyfüggőségek miatt meghiúsult üzemelő példányok hibaelhárítása időigényes lehet. Ezért javasoljuk, hogy a lehető leghamarabb automatizált tesztelést végezzünk a szerzői ciklusban. Végső soron kevesebb fejlesztési időre és kevesebb erőforrásra lesz szüksége, és a felhőkonzisztens összetevők még értékesebbek lesznek.

Az alábbi képen egy tipikus példa látható egy integrált fejlesztési környezetet (IDE) használó csapat fejlesztési folyamatára. Az ütemterv különböző szakaszaiban a rendszer különböző teszttípusokat hajt végre. Itt két fejlesztő dolgozik ugyanazon a megoldáson, de ez a forgatókönyv egyformán vonatkozik egyetlen fejlesztőre vagy egy nagy csapatra. Minden fejlesztő általában egy központi adattár helyi másolatát hozza létre, amely lehetővé teszi, hogy mindegyik a helyi másolaton dolgozzon anélkül, hogy hatással lenne a többire, akik ugyanazon a fájlon dolgoznak.

Tekintse meg az alábbi tippeket a teszteléshez és az automatizáláshoz:

• Használjon tesztelési eszközöket. A Visual Studio Code és a Visual Studio például tartalmazza az IntelliSense-t és más funkciókat, amelyek segíthetnek a sablonok ellenőrzésében.
• A helyi IDE-n végzett fejlesztés során a kódminőség javítása érdekében végezzen statikus kódelemzést egységtesztekkel és integrációs tesztekkel.
• A kezdeti fejlesztés során még jobb élmény érdekében az egységtesztek és az integrációs tesztek csak akkor figyelmeztetnek, ha probléma merül fel, és folytassa a teszteket. Így azonosíthatja a megoldandó problémákat, és rangsorolhatja a módosítások sorrendjét, más néven tesztalapú üzembe helyezést (TDD).
• Vegye figyelembe, hogy egyes tesztek az Azure Resource Managerhez való csatlakozás nélkül is elvégezhetők. Mások, például a sablon üzembe helyezésének tesztelése megkövetelik, hogy a Resource Manager bizonyos, offline módban nem végrehajtható műveleteket hajt végre.
• Az üzembehelyezési sablon tesztelése az érvényesítési API-val nem egyenlő a tényleges üzembe helyezéssel. Emellett még ha helyi fájlból is üzembe helyez egy sablont, a sablonban lévő beágyazott sablonokra mutató hivatkozásokat közvetlenül a Resource Manager kéri le, és a virtuálisgép-bővítmények által hivatkozott összetevőket az üzembe helyezett virtuális gépen futó virtuálisgép-ügynök kéri le.

Következő lépések

• Azure Resource Manager-sablonokkal kapcsolatos szempontok
• Ajánlott eljárások ARM-sablonokhoz