Azure Resource Manager tesztmeghajtó

Fontos

A tesztmeghajtó már elavult. A Tesztmeghajtók alternatívaként javasoljuk, hogy fontolja meg az ingyenes próbaverziókra való áttérést, amely lehetővé teszi az ügyfelek számára, hogy teljes mértékben kapcsolatba léphessenek a termékkel a személyre szabott beállításaik és konfigurációik segítségével, és megfelelnek az igényeiknek. Javasoljuk, hogy távolítsa el a tesztmeghajtókat az ajánlatokból, és törölje a tesztmeghajtó-környezeteket. Ezt a típust akkor használja, ha van ajánlata az Azure Marketplace-en vagy az AppSource-on, de csak Azure-erőforrásokat tartalmazó tesztmeghajtót szeretne létrehozni. Az Azure Resource Manager-sablon (ARM) az Azure-erőforrások kódolt tárolója, amelyet úgy tervez meg, hogy a legjobban képviselje a megoldást. A tesztmeghajtó a megadott ARM-sablont használja, és üzembe helyezi az összes szükséges erőforrást egy erőforráscsoportban. Ez az egyetlen tesztmeghajtó-lehetőség a virtuális gépekhez vagy az Azure-alkalmazásokhoz.

Ha nem ismeri az ARM-sablonokat, olvassa el a Mi az Azure Resource Manager? című cikket, és ismerje meg az ARM-sablonok szerkezetét és szintaxisát, hogy jobban megértse, hogyan hozhat létre és tesztelhet saját sablonokat.

Egy üzemeltetett vagy logikai alkalmazás tesztmeghajtójára vonatkozó információkért lásd: Mi az a tesztmeghajtó?

Tipp.

A kereskedelmi piactéren található tesztmeghajtók ügyfélnézetét a Mi az Azure Marketplace? és mi a Microsoft AppSource? című témakörben tekintheti meg.

Műszaki konfiguráció

Az üzembehelyezési sablon tartalmazza a megoldást alkotó összes Azure-erőforrást. Az ehhez a forgatókönyvhöz illeszkedő termékek csak Azure-erőforrásokat használnak. Adja meg a következő tulajdonságokat a Partnerközpontban:

• Régiók (kötelező) – Jelenleg 26 Azure által támogatott régióban érhető el a tesztmeghajtó. A legjobb teljesítmény érdekében azt javasoljuk, hogy válasszon egy régiót, ahol a legnagyobb számú ügyfélre számít. Győződjön meg arról, hogy az előfizetése minden szükséges erőforrást üzembe helyezhet a kiválasztott régiókban.

• Példányok – Válassza ki a típust (gyakori vagy ritka elérésű) és az elérhető példányok számát, amelyet a rendszer megszoroz azon régiók számával, ahol az ajánlat elérhető.

  • Gyakori elérésű – Ez a példánytípus üzembe van helyezve, és a kijelölt régiónkénti hozzáférésre vár. Az ügyfelek azonnal hozzáférhetnek egy tesztmeghajtó gyakori elérésű példányaihoz ahelyett, hogy várniuk kellene az üzembe helyezésre. A kompromisszum az, hogy ezek a példányok mindig az Azure-előfizetésen futnak, így nagyobb üzemidővel járnak. Erősen ajánlott legalább egy gyakori elérésű példány használata, mivel a legtöbb ügyfél nem szeretne megvárni a teljes üzembe helyezést, ami az ügyfélhasználat csökkenését eredményezi, ha nincs elérhető gyakori elérésű példány.

  • Hideg – Ez a példánytípus a régiónként üzembe helyezhető példányok teljes számát jelöli. A hideg példányokhoz a teljes Test Drive Resource Manager-sablont telepíteni kell, amikor egy ügyfél a tesztmeghajtót kéri, így a hideg példányok betöltése sokkal lassabb, mint a gyakori elérésű példányok. A kompromisszum az, hogy csak a tesztmeghajtó időtartamáért kell fizetnie, nem* mindig fut az Azure-előfizetésén, mint egy gyakori elérésű példány esetében.

• Tesztmeghajtó Azure Resource Manager-sablon – Töltse fel az Azure Resource Manager-sablont tartalmazó .zip. További információ az Azure Resource Manager-sablon létrehozásáról az Azure Resource Manager-sablonok létrehozása és üzembe helyezése az Azure Portal használatával című rövid útmutatóban.

  Feljegyzés

  A sikeres közzétételhez fontos ellenőrizni az ARM-sablon formázását. Ennek kétféle módja van: (1) egy online API-eszközzel vagy (2) egy teszttelepítéssel.

