Publier un module dans un registre privé

Effectué

Vous comprenez maintenant ce que sont les registres Bicep et comment ils peuvent être utiles pour partager des modules dans votre organisation. Dans cette unité, vous allez apprendre à publier un module dans un registre privé.

Chemins des modules

Lorsque vous avez travaillé avec des modules dans le passé, vous avez probablement utilisé le chemin de fichier du module pour y faire référence dans vos modèles. Lorsque vous travaillez avec des modules et des registres privés, vous devez utiliser un autre chemin d’accès de module pour que Bicep sache comment localiser le module dans votre registre.

Voici un exemple de chemin d’accès pour un module dans un registre de conteneurs Azure privé :

Le chemin d’accès contient quatre segments :

• Schéma : Bicep prend en charge plusieurs types de module, appelés schémas. Lorsque vous travaillez avec des registres Bicep, le schéma est br.
• Registre : nom du Registre qui contient le module que vous souhaitez utiliser. Dans l’exemple précédent, le nom du registre est toycompany.azurecr.io, qui est le nom du registre de conteneurs.
• Identificateur du module : chemin d’accès complet au module dans le registre.
• Balise : les balises représentent généralement des versions de module, car un même module peut avoir plusieurs versions publiées. Pour en savoir plus sur les étiquettes et les versions, consultez la section suivante.

Quand vous publiez votre propre identificateur de module, utilisez un identificateur significatif qui indique l’objectif du module. Vous pouvez éventuellement utiliser des espaces de noms, où vous utilisez des barres obliques (/) pour faire la distinction entre les parties d’un nom. Toutefois, Azure Container Registry et Bicep ne prennent pas en charge les hiérarchies. Ils traitent l’identificateur de module comme une simple valeur.

Balises et versions

Une balise représente la version d’un module. Un même module d’un registre peut avoir plusieurs versions. Toutes les versions partagent un identificateur de module, mais elles ont des balises différentes. Quand vous utilisez un module, vous devez utiliser une balise pour spécifier la version que vous souhaitez utiliser, afin que Bicep sache quel fichier de module récupérer.

Il est judicieux de planifier avec soin la façon dont vous allez gérer les versions de vos modules. Le schéma de contrôle de version et la stratégie de contrôle de version à utiliser sont les deux principales décisions que vous devez prendre.

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. Vous pouvez également ajouter un préfixe à chaque numéro de version, comme v1 et v2.
• Les dates font également de bons numéros de version. Par exemple, si vous publiez la première version de votre module le 16 janvier 2022, vous pouvez nommer la version 2022-01-16 (en utilisant le format aaaa-mm-jj). Lorsque vous publiez une autre version le 3 mars, vous pouvez la nommer 2022-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 le schéma de gestion de versions de votre choix, il est judicieux de choisir quelque chose qui peut être trié dans un ordre significatif. Les nombres et les dates sont souvent de bons choix.

Notes

Azure Container Registry stocke la date à laquelle chaque balise est créée. 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 modules vous donnent la possibilité de choisir quand créer des 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 module, 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 à un module existant un changement mineur qui n’affecte pas son utilisation, la création d’une version n’est probablement pas une bonne idée. Vous devez communiquer le nouveau numéro de version à toute personne utilisant le module.

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

• Chaque fois que vous apportez des modifications importantes à un module, créez une nouvelle version. Les modifications importantes incluent tout ce qui peut faire une différence pour une personne qui utilise votre module. Il peut s’agir, par exemple, d’ajouter une autre ressource au module ou de modifier les propriétés d’une ressource.
• Chaque fois que vous apportez des modifications mineures à un module, ce qu’on appelle parfois correctif, mettez à jour la version de module 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 module et ce à quoi ils doivent s’attendre. Si quelqu’un utilise votre module plusieurs fois et obtient un résultat, puis l’utilise à nouveau après un correctif et obtient un résultat différent, il sera probablement surpris. Essayez d’éviter de surprendre vos utilisateurs.

Publier votre module

Lorsque vous créez un module Bicep que vous souhaitez le partager, vous devez créer le fichier Bicep normalement. Vous publiez ensuite le fichier dans un registre à l’aide de la commande bicep publish. Lorsque vous publiez, vous devez spécifier le chemin d’accès auquel enregistrer le module :

az bicep publish \
   --file module.bicep \
   --target 'br:toycompany.azurecr.io/mymodules/modulename:moduleversion'

bicep publish module.bicep `
   --target 'br:toycompany.azurecr.io/mymodules/modulename:moduleversion'

L’opération de publication effectue les mêmes étapes de validation que celles de la génération ou du déploiement d’un fichier Bicep. Ces étapes sont les suivantes :

• Vérification de l’absence d’erreurs syntaxiques dans votre code.
• Vérification que vous spécifiez des définitions de ressources valides.
• Exécution du linter Bicep pour vérifier que votre code passe une série de contrôles de qualité.

Si les étapes de validation réussissent, le module est publié dans votre registre.