Version d’évaluation d’Azure Resource Manager

Article
05/20/2024

Important

La version d’évaluation a déjà été déconseillée. En guise d’alternative aux versions d’évaluation, nous vous encourageons à envisager de passer à des essais gratuits, ce qui offre aux clients la possibilité de s’engager pleinement avec votre produit à l’aide de leurs paramètres et configurations personnalisés, répondant à leurs exigences spécifiques. Nous vous recommandons de supprimer les versions d’évaluation de vos offres et de propre vos environnements de version d’évaluation. Utilisez ce type si vous disposez d’une offre sur la Place de marché Azure ou AppSource, mais que vous souhaitez créer une version d’évaluation uniquement avec des ressources Azure. Un modèle ARM (Azure Resource Manager) est un conteneur codé de ressources Azure que vous concevez pour représenter votre solution de la meilleure façon. La version d’évaluation prend le modèle ARM fourni et déploie toutes les ressources nécessaires sur un groupe de ressources. Il s’agit de la seule option de version d’évaluation pour les offres de machines virtuelles ou d’applications Azure.

Si vous n’êtes pas familiarisé avec ce qu’est un modèle ARM, lisez Qu’est-ce qu’Azure Resource Manager ? et découvrez la structure et la syntaxe des modèles ARM pour mieux comprendre comment générer et tester vos propres modèles.

Pour plus d’informations sur ce qu’est une version d’évaluation hébergée ou d’application logique, consultez Qu’est-ce qu’une version d’évaluation ?

Conseil

Pour voir la vue client du test drive dans la place de marché commerciale, consultez Qu’est-ce que la Place de marché Azure et Qu’est-ce que Microsoft AppSource ?.

Configuration technique

Un modèle de déploiement contient toutes les ressources Azure constituant votre solution. Les produits adaptés à ce scénario utilisent uniquement des ressources Azure. Définissez les propriétés suivantes dans l’Espace partenaires :

Régions (obligatoire) : à l’heure actuelle, vous pouvez mettre votre version d’évaluation à disposition dans 26 régions Azure. Pour de meilleures performances, nous vous recommandons de choisir une région dans laquelle vous vous attendez à trouver le plus grand nombre de clients. Vous devez vous assurer que votre abonnement est autorisé à déployer toutes les ressources nécessaires dans chacune des régions que vous sélectionnez.
Instances : sélectionnez le type (chaud ou froid) et le nombre d’instances disponibles, qui seront multipliés par le nombre de régions où votre offre sera disponible.
- Chaud : ce type d’instance est déployé et en attente de l’accès par région sélectionnée. Les clients peuvent accéder instantanément aux instances à chaud d’une version d’évaluation au lieu d’attendre un déploiement. Le compromis est que ces instances sont toujours en cours d’exécution sur votre abonnement Azure, afin qu’elles entraînent un coût de temps d’activité plus élevé. Il est vivement recommandé d’avoir au moins une instance à chaud, car la plupart des clients ne souhaitent pas attendre les déploiements complets, ce qui entraîne une suppression de l’utilisation du client si aucune instance à chaud n’est disponible.
- Froid : ce type d’instance représente le nombre total d’instances pouvant éventuellement être déployées par région. Les instances à froid nécessitent le modèle Resource Manager entier de la version d’évaluation pour être déployées lorsqu’un client demande la version d’évaluation, les instances à froid sont donc plus lentes à charger que les instances à chaud. Le compromis est que vous n’avez à payer que pour la durée de la version d’évaluation, il n’est pas* toujours en cours d’exécution sur votre abonnement Azure comme avec une instance hot .
Version d’évaluation du modèle Azure Resource Manager – Chargez le fichier .zip contenant votre modèle Azure Resource Manager. Apprenez-en plus sur la création d’un modèle Azure Resource Manager dans l’article de démarrage rapide Créer et déployer des modèles Azure Resource Manager à l’aide du portail Azure.

Remarque

Pour une publication réussie, il est important de valider la mise en forme du modèle ARM. Pour ce faire, il existe deux méthodes : (1) en utilisant un outil API en ligne ou (2) avec un déploiement de test.
Durée de la version d’évaluation (obligatoire) – Entrez le nombre d’heures durant lesquelles la version d’évaluation restera active. La version d’évaluation se termine automatiquement à la fin de cette période. Utilisez uniquement des nombres entiers (par exemple, « 2 » heures est valide, « 1,5 » n’est pas).

Écrire le modèle de version d’évaluation

Une fois que vous avez conçu le package de ressources souhaité, écrivez et générez le modèle ARM de version d’évaluation. La version d’évaluation exécutant des déploiements dans un mode entièrement automatisé, les modèles de version d’évaluation ont certaines restrictions :

Paramètres

