Zrozumienie wdrożeń typu end-to-end

Ukończone

Rurociągi 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 rurociągó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 linii przetwarzania, z których każda jest własnością zespołu odpowiedzialnego za dany obszar. Możesz na przykład utworzyć jeden potok do wdrożenia kodu Bicep, który odpowiedzialny jest za wdrożenie zasobów platformy Azure dla Twojej witryny internetowej, oraz inny potok do wdrożenia aplikacji 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 Azure App 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 wysyłanie danych, takich jak nazwy zasobów platformy Azure utworzonych przez Twój potok infrastruktury, między różnymi ciągami może być skomplikowane.

Zamiast tego często lepiej jest utworzyć pojedynczy pipeline, który wdraża wszystkie elementy niezbędne dla rozwiązania, nawet jeśli różne osoby lub 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 przepływ wykonuje wszystkie kroki niezbędne do budowania i wdrożenia rozwiązania. Pojedynczy potok danych zmniejsza prawdopodobieństwo rozsynchronizacji.

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 Twojej infrastruktury wraz z Twoim kodem aplikacji sprawia, że potok działa wolniej i hamuje postęp.

Jeśli jesteś w tej sytuacji, możesz rozważyć wyłączenie wdrażania infrastruktury dla środowiska programistycznego. 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 dwie różne płaszczyzny dla 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 magazynowego.
• Modyfikowanie schematu bazy danych.
• Wykonaj wywołanie interfejsu API do usługi zewnętrznej.
• Wyzwalanie aktualizacji modelu uczenia maszynowego.
• Wdrażanie witryny internetowej w aplikacji usługi Azure App Service.
• Wdrażanie oprogramowania na maszynie wirtualnej.
• Zarejestruj wpis DNS (serwer nazw domen) u zewnętrznego dostawcy.

Gdy rozważasz pełny potok, zwykle trzeba wdrożyć zasoby 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 kontrolnej i pozostaje tylko niewielka ilość konfiguracji.

Notatka

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żesz wykorzystać jedno z trzech typowych podejść.

• Skrypty wdrażania usługi Resource Manager.
• Skrypty potokowe.
• Zadania pipeline'u.

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ę w platformie Azure, a platforma Azure automatycznie udostępnia i zarządza innymi zasobami, 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 przepływu danych.

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.

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

Wyjścia

Potok zadań zwykle tworzy i konfiguruje zasoby Azure, wdrażając plik Bicep. Kolejne części strumienia 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 magazynowe. Chcesz, aby pipeline wdrożył konto magazynowe, a następnie przesłał niektóre obiekty blob do kontenera na obiekty blobów w tym koncie magazynowym. Zadanie w potoku, które przesyła obiekty blob, musi znać nazwę konta magazynowego, do którego ma się połączyć, oraz nazwę kontenera obiektów blob, do którego ma przesłać plik.

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 magazynowego 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 pipeline'u nie musi twardo zakodować ż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 skrypcie 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 przypisać ją.

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 przetwarzania, należy również odwzorować zmienną, ale należy użyć 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 wielostopniowy, który wdraża kod Bicep, a następnie wykonuje różne akcje na zasobach w ramach wdrożenia.