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

Cikk
03/20/2024

Fontos

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

Távolítsa el az Az modult egy PowerShell 5.1-munkamenetből.
Telepítse az AzureRM modult egy PowerShell 5.1-munkamenetből.
Töltse le és telepítse a PowerShell Core 6.x vagy újabb verzióját.
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. Az Azure Resource Manager-sablon (ARM-sablon) konzisztenssé és megismételhetővé teszi az üzemelő példányokat a különböző 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 intelligens, nagyvállalati használatra kész felhőszolgáltatásokat kínál számos helyen, 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, a Azure Government és a Microsoft Azure. A szuverén felhők egységes platformot biztosítanak a legtöbb olyan nagyszerű funkcióval, amelyhez a globális Azure-ügyfelek hozzáférhetnek.
Az Azure Stack egy hibrid felhőplatform, amellyel Azure-szolgáltatásokat nyújthat a szervezet adatközpontjából. A vállalatok beállíthatják az Azure Stacket a saját adatközpontjaikban, vagy használhatják az Azure-szolgáltatásokat a szolgáltatóktól, és az Azure Stacket a saját 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úrát biztosít. Az Azure-felhőplatformon elérhető bármilyen típusú erőforrás üzembe helyezhető és konfigurálható az Azure Resource Manager. Egyetlen sablonnal üzembe helyezheti és konfigurálhatja a teljes alkalmazást működési végállapotba.

Diagram különböző Azure-környezetekről, beleértve a globális Azure-t, a szuverén felhőket és az Azure Stacket.

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 kihasználni az Azure Resource Manager előnyeit. A sablonalapú erőforrás-üzembe helyezés és -konfiguráció beállításakor újra felhasználhatja a fejlesztési befektetéseit ezeken a felhőkön.

Annak ellenére azonban, hogy a globális, szuverén, üzemeltetett és hibrid felhők konzisztens szolgáltatásokat biztosítanak, 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 frissíté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él üzembehelyezési helyeken.
A beágyazott sablonokat és konfigurációs összetevőket akadálymentes helyeken tárolhatja, így biztosítva a felhők közötti hozzáférést.
Használjon dinamikus hivatkozásokat a hivatkozások és elemek kódolása helyett.
Győződjön meg arról, hogy a célfelhőkben használt sablonparaméterek 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ése című témakörben olvashat bővebben.

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

Az ARM-sablonok alapszintaxisa a JSON. A sablonok jSON-szuperhalmazt használnak, és kifejezésekkel és függvényekkel bővítik ki a szintaxist. A sablonnyelv-feldolgozó gyakran frissül, hogy további sablonfüggvényeket is támogatjon. Az elérhető sablonfüggvények részletes ismertetését az ARM-sablonfüggvények című témakörben találja.

Az Azure Resource Manager 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:

Klónozza a GitHub-adattárat: https://github.com/marcvaneijk/arm-template-functions.
Ha már rendelkezik az adattár helyi klónjával, csatlakozzon a cél Azure-Resource Manager a PowerShell-lel.

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 hivatkozhatnak csatolt összetevőkre, és tartalmazhatnak olyan üzembehelyezési erőforrást, amely egy másik sablonra hivatkozik. A csatolt sablonokat (más néven beágyazott sablonokat) futásidőben Resource Manager 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.

Az alábbi 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 méretű, ú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 beágyazhat sablonokat. Hasonlóképpen, a beágyazott sablonok más sablonokra mutató hivatkozásokat is tartalmazhatnak. Akár öt szint mélyre is beágyazhat.

Az alábbi kód bemutatja, hogyan hivatkozik a templateLink paraméter egy 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 futtatáskor 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 összeolvad, és további feldolgozást kezdeményez.

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

Gondolja át, hol és hogyan tárolhatja az Ön által használt csatolt sablonokat. Futásidőben az Azure Resource Manager lekéri a csatolt sablonokat , és ezért közvetlen hozzáférést igényel. Gyakori eljárás a Beágyazott sablonok tárolása a GitHub használatával. A GitHub-adattárak olyan fájlokat tartalmazhatnak, amelyek nyilvánosan elérhetők egy URL-címen keresztül. 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 vállalati hálózaton vagy 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 minden üzembehelyezési összetevőt egy folyamatos integrációs/folyamatos fejlesztési (CI/CD) folyamat tart fenn és helyez üzembe. A beágyazott sablonokat egy blobtárolóban is tárolhatja, amelyből az Azure Resource Manager lekérheti őket.