La plupart des modèles ont un ensemble de paramètres qui définissent les noms de ressources, les tailles de ressources (telles que les types de comptes de stockage ou les tailles de machine virtuelle), les noms d’utilisateur et les mots de passe, les noms DNS et ainsi de suite. Lorsque vous déployez des solutions à l’aide du portail Azure, vous pouvez manuellement remplir tous ces paramètres, choisir des noms DNS disponibles ou des noms de compte de stockage et ainsi de suite.

Liste des paramètres dans Azure Resource Manager

Toutefois, la version d’évaluation fonctionne automatiquement, sans intervention humaine. Elle prend donc en charge un ensemble limité de catégories de paramètres. Si un paramètre dans le modèle ARM de version d’évaluation n’entre pas dans l’une des catégories prises en charge, vous devez le remplacer par une variable ou une valeur constante.

Vous pouvez utiliser n’importe quel nom valide pour vos paramètres ; la version d’évaluation reconnaît la catégorie d’un paramètre à l’aide d’une valeur metadata-type. Spécifiez le type de métadonnées pour chaque paramètre de modèle, sinon votre modèle ne passera pas de validation :

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

Remarque

Tous les paramètres sont facultatifs. Vous n’êtes pas obligé d’en utiliser si vous ne le souhaitez pas.

Types de métadonnées de paramètres acceptés

Type de métadonnées	Type de paramètre	Description	Exemple de valeur
baseuri	string	URI de base de votre package de déploiement	`https://<..>.blob.core.windows.net/<..>`
username	string	Nouveau nom d’utilisateur aléatoire.	admin68876
mot de passe	chaîne sécurisée	Nouveau mot de passe aléatoire	Lp!ACS^2kh
ID de la session	string	ID de session unique de la version d’évaluation (GUID)	b8c8693e-5673-449c-badd-257a405a6dee

baseuri

La version d’évaluation initialise ce paramètre avec un URI de base de votre package de déploiement ; vous pouvez donc utiliser ce paramètre pour construire un URI de tous les fichiers inclus dans votre package.

Remarque

Le baseUri paramètre ne peut pas être utilisé conjointement avec une extension de script personnalisé.

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

Utilisez ce paramètre à l’intérieur de votre modèle pour construire un URI de n’importe quel fichier à partir du package de déploiement de votre version d’évaluation. L’exemple suivant montre comment construire un URI du modèle lié :

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

username

La version d’évaluation initialise ce paramètre avec un nouveau nom d’utilisateur aléatoire :

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

Exemple de valeur : admin68876

Vous pouvez utiliser des noms d’utilisateur aléatoires ou constants pour votre solution.

mot de passe

La version d’évaluation initialise ce paramètre avec un nouveau mot de passe aléatoire :

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

Exemple de valeur : Lp!ACS^2kh

Vous pouvez utiliser des mots de passe aléatoires ou constants pour votre solution.

session ID

La version d’évaluation initialise ce paramètre avec un GUID unique représentant l’ID de session de la version d’évaluation :

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

Exemple de valeur : b8c8693e-5673-449c-badd-257a405a6dee

Vous pouvez utiliser ce paramètre pour identifier de façon unique la session de version d’évaluation, si nécessaire.

Noms uniques

Certaines ressources Azure, comme les comptes de stockage ou les noms DNS, exigent des noms globalement uniques. Autrement dit, chaque fois que la version d’évaluation déploie le modèle ARM, elle crée un groupe de ressources avec un nom unique pour toutes ses ressources. Par conséquent, vous devez utiliser la fonction uniquestring concaténée avec vos noms de variables sur les ID de groupes de ressources pour générer des valeurs uniques aléatoires :

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

Veillez à concaténer les chaînes de votre paramètre/variable (contosovm) avec une sortie de chaîne unique (resourceGroup().id), car cela garantit l’unicité et la fiabilité de chaque variable.

Par exemple, la plupart des noms de ressources ne peuvent pas commencer par un chiffre, mais une fonction de chaîne unique peut retourner une chaîne, qui commence par un chiffre. Par conséquent, si vous utilisez une sortie de chaîne unique brute, vos déploiements échoueront.

Vous trouverez des informations supplémentaires sur les règles et restrictions d’affectation de noms des ressources dans Développer votre stratégie d’affectation de noms et d’étiquetage pour les ressources Azure.

Emplacement de déploiement

Vous pouvez rendre votre version d’évaluation disponible dans plusieurs régions Azure.

Lorsque la version d’évaluation crée une instance du laboratoire, elle crée toujours un groupe de ressources dans l’une des régions sélectionnées, puis exécute votre modèle de déploiement dans le contexte de ce groupe. Par conséquent, votre modèle doit choisir l’emplacement de déploiement à partir du groupe de ressources :

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

Utilisez ensuite cet emplacement pour chaque ressource d’une instance de laboratoire spécifique :

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

