Bereitstellen Ihrer Anwendung in Azure mithilfe in Visual Studio erstellter GitHub Actions-Workflows
Ab Visual Studio 2019 Version 16.11 können Sie neue GitHub Actions-Workflows für auf GitHub.com gehostete .NET-Projekte erstellen.
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 Actions
Klicken Sie im Projektmappen-Explorer mit der rechten Maustaste auf Ihr auf GitHub.com gehostetes Projekt, und wählen Sie dann Veröffentlichen aus.
Wählen Sie auf dem nächsten Bildschirm Azure und dann Weiter aus.
Je nach dem Projekttyp wird Sie eine andere Liste von Azure-Diensten angezeigt, aus der Sie auswählen können. Wählen Sie einen der unterstützten Azure-Dienste aus, der Ihren Anforderungen entspricht.
Wählen Sie im letzten Schritt des Assistenten die Option CI/CD mit GitHub Actions-Workflows (generiert yml-Datei) und dann Fertigstellen aus.
Visual Studio generiert einen neuen GitHub Actions-Workflow und fordert Sie auf, ihn als Commit auf GitHub.com zu pushen.
Wenn Sie diesen Schritt mit dem integrierten Git-Tools ausführen, erkennt Visual Studio die Ausführung des Workflows.
Festlegen der GitHub-Geheimnisse
Damit der generierte Workflow erfolgreich in Azure bereitgestellt werden kann, benötigt er möglicherweise Zugriff auf ein Veröffentlichungsprofil.
Für eine erfolgreiche Bereitstellung kann auch der Zugang zu einem Dienstprinzipal erforderlich sein.
In allen Fällen versucht Visual Studio, das GitHub-Geheimnis in Ihrem Namen auf den richtigen Wert festzulegen. Wenn ein Fehler auftritt, werden Sie darüber informiert und können den Vorgang erneut ausführen.
Wenn das Geheimnis nicht erneut festgelegt werden kann, bietet Visual Studio Ihnen die Möglichkeit, manuell auf das Geheimnis zuzugreifen, damit Sie den Vorgang über die Seite Ihres Repositorys auf Github.com abschließen können.
Bereitstellen mehrerer Projekte in Azure Container Apps mithilfe von GitHub Actions
Diese Schritte sind geeignet, wenn Sie mehr als ein Projekt haben, das Docker-Container verwendet, und Sie diese als Multiprojekt-App bereitstellen möchten. Sie können Multiprojekt-Apps, z. B. solche, die Microservices implementieren, auf Azure Container Apps oder Azure Kubernetes Service (AKS) bereitstellen. Dieser Artikel behandelt Azure Container Apps.
Klicken Sie im Projektmappen-Explorer mit der rechten Maustaste auf den Knoten GitHub Actions, und wählen Sie Neuer Workflow aus. Der GitHub Actions-Workflowassistent wird angezeigt.
Wählen Sie auf dem Zielbildschirm „GitHub Actions-Workflow“ die Option Azure aus.
Wählen Sie für das spezifische Ziel Azure Container Apps aus. Der Assistent wechselt zum Bildschirm Container-App.
Wählen Sie eine vorhandene Azure Container-App aus, oder wählen Sie Neu erstellen aus.
Wenn Sie eine neue 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 gemeinsam dasselbe virtuelle Netzwerk nutzen und Protokolle an dasselbe Protokollierungsziel schreiben. Weitere Informationen finden Sie unter Azure Container Apps-Umgebungen. Wenn Sie nicht wissen, was das ist oder bisher noch keine erstellt haben, erstellen Sie für diesen Fall 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 Container Registry aus, oder erstellen Sie eine neue.
Wenn Sie sich für die Erstellung einer neuen entscheiden, sehen Sie diesen Bildschirm. Geben Sie die Ressourcengruppe (SKU) an, und wählen Sie nach Möglichkeit dieselbe Region wie zuvor aus. Informationen zu den SKUs für Azure Container Registry finden Sie unter Azure Container Registry-Dienstebenen.
Nach der Erstellung wird die neue Registrierung auf dem Bildschirm angezeigt.
Die bereitstellbaren 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 die Befehle sehen, die 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 den Befehl über die CLI erneut versuchen können. Machen Sie sich keine zu großen 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 GitHub Actions-Geheimnissen 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, diesen hier zu korrigieren, indem Sie auf den Link neben dem Warnzeichen klicken und einige Schritte ausführen.
Öffnen Sie die Workflowdatei, um zu überprüfen, was Visual Studio generiert hat. Visual Studio tut zwar sein Bestes, um einen Workflow für Ihre Situation zu generieren, aber jede App und jedes Repository ist einzigartig, so dass Sie die von Visual Studio generierte YML-Workflowdatei oft manuell bearbeiten müssen, bevor sie erfolgreich ausgeführt werden kann. 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 einer Workflowdatei, die von Visual Studio für eine Lösung mit zwei bereitstellbaren 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 müssen sie jedoch in der Regel überprüfen und anpassen, bevor sie für eine Bereitstellung verwendet werden kann. Möglicherweise müssen Sie den Leitfaden von GitHub zum Schreiben von Workflowaktionen zu Rate ziehen, siehe Infos zu benutzerdefinierten Aktionen. Die Workflowdatei enthält viele konfigurierbare Elemente, z. B. die Einstellungen für die Umgebungsvariablen und die Namen der Geheimnisse. Sie können Verweise auf die Speicherorte Ihrer Dockerfile-Dateien, den Namen Ihrer Azure Container-App, die Verzweigung im Repository, die Sie zum Auslösen des Workflows verwenden werden und Verweise auf die Geheimnisse in GitHub sehen. Geheimnisse werden mithilfe der Syntax ${{ secrets.SECRET_NAME }} referenziert. Weitere Informationen finden Sie unter GitHub Actions-Geheimnisse.
Wenn sich Ihre Projekte nicht im Stamm des Repositorys befinden, müssen Sie den Workflow ändern, um den Pfad zum Suchen der Dockerfile-Dateien 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 file-Parameter 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 keinen Pull Request (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 die Workflowausführung öffnen, um die Protokolle anzuzeigen.
Problembehandlung
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-Datei verfügen. Hier ist ein Beispiel, bei dem sich ein Projekt in einem Repository bei docker/ComposeSample/WebApi befindet. Der vollständige Pfad wird angegeben, da der Dockerfile-Kontext im Workflowbuildcontainer auf den Stamm des Repositorys festgelegt ist, aber in Visual Studio ist 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 Dockerfile-Standarddatei wurde der Dateiteil des Pfads im ersten Argument des COPY-Befehls entfernt, sodass wir den gesamten Ordner statt nur die 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: Anmeldeinformationen für die Authentifizierung
Der Workflow erfordert, dass für den Azure-Zugriff die richtigen Geheimnisse für Benutzername und Kennwort eingerichtet werden. Visual Studio versucht, dies automatisch zu tun, wenn Sie die Azure-Assets erstellen oder über den Bildschirm „GitHub-Aktionen“ in der Microsoft Visual Studio IDE. Sie können die Geheimnisse 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 Geheimnisse 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 eines Kennworts (geheimer Clientschlüssel) für die Azure Container-App-Authentifizierung angeben. Ersetzen Sie dazu den Schritt Azure login mit dem folgenden Code. Verwenden Sie Ihre eigenen GitHub-Geheimnisnamen, 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, Sie aber weiterhin Probleme mit Ihrem Workflow haben, sollten Sie die folgenden Ressourcen nutzen:
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 Management
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter https://aka.ms/ContentUserFeedback.
Feedback senden und anzeigen für