Utiliser un module à partir d’un registre privé
Vous avez appris à publier des modules dans un registre privé. Dans cette unité, vous allez apprendre à utiliser des modules qui se trouvent déjà dans un registre dans le cadre d’un modèle Bicep.
Utiliser un module Bicep
Une fois que vous avez trouvé un module à utiliser, vous créez une définition de module dans votre modèle Bicep. Voici un exemple :
module myModule 'br:myregistry.azurecr.io/modulepath/modulename:moduleversion' = {
name: 'my-module'
params: {
moduleParameter1: 'value'
}
}
Notez que la définition de module est similaire à celle d’un module local, mais avec une différence importante. Au lieu de spécifier le chemin d’un fichier Bicep sur votre système de fichiers, vous ajoutez le chemin de votre module dans votre registre.
Une fois que vous avez ajouté une référence au module, Visual Studio Code tente de télécharger automatiquement le module à partir du registre. Quand le module est téléchargé, l’extension Bicep pour Visual Studio Code vous fournit IntelliSense et d’autres fonctionnalités d’assistance à la création de code pendant votre travail.
Alias
Vous pouvez utiliser un alias de registre pour simplifier vos définitions de module. Au lieu de spécifier le nom du registre à chaque fois que vous définissez un module, vous utilisez son alias. Les alias vous aident de plusieurs façons :
- Ils peuvent maintenir votre fichier Bicep plus propre et vous permettent d’éviter de taper le nom complet du registre plusieurs fois.
- Si vous passez à un nouveau registre à l’avenir, vous pouvez mettre à jour l’alias au lieu de mettre à jour chaque référence à celui-ci.
- Certaines organisations doivent utiliser différents registres pour différentes situations, comme pour les environnements de développement et de production. Vous pouvez changer le registre référencé par un alias en modifiant un fichier de configuration. Le changement s’applique alors à tous les fichiers Bicep du dossier.
Pour définir un alias, vous devez créer un fichier bicepconfig.json dans le même dossier que votre fichier Bicep. Dans le fichier bicepconfig.json, vous définissez des alias comme dans l’exemple suivant :
{
"moduleAliases": {
"br": {
"MyRegistry": {
"registry": "myregistry.azurecr.io"
}
}
}
}
Lorsque vous définissez un module dans un fichier Bicep, vous utilisez un type de chemin de module légèrement différent, qui comprend l’alias :
module myModule 'br/MyRegistry:bicep/my-module:v1' = {
// ...
}
Conseil
Notez que le début du chemin est br/
quand vous utilisez un alias et br:
dans le cas contraire.
Un alias peut également inclure le chemin de vos modules dans le registre, ce qui est utile si vous utilisez un préfixe commun pour vos modules :
{
"moduleAliases": {
"br": {
"MyRegistryWithPath": {
"registry": "myregistry.azurecr.io",
"modulePath": "bicep"
}
}
}
}
Ensuite, vous pouvez omettre le chemin d’accès lorsque vous définissez le module dans votre fichier Bicep :
module myModule 'br/MyRegistryWithPath:my-module:v1' = {
// ...
}
Générer votre fichier Bicep
Lorsque vous êtes prêt à déployer votre fichier Bicep, vous le déployez comme vous le faites habituellement. Bicep télécharge le module à partir du registre automatiquement dans le cadre du processus de déploiement. Bicep incorpore tous les modules que vous référencez dans le fichier JSON du modèle ARM transpilé.
Vous pouvez aussi séparer le processus de téléchargement du module de la génération en utilisant la commande bicep restore
. Vous pouvez alors utiliser la commande bicep build
avec le commutateur de ligne de commande --no-restore
pour empêcher le processus de génération de télécharger le module. En règle générale, toutefois, vous n’avez pas besoin de séparer les modules et vous laissez Bicep se charger du téléchargement automatique des modules.