Vérifiez que votre abonnement est autorisé à déployer toutes les ressources souhaitées dans chacune des régions sélectionnées. Vérifiez également que vos images de machine virtuelle sont disponibles dans toutes les régions que vous allez activer, sinon votre modèle de déploiement ne fonctionnera pas pour certaines régions.

Outputs

Normalement, avec des modèles Resource Manager, vous pouvez effectuer un déploiement sans produire de sortie. La raison est que vous connaissez toutes les valeurs que vous utilisez pour remplir les paramètres de modèle et vous pouvez toujours inspecter les propriétés de n’importe quelle ressource manuellement.

Toutefois, pour les modèles Resource Manager de version d’évaluation, il est important de retourner toutes les informations à la version d’évaluation ; elles sont exigées pour obtenir l’accès au laboratoire (URI de site web, noms d’hôte de machine virtuelle, noms d’utilisateur et mots de passe). Vérifiez que vos noms de sortie sont lisibles, car ces variables sont présentées au client.

Il n’existe aucune restriction liée aux sorties de modèle. La version d’évaluation convertit toutes les valeurs de sortie en chaînes. Par conséquent, si vous envoyez un objet vers la sortie, un utilisateur verra une chaîne JSON.

Exemple :

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

Limites d’abonnement

N’oubliez pas les limites du service et de l’abonnement. Par exemple, si vous souhaitez déployer jusqu’à dix machines virtuelles à quatre cœurs, vous devez vous assurer que l’abonnement que vous utilisez pour votre laboratoire vous permet d’utiliser 40 cœurs. Pour plus d’informations sur les limites applicables aux services et aux abonnements Azure, consultez Abonnement Azure et limites, quotas et contraintes de service. Étant donné que plusieurs versions d’évaluation peuvent être faites en même temps, vérifiez que votre abonnement peut gérer le nombre de cœurs multiplié par le nombre total de versions d’évaluation simultanées pouvant être faites.

Les éléments à télécharger

Le modèle ARM de version d’évaluation est chargé sous la forme d’un fichier zip, pouvant inclure différents artefacts de déploiement, mais il doit inclure un fichier nommé main-template.json. Il s’agit du modèle de déploiement ARM utilisé par la version d’évaluation pour instancier un laboratoire. Si vous avez des ressources supplémentaires en plus de ce fichier, vous pouvez les référencer en tant que ressources externes à l’intérieur du modèle, ou les inclure dans le fichier zip.

Au cours de la certification de publication, la version d’évaluation décompresse votre package de déploiement et place son contenu dans un conteneur d’objets blob interne de la version d’évaluation. La structure du conteneur reflète la structure de votre package de déploiement :

package.zip	Conteneur d’objets blob de la version d’évaluation
`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`

Un URI de ce conteneur d’objets blob est appelé URI de Base. Chaque révision de votre laboratoire ayant son propre conteneur d’objets blob, elle a son propre URI de base. La version d’évaluation peut passer un URI de base de votre package de déploiement décompressé dans votre modèle par le biais des paramètres de modèle.

Exemples de transformation de modèle pour version d’évaluation

Le processus de transformation d’une architecture de ressources en modèle Resource Manager de version d’évaluation peut être décourageant. Pour obtenir une aide supplémentaire, consultez les exemples illustrant comment transformer au mieux les modèles de déploiement actuels dans l’article Qu’est-ce qu’une version d’évaluation ?.

Détails de l’abonnement de déploiement de la version d’évaluation

La dernière section à terminer consiste à pouvoir déployer automatiquement les versions d’évaluation en connectant votre abonnement Azure et votre ID Microsoft Entra.

Détails de l’abonnement de déploiement de la version d’évaluation

Obtenez un ID d’abonnement Azure. Ce paramètre accorde l’accès aux services Azure et au portail Azure. C’est dans l’abonnement que l’utilisation des ressources est signalée et que les services sont facturés. Si vous n’avez pas encore d’abonnement Azure distinct pour les versions d’évaluation uniquement, créez-en un. Vous pouvez rechercher des ID d’abonnements Azure (par exemple 1a83645ac-1234-5ab6-6789-1h234g764ghty1) en vous connectant au portail Azure et en sélectionnant Abonnements dans le menu de navigation de gauche.
Obtenez un ID de locataire Microsoft Entra. Si vous disposez déjà d’un ID de locataire, vous pouvez le trouver dans l’ID des propriétés>de l’ID> Microsoft Entra :

