Delen via

Azure Resource Manager-teststation

  • Artikel

Notitie

Test drive is al afgeschaft. Als alternatief voor Test Drives raden we u aan om over te stappen op gratis proefversies, die klanten de mogelijkheid biedt om volledig te communiceren met uw product met behulp van hun persoonlijke instellingen en configuraties, die voldoen aan hun specifieke vereisten. U wordt aangeraden teststations uit uw aanbiedingen te verwijderen en uw testomgevingen op te schonen.

Gebruik dit type als u een aanbieding hebt op Azure Marketplace of AppSource, maar een teststation wilt bouwen met alleen Azure-resources. Een ARM-sjabloon (Azure Resource Manager) is een gecodeerde container met Azure-resources die u ontwerpt om uw oplossing het beste weer te geven. Teststation maakt gebruik van de opgegeven ARM-sjabloon en implementeert alle resources die nodig zijn voor een resourcegroep. Dit is de enige test drive-optie voor aanbiedingen voor virtuele machines of Azure-apps.

Als u niet bekend bent met wat een ARM-sjabloon is, leest u Wat is Azure Resource Manager? en begrijpt u de structuur en syntaxis van ARM-sjablonen om beter inzicht te krijgen in het bouwen en testen van uw eigen sjablonen.

Zie Wat is een teststation voor een gehoste of logische app voor informatie over een teststation?

Tip

Zie Wat is Azure Marketplace? en wat is Microsoft AppSource? als u de weergave van de testrit van de klant in de commerciële marketplace wilt bekijken.

Technische configuratie

Een implementatiesjabloon bevat alle Azure-resources waaruit uw oplossing bestaat. Producten die in dit scenario passen, maken alleen gebruik van Azure-resources. Stel de volgende eigenschappen in partnercentrum in:

  • Regio's (vereist): momenteel zijn er 26 door Azure ondersteunde regio's waar uw teststation beschikbaar kan worden gesteld. Voor de beste prestaties raden we u aan om één regio te kiezen waarin u verwacht dat het grootste aantal klanten zich bevindt. U moet ervoor zorgen dat uw abonnement alle benodigde resources mag implementeren in elk van de regio's die u selecteert.

  • Exemplaren : selecteer het type (dynamisch of koud) en het aantal beschikbare exemplaren, dat wordt vermenigvuldigd met het aantal regio's waar uw aanbieding beschikbaar is.

    • Dynamisch : dit type exemplaar wordt geïmplementeerd en wacht op toegang per geselecteerde regio. Klanten hebben direct toegang tot hot-exemplaren van een teststation, in plaats van te wachten op een implementatie. Het nadeel is dat deze exemplaren altijd worden uitgevoerd op uw Azure-abonnement, zodat ze een grotere uptimekosten met zich meebrengt. Het wordt ten zeerste aanbevolen om ten minste één hot-exemplaar te hebben, omdat de meeste klanten niet willen wachten op volledige implementaties, wat resulteert in een drop-off in het gebruik van klanten als er geen hot-exemplaar beschikbaar is.

    • Koud : dit type exemplaar vertegenwoordigt het totale aantal exemplaren dat mogelijk per regio kan worden geïmplementeerd. Voor koude exemplaren is de volledige Resource Manager-sjabloon teststation vereist om te implementeren wanneer een klant het teststation aanvraagt, zodat koude exemplaren veel langzamer zijn te laden dan hot-exemplaren . Het nadeel is dat u alleen hoeft te betalen voor de duur van de testrit, het wordt niet* altijd uitgevoerd op uw Azure-abonnement, net als bij een Hot-exemplaar .

  • Azure Resource Manager-sjabloon testen: upload de .zip met uw Azure Resource Manager-sjabloon. Meer informatie over het maken van een Azure Resource Manager-sjabloon vindt u in het quickstart-artikel Azure Resource Manager-sjablonen maken en implementeren met behulp van Azure Portal.

    Notitie

    Als u wilt publiceren, is het belangrijk dat u de opmaak van de ARM-sjabloon valideert. Twee manieren om dit te doen, zijn (1) met behulp van een online API-hulpprogramma of (2) met een testimplementatie.

  • Duur van testrit (vereist): voer het aantal uren in dat de testrit actief blijft. Het teststation wordt automatisch beëindigd nadat deze periode is beëindigd. Gebruik alleen gehele getallen (bijvoorbeeld '2' uur is geldig, '1,5' is niet).

De sjabloon voor het teststation schrijven

Zodra u het gewenste pakket met resources hebt ontworpen, schrijft en bouwt u de ARM-sjabloon voor het teststation. Omdat teststation implementaties uitvoert in een volledig geautomatiseerde modus, hebben teststationsjablonen enkele beperkingen:

