Regrouper les ressources associées à l’aide de modules

Effectué

Vous avez commencé à utiliser des modèles Bicep pour des lancements de produits récents et ils ont été efficaces. Étant donné que vous avez déclaré vos ressources dans un fichier de modèle, vous pouvez rapidement déployer les ressources pour les lancements de nouveaux jouets sans avoir à configurer manuellement les ressources dans le portail Azure.

Le responsable informatique a constaté que votre code Bicep devient de plus en plus complexe et qu’il contient un nombre grandissant de ressources définies : il vous a donc demandé si vous pouviez rendre le code plus modulaire. Vous pouvez créer des fichiers Bicep individuels, appelés modules, pour différentes parties de votre déploiement. Le modèle Bicep principal peut référencer ces modules. En arrière-plan, les modules sont transcompilés en un seul modèle JSON pour le déploiement.

Les modules sont également un moyen de rendre le code Bicep encore mieux réutilisable. Un seul module Bicep peut être utilisé par de nombreux modèles Bicep.

Vous devrez également souvent émettre des sorties à partir des modèles et des modules Bicep. Les sorties sont un moyen pour votre code Bicep de renvoyer des données à la personne ou à l’outil qui a démarré le déploiement. Commençons par examiner les sorties.

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.

Outputs

Un humain peut déployer manuellement des modèles Bicep, ou un processus de mise en production automatisé le faire. Dans les deux cas, il est courant que des données du modèle doivent être renvoyées vers la personne ou l’outil qui effectue le déploiement du modèle.

Voici quelques exemples de scénarios dans lesquels il pourrait être nécessaire de récupérer des informations à partir du déploiement du modèle :

• Vous créez un modèle Bicep qui déploie une machine virtuelle et vous avez besoin de l’adresse IP publique afin d’établir une connexion SSH à la machine.
• Vous créez un modèle Bicep qui accepte un ensemble de paramètres, comme un nom d’environnement et un nom d’application. Le modèle utilise une expression pour nommer une application Azure App Service qu’il déploie. Vous devez produire en sortie le nom de l’application déployée par le modèle afin qu’il puisse être utilisé dans un pipeline de déploiement pour publier les fichiers binaires de l’application.

Vous pouvez utiliser les sorties pour ces scénarios. Pour définir une sortie dans un modèle Bicep, utilisez le mot clé output comme suit :

output appServiceAppName string = appServiceAppName

La définition de sortie comprend quelques éléments clés :

• Le mot clé output indique à Bicep que vous définissez une sortie.
• appServiceAppName est le nom de la sortie. Quand quelqu’un déploie le modèle correctement, les valeurs de sortie incluent le nom que vous avez spécifié, ce qui leur permet d’accéder aux valeurs attendues.
• string est le type de sortie. Les sorties Bicep prennent en charge les mêmes types que les paramètres.
• Une valeur doit être spécifiée pour chaque sortie. Contrairement aux paramètres, les sorties doivent toujours avoir des valeurs. Les valeurs de sortie peuvent être des expressions, des références à des paramètres ou des variables, ou bien des propriétés des ressources qui sont déployées dans le fichier.

Conseil

Les sorties peuvent utiliser les mêmes noms que les variables et les paramètres. Cette convention peut être utile si vous construisez une expression complexe dans une variable à utiliser dans les ressources de votre modèle, et si vous devez aussi exposer la valeur de la variable comme sortie.

Voici un autre exemple de sortie. Cette sortie a une valeur définie sur le nom de domaine complet (FQDN) d’une ressource d’adresse IP publique.

output ipFqdn string = publicIPAddress.properties.dnsSettings.fqdn

Conseil

Essayez d’utiliser les propriétés de ressource en tant que sorties, plutôt que de faire des hypothèses sur le comportement des ressources. Par exemple, si vous avez besoin d’une sortie pour l’URL de l’application App Service, utilisez la propriété defaultHostName de l’application au lieu de créer vous-même une chaîne pour l’URL. Parfois, ces hypothèses ne sont pas valides dans des environnements distincts, ou le mode de fonctionnement de la ressource change, il est donc plus prudent de demander à la ressource de vous indiquer ses propres propriétés.

Attention

Ne créez pas de sorties pour les valeurs secrètes comme les chaînes de connexion ou les clés. Toute personne ayant accès à votre groupe de ressources peut lire des sorties à partir de modèles. Vous pouvez utiliser d’autres approches pour obtenir l’accès aux propriétés des ressources de secret, comme nous le verrons dans un module ultérieur.

