Konfigurowanie środowiska Bicep
Bicep obsługuje opcjonalny plik konfiguracji o nazwie bicepconfig.json. W tym pliku możesz dodać wartości, które dostosują środowisko deweloperskie Bicep. Ten plik jest scalony z domyślnym plikiem konfiguracji. Aby uzyskać więcej informacji, zobacz Omówienie procesu scalania. Aby dostosować konfigurację, utwórz plik konfiguracji w tym samym katalogu lub katalogu nadrzędnym plików Bicep. Jeśli istnieje wiele katalogów nadrzędnych zawierających bicepconfig.json plików, Bicep używa konfiguracji z najbliższej. Aby uzyskać więcej informacji, zobacz Omówienie procesu rozpoznawania plików.
Aby skonfigurować ustawienia rozszerzenia Bicep, zobacz Rozszerzenia Visual Studio Code i Bicep.
Tworzenie pliku konfiguracji w programie Visual Studio Code
Do utworzenia pliku konfiguracji można użyć dowolnego edytora tekstów.
Aby utworzyć plik bicepconfig.json w programie Visual Studio Code, otwórz paletę poleceń ([CTRL/CMD]+[SHIFT]+P), a następnie wybierz pozycję Bicep: Utwórz plik konfiguracji Bicep. Aby uzyskać więcej informacji, zobacz Create Bicep configuration file (Tworzenie pliku konfiguracji Bicep).
Rozszerzenie Bicep dla programu Visual Studio Code obsługuje funkcję IntelliSense dla plików bicepconfig.json . Użyj funkcji IntelliSense, aby odnaleźć dostępne właściwości i wartości.
Omówienie procesu scalania
Plik bicepconfig.json przechodzi cyklicznego procesu scalania z domyślnym plikiem konfiguracji. Podczas procesu scalania Bicep analizuje każdą ścieżkę w obu konfiguracjach. Jeśli ścieżka nie jest obecna w konfiguracji domyślnej, ścieżka i skojarzona z nią wartość zostaną dodane w końcowym wyniku. Z drugiej strony, jeśli ścieżka istnieje w konfiguracji domyślnej z inną wartością, wartość z bicepconfig.json ma pierwszeństwo w scalanym wyniku.
Rozważmy scenariusz, w którym konfiguracja domyślna jest zdefiniowana w następujący sposób:
{
"cloud": {
...
"credentialPrecedence": [
"AzureCLI",
"AzurePowerShell"
]
},
"moduleAliases": {
"ts": {},
"br": {
"public": {
"registry": "mcr.microsoft.com",
"modulePath": "bicep"
}
}
},
...
}
A bicepconfig.json jest definiowana w następujący sposób:
{
"cloud": {
"credentialPrecedence": [
"AzurePowerShell",
"AzureCLI"
]
},
"moduleAliases": {
"br": {
"ContosoRegistry": {
"registry": "contosoregistry.azurecr.io"
},
"CoreModules": {
"registry": "contosoregistry.azurecr.io",
"modulePath": "bicep/modules/core"
}
}
}
}
Wynikowa scalona konfiguracja będzie:
{
"cloud": {
...
"credentialPrecedence": [
"AzurePowerShell",
"AzureCLI"
]
},
"moduleAliases": {
"ts": {},
"br": {
"public": {
"registry": "mcr.microsoft.com",
"modulePath": "bicep"
},
"ContosoRegistry": {
"registry": "contosoregistry.azurecr.io"
},
"CoreModules": {
"registry": "contosoregistry.azurecr.io",
"modulePath": "bicep/modules/core"
}
}
},
...
}
W poprzednim przykładzie wartość cloud.credentialPrecedence
jest zastępowana, a wartości cloud.moduleAliases.ContosoRegistry
i cloud.moduleAliases.CoreModules
są dołączane do scalonej konfiguracji.
Omówienie procesu rozpoznawania plików
Plik bicepconfig.json można umieścić w tym samym katalogu lub katalogu nadrzędnym plików Bicep. Jeśli istnieje wiele katalogów nadrzędnych zawierających pliki bicepconfig.json , Bicep używa pliku konfiguracji z najbliższego. Na przykład w danej strukturze folderów, w której każdy folder ma plik bicepconfig.json :
Jeśli skompilujesz plik main.bicep w folderzechild
, zostanie użyty plik bicepconfig.json w folderzechild
. Pliki konfiguracji w folderze parent
i root
folderze są ignorowane. child
Jeśli folder nie zawiera pliku konfiguracji, Bicep wyszukuje konfigurację w folderzeparent
, a następnie root
folder. Jeśli plik konfiguracji nie zostanie znaleziony w żadnym z folderów, Bicep domyślnie używa wartości domyślnych.
W kontekście pliku Bicep wywołującego wiele modułów każdy moduł przechodzi kompilację przy użyciu najbliższej bicepconfig.json. Następnie główny plik Bicep jest kompilowany z odpowiednimi bicepconfig.json. W poniższym scenariuszu modA.bicep
jest kompilowany przy użyciu bicepconfig.json znajdujących się w A
folderze, modB.bicep
jest kompilowany z bicepconfig.json w B
folderze, a na koniec plik main.bicep jest kompilowany przy użyciu bicepconfig.json w folderze root
.
W przypadku braku pliku bicepconfig.json w A
folderach i B
wszystkie trzy pliki Bicep są kompilowane przy użyciu bicepconfig.json znalezionych w folderze root
. Jeśli bicepconfig.json nie istnieje w żadnym z folderów, kompilacja domyślnie używa wartości domyślnych.
Konfigurowanie modułów Bicep
Podczas pracy z modułami można dodać aliasy dla ścieżek modułów. Te aliasy upraszczają plik Bicep, ponieważ nie trzeba powtarzać skomplikowanych ścieżek. Możesz również skonfigurować pierwszeństwo profilu chmury i poświadczeń na potrzeby uwierzytelniania na platformie Azure z poziomu interfejsu wiersza polecenia Bicep i programu Visual Studio Code. Poświadczenia są używane do publikowania modułów w rejestrach i przywracania modułów zewnętrznych do lokalnej pamięci podręcznej podczas korzystania z funkcji wstawiania zasobów. Aby uzyskać więcej informacji, zobacz Dodawanie ustawień modułu do konfiguracji Bicep.
Konfigurowanie reguł linter
Linter Bicep sprawdza pliki Bicep pod kątem błędów składni i naruszeń najlepszych rozwiązań. Możesz zmodyfikować plik bicepconfig.json , aby zastąpić ustawienia domyślne sposobu weryfikacji pliku Bicep. Aby uzyskać więcej informacji, zobacz Dodawanie ustawień linter do konfiguracji Bicep.
Włączanie funkcji eksperymentalnych
Funkcje eksperymentalne można włączyć, dodając następującą sekcję do pliku bicepconfig.json . Korzystanie z funkcji eksperymentalnych automatycznie włącza generowanie kodu w wersji 2.0 języka.
Oto przykład włączania funkcji "asercji" i "testFramework".
{
"experimentalFeaturesEnabled": {
"assertions": true,
"testFramework": true
}
}
Zobacz Funkcje eksperymentalne, aby uzyskać więcej informacji na temat funkcji eksperymentalnych Bicep.
Następne kroki
- Dowiedz się, jak dodać ustawienia modułu i ustawienia linter w pliku konfiguracji Bicep.
- Dowiedz się więcej o linterze Bicep.