GitHub Actions na platformie Azure

GitHub Actions to wbudowana w GitHub platforma CI/CD i automatyzacji. Przepływy pracy definiuje się w plikach YAML przechowywanych w katalogu .github/workflows/ repozytorium; są one uruchamiane przez zdarzenia GitHub — wypchnięcia zmian, żądania ściągnięcia, wydania i inne. GitHub Actions jest ściśle zintegrowany z ekosystemem GitHub (issues, PR-y, pakiety i skanowanie zabezpieczeń) oraz udostępnia bogaty marketplace akcji społeczności do zadań takich jak kompilowanie, testowanie i wdrażanie na platformę Azure.

Plik przepływu pracy GitHub Actions ma trzy sekcje najwyższego poziomu. on definiuje zdarzenia wyzwalające. env ustawia globalne zmienne środowiskowe. jobs definiuje jedno lub więcej zadań, z których każde jest uruchamiane na obiekcie runner (hostowanym przez GitHub lub własnym). Każde zadanie ma elementy steps — albo run (skrypt powłoki), albo uses (gotowa akcja). Domyślnie zadania są uruchamiane równolegle; elementu needs należy użyć do utworzenia zależności sekwencyjnych.

Zalecanym sposobem uwierzytelniania GitHub Actions na platformie Azure jest OpenID Connect (OIDC) — mechanizm ten wydaje krótkotrwałe tokeny bez przechowywania w GitHub długotrwałych wpisów tajnych. Należy skonfigurować poświadczenie tożsamości federacyjnej w rejestracji aplikacji Azure lub tożsamości zarządzanej, nadając jej zaufanie do repozytorium GitHub i jego gałęzi. Proszę użyć akcji azure/login@v2, aby wymienić token OIDC GitHub na token dostępu platformy Azure — wpisy tajne klienta w GitHub Secrets nie są wymagane.

Akcja azure/webapps-deploy@v3 wdraża kod lub obraz kontenera do usługi Azure App Service. Obsługuje wdrażanie do slotu, wdrażanie na podstawie pakietu oraz wdrażanie obrazu platformy Docker. Należy połączyć ją z akcją azure/login@v2 w celu uwierzytelniania. Można wskazać slot staging, uruchomić testy dymne, a następnie zamienić sloty za pomocą akcji azure/CLI@v2, uruchamiającej polecenie zamiany slotów — w ten sposób cały wzorzec wdrażania blue-green z Azure Pipelines można odtworzyć w GitHub Actions.

Wdrażanie do AKS z poziomu GitHub Actions odbywa się za pomocą akcji azure/k8s-deploy@v5. Akcja ta używa polecenia kubectl apply do wdrażania manifestów, wykonuje podstawianie obrazu (zastępuje znacznik obrazu znacznikiem bieżącej kompilacji) oraz monitoruje kondycję wdrożenia. Akcja azure/aks-set-context@v4 konfiguruje dane uwierzytelniające kubectl, pobierając kubeconfig klastra przy użyciu uwierzytelnionej sesji Azure.

Wrażliwe wartości należy przechowywać w GitHub Secrets — zaszyfrowanych wartościach dostępnych w przepływach pracy jako ${{ secrets.SECRET_NAME }}. Konfigurację niewrażliwą należy umieszczać w GitHub Variables — dostępną jako ${{ vars.VARIABLE_NAME }}. Oba typy można ograniczyć do repozytorium, środowiska lub organizacji. Należy używać środowisk w GitHub Actions, aby dodawać reguły ochrony (wymaganych recenzentów i gałęzi wdrażania), podobnie jak w przypadku środowisk Azure DevOps.

Środowiska GitHub Actions (konfigurowane w obszarze Ustawienia repozytorium → Environments) dodają bramki wdrażania podobne do środowisk Azure DevOps. Można wymagać wymaganych recenzentów, którzy muszą zatwierdzić zadanie przed jego uruchomieniem dla danego środowiska, ograniczyć wdrożenia do określonych gałęzi (tylko main może wdrażać do środowiska Production) oraz dodać czasy oczekiwania opóźniające wdrożenia. Zadania kierowane do chronionego środowiska są wstrzymywane do momentu spełnienia wszystkich reguł ochrony.

Proszę unikać powielania logiki CI/CD w repozytoriach, korzystając z dwóch funkcji GitHub Actions. Przepływy pracy wielokrotnego użytku pozwalają zdefiniować przepływ pracy w jednym repozytorium i wywoływać go z przepływów pracy w innych repozytoriach za pomocą uses: myorg/shared-workflows/.github/workflows/deploy.yml@main. Akcje złożone łączą wiele kroków w jedną akcję przechowywaną w repozytorium i możliwą do ponownego użycia za pomocą uses: myorg/my-actions/deploy@v1. Obie funkcje wspierają zasadę DRY w potokach CI/CD organizacji.

Proszę wybrać GitHub Actions, gdy kod jest hostowany w GitHub, zespół preferuje interfejs GitHub, potrzebna jest ścisła integracja ze sprawdzaniem PR-ów i skanowaniem kodu GitHub lub tworzone są projekty open source (z dużą liczbą bezpłatnych minut). Proszę wybrać Azure Pipelines, gdy potrzebna jest integracja z Azure Boards, zaawansowane testowanie z Azure Test Plans, zarządzanie źródłami Azure Artifacts, kod znajduje się w Azure Repos albo wymagane jest złożone, wieloetapowe zarządzanie wydaniami z bramkami obejmującymi wiele środowisk. Oba rozwiązania równie dobrze obsługują wdrażanie na platformę Azure.

Marketplace GitHub Actions zawiera tysiące akcji społeczności i akcji oficjalnych do typowych zadań. Firma Microsoft publikuje oficjalne akcje Azure: azure/login, azure/webapps-deploy, azure/aks-set-context, azure/k8s-deploy, azure/CLI, azure/arm-deploy i wiele innych. Zawsze należy przypinać akcje do określonego znacznika wersji (np. @v3) lub skrótu SHA zatwierdzenia, aby zapobiec atakom na łańcuch dostaw, w których przejęta akcja zostaje zaktualizowana złośliwym kodem.

Runnery hostowane przez GitHub mają dostęp wyłącznie do publicznego Internetu — nie mogą uzyskać dostępu do prywatnych zasobów Azure (baz danych SQL i wewnętrznych interfejsów API) bez publicznego udostępniania tych zasobów. W przypadku wdrożeń do zasobów prywatnych należy używać własnych runnerów na maszynach wirtualnych Azure znajdujących się w sieci VNet. Runnery rejestruje się przez pobranie agenta runnera GitHub Actions, skonfigurowanie go za pomocą adresu URL repozytorium i tokenu rejestracji oraz uruchomienie go jako usługi. Własne runnery można skalować za pomocą Azure Container Apps, tworząc elastyczne pule runnerów.

W tej lekcji nauczyli się Państwo, że przepływy pracy GitHub Actions to pliki YAML w katalogu .github/workflows/, uruchamiane przez zdarzenia GitHub i wykonywane na runnerach, federacyjne poświadczenia OIDC umożliwiają uwierzytelnianie na platformie Azure z poziomu GitHub Actions bez wpisów tajnych, a środowiska GitHub z regułami ochrony dodają bramki zatwierdzania do wdrożeń produkcyjnych. To kończy kurs Azure DevOps — w następnej części omówimy Azure Monitor i Log Analytics.