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

Fontos

A PowerShellből származó Azure-funkció használatához telepíteni kell a AzureRM modult. 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óihoz 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 egy másik helyen újrafelhasználhatók. Az 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 több felhőben való újrafelhasználásához azonban figyelembe kell vennie a felhőspecifikus függőségeket, ahogy ez az útmutató ismerteti.

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

• A globális Azure-platformot a Microsoft által felügyelt adatközpontok egyre bővülő hálózata támogatja a világ különböző régióiban.
• Elkülönített szuverén felhők, például az Azure Germany, az Azure Government és az Azure China 21Vianet. A szuverén felhők konzisztens platformot biztosítanak a legtöbb olyan nagyszerű funkcióval, amelyekhez a globális Azure-ügyfelek hozzáférhetnek.
• Az Azure Stack egy hibrid felhőplatform, amellyel Azure-szolgáltatásokat biztosíthat 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 futtathatják a létesítményeikben (más néven üzemeltetett régiókban).

Ezeknek a felhőknek a középpontjában az Azure Resource Manager egy OLYAN API-t biztosít, amely lehetővé teszi, hogy a felhasználói felületek széles köre kommunikáljon az Azure platformmal. Ez az API hatékony infrastruktúra-kódolási 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 kihasználni az Azure Resource Manager előnyeit. A sablonalapú erőforrások üzembe helyezésének és konfigurálásának beállításakor újra felhasználhatja a fejlesztési befektetéseit ezekben a felhőkben.

Bár 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ő szolgáltatásoktó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 rögzített hivatkozások és elemek 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 sablonok üzembe helyezését ismertető cikkben olvashat bővebben.

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

Az ARM-sablonok alapszintaxisa a JSON. A sablonok JSON-kódrészletet használnak, és kifejezésekkel és függvényekkel bővítik ki a szintaxist. A sablonnyelv feldolgozóját gyakran frissítik, hogy további sablonfüggvényeket is támogassanak. A rendelkezésre álló 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. A következő PowerShell-szkripttel ellenőrizheti, hogy az újonnan bevezetett sablonfüggvények elérhetők-e az Azure Stackben is:

1. Klónozza a GitHub-adattárat: https://github.com/marcvaneijk/arm-template-functions.

2. Ha már 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 jelenti a támogatott és nem elérhető sablonfüggvényeket.

Csatolt összetevők használata

A sablonok hivatkozhatnak csatolt összetevőkre, és tartalmazhatnak egy üzembe helyezé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 a virtuálisgép-bővítmények összetevőire mutató hivatkozásokat is tartalmazhatnak. Ezeket az összetevőket a virtuális gépen 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 méretű, újrafelhasználható sablonokra bonthatók, amelyek mindegyike meghatározott céllal rendelkezik, és újra felhasználhatók az üzembe helyezési forgatókönyvekben. Az üzembe helyezés végrehajtásához egyetlen sablont kell megadnia, amelynek neve fő vagy fő sablon. 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 tartalmazhat egy másik sablonra mutató hivatkozást is, ami azt jelenti, hogy sablonokat ágyazhat be. 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 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 egybesimul, és további feldolgozást kezdeményez.

Csatolt sablonok akadálymentesítése 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 így 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 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őben és a szuverén felhőkben, az Azure Stack-környezetek vállalati hálózaton vagy leválasztott távoli helyen, kimenő internet-hozzáférés nélkül is elhelyezhetők. Ezekben az esetekben az Azure Resource Manager nem tudta lekérni a beágyazott sablonokat.

A felhők közötti üzembe helyezés 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. Azt is megteheti, hogy beágyazott sablonokat tárol egy Blob Storage-tárolóban, ahonnan 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 a felhasználói bevitelt. 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álásában.

