Publikowanie kodu Bicep z przepływu pracy wdrażania
Podczas automatyzowania procesu publikowania specyfikacji szablonu lub modułu Bicep należy upewnić się, że wszystko, co zwykle robisz samodzielnie, można zautomatyzować i uruchomić w ramach przepływu pracy. W tej lekcji dowiesz się, jak zastosować niektóre z zasad poznanych wcześniej podczas publikowania specyfikacji szablonu i modułów Bicep z przepływu pracy wdrażania.
Specyfikacje i moduły szablonu
Bicep umożliwia łatwe ponowne użycie kodu. Dwa typowe podejścia do ponownego uzyskiwania kodu Bicep we wdrożeniach to:
- Specyfikacje szablonów zoptymalizowane pod kątem wdrażania kompletnych rozwiązań. Załóżmy na przykład, że zdefiniowano zestaw zasobów ze wzmocnionych zabezpieczeniami w celu wdrożenia pełnej maszyny wirtualnej zgodnie ze specyfikacjami firmy. Ten kod można opublikować jako specyfikację szablonu. Twoi współpracownicy mogą następnie użyć specyfikacji szablonu, aby wdrożyć pełną maszynę wirtualną, nawet w witrynie Azure Portal.
- Moduły, które są przeznaczone do składników innych wdrożeń. Załóżmy na przykład, że utworzono plik Bicep, który tworzy konto magazynu. Prawdopodobnie będziesz potrzebować kont magazynu w wielu innych wdrożeniach, więc możesz opublikować plik Bicep w rejestrze i użyć go jako modułu we wszystkich wdrożeniach organizacji.
Podczas podejmowania decyzji między specyfikacjami szablonu i modułami Bicep dobrym rozwiązaniem jest: jeśli szablon zostanie wdrożony w całej organizacji, specyfikacje szablonu są prawdopodobnie dobrym rozwiązaniem. Jeśli jednak prawdopodobnie użyjesz tego szablonu w wielu szablonach nadrzędnych, moduły Bicep mogą lepiej spełniać Twoje potrzeby.
Weryfikowanie kodu wielokrotnego użytku w przepływie pracy
W przeciwieństwie do zwykłych wdrożeń Bicep podczas tworzenia specyfikacji szablonu lub modułu nie wdrażasz zasobów bezpośrednio na platformie Azure. Zamiast tego publikujesz specyfikację lub moduł szablonu. Następnie możesz użyć specyfikacji szablonu lub modułu w innym wdrożeniu. To wdrożenie spowoduje wdrożenie zdefiniowanych zasobów. Ze względu na tę różnicę sposoby weryfikowania i testowania specyfikacji szablonu i modułów Bicep mogą różnić się od procesu używanego w przypadku zwykłych wdrożeń Bicep.
Tworzenie linting kodu Bicep jest dobrym rozwiązaniem. Linter wykrywa problemy składniowe i ostrzega, jeśli nie przestrzegasz zalecanych rozwiązań.
Poza linting możesz rozważyć przetestowanie specyfikacji i modułów szablonu przy użyciu weryfikacji wstępnej. Możesz nawet rozważyć wdrożenie specyfikacji i modułów szablonu na platformie Azure oraz przetestowanie, czy tworzone przez nich zasoby zachowują się zgodnie z oczekiwaniami. Jednak uruchomienie tych typów testów z przepływu pracy wdrażania może być trudne z dwóch powodów:
- Wstępne sprawdzanie poprawności i wdrożenia wymagają środowiska platformy Azure do wdrożenia zasobów. Może być konieczne utrzymanie dedykowanej subskrypcji platformy Azure lub grupy zasobów do użycia do wdrażania i testowania modułów.
- Wiele specyfikacji i modułów szablonu wymaga określenia zestawu parametrów. Może być konieczne utworzenie zestawu testowego parametrów dla specyfikacji szablonu lub modułów do użycia podczas ich wdrażania.
Należy wybrać, czy należy uwzględnić kroki przepływu pracy, które wdrażają i testować specyfikacje i moduły szablonu. W tym module szkoleniowym usługi Microsoft Learn lintujemy kod Bicep, ale nie uwzględniamy innych form testowania. Jeśli chcesz przetestować specyfikacje i moduły szablonu, rozważ wdrożenie ich na platformie Azure. Zastanów się również, czy do wdrażania zasobów będą używane dedykowane subskrypcje lub grupy zasobów.
Napiwek
Zalecamy zapoznanie się z artykułem Testowanie kodu Bicep przy użyciu funkcji GitHub Actions , aby uzyskać więcej informacji na temat testowania plików Bicep w zautomatyzowanym przepływie pracy.
Uwierzytelnianie i autoryzacja
Podczas samodzielnego publikowania specyfikacji szablonu na platformie Azure użytkownik firmy Microsoft Entra musi mieć dostęp do grupy zasobów zawierającej zasób specyfikacji szablonu. Podobnie podczas publikowania modułu Bicep w rejestrze użytkownik firmy Microsoft Entra musi mieć uprawnienia do zapisu w wystąpieniu usługi Azure Container Registry używanym przez organizację na potrzeby modułów Bicep.
W przypadku pracy z zautomatyzowanym przepływem pracy wdrażania obowiązują te same zasady. Jednak ponieważ nie jesteś osobą uruchamiającą wdrożenie, musisz upewnić się, że tożsamość przepływu pracy ma odpowiedni dostęp do grupy zasobów na potrzeby publikowania specyfikacji szablonu lub do rejestru kontenerów na potrzeby publikowania modułów.
Napiwek
Podczas publikowania modułu w rejestrze tożsamość obciążenia uruchomiona we wdrożeniu prawdopodobnie nie potrzebuje wielu uprawnień. Gdy rejestr używa autoryzacji Microsoft Entra, tożsamość obciążenia wymaga tylko uprawnień AcrPush w rejestrze.
Rozważ użycie zasady zabezpieczeń najniższych uprawnień. Podaj tożsamość przepływu pracy z dostępem tylko do rejestru kontenerów, a nie do grupy zasobów lub subskrypcji.
Publikowanie specyfikacji szablonu i modułów z przepływu pracy
Podczas publikowania specyfikacji szablonu na własnym komputerze przy użyciu interfejsu wiersza polecenia platformy Azure należy użyć polecenia podobnego do następującego:
az ts create \
--name StorageWithoutSAS \
--location westus3 \
--display-name "Storage account with SAS disabled" \
--description "This template spec creates a storage account, which is preconfigured to disable SAS authentication." \
--version 1 \
--template-file main.bicep
To polecenie interfejsu wiersza polecenia platformy Azure można przekonwertować na krok funkcji GitHub Actions:
- name: Publish template spec
uses: azure/cli@v1
with:
inlineScript: |
az ts create \
--name StorageWithoutSAS \
--location westus3 \
--display-name "Storage account with SAS disabled" \
--description "This template spec creates a storage account, which is preconfigured to disable SAS authentication." \
--version 1 \
--template-file main.bicep
Przepływ pracy używa tego samego procesu, aby opublikować specyfikację szablonu, której będziesz używać samodzielnie.
Podobnie podczas publikowania modułu Bicep z własnego komputera przy użyciu interfejsu wiersza polecenia platformy Azure należy użyć polecenia podobnego do następującego:
az bicep publish \
--file module.bicep \
--target 'br:toycompany.azurecr.io/mymodules/myqueue:2'
Możesz też przekonwertować to polecenie interfejsu wiersza polecenia platformy Azure na krok funkcji GitHub Actions:
- name: Publish Bicep module
uses: azure/cli@v1
with:
inlineScript: |
az bicep publish \
--file module.bicep \
--target 'br:toycompany.azurecr.io/mymodules/myqueue:2'
Napiwek
W tym przykładzie nazwa hosta rejestru Bicep (toycompany.azurecr.io) jest osadzona w definicji kroku przepływu pracy. Nie jest to dobra praktyka. Możesz użyć zmiennych środowiskowych, aby ustawić ustawienia konfiguracji w następujący sposób. Zobaczysz, jak to działa w dalszej części tego modułu szkoleniowego usługi Microsoft Learn.
Wkrótce zobaczysz, jak opublikować specyfikację szablonu z przepływu pracy, wykonując kroki opisane w tej lekcji.
Używanie specyfikacji modułu lub szablonu
W poprzednich modułach szkoleniowych usługi Microsoft Learn przedstawiono sposób wdrażania zasobów zdefiniowanych w specyfikacji szablonu oraz używania modułów Bicep przechowywanych w rejestrach. Niezależnie od tego, czy tworzysz specyfikacje szablonu i moduły ręcznie, czy z przepływu pracy wdrażania, użyjesz ich i wdrożysz w taki sam sposób.
Można na przykład wdrożyć specyfikację szablonu lub plik Bicep w grupie zasobów przy użyciu polecenia interfejsu az deployment group create wiersza polecenia platformy Azure lub New-AzResourceGroupDeployment polecenia cmdlet za pomocą programu Azure PowerShell.