Bereitstellen in App Service mithilfe von GitHub Actions

Verwenden Sie GitHub Actions zum Automatisieren Ihres Workflows und zum Bereitstellen im Azure App Service aus GitHub.

Voraussetzungen

Einrichten der Bereitstellung von GitHub-Aktionen beim Erstellen der App

Die Bereitstellung von GitHub-Aktionen ist in den standardmäßigen App-Erstellungsassistenten integriert. Sie müssen lediglich Continuous Deployment (CD) auf Aktivieren der Registerkarte „Bereitstellung“ festlegen und die gewünschte Organisation, das Repository und die gewünschte Verzweigung konfigurieren.

Screenshot, der zeigt, wie Sie die Bereitstellung von GitHub Actions im Assistenten zum Erstellen von App-Diensten aktivieren.

Wenn Sie die kontinuierliche Bereitstellung aktivieren, wählt der Assistent für die App-Erstellung automatisch die Authentifizierungsmethode basierend auf der Auswahl der Standardauthentifizierung aus und konfiguriert Ihre App und Ihr GitHub-Repository entsprechend:

Auswahl der Standardauthentifizierung Authentifizierungsmethode
Disable Vom Benutzer zugewiesene Identität (OpenID Connect) (empfohlen)
Aktivieren Standardauthentifizierung

Hinweis

Wenn beim Erstellen Ihrer App eine Fehlermeldung angezeigt wird, die besagt, dass Ihr Azure-Konto nicht über bestimmte Berechtigungen verfügt, hat es möglicherweise nicht die erforderlichen Berechtigungen zum Erstellen und Konfigurieren der vom Benutzer zugewiesenen Identität. Eine Alternative finden Sie unter Einrichten der Bereitstellung von GitHub Actions aus dem Deployment Center.

Einrichten der Bereitstellung von GitHub Actions über das Deployment Center

Bei einer vorhandenen Anwendung können Sie mit GitHub Actions schnell loslegen, indem Sie das App Service Deployment Center nutzen. Diese schlüsselfertige Methode generiert automatisch eine GitHub Actions Workflow-Datei auf der Grundlage Ihres Anwendungsstapels und überträgt sie in Ihr GitHub-Repository.

Mit dem Deployment Center können Sie auch die sicherere OpenID Connect-Authentifizierung mit der Option für die vom Benutzer zugewiesene Identität problemlos konfigurieren.

Wenn Ihr Azure-Konto über die erforderlichen Berechtigungen verfügt, können Sie eine benutzerseitig zugewiesene Identität erstellen. Andernfalls können Sie eine vorhandene, benutzerseitig zugewiesene verwaltete Identität im Dropdown Identität auswählen. Sie können mit Ihrem Azure-Administrator eine benutzerseitig zugewiesene verwaltete Identität mit der Rolle Website-Mitwirkender erstellen.

Weitere Informationen finden Sie unter Continuous Deployment in Azure App Service.

Manuelles Einrichten eines GitHub-Actions-Workflows

Sie können einen Workflow auch ohne das Deployment Center bereitstellen. In diesem Fall müssen Sie drei Schritte ausführen:

  1. Generieren von Anmeldeinformationen für die Bereitstellung
  2. Konfigurieren des GitHub-Geheimnisses
  3. Hinzufügen der Workflowdatei zum GitHub-Repository

1. Generieren von Anmeldeinformationen für die Bereitstellung

Die empfohlene Vorgehensweise für die Authentifizierung mit Azure App Services für GitHub Actions ist mit OpenID Connect. Dies ist eine Authentifizierungsmethode, die kurzlebige Token verwendet. Einrichten von OpenID Connect mit GitHub Actions ist komplexer, bietet jedoch mehr Sicherheit.

Alternativ können Sie sich mit einer vom Benutzer zugewiesenen verwalteten Identität, einem Dienstprinzipal oder einem Veröffentlichungsprofil authentifizieren.

