Wdrażanie aplikacji na platformie Azure przy użyciu przepływów pracy funkcji GitHub Actions utworzonych przez program Visual Studio

Począwszy od programu Visual Studio 2019 w wersji 16.11, można tworzyć nowe przepływy pracy funkcji GitHub Actions dla projektów platformy .NET hostowanych na GitHub.com.

Warunki wstępne

• Musisz zalogować się do konta usługi GitHub w programie Visual Studio.
• Konto platformy Azure. Jeśli nie masz konta platformy Azure, aktywuj korzyści platformy Azure dla subskrybentów programu Visual Studio albo zarejestruj się, aby otrzymać bezpłatną wersję próbną.

Wdrażanie pojedynczego projektu na platformie Azure przy użyciu funkcji GitHub Actions

W Eksploratorze rozwiązań kliknij prawym przyciskiem myszy projekt hostowany na GitHub.com i wybierz Publikuj.

Na następnym ekranie wybierz pozycję Azure, a następnie wybierz pozycję Dalej.

W zależności od typu projektu uzyskasz inną listę usług platformy Azure do wyboru. Wybierz jedną z obsługiwanych usług platformy Azure pasujących do Twoich potrzeb.

W ostatnim kroku kreatora wybierz CI/CD przy użyciu GitHub Actions (generuje plik yml), a następnie wybierz Zakończ.

Visual Studio generuje nowy przepływ pracy dla GitHub Actions i prosi o jego zatwierdzenie oraz przesłanie na GitHub.com.

Jeśli wykonasz ten krok przy użyciu wbudowanego narzędzia Git , program Visual Studio wykryje wykonywanie przepływu pracy.

Przepływ pracy

Ustawianie tajnych danych GitHub

Aby wygenerowany przepływ pracy został pomyślnie wdrożony na platformie Azure, może wymagać dostępu do profilu publikowania .

Pomyślne wdrożenie może również wymagać dostępu do jednostki usługi .

We wszystkich przypadkach program Visual Studio próbuje ustawić tajemnicę GitHub za ciebie z poprawną wartością. Jeśli to się nie powiedzie, poinformuje Cię o tym i da ci możliwość ponownego wypróbowania.

brak wpisu tajnego usługi GitHub

Jeśli nie można ponownie ustawić sekretnego klucza, program Visual Studio daje możliwość ręcznego uzyskania dostępu do niego, aby można było ukończyć proces za pośrednictwem strony repozytorium na GitHubie.

Wdrażanie wielu projektów w usłudze Azure Container Apps przy użyciu funkcji GitHub Actions

Te kroki są odpowiednie, jeśli masz więcej niż jeden projekt korzystający z kontenerów platformy Docker i chcesz wdrożyć je jako aplikację wieloprojektową. Możesz wdrożyć aplikacje wieloprojektowe, takie jak te implementujące mikrousługi, do Azure Container Apps lub Azure Kubernetes Service (AKS). W tym artykule opisano usługę Azure Container Apps.

1. Kliknij prawym przyciskiem myszy węzeł GitHub Actions w Eksploratorze rozwiązań, a następnie wybierz pozycję Nowy przepływ pracy. Pojawi się kreator przepływu pracy GitHub Actions.

   

2. Na ekranie docelowym przepływu pracy w GitHub Actions wybierz opcję Azure.

3. Dla określonego celu wybierz opcję Azure Container Apps. Kreator przechodzi do ekranu aplikacji kontenera.

   

4. Wybierz istniejącą aplikację kontenerową platformy Azure albo Utwórz nową.

   

   Gdy tworzysz nowy, widzisz ten ekran. Podczas testowania lub uczenia najlepiej jest utworzyć nową grupę zasobów, aby ułatwić późniejsze usunięcie wszystkich elementów. Środowisko usługi Container Apps to bezpieczna granica wokół grup aplikacji kontenerowych, które współużytkują tę samą sieć wirtualną i zapisują dzienniki do tego samego miejsca docelowego rejestrowania. Zobacz środowiska Azure Container Apps . Jeśli nie wiesz, co to jest, lub jeśli nie stworzyłeś jednego wcześniej, utwórz nowy dla tego przypadku.

   

   Po utworzeniu nowe wystąpienie usługi Azure Container Apps jest wyświetlane.

   

5. Wybierz Dalej, aby przejść do ekranu rejestru. Wybierz istniejącą usługę Azure Container Registry lub utwórz nową.

   

   Jeśli zdecydujesz się utworzyć nowy, zostanie wyświetlony ten ekran. Podaj grupę zasobów, jednostkę SKU i wybierz ten sam region, jeśli to możliwe, tak jak wcześniej. Aby uzyskać informacje o SKU dla Azure Container Registry, zobacz warstwy cenowe usługi Azure Container Registry.

   

   Po utworzeniu nowy rejestr zostanie wyświetlony na ekranie.

   