Si vous n’avez pas d’ID de locataire, créez-en un dans Microsoft Entra ID. Pour obtenir de l’aide sur la configuration d’un locataire, consultez Démarrage rapide : Configurer un locataire.
Approvisionnez l’application Microsoft Test-Drive sur votre locataire. Nous allons utiliser cette application pour effectuer des opérations sur vos ressources de version d’évaluation.
1. Si ce n’est pas déjà fait, installez le module Azure Az PowerShell.
2. Ajoutez le principal de service pour l’application Microsoft Test-Drive.
  1. Exécutez et fournissez Connect-AzAccount des informations d’identification pour vous connecter à votre compte Azure, ce qui nécessite le rôle intégré Microsoft Entra ID Global Administration istrator.
  2. Créez un nouveau principal de service : New-AzADServicePrincipal -ApplicationId d7e39695-0b24-441c-a140-047800a05ede -DisplayName 'Microsoft TestDrive'.
  3. Assurez-vous que le principal de service a été créé : Get-AzADServicePrincipal -DisplayName 'Microsoft TestDrive'.
Pour l’ID d’application Microsoft Entra, collez cet ID d’application : d7e39695-0b24-441c-a140-047800a05ede.
Pour Microsoft Entra App Key, car aucun secret n’est requis, insérez un secret factice, tel que « no-secret ».
Étant donné que nous utilisons l’application pour effectuer le déploiement sur l’abonnement, nous devons ajouter l’application en tant que contributeur sur l’abonnement, à partir de l’Portail Azure ou de PowerShell :
1. À partir du portail Azure :
  1. Sélectionnez l’abonnement utilisé pour la version d’évaluation.
  2. Sélectionnez Contrôle d’accès (IAM) .
  3. Sélectionner Ajouter> Ajouter une attribution de rôle.
  4. Sous l’onglet Rôle, sélectionnez Contributeur.
  5. Dans l’onglet Membres, sélectionnez Utilisateur, groupe ou principal de service, puis choisissez Sélectionner des membres.
  6. Sélectionnez le principal du service Microsoft TestDrive que vous avez créé précédemment.
  7. Dans l’onglet Passer en revue + affecter, sélectionnez Passer en revue + affecter pour affecter le rôle.
    
    Pour plus d’informations sur l’attribution de rôle, consultez Attribuer des rôles Azure à l’aide du Portail Azure
2. En cas d’utilisation de PowerShell :
  1. Exécutez la commande suivante pour obtenir l’object-id ServicePrincipal : (Get-AzADServicePrincipal -DisplayName 'Microsoft TestDrive').id.
  2. Exécutez la commande suivante avec l’ObjectId et l’ID d’abonnement : New-AzRoleAssignment -ObjectId <objectId> -RoleDefinitionName Contributor -Scope /subscriptions/<subscriptionId>.

Remarque

Avant de supprimer l’ancien appID, accédez au portail Azure, puis à Groupes de ressources, et recherchez CloudTry_. Vérifiez la colonne Événement lancé par.

Ne supprimez pas l’ancien appID, sauf si au moins une ressource (Nom d’opération) est définie sur Microsoft TestDrive.

Pour supprimer l’appID, dans le menu de navigation de gauche, sélectionnez Inscriptions d’applications Microsoft Entra ID>, puis l’onglet Toutes les applications. Choisissez votre application, puis sélectionnez Supprimer.

Republier

Maintenant que tous les champs de version d’évaluation sont renseignés, republiez votre offre. Une fois que votre version d’évaluation a réussi la certification, testez l’expérience du client dans la préversion de votre offre :

Démarrez une version d’évaluation dans l’interface utilisateur.
Ouvrez votre abonnement Azure dans le portail Azure.
Vérifiez que votre version d’évaluation est correctement déployée.

Ne supprimez aucune instance de version d’évaluation provisionnée pour vos clients ; le service de version d’évaluation nettoiera automatiquement ces groupes de ressources une fois qu’un client aura terminé de les utiliser.

Une fois que vous êtes à l’aise avec votre offre en préversion, il est temps d’aller en direct ! Il existe un processus de révision final pour doubler case activée l’expérience de bout en bout. Si nous rejetons l’offre, nous envoyons un e-mail au contact d’ingénierie pour votre offre expliquant ce qui doit être résolu.

Étapes suivantes

Si vous suiviez les instructions pour créer votre offre dans l’Espace partenaires, utilisez la flèche Précédent pour revenir à cette rubrique.
Apprenez-en davantage sur les autres types de versions d’évaluation dans Qu’est-ce qu’une version d’évaluation ?.

Share via

Version d’évaluation d’Azure Resource Manager

Configuration technique

Écrire le modèle de version d’évaluation

Paramètres

Types de métadonnées de paramètres acceptés

baseuri

username

mot de passe

session ID

Noms uniques

Emplacement de déploiement

Outputs

Limites d’abonnement

Les éléments à télécharger

Exemples de transformation de modèle pour version d’évaluation

Détails de l’abonnement de déploiement de la version d’évaluation

Republier

Étapes suivantes

Commentaires

Commentaires

Ressources supplémentaires