Omówienie kompleksowej obsługi wdrożeń

  • 5 min

Potoki to elastyczne narzędzia, które można skonfigurować na wiele różnych sposobów, aby odpowiadały Twoim potrzebom. W tej lekcji dowiesz się, jak używać potoków do wdrażania całego rozwiązania, w tym konfigurowania infrastruktury platformy Azure i wykonywania innych operacji wdrażania.

Ile potoków?

W niektórych organizacjach zespół zarządzający środowiskiem platformy Azure różni się od zespołu, który opracowuje kod uruchamiany w środowisku. W takich sytuacjach często kuszące jest utworzenie wielu potoków, z których każdy jest własnością zespołu odpowiedzialnego za dany obszar. Możesz na przykład utworzyć jeden potok, aby wdrożyć kod Bicep, który wdraża zasoby platformy Azure witryny internetowej, oraz inny potok, który wdraża aplikację witryny internetowej.

Mimo że takie podejście może zapewnić pewną elastyczność w sposobie zarządzania potokami, może to być trudne, aby zachować wszystko w synchronizacji. Załóżmy na przykład, że zespół witryny internetowej potrzebuje nowego ustawienia w swojej aplikacji usługi aplikacja systemu Azure Service, aby umożliwić tworzenie funkcji. Potok wdrażania aplikacji nie może działać, dopóki potok wdrażania infrastruktury nie zakończy się pomyślnie. Ponadto może to być skomplikowane w przypadku wysyłania danych, takich jak nazwy zasobów platformy Azure utworzonych przez potok infrastruktury między potokami.

Zamiast tego często lepiej jest utworzyć pojedynczy potok, który wdraża wszystkie elementy wymagane dla rozwiązania, nawet jeśli różne osoby lub różne zespoły zarządzają składnikami. Aby koordynować swoją pracę, możesz użyć narzędzi, takich jak Git i Azure DevOps. Po dodaniu nowej funkcji można użyć gałęzi, aby wprowadzić niezbędne zmiany w pliku Bicep. Gdy zmiana jest gotowa do zintegrowania i wydania, pojedynczy potok wykonuje wszystkie kroki niezbędne do skompilowania i wdrożenia rozwiązania. Pojedynczy potok zmniejsza prawdopodobieństwo wylogowania się z synchronizacji.

Napiwek

Podczas kompilowania kodu dla rozwiązania prawdopodobnie trzeba go często wdrażać, aby można było przetestować jego działanie. Może się okazać, że wdrażanie infrastruktury wraz z kodem aplikacji spowalnia działanie potoku i hamuje postęp.

Jeśli jesteś na tym stanowisku, możesz rozważyć wyłączenie wdrożenia infrastruktury dla środowiska deweloperskiego. Aby to osiągnąć, możesz użyć filtrów ścieżek, szablonów potoków i warunków. Jednak należy pozostawić pełną sekwencję wdrażania bez zmian dla innych środowisk.

Płaszczyzna sterowania i płaszczyzna danych

Wiele zasobów platformy Azure zapewnia dwa różne płaszczyzny dostępu. Płaszczyzna sterowania wdraża i konfiguruje zasób. Płaszczyzna danych umożliwia dostęp do funkcji zasobu.

Podczas tworzenia i wdrażania plików Bicep można korzystać z płaszczyzny sterowania. Na platformie Azure płaszczyzna sterowania to Azure Resource Manager. Usługa Resource Manager służy do definiowania konfiguracji poszczególnych zasobów.

Jednak potok często musi wykonywać więcej niż tylko interakcję z płaszczyzną sterowania. Na przykład może być konieczne wykonywanie innych zadań:

  • Przekaż obiekt blob do konta magazynu.
  • Modyfikowanie schematu bazy danych.
  • Wywołanie interfejsu API do usługi innej firmy.
  • Wyzwalanie aktualizacji modelu uczenia maszynowego.
  • Wdróż witrynę internetową w aplikacji usługi aplikacja systemu Azure Service.
  • Wdrażanie oprogramowania na maszynie wirtualnej.
  • Zarejestruj wpis serwera nazw domen (DNS) u dostawcy innej firmy.

W przypadku uwzględnienia kompleksowego potoku zwykle trzeba wdrożyć zasoby platformy Azure, a następnie wykonać serię operacji na płaszczyznach danych tych zasobów. Czasami te operacje są nazywane ostatnią milą wdrożenia, ponieważ wykonujesz większość wdrożenia przy użyciu płaszczyzny sterowania i pozostaje tylko niewielka ilość konfiguracji.

Uwaga

Niektóre zasoby nie mają wyraźnego podziału między płaszczyzną sterowania a płaszczyzną danych. Należą do nich usługi Azure Data Factory i Azure API Management. Obie usługi obsługują w pełni zautomatyzowane wdrożenia przy użyciu rozwiązania Bicep, ale wymagają one szczególnych zagadnień. Linki do dodatkowych informacji można znaleźć na stronie Podsumowanie na końcu modułu.

Jak wykonywać operacje płaszczyzny danych

Podczas tworzenia potoku wdrażania, który współdziała z płaszczyzną danych zasobów, można użyć dowolnego z trzech typowych podejść:

  • Skrypty wdrażania usługi Resource Manager.
  • Skrypty potoku.
  • Zadania potoku.