Mivel a blobtároló minden felhőben egy másik végpont teljes tartománynevét (FQDN) használja, 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 bevitelt. A sablonokat általában több személy szerkesztette és osztotta meg, ezért az ajánlott eljárás egy szabványos név használata 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álásában.

Az alábbi kódban _artifactsLocation a rendszer egyetlen helyre mutat, amely az összes üzembe helyezéssel kapcsolatos összetevőt tartalmazza. Figyelje meg, hogy egy alapértelmezett érték van megadva. Az üzembe helyezéskor, ha nincs megadva bemeneti érték a értékhez _artifactsLocation, a rendszer az alapértelmezett értéket használja. A _artifactsLocationSasToken bemenete a sasToken. Az alapértelmezett értéknek egy üres sztringnek kell lennie az olyan forgatókönyvek esetében, ahol a _artifactsLocation nem biztonságos – 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 _artifactsLocationSasTokenkövetkezővel: . 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éke _artifactsLocation lesz használva. Ha a csatolt sablonokat egy másik 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 – magához a sablonhoz nincs szükség módosításra.

A _artifactsLocation használata rögzített hivatkozások helyett

A beágyazott sablonokon kívül a _artifactsLocation paraméterBEN található URL-cím az üzembehelyezési sablon összes kapcsolódó összetevőjének alapjaként szolgál. Egyes virtuálisgép-bővítmények a sablonon kívül tárolt szkriptre mutató hivatkozást tartalmaznak. Ezekben a bővítményekben nem szabad a hivatkozásokat rögzítetten kódolni. Az egyéni szkriptek és a PowerShell DSC-bővítmények például egy külső gitHub-szkriptre hivatkozhatnak az ábrán látható 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 keménykódolása 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 hivatkozott összes szkript letöltését, majd a szkripteket a virtuális gép helyi lemezén tárolja. 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.

Resource Manager lekéri a beágyazott sablonokat futásidőben. 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 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ó rögzített hivatkozásokat az URI sablonfüggvényre cseréli, a sablonban ez a funkció a felhőkonzisztenciára 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 üzembe helyezési összetevő, beleértve a konfigurációs szkripteket is, ugyanazon a helyen tárolható magával a sablonnal. 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.

Különböző 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. Szigorú belső tesztelést követően az érvényesítési programban részt vevő ügyfelek egy kis közönsége általában új szolgáltatásokat vagy meglévő szolgáltatások frissítéseit mutatják be. Az ügyfelek sikeres ellenőrzése után a szolgáltatások vagy frissítések elérhetővé válnak az Azure-régiók egy részhalmazán belül, majd több régióban lesznek bevezetve, a szuverén felhőkbe kerülnek, és potenciálisan elérhetővé válnak az Azure Stack-ügyfelek számára is.

Tudva, hogy az Azure-régiók és -felhők eltérhetnek 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ó megadja az Azure-szolgáltatásokhoz elérhető erőforrásokat és műveleteket.

Egy sablon üzembe helyezi és konfigurálja az erőforrásokat. Az erőforrástípust egy erőforrás-szolgáltató biztosítja. A számítási erőforrás-szolgáltató (Microsoft.Compute) például több erőforrástípust biztosít, például virtualMachines és availabilitySets. Minden erőforrás-szolgáltató egy közös szerződés által meghatározott API-t biztosít az Azure-hoz Resource Manager, amely 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 erőforrás-szolgáltatók, az erőforrástípusok és az API-verziók közötti kapcsolatot bemutató ábra.

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ásnak saját egyedi tulajdonságai is vannak. 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. Egy sablonban lévő erőforrás saját API-verzió tulajdonságával rendelkezik – 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 meglévő erőforrástípusaihoz bevezetett új API-verziók nem feltétlenül érhetők el azonnal az összes régióban, szuverén felhőben vagy az Azure Stackben. A felhőhöz elérhető erőforrás-szolgáltatók, erőforrástípusok és API-verziók listájának megtekintéséhez használhatja az Erőforrás-kezelőt Azure Portal. Keresse meg az Erőforrás-kezelőt a Minden szolgáltatás menüben. Bontsa ki a Szolgáltatók csomópontot az Erőforrás-kezelőben, és adja vissza az összes elérhető erőforrás-szolgáltatót, azok erőforrástípusait és API-verzióit a felhőben.

