Comprendre les specs de modèle

Effectué

À ce stade, vous êtes habitué à déployer des modèles Azure Resource Manager (modèles ARM) sur Azure à l’aide de Bicep ou de JSON. Vous créez un fichier de modèle, puis vous l’envoyez à Azure en créant un déploiement. Azure Resource Manager orchestre la création ou la reconfiguration de vos ressources.

Quand vous travaillez avec des specs de modèle, vous envoyez toujours le modèle à Azure. Mais au lieu de le déployer, Azure l’enregistre pour vous permettre de l’utiliser à l’avenir. Ensuite, vous pouvez y revenir et demander à Azure de déployer le spec de modèle. Vous pouvez même utiliser le même spec de modèle à plusieurs reprises pour déployer davantage d’environnements.

Pourquoi utiliser des spécifications de modèle ?

Au sein de votre entreprise de jouets, vous avez créé de nombreux modèles réutilisables, notamment :

Nom du modèle	Description
Compte de stockage	Déploie un compte de stockage et applique l’authentification Microsoft Entra.
Compte Cosmos DB	Déploie un compte Azure Cosmos DB avec la sauvegarde continue activée.
Réseau virtuel	Déploie un réseau virtuel qui a la configuration appropriée pour s’homologuer avec le réseau hub principal.
Site web de lancement de produit	Déploie un plan Azure App Service, une application et un compte de stockage pour les sites web consacrés au lancement de nouveaux jouets.

Les specs de modèle sont un excellent moyen de créer une bibliothèque de modèles ARM réutilisables pour des scénarios courants dans votre organisation. Un expert peut créer un modèle avec une ressource préconfigurée ou un ensemble de ressources. Cet expert peut ensuite le publier en tant que spec de modèle, ce qui permet à d’autres personnes de l’organisation de le déployer.

Vous pouvez utiliser les specs de modèle pour vous assurer que les ressources que votre équipe crée sont configurées en fonction de vos besoins. Par exemple, vous pouvez publier une spec de modèle comme le modèle de compte de stockage que nous avons décrit précédemment. Ensuite, chaque fois que toute personne de votre organisation déploie votre spec de modèle, vous pouvez vous assurer qu’elle crée un compte de stockage avec les paramètres d’authentification appropriés.

Les specs de modèle sont stockés dans Azure. Vous n’avez donc pas besoin de conserver les fichiers de modèle partagés vous-même. Vous pouvez utiliser le contrôle d’accès en fonction du rôle Azure pour gérer les utilisateurs qui peuvent utiliser et modifier les specs de modèle. Sans specs de modèle, vous devez choisir un emplacement de stockage, comme le Stockage Azure, pour conserver vos fichiers de modèle. Vous devez également contrôler l’accès vous-même.

Quelles sont les différences entre les specs de modèle et les modules Bicep ?

Lorsque vous travaillez avec Bicep, vous pouvez créer des modules réutilisables pour définir des ensembles de ressources dans un seul fichier. Les specs de modèle et les modules Bicep sont deux méthodes pour ajouter la réutilisabilité à vos modèles, mais elles sont optimisées pour différentes choses :

• Les specs de modèle sont conçus pour être déployables sous forme de modèle complet. Vous pouvez déployer des specs de modèle à l’aide du portail Azure et des outils comme Azure CLI et Azure PowerShell. Les modules Bicep sont conçus pour être combinés dans un déploiement plus vaste. Toutefois, si vous créez une spec de modèle, Bicep vous permet également de l’utiliser comme module si vous le souhaitez.
• Les spécifications de modèle fournissent des fonctionnalités de contrôle de version et de contrôle d’accès. Vous devez gérer vous-même les versions et la sécurité de votre code Bicep.
• Les spécifications de modèle sont stockées dans Azure en tant que ressource. Vous devez stocker les modules Bicep dans un emplacement que vous contrôlez, comme un système de contrôle de version, tel que Git, ou votre système de fichiers.
• Les modules Bicep conservent tout le code Bicep d’origine, y compris les commentaires, les noms symboliques et les espaces blancs. Lorsque vous créez un spec de modèle à l’aide de Bicep, votre code Bicep est converti en JSON et certaines de ces informations sont perdues. Vous devez donc conserver le fichier Bicep source ailleurs.

Lorsque vous choisissez entre les specs de modèle et les modules Bicep, une bonne règle empirique est : si le modèle va être déployé tel quel dans votre organisation, les specs de modèle sont probablement mieux adaptés. Toutefois, si vous êtes susceptible de réutiliser ce modèle dans plusieurs modèles parents, les modules Bicep peuvent répondre à vos besoins.

Fonctionnement des specs de modèle

Un spec de modèle est une ressource Azure, tout comme un compte de stockage ou une machine virtuelle. Il doit être créé dans un groupe de ressources, bien que le modèle lui-même puisse déployer des ressources dans une étendue d’abonnement, de gestion ou de locataire.

Lorsque vous travaillez avec des specs de modèle, vous créez deux ressources :

• Le spec de modèle est la ressource de conteneur. Il contient une ou plusieurs versions.
• Les versions de spec de modèle contiennent le modèle réel à déployer.

Vous travaillez avec des specs de modèle et des versions à l’aide de leurs ID de ressource. Voici un exemple d’ID de ressource pour un spec de modèle :

/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/SharedTemplates/providers/Microsoft.Resources/templateSpecs/StorageWithoutSAS

Une version est une ressource enfant de la spec de modèle. Elle a un ID de ressource comme cet exemple :

/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/SharedTemplates/providers/Microsoft.Resources/templateSpecs/StorageWithoutSAS/versions/1.0

Lorsque vous déployez un spec de modèle, vous devez spécifier l’ID de ressource de la version de spec de modèle.

Voici une illustration du flux de travail que vous suivez lorsque vous utilisez des specs de modèle :

Vous créez un modèle de la manière dont vous avez l’habitude. Il n’y a rien de spécial quant au modèle que vous créez pour un spec de modèle. Vous déclarez des ressources, créez des paramètres et des variables, utilisez des fonctions, etc.

Lorsque votre modèle est prêt, vous créez une ressource de spec de modèle. Vous publiez ensuite votre modèle dans le spec de modèle en tant que version. L’outil que vous utilisez pour créer des specs de modèle vous permet d’effectuer ces étapes en une seule opération. Une fois que vous avez publié votre spec de modèle, elle est stockée dans Azure en tant que ressource. Vous pouvez l’afficher, le modifier et contrôler son accès comme n’importe quelle autre ressource Azure. Vous pouvez publier vos specs de modèle à partir de votre ordinateur local ou d’un pipeline de déploiement.

Chaque fois que vous souhaitez déployer votre spec de modèle, vous faites référence à l’ID de ressource de la version de spec de modèle à partir du déploiement. Vous pouvez le déployer vers n’importe quel groupe de ressources, ou même vers un autre abonnement ou une autre étendue. Azure lit les spécifications du modèle et les utilise comme modèle pour le déploiement.