Dodawanie ustawień modułu w pliku konfiguracji Bicep
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 w programie Visual Studio Code używa nowego wbudowanego interfejsu API uwierzytelniania do zarządzania uwierzytelnianiem. Nie używa profilów chmury z bicepconfig.json. Aby zalogować się do chmury niestandardowej, wybierz pozycję Zarządzaj>>rozszerzeniami>>Microsoft Accounts Microsoft Sovereign Cloud. Obecnie wiele kont zalogowanych nie jest obsługiwanych.
Następne kroki
- Konfigurowanie środowiska Bicep
- Dodawanie ustawień linter do konfiguracji Bicep
- Dowiedz się więcej o modułach