Dela via

Azure Resource Manager-testenhet

  • Artikel

Kommentar

Testkörningen är redan inaktuell. Som ett alternativ till Provkörning rekommenderar vi att du överväger att övergå till kostnadsfria utvärderingsversioner, vilket ger kunderna möjlighet att fullt ut interagera med din produkt med hjälp av deras anpassade inställningar och konfigurationer, vilket uppfyller deras specifika krav. Vi rekommenderar att du tar bort testenheter från dina erbjudanden och rensar testkörningsmiljöerna.

Använd den här typen om du har ett erbjudande på Azure Marketplace eller AppSource men vill skapa en provkörning med endast Azure-resurser. En ARM-mall (Azure Resource Manager) är en kodad container med Azure-resurser som du utformar för att bäst representera din lösning. Testenheten tar den angivna ARM-mallen och distribuerar alla resurser som krävs till en resursgrupp. Det här är det enda testenhetsalternativet för erbjudanden för virtuella datorer eller Azure-appar.

Om du inte känner till vad en ARM-mall är läser du Vad är Azure Resource Manager? och Förstå strukturen och syntaxen för ARM-mallar för att bättre förstå hur du skapar och testar dina egna mallar.

Information om en värdbaserad testenhet eller logikapp finns i Vad är en testenhet?

Dricks

Om du vill se kundens vy över provkörning på den kommersiella marknadsplatsen läser du Vad är Azure Marketplace? och Vad är Microsoft AppSource?.

Teknisk konfiguration

En distributionsmall innehåller alla Azure-resurser som ingår i din lösning. Produkter som passar det här scenariot använder endast Azure-resurser. Ange följande egenskaper i Partnercenter:

  • Regioner (krävs) – För närvarande finns det 26 Azure-stödda regioner där din testenhet kan göras tillgänglig. För bästa prestanda rekommenderar vi att du väljer en region där du förväntar dig att det största antalet kunder ska finnas. Du måste se till att din prenumeration tillåts distribuera alla resurser som behövs i var och en av de regioner som du väljer.

  • Instanser – Välj typ (varm eller kall) och antalet tillgängliga instanser, som multipliceras med antalet regioner där ditt erbjudande är tillgängligt.

    • Frekvent – Den här typen av instans distribueras och väntar på åtkomst per vald region. Kunder kan omedelbart komma åt frekventa instanser av en provkörning i stället för att behöva vänta på en distribution. Kompromissen är att dessa instanser alltid körs på din Azure-prenumeration, så de medför en större drifttidskostnad. Vi rekommenderar starkt att du har minst en frekvent instans, eftersom de flesta kunder inte vill vänta på fullständiga distributioner, vilket resulterar i en avlämning i kundanvändningen om ingen frekvent instans är tillgänglig.

    • Cold – Den här typen av instans representerar det totala antalet instanser som eventuellt kan distribueras per region. Kalla instanser kräver att hela Test Drive Resource Manager-mallen distribueras när en kund begär testenheten, så kalla instanser är mycket långsammare att läsa in än frekventa instanser. Kompromissen är att du bara behöver betala under testkörningens varaktighet, det är inte* alltid körs på din Azure-prenumeration som med en frekvent instans.

  • Testkör Azure Resource Manager-mall – Ladda upp .zip som innehåller din Azure Resource Manager-mall. Läs mer om att skapa en Azure Resource Manager-mall i snabbstartsartikeln Skapa och distribuera Azure Resource Manager-mallar med hjälp av Azure Portal.

    Kommentar

    För att publicera är det viktigt att verifiera formateringen av ARM-mallen. Två sätt att göra detta är (1) med hjälp av ett API-onlineverktyg eller (2) med en testdistribution.

  • Varaktighet för provkörning (krävs) – Ange hur många timmar provenheten ska vara aktiv. Provkörningen avslutas automatiskt när den här tidsperioden är slut. Använd endast heltal (till exempel är "2" timmar giltiga, "1,5" är inte).

Skriva testenhetsmallen

När du har utformat önskat resurspaket skriver och skapar du ARM-mallen för testenheten. Eftersom testenheten kör distributioner i ett helt automatiserat läge har testenhetsmallar vissa begränsningar:

Parametrar

De flesta mallar har en uppsättning parametrar som definierar resursnamn, resursstorlekar (till exempel typer av lagringskonton eller storlekar på virtuella datorer), användarnamn och lösenord, DNS-namn och så vidare. När du distribuerar lösningar med hjälp av Azure Portal kan du fylla i alla dessa parametrar manuellt, välja tillgängliga DNS-namn eller lagringskontonamn och så vidare.

Lista över parametrar i en Azure Resource Manager

Provkörningen fungerar dock automatiskt, utan mänsklig interaktion, så den stöder bara en begränsad uppsättning parameterkategorier. Om en parameter i ARM-mallen för testenheten inte tillhör någon av de kategorier som stöds måste du ersätta den här parametern med en variabel eller ett konstant värde.

Du kan använda valfritt giltigt namn för dina parametrar. testenheten identifierar parameterkategorin med hjälp av ett värde av metadatatyp. Ange metadatatyp för varje mallparameter, annars godkänns inte valideringen av mallen:

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

Kommentar

Alla parametrar är valfria, så om du inte vill använda några behöver du inte göra det.

Metadatatyper för godkända parametrar

Metadatatyp Parametertyp beskrivning Exempelvärde
baseuri sträng Bas-URI för distributionspaketet https://<..>.blob.core.windows.net/<..>
användarnamn sträng Nytt slumpmässigt användarnamn. admin68876
lösenord säker sträng Nytt slumpmässigt lösenord Lp! ACS^2kh
sessions-ID sträng Unikt testkörningssessions-ID (GUID) b8c8693e-5673-449c-badd-257a405a6dee

baseuri

Testenheten initierar den här parametern med en bas-URI för distributionspaketet så att du kan använda den här parametern för att konstruera en URI för alla filer som ingår i paketet.

Kommentar

Parametern baseUri kan inte användas tillsammans med ett anpassat skripttillägg.

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

Använd den här parametern i mallen för att skapa en URI för valfri fil från distributionspaketet för testenheten. I följande exempel visas hur du skapar en URI för den länkade mallen:

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

användarnamn

Testenheten initierar den här parametern med ett nytt slumpmässigt användarnamn:

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

Exempelvärde: admin68876

Du kan använda antingen slumpmässiga eller konstanta användarnamn för din lösning.

password

Testenheten initierar den här parametern med ett nytt slumpmässigt lösenord:

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

Exempelvärde: Lp!ACS^2kh

Du kan använda antingen slumpmässiga eller konstanta lösenord för din lösning.

sessions-ID

Testenheten initierar den här parametern med ett unikt GUID som representerar testenhetssessions-ID:

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

Exempelvärde: b8c8693e-5673-449c-badd-257a405a6dee

Du kan använda den här parametern för att unikt identifiera testkörningssessionen om det behövs.

Unika namn

Vissa Azure-resurser, till exempel lagringskonton eller DNS-namn, kräver globalt unika namn. Det innebär att varje gång testenheten distribuerar ARM-mallen skapas en ny resursgrupp med ett unikt namn för alla dess resurser. Därför måste du använda funktionen uniquestring sammanfogad med dina variabelnamn på resursgrupps-ID:t för att generera slumpmässiga unika värden:

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

Se till att du sammanfogar dina parameter-/variabelsträngar (contosovm) med ett unikt strängutdata (resourceGroup().id), eftersom detta garanterar varje variabels unikhet och tillförlitlighet.

De flesta resursnamn kan till exempel inte börja med en siffra, men en unik strängfunktion kan returnera en sträng som börjar med en siffra. Om du använder råa unika strängutdata misslyckas distributionerna.

Du hittar ytterligare information om namngivningsregler och begränsningar för resurser i Utveckla din namngivnings- och taggningsstrategi för Azure-resurser.

Distributionsplats

Du kan göra din testenhet tillgänglig i olika Azure-regioner.

När en testenhet skapar en instans av labbet skapar den alltid en resursgrupp i en av de valda regionerna och kör sedan distributionsmallen i den här gruppkontexten. Mallen bör därför välja distributionsplats från resursgrupp:

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

