Bereitstellen Ihrer Anwendung in Azure mithilfe von GitHub Actions-Workflows, die von Visual Studio erstellt wurden

Artikel
02/07/2025

Ab Visual Studio 2019, Version 16.11, können Sie neue GitHub Actions-Workflows für .NET-Projekte erstellen, die auf GitHub.com gehostet werden.

Voraussetzungen

Sie müssen bei Ihrem GitHub-Konto in Visual Studio angemeldet sein.
Ein Azure-Konto. Wenn Sie nicht über ein Azure-Konto verfügen, aktivieren Sie Ihre Azure-Nutzen für Visual Studio-Abonnenten oder registrieren Sie sich für eine kostenlose Testversion.

Bereitstellen eines einzelnen Projekts in Azure mithilfe von GitHub-Aktionen

Klicken Sie im Projektmappen-Explorer mit der rechten Maustaste auf Ihr Projekt, das auf GitHub.com gehostet wird, und wählen Sie Veröffentlichenaus.

Rechtsklick > Veröffentlichen

Wählen Sie auf dem nächsten Bildschirm Azure und dann Nextaus.

Azure auswählen

Je nach Projekttyperhalten Sie eine andere Liste von Azure-Diensten, aus der Sie auswählen können. Wählen Sie einen der unterstützten Azure-Dienste aus, die Ihren Anforderungen entsprechen.

Wählen Sie den entsprechenden Azure-Dienst für Ihr Projekt

Wählen Sie im letzten Schritt des Assistenten die Option CI/CD mit GitHub Actions-Workflows (generiert yml-Datei) und dann Fertigstellen aus.

CI/CD mithilfe von GitHub Actions-Workflows (generiert yml-Datei)

Visual Studio generiert einen neuen GitHub Actions-Workflow und fordert Sie auf, ihn zu übernehmen und an GitHub.com zu übertragen.

Commit und Push

Wenn Sie diesen Schritt ausführen, indem Sie die integrierten Git-Toolsverwenden, erkennt Visual Studio die Ausführung des Workflows.

Workflow wird ausgeführt.

Festlegen der GitHub-Geheimnisse

Damit der generierte Workflow erfolgreich in Azure bereitgestellt werden kann, könnte es erforderlich sein, auf ein Veröffentlichungsprofilzuzugreifen.

ein GitHub-Secret

Eine erfolgreiche Bereitstellung kann auch den Zugriff auf einen Dienstprinzipal erfordern.

zwei GitHub-Geheimschlüssel

In allen Fällen versucht Visual Studio, den GitHub-Geheimschlüssel für Sie mit dem richtigen Wert festzulegen. Wenn er fehlschlägt, informiert es Sie und gibt Ihnen die Möglichkeit, es erneut zu versuchen.

GitHub-Geheimnis fehlt

Wenn der geheime Schlüssel nicht erneut festgelegt werden kann, bietet Ihnen Visual Studio die Möglichkeit, manuell zugriff auf den geheimen Schlüssel zu erhalten, sodass Sie den Vorgang über die Seite Ihres Repositorys auf GitHub.com abschließen können.

Fehlendes GitHub-Geheimnis festlegen festlegen

Bereitstellen mehrerer Projekte in Azure-Container-Apps mithilfe von GitHub-Aktionen

Diese Schritte sind geeignet, wenn Sie über mehr als ein Projekt verfügen, das Docker-Container verwendet, und Sie diese als Multiprojekt-App bereitstellen möchten. Sie können Multiprojekt-Apps wie solche bereitstellen, die Microservices für Azure Container Apps oder Azure Kubernetes Service (AKS)implementieren. Dieser Artikel behandelt Azure-Container-Apps.

Klicken Sie im Projektmappen-Explorer mit der rechten Maustaste auf den Knoten GitHub Actions, und wählen Sie New workflowaus. Der Workflow-Assistent für GitHub-Aktionen wird angezeigt.
Wählen Sie auf dem Zielbildschirm "GitHub Actions Workflow" Azureaus.
Wählen Sie für das jeweilige Ziel Azure Container Appsaus. Der Assistent wechselt zum Bildschirm Container-App.
Wählen Sie eine vorhandene Azure-Container-App aus, oder wählen Sie "Neueerstellen" aus.

Wenn Sie ein neues erstellen, wird dieser Bildschirm angezeigt. Beim Testen oder Lernen empfiehlt es sich in der Regel, eine neue Ressourcengruppe zu erstellen, damit später alles einfacher gelöscht werden kann. Eine Container-Apps-Umgebung ist eine sichere Grenze um Gruppen von Container-Apps, die dasselbe virtuelle Netzwerk gemeinsam nutzen und Protokolle an dasselbe Protokollierungsziel schreiben. Weitere Informationen finden Sie unter Azure Container Apps-Umgebungen. Wenn Sie nicht wissen, was das ist oder noch nicht erstellt wurde, erstellen Sie für diese Instanz eine neue.