Az Azure CLI-ben az 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 az erőforráshelyeket paraméterrel

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ágsal is, amellyel megadhatja az üzembe helyezéshez használt régiót. A felhőkonzisztencia sablonjának fejlesztéséhez dinamikus módon kell hivatkoznia az erőforráshelyekre, 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 a régiók közötti alkalmazások rendelkezésre állása, hasznos lehet az erőforrások régiók közötti elosztására.

Annak ellenére, hogy a régióneveket egy sablon erőforrás-tulajdonságainak megadásakor meg tudja 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. A rendszer az alapértelmezett értéket használja, 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 a bemeneti paraméter defaultValue értékében hivatkozik az objektum helykulcsára, 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 sablont üzembe helyezi.

"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 a sablon egy adott erőforrásának helye eltérhet az erőforráscsoport helyétől. Ebben az esetben konfigurálhatja úgy, hogy további bemeneti paramétereket használ az adott erőforráshoz, míg az ugyanabban a sablonban lévő többi erőforrás továbbra is a kezdeti helybeviteli paramétert használja.

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

Az Azure Stackben elérhető összes erőforrás-szolgáltató és kapcsolódó API-verzió nyomon követése nagy kihívást jelenthet. Íráskor például a Microsoft.Compute/availabilitySets legújabb API-verziója az Azure-ban, 2018-04-01míg az Azure-ban és az Azure Stackben gyakran használt API-verzió.2016-03-30 A Microsoft.Storage/storageAccounts közös API-verziója az összes Azure- és Azure Stack-hely 2016-01-01között, míg az Azure legújabb API-verziója.2018-02-01

Ezért Resource Manager bevezette az API-profilok fogalmát a sablonokhoz. API-profilok nélkül a sablon minden erőforrása egy apiVersion olyan elemmel van konfigurálva, 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-profilverziók az Azure-ban és az Azure Stackben gyakran használt erőforrástípusonként egyetlen API-verzió aliasaként szolgálnak. Ahelyett, hogy api-verziót ad meg egy sablon minden erőforrásához, csak az API-profil verzióját kell megadnia egy nevű apiProfile új gyökérelemben, é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 több helyen is elérhetők legyenek, így nem kell manuálisan ellenőriznie az adott helyen elérhető apiVersion-eket. 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ónapos elavult, akkor a rendszer nem megfelelőnek tekinti, és frissíteni kell a környezetet.

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 a platform más szolgáltatásaira. Egy nyilvános IP-címhez például hozzárendelhet egy nyilvános DNS-nevet. 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. A legtöbb esetben egy erőforrás csak egy előtagot igényel bemenetként a sablonban. Futásidőben az Azure Resource Manager hozzáfűzi a végpont értékét. Egyes végpontértékeket explicit módon kell megadni a sablonban.

Megjegyzés

A felhőkonzisztencia sablonjainak 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 Redis

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. Az alábbiakban gyakori példákat láthat:

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 rögzített 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 rendelkezik egy egyedi teljes tartománynévvel, amely a tárfiók nevének és a végpontnévtérnek a összefűzésével jön létre. A mystorageaccount1 nevű Blob Storage-fiók különböző teljes tartományneveket eredményez a felhőtől függően:

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

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 rögzített é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.

Tekintse meg a meglévő erőforrásokat egyedi azonosító alapján

Hivatkozhat egy meglévő erőforrásra is ugyanabból vagy egy másik erőforráscsoportból, valamint ugyanazon előfizetésből vagy egy másik előfizetésből, ugyanabban a felhőben található 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óját kell használnia. A resourceId sablonfüggvény lekéri egy erőforrás egyedi azonosítóját, például SQL Server, 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énnyel lekérheti egy adatbázis tulajdonságait. A visszatérési objektum tartalmazza a fullyQualifiedDomainName teljes végpontértéket tartalmazó tulajdonságot. Ez az érték futásidőben lesz lekérve, és a felhőkörnyezet-specifikus végpontnévteret biztosítja. Ha a kapcsolati sztring a végpontnévtér bekódolása nélkül szeretné definiálni, hivatkozhat a visszatérési objektum tulajdonságára közvetlenül a kapcsolati sztring 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 megfontolása

Az Azure Stack-környezetekben található 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 virtuálisgép-rendszerképek széles választékát kínálja. Ezeket a rendszerképeket a Microsoft és a partnerek hozzák létre és készítik elő üzembe helyezésre. A rendszerképek képezik a platformon futó 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.