• Tesztmeghajtó időtartama (kötelező) – Adja meg, hogy a tesztmeghajtó hány órán keresztül maradjon aktív. A tesztmeghajtó ennek az időszaknak a vége után automatikusan leáll. Csak egész számokat használjon (például a "2" óra érvényes, az "1,5" nem).

A tesztmeghajtó sablonjának írása

Miután megtervezte a kívánt erőforráscsomagot, írja meg és hozza létre a tesztmeghajtó ARM-sablonját. Mivel a tesztmeghajtó teljesen automatizált módban futtatja az üzembe helyezéseket, a tesztmeghajtó-sablonok bizonyos korlátozásokkal rendelkeznek:

Paraméterek

A legtöbb sablon olyan paraméterekkel rendelkezik, amelyek meghatározzák az erőforrásneveket, az erőforrások méretét (például a tárfiókok vagy virtuális gépek méretét), a felhasználóneveket és jelszavakat, a DNS-neveket stb. Amikor megoldásokat helyez üzembe az Azure Portalon, manuálisan feltöltheti ezeket a paramétereket, kiválaszthatja az elérhető DNS-neveket vagy tárfiókneveket stb.

A tesztmeghajtó azonban automatikusan, emberi beavatkozás nélkül működik, ezért csak korlátozott számú paraméterkategóriát támogat. Ha a tesztmeghajtó ARM-sablonjának egyik paramétere nem tartozik a támogatott kategóriák egyikébe, ezt a paramétert változóra vagy állandó értékre kell cserélnie.

A paraméterekhez bármilyen érvényes nevet használhat; A tesztmeghajtó metaadat-típusú érték használatával felismeri a paraméterkategóriát. Adjon meg metaadattípust minden sablonparaméterhez, különben a sablon nem felel meg az ellenőrzésnek:

"parameters": {
  ...
  "username": {
    "type": "string",
    "metadata": {
      "type": "username"
    }
  },
  ...
}

Feljegyzés

Az összes paraméter megadása nem kötelező, ezért ha nem szeretne használni semmilyen paramétert, akkor nem kell.

Elfogadott paraméter metaadatainak típusai

Metaadatok típusa	Paraméter típusa	Leírás	Mintaérték
baseuri	húr	Az üzembehelyezési csomag alap URI-ja	https://<..>.blob.core.windows.net/<..>
Felhasználónév	húr	Új véletlenszerű felhasználónév.	admin68876
Jelszó	biztonságos sztring	Új véletlenszerű jelszó	Lp! ACS^2kh
munkamenet-azonosító	húr	Egyedi tesztmeghajtó munkamenet-azonosítója (GUID)	b8c8693e-5673-449c-badd-257a405a6dee

baseuri

A tesztmeghajtó inicializálja ezt a paramétert az üzembehelyezési csomag alap URI-jával, így ezzel a paraméterrel létrehozhatja a csomagban található bármely fájl Uri-ját.

Feljegyzés

A baseUri paraméter nem használható egyéni szkriptbővítménnyel együtt.

"parameters": {
  ...
  "baseuri": {
    "type": "string",
    "metadata": {
      "type": "baseuri",
      "description": "Base Uri of the deployment package."
    }
  },
  ...
}

Ezzel a paraméterrel a sablonon belül létrehozhatja a tesztmeghajtó üzembehelyezési csomagjából származó bármely fájl URI-ját. Az alábbi példa bemutatja, hogyan hozhat létre URI-t a csatolt sablonból:

"templateLink": {
  "uri": "[concat(parameters('baseuri'),'templates/solution.json')]",
  "contentVersion": "1.0.0.0"
}

username

A tesztmeghajtó inicializálja ezt a paramétert egy új véletlenszerű felhasználónévvel:

"parameters": {
  ...
  "username": {
    "type": "string",
    "metadata": {
      "type": "username",
      "description": "Solution admin name."
    }
  },
  ...
}

Mintaérték: admin68876

A megoldáshoz használhat véletlenszerű vagy állandó felhasználóneveket.

jelszó

A tesztmeghajtó új véletlenszerű jelszóval inicializálja ezt a paramétert:

"parameters": {
  ...
  "password": {
    "type": "securestring",
    "metadata": {
      "type": "password",
      "description": "Solution admin password."
    }
  },
  ...
}

Mintaérték: Lp!ACS^2kh

A megoldáshoz használhat véletlenszerű vagy állandó jelszavakat.

munkamenet-azonosító

A tesztmeghajtó inicializálja ezt a paramétert egy egyedi GUID azonosítóval, amely a tesztmeghajtó munkamenet-azonosítóját jelöli:

"parameters": {
  ...
  "sessionid": {
    "type": "string",
    "metadata": {
      "type": "sessionid",
      "description": "Unique test drive session id."
    }
  },
  ...
}

Mintaérték: b8c8693e-5673-449c-badd-257a405a6dee

Ezzel a paraméterel egyedileg azonosíthatja a tesztmeghajtó munkamenetét, ha szükséges.

Egyedi nevek

Egyes Azure-erőforrások, például tárfiókok vagy DNS-nevek globálisan egyedi neveket igényelnek. Ez azt jelenti, hogy minden alkalommal, amikor a tesztmeghajtó üzembe helyezi az ARM-sablont, létrehoz egy új erőforráscsoportot, amelynek minden erőforrása egyedi nevet ad. Ezért az erőforráscsoport-azonosítók változóneveivel összefűzött uniquestring függvényt kell használnia véletlenszerű egyedi értékek létrehozásához:

"variables": {
  ...
  "domainNameLabel": "[concat('contosovm',uniquestring(resourceGroup().id))]",
  "storageAccountName": "[concat('contosodisk',uniquestring(resourceGroup().id))]",
  ...
}

Győződjön meg arról, hogy a paraméter-/változósztringeket () egyedi sztringkimenettel (contosovmresourceGroup().id) fűzi össze, mivel ez garantálja az egyes változók egyediségét és megbízhatóságát.

A legtöbb erőforrásnév például nem kezdődhet számjegyekkel, de az egyedi sztringfüggvények visszaadhatnak egy sztringet, amely számjegygel kezdődik. Így ha nyers egyedi sztringkimenetet használ, az üzembe helyezések sikertelenek lesznek.

Az azure-erőforrások elnevezési és címkézési stratégiájának fejlesztésében további információt talál az erőforrás-elnevezési szabályokról és korlátozásokról.

Üzembehelyezési hely

A tesztmeghajtót különböző Azure-régiókban is elérhetővé teheti.

Amikor a tesztmeghajtó létrehozza a tesztkörnyezet egy példányát, mindig létrehoz egy erőforráscsoportot az egyik kijelölt régióban, majd végrehajtja az üzembehelyezési sablont ebben a csoportkörnyezetben. Ezért a sablonnak az erőforráscsoportból kell kiválasztania az üzembehelyezési helyet:

"variables": {
  ...
  "location": "[resourceGroup().location]",
  ...
}

Ezután használja ezt a helyet minden erőforráshoz egy adott laborpéldányhoz:

"resources": [
  {
    "type": "Microsoft.Storage/storageAccounts",
    "location": "[variables('location')]",
    ...
  },
  {
    "type": "Microsoft.Network/publicIPAddresses",
    "location": "[variables('location')]",
    ...
  },
  {
    "type": "Microsoft.Network/virtualNetworks",
    "location": "[variables('location')]",
    ...
  },
  {
    "type": "Microsoft.Network/networkInterfaces",
    "location": "[variables('location')]",
    ...
  },
  {
    "type": "Microsoft.Compute/virtualMachines",
    "location": "[variables('location')]",
    ...
  }
]

Győződjön meg arról, hogy az előfizetés minden egyes kiválasztott régióban üzembe helyezheti a kívánt erőforrásokat. Győződjön meg arról is, hogy a virtuálisgép-rendszerképek az összes engedélyezni kívánt régióban elérhetők, ellenkező esetben az üzembehelyezési sablon egyes régiókban nem fog működni.

Kimenetek

A Resource Manager-sablonok általában kimenet nélkül is üzembe helyezhetők. Ennek az az oka, hogy ismeri a sablonparaméterek feltöltéséhez használt összes értéket, és bármikor manuálisan is megvizsgálhatja bármelyik erőforrás tulajdonságait.

A Resource Manager-sablonok teszteléséhez azonban fontos visszatérni a tesztmeghajtóhoz minden olyan információhoz, amely a tesztkörnyezethez való hozzáféréshez szükséges (webhely URI-jai, virtuálisgép-gazdagépek nevei, felhasználónevek és jelszavak). Győződjön meg arról, hogy az összes kimeneti név olvasható, mert ezek a változók megjelennek az ügyfél számára.

A sablonkimenetekhez nincsenek korlátozások. A tesztmeghajtó az összes kimeneti értéket sztringekké alakítja, így ha objektumot küld a kimenetbe, a felhasználó JSON-sztringet fog látni.

Példa:

"outputs": {
  "Host Name": {
    "type": "string",
    "value": "[reference(variables('pubIpId')).dnsSettings.fqdn]"
  },
  "User Name": {
    "type": "string",
    "value": "[parameters('adminName')]"
  },
  "Password": {
    "type": "string",
    "value": "[parameters('adminPassword')]"
  }
}

