Wdrażanie plików Bicep przy użyciu potoku

  • 7 min

Po utworzeniu podstawowego potoku możesz przystąpić do konfigurowania potoku w celu wdrożenia plików Bicep. W tej lekcji dowiesz się, jak wdrożyć kod Bicep z potoku i jak skonfigurować kroki wdrażania.

Uwaga

Polecenia w tej lekcji są wyświetlane w celu zilustrowania pojęć. Nie uruchamiaj jeszcze poleceń. Będziesz ćwiczyć to, czego nauczysz się tutaj wkrótce.

Połączenia z usługą

Podczas wdrażania pliku Bicep z własnego komputera należy użyć interfejsu wiersza polecenia platformy Azure lub programu Azure PowerShell. Zanim będzie można wdrożyć kod, zaloguj się na platformie Azure. Zwykle narzędzia proszą o wprowadzenie adresu e-mail i hasła w przeglądarce. Po zweryfikowaniu poświadczeń twoje uprawnienia do wdrażania zasobów zostaną potwierdzone i możesz użyć narzędzi do wdrożenia pliku Bicep.

Wdrożenie według potoku wymaga też uwierzytelniania. Ponieważ potoki działają bez interwencji człowieka, potoki uwierzytelniają się na platformie Azure przy użyciu jednostki usługi. Poświadczenia jednostki usługi składają się z identyfikatora aplikacji i wpisu tajnego, który zazwyczaj jest kluczem lub certyfikatem. W usłudze Azure Pipelines użyjesz połączenia usługi, aby bezpiecznie przechowywać te poświadczenia, aby potok mógł ich używać. Połączenie z usługą zawiera również inne informacje ułatwiające potokowi zidentyfikowanie środowiska platformy Azure, do którego chcesz wdrożyć.

Napiwek

W tym module użyjesz usługi Azure DevOps do automatycznego utworzenia jednostki usługi podczas tworzenia połączenia z usługą. Moduł Uwierzytelnianie potoku wdrażania platformy Azure przy użyciu jednostek usługi zawiera bardziej szczegółowe wyjaśnienie jednostek usługi, w tym sposobu ich działania, a także sposobu ich tworzenia, przypisywania ról i zarządzania nimi.

Podczas tworzenia połączenia z usługą należy nazwać połączenie. Kroki odwołują się do połączenia z usługą przy użyciu tej nazwy, więc kod YAML potoku nie musi zawierać informacji tajnych.

Po uruchomieniu potoku agent, który uruchamia kroki wdrażania, ma dostęp do połączenia z usługą, w tym jego poświadczeń. Krok potoku używa poświadczeń do logowania się na platformie Azure, podobnie jak logowanie się samodzielnie. Następnie akcje zdefiniowane w kroku używają tożsamości jednostki usługi.

Diagram that shows a pipeline that includes an Azure deployment step, which accesses a service connection and then deploys to Azure.

Musisz upewnić się, że jednostka usługi ma uprawnienia wymagane do wykonania kroków wdrażania. Na przykład może być konieczne przypisanie jednostki usługi roli Współautor dla grupy zasobów, do której wdraża zasoby.

Ostrzeżenie

Może się wydawać, że łatwiej będzie przechowywać poświadczenia jednostki usługi w pliku YAML, a następnie zalogować się przy użyciu az login polecenia . Nigdy nie należy używać tego podejścia do uwierzytelniania jednostki usługi. Poświadczenia w pliku YAML są przechowywane w postaci zwykłego tekstu. Każdy, kto ma dostęp do repozytorium, może wyświetlać poświadczenia i używać ich. Nawet jeśli ograniczysz dostęp do organizacji i projektu usługi Azure DevOps, za każdym razem, gdy ktoś sklonuje repozytorium, plik YAML, który przechowuje poświadczenia, będzie znajdować się na komputerze tej osoby. Ważne jest, aby używać połączenia z usługą za każdym razem, gdy pracujesz z platformą Azure z potoku. Połączenia usług zapewniają również inne funkcje zabezpieczeń i kontroli dostępu.

Połączenia usług są tworzone w projekcie usługi Azure DevOps. Jedno połączenie usługi może być współużytkowane przez wiele potoków. Jednak zazwyczaj dobrym pomysłem jest skonfigurowanie połączenia z usługą i odpowiedniej jednostki usługi dla każdego potoku i każdego wdrażanego środowiska. Ta praktyka pomaga zwiększyć bezpieczeństwo potoków i zmniejsza prawdopodobieństwo przypadkowego wdrożenia lub skonfigurowania zasobów w innym środowisku niż oczekiwana.

