Gérer un spec de modèle

Effectué

Les specs de modèle offrent un moyen pratique de publier et partager des modèles au sein de votre organisation. À mesure que vous utilisez d’autres specs de modèle, il est important de comprendre comment les gérer.

Dans cette unité, vous découvrez le contrôle de version, comment modifier et supprimer des specs de modèle, et comment contrôler l’accès aux specs de modèle.

Notes

Les commandes de cette unité sont présentées pour illustrer les concepts. N’exécutez pas encore les commandes. Vous allez bientôt mettre en pratique ce que vous apprenez ici.

Ajouter des versions

Vous avez appris qu’une seule spécification de modèle peut avoir plusieurs versions. Un spec de modèle agit comme un conteneur pour une ou plusieurs versions, et chaque version est associée à un fichier de modèle. Lorsque vous déployez un spec de modèle, vous devez spécifier la version que vous souhaitez utiliser afin qu’Azure Resource Manager sache quel fichier de modèle récupérer.

Azure CLI et Azure PowerShell facilitent l’utilisation de plusieurs versions. En fait, vous avez déjà travaillé avec les versions lorsque vous avez déployé le spec de modèle dans l’exercice précédent.

Il est judicieux de planifier avec soin la façon dont vous allez gérer les versions de vos specs de modèle. Deux décisions clés à prendre sont le schéma de contrôle de version et la stratégie de contrôle de version à utiliser.

Schémas de contrôle de version

Votre schéma de contrôle de version détermine la façon dont vous générez les numéros de version. Les schémas de contrôle de version courants sont les suivants :

• Les entiers de base peuvent être utilisés comme numéros de version. Par exemple, votre première version peut être appelée 1, votre deuxième version 2, et ainsi de suite.
• Les dates font également de bons numéros de version. Par exemple, si vous publiez la première version de votre spec de modèle le 16 janvier 2021, vous pouvez nommer la version 2021-01-16 (en utilisant le format aaaa-mm-jj). Lorsque vous publiez une autre version le 3 mars, vous pouvez la nommer 2021-03-03.
• Le contrôle de version sémantique est un système de contrôle de version souvent utilisé dans les logiciels, où un seul numéro de version contient plusieurs parties. Chaque partie signale des informations différentes sur la nature de la modification.

Bien que vous puissiez utiliser n’importe quel schéma de contrôle de version, il est judicieux de choisir quelque chose qui peut être trié dans un ordre significatif tel que les nombres et les dates.

Remarque

Azure stocke la date de création de chaque version. Même si vous n’utilisez pas le contrôle de version basé sur la date, vous pouvez toujours voir ces informations.

Stratégies de contrôle de version

Les spécifications de modèle vous donnent la possibilité de choisir quand créer de nouvelles versions ou mettre à jour une version existante. Par exemple, vous pouvez désactiver le contrôle de version en créant et en publiant une version unique nommée latest. Chaque fois que vous devez modifier votre spec de modèle, il vous suffit de mettre à jour cette version. Bien que cette stratégie fonctionne, ce n’est pas une bonne pratique.

À l’inverse, si vous apportez une petite modification à un modèle existant qui n’affecte pas son utilisation, la création d’une nouvelle version n’est probablement pas une bonne idée. Vous devez communiquer le nouveau numéro de version à toute personne utilisant le spec de modèle.

Voici une stratégie de contrôle de version qui fonctionne souvent bien :

• Chaque fois que vous apportez des modifications importantes à un spec de modèle, créez une nouvelle version. Les modifications importantes apportées à votre spec de modèle incluent tout ce qui peut faire la différence avec l’utilisateur qui le déploie. Les exemples incluent l’ajout d’une autre ressource au modèle ou la modification des propriétés d’une ressource.
• Chaque fois que vous apportez des modifications mineures à un spec de modèle, ce qu’on appelle parfois correctif, mettez à jour la version de spec de modèle existante.
• Supprimez les anciennes versions lorsqu’elles ne sont plus pertinentes ou lorsque vous ne souhaitez pas que quiconque les utilise.

Conseil

Prenez en compte les utilisateurs de votre spec de modèle et veillez à réfléchir à ce à quoi ils s’attendront. Si un utilisateur déploie votre spec de modèle plusieurs fois et obtient un résultat, puis le déploie à nouveau après un correctif et obtient un résultat différent, il sera probablement surpris. Essayez de réduire la probabilité que vos utilisateurs obtiennent un résultat inattendu.

Descriptions des versions

Lorsque vous créez une nouvelle version d’un spec de modèle, vous pouvez éventuellement lui attribuer une description de version. Fournir une description de version est une bonne pratique, même s’il n’est pas nécessaire. La description de la version récapitule les modifications que vous avez apportées pour aider toute personne qui utilise votre spec de modèle pour sélectionner la version qui correspond le mieux à ses besoins.

Apporter des modifications à une spécification de modèle

Les spécifications de modèle sont des ressources Azure, ce qui vous permet de les gérer comme n’importe quelle autre ressource. Cela signifie que vous pouvez afficher les détails d’une spécification de modèle, la mettre à jour et la supprimer, comme normale.

Par exemple, pour répertorier les versions d’un spec de modèle, utilisez la cmdlet Get-AzTemplateSpec :