A következő kód egyetlen helyre mutat, _artifactsLocation amely az összes üzembe helyezéssel kapcsolatos összetevőt tartalmazza. Figyelje meg, hogy meg van adva egy alapértelmezett érték. Az üzembe helyezéskor, ha nincs megadva _artifactsLocationbemeneti érték, a rendszer az alapértelmezett értéket használja. A _artifactsLocationSasToken rendszer ezt használja bemenetként a sasToken. Az alapértelmezett értéknek egy üres sztringnek kell lennie olyan forgatókönyvek esetében, ahol az _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 csatolások az alap URI (a _artifactsLocation paraméterből) és egy összetevő relatív elérési útjának _artifactsLocationSasTokenkombinálásával jönnek létre. 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 megközelítéssel a paraméter alapértelmezett értékét _artifactsLocation használja a rendszer. Ha a csatolt sablonokat egy másik helyről kell lekérni, a paraméterbemenet 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.

Hivatkozások bekódolása helyett _artifactsLocation használata

A beágyazott sablonok használata mellett a _artifactsLocation paraméterben lévő URL-cím egy üzembe helyezési sablon összes kapcsolódó összetevőjének alapjaként szolgál. Egyes virtuálisgép-bővítmények tartalmaznak egy, a sablonon kívül tárolt szkriptre mutató hivatkozást. 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 hivatkozhatnak egy külső szkriptre 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 rögzített beírásával 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 szkriptek 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 korábban 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 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árolódik (beleértve a virtuálisgép-bővítmény szkripteit), valamint 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 ajánlott módszer az URI-sablonfüggvény használata az összefűzési sablonfüggvény helyett. Ha a virtuálisgép-bővítmény szkriptjeire mutató rögzített hivatkozásokat lecseréli az URI-sablonfüggvényre, a sablonban ez a funkció a felhők konzisztenciájá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ó 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.

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. A szigorú belső tesztelés után a meglévő szolgáltatások új szolgáltatásait vagy frissítéseit általában az érvényesítési programban részt vevő ügyfelek kis közönsége mutatják be. Az ügyfelek sikeres érvényesítése után a szolgáltatások vagy frissítések az Azure-régiók egy részhalmazán belül lesznek elérhetővé téve, majd több régióban jelennek meg, a szuverén felhőkben jelennek meg, é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érhetnek az elérhető szolgáltatásaikban, proaktív döntéseket hozhat a sablonokkal kapcsolatban. Elsőként érdemes megvizsgálni a felhőben 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 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

Az alábbi 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 egyedi 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ágtal 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 módosítá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 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 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

Erőforráshelyek hivatkozása 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ágtal is, amellyel megadhatja a régiót, amelyben üzembe helyezhető. 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ása.

Annak ellenére, hogy egy sablon erőforrás-tulajdonságainak megadásakor a régiónevek kódolhatók, 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 nincs megadva érték az üzembe helyezés során.

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 alapértelmezett Érték értéké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 további bemeneti paraméterekkel konfigurálhatja az adott erőforráshoz, 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

Az Azure Stackben elérhető összes elérhető erőforrás-szolgáltató és kapcsolódó API-verzió nyomon követése nagy kihívást jelenthet. Az írás időpontjában például az Azure-beli Microsoft.Compute/availabilitySets legújabb API-verziója, 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 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 elemhez 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 új, úgynevezett apiProfile 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 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 tekinti, é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 azokhoz az erőforrásokhoz lesz felhasználva, amelyekhez nincs apiVersion megadva. Ez az elem lehetővé teszi a fokozatos változtatá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 hozzárendelhet egy nyilvános DNS-nevet. A nyilvános felhő, a szuverén felhők és az Azure Stack-megoldások saját 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. Bizonyos végpontértékeket explicit módon kell megadni a sablonban.

Megjegyzés

A felhők konzisztenciájára 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 Az 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 rögzített végpontok használatát. 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áskor.
• mystorageaccount1.blob.core.chinacloudapi.cn az Azure China 21Vianet felhőben való létrehozásakor.

A következő referenciasablonfüggvény lekéri a végpontnévteret a tárolási 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 különböző környezetekben való sikeres üzembe helyezéshez anélkül, hogy módosítaná a végponthivatkozást.

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