Możesz również skonfigurować połączenie usługi, aby można było go używać tylko w określonych potokach. Na przykład podczas tworzenia połączenia z usługą wdrażanego w środowisku produkcyjnym witryny internetowej dobrym pomysłem jest upewnienie się, że tylko potok witryny internetowej może używać tego połączenia z usługą. Ograniczenie połączenia z usługą do określonych potoków uniemożliwia innej osobie przypadkowe użycie tego samego połączenia usługi dla innego projektu i potencjalnie spowodowanie, że produkcyjna witryna internetowa przestanie działać.

Wdrażanie pliku Bicep przy użyciu zadania rozmieszczania grupy zasobów platformy Azure

Jeśli musisz wdrożyć plik Bicep z potoku, możesz użyć zadania wdrażania grupy zasobów platformy Azure. Oto przykład konfigurowania kroku w celu użycia zadania:

- task: AzureResourceManagerTemplateDeployment@3
  inputs:
    connectedServiceName: 'MyServiceConnection'
    location: 'westus3'
    resourceGroupName: Example
    csmFile: deploy/main.bicep
    overrideParameters: >
        -parameterName parameterValue

Pierwszy wiersz określa AzureResourceManagerTemplateDeployment@3. Informuje ona usługę Azure Pipelines, że zadanie, którego chcesz użyć w tym kroku, nosi nazwę AzureResourceManagerTemplateDeploymenti chcesz użyć wersji 3 zadania.

W przypadku korzystania z zadania rozmieszczania grupy zasobów platformy Azure należy określić dane wejściowe, aby poinformować zadanie o tym, co należy zrobić. Poniżej przedstawiono niektóre dane wejściowe, które można określić podczas korzystania z zadania:

  • connectedServiceName to nazwa połączenia usługi do użycia.
  • location należy określić, mimo że jej wartość może nie być używana. Zadanie rozmieszczania grupy zasobów platformy Azure może również utworzyć grupę zasobów, a jeśli tak, musi znać region świadczenia usługi Azure, w którym ma zostać utworzona grupa zasobów. W tym module określisz wartość wejściową location , ale jej wartość nie jest używana.
  • resourceGroupName określa nazwę grupy zasobów, do którego ma zostać wdrożony plik Bicep.
  • overrideParameters zawiera wszystkie wartości parametrów, które mają zostać przekazane do pliku Bicep w czasie wdrażania.

Po uruchomieniu zadania używa połączenia usługi do logowania się na platformie Azure. Po uruchomieniu określonego wdrożenia zadanie zostało uwierzytelnione. Nie trzeba uruchamiać polecenia az login.

Uruchamianie poleceń interfejsu wiersza polecenia platformy Azure i programu Azure PowerShell

Dwa z najbardziej przydatnych wbudowanych zadań w usłudze Azure Pipelines to interfejs wiersza polecenia platformy Azure i zadania programu Azure PowerShell. Za pomocą tych zadań można wykonywać co najmniej jedno polecenie interfejsu wiersza polecenia platformy Azure lub programu PowerShell.

W przyszłych modułach usługi Microsoft Learn zobaczysz, jak polecenie interfejsu wiersza polecenia platformy Azure może pomóc zautomatyzować więcej części procesu wdrażania z potoku.

Zmienne

Często potoki zawierają wartości, które mają być oddzielone od pliku YAML. Na przykład podczas wdrażania pliku Bicep w grupie zasobów należy określić nazwę grupy zasobów. Nazwa grupy zasobów prawdopodobnie różni się podczas wdrażania w różnych środowiskach. Może być również konieczne podanie parametrów dla plików Bicep, w tym wpisów tajnych, takich jak hasła serwera bazy danych. Nie przechowuj tych wartości w pliku YAML potoku ani w innym miejscu w repozytorium Git. Zamiast tego, aby zwiększyć bezpieczeństwo i uczynić definicje potoków wielokrotnego użytku, użyj zmiennych.

Tworzenie zmiennej

Interfejs internetowy usługi Azure Pipelines zawiera edytor, którego można użyć do tworzenia zmiennych dla potoku:

Screenshot of Azure DevOps that shows creating a new variable.

Wartość zmiennej usługi Azure Pipelines można ustawić jako wpis tajny. Po ustawieniu wartości zmiennej jako wpisu tajnego nie można wyświetlić wartości po jej ustawieniu. Usługa Azure Pipelines została zaprojektowana tak, aby nie ujawniała wartości wpisów tajnych w dziennikach potoku.

Ostrzeżenie