Définir un module

Les modules Bicep vous permettent d’organiser et de réutiliser votre code Bicep en créant des unités plus petites qui peuvent être combinées en un modèle. Tout modèle Bicep peut être utilisé comme un module par un autre modèle. Tout au long de ce module d’apprentissage, vous avez créé des modèles Bicep. Cela signifie que vous avez déjà créé des fichiers qui peuvent être utilisés en tant que modules Bicep !

Imaginez que vous avez un modèle Bicep qui déploie des ressources d’application, de base de données et de réseau pour une solution A. Vous pouvez diviser ce modèle en trois modules, chacun d’eux étant axé sur son propre ensemble de ressources. En bonus, vous pouvez maintenant réutiliser les modules dans d’autres modèles pour d’autres solutions également. Ainsi, lorsque vous développez un modèle pour une solution B, qui a des exigences de mise en réseau similaires à la solution A, vous pouvez réutiliser le module réseau.

Quand vous souhaitez que le modèle inclue une référence à un fichier de module, utilisez le mot clé module. Une définition de module ressemble à une déclaration de ressource, mais au lieu d’inclure un type de ressource et une version d’API, vous utilisez le nom de fichier du module :

module myModule 'modules/mymodule.bicep' = {
  name: 'MyModule'
  params: {
    location: location
  }
}

Examinons en détail certaines parties clés de cette définition de module :

• Le mot clé module indique à Bicep que vous allez utiliser un autre fichier Bicep comme module.
• Tout comme les ressources, les modules ont besoin d’un nom symbolique comme myModule. Vous utilisez le nom symbolique quand vous faites référence aux sorties du module dans d’autres parties du modèle.
• modules/mymodule.bicep est le chemin d’accès au fichier du module, par rapport au fichier du modèle. N’oubliez pas qu’un fichier de module n’est qu’un fichier Bicep standard.
• Tout comme pour les ressources, la propriété name est obligatoire. Azure utilise le nom du module, car un déploiement distinct est créé pour chaque module au sein du fichier de modèle. Ces déploiements ont des noms qui permettent de les identifier.
• Vous pouvez spécifier tout paramètre du module à l’aide du mot clé params. Quand vous définissez les valeurs de chaque paramètre dans le modèle, vous pouvez utiliser des expressions, des paramètres de modèle, des variables, des propriétés de ressources déployées dans le modèle, ainsi que des sorties d’autres modules. Bicep va automatiquement comprendre les dépendances entre les ressources.

Modules et sorties

Tout comme les modèles, les modules Bicep peuvent définir des sorties. Il est courant de chaîner les modules dans un modèle. Dans ce cas, la sortie d’un module peut être un paramètre d’un autre module. En combinant des modules et des sorties, vous pouvez créer des fichiers Bicep puissants et réutilisables.

Concevoir vos modules

Un bon module Bicep suit quelques principes clés :

• La finalité du module doit être claire. Vous pouvez utiliser des modules pour définir toutes les ressources liées à une partie spécifique de votre solution. Par exemple, vous pouvez créer un module qui contient toutes les ressources utilisées pour superviser votre application. Vous pouvez également utiliser un module pour définir un ensemble de ressources liées, comme tous vos serveurs de base de données et toutes vos bases de données.

• Ne placez pas chaque ressource dans son propre module. Vous ne devez pas créer un module distinct pour chaque ressource que vous déployez. Si vous avez une ressource qui a de nombreuses propriétés complexes, il peut être judicieux de placer cette ressource dans son propre module, mais en général, il est préférable que les modules combinent plusieurs ressources.

• Un module doit avoir des paramètres clairs et des sorties explicites. Tenez compte de la finalité du module. Déterminez si le module doit manipuler les valeurs de paramètre ou si c’est le modèle parent qui doit s’en charger puis transmettre une seule valeur au module. De même, pensez aux sorties qu’un module doit retourner, et vérifiez qu’elles sont utiles aux modèles qui vont utiliser ce module.

• Un module doit être aussi autonome que possible. Si un module doit utiliser une variable pour définir une partie d’un module, la variable doit généralement être incluse dans le fichier de module plutôt que dans le modèle parent.

• Un module ne doit pas générer de secrets. Tout comme pour les modèles, ne créez pas de sorties de module pour des valeurs de secret, comme des chaînes de connexion ou des clés.