Adición de una configuración de módulo en el archivo de configuración de Bicep
En un archivo bicepconfig.json, puede crear alias para las rutas de acceso del módulo y configurar la precedencia de perfiles y credenciales para publicar y restaurar un módulo.
En este artículo se describe la configuración disponible para trabajar con módulos de Bicep.
Alias para módulos
A fin de simplificar la ruta de acceso para vincular a los módulos, puede crear alias en el archivo de configuración. Un alias puede hacer referencia a un registro de módulo o a un grupo de recursos que contiene especificaciones de plantilla.
El archivo de configuración tiene una propiedad para moduleAliases. Esta propiedad contiene todos los alias que defina. En esta propiedad, los alias se dividen en función de si hacen referencia a un registro o a una especificación de plantilla.
A fin de crear un alias para un registro de Bicep, agregue una propiedad br. Si quiere agregar un alias para una especificación de plantilla, use la propiedad ts.
{
"moduleAliases": {
"br": {
<add-registry-aliases>
},
"ts": {
<add-template-specs-aliases>
}
}
}
En la propiedad br, agregue tantos alias como necesite. Para cada alias, asigne un nombre y las siguientes propiedades:
- registry (obligatorio): nombre del servidor de inicio de sesión del registro
- modulePath (opcional): repositorio del registro donde se almacenan los módulos
En la propiedad ts, agregue tantos alias como necesite. Para cada alias, asigne un nombre y las siguientes propiedades:
- subscription (obligatorio): el id. de la suscripción que hospeda las especificaciones de plantilla
- resourceGroup (obligatorio): el nombre del grupo de recursos que contiene las especificaciones de plantilla
En el ejemplo siguiente se muestra un archivo de configuración que define dos alias para un registro de módulos y un alias para un grupo de recursos que contiene especificaciones de plantilla.
{
"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"
}
}
}
}
Al usar un alias en la referencia del módulo, debe usar los formatos siguientes:
br/<alias>:<file>:<tag>
ts/<alias>:<file>:<tag>
Defina los alias en la carpeta o el grupo de recursos que contiene los módulos, no en el propio archivo. El nombre de archivo debe incluirse en la referencia al módulo.
Sin los alias, se vincularía a un módulo de un registro con la ruta de acceso completa.
module stgModule 'br:contosoregistry.azurecr.io/bicep/modules/core/storage:v1' = {
Con los alias, puede simplificar el vínculo mediante el alias para el registro.
module stgModule 'br/ContosoRegistry:bicep/modules/core/storage:v1' = {
También puede simplificar el vínculo mediante el alias que especifica la ruta de acceso del registro y del módulo.
module stgModule 'br/CoreModules:storage:v1' = {
En el caso de una especificación de plantilla, use lo siguiente:
module stgModule 'ts/CoreSpecs:storage:v1' = {
Se ha predefinido un alias para módulos públicos. Para hacer referencia a un módulo público, puede usar el formato:
br/public:<file>:<tag>
Nota:
Los módulos que no son de AVM (módulos comprobados de Azure) se retiran del registro de módulos públicos con la mayoría de ellos disponibles como módulos de AVM.
Puede invalidar la definición de alias del registro del módulo público en el archivo bicepconfig.json file:
{
"moduleAliases": {
"br": {
"public": {
"registry": "<your_module_registry>",
"modulePath": "<optional_module_path>"
}
}
}
}
Configuración de perfiles y credenciales
Para publicar módulos en un registro de módulos privado o para restaurar módulos externos en la caché local, la cuenta debe tener los permisos correctos para acceder al registro. Puede configurar manualmente currentProfile y credentialPrecedence en el archivo de configuración de Bicep para autenticarse en el registro.
{
"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"
]
}
}
Los perfiles disponibles son:
- AzureCloud
- AzureChinaCloud
- AzureUSGovernment
De forma predeterminada, Bicep usa el perfil de AzureCloud y las credenciales del usuario autenticado en la CLI de Azure o Azure PowerShell. Puede personalizar estos perfiles o incluir otros nuevos para los entornos locales. Si desea publicar o restaurar un módulo en un entorno de nube nacional, como AzureUSGovernment, debe establecer "currentProfile": "AzureUSGovernment" incluso si ha seleccionado ese perfil de nube en la CLI de Azure. Bicep no puede determinar automáticamente el perfil de nube actual en función de la configuración de la CLI de Azure.
Bicep usa el SDK de Azure.Identity para realizar la autenticación. Los tipos de credenciales disponibles son:
Nota:
El comando De implementación de Bicep en Visual Studio Code usa la nueva API de autenticación integrada para administrar la autenticación. No usa perfiles de nube de bicepconfig.json. Para iniciar sesión en una nube personalizada, seleccione Administrar configuración de>configuración>extensión>cuentas de Microsoft>Microsoft Sovereign Cloud. En este momento, no se admiten varias cuentas de inicio de sesión.
Pasos siguientes
- Configuración del entorno de Bicep
- Adición de la configuración de linter a la configuración de Bicep
- Más información sobre los módulos