Get-AzTemplateSpec `
  -ResourceGroupName MyResourceGroup `
  -Name MyTemplateSpec

La même cmdlet est utilisée pour afficher une version de spec de modèle. Ajoutez le paramètre -Version pour obtenir les détails d’une version :

Get-AzTemplateSpec `
  -ResourceGroupName MyResourceGroup `
  -Name MyTemplateSpec `
  -Version 1.0

Vous pouvez accéder au modèle JSON en lisant la propriété MainTemplate à partir du tableau Versions :

(Get-AzTemplateSpec `
  -ResourceGroupName MyResourceGroup `
  -Name MyTemplateSpec `
  -Version 1.0 `
).Versions[0].MainTemplate

Par exemple, pour répertorier les versions d’un spec de modèle, utilisez la commande az ts show :

az ts show \
  --resource-group MyResourceGroup \
  --name MyTemplateSpec

La même commande est utilisée pour afficher une version de spec de modèle. Ajoutez l’argument --version pour obtenir les détails d’une version :

az ts show \
  --resource-group MyResourceGroup \
  --name MyTemplateSpec \
  --version 1.0

Le modèle JSON est inclus dans la sortie.

Notes

Lorsque vous publiez un fichier Bicep dans un spec de modèle, il est converti au format JSON. Vous ne pouvez pas voir le fichier Bicep d’origine. Il est donc judicieux de le conserver ailleurs.

Pour mettre à jour un spec de modèle existant, vous utilisez la cmdlet Set-AzTemplateSpec. Par exemple, vous pouvez utiliser cette cmdlet pour appliquer un correctif logiciel à une version que vous avez déjà publiée :

Set-AzTemplateSpec `
  -ResourceGroupName MyResourceGroup `
  -Name MyTemplateSpec `
  -Version 1.0 `
  -TemplateFile azuredeploy.json

Vous pouvez supprimer une version de spec de modèle à l’aide de la cmdlet Remove-AzTemplateSpec :

Remove-AzTemplateSpec `
  -ResourceGroupName MyResourceGroup `
  -Name MyTemplateSpec `
  -Version 1.0

Pour mettre à jour un spec de modèle existant, vous utilisez la commande az ts update. Par exemple, vous pouvez utiliser cette commande pour appliquer un correctif logiciel à une version que vous avez déjà publiée :

az ts update \
  --resource-group MyResourceGroup \
  --name MyTemplateSpec \
  --version 1.0 \
  --template-file azuredeploy.json

Vous pouvez supprimer une version de spec de modèle à l’aide de la commande az ts delete :

az ts delete \
  --resource-group MyResourceGroup \
  --name MyTemplateSpec \
  --version 1.0

Exporter un spec de modèle

Après avoir publié un modèle en tant que spec de modèle, vous pouvez l’exporter. L’exportation d’un spec de modèle permet de télécharger le fichier de modèle sur votre ordinateur local. À partir de là, vous pouvez modifier le fichier de modèle ou simplement l’inspecter afin de comprendre ce qu’il fait.

Conseil

Si votre spec de modèle comprend des modèles liés, l’exportation d’un spec de modèle télécharge également les modèles liés. Elle gère même la structure des dossiers.

Important

Lorsque vous publiez un fichier Bicep en tant que spec de modèle, votre code Bicep est converti en modèle JSON. Le processus de conversion de votre code Bicep en JSON supprime certaines informations de votre fichier Bicep. Par exemple, vos commentaires, les noms symboliques pour les ressources et l’ordre dans lequel vous définissez vos ressources peuvent être absents ou différents en JSON. Cela signifie que vous ne pouvez pas publier facilement un fichier Bicep en tant que spec de modèle, puis obtenir à nouveau le fichier Bicep d’origine (ce qu’on appelle également roundtripping). Il est judicieux de conserver une copie de votre code Bicep d’origine dans un référentiel de code tel que Git, en particulier lorsque vous travaillez avec des specs de modèle.

Pour exporter un spec de modèle, utilisez la cmdlet Export-AzTemplateSpec. Utilisez la valeur -OutputFolder pour spécifier l’emplacement où vous souhaitez enregistrer les fichiers de modèle :

Export-AzTemplateSpec `
  -ResourceGroupName MyResourceGroup `
  -Name MyTemplateSpec `
  -Version 1.0 `
  -OutputFolder ./mytemplate

Pour exporter un spec de modèle, utilisez la commande az ts export. Utilisez la valeur --output-folder pour spécifier l’emplacement où vous souhaitez enregistrer les fichiers de modèle :

az ts export \
  --resource-group MyResourceGroup \
  --name MyTemplateSpec \
  --version 1.0 \
  --output-folder ./mytemplate

Contrôler l’accès à un spec de modèle

Étant donné que les specs de modèle sont des ressources Azure, ils utilisent la gestion des identités et des accès Azure (IAM). Quand un utilisateur déploie un spec de modèle, Azure vérifie d’abord que l’utilisateur a accès au spec de modèle.

Notes

Pour déployer un spec de modèle, un utilisateur a besoin des éléments suivants :

• Accès pour lire le spec de modèle.
• Accès pour déployer sur le groupe de ressources ou une autre étendue sur laquelle le déploiement est demandé.

Azure vérifie les deux conditions avant le démarrage du déploiement.