6. Zostaną wyświetlone projekty możliwe do wdrożenia w rozwiązaniu; wybierz projekty, które chcesz wdrożyć razem w tym samym wystąpieniu usługi Azure Container Apps.

   

7. Wybierz pozycję Zakończ. Możesz wyświetlić polecenia wydawane w celu utworzenia zasobów na platformie Azure i skonfigurowania uwierzytelniania. Jeśli coś nie powiedzie się, zwróć uwagę na użyty wiersz polecenia, ponieważ możesz spróbować go ponownie z poziomu interfejsu wiersza polecenia. Nie martw się zbytnio, jeśli na tym etapie wystąpi błąd autoryzacji. Możesz również skonfigurować uwierzytelnianie później w programie Visual Studio.

8. Po zakończeniu zostanie wyświetlony ekran podsumowania. Na ekranie podsumowania wyświetlane są poświadczenia, które są zgodne z wpisami tworzonymi przez program Visual Studio w repozytorium GitHub w sekcji tajnych GitHub Actions. Sprawdź, czy nie ma żadnych żółtych znaków ostrzegawczych. Jeśli którykolwiek z kroków uwierzytelniania nie powiódł się podczas procesu tworzenia, możesz rozwiązać ten problem, klikając link za pomocą znaku ostrzegawczego i wykonując kilka kroków.

9. Otwórz plik przepływu pracy, aby sprawdzić, co wygenerowano w programie Visual Studio. Chociaż program Visual Studio najlepiej generuje przepływ pracy w danej sytuacji, każda aplikacja i repozytorium jest unikatowa, dlatego często trzeba ręcznie edytować plik YML przepływu pracy wygenerowany przez program Visual Studio, zanim zostanie uruchomiony pomyślnie. Aby go otworzyć, rozwiń węzeł GitHub Actions w Eksploratorze rozwiązań, kliknij prawym przyciskiem myszy właśnie utworzony przepływ pracy i wybierz pozycję Edytuj.

Poniżej przedstawiono przykład pliku przepływu pracy utworzonego przez program Visual Studio dla rozwiązania z dwoma projektami, które można wdrożyć, WebAPI i WebFrontEnd.

on:
push:
  branches:
  - main
env:
CONTAINER_REGISTRY_LOGIN_SERVER: registry20230810121555.azurecr.io
CONTAINER_APP_NAME: containerapp20230810121017
CONTAINER_APP_RESOURCE_GROUP_NAME: webfrontend-container-app-1234
CONTAINER_APP_CONTAINER_NAME: containerapp
jobs:
WebApi_buildImageAndDeploy:
  runs-on: ubuntu-latest
  steps:
  - name: Checkout source code
    uses: actions/checkout@v3
  - name: Set up Docker Buildx
    uses: docker/setup-buildx-action@v2
  - name: Login to Docker registry
    uses: docker/login-action@v2
    with:
      registry: ${{ env.CONTAINER_REGISTRY_LOGIN_SERVER }}
      username: ${{ secrets.registry20230810121555_USERNAME_6891 }}
      password: ${{ secrets.registry20230810121555_PASSWORD_6891 }}
  - name: Build and push Docker image to Azure container registry
    uses: docker/build-push-action@v4
    with:
      push: true
      tags: ${{ env.CONTAINER_REGISTRY_LOGIN_SERVER }}/webapi:${{ github.sha }}
      file: WebApi\Dockerfile
  - name: Azure login
    uses: azure/login@v1
    with:
      creds: ${{ secrets.containerapp20230810121017_SPN }}
  - name: Deploy to Azure container app
    uses: azure/CLI@v1
    with:
      inlineScript: >-
        az config set extension.use_dynamic_install=yes_without_prompt
        az containerapp registry set --name ${{ env.CONTAINER_APP_NAME }} --resource-group ${{ env.CONTAINER_APP_RESOURCE_GROUP_NAME }} --server ${{ env.CONTAINER_REGISTRY_LOGIN_SERVER }} --username ${{ secrets.registry20230810121555_USERNAME_2047 }} --password ${{ secrets.registry20230810121555_PASSWORD_2047 }}
        az containerapp update --name ${{ env.CONTAINER_APP_NAME }} --container-name ${{ env.CONTAINER_APP_CONTAINER_NAME }} --resource-group ${{ env.CONTAINER_APP_RESOURCE_GROUP_NAME }} --image ${{ env.CONTAINER_REGISTRY_LOGIN_SERVER }}/webapi:${{ github.sha }}
  - name: Azure logout
    run: az logout
