Partilhar via

Adicionar configurações de módulo no arquivo de configuração do Bicep

  • Artigo

Em um arquivo bicepconfig.json , você pode criar aliases para caminhos de módulo e configurar precedência de perfil e credencial para publicação e restauração de módulos.

Este artigo descreve as configurações disponíveis para trabalhar com módulos Bicep.

Aliases para módulos

Para simplificar o caminho de vinculação a módulos, crie aliases no arquivo de configuração. Um alias refere-se a um registro de módulo ou a um grupo de recursos que contém especificações de modelo.

O arquivo de configuração tem uma propriedade para moduleAliases. Esta propriedade contém todos os aliases definidos. Sob essa propriedade, os aliases são divididos com base em se eles se referem a um registro ou uma especificação de modelo.

Para criar um alias para um registro Bicep, adicione uma br propriedade. Para adicionar um alias para uma especificação de modelo, use a ts propriedade.

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

Dentro da br propriedade, adicione quantos aliases precisar. Para cada alias, dê-lhe um nome e as seguintes propriedades:

  • Registro (obrigatório): Nome do servidor de login do Registro
  • modulePath (opcional): repositório do registro onde os módulos são armazenados

Dentro da ts propriedade, adicione quantos aliases precisar. Para cada alias, dê-lhe um nome e as seguintes propriedades:

  • subscrição (obrigatório): o ID de subscrição que aloja as especificações do modelo
  • resourceGroup (obrigatório): o nome do grupo de recursos que contém as especificações do modelo

O exemplo a seguir mostra um arquivo de configuração que define dois aliases para um registro de módulo e um alias para um grupo de recursos que contém especificações de modelo.

{
  "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"
      }
    }
  }
}

Ao usar um alias na referência do módulo, você deve usar os formatos:

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

Defina seus aliases para a pasta ou grupo de recursos que contém módulos, não para o arquivo em si. O nome do arquivo deve ser incluído na referência ao módulo.

Sem os aliases, você vincularia a um módulo em um registro com o caminho completo.

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

Com os aliases, você pode simplificar o link usando o alias para o registro.

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

Ou, você pode simplificar o link usando o alias que especifica o registro e o caminho do módulo.

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

Para uma especificação de modelo, use:

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

Um alias foi predefinido para módulos públicos. Para fazer referência a um módulo público, você pode usar o formato:

br/public:<file>:<tag>

Nota

Os módulos não-AVM (Módulos Verificados do Azure) são retirados do registro do módulo público, com a maioria deles disponível como módulos AVM.

Você pode substituir a definição de alias do Registro do módulo público no arquivo bicepconfig.json:

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

Configurar perfis e credenciais

Para publicar módulos em um registro de módulo privado ou restaurar módulos externos para o cache local, a conta deve ter as permissões corretas para acessar o registro. Você pode configurar currentProfile manualmente e credentialPrecedence no arquivo de configuração do Bicep para autenticação no 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"
    ]
  }
}

Os perfis disponíveis são:

  • AzureCloud
  • AzureChinaCloud
  • AzureUSGovernment

Por padrão, o Bicep usa o AzureCloud perfil e as credenciais do usuário autenticado na CLI do Azure ou no Azure PowerShell. Você pode personalizar esses perfis ou incluir novos para seus ambientes locais. Se quiser publicar ou restaurar um módulo para um ambiente de nuvem nacional, como AzureUSGovernmento , você deve definir "currentProfile": "AzureUSGovernment" mesmo que tenha selecionado esse perfil de nuvem na CLI do Azure. O Bicep não consegue determinar automaticamente o perfil de nuvem atual com base nas configurações da CLI do Azure.

O Bicep usa o SDK Azure.Identity para fazer autenticação. Os tipos de credenciais disponíveis são:

Nota

O comando Bicep deploy no Visual Studio Code usa a nova API de autenticação interna para gerenciar a autenticação. Ele não usa perfis de nuvem do bicepconfig.json. Para iniciar sessão numa nuvem personalizada, selecione Gerir>Definições>Extensão>Contas Microsoft>Sovereign Cloud. Neste momento, não há suporte para várias contas conectadas.

Próximos passos