A rendelkezésre álló 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 kívánt helyet a -Location paraméterrel. Például:

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 elérhetővé tette ezeket a virtuálisgép-rendszerképeket az Azure Stack számára, a rendszer az összes rendelkezésre álló tárterületet felhasználja. Az Azure Stack lehetővé teszi a környezethez hozzáadni kívánt rendszerképek kiválasztását, hogy még a legkisebb méretezési egység is elférjen.

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ők konzisztenciájának kialakításához 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álisgép-méretek a virtuális gép által futtatott hardvertől függenek. 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 bevezet egy új méretű virtuális gépet, 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ók és felhők számára is elérhetővé válik. Ha meg szeretné győződni arról, hogy a virtuálisgép-méret minden olyan felhőben létezik, amelyen üzembe helyezi, lekérheti a rendelkezésre álló méreteket az alábbi Azure CLI-paranccsal:

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át lásd: Régiónként elérhető termékek.

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 meg szeretné adni 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ép üzembe helyezésekor. A felügyelt lemezek növelik a rendelkezésre állást azáltal, 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ő VHD-k 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, létrehozhat felhőkonzisztens sablonokat az Azure Stackhez úgy, hogy explicit módon megadja a virtuális merevlemezeket a vhd virtuálisgép-erőforrás sablonjának elemével, az alábbi 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. A 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 microsoftos SQL Server futtató virtuális gépet szeretne konfigurálni, a virtuálisgép-bővítmény konfigurálhatja SQL Server a sablon üzembe helyezésének részeként. Gondolja át, mi történik, ha az üzembe helyezési sablon tartalmaz egy olyan alkalmazáskiszolgálót is, amely úgy van konfigurálva, hogy adatbázist hozzon létre a SQL Server futó virtuális gépen. 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 a 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 a SQL Server futó virtuális gép konfigurálva legyen, és elérhető legyen, amikor az alkalmazáskiszolgálót az adatbázis létrehozására utasítják.

A sablon deklaratív megközelítése lehetővé teszi az erőforrások és azok közötti függőségek végső á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őkonzisztencia sablonjának fejlesztésekor ügyeljen arra, hogy csak azokat a bővítményeket használja, amelyek a sablon által célként kitűzött ö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

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

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 egy 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ény-erőforrás API-verziójának jelen kell lennie az összes olyan helyen, ahol meg szeretné célozni a sablont. 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 az "Az összes erőforrástípus verziójának ellenőrzése" című szakaszban tárgyaltak.

A virtuálisgép-bővítmény erőforrásához 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őkonzisztencia sablonjának fejlesztéséhez győződjön meg arról, hogy az API-verziók minden olyan helyen elérhetők, ahol üzembe szeretne helyezni. A méretezési csoportok virtuálisgép-bővítmény-erőforrásának API-verzióinak lekéréséhez 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 ábrán látható 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",
        ...

Egy adott virtuálisgép-bővítmény elérhető verzióinak lekéréséhez 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 fájlbó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. A 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ésekor. A gyakori módszer a sablonok egyetlen felhőn való fejlesztése és tesztelése, mielőtt más helyekre céloznak. Azonban minél korábban végzik el a teszteket a szerzői folyamatban, annál kevesebb hibaelhárítást és kód újraírást kell végeznie a fejlesztői csapatnak. A helyfüggőségek miatt meghiúsuló üzemelő példányok hibaelhárítása időigényes lehet. Ezért javasoljuk, hogy a lehető leghamarabb automatizált tesztelést végez 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 idősor 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 egyetlen fejlesztőre vagy egy nagy csapatra egyaránt érvényes. Minden fejlesztő általában létrehoz egy helyi másolatot egy központi adattárról, így mindegyik dolgozhat a helyi másolaton anélkül, hogy hatással lenne a többire, akik esetleg ugyanazon a fájlon dolgoznak.

A párhuzamos egységteszteket és integrációs teszteket bemutató ábra a helyi azonosítókban, a CI/CD fejlesztési folyamatba való egyesítés egységtesztekkel, integrációs tesztekkel, tesztelési üzembe helyezéssel és végső üzembe helyezéssel.

Fontolja 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 intelliSense-t és más olyan funkciókat tartalmaz, amelyek segíthetnek a sablonok érvényesíté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 kijavítandó 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 Manager csatlakoztatása nélkül is elvégezhetők. Másoknak, például a sablon üzembe helyezésének teszteléséhez Resource Manager kell végrehajtaniuk bizonyos, offline módban nem végrehajtható műveleteket.
Az üzembehelyezési sablon ellenőrzési API-val való tesztelése 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 Resource Manager, é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.