WebFrontEnd_buildImageAndDeploy:
  runs-on: ubuntu-latest
  needs: WebApi_buildImageAndDeploy
  steps:
  - name: Checkout source code
    uses: actions/checkout@v3
  - name: Set up Docker Buildx
    uses: docker/setup-buildx-action@v2
  - name: Login to Docker registry
    uses: docker/login-action@v2
    with:
      registry: ${{ env.CONTAINER_REGISTRY_LOGIN_SERVER }}
      username: ${{ secrets.registry20230810121555_USERNAME_2047 }}
      password: ${{ secrets.registry20230810121555_PASSWORD_2047 }}
  - name: Build and push Docker image to Azure container registry
    uses: docker/build-push-action@v4
    with:
      push: true
      tags: ${{ env.CONTAINER_REGISTRY_LOGIN_SERVER }}/webfrontend:${{ github.sha }}
      file: WebFrontEnd\Dockerfile
  - name: Azure login
    uses: azure/login@v1
    with:
      creds: ${{ secrets.containerapp20230810121017_SPN }}
  - name: Deploy to Azure container app
    uses: azure/CLI@v1
    with:
      inlineScript: >-
        az config set extension.use_dynamic_install=yes_without_prompt
        az containerapp registry set --name ${{ env.CONTAINER_APP_NAME }} --resource-group ${{ env.CONTAINER_APP_RESOURCE_GROUP_NAME }} --server ${{ env.CONTAINER_REGISTRY_LOGIN_SERVER }} --username ${{ secrets.registry20230810121555_USERNAME_2047 }} --password ${{ secrets.registry20230810121555_PASSWORD_2047 }}
        az containerapp update --name ${{ env.CONTAINER_APP_NAME }} --container-name ${{ env.CONTAINER_APP_CONTAINER_NAME }} --resource-group ${{ env.CONTAINER_APP_RESOURCE_GROUP_NAME }} --image ${{ env.CONTAINER_REGISTRY_LOGIN_SERVER }}/webfrontend:${{ github.sha }}
  - name: Azure logout
    run: az logout

Główną funkcją przepływu pracy jest zalogowanie się do usług platformy Azure przy użyciu odpowiedniego uwierzytelniania i uruchomienie poleceń w celu skompilowania i wdrożenia aplikacji.

Edytowanie i testowanie przepływu pracy

Powyższa procedura generuje plik YML przepływu pracy, ale zwykle należy go przejrzeć i dostosować, zanim będzie można go użyć do wdrożenia. Może być konieczne zapoznanie się ze wskazówkami usługi GitHub dotyczącymi pisania akcji przepływu pracy; zobacz Informacje o akcjach niestandardowych. Plik przepływu pracy zawiera wiele konfigurowalnych elementów, takich jak ustawienia zmiennych środowiskowych i nazwy tajnych informacji. Możesz zobaczyć odniesienia do lokalizacji plików Dockerfiles, nazwy aplikacji kontenera Azure, gałęzi w repozytorium, której będziesz używać do wyzwalania przebiegów przepływu pracy, oraz odniesienia do tajnych danych w usłudze GitHub. Tajemnice są odwoływane przy użyciu składni ${{ secrets.SECRET_NAME }}. Zobacz sekrety GitHub Actions.

Jeśli projekty nie znajdują się w katalogu głównym repozytorium, należy zmienić przepływ pracy, aby określić ścieżkę do znalezienia plików Dockerfile. Dodaj zmienne środowiskowe dla ścieżek względnych do pliku Dockerfile w obu projektach.

DOCKER_FILEPATH_WEBAPI: docker/ComposeSample/WebApi/Dockerfile
DOCKER_FILEPATH_WEBFRONTEND: docker/ComposeSample/WebFrontend/Dockerfile

Użyj wartości tych zmiennych środowiskowych dla parametru file w następujący sposób:

- name: Build and push Docker image to Azure container registry
  uses: docker/build-push-action@v4
  with:
    push: true
    tags: ${{ env.CONTAINER_REGISTRY_LOGIN_SERVER }}/webfrontend:${{ github.sha }}
    file: ${{ env.DOCKER_FILEPATH_WEBFRONTEND }}

Jeśli musisz wprowadzić zmiany w pliku Dockerfile, wprowadź i zapisz zmiany, zatwierdź i wypchnij do repozytorium zdalnego. Przepływ pracy generowany przez program Visual Studio zawiera wyzwalacz, który powoduje jego uruchomienie w przypadku aktualizacji w określonej gałęzi. Jeśli wypchniesz do gałęzi working, powinien on wyglądać podobnie do następującego kodu:

on:
  push:
  branches:
  - working

Aby przetestować zmiany, zatwierdź je i wypchnij do gałęzi repozytorium określonego w kodzie wyzwalacza. Nie musisz tworzyć pull requesta. Przepływ pracy działa pod warunkiem, że wyzwalacz push jest ustawiony na właściwą gałąź.