Előfizetési korlátok

Ne feledkezzen meg az előfizetés és a szolgáltatás korlátairól. Ha például legfeljebb tíz négymagos virtuális gépet szeretne üzembe helyezni, győződjön meg arról, hogy a laborhoz használt előfizetés 40 mag használatát teszi lehetővé. Az Azure-előfizetéssel és szolgáltatáskorlátokkal kapcsolatos további információkért tekintse meg az Azure-előfizetések és -szolgáltatások korlátait, kvótáit és korlátozásait. Mivel egyszerre több tesztmeghajtó is használható, ellenőrizze, hogy az előfizetés képes-e kezelni a magok számát és az egyidejűleg használható tesztmeghajtók teljes számát.

Mit kell feltölteni?

A tesztmeghajtó ARM-sablonja zip-fájlként van feltöltve, amely különböző üzembehelyezési összetevőket tartalmazhat, de egy nevű fájllal kell rendelkeznie main-template.json. Ez az ARM-alapú üzembehelyezési sablon, amelyet a tesztmeghajtó a labor példányosítására használ. Ha a fájlon kívül további erőforrásokkal is rendelkezik, hivatkozhat rájuk külső erőforrásként a sablonon belül, vagy belefoglalhatja őket a zip-fájlba.

A közzétételi minősítés során a tesztmeghajtó kibontja az üzembehelyezési csomagot, és annak tartalmát egy belső tesztmeghajtó-blobtárolóba helyezi. A tárolóstruktúra az üzembehelyezési csomag szerkezetét tükrözi:

package.zip	Meghajtóblobtároló tesztelése
main-template.json	https:\//\<\...\>.blob.core.windows.net/\<\...\>/main-template.json
templates/solution.json	https:\//\<\...\>.blob.core.windows.net/\<\...\>/templates/solution.json
scripts/warmup.ps1	https:\//\<\...\>.blob.core.windows.net/\<\...\>/scripts/warmup.ps1

Ennek a blobtárolónak a Base Uri-nak hívjuk az Uri-t. Mivel a tesztkörnyezet minden változatának saját blobtárolója van, a tesztkörnyezet minden változatának saját Base Uri-ja van. A tesztmeghajtó sablonparamétereken keresztül képes átadni a nem kibontott üzembehelyezési csomag alap URI-ját a sablonba.

Mintasablon átalakítása tesztmeghajtóhoz

Az erőforrások architektúrájának tesztelési meghajtóvá alakítása a Resource Manager-sablonnal ijesztő lehet. További segítségért tekintse meg az alábbi példákat, amelyek bemutatja, hogyan alakíthatja át a legjobban az aktuális üzembehelyezési sablonokat a Mi az a tesztmeghajtó?

A meghajtó üzembehelyezési előfizetésének tesztelése

Az utolsó befejezési szakasz a tesztmeghajtók automatikus üzembe helyezése az Azure-előfizetés és a Microsoft Entra-azonosító csatlakoztatásával.

1. Szerezze be az Azure-előfizetés azonosítóját. Ez hozzáférést biztosít az Azure-szolgáltatásokhoz és az Azure Portalhoz. A rendszer az előfizetésben jelenti az erőforrás-használatot és a szolgáltatások számlázását. Ha még nem rendelkezik külön Azure-előfizetéssel a tesztmeghajtókhoz, hozzon létre egyet. Az Azure-előfizetési azonosítókat (például 1a83645ac-1234-5ab6-6789-1h234g764ghty1) az Azure Portalra való bejelentkezéssel és az Előfizetések lehetőség kiválasztásával találja meg a bal oldali navigációs menüben.

   

2. Szerezze be a Microsoft Entra bérlőazonosítóját. Ha már rendelkezik elérhető bérlőazonosítóval, a Microsoft Entra ID>Properties>Directory ID azonosítójában találja:

   

   Ha nem rendelkezik bérlőazonosítóval, hozzon létre egy újat a Microsoft Entra ID-ban. A bérlő beállításával kapcsolatos segítségért tekintse meg a következő rövid útmutatót: Bérlő beállítása.

3. A Microsoft Test-Drive alkalmazás kiépítése a bérlő számára. Ezzel az alkalmazással hajtunk végre műveleteket a tesztmeghajtó erőforrásain.

   1. Ha még nem rendelkezik vele, telepítse az Azure Az PowerShell-modult.
   2. Adja hozzá a Szolgáltatásnév a Microsoft Test-Drive alkalmazáshoz.
      1. Futtassa Connect-AzAccount és adja meg a hitelesítő adatokat az Azure-fiókba való bejelentkezéshez, amelyhez a Microsoft Entra ID Global Rendszergazda istratorbeépített szerepköre szükséges.
      2. Hozzon létre egy új szolgáltatásnevet: New-AzADServicePrincipal -ApplicationId d7e39695-0b24-441c-a140-047800a05ede -DisplayName 'Microsoft TestDrive'.
      3. Győződjön meg arról, hogy a szolgáltatásnév létrejött: Get-AzADServicePrincipal -DisplayName 'Microsoft TestDrive'.

4. A Microsoft Entra alkalmazásazonosítóhoz illessze be a következő alkalmazásazonosítót: d7e39695-0b24-441c-a140-047800a05ede.

5. A Microsoft Entra Alkalmazáskulcs esetében, mivel nincs szükség titkos kódra, szúrjon be egy titkos titkos kulcsot, például a "no-secret"-t.

6. Mivel az alkalmazást az előfizetésben való üzembe helyezéshez használjuk, hozzá kell adnunk az alkalmazást közreműködőként az előfizetéshez az Azure Portalról vagy a PowerShellből:

   1. Az Azure Portalon:

      1. Válassza ki a tesztmeghajtóhoz használt előfizetést.

      2. Válassza a Hozzáférés-vezérlés (IAM) lehetőséget.

      3. Válassza a Szerepkör-hozzárendelés hozzáadása > lehetőséget.

      4. A Szerepkör lapon válassza a Közreműködő lehetőséget.

      5. A Tagok lapon válassza a Felhasználó, csoport vagy szolgáltatásnév lehetőséget, majd válassza a Tagok kijelölése lehetőséget.

      6. Válassza ki a korábban létrehozott Microsoft TestDrive szolgáltatásnevet.

      7. A szerepkör hozzárendeléséhez a Felülvizsgálat + hozzárendelés lapon válassza a Felülvizsgálat + hozzárendelés lehetőséget.

         További információ a szerepkör-hozzárendelésekről: Azure-szerepkörök hozzárendelése az Azure Portal használatával

   2. Ha a PowerShellt használja:

      1. Futtassa ezt a servicePrincipal objektumazonosító lekéréséhez: (Get-AzADServicePrincipal -DisplayName 'Microsoft TestDrive').id.
      2. Futtassa ezt az ObjectId és az előfizetés azonosítójával: New-AzRoleAssignment -ObjectId <objectId> -RoleDefinitionName Contributor -Scope /subscriptions/<subscriptionId>.

Feljegyzés

A régi appID törlése előtt nyissa meg az Azure Portalt, majd az Erőforráscsoportokat, és keressen rá CloudTry_. Ellenőrizze az oszlop által kezdeményezett eseményt .

Ne törölje a régi appID-t, kivéve, ha legalább egy erőforrás (művelet neve) a Microsoft TestDrive-ra van beállítva.

Az appID törléséhez a bal oldali navigációs menüben válassza a Microsoft Entra ID>Alkalmazásregisztrációk, majd a Minden alkalmazás fület. Válassza ki az alkalmazást, és válassza a Törlés lehetőséget.

Ismételt közzététel

Most, hogy az összes tesztmeghajtó mező befejeződött, tegye közzé újra az ajánlatot. Miután a tesztmeghajtó sikeresen teljesítette a minősítést, tesztelje az ügyfélélményt az ajánlat előzetes verziójában:

1. Indítsa el a tesztmeghajtót a felhasználói felületen.

2. Nyissa meg Azure-előfizetését az Azure Portalon.

3. Ellenőrizze, hogy a tesztmeghajtó megfelelően van-e üzembe helyezve.

   

Ne törölje az ügyfelek számára kiépített tesztmeghajtó-példányokat; a tesztmeghajtó szolgáltatás automatikusan törli ezeket az erőforráscsoportokat, miután az ügyfél befejezte azt.

Ha már megfelel az előzetes verziós ajánlatának, ideje élőben is élni! Van egy végső felülvizsgálati folyamat, amely a teljes teljes felhasználói élményt duplán ellenőrzi. Ha elutasítjuk az ajánlatot, e-mailben elküldjük az ajánlat műszaki kapcsolattartójának, hogy elmagyarázza, mit kell kijavítani.

Következő lépések

• Ha a Partnerközpontban az ajánlat létrehozásához szükséges utasításokat követte, a Vissza nyíllal térjen vissza a témakörhöz.
• További információ a tesztmeghajtók egyéb típusairól a Mi az a tesztmeghajtó?