Die folgenden Schritte führen Sie durch die Erstellung einer Active Directory-Anwendung, eines Dienstprinzipals und von Verbundanmeldeinformationen mithilfe von Azure CLI-Anweisungen. Informationen zum Erstellen einer Active Directory-Anwendung, eines Dienstprinzipals und von Verbundanmeldeinformationen über das Azure-Portal finden Sie unter Verbinden von GitHub und Azure.

  1. Wenn Sie keine bestehende Anwendung besitzen, registrieren Sie eine neue Active Directory-Anwendung und einen neuen Dienstprinzipal, die auf Ressourcen zugreifen können. Erstellen Sie die Active Directory-Anwendung.

    az ad app create --display-name myApp
    

    Dieser Befehl gibt JSON mit einem appId-Wert aus, der client-id entspricht. Speichern Sie den Wert, der später als AZURE_CLIENT_IDGitHub-Geheimnis verwendet werden soll.

    Sie verwenden den objectId Wert beim Erstellen von Verbundanmeldeinformationen mit Graph-API und verweisen diese als APPLICATION-OBJECT-ID.

  2. Erstellen eines Dienstprinzipals. Ersetzen Sie $appID durch die AppId aus Ihrer JSON-Ausgabe.

    Dieser Befehl generiert eine JSON-Ausgabe mit einem anderen objectId und wird im nächsten Schritt verwendet. Der neue objectId ist der assignee-object-id.

    Kopieren Sie die appOwnerTenantId, um sie später als GitHub-Geheimnis für AZURE_TENANT_ID zu verwenden.

     az ad sp create --id $appId
    
  3. Erstellen Sie eine neue Rollenzuweisung nach Abonnement und Objekt. Standardmäßig ist die Rollenzuweisung an Ihr Standardabonnement gebunden. Ersetzen Sie $subscriptionId durch Ihre Abonnement-ID, $resourceGroupName durch Ihren Ressourcengruppennamen, $webappName durch Ihren Web-App-Namen und $assigneeObjectId durch die generierte id. Erfahren Sie, wie Sie Azure-Abonnements mit der Azure CLI verwalten.

    az role assignment create --role contributor --subscription $subscriptionId --assignee-object-id  $assigneeObjectId --scope /subscriptions/$subscriptionId/resourceGroups/$resourceGroupName/providers/Microsoft.Web/sites/$webappName --assignee-principal-type ServicePrincipal
    
  4. Führen Sie den folgenden Befehl aus, um neue Anmeldeinformationen für die Verbundidentität für Ihre Active Directory-Anwendung zu erstellen.

    • Ersetzen Sie APPLICATION-OBJECT-ID durch die AppId (die beim Erstellen der Anwendung generiert wurde) für Ihre Active Directory-Anwendung.
    • Legen Sie einen Wert für CREDENTIAL-NAME fest, um später auf ihn zu verweisen.
    • Legen Sie die subject fest. Der Wert wird von GitHub in Abhängigkeit von Ihrem Workflow festgelegt:
      • Aufträge in Ihrer GitHub Actions-Umgebung: repo:< Organization/Repository >:environment:< Name >
      • Bei Aufträgen, die nicht an eine Umgebung gebunden sind, fügen Sie den Referenzpfad für den Branch/Tag auf der Grundlage des für die Auslösung des Workflows verwendeten Referenzpfads ein: repo:< Organization/Repository >:ref:< ref path>. Zum Beispiel: repo:n-username/ node_express:ref:refs/heads/my-branch oder repo:n-username/ node_express:ref:refs/tags/my-tag.
      • Für Workflows, die durch ein Pull Request-Ereignis ausgelöst werden: repo:< Organization/Repository >:pull_request.
    az ad app federated-credential create --id <APPLICATION-OBJECT-ID> --parameters credential.json
    ("credential.json" contains the following content)
    {
        "name": "<CREDENTIAL-NAME>",
        "issuer": "https://token.actions.githubusercontent.com",
        "subject": "repo:organization/repository:ref:refs/heads/main",
        "description": "Testing",
        "audiences": [
            "api://AzureADTokenExchange"
        ]
    }     
    