Ugyanabból vagy egy másik erőforráscsoportból, illetve ugyanazon előfizetésen vagy előfizetésen belül, ugyanazon bérlőn belül, ugyanazon a felhőben is hivatkozhat egy meglévő erőforrásra. 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ényben található reference függvénnyel lekérheti az 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örnyezetspecifikus végpont-névterét biztosítja. Ha a kapcsolati sztringet a végpontnévtér bekódolása nélkül szeretné definiálni, közvetlenül a kapcsolati sztringben hivatkozhat a visszatérési objektum tulajdonságára az alábbi 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ás-tulajdonságok megfontolása

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

Virtuálisgép-rendszerképek rendelkezésre állásának biztosítása

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ő ü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őjére, ajánlatára és termékváltozatára.

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 rendszerké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 skálázá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álisgép-méretek a virtuális gép által futtatott hardvertől függenek. Ha például GPU-optimalizált virtuális gépet szeretne üzembe helyezni, a hipervizort futtató hardvernek rendelkeznie kell a hardver GPU-kkal.

Amikor a Microsoft olyan új virtuálisgép-méretet vezet be, amely bizonyos hardverfüggőségekkel rendelkezik, a virtuális gép mérete általában először az Azure-felhő régióinak egy kis részhalmazában lesz elérhetővé téve. 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 megtalálható, amelyen üzembe helyez, lekérheti az elérhető méreteket az alábbi Azure CLI-paranccsal:

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

Az Azure PowerShellhez használja a következőt:

Get-AzureRmVMSize -Location "West Europe"

Az elérhető szolgáltatások teljes listáját a régiónként elérhető termékek között találja.

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 megad egy virtuális merevlemez (VHD) URI-ját, a felügyelt lemezek használatával implicit módon végrehajthatja ezeket a műveleteket a virtuális gép ü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 fejlesztési ütemtervében szerepelnek, jelenleg nem támogatottak. Amíg el nem készülnek, az Azure Stackhez létrehozhat felhőkonzisztens sablonokat úgy, 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 ha felügyelt lemezkonfigurációt szeretne megadni egy sablonban, távolítsa el az vhd elemet a 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.

Annak ellenőrzése, hogy a virtuálisgép-bővítmények elérhetők-e az Azure Stackben

A felhők konzisztenciájának egy 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, így 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 olyan alkalmazáskiszolgálót is, amely úgy van konfigurálva, hogy adatbázist hozzon létre az SQL Servert futtató 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 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óban 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álisgép-rendszerkép 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 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ának 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ó rendelkezésre állása, amelyet az "Összes erőforrástípus verziószámá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 ábrán látható 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ők konzisztenciájára szolgáló 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ánja helyezni az alkalmazást. 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ó megjelenik a typeHandlerVersion virtuálisgép-bővítmény tulajdonságában. 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. Az alábbi 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 myLocationbó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ás nyomon követni az összes kapcsolódó beállítást, képességet és korlátozást egy sablon létrehozásakor. A gyakori megközelítés a sablonok fejlesztése és tesztelése egyetlen felhőn, mielőtt más helyekre irányulnak. Azonban minél korábban végzik el a 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úsuló üzemelő példányok hibaelhárítása időigényes lehet. Ezért javasoljuk az automatizált tesztelést a lehető leghamarabb 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őkörnyezetet (IDE) használó csapat fejlesztési folyamatára. Az ütemterv különböző szakaszaiban különböző teszttípusokat hajtanak 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 példányát hozza létre, amely lehetővé teszi, hogy mindegyik a helyi példányon dolgozzon anélkül, hogy hatással lenne az ugyanazon a fájlokon dolgozó többire.

Fontolja meg a következő 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 olyan funkciókat, 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 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 üzembe helyezé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 sablonba ágyazott sablonokra mutató hivatkozásokat a Resource Manager közvetlenül kéri le, a virtuálisgép-bővítmények által hivatkozott összetevőket pedig az üzembe helyezett virtuális gépen futó virtuálisgép-ügynök kéri le.

Következő lépések

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