Publikacja kodu Bicep z pipeline'u wdrożeniowego

Ukończone

Podczas automatyzowania procesu publikowania specyfikacji szablonu lub modułu Bicep należy upewnić się, że wszystko, co zwykle robisz ręcznie, można zautomatyzować i uruchomić w potoku. W tej lekcji stosujesz zasady, które wcześniej poznano, aby opublikować specyfikacje szablonu i moduły Bicep z potoku wdrażania.

Specyfikacje i moduły szablonu

Bicep umożliwia łatwe ponowne użycie kodu. Dwa typowe podejścia do ponownego wykorzystania kodu Bicep przy wdrażaniu to:

• specyfikacje szablonu, które są 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.
• Modules, które są przeznaczone jako komponenty innych wdrożeń. Na przykład, załóżmy, że utworzono plik Bicep, który tworzy konto magazynowe. 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 na potrzeby wdrożeń w całej organizacji.

Podczas podejmowania decyzji między specyfikacjami szablonu a modułami Bicep warto pamiętać o zasadzie: jeśli szablon ma być wdrażany w niezmienionej formie w całej organizacji, specyfikacje szablonu są prawdopodobnie odpowiednim wyborem. Jeśli jednak będziesz często używać tego szablonu w wielu szablonach nadrzędnych, moduły Bicep mogą lepiej spełniać Twoje potrzeby.

Walidacja kodu wielokrotnego użytku w pipeline

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ę szablonu lub moduł. Następnie możesz użyć specyfikacji szablonu lub modułu w innym wdrożeniu. Wdrożenie następnie wdraża zdefiniowane zasoby. W związku z tym sposoby weryfikowania i testowania specyfikacji szablonu oraz modułów Bicep mogą różnić się od procesu używanego w przypadku zwykłych wdrożeń Bicep.

Lintowanie twojego kodu Bicep jest dobrą praktyką. Linter wykrywa problemy składniowe i ostrzega, jeśli nie przestrzegasz zalecanych rozwiązań.

Oprócz lintingu warto 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 potoku 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.

Musisz zdecydować, czy uwzględnić etapy potoku, które wdrażają i testują swoje specyfikacje i moduły szablonów. W module Microsoft Learn sprawdzamy 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. Należy również rozważyć użycie dedykowanych subskrypcji lub grup zasobów w celu wdrożenia zasobów.

Napiwek

Zalecamy przejrzenie testowanie kodu Bicep przy użyciu usługi Azure Pipelines, aby uzyskać więcej informacji na temat testowania plików Bicep w zautomatyzowanym potoku.

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 potokiem wdrażania zautomatyzowanego obowiązują te same zasady. Jednak ponieważ nie jesteś osobą uruchamiającą wdrożenie, musisz upewnić się, że jednostka usługi potoku ma odpowiedni dostęp do grupy zasobów do publikowania specyfikacji szablonu lub do rejestru kontenerów na potrzeby publikowania modułów.

Napiwek

Podczas publikowania modułu do rejestru, główna usługa realizująca wdrożenie prawdopodobnie nie potrzebuje wielu uprawnień. Gdy rejestr korzysta z autoryzacji Microsoft Entra, jednostka usługi potrzebuje jedynie uprawnienia AcrPush w rejestrze.

Rozważ użycie zasady minimalnych uprawnień w kwestiach bezpieczeństwa. Udostępnij jednostce usługi potoku tylko dostęp do rejestru kontenerów i nie do grupy zasobów lub subskrypcji.

Opublikuj specyfikacje i moduły szablonów z pipeline'u

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 \
  --resource-group MyResourceGroup \
  --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

Można przekonwertować to polecenie Azure CLI na krok potoku:

- task: AzureCLI@2
  name: Publish
  displayName: Publish template spec
  inputs:
    azureSubscription: $(ServiceConnectionName)
    scriptType: 'bash'
    scriptLocation: 'inlineScript'
    inlineScript: |
      az ts create \
        --name StorageWithoutSAS \
        --resource-group MyResourceGroup \
        --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

Potok danych używa tego samego procesu, aby opublikować specyfikację szablonu, którego używałbyś 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 również przekształcić to polecenie Azure CLI w etap potoku.

- task: AzureCLI@2
  name: Publish
  displayName: Publish Bicep module
  inputs:
    azureSubscription: $(ServiceConnectionName)
    scriptType: 'bash'
    scriptLocation: 'inlineScript'
    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 przetwarzania. 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 Platformy Microsoft Learn.

Sposób publikowania specyfikacji szablonu z potoku jest opisany 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 publikujesz specyfikacje szablonu i moduły ręcznie, czy z potoku wdrażania, używasz ich i wdrażasz w taki sam sposób.

Można na przykład wdrożyć specyfikację szablonu lub plik Bicep w grupie zasobów za pomocą polecenia Azure CLI az deployment group create lub cmdletu New-AzResourceGroupDeployment w programie Azure PowerShell.