Parameters

De meeste sjablonen hebben een set parameters waarmee resourcenamen, resourcegrootten (zoals typen opslagaccounts of grootten van virtuele machines), gebruikersnamen en wachtwoorden, DNS-namen enzovoort worden gedefinieerd. Wanneer u oplossingen implementeert met behulp van Azure Portal, kunt u al deze parameters handmatig vullen, beschikbare DNS-namen of opslagaccountnamen kiezen, enzovoort.

Lijst met parameters in Een Azure Resource Manager

Test drive werkt echter automatisch, zonder menselijke interactie, dus het ondersteunt alleen een beperkte set parametercategorieën. Als een parameter in de ARM-sjabloon voor teststations niet in een van de ondersteunde categorieën valt, moet u deze parameter vervangen door een variabele of constante waarde.

U kunt elke geldige naam voor uw parameters gebruiken; test drive herkent parametercategorie met behulp van een waarde voor het metagegevenstype. Geef het metagegevenstype op voor elke sjabloonparameter, anders wordt de validatie van de sjabloon niet doorgegeven:

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

Notitie

Alle parameters zijn optioneel, dus als u geen parameters wilt gebruiken, hoeft u dat niet te doen.

Metagegevenstypen geaccepteerde parameters

Metagegevenstype Parametertype Beschrijving Voorbeeldwaarde
baseuri tekenreeks Basis-URI van uw implementatiepakket https://<..>.blob.core.windows.net/<..>
Gebruikersnaam tekenreeks Nieuwe willekeurige gebruikersnaam. admin68876
password beveiligde tekenreeks Nieuw willekeurig wachtwoord Lp! ACS^2kh
sessie-id tekenreeks Unieke sessie-id van teststation (GUID) b8c8693e-5673-449c-badd-257a405a6dee

baseuri

Teststation initialiseert deze parameter met een basis-URI van uw implementatiepakket, zodat u deze parameter kunt gebruiken om een URI te maken van elk bestand dat in uw pakket is opgenomen.

Notitie

De baseUri parameter kan niet worden gebruikt in combinatie met een aangepaste scriptextensie.

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

Gebruik deze parameter in uw sjabloon om een URI van elk bestand te maken vanuit het implementatiepakket voor teststations. In het volgende voorbeeld ziet u hoe u een URI van de gekoppelde sjabloon maakt:

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

gebruikersnaam

Test drive initialiseert deze parameter met een nieuwe willekeurige gebruikersnaam:

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

Voorbeeldwaarde: admin68876

U kunt willekeurige of constante gebruikersnamen gebruiken voor uw oplossing.

password

Teststation initialiseert deze parameter met een nieuw willekeurig wachtwoord:

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

Voorbeeldwaarde: Lp!ACS^2kh

U kunt willekeurige of constante wachtwoorden gebruiken voor uw oplossing.

sessie-id

Teststation initialiseert deze parameter met een unieke GUID die de sessie-id teststation vertegenwoordigt:

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

Voorbeeldwaarde: b8c8693e-5673-449c-badd-257a405a6dee

U kunt deze parameter gebruiken om de test drive-sessie uniek te identificeren, indien nodig.

Unieke namen

Voor sommige Azure-resources, zoals opslagaccounts of DNS-namen, zijn wereldwijd unieke namen vereist. Dit betekent dat telkens wanneer het teststation de ARM-sjabloon implementeert, er een nieuwe resourcegroep wordt gemaakt met een unieke naam voor alle resources. Daarom moet u de functie uniquestring gebruiken die is samengevoegd met uw variabelenamen op resourcegroep-id's om willekeurige unieke waarden te genereren:

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

Zorg ervoor dat u de tekenreeksen voor parameters/variabelen (contosovm) samenvoegt met een unieke tekenreeksuitvoer (resourceGroup().id), omdat dit de uniekheid en betrouwbaarheid van elke variabele garandeert.

De meeste resourcenamen kunnen bijvoorbeeld niet beginnen met een cijfer, maar de unieke tekenreeksfunctie kan een tekenreeks retourneren, die begint met een cijfer. Als u dus onbewerkte unieke tekenreeksuitvoer gebruikt, mislukken uw implementaties.

Meer informatie over naamgevingsregels en beperkingen voor resources vindt u in De strategie voor naamgeving en taggen ontwikkelen voor Azure-resources.

Implementatielocatie

U kunt uw teststation beschikbaar maken in verschillende Azure-regio's.