2. Konfigurieren des GitHub-Geheimnisses

Sie müssen die Client-ID Ihrer Anwendung, die Mandanten-ID und die Abonnement-ID für die Azure/Anmeldeaktion bereitstellen. Diese Werte können entweder direkt im Workflow bereitgestellt werden oder in GitHub-Geheimnissen gespeichert und darauf in Ihrem Workflow verwiesen werden. Das Speichern der Werte als GitHub-Geheimnisse ist die sicherere Option.

  1. Öffnen Sie Ihr GitHub-Repository, und wechseln Sie zu Einstellungen > Sicherheit > Geheimnisse und Variablen > Aktionen > Neues Repositorygeheimnis.

  2. Erstellen Sie Geheimnisse für AZURE_CLIENT_ID, AZURE_TENANT_ID und AZURE_SUBSCRIPTION_ID. Verwenden Sie diese Werte aus Ihrer Active Directory-Anwendung für Ihre GitHub-Geheimnisse:

    GitHub-Geheimnis Eine Active Directory-Anwendung
    AZURE_CLIENT_ID Anwendungs-ID (Client)
    AZURE_TENANT_ID Verzeichnis-ID (Mandant)
    AZURE_SUBSCRIPTION_ID Abonnement-ID
  3. Speichern Sie jedes Geheimnis, indem Sie Geheimnis hinzufügen auswählen.

3. Hinzufügen der Workflowdatei zum GitHub-Repository

Ein Workflow wird durch eine YAML-Datei (.yml) in dem /.github/workflows/-Pfad in Ihrem GitHub-Repository definiert. Diese Definition enthält die verschiedenen Schritte und Parameter, die den Workflow bilden.

Die Workflowdatei sollte mindestens die folgenden einzelnen Schritte enthalten:

  1. Authentifizieren Sie sich bei App Service mit dem von Ihnen erstellten GitHub-Geheimschlüssel.
  2. Erstellen der Web-App.
  3. Bereitstellen der Web-App.

Um Ihren Code in einer App Service-Anwendung bereitzustellen, verwenden Sie die Aktion azure/webapps-deploy@v3. Die Aktion erfordert den Namen Ihrer Web-App in app-name und, je nach Sprachstapel, den Pfad eines *.zip, *.war, *.jar oder Ordners, der in package bereitgestellt werden soll. Eine vollständige Liste der möglichen Eingaben für die azure/webapps-deploy@v3-Aktion finden Sie in der Definition action.yml.

Die folgenden Beispiele zeigen den Teil des Workflows, in dem die Web-App in den verschiedenen unterstützten Sprachen erstellt wird.

Um mit OpenID Connect mithilfe der von Ihnen konfigurierten verwalteten Identität bereitzustellen, verwenden Sie die azure/login@v1-Aktion mit den client-id, tenant-id und subscription-id-Schlüsseln und verweisen Sie auf die zuvor erstellten GitHub-Schlüssel.

name: .NET Core

on: [push]

permissions:
      id-token: write
      contents: read

env:
  AZURE_WEBAPP_NAME: my-app    # set this to your application's name
  AZURE_WEBAPP_PACKAGE_PATH: '.'      # set this to the path to your web app project, defaults to the repository root
  DOTNET_VERSION: '6.0.x'           # set this to the dot net version to use

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      # Checkout the repo
      - uses: actions/checkout@main
      - uses: azure/login@v1
        with:
          client-id: ${{ secrets.AZURE_CLIENT_ID }}
          tenant-id: ${{ secrets.AZURE_TENANT_ID }}
          subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

      
      # Setup .NET Core SDK
      - name: Setup .NET Core
        uses: actions/setup-dotnet@v3
        with:
          dotnet-version: ${{ env.DOTNET_VERSION }} 
      
      # Run dotnet build and publish
      - name: dotnet build and publish
        run: |
          dotnet restore
          dotnet build --configuration Release
          dotnet publish -c Release --property:PublishDir='${{ env.AZURE_WEBAPP_PACKAGE_PATH }}/myapp' 
          
      # Deploy to Azure Web apps
      - name: 'Run Azure webapp deploy action using publish profile credentials'
        uses: azure/webapps-deploy@v3
        with: 
          app-name: ${{ env.AZURE_WEBAPP_NAME }} # Replace with your app name
          package: '${{ env.AZURE_WEBAPP_PACKAGE_PATH }}/myapp'
      
      - name: logout
        run: |
          az logout