Skrypty wdrażania usługi Resource Manager są definiowane w pliku Bicep. Uruchamiają skrypty powłoki Bash lub programu PowerShell i mogą wchodzić w interakcje z interfejsem wiersza polecenia platformy Azure lub poleceniami cmdlet programu Azure PowerShell. Tworzysz tożsamość zarządzaną, aby skrypt wdrażania mógł uwierzytelniać się na platformie Azure, a platforma Azure automatycznie aprowizuje inne zasoby, których potrzebuje do uruchomienia skryptu wdrażania.

Skrypty wdrażania są dobre, gdy trzeba uruchomić podstawowy skrypt w procesie wdrażania. Nie zapewniają one jednak łatwego dostępu do innych elementów z potoku.

Możesz również uruchomić własną logikę z poziomu potoku wdrażania. Usługa Azure Pipelines udostępnia bogaty ekosystem zadań dla typowych rzeczy, które należy wykonać. Jeśli nie możesz znaleźć zadania spełniającego Twoje potrzeby, możesz użyć skryptu , aby uruchomić własny kod powłoki Bash lub programu PowerShell. Zadania potoku i skrypty są uruchamiane z agenta potoku. Często trzeba uwierzytelnić zadanie lub skrypt na płaszczyźnie danych używanej usługi, a sposób uwierzytelniania zależy od usługi.

Zadania i skrypty potoku zapewniają elastyczność i kontrolę. Umożliwiają one również dostęp do artefaktów potoku, które wkrótce poznasz. W tym module koncentrujemy się na skryptach i zadaniach potoku. Link do dodatkowych informacji na temat skryptów wdrażania usługi Resource Manager na stronie Podsumowanie na końcu modułu.

Dane wyjściowe

Potok zwykle tworzy i konfiguruje zasoby platformy Azure przez wdrożenie pliku Bicep. Kolejne części potoku następnie wchodzą w interakcję z płaszczyzną danych tych zasobów. Aby móc korzystać z zasobów, zadania potoku i kroki wymagają informacji o utworzonym zasobie platformy Azure.

Załóżmy na przykład, że masz plik Bicep, który wdraża konto magazynu. Chcesz, aby potok wdrożyć konto magazynu, a następnie przekazać niektóre obiekty blob do kontenera obiektów blob na koncie magazynu. Zadanie potoku, które przekazuje obiekty blob, musi znać nazwę konta magazynu, z którą ma nawiązać połączenie, oraz nazwę kontenera obiektów blob w celu przekazania pliku do.

Dobrym rozwiązaniem jest podjęcie decyzji o nazwach zasobów platformy Azure przez plik Bicep. Może używać parametrów, zmiennych lub wyrażeń, aby utworzyć nazwy konta magazynu i kontenera obiektów blob. Plik Bicep może następnie uwidocznić dane wyjściowe, które zawierają nazwę każdego zasobu. W kolejnych krokach potoku można odczytać wartość danych wyjściowych. W ten sposób definicja potoku nie musi kodować żadnych nazw ani innych informacji, które mogą ulec zmianie między środowiskami. Ponadto definicja nie musi być oparta na regułach zdefiniowanych w pliku Bicep.

Za pomocą usługi Azure Pipelines można propagować wartości danych wyjściowych przy użyciu zmiennych potoku. Wartość zmiennej potoku można ustawić w skrypsie potoku. Używasz specjalnie sformatowanych danych wyjściowych dziennika, które usługa Azure Pipelines rozumie, jak interpretować, jak pokazano poniżej:

stages:
- stage: Stage1
  jobs:
  - job: Job1
    steps:
      # Set the variable's value.
      - script: |
          echo "##vso[task.setvariable variable=myVariableName;isOutput=true]VariableValue"
        name: Step1

      # Read the variable's value.
      - script:
          echo $(myVariableName)

Podczas tworzenia zmiennej w jednym zadaniu, ale chcesz uzyskać do niej dostęp w innym zadaniu na tym samym etapie, musisz ją zamapować.

stages:
- stage: Stage2
  jobs:
  - job: Job2
    steps:
      # Set the variable's value.
      - script: |
          echo "##vso[task.setvariable variable=myVariableName;isOutput=true]VariableValue"
        name: Step1

  - job: Job3
    dependsOn: Job2
    variables: # Map the variable to this job.
      myVariableName: $[ dependencies.Job2.outputs['Step1.myVariableName'] ]
    steps:
      # Read the variable's value.
      - script: |
          echo $(myVariableName)

Aby uzyskać dostęp do zmiennej między etapami potoku, musisz również zamapować zmienną, ale używasz innej składni:

stages:
- stage: Stage2
  jobs:
  - job: Job2
    steps:
      # Set the variable's value.
      - script: |
          echo "##vso[task.setvariable variable=myVariableName;isOutput=true]VariableValue"
        name: Step1

  - job: Job3
    dependsOn: Job2
    variables: # Map the variable to this job.
      myVariableName: $[ dependencies.Job2.outputs['Step1.myVariableName'] ]
    steps:
      # Read the variable's value.
      - script: |
          echo $(myVariableName)

- stage: Stage3
  dependsOn: Stage2
  jobs:
  - job: Job4
    variables: # Map the variable to this stage.
      myVariableName: $[ stageDependencies.Stage2.Job2.outputs['Step1.myVariableName'] ]
    steps:
      # Read the variable's value.
    - script: |
        echo $(myVariableName)

Za pomocą danych wyjściowych Bicep i zmiennych potoku można utworzyć potok wieloestowy, który wdraża kod Bicep, a następnie wykonuje różne akcje na zasobach w ramach wdrożenia.