Udostępnij za pośrednictwem

Dodawanie ustawień modułu w pliku konfiguracji Bicep

  • Artykuł

W pliku bicepconfig.json można utworzyć aliasy dla ścieżek modułów oraz skonfigurować pierwszeństwo profilu i poświadczeń na potrzeby publikowania i przywracania modułów.

W tym artykule opisano ustawienia dostępne do pracy z modułami Bicep.

Aliasy dla modułów

Aby uprościć ścieżkę łączenia z modułami, utwórz aliasy w pliku konfiguracji. Alias odnosi się do rejestru modułów lub grupy zasobów zawierającej specyfikacje szablonu.

Plik konfiguracji ma właściwość .moduleAliases Ta właściwość zawiera wszystkie zdefiniowane aliasy. W ramach tej właściwości aliasy są podzielone na podstawie tego, czy odwołują się do rejestru, czy specyfikacji szablonu.

Aby utworzyć alias dla rejestru Bicep, dodaj br właściwość. Aby dodać alias specyfikacji szablonu, użyj ts właściwości .

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

W ramach właściwości dodaj dowolną br liczbę aliasów. Dla każdego aliasu nadaj mu nazwę i następujące właściwości:

  • rejestr (wymagany): nazwa serwera logowania rejestru
  • modulePath (opcjonalnie): repozytorium rejestru, w którym są przechowywane moduły

W ramach właściwości dodaj dowolną ts liczbę aliasów. Dla każdego aliasu nadaj mu nazwę i następujące właściwości:

  • subskrypcja (wymagana): identyfikator subskrypcji hostujący specyfikacje szablonu
  • resourceGroup (wymagane): nazwa grupy zasobów zawierającej specyfikacje szablonu

W poniższym przykładzie przedstawiono plik konfiguracji, który definiuje dwa aliasy rejestru modułów i jeden alias dla grupy zasobów zawierającej specyfikacje szablonu.

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

W przypadku korzystania z aliasu w dokumentacji modułu należy użyć formatów:

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

Zdefiniuj aliasy do folderu lub grupy zasobów zawierającej moduły, a nie sam plik. Nazwa pliku musi być uwzględniona w odwołaniu do modułu.

Bez aliasów można połączyć się z modułem w rejestrze z pełną ścieżką.

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

Za pomocą aliasów można uprościć link przy użyciu aliasu dla rejestru.

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

Możesz też uprościć link przy użyciu aliasu określającego ścieżkę rejestru i modułu.

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

W przypadku specyfikacji szablonu użyj:

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

Alias został wstępnie zdefiniowany dla modułów publicznych. Aby odwołać się do modułu publicznego, możesz użyć formatu:

br/public:<file>:<tag>

Uwaga

Moduły inne niż AVM (moduły zweryfikowane platformy Azure) są wycofane z publicznego rejestru modułów, a większość z nich jest dostępna jako moduły AVM.

Definicję aliasu rejestru publicznego modułu można zastąpić w pliku bicepconfig.json:

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

Konfigurowanie profilów i poświadczeń

Aby opublikować moduły w rejestrze modułów prywatnych lub przywrócić moduły zewnętrzne do lokalnej pamięci podręcznej, konto musi mieć odpowiednie uprawnienia dostępu do rejestru. Możesz ręcznie skonfigurować currentProfile plik credentialPrecedence konfiguracji i w pliku konfiguracji Bicep na potrzeby uwierzytelniania w rejestrze.

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

Dostępne profile to:

  • AzureCloud
  • AzureChinaCloud
  • AzureUSGovernment

Domyślnie Bicep używa AzureCloud profilu i poświadczeń użytkownika uwierzytelnionego w interfejsie wiersza polecenia platformy Azure lub w programie Azure PowerShell. Możesz dostosować te profile lub dołączyć nowe dla środowisk lokalnych. Jeśli chcesz opublikować lub przywrócić moduł do środowiska chmury krajowej, takiego jak AzureUSGovernment, musisz ustawić "currentProfile": "AzureUSGovernment" , nawet jeśli wybrano ten profil w chmurze w interfejsie wiersza polecenia platformy Azure. Bicep nie może automatycznie określić bieżącego profilu chmury na podstawie ustawień interfejsu wiersza polecenia platformy Azure.

Bicep używa zestawu AZURE.Identity SDK do uwierzytelniania. Dostępne typy poświadczeń to:

Uwaga

Polecenie Bicep deploy z poziomu programu vscode używa rozszerzenia konta platformy Azure do uwierzytelniania. Nie używa profilów chmury z bicepconfig.json.

Następne kroki