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.
Wymagania wstępne
- Musisz zalogować się do konta usługi GitHub w programie Visual Studio.
- Konto Azure. Jeśli nie masz konta platformy Azure, aktywuj korzyści platformy Azure dla subskrybentów programu Visual Studio lub zarejestruj się w celu uzyskania bezpłatnej wersji próbnej.
Wdrażanie pojedynczego projektu na platformie Azure przy użyciu funkcji GitHub Actions
W Eksplorator rozwiązań kliknij prawym przyciskiem myszy GitHub.com hostowany projekt i wybierz polecenie 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, która odpowiada Twoim potrzebom.
W ostatnim kroku kreatora wybierz pozycję Ciągła integracja/ciągłe wdrażanie przy użyciu przepływów pracy funkcji GitHub Actions (generuje plik yml), a następnie wybierz pozycję Zakończ.
Program Visual Studio generuje nowy przepływ pracy funkcji GitHub Actions i prosi o zatwierdzenie go i wypchnięcie go do GitHub.com.
Jeśli wykonasz ten krok przy użyciu wbudowanego narzędzia Git, program Visual Studio wykryje wykonywanie przepływu pracy.
Ustawianie wpisów tajnych usługi 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ć wpis tajny usługi GitHub dla Ciebie z poprawną wartością. Jeśli to się nie powiedzie, poinformuje Cię o tym i da ci możliwość ponownego wypróbowania.
Jeśli nie można ponownie ustawić wpisu tajnego, program Visual Studio daje możliwość ręcznego uzyskania dostępu do wpisu tajnego, dzięki czemu można ukończyć proces za pośrednictwem strony repozytorium na GitHub.com.
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, które implementują mikrousługi w usłudze Azure Container Apps lub Azure Kubernetes Service (AKS). W tym artykule opisano usługę Azure Container Apps.
Kliknij prawym przyciskiem myszy węzeł GitHub Actions w Eksplorator rozwiązań, a następnie wybierz pozycję Nowy przepływ pracy. Zostanie wyświetlony kreator przepływu pracy funkcji GitHub Actions.
Na ekranie docelowym przepływu pracy funkcji GitHub Actions wybierz pozycję Azure.
Dla określonego miejsca docelowego wybierz pozycję Azure Container Apps. Kreator przechodzi do ekranu Aplikacja kontenera.
Wybierz istniejącą aplikację kontenera platformy Azure lub wybierz pozycję Utwórz nową.
Po utworzeniu nowego ekranu zostanie wyświetlony 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 kontenerów, które współużytkować tę samą sieć wirtualną i zapisywać dzienniki w tym samym miejscu docelowym rejestrowania. Zobacz Środowiska usługi Azure Container Apps. Jeśli nie wiesz, co to jest lub nie utworzono go wcześniej, utwórz nowe dla tego wystąpienia.
Po utworzeniu zostanie wyświetlone nowe wystąpienie usługi Azure Container Apps.
Wybierz przycisk 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 jednostkach SKU usługi Azure Container Registry, zobacz Warstwy usługi Azure Container Registry.
Po utworzeniu nowy rejestr zostanie wyświetlony na ekranie.
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.
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.
Po zakończeniu zostanie wyświetlony ekran podsumowania. Na ekranie podsumowania są wyświetlane poświadczenia zgodne z wpisami tworzonymi przez program Visual Studio w repozytorium GitHub w ramach wpisów tajnych funkcji 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.
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 Eksplorator rozwiązań, kliknij prawym przyciskiem myszy właśnie utworzony przepływ pracy, a następnie wybierz polecenie 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 About custom actions (Informacje o akcjach niestandardowych). Plik przepływu pracy zawiera wiele konfigurowalnych elementów, takich jak ustawienia zmiennych środowiskowych i nazw wpisów tajnych. Możesz zobaczyć odwołania do lokalizacji plików Dockerfile, nazwy aplikacji kontenera platformy Azure, gałęzi w repozytorium, która będzie używana do wyzwalania przebiegów przepływu pracy i odwołuje się do wpisów tajnych w usłudze GitHub. Odwołania do wpisów tajnych są przywołyne przy użyciu składni ${{ secrets.SECRET_NAME }}. Zobacz Wpisy tajne funkcji 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, powinien on wyglądać podobnie do working 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ć żądania ściągnięcia. Przepływ pracy jest uruchamiany tak długo, jak push wyzwalacz jest ustawiony na właściwą gałąź.
Na karcie Akcje 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ę 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 nad folderem 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 wpisów tajnych nazwy użytkownika i hasła na potrzeby dostępu do platformy Azure. Program Visual Studio próbuje to zrobić automatycznie podczas tworzenia zasobów platformy Azure lub ekranu funkcji GitHub Actions w środowisku IDE programu 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 wpisów tajnych pod kątem odwołań 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 uruchomiono az ad sp create-for-rbac polecenie w celu skonfigurowania jednostki usługi i pobrania identyfikatora klienta, wpisu tajnego klienta i identyfikatora dzierżawy, dodaj identyfikator klienta i klucz tajny klienta jako wpisy tajne w sekcji Wpisy tajne funkcji GitHub Actions dla 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 wpisów tajnych usługi GitHub utworzonych dla identyfikatora klienta i klucza tajnego klienta, a następnie użyj identyfikatora dzierżawy 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:
Które typy projektów są obsługiwane?
- ASP.NET Core
- ASP.NET 5 i nowszych
- Azure Functions
Które usługi platformy Azure są obsługiwane?
- Aplikacje internetowe platformy Azure
- Azure Functions
- Usługa Azure API Management
Opinia
Dostępne już wkrótce: W 2024 r. będziemy stopniowo wycofywać zgłoszenia z serwisu GitHub jako mechanizm przesyłania opinii na temat zawartości i zastępować go nowym systemem opinii. Aby uzyskać więcej informacji, sprawdź: https://aka.ms/ContentUserFeedback.
Prześlij i wyświetl opinię dla