Créer et utiliser des modules Bicep

Effectué

Les modules sont des fichiers Bicep indépendants. Ils contiennent généralement des ensembles de ressources déployées ensemble. Les modules peuvent être consommés à partir de n’importe quel autre modèle Bicep.

Quand vous utilisez des modules, vous pouvez réutiliser votre code Bicep, et rendre vos fichiers Bicep plus lisibles et compréhensibles parce qu’ils sont tous axés sur un travail spécifique. Vos modèles main composent plusieurs modules ensemble.

Avantages des modules

Dans votre société de jouets, vous avez provisionné des ressources cloud en utilisant de nombreux fichiers Bicep individuels. Au fil du temps, ces modèles augmentent considérablement. À la fin, vous avez du code monolithique difficile à lire et à parcourir, et encore plus difficile à gérer.

Cette approche vous oblige également à dupliquer des parties de votre code quand vous voulez le réutiliser dans d’autres modèles. Pour changer quelque chose, vous devez faire une recherche dans plusieurs fichiers et les mettre à jour.

Les modules Bicep vous aident à résoudre ces difficultés en divisant votre code en fichiers plus petits et plus faciles à gérer qui peuvent être référencés par plusieurs modèles. Les modules vous donnent quelques avantages essentiels.

Possibilité de réutilisation

Une fois que vous avez créé un module, vous pouvez le réutiliser dans plusieurs fichiers Bicep, même si les fichiers sont destinés à des charges de travail ou des projets différents. Par exemple, quand vous créez une solution, vous pouvez créer des modules distincts pour les composants d’application, de base de données et les ressources liées au réseau. Ensuite, quand vous commencez à travailler sur un autre projet avec des exigences réseau similaires, vous pouvez réutiliser le module approprié.

Vous pouvez même partager des modules au sein de votre équipe, de votre organisation ou avec la communauté Azure. Vous découvrirez plus d’informations sur le partage des modules Bicep dans un prochain module Microsoft Learn.

Encapsulation

Les modules vous aident à conserver ensemble des définitions de ressources associées. Par exemple, quand vous définissez une application Azure Functions, vous déployez généralement l’application, un plan d’hébergement pour l’application et un compte de stockage pour les métadonnées de l’application. Ces trois composants sont définis séparément, mais comme ils représentent un regroupement logique de ressources, vous pouvez les définir dans un module.

De cette façon, votre modèle main n’a pas besoin de connaître les détails de déploiement d’une application de fonction. C’est la responsabilité du module.

Composabilité

Une fois que vous avez créé un ensemble de modules, vous pouvez les composer ensemble. Par exemple, vous pouvez créer un module qui déploie un réseau virtuel et un autre module qui déploie une machine virtuelle. Vous définissez des paramètres et des sorties pour chaque module afin de pouvoir prendre les informations importantes de l’un et les envoyer à l’autre.

Conseil

Vous pouvez voir les modules Bicep comme des composants pouvant être combinés de différentes façons pour prendre en charge vos déploiements.

Fonctionnalité

Parfois, vous avez besoin d’utiliser des modules pour accéder à certaines fonctionnalités. Par exemple, vous pouvez utiliser des modules et des boucles ensemble pour déployer plusieurs ensembles de ressources. Vous pouvez également utiliser des modules pour définir des ressources dans différentes étendues d’un même déploiement.

Création d’un module

Un module est un fichier Bicep normal. Vous pouvez le créer comme n’importe quel autre fichier Bicep.

En règle générale, il n’est pas recommandé de créer un module pour chaque ressource que vous déployez. Un bon module Bicep définit généralement plusieurs ressources associées. Toutefois, si vous avez une ressource complexe avec beaucoup de configuration, il vaut mieux avoir un seul module pour encapsuler la complexité. Cette approche permet d’avoir des modèles main toujours simples et épurés.

Diviser un modèle Bicep existant en modules

Vous pouvez créer un grand modèle Bicep, puis décider de le diviser en modules. Parfois, vous savez exactement comment diviser votre grand fichier Bicep. Vous pouvez avoir un ensemble de ressources qui appartiennent clairement à un module. Dans d’autres cas, ce n’est pas aussi simple de déterminer les ressources qui doivent être regroupées dans un module.

Le visualiseur Bicep peut vous aider à mettre l’intégralité de votre fichier Bicep en perspective. Le visualiseur est compris dans l’extension Bicep pour Visual Studio Code.

Pour voir le visualiseur, ouvrez l’explorateur Visual Studio Code, sélectionnez le fichier Bicep avec un appui long (ou cliquez dessus avec le bouton droit), puis sélectionnez Ouvrir le visualiseur Bicep. Le visualiseur montre une représentation graphique des ressources dans votre fichier Bicep. Les lignes entre les ressources montrent les dépendances détectées par Bicep.

Vous pouvez utiliser le visualiseur pour vous aider à diviser vos fichiers. Déterminez si la visualisation met en évidence des clusters de ressources. Vous pouvez peut-être déplacer ces clusters dans un même module.

Par exemple, imaginez la visualisation suivante pour un fichier Bicep. Deux ensembles distincts de ressources sont définis. Vous pouvez peut-être les regrouper dans deux modules distincts Base de données et Réseau.

Visualiseur

Regroupement

Modules imbriqués

