Konfigurowanie aplikacji i maszyn wirtualnych

Ukończone

Często kompilowanie aplikacji i innego kodu niestandardowego dla rozwiązania platformy Azure. Aplikacje niestandardowe mogą obejmować witryny internetowe, interfejsy API i aplikacje w tle, które działają bez żadnej interakcji z człowiekiem. W tej lekcji dowiesz się, jak zaprojektować potok w celu skompilowania i wdrożenia aplikacji wraz z jej infrastrukturą.

Kompilacja aplikacji

Przed ich zastosowaniem należy skompilować lub skompilować wiele typów aplikacji. Proces kompilacji pobiera kod źródłowy aplikacji, wykonuje na niej sekwencję działań, a następnie tworzy zestaw plików, które można wdrożyć.

Proces kompilacji kompiluje kod źródłowy do plików binarnych lub plików wykonywalnych, ale zwykle obejmuje również inne działania:

  • Kompresowanie plików obrazów, które są obsługiwane użytkownikom witryny internetowej.
  • Tworzenie lintingu kodu w celu sprawdzenia, czy jest ono zgodne z dobrymi rozwiązaniami w zakresie kodowania.
  • Uruchamianie testów jednostkowych , które weryfikują zachowanie poszczególnych elementów aplikacji.

Oprócz tych kroków można również wykonać kroki, takie jak cyfrowe podpisywanie plików, aby upewnić się, że nie można ich modyfikować.

Niezależnie od serii kroków, dane wyjściowe procesu kompilacji są artefaktem, który można wdrożyć. Artefakt jest zwykle zapisywany w systemie plików agenta potoku. Później etapy potoku muszą współpracować z artefaktem, aby wdrożyć go za pośrednictwem środowisk i przetestować go w miarę postępu za pośrednictwem bram jakości zdefiniowanych w definicji potoku.

Uwaga

Być może znasz terminy ciągła integracja i ciągłe wdrażanie lub ciągła integracja i ciągłe wdrażanie. Proces kompilacji znajduje się w ramach ciągłej integracji części potoku.

Artefakty potoku

Artefakty generowane w potoku nie są przechowywane w repozytorium Git. Pochodzą one z kodu źródłowego, ale nie są same w kodzie, dlatego nie należą do repozytorium kontroli źródła. Są one tworzone w systemie plików agenta potoku. Nowy agent jest tworzony dla każdego zadania potoku, więc potrzebny jest sposób udostępniania plików między zadaniami i agentami.

Artefakty potoku umożliwiają przechowywanie plików w usłudze Azure Pipelines i są one skojarzone z konkretnym uruchomieniem potoku. Za pomocą wbudowanego PublishBuildArtifacts zadania potoku należy poinstruować usługę Azure Pipelines o opublikowaniu pliku lub folderu z systemu plików agenta jako artefaktu potoku:

- task: PublishBuildArtifacts@1
  displayName: Publish folder as a pipeline artifact
  inputs:
    artifactName: my-artifact-name
    pathToPublish: '$(Build.ArtifactStagingDirectory)/my-folder'

Właściwość pathToPublish to lokalizacja zawierająca skompilowany kod lub pliki wyjściowe w systemie plików agenta potoku. Zawartość w tej lokalizacji jest publikowana w artefaktie. Można określić pojedynczy plik lub folder.

Każdy artefakt ma nazwę, którą określasz przy użyciu artifactName właściwości zadania. Nazwa artefaktu służy do odwoływania się do niej w dalszej części potoku. Kolejne zadania potoku i etapy mogą pobierać artefakt, aby mogły z nim pracować, na przykład wdrożyć witrynę internetową na serwerze, który go hostuje:

Diagram that shows pipeline stages to build and deploy that refer to an artifact named Website.

W przypadku korzystania z zadań wdrażania artefakty potoku są domyślnie automatycznie pobierane. Jeśli używasz zwykłych zadań, użyj DownloadBuildArtifacts zadania , aby pobrać artefakt potoku:

- task: DownloadBuildArtifacts@0
  inputs:
    buildType: current
    downloadType: single
    artifactName: my-artifact-name
    downloadPath: '$(System.ArtifactsDirectory)'

Wdrażanie aplikacji

Proces kompilacji aplikacji generuje i publikuje wdrażalny artefakt. Później etapy potoku wdrażają artefakt. Sposób wdrażania aplikacji zależy od usługi używanej do jej hostowania.

Wdrażanie w usłudze Azure App Service

Twoja firma z aplikacjami do hostowania witryny internetowej korzysta z usługi aplikacja systemu Azure Service. Aplikację usługi App Service można utworzyć i skonfigurować przy użyciu aplikacji Bicep. Jednak jeśli przychodzi czas na wdrożenie aplikacji, masz kilka opcji, aby skompilować aplikację w infrastrukturze hostingu. Te opcje są zarządzane w ramach płaszczyzny danych usługi App Service.

Najczęstszym podejściem jest użycie AzureRmWebAppDeployment zadania usługi Azure Pipelines:

- task: AzureRmWebAppDeployment@4
  inputs:
    azureSubscription: MyServiceConnection
    ResourceGroupName: MyResourceGroup
    WebAppName: my-app-service
    Package: '$(Pipeline.Workspace)/my-artifact-name/website.zip'

Aby wdrożyć aplikację w usłudze App Service, musisz podać kilka informacji. Te informacje obejmują grupę zasobów i nazwę zasobu aplikacji usługi App Service, która jest określana przy użyciu elementów ResourceGroupName wejściowych i WebAppName . Jak pokazano w poprzedniej lekcji, należy dodać dane wyjściowe do pliku Bicep i użyć zmiennej potoku do propagowania nazwy aplikacji za pośrednictwem potoku. Należy również określić plik .zip z aplikacją do wdrożenia przy użyciu Package danych wejściowych, które są zwykle ścieżką do artefaktu potoku.

Usługa App Service ma własny system uwierzytelniania płaszczyzny danych używany do wdrożeń. Zadanie AzureRmWebAppDeployment automatycznie obsługuje proces uwierzytelniania:

Diagram that shows the credential exchange process.

Zadanie AzureRmWebAppDeployment używa jednostki usługi skojarzonej z połączeniem usługi w celu automatycznego tworzenia i pobierania niezbędnych poświadczeń do wdrożenia . Następnie używa poświadczeń wdrożenia podczas komunikowania się z interfejsem API płaszczyzny danych usługi App Service.

Usługa App Service udostępnia również kilka innych funkcji związanych z wdrażaniem, w tym miejsc wdrożenia. Miejsca ułatwiają bezpieczne wdrażanie nowych wersji aplikacji bez przestojów. Ułatwiają one również przygotowanie i rozgrzewkę nowej wersji aplikacji przed wysłaniem do niej ruchu produkcyjnego. Nie używamy miejsc w tym module, ale udostępniamy link do dodatkowych informacji o nich na stronie Podsumowanie na końcu modułu.

Wdrażanie aplikacji w innych usługach platformy Azure

Platforma Azure oferuje wiele innych opcji hostowania aplikacji, z których każda ma własne podejście do wdrażania.

Usługa Azure Functions jest oparta na usłudze App Service i używa procesu wdrażania podobnego do opisanego wcześniej.

W przypadku wdrożenia na maszynie wirtualnej zwykle musisz nawiązać połączenie z wystąpieniem maszyny wirtualnej, aby zainstalować aplikację. Do organizowania wdrożenia na maszynach wirtualnych często trzeba używać wyspecjalizowanych narzędzi, takich jak Chef, Puppet lub Ansible.

Jeśli używasz platformy Kubernetes lub usługi Azure Kubernetes Service (AKS), użyj nieco innego podejścia do kompilowania i wdrażania rozwiązania. Po utworzeniu aplikacji potok tworzy obraz kontenera i publikuje go w rejestrze kontenerów, z którego następnie odczytuje klaster Kubernetes. Ponieważ rejestr kontenerów przechowuje skompilowana aplikację, zazwyczaj nie używasz artefaktu potoku.

W tym module koncentrujemy się na usłudze aplikacja systemu Azure, aby zilustrować związane z nim pojęcia dotyczące potoku. Na stronie Podsumowanie na końcu modułu udostępniamy linki do dodatkowych informacji na temat wdrażania w innych usługach hostingowych.

Testowanie aplikacji w potoku

W poprzednim module przedstawiono wartość i znaczenie uruchamiania testów automatycznych z potoku. Podczas wdrażania aplikacji dobrym rozwiązaniem jest uruchomienie niektórych testów wywołujących kod aplikacji. Takie testy zmniejszają ryzyko, że błąd aplikacji lub wdrożenia może spowodować przestój. W bardziej zaawansowanych scenariuszach można nawet wykonać zestaw przypadków testowych dla aplikacji, takich jak wywoływanie interfejsów API lub przesyłanie i monitorowanie transakcji syntetycznej.

Wiele aplikacji implementuje punkty końcowe sprawdzania kondycji. Gdy punkt końcowy kontroli kondycji odbiera żądanie, wykonuje serię kontroli w witrynie internetowej, takich jak zapewnienie, że bazy danych i usługi sieciowe są dostępne ze środowiska aplikacji. Odpowiedź zwrócona przez witrynę wskazuje, czy aplikacja jest w dobrej kondycji. Deweloperzy mogą pisać i dostosowywać własne kontrole kondycji zgodnie z wymaganiami aplikacji. Jeśli aplikacja ma punkt końcowy kontroli kondycji, często warto monitorować ją z potoku po zakończeniu etapu wdrażania.

Potok wdrażania

W następnym ćwiczeniu zaktualizujesz potok wdrażania, aby dodać nowe zadania w celu skompilowania aplikacji witryny internetowej i wdrożenia go w każdym środowisku:

Diagram that shows the revised pipeline, including a new build stage and an application deployment step.