Häufig gestellte Fragen

Wie stelle ich eine WAR-Datei über das Maven-Plug-In bereit?

Falls Sie Ihr Java Tomcat-Projekt mit dem Maven-Plug-In konfiguriert haben, können Sie es auch über dieses Plug-In für Azure App Service bereitstellen. Wenn Sie die Azure CLI-GitHub-Aktion verwenden, werden Ihre Azure-Anmeldeinformationen verwendet.

    - name: Azure CLI script file
      uses: azure/cli@v2
      with:
        inlineScript: |
          mvn package azure-webapp:deploy

Weitere Informationen zum Maven-Plug-In und zur Verwendung und Konfiguration finden Sie im Maven-Plug-In-Wiki für Azure App Service.

Wie stelle ich eine WAR-Datei über die Azure CLI bereit?

Wenn Sie die Azure CLI für die Bereitstellung in App Service verwenden, können Sie die GitHub-Aktion für die Azure CLI verwenden.

- name: Azure CLI script
  uses: azure/cli@v2
  with:
    inlineScript: |
      az webapp deploy --src-path '${{ github.workspace }}/target/yourpackage.war' --name ${{ env.AZURE_WEBAPP_NAME }} --resource-group ${{ env.RESOURCE_GROUP }}  --async true --type war

Weitere Informationen zur GitHub-Aktion für CLI und zur Verwendung und Konfiguration finden Sie in der GitHub-Aktion der Azure CLI. Weitere Informationen zum Befehl „az webapp deploy“, zur Verwendung und zu den Parameterdetails finden Sie in der Dokumentation zu „az webapp deploy“.

Wie stelle ich eine Startdatei bereit?

Verwenden Sie die GitHub-Aktion für die CLI. Zum Beispiel:

- name: Deploy startup script
  uses: azure/cli@v2
  with:
    inlineScript: |
      az webapp deploy --src-path ${{ github.workspace }}/src/main/azure/createPasswordlessDataSource.sh --name ${{ env.AZURE_WEBAPP_NAME }} --resource-group ${{ env.RESOURCE_GROUP }} --type startup --track-status false

Wie kann ich in einem Container bereitstellen?

Mit der Azure Web Deploy-Aktion können Sie Ihren Workflow automatisieren, um mithilfe von GitHub Actions benutzerdefinierte App Service-Container bereitzustellen. Ausführliche Informationen zu den Schritten zur Bereitstellung mithilfe von GitHub Actions finden Sie unter In Container bereitstellen.

Wie aktualisiere ich die Tomcat-Konfiguration nach der Bereitstellung?

Falls Sie eine Ihrer Web-Apps-Einstellungen nach der Bereitstellung aktualisieren möchten, können Sie die Aktion App Service-Einstellungen verwenden.

    - uses: azure/appservice-settings@v1
      with:
        app-name: 'my-app'
        slot-name: 'staging'  # Optional and needed only if the settings have to be configured on the specific deployment slot
        app-settings-json: '[{ "name": "CATALINA_OPTS", "value": "-Dfoo=bar" }]' 
        connection-strings-json: '${{ secrets.CONNECTION_STRINGS }}'
        general-settings-json: '{"alwaysOn": "false", "webSocketsEnabled": "true"}' #'General configuration settings as Key Value pairs'
      id: settings

Weitere Informationen zu dieser Aktion und zur Verwendung und Konfiguration finden Sie im Repository App Service-Einstellungen.

Nächste Schritte

Sehen Sie sich die Referenzen zu Azure GitHub Actions und Workflows an: