Continuous Deployment mit benutzerdefinierten Containern in Azure App Service

2. Bereitstellungsquelle auswählen

Die Auswahl der Bereitstellungsquelle hängt von Ihrem Szenario ab:

• Die Containerregistrierung richtet CI/CD zwischen Ihrer Containerregistrierung und App Service ein.
• GitHub Actions ist die richtige Wahl für Sie, wenn Sie den Quellcode für das Containerimage in GitHub hosten. Die neue Bereitstellungsaktion wird durch neue Commits in Ihrem GitHub-Repository ausgelöst und kann docker build sowie docker push direkt in Ihrer Containerregistrierung ausführen. Anschließend aktualisiert sie die App Service-App, um das neue Image auszuführen. Weitere Informationen finden Sie unter Funktionsweise von CI/CD mit GitHub Actions.
• Informationen zum Einrichten von CI/CD mit Azure Pipelines finden Sie unter Bereitstellen eines Azure-Web-App-Containers aus Azure Pipelines.

Wenn Sie sich für GitHub Actions entscheiden, klicken Sie auf Autorisieren, und befolgen Sie die Eingabeaufforderungen zur Autorisierung. Wenn Sie die Autorisierung schon einmal mit GitHub durchgeführt haben, können Sie die Bereitstellung über das Repository eines anderen Benutzers ausführen, indem Sie auf Konto ändern klicken.

Nachdem Sie Ihr Azure-Konto bei GitHub autorisiert haben, wählen Sie das Unternehmen, das Repository und den Branch aus, über die Sie die Bereitstellung vornehmen möchten.

2. Konfigurieren der Registrierungseinstellungen

3. Konfigurieren der Registrierungseinstellungen

Wählen Sie zum Bereitstellen einer App mit mehreren Containern (Docker Compose) unter Containertyp die Option Docker Compose aus.

Wird das Dropdownmenü Containertyp nicht angezeigt, müssen Sie zurück zu Quelltext scrollen und Container Registry auswählen.

3. Aktivieren von CI/CD

4. Aktivieren von CI/CD

4. Speichern der Einstellungen

5. Speichern der Einstellungen

Funktionsweise von CI/CD mit GitHub Actions

Wenn Sie unter Quelltext die Option GitHub Actions auswählen (siehe Auswählen der Bereitstellungsquelle), richtet App Service CI/CD auf folgende Weise ein:

• Legt eine GitHub Actions-Workflowdatei in Ihrem GitHub-Repository ab, um Build- und Bereitstellungsaufgaben für App Service zu verarbeiten.
• Fügt die Anmeldeinformationen für Ihre private Registrierung als GitHub-Geheimnisse hinzu. Die generierte Workflowdatei führt die Aktion Azure/docker-login aus, um sich bei Ihrer privaten Registrierung anzumelden, und führt dann docker push für die Bereitstellung aus.
• Fügt das Veröffentlichungsprofil für Ihre App als GitHub-Geheimnis hinzu. Die generierte Workflowdatei verwendet dieses Geheimnis für die Authentifizierung bei App Service und führt dann die Aktion Azure/webapps-deploy aus, um das aktualisierte Image zu konfigurieren. Dadurch wird ein App-Neustart ausgelöst, um das aktualisierte Image abzurufen.
• Erfasst Informationen aus den Workflowausführungsprotokollen und zeigt sie auf der Registerkarte Protokolle im Deployment Center Ihrer App an.

Sie können den GitHub Actions-Buildanbieter auf folgende Weise anpassen:

• Anpassen der Workflowdatei, nachdem Sie in Ihrem GitHub-Repository generiert wurde. Weitere Informationen finden Sie unter Workflowsyntax für GitHub Actions. Stellen Sie unbedingt sicher, dass der Workflow mit der Aktion Azure/webapps-deploy endet, um einen App-Neustart auszulösen.
• Wenn der ausgewählte Branch geschützt ist, können Sie trotzdem eine Vorschau der Workflowdatei anzeigen, ohne die Konfiguration zu speichern, und sie dann zusammen mit den erforderlichen GitHub-Geheimnissen manuell zu Ihrem Repository hinzufügen. Diese Methode verschafft Ihnen nicht die Protokollintegration in das Azure-Portal.
• Anstatt ein Veröffentlichungsprofil zu verwenden, führen Sie die Bereitstellung mithilfe eines Dienstprinzipals in Microsoft Entra ID durch.

Authentifizieren mit einem Dienstprinzipal

Diese optionale Konfiguration ersetzt die Standardauthentifizierung mit Veröffentlichungsprofilen in der generierten Workflowdatei.

Generieren Sie in der Azure CLI mit dem Befehl az ad sp create-for-rbac einen Dienstprinzipal. Ersetzen Sie im folgenden Beispiel <subscription-id>, <group-name> und <app-name> durch Ihre eigenen Werte. Speichern Sie die gesamte JSON-Ausgabe für den nächsten Schritt, einschließlich der {}-Objekte der obersten Ebene.

az ad sp create-for-rbac --name "myAppDeployAuth" --role contributor \
                            --scopes /subscriptions/<subscription-id>/resourceGroups/<group-name>/providers/Microsoft.Web/sites/<app-name> \
                            --json-auth

Navigieren Sie in GitHub zu Ihrem Repository, und wählen Sie Einstellungen > Geheimnisse > Neues Geheimnis hinzufügen aus. Fügen Sie die gesamte JSON-Ausgabe aus dem Azure CLI-Befehl in das Wertfeld des Geheimnisses ein. Geben Sie dem Geheimnis einen Namen wie AZURE_CREDENTIALS.

Ändern Sie in der Workflowdatei, die vom Bereitstellungscenter generiert wurde, den Schritt azure/webapps-deploy mit Code wie im folgenden Beispiel:

- name: Sign in to Azure 
# Use the GitHub secret you added
- uses: azure/login@v1
    with:
    creds: ${{ secrets.AZURE_CREDENTIALS }}
- name: Deploy to Azure Web App
# Remove publish-profile
- uses: azure/webapps-deploy@v2
    with:
    app-name: '<app-name>'
    slot-name: 'production'
    images: '<registry-server>/${{ secrets.AzureAppService_ContainerUsername_... }}/<image>:${{ github.sha }}'
    - name: Sign out of Azure
    run: |
    az logout

Bereiten Sie zum Konfigurieren einer App mit mehreren Containern eine Docker Compose-Datei vor, und führen Sie az webapp config container set mit dem --multicontainer-config-file-Parameter aus. Wenn Ihre Docker Compose-Datei private Images enthält, fügen Sie, wie im vorherigen Beispiel gezeigt, --docker-registry-server-*-Parameter hinzu.

az webapp config container set --resource-group <group-name> --name <app-name> --multicontainer-config-file <docker-compose-file>