Les modules peuvent comprendre d’autres modules. Cette technique d’imbrication vous permet de créer des modules qui déploient de petits ensembles de ressources, puis de les composer en modules plus grands pour définir des topologies complexes de ressources. Un modèle combine ces éléments en artefact déployable.

Conseil

Bien qu’il soit possible d’imbriquer plusieurs couches de modules, cela peut devenir complexe. Si vous recevez une erreur ou que quelque chose tourne mal, c’est plus difficile de trouver ce qu’il faut corriger quand vous avez plusieurs couches d’imbrication.

Pour les déploiements complexes, vous pouvez parfois utiliser des pipelines de déploiement afin de déployer plusieurs modèles au lieu de créer un seul modèle et d’utiliser l’imbrication. Vous découvrirez plus d’informations sur les pipelines de déploiement dans un prochain module Microsoft Learn.

Choisir de bons noms de fichier

Veillez à utiliser un nom de fichier descriptif pour chaque module. Le nom de fichier devient l’identificateur du module. Vos collègues doivent pouvoir comprendre l’objectif du module en regardant simplement le nom du fichier.

Utiliser le module dans un modèle Bicep

Vous utilisez un module dans un modèle Bicep à l’aide du mot clé module, de la façon suivante :

module appModule 'modules/app.bicep' = {
  name: 'myApp'
  params: {
    location: location
    appServiceAppName: appServiceAppName
    environmentType: environmentType
  }
}

Une définition de module comprend les composants suivants :

• Le mot clé module.
• Un nom symbolique, par exemple appModule. Ce nom est utilisé dans ce fichier Bicep chaque fois que vous voulez référencer le module. Le nom symbolique n’apparaît jamais dans Azure.
• Le chemin d'accès du module, par exemple modules/app.bicep. Il s’agit généralement du chemin d’un fichier Bicep sur votre système de fichiers local. Dans un prochain module Microsoft Learn, vous apprendrez à partager des modules en utilisant des registres et des specs de modèle, qui ont leurs propres formats de chemin de module.

  Conseil

  Vous pouvez également utiliser un modèle Azure Resource Manager (modèle ARM) JSON comme module. Cette possibilité peut vous rendre service si vous avez un ensemble de modèles qui n’est pas encore migré vers Bicep.

• La propriété name, qui spécifie le nom du déploiement. Vous découvrirez plus d’informations sur les déploiements dans la section suivante.
• La propriété params, où vous pouvez spécifier des valeurs pour les paramètres attendus par le module. Vous découvrirez plus d’informations sur les paramètres de module dans l’unité suivante.

Fonctionnement des modules

Vous n’avez pas besoin de comprendre le fonctionnement des modules pour les utiliser, mais cela peut vous aider à investiguer les problèmes liés à vos déploiements ou à expliquer un comportement inattendu.

Déploiements

Dans Azure, un déploiement est une ressource spéciale qui représente une opération de déploiement. Les déploiements sont des ressources Azure dont le type de ressource est Microsoft.Resources/deployments. Quand vous envoyez un déploiement Bicep, vous créez ou mettez à jour une ressource de déploiement. De même, quand vous créez des ressources dans le portail Azure, le portail crée une ressource de déploiement pour vous.

Toutefois, les changements effectués sur les ressources Azure n’entraînent pas tous la création ou l’utilisation de déploiements. Par exemple, quand vous utilisez le portail Azure pour modifier une ressource existante, il ne crée généralement pas de déploiement pour faire le changement. Quand vous utilisez des outils tiers comme Terraform pour déployer ou configurer vos ressources, ils peuvent ne pas créer de déploiements.

Quand vous déployez un fichier Bicep avec Azure CLI ou Azure PowerShell, vous pouvez éventuellement spécifier le nom du déploiement. Si vous ne spécifiez pas de nom, Azure CLI ou Azure PowerShell crée automatiquement un nom de déploiement à partir du nom de fichier du modèle. Par exemple, si vous déployez un fichier nommé main.bicep, le nom de déploiement par défaut est main.

Quand vous utilisez des modules, Bicep crée un déploiement distinct pour chaque module. La propriété name que vous spécifiez pour le module devient le nom du déploiement. Quand vous déployez un fichier Bicep qui contient un module, plusieurs ressources de déploiement sont créées : une pour le modèle parent et une pour chaque module.

Par exemple, supposons que vous créez un fichier Bicep nommé main.bicep. Il définit un module nommé myApp. Quand vous déployez le fichier main.bicep, deux déploiements sont créés. Le premier est nommé main, et l’autre myApp et contient les ressources de votre application.

Vous pouvez lister et consulter les détails des ressources de déploiement pour monitorer l’état de vos déploiements Bicep ou voir l’historique des déploiements. Toutefois, quand vous réutilisez le même nom pour un déploiement, Azure remplace le dernier déploiement du même nom. Si vous avez besoin de conserver l’historique de déploiement, veillez à utiliser un nom unique pour chaque déploiement. Vous pouvez ajouter la date et l’heure du déploiement dans le nom pour le rendre unique.

Modèles ARM JSON générés

Quand vous déployez un fichier Bicep, Bicep le convertit en modèle ARM JSON. Cette conversion est également appelée transpilation. Les modules utilisés par le modèle sont incorporés dans le fichier JSON. Quel que soit le nombre de modules que vous ajoutez dans votre modèle, un seul fichier JSON est créé.

Dans l’exemple présenté dans la section précédente, Bicep génère un seul fichier JSON, même s’il y avait deux fichiers Bicep à l’origine.