Nach der Erstellung wird die neue Azure Container Apps-Instanz angezeigt.
Wählen Sie Weiter aus, um zum Bildschirm Registrierung zu wechseln. Wählen Sie eine vorhandene Azure-Containerregistrierung aus, oder erstellen Sie eine neue.

Wenn Sie auswählen, ein neues zu erstellen, wird dieser Bildschirm angezeigt. Geben Sie die Ressourcengruppe, SKU an, und wählen Sie nach Möglichkeit denselben Bereich wie zuvor aus. Informationen zu den SKUs für die Azure-Containerregistrierung finden Sie unter Dienstebenen der Azure-Containerregistrierung.

Nach der Erstellung wird die neue Registrierung auf dem Bildschirm angezeigt.
Die bereitstellungsfähigen Projekte in Ihrer Lösung werden angezeigt; Wählen Sie die Projekte aus, die Sie zusammen in derselben Azure-Container-Apps-Instanz bereitstellen möchten.
Klicken Sie auf Fertig stellen. Sie können sehen, welche Befehle ausgegeben werden, um die Ressourcen in Azure zu erstellen und die Authentifizierung einzurichten. Wenn etwas fehlschlägt, notieren Sie sich die verwendete Befehlszeile, da Sie dies über die CLI erneut versuchen können. Machen Sie sich keine Sorgen, wenn Sie zu diesem Zeitpunkt einen Autorisierungsfehler erhalten. Sie können die Authentifizierung auch später in Visual Studio einrichten.
Nach Abschluss des Vorgangs wird der Zusammenfassungsbildschirm angezeigt. Der Zusammenfassungsbildschirm zeigt die Anmeldeinformationen an, die den Einträgen entsprechen, die Visual Studio in Ihrem GitHub-Repository unter den geheimen GitHub-Aktionen erstellt. Überprüfen Sie auf gelbe Warnzeichen. Wenn bei einem der Authentifizierungsschritte während des Erstellungsprozesses ein Fehler aufgetreten ist, haben Sie die Möglichkeit, dies hier zu korrigieren, indem Sie auf den Link durch das Warnzeichen klicken und einige Schritte ausführen.
Öffnen Sie die Workflowdatei, um zu überprüfen, was Visual Studio generiert hat. Während Visual Studio am besten einen Workflow für Ihre Situation generiert, ist jede App und jedes Repository einzigartig, sodass Sie die von Visual Studio generierte Workflow-YML-Datei häufig manuell bearbeiten müssen, bevor sie erfolgreich ausgeführt wird. Erweitern Sie zum Öffnen den Knoten „GitHub Actions“ im Projektmappen-Explorer, klicken Sie mit der rechten Maustaste auf den soeben erstellten Workflow, und wählen Sie Bearbeiten aus.

Im Folgenden sehen Sie ein Beispiel für eine Workflowdatei, die von Visual Studio für eine Lösung mit zwei bereitgestellten Projekten, WebAPI und WebFrontEnd erstellt wurde.

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

Die Hauptfunktion des Workflows besteht darin, sich bei den Azure-Diensten mit der richtigen Authentifizierung anzumelden und die Befehle zum Erstellen und Bereitstellen der App auszuführen.

Bearbeiten und Testen des Workflows

Die obige Prozedur generiert eine YML-Workflowdatei, sie muss jedoch normalerweise überprüft und angepasst werden, bevor sie für eine Bereitstellung verwendet werden kann. Möglicherweise müssen Sie sich auf gitHubs Anleitung zum Schreiben von Workflowaktionen beziehen. siehe Informationen zu benutzerdefinierten Aktionen. Die Workflowdatei enthält viele konfigurierbare Elemente, z. B. die Einstellungen für die Umgebungsvariablen und Die Namen der geheimen Schlüssel. Sie können Verweise auf die Speicherorte Ihrer Dockerfiles, den Namen Ihrer Azure-Container-App, die Verzweigung im Repository anzeigen, die Sie zum Auslösen des Workflows verwenden, und Verweise auf die geheimen Schlüssel in GitHub. Geheime Schlüssel werden mithilfe der Syntax ${{ secrets.SECRET_NAME }}referenziert. Weitere Informationen finden Sie unter GitHub Actions-Geheimnisse.

Wenn sich Ihre Projekte nicht im Stammverzeichnis des Repositorys befinden, müssen Sie den Workflow ändern, um den Pfad zum Suchen der Dockerfiles anzugeben. Fügen Sie Umgebungsvariablen für die relativen Pfade zur Dockerfile-Datei in beiden Projekten hinzu.

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

Verwenden Sie die Werte dieser Umgebungsvariablen für den parameter file wie folgt:

- 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 }}

Wenn Sie Änderungen an der Dockerfile-Datei vornehmen müssen, nehmen Sie die Änderungen vor und speichern sie, und committen und pushen Sie diese an das Remote-Repository. Der von Visual Studio generierte Workflow enthält einen Trigger, der bewirkt, dass er ausgeführt wird, wenn er auf einer angegebenen Verzweigung aktualisiert wird. Wenn Sie einen Push an die working-Verzweigung ausführen, sollte dies dem folgenden Code ähneln:

on:
  push:
  branches:
  - working

Um die Änderungen zu testen, führen Sie einen Commit durch und pushen die Änderung an die Verzweigung des im Triggercode angegebenen Repositorys. Sie müssen keine Pull-Anforderung (PR) erstellen. Der Workflow wird ausgeführt, solange der push-Trigger auf die richtige Verzweigung festgelegt ist.

Suchen Sie auf der Registerkarte Aktionen Ihres Repositorys unter GitHub.com nach der Workflowausführung. Sie können direkt dorthin gelangen, indem Sie einen Link auf der Zusammenfassungsregisterkarte „GitHub Actions“ in Visual Studio verwenden. In GitHub können Sie den Workflow öffnen, um die Protokolle anzuzeigen.

Fehlerbehebung

Die folgenden Tipps zur Problembehandlung sind möglicherweise hilfreich, wenn Ihr Workflow nicht erfolgreich ausgeführt wird.

Problem: Buildphase wird nicht erstellt

Ein Problem, das in der Dockerfile-Datei auftreten kann, besteht darin, dass die Buildphase nicht wie in Visual Studio funktioniert. Die Dockerfile-Standarddatei, die Visual Studio für ein Projekt generiert, veranschaulicht dieses Problem. Berücksichtigen Sie die folgenden Änderungen an der Buildphase, wenn Sie über eine solche Dockerfile verfügen. Hier ist ein Beispiel, in dem sich ein Projekt in docker/ComposeSample/WebApi in einem Repository befindet. Der vollständige Pfad wird angegeben, da der Dockerfile-Kontext im Workflowbuildcontainer auf den Stamm des Repositorys festgelegt ist, aber in Visual Studio wird er auf den Ordner oberhalb des Projektordners festgelegt. Das Suffix _build wird hier angefügt, um den Buildordner zu erstellen, und anstatt nur die Projektdatei zu kopieren, wird der gesamte Ordner kopiert. Im Vergleich zu der von Visual Studio generierten Standard-Dockerfile wurde der Dateiteil des Pfads im ersten Argument des Befehls `COPY` entfernt, sodass wir den gesamten Ordner anstelle der Projektdatei kopieren. Ohne diese Änderungen erzeugt diese Phase einen MSBuild-Fehler.

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: Authentifizierungsdaten

Der Workflow erfordert, dass für den Azure-Zugriff die richtigen Benutzernamen- und Kennwortschlüssel eingerichtet werden. Visual Studio versucht, dies automatisch zu tun, wenn Sie die Azure-Ressourcen erstellen oder den GitHub-Aktionsbildschirm in der Microsoft Visual Studio-IDE verwenden. Sie können die geheimen Schlüssel in GitHub überprüfen und sicherstellen, dass sie vorhanden sind, oder sie erneut generieren und bei Bedarf mithilfe des Abschnitts "Einstellungen" im Repository zu GitHub hinzufügen. Überprüfen Sie die ID der Geheimnisse anhand der Verweise in den einzelnen Abschnitten des Workflows. Bei Bedarf können Sie zur Containerregistrierung im Azure-Portal wechseln und den Benutzernamen und das Kennwort für die Containerregistrierung abrufen und diese Werte verwenden, um die geheimen Schlüssel in GitHub zu aktualisieren.

Wenn Sie den az ad sp create-for-rbac-Befehl ausgeführt haben, um einen Dienstprinzipal einzurichten und eine Client-ID, einen geheimen Clientschlüssel und eine Mandanten-ID abzurufen, fügen Sie die Client-ID und den geheimen Clientschlüssel im Abschnitt GitHub Actions-Geheimnisse für Ihr GitHub-Repository hinzu. Sie können Azure-Anmeldeinformationen in Form eines Benutzernamens (Client-ID für die App) und des Kennworts (geheimer Clientschlüssel) für die Azure-Container-App-Authentifizierung angeben. Ersetzen Sie dazu den Schritt Azure login durch den folgenden Code. Verwenden Sie Ihre eigenen geheimen GitHub-Namen, die Sie für die Client-ID und den geheimen Clientschlüssel erstellt haben, und verwenden Sie die Mandanten-ID aus der Ausgabe desselben Befehls.

- 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

Wenn die Dockerfile-Datei ordnungsgemäß funktioniert und die Authentifizierung korrekt ist und weiterhin Probleme mit Ihrem Workflow auftreten, berücksichtigen Sie die folgenden Ressourcen:

Welche Projekttypen werden unterstützt?

ASP.NET Core
ASP.NET 5 und höher
Azure-Funktionen

Welche Azure-Dienste werden unterstützt?

Azure Web Apps
Azure-Funktionen
Azure-API-Verwaltung

Freigeben über