Na karcie Actions w repozytorium w GitHub.com wyszukaj przebieg przepływu pracy. Możesz uzyskać dostęp bezpośrednio za pomocą linku na karcie podsumowania funkcji GitHub Actions w programie Visual Studio. W usłudze GitHub możesz otworzyć przebieg przepływu pracy, aby wyświetlić dzienniki.

Rozwiązywanie problemów

Poniższe porady dotyczące rozwiązywania problemów mogą być przydatne, jeśli przepływ pracy nie zostanie uruchomiony pomyślnie.

Problem: Etap kompilacji nie kompiluje

Jednym z problemów, które można napotkać w pliku Dockerfile, jest to, że etap kompilacji nie będzie działać tak samo jak w programie Visual Studio. Domyślny plik Dockerfile generowany przez program Visual Studio dla projektu pokazuje ten problem. Rozważ następujące modyfikacje etapu kompilacji, jeśli masz taki plik Dockerfile. Oto przykład, w którym projekt znajdował się w docker/ComposeSample/WebApi w repozytorium. Pełna ścieżka jest podana, ponieważ kontekst Dockerfile w kontenerze kompilacji przepływu pracy jest ustawiony na katalog główny repozytorium, ale w programie Visual Studio jest ustawiony na folder nadrzędny względem folderu projektu. Sufiks _build jest dołączany tutaj, aby utworzyć folder kompilacji, a zamiast kopiować plik projektu, cały folder jest kopiowany. W porównaniu do domyślnego pliku Dockerfile wygenerowanego przez program Visual Studio część pliku ścieżki w pierwszym argumencie polecenia COPY została usunięta, abyśmy kopiowali cały folder zamiast tylko pliku projektu. Bez tych zmian ten etap generuje błąd MSBuild.

FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build
WORKDIR /src
COPY ["docker/ComposeSample/WebApi/", "WebApi_build/"]
RUN dotnet restore "WebApi_build/WebApi.csproj"
COPY . .
WORKDIR "/src/WebApi_build"
RUN dotnet build "WebApi.csproj" -c Release -o /app/build

Problem: Poświadczenia uwierzytelniania

Przepływ pracy wymaga skonfigurowania odpowiednich tajnych danych nazwy użytkownika i hasła na potrzeby dostępu do usługi Azure. Program Visual Studio próbuje to zrobić automatycznie podczas tworzenia zasobów Azure oraz na ekranie GitHub Actions w środowisku IDE Microsoft Visual Studio. Możesz sprawdzić wpisy tajne w usłudze GitHub i upewnić się, że są tam, lub ponownie je wygenerować i dodać je ponownie do usługi GitHub, jeśli to konieczne, korzystając z sekcji Ustawienia w repozytorium. Sprawdź identyfikator tajemnic w odniesieniu do tego, co jest wymienione w każdej sekcji przepływu pracy. W razie potrzeby możesz przejść do rejestru kontenerów w witrynie Azure Portal i uzyskać nazwę użytkownika i hasło rejestru kontenerów oraz użyć tych wartości do zaktualizowania wpisów tajnych w usłudze GitHub.

Jeśli uruchomiłeś polecenie az ad sp create-for-rbac, aby skonfigurować jednostkę usługi i uzyskać identyfikator klienta, tajemnicę klienta i identyfikator dzierżawy, dodaj identyfikator klienta i tajemnicę klienta jako sekrety w sekcji Sekrety GitHub Actions dla swojego repozytorium GitHub. Poświadczenia logowania platformy Azure można podać w postaci nazwy użytkownika (identyfikatora klienta aplikacji) i hasła (klucza tajnego klienta) na potrzeby uwierzytelniania aplikacji kontenera platformy Azure. W tym celu zastąp krok Azure login poniższym kodem. Użyj własnych nazw tajemnic GitHub utworzonych dla identyfikatora klienta i klucza tajnego klienta, a następnie użyj identyfikatora dzierżawcy z danych wyjściowych tego samego polecenia.

- name: Azure login
  uses: azure/CLI@v1
  with:
    inlineScript: |
      az login --service-principal -u ${{ secrets.GITHUB_SECRETID_FOR_USERNAME }} -p ${{ secrets.GITHUB_SECRETID_FOR_PASSWORD }} --tenant {your tenant ID}
      az account list

Jeśli plik Dockerfile działa poprawnie, a uwierzytelnianie jest poprawne i nadal występują problemy z przepływem pracy, rozważ następujące zasoby:

• Azure Container Apps na GitHub
• Azure Container Apps on Stack Overflow

Które typy projektów są obsługiwane?

• ASP.NET Core
• ASP.NET 5 i wyższych
• Azure Functions

Które usługi platformy Azure są obsługiwane?

• Azure Web Apps
• Azure Functions
• Azure API Management