Wanneer een teststation een exemplaar van het lab maakt, wordt er altijd een resourcegroep gemaakt in een van de geselecteerde regio's en wordt vervolgens uw implementatiesjabloon in deze groepscontext uitgevoerd. Uw sjabloon moet dus de implementatielocatie uit de resourcegroep kiezen:

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

Gebruik vervolgens deze locatie voor elke resource voor een specifiek lab-exemplaar:

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

Zorg ervoor dat uw abonnement alle gewenste resources mag implementeren in elk van de regio's die u selecteert. Zorg er ook voor dat uw installatiekopieën van virtuele machines beschikbaar zijn in alle regio's die u inschakelt, anders werkt uw implementatiesjabloon niet voor sommige regio's.

Uitvoerwaarden

Normaal gesproken kunt u met Resource Manager-sjablonen implementeren zonder uitvoer te produceren. Dit komt doordat u alle waarden kent die u gebruikt om sjabloonparameters te vullen en u altijd handmatig eigenschappen van elke resource kunt inspecteren.

Voor Resource Manager-sjablonen voor teststations is het echter belangrijk om terug te keren naar alle informatie die nodig is om toegang te krijgen tot het lab (website-URI's, hostnamen van virtuele machines, gebruikersnamen en wachtwoorden). Zorg ervoor dat al uw uitvoernamen leesbaar zijn omdat deze variabelen aan de klant worden gepresenteerd.

Er zijn geen beperkingen met betrekking tot sjabloonuitvoer. Teststation converteert alle uitvoerwaarden naar tekenreeksen, dus als u een object naar de uitvoer verzendt, ziet een gebruiker de JSON-tekenreeks.

Voorbeeld:

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

Abonnementslimieten

Vergeet niet de abonnements- en servicelimieten. Als u bijvoorbeeld maximaal tien virtuele machines met vier kernen wilt implementeren, moet u ervoor zorgen dat het abonnement dat u voor uw lab gebruikt, 40 kernen kunt gebruiken. Zie Azure-abonnements- en servicelimieten, quota en beperkingen voor Azure-abonnementen en -services voor meer informatie over Azure-abonnements- en servicelimieten. Aangezien er tegelijkertijd meerdere teststations kunnen worden genomen, controleert u of uw abonnement het aantal kernen kan verwerken dat wordt vermenigvuldigd met het totale aantal gelijktijdige teststations dat kan worden genomen.

Wat u wilt uploaden

De ARM-sjabloon voor het teststation wordt geüpload als een zip-bestand, dat verschillende implementatieartefacten kan bevatten, maar moet één bestand hebben met de naam main-template.json. Dit is de ARM-implementatiesjabloon die wordt gebruikt om een lab te instantiëren. Als u meer resources dan dit bestand hebt, kunt u ernaar verwijzen als externe resources in de sjabloon of opnemen in het zip-bestand.

Tijdens de publicatiecertificering pakt het teststation uw implementatiepakket uit en plaatst u de inhoud ervan in een interne blobcontainer voor teststations. De containerstructuur weerspiegelt de structuur van uw implementatiepakket:

package.zip Blobcontainer voor teststation
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

We noemen een URI van deze blobcontainer base-URI. Omdat elke revisie van uw lab een eigen blobcontainer heeft, heeft elke revisie van uw lab een eigen Basis-URI. Teststation kan een basis-URI van uw uitgepakte implementatiepakket doorgeven aan uw sjabloon via sjabloonparameters.

Voorbeelden van transformatiesjablonen voor test drive

Het proces voor het omzetten van een architectuur van resources in een Resource Manager-teststationsjabloon kan lastig zijn. Zie deze voorbeelden van hoe u de huidige implementatiesjablonen het beste kunt transformeren op Wat is een testrit? voor aanvullende hulp.

Details van implementatieabonnement op teststation

De laatste sectie die moet worden voltooid, is het automatisch implementeren van de teststations door uw Azure-abonnement en Microsoft Entra-id te verbinden.

Details van implementatieabonnement op teststation

  1. Haal een Azure-abonnements-id op. Hiermee verleent u toegang tot Azure-services en Azure Portal. Het abonnement is waar resourcegebruik wordt gerapporteerd en services worden gefactureerd. Als u nog geen afzonderlijk Azure-abonnement voor teststations hebt, maakt u er een. U vindt Azure-abonnements-id's (zoals 1a83645ac-1234-5ab6-6789-1h234g764ghty1) door u aan te melden bij Azure Portal en abonnementen te selecteren in het linkernavigatiemenu.

    Azure-abonnementen

  2. Haal een Microsoft Entra-tenant-id op. Als u al een tenant-id hebt, kunt u deze vinden in de map-id eigenschappen>van Microsoft Entra-id:>

    Eigenschappen van Microsoft Entra

    Als u geen tenant-id hebt, maakt u een nieuwe in Microsoft Entra-id. Zie quickstart: Een tenant instellen voor hulp bij het instellen van een tenant.

  3. Richt de Microsoft Test Drive-toepassing in op uw tenant. We gebruiken deze toepassing om bewerkingen uit te voeren op uw teststationresources.

    1. Als u deze nog niet hebt, installeert u de Azure Az PowerShell-module.
    2. Voeg de service-principal voor de Microsoft Test Drive-toepassing toe.
      1. Voer Connect-AzAccount referenties uit om u aan te melden bij uw Azure-account. Hiervoor is de ingebouwde rol microsoft Entra ID Global Beheer istratorvereist.
      2. Maak een nieuwe service-principal: New-AzADServicePrincipal -ApplicationId d7e39695-0b24-441c-a140-047800a05ede -DisplayName 'Microsoft TestDrive'.
      3. Zorg ervoor dat de service-principal is gemaakt: Get-AzADServicePrincipal -DisplayName 'Microsoft TestDrive'. Geeft de code weer om de service-principal te verifiëren

  4. Plak voor Microsoft Entra App ID deze toepassings-id: d7e39695-0b24-441c-a140-047800a05ede.

  5. Voor Microsoft Entra App Key, omdat er geen geheim is vereist, voegt u een dummygeheim in, zoals 'geen geheim'.

  6. Omdat we de toepassing gebruiken om te implementeren in het abonnement, moeten we de toepassing toevoegen als inzender voor het abonnement, vanuit de Azure-portal of PowerShell:

    1. Vanuit de Azure-portal:

      1. Selecteer het abonnement dat wordt gebruikt voor het teststation.

      2. Klik op Toegangsbeheer (IAM) .

      3. Selecteer Roltoewijzing toevoegen.>

      4. Selecteer Inzender op het tabblad Rol.

      5. Selecteer op het tabblad Leden de optie Gebruiker, groep of service-principal en kies Leden selecteren.

      6. Selecteer de Microsoft TestDrive-service-principal die u eerder hebt gemaakt.

      7. Selecteer op het tabblad Beoordelen en toewijzen de optie Beoordelen en toewijzen om de rol toe te wijzen.

        Zie Azure-rollen toewijzen met behulp van Azure Portal voor meer informatie over roltoewijzingen

    2. Als u PowerShell gebruikt:

      1. Voer deze opdracht uit om de ServicePrincipal-object-id op te halen: (Get-AzADServicePrincipal -DisplayName 'Microsoft TestDrive').id.
      2. Voer dit uit met de ObjectId en abonnements-id: New-AzRoleAssignment -ObjectId <objectId> -RoleDefinitionName Contributor -Scope /subscriptions/<subscriptionId>.

Notitie

Voordat u de oude appID verwijdert, gaat u naar Azure Portal, vervolgens naar resourcegroepen en zoekt u naar CloudTry_. Controleer de gebeurtenis die is geïnitieerd door de kolom.

Toont het veld Gebeurtenis geïnitieerd door

Verwijder de oude appID alleen als ten minste één resource (bewerkingsnaam) is ingesteld op Microsoft TestDrive.

Als u de appID wilt verwijderen, selecteert u in het linkernavigatiemenu Microsoft Entra ID-app-registraties> en vervolgens op het tabblad Alle toepassingen. Kies uw toepassing en selecteer Verwijderen.

Opnieuw publiceren

Nu alle velden voor het teststation zijn voltooid, publiceert u uw aanbieding opnieuw. Zodra uw test drive is gecertificeerd, test u de klantervaring in de preview van uw aanbieding:

  1. Start een teststation in de gebruikersinterface.

  2. Open uw Azure-abonnement in Azure Portal.

  3. Controleer of uw teststation correct wordt geïmplementeerd.

    Azure Portal

Verwijder geen teststationexemplaren die zijn ingericht voor uw klanten; de test drive-service schoont deze resourcegroepen automatisch op nadat een klant ermee klaar is.

Zodra u vertrouwd bent met uw preview-aanbieding, is het tijd om live te gaan! Er is een laatste beoordelingsproces om de volledige end-to-end ervaring te controleren. Als we de aanbieding afwijzen, sturen we de technische contactpersoon voor uw aanbieding een e-mail waarin wordt uitgelegd wat er moet worden opgelost.

Volgende stappen

  • Als u de instructies voor het maken van uw aanbieding in partnercentrum volgt, gebruikt u de pijl Terug om terug te keren naar dat onderwerp.
  • Meer informatie over andere typen teststations op Wat is een testrit?