Domyślnie usługa Azure Pipelines zaciemnia wartości zmiennych wpisów tajnych w dziennikach potoku, ale należy również postępować zgodnie z dobrymi rozwiązaniami. Kroki potoku mają dostęp do wszystkich wartości zmiennych, w tym wpisów tajnych. Jeśli potok zawiera krok, który nie obsługuje bezpiecznej zmiennej, istnieje prawdopodobieństwo, że zmienna wpisu tajnego może być wyświetlana w dziennikach potoku.

Możesz zezwolić użytkownikom na zastąpienie wartości zmiennej po ręcznym uruchomieniu potoku. Wartość udostępniana przez użytkownika jest używana tylko dla tego konkretnego uruchomienia potoku. Przesłonięcia zmiennych mogą być przydatne podczas testowania potoku.

Używanie zmiennej w potoku

Po utworzeniu zmiennej użyjesz określonej składni, aby odwołać się do zmiennej w pliku YAML potoku:

- task: AzureResourceManagerTemplateDeployment@3
  inputs:
    connectedServiceName: $(ServiceConnectionName)
    location: $(DeploymentDefaultLocation)
    resourceGroupName: $(ResourceGroupName)
    csmFile: deploy/main.bicep
    overrideParameters: >
      -environmentType $(EnvironmentType)

Format pliku definicji potoku zawiera specjalną $(VariableName) składnię. Możesz odwołać się do dowolnej zmiennej przy użyciu tej metody, niezależnie od tego, czy jest ona wpisem tajnym, czy nie.

Napiwek

W poprzednim przykładzie zwróć uwagę, że nazwa pliku Bicep nie jest przechowywana w zmiennej. Podobnie jak w przypadku parametrów Bicep, nie trzeba tworzyć zmiennych dla wszystkich elementów. Dobrym pomysłem jest utworzenie zmiennych dla wszystkich elementów, które mogą ulec zmianie między środowiskami i dla wszystkich elementów tajnych. Ponieważ potok zawsze będzie używać tego samego pliku szablonu, nie musisz tworzyć zmiennej dla ścieżki.

Zmienne systemowe

Usługa Azure Pipelines używa również zmiennych systemowych. Zmienne systemowe zawierają wstępnie zdefiniowane informacje, których można użyć w potoku. Poniżej przedstawiono niektóre zmienne systemowe, których można użyć w potoku:

  • Build.BuildNumber jest unikatowym identyfikatorem przebiegu potoku. Pomimo jej nazwy Build.BuildNumber wartość często jest ciągiem, a nie liczbą. Możesz użyć tej zmiennej, aby nazwać wdrożenie platformy Azure, aby śledzić wdrożenie z powrotem do określonego uruchomienia potoku, które go wyzwoliło.
  • Agent.BuildDirectory to ścieżka w systemie plików komputera agenta, w którym są przechowywane pliki przebiegu potoku. Te informacje mogą być przydatne, gdy chcesz odwoływać się do plików agenta kompilacji.

Tworzenie zmiennych w pliku YAML potoku

Oprócz używania interfejsu internetowego usługi Azure Pipelines do tworzenia zmiennych można ustawić wartości zmiennych w pliku YAML potoku. Możesz użyć tej opcji, jeśli masz wartości, które nie są tajne, gdy wartości mogą być przechowywane w repozytorium, a kiedy chcesz zachować wartości zmiennych w jednym miejscu w pliku, aby można było odwoływać się do nich w całej definicji potoku. Tego podejścia można użyć do śledzenia zmian w zmiennej w systemie kontroli wersji.

Aby ustawić zmienną w pliku YAML, dodaj sekcję variables :

trigger: none

pool:
  vmImage: ubuntu-latest

variables:
  ServiceConnectionName: 'MyServiceConnection'
  EnvironmentType: 'Test'
  ResourceGroupName: 'MyResourceGroup'
  DeploymentDefaultLocation: 'westus3'

jobs:
- job:
  steps:
  - task: AzureResourceManagerTemplateDeployment@3
    inputs:
      connectedServiceName: $(ServiceConnectionName)
      location: $(DeploymentDefaultLocation)
      resourceGroupName: $(ResourceGroupName)
      csmFile: deploy/main.bicep
      overrideParameters: >
        -environmentType $(EnvironmentType)

W tym przykładzie potoku zdefiniowano cztery zmienne: ServiceConnectionName, , EnvironmentTypeResourceGroupNamei DeploymentDefaultLocation.

W dalszej części tego modułu zobaczysz, jak można mieszać zmienne zdefiniowane w różnych miejscach w jednym potoku.