Présentation des registres de modules

Effectué

Dans cette unité, vous apprendrez ce que sont les registres Bicep et pourquoi ils sont utiles pour partager votre code Bicep. Vous allez également apprendre à créer un registre pour votre propre organisation.

Pourquoi partager des modules Bicep ?

Lorsque vous travaillez avec Bicep, vous utilisez souvent des ressources similaires de manière répétée. En outre, il est courant de créer des combinaisons de ressources que vous déployez à plusieurs emplacements. Les modules Bicep offrent un moyen pratique de créer des fichiers Bicep réutilisables. Chaque module définit généralement un ensemble de ressources avec une configuration prédéfinie.

L’un des avantages de l’utilisation de modules est que vous pouvez les partager avec d’autres personnes, et vous pouvez tirer parti des modules que les autres partagent avec vous. Par exemple, vous pouvez consacrer du temps à la création et au test d’un fichier Bicep pour déployer un ensemble de ressources que vous utilisez souvent ensemble. Lorsque vous partagez votre fichier en tant que module Bicep, vos collègues peuvent utiliser le module pour déployer rapidement les mêmes ressources.

Un registre Bicep est l’endroit où les modules sont stockés et partagés. Tout le monde peut créer son propre registre. À l’avenir, Microsoft prévoit de prendre en charge l’autres types de contenu Bicep dans les registres, en plus des modules.

Conseil

Microsoft gère un registre de modules Bicep public. Le registre public contient des modules que toute personne de la communauté peut utiliser. Au fil du temps, le registre public contiendra des modules permettant de réaliser certains scénarios courants dans Bicep.

Ce module Learn se concentre sur le partage de vos propres modules à l’aide de registres privés. L’unité récapitulative contient un lien vers davantage d’informations sur le registre public.

Quelles sont les différences entre les registres et les spécifications de modèle ?

Vous pouvez enregistrer un modèle Azure Resource Manager (modèle ARM) comme spec de modèle. Un spec de modèle permet de rendre vos modèles réutilisables et de les partager dans votre organisation.

Les modules stockés dans les registres Bicep et les specs de modèle sont deux moyens d’ajouter de la réutilisabilité à votre code de déploiement. Cependant, ils sont optimisés pour différentes choses :

  • Les modules Bicep sont conçus pour être combinés dans un déploiement plus vaste. 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 ainsi qu’avec des outils tels qu’Azure CLI et Azure PowerShell. Mais si vous avez créé un spec de modèle, Bicep vous permet également de l’utiliser en tant que module si vous le souhaitez.
  • Les spécifications de modèle sont stockées dans Azure en tant que ressources. Les modules des registres sont stockés en tant qu’artefacts de conteneur.
  • Les specs de modèle fournissent des capacités de contrôle d'accès. Lorsque vous utilisez un registre privé, vous devez contrôler l’accès à vos modules d’une autre manière. Vous en apprendrez davantage sur le contrôle d’accès dans une unité ultérieure.

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. Un registre est un bon moyen de partager des modules.

Registres privés

Les registres Bicep sont basés sur une technologie appelée registres de conteneur.

Si votre organisation utilise Kubernetes ou une autre technologie de conteneur, vous connaissez peut-être déjà les registres. Toutefois, il n'est pas nécessaire d'utiliser des conteneurs ou Kubernetes pour travailler avec Bicep. Les registres fournissent un moyen générique et pratique de stocker et de partager des artefacts. Considérez-les comme étant analogues aux comptes de stockage.

Actuellement, Bicep prend en charge Azure Container Registry. À l’avenir, Microsoft prévoit de prendre en charge d’autres registres, comme Docker Hub.

Azure Container Registry fournit plusieurs niveaux de service, avec différentes capacités et limites. Lorsque vous approvisionnez votre propre registre, vous devez sélectionner le niveau adapté à vos besoins. L’unité de synthèse contient des liens vers des informations supplémentaires.

Bientôt, vous apprendrez à publier des modules dans un registre.

Conseil

Dans Azure Container Registry, un module est appelé référentiel. Ne confondez pas cela avec un référentiel Git. Les termes sont les mêmes, mais la signification est différente.

Contrôle d’accès

Étant donné qu’Azure Container Registry fournit un registre privé pour votre organisation, vous pouvez contrôler qui y a accès. Azure Container Registry propose plusieurs options de gestion de l’accès, notamment l’ID Et les clés Microsoft Entra que vous émettez à des utilisateurs individuels.

Lorsque vous travaillez avec Bicep, l’approche la plus simple consiste à utiliser l’authentification Microsoft Entra. Bicep détecte automatiquement l’identité Microsoft Entra que vous utilisez dans Azure CLI ou Azure PowerShell. Vous n’avez donc pas besoin de vous reconnecter. Vous verrez comment fonctionne l’authentification dans l’exercice suivant. Lorsque vous utilisez un registre de modules Bicep à partir d’un pipeline, vous utilisez un type spécial d’identité appelé principal de service.

Vous pouvez contrôler séparément qui a l’autorisation d’écrire des modules dans votre registre et qui est autorisé à lire les modules.