Partager via

Ajouter des paramètres de module dans le fichier config Bicep

  • Article

Dans un fichier bicepconfig.json, vous pouvez créer des alias pour les chemins d’accès des modules et configurer la priorité du profil et des informations d’identification pour la publication et la restauration des modules.

Cet article décrit les paramètres disponibles pour l’utilisation des modules Bicep.

Alias pour les modules

Afin de simplifier le chemin pour la liaison aux modules, créez des alias dans le fichier config. Un alias fait référence à un registre de modules ou à un groupe de ressources qui contient des specs de modèle.

Le fichier de configuration a une propriété pour moduleAliases. Cette propriété contient tous les alias que vous définissez. Sous cette propriété, les alias sont divisés selon qu’ils font référence à un registre ou à un spec de modèle.

Pour créer un alias pour un registre Bicep, ajoutez une propriété br. Pour ajouter un alias pour un spec de modèle, utilisez la propriété ts.

{
  "moduleAliases": {
    "br": {
      <add-registry-aliases>
    },
    "ts": {
      <add-template-specs-aliases>
    }
  }
}

Dans la propriété br, ajoutez autant d’alias que nécessaire. Attribuez un nom et les propriétés suivantes à chaque alias :

  • registry (obligatoire) : nom de serveur de connexion au registre
  • modulePath (facultatif) : référentiel du registre dans lequel les modules sont stockés

Dans la propriété ts, ajoutez autant d’alias que nécessaire. Attribuez un nom et les propriétés suivantes à chaque alias :

  • subscription (obligatoire) : ID de l’abonnement qui héberge les spécifications de modèle
  • resourceGroup (obligatoire) : nom du groupe de ressources qui contient les spécifications de modèle

L’exemple suivant montre un fichier de configuration qui définit deux alias pour un registre de modules et un alias pour un groupe de ressources qui contient des spécifications de modèle.

{
  "moduleAliases": {
    "br": {
      "ContosoRegistry": {
        "registry": "contosoregistry.azurecr.io"
      },
      "CoreModules": {
        "registry": "contosoregistry.azurecr.io",
        "modulePath": "bicep/modules/core"
      }
    },
    "ts": {
      "CoreSpecs": {
        "subscription": "00000000-0000-0000-0000-000000000000",
        "resourceGroup": "CoreSpecsRG"
      }
    }
  }
}

Lorsque vous utilisez un alias dans la référence de module, vous devez utiliser les formats suivants :

br/<alias>:<file>:<tag>
ts/<alias>:<file>:<tag>

Définissez vos alias sur le dossier ou le groupe de ressources qui contient les modules, pas sur le fichier lui-même. Le nom de fichier doit être inclus dans la référence au module.

Sans les alias, vous créez un lien vers un module dans un registre avec le chemin d’accès complet.

module stgModule 'br:contosoregistry.azurecr.io/bicep/modules/core/storage:v1' = {

Avec les alias, vous pouvez simplifier le lien à l’aide de l’alias du registre.

module stgModule 'br/ContosoRegistry:bicep/modules/core/storage:v1' = {

Ou vous pouvez simplifier le lien à l’aide de l’alias qui spécifie le chemin d’accès au registre et au module.

module stgModule  'br/CoreModules:storage:v1' = {

Pour une spécification de modèle, utilisez :

module stgModule  'ts/CoreSpecs:storage:v1' = {

Un alias a été prédéfini pour le registre de modules publics. Pour référencer un module public, vous pouvez utiliser le format :

br/public:<file>:<tag>

Vous pouvez remplacer la définition d’alias de registre de modules publics dans le fichier bicepconfig.json :

{
  "moduleAliases": {
    "br": {
      "public": {
        "registry": "<your_module_registry>",
        "modulePath": "<optional_module_path>"
      }
    }
  }
}

Configurer les profils et les informations d’identification

Pour publier des modules dans un registre de modules privés ou pour restaurer des modules externes dans le cache local, le compte doit avoir les autorisations correctes pour accéder au registre. Vous pouvez configurer manuellement currentProfile et credentialPrecedence dans le fichier de configuration Bicep pour l’authentification auprès du Registre.

{
  "cloud": {
    "currentProfile": "AzureCloud",
    "profiles": {
      "AzureCloud": {
        "resourceManagerEndpoint": "https://management.azure.com",
        "activeDirectoryAuthority": "https://login.microsoftonline.com"
      },
      "AzureChinaCloud": {
        "resourceManagerEndpoint": "https://management.chinacloudapi.cn",
        "activeDirectoryAuthority": "https://login.chinacloudapi.cn"
      },
      "AzureUSGovernment": {
        "resourceManagerEndpoint": "https://management.usgovcloudapi.net",
        "activeDirectoryAuthority": "https://login.microsoftonline.us"
      }
    },
    "credentialPrecedence": [
      "AzureCLI",
      "AzurePowerShell"
    ]
  }
}

Les profils disponibles sont les suivants :

  • AzureCloud
  • AzureChinaCloud
  • AzureUSGovernment

Par défaut, Bicep utilise le profil AzureCloud et les informations d’identification de l’utilisateur authentifié dans Azure CLI ou Azure PowerShell. Vous pouvez personnaliser ces profils ou en inclure de nouveaux pour vos environnements locaux. Si vous souhaitez publier ou restaurer un module dans un environnement cloud national tel que AzureUSGovernment, vous devez définir "currentProfile": "AzureUSGovernment" même si vous avez sélectionné ce profil cloud dans Azure CLI. Bicep ne peut pas déterminer automatiquement le profil cloud actuel sur la base des paramètres Azure CLI.

Bicep utilise le SDK Azure.Identity pour effectuer l’authentification. Les types d’informations d’identification disponibles sont les suivants :

Notes

La commande de déploiement Bicep à partir de vscode utilise l’extension de compte Azure pour l’authentification. Elle n’utilise pas les profils cloud de bicepconfig.json.

Étapes suivantes