Använd sedan den här platsen för varje resurs för en specifik labbinstans:

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

Se till att din prenumeration tillåts distribuera alla resurser som du vill ha i var och en av de regioner som du väljer. Se också till att dina avbildningar av virtuella datorer är tillgängliga i alla regioner som du aktiverar, annars fungerar inte distributionsmallen för vissa regioner.

Utdata

Normalt med Resource Manager-mallar kan du distribuera utan att generera några utdata. Det beror på att du känner till alla värden som du använder för att fylla i mallparametrar och du alltid kan inspektera egenskaperna för alla resurser manuellt.

För Resource Manager-mallar för provkörning är det dock viktigt att återgå till att provköra all information, vilket krävs för att få åtkomst till labbet (webbplats-URI:er, värdnamn för virtuella datorer, användarnamn och lösenord). Kontrollera att alla utdatanamn är läsbara eftersom dessa variabler visas för kunden.

Det finns inga begränsningar som rör mallutdata. Testenheten konverterar alla utdatavärden till strängar, så om du skickar ett objekt till utdata ser en användare JSON-sträng.

Exempel:

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

Prenumerationsgränser

Glöm inte prenumerations- och tjänstgränser. Om du till exempel vill distribuera upp till tio virtuella datorer med fyra kärnor måste du se till att prenumerationen som du använder för ditt labb gör att du kan använda 40 kärnor. Mer information om Azure-prenumerations- och tjänstgränser finns i Azure-prenumerations- och tjänstgränser, kvoter och begränsningar. Eftersom flera testenheter kan tas samtidigt kontrollerar du att din prenumeration kan hantera antalet kärnor multiplicerat med det totala antalet samtidiga testenheter som kan tas.

Ladda upp

ARM-mallen för testenheten laddas upp som en zip-fil, som kan innehålla olika distributionsartefakter, men måste ha en fil med namnet main-template.json. Det här är ARM-distributionsmallen som testenheten använder för att instansiera ett labb. Om du har ytterligare resurser utöver den här filen kan du referera till dem som externa resurser i mallen eller inkludera dem i zip-filen.

Under publiceringscertifieringen packar testenheten upp distributionspaketet och placerar innehållet i en intern testenhetsblobcontainer. Containerstrukturen återspeglar strukturen för distributionspaketet:

package.zip Testenhetsblobcontainer
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

Vi anropar en URI för den här blobcontainerns bas-URI. Eftersom varje revision av ditt labb har en egen blobcontainer har varje revision av labbet en egen Bas-URI. Testenheten kan skicka en bas-URI för ditt uppackade distributionspaket till mallen via mallparametrar.

Transformera mallexempel för provkörning

Det kan vara skrämmande att omvandla en resursarkitektur till en Resource Manager-mall för provkörning. Mer hjälp finns i de här exemplen på hur du bäst transformerar aktuella distributionsmallar på Vad är en testenhet?.

Information om distribution av testenhetsprenumeration

Det sista avsnittet att slutföra är att kunna distribuera testenheterna automatiskt genom att ansluta din Azure-prenumeration och Ditt Microsoft Entra-ID.

  1. Skaffa ett Azure-prenumerations-ID. Detta ger åtkomst till Azure-tjänster och Azure Portal. I prenumerationen rapporteras resursanvändning och tjänster faktureras. Om du inte redan har en separat Azure-prenumeration för endast testenheter skapar du en. Du hittar Azure-prenumerations-ID:t (till exempel 1a83645ac-1234-5ab6-6789-1h234g764ghty1) genom att logga in på Azure Portal och välja Prenumerationer på menyn till vänster.

    Azure-prenumerationer

  2. Skaffa ett Microsoft Entra-klient-ID. Om du redan har ett klient-ID tillgängligt kan du hitta det i Microsoft Entra ID>Properties>Directory ID:

    Microsoft Entra-egenskaper

    Om du inte har något klient-ID skapar du ett nytt i Microsoft Entra-ID. Hjälp med att konfigurera en klient finns i Snabbstart: Konfigurera en klientorganisation.

  3. Etablera Microsoft Test-Drive-programmet till din klientorganisation. Vi använder det här programmet för att utföra åtgärder på dina testenhetsresurser.

    1. Om du inte har den ännu installerar du Azure Az PowerShell-modulen.
    2. Lägg till tjänstens huvudnamn för Microsoft Test-Drive-programmet.

      1. Kör Connect-AzAccount och ange autentiseringsuppgifter för att logga in på ditt Azure-konto, vilket kräver minst Privilegierade Roller för Microsoft Entra-ID efter inbyggda uppgifter.

      2. Skapa ett nytt huvudnamn för tjänsten: New-AzADServicePrincipal -ApplicationId d7e39695-0b24-441c-a140-047800a05ede -DisplayName 'Microsoft TestDrive'.

      3. Kontrollera att tjänstens huvudnamn har skapats: Get-AzADServicePrincipal -DisplayName 'Microsoft TestDrive'. Visar koden för att verifiera tjänstens huvudnamn

  4. För Microsoft Entra-app-ID klistrar du in det här program-ID:t: d7e39695-0b24-441c-a140-047800a05ede.

  5. Eftersom ingen hemlighet krävs för Microsoft Entra-appnyckeln infogar du en dummyhemlighet, till exempel "ingen hemlighet".

  6. Eftersom vi använder programmet för att distribuera till prenumerationen måste vi lägga till programmet som deltagare i prenumerationen, från Azure Portal eller PowerShell:

    1. Från Azure-portalen:

      1. Välj den prenumeration som används för provkörningen.

      2. Välj Åtkomstkontroll (IAM) .

      3. Välj Lägg till lägg till > rolltilldelning.

      4. På fliken Roll väljer du Deltagare.

      5. På fliken Medlemmar väljer du Användare, grupp eller tjänstens huvudnamn och väljer sedan Välj medlemmar.

      6. Välj tjänstens huvudnamn för Microsoft TestDrive som du skapade tidigare.

      7. På fliken Granska + tilldela väljer du Granska + tilldela för att tilldela rollen.

        Mer information om rolltilldelningar finns i Tilldela Azure-roller med hjälp av Azure Portal

    2. Om du använder PowerShell:

      1. Kör detta för att hämta ServicePrincipal object-id: (Get-AzADServicePrincipal -DisplayName 'Microsoft TestDrive').id.
      2. Kör detta med ObjectId och prenumerations-ID: New-AzRoleAssignment -ObjectId <objectId> -RoleDefinitionName Contributor -Scope /subscriptions/<subscriptionId>.

Kommentar

Innan du tar bort det gamla appID:t går du till Azure Portal, sedan Resursgrupper och söker CloudTry_efter . Kontrollera händelsen som initierades av kolumnen.

Visar fältet Händelse initierad av

Ta inte bort det gamla appID:t om inte minst en resurs (åtgärdsnamn) har angetts till Microsoft TestDrive.

Om du vill ta bort appID går du till den vänstra navigeringsmenyn och väljer Microsoft Entra ID-appregistreringar> och sedan fliken Alla program. Välj ditt program och välj Ta bort.

Publicera om

Nu när alla testkörningsfält har slutförts publicerar du erbjudandet igen. När din provkörning har godkänts testar du kundupplevelsen i förhandsversionen av ditt erbjudande:

  1. Starta en provkörning i användargränssnittet.

  2. Öppna din Azure-prenumeration i Azure Portal.

  3. Kontrollera att testenheten distribueras korrekt.

    Azure Portal

Ta inte bort några provkörningsinstanser som etablerats för dina kunder. testkörningstjänsten rensar automatiskt dessa resursgrupper när en kund är klar med den.

När du är nöjd med ditt förhandsversionserbjudande är det dags att gå live! Det finns en slutlig granskningsprocess för att dubbelkolla hela upplevelsen från slutpunkt till slutpunkt. Om vi avvisar erbjudandet skickar vi ett e-postmeddelande till teknikkontakten för ditt erbjudande och förklarar vad som behöver åtgärdas.

Relaterat innehåll

  • Om du följde anvisningarna för att skapa ditt erbjudande i Partnercenter använder du bakåtpilen för att återgå till det ämnet.
  • Läs mer om andra typer av provkörningar på Vad är en provkörning?.