Freigeben über


Continuous Deployment mit benutzerdefinierten Containern in Azure App Service

In diesem Artikel wird erläutert, wie Sie eine kontinuierliche Integration und kontinuierliche Übermittlung (CI/CD) für ein benutzerdefiniertes Containerimage aus verwalteten Azure Container Registry-Repositorys oder Docker Hub konfigurieren.

1. Wechseln Sie zum Bereitstellungscenter

Wechseln Sie im Azure-Portal zum Verwaltungsbereich für Ihre Azure App Service-App.

Wählen Sie im Randleistenmenü unter "Bereitstellung" die Option "Bereitstellungscenter" aus. Wählen Sie die Registerkarte Einstellungen aus.

2. Codequelle auswählen

Wählen Sie im Dropdownmenü " Quelle " die Bereitstellungsquelle basierend auf den folgenden Kriterien aus:

  • Die Container-Registry richtet CI/CD zwischen Ihrer Container-Registry und dem App Service ein.
  • Wählen Sie die Option "GitHub-Aktionen " aus, wenn Sie den Quellcode für Ihr Containerimage in GitHub verwalten. Neue Commits für Ihr GitHub-Repository lösen die Bereitstellungsaktion aus, die docker build und docker push direkt in Ihrer Containerregistrierung ausführen kann. Anschließend wird Ihre App Service-App aktualisiert, 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.
  • Wählen Sie für eine Docker Compose-App Containerregistrierung aus.

Wenn Sie GitHub-Aktionen auswählen, wählen Sie "Autorisieren" aus, und folgen Sie den Autorisierungsaufforderungen. Wenn Sie zuvor mit GitHub autorisiert wurden, können Sie das Repository eines anderen Benutzers bereitstellen, indem Sie "Konto ändern" auswählen.

Nachdem Sie Ihr Azure-Konto mit GitHub autorisiert haben, wählen Sie die Organisations-, Repository- und Branch-Option aus, aus der Sie bereitstellen möchten.

2. Konfigurieren der Registrierungseinstellungen

3. Konfigurieren der Registrierungseinstellungen

Hinweis

Sidecar-Container sind mit Mehrcontainer-Apps (Docker Compose) in App Service erfolgreich. Um loszulegen, sehen Sie sich das Lernprogramm: Konfigurieren eines Sidecar-Containers für benutzerdefinierte Container in Azure App Service an.

Um eine Multicontainer-App (Docker Compose) bereitzustellen, wählen Sie Docker Compose im Containertyp aus.

Wenn die Dropdownliste " Containertyp " nicht angezeigt wird, scrollen Sie zurück zur Quelle , und wählen Sie "Containerregistrierung" aus.

Wählen Sie in der Registrierungsquelle aus, wo sich Ihre Containerregistrierung befindet. Wenn es sich nicht um azure Container Registry oder Docker Hub handelt, wählen Sie private Registrierung aus.

Hinweis

Wenn Ihre Multicontainer-App (Docker Compose) mehr als ein privates Image verwendet, stellen Sie sicher, dass sich die privaten Images in derselben privaten Registrierung befinden und mit denselben Benutzeranmeldeinformationen darauf zugreifen können. Wenn Ihre Multi-Container-App nur öffentliche Images verwendet, wählen Sie Docker Hub aus, auch wenn einige Images nicht im Docker Hub vorhanden sind.

Wählen Sie die Registerkarte, die Ihrer Wahl entspricht, und folgen Sie den nächsten Schritten.

In der Dropdownliste " Registrierung " werden die Registrierungen im selben Abonnement wie Ihre App angezeigt. Wählen Sie die gewünschte Registrierung aus.

Wenn Sie eine Registrierung in einem anderen Abonnement bereitstellen möchten, wählen Sie stattdessen private Registrierung in Registrierungsquelle aus.

Informationen zur Verwendung verwalteter Identitäten zum Sperren des Azure Container Registry-Zugriffs finden Sie unter:

Wählen Sie das bereitzustellende Image und Tag aus. Sie können den Startbefehl in der Startdatei eingeben.

Führen Sie den nächsten Schritt abhängig vom Wert des Containertyps aus:

  • Wählen Sie für Docker Compose die Registrierung für Ihre privaten Images aus. Wählen Sie "Datei auswählen ", um Ihre Docker Compose-Datei hochzuladen, oder fügen Sie einfach den Inhalt Ihrer Docker Compose-Datei in "Config" ein.
  • Wählen Sie für einzelne Container das bereitzustellende Image und Tag aus. Sie können den Startbefehl in der Startdatei eingeben.

App Service fügt die Zeichenfolge unter Startdatei an das Ende des Befehls „docker run“ (als [COMMAND] [ARG...]-Segment) an, wenn Ihr Container gestartet wird.

3. Aktivieren von CI/CD

4. Aktivieren von CI/CD

App Service unterstützt die CI/CD-Integration mit Azure Container Registry und Docker Hub. Um die CI/CD-Integration zu aktivieren, wählen Sie „Ein“ in der kontinuierlichen Bereitstellung aus.

Hinweis

Wenn Sie GitHub-Aktionen in der Quelle auswählen, wird diese Option nicht angezeigt, da CI/CD direkt von GitHub-Aktionen behandelt wird. Stattdessen wird ein Abschnitt " Workflowkonfiguration " angezeigt, in dem Sie die Vorschaudatei auswählen können, um die Workflowdatei zu prüfen. Azure überträgt diese Datei in Ihr ausgewähltes GitHub-Repository, um Build- und Bereitstellungsaufgaben zu verwalten. Weitere Informationen finden Sie unter Funktionsweise von CI/CD mit GitHub Actions.

Wenn Sie diese Option aktivieren, fügt App Service Ihrem Repository in Azure Container Registry oder Docker Hub einen Webhook hinzu. Ihr Repository veröffentlicht immer an diesen Webhook, wenn Ihr ausgewähltes Image mit docker push aktualisiert wird. Der Webhook bewirkt, dass Ihre App Service-App neu gestartet wird und docker pull ausführt, um das aktualisierte Image abzurufen.

Um eine ordnungsgemäße Funktion des Webhooks sicherzustellen, ist es wichtig, die Option für die Veröffentlichungsanmeldeinformationen für die Standardauthentifizierung in Ihrer Web App zu aktivieren. Andernfalls erhalten Sie möglicherweise den Fehler „401 - Nicht autorisiert“ für den Webhook.

Um zu überprüfen, ob die Standardanmeldeinformationen für die Authentifizierung aktiviert sind, wechseln Sie zu den allgemeinen Konfigurationseinstellungen> Ihrer Web-App. Suchen Sie nach dem Abschnitt "Plattformeinstellung ", und wählen Sie dann die Option " Standard-Auth-Veröffentlichungsanmeldeinformationen " aus.

Bei anderen privaten Registrierungen können Sie den Webhook manuell oder als Schritt einer CI/CD-Pipeline veröffentlichen. Wählen Sie in der Webhook-URL die Schaltfläche "Kopieren " aus, um die Webhook-URL abzurufen.

Klicken Sie auf Save (Speichern), um Ihre Einstellungen zu speichern.

Hinweis

Die Unterstützung für Apps mit mehreren Containern (Docker Compose) ist eingeschränkt. Für Azure Container Registry erstellt App Service einen Webhook in der ausgewählten Registrierung, der nur für diese Registrierung gilt. Ein docker push-Befehl für eines der Repositorys in der Registrierung (einschließlich derjenigen, auf die nicht in Ihrer Docker Compose-Datei verwiesen wird) löst einen Neustart der App aus. Möglicherweise möchten Sie den Webhook in einen schmaleren Bereich ändern. Docker Hub unterstützt keine Webhooks auf Registrierungsebene. Sie müssen die Webhooks manuell zu den in Ihrer Docker Compose-Datei angegebenen Images hinzufügen.

Funktionsweise von CI/CD mit GitHub Actions

Wenn Sie GitHub-Aktionen aus dem Dropdownmenü " Quellcode auswählen " auswählen, richtet App Service CI/CD wie folgt ein:

  • Es legt eine GitHub Actions-Workflowdatei in Ihrem GitHub-Repository ab, um Build- und Bereitstellungsaufgaben für den App Service zu erledigen.
  • Sie fügt die Anmeldeinformationen für Ihre private Registrierung als GitHub-Geheimschlüssel hinzu. Die generierte Workflow-Datei führt die Azure/docker-login Aktion aus, um sich bei Ihrem privaten Registry anzumelden, und führt dann docker push aus, um dort zu deployen.
  • Es fügt das Veröffentlichungsprofil für Ihre App als GitHub-Geheimnis hinzu. Die generierte Workflowdatei verwendet diesen geheimen Schlüssel, um sich bei App Service zu authentifizieren, und führt dann die Azure/webapps-deploy Aktion aus, um das aktualisierte Image zu konfigurieren, wodurch ein App-Neustart ausgelöst wird, um das aktualisierte Image abzurufen.
  • Sie erfasst Informationen aus den Workflowausführungsprotokollen und zeigt sie auf der Registerkarte "Protokolle " im Bereitstellungscenter Ihrer App an.

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

  • Passen Sie die Workflowdatei an, nachdem sie in Ihrem GitHub-Repository generiert wurde. Weitere Informationen finden Sie unter Workflowsyntax für GitHub Actions. Der Workflow muss mit der Azure/webapps-deploy Aktion enden, um einen App-Neustart auszulösen.
  • Wenn die ausgewählte Verzweigung geschützt ist, können Sie die Workflowdatei weiterhin anzeigen, ohne die Konfiguration zu speichern. Fügen Sie es und die erforderlichen GitHub-Geheimnisse manuell in Ihr Repository ein. Bei dieser Methode erfolgt keine 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 einen Dienstprinzipal mithilfe des az ad sp create-for-rbac Befehls in der Azure CLI. 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 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

Wichtig

Erteilen Sie aus Sicherheitsgründen dem Dienstprinzipal den minimal erforderlichen Zugriff. Der Bereich im vorherigen Beispiel ist auf die spezifische App Service-App und nicht auf die gesamte Ressourcengruppe beschränkt.

Wechseln Sie in GitHub zu Ihrem Repository, und wählen Sie dann "Einstellungen>geheime Schlüssel>hinzufügen" aus. Fügen Sie die gesamte JSON-Ausgabe aus dem Azure CLI-Befehl in das Wertfeld des Geheimnisses ein. Geben Sie dem Geheimen 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

Automatisieren mithilfe der Befehlszeilenschnittstelle

Führen Sie az webapp config container set aus, um die Containerregistrierung und das Docker-Abbild zu konfigurieren.

az webapp config container set --name <app-name> --resource-group <group-name> --docker-custom-image-name '<image>:<tag>' --docker-registry-server-url 'https://<registry-name>.azurecr.io' --docker-registry-server-user '<username>' --docker-registry-server-password '<password>'

Um eine Multicontainer-App (Docker Compose) zu konfigurieren, bereiten Sie eine Docker Compose-Datei lokal vor, und führen Sie dann az webapp config container set mit dem Parameter --multicontainer-config-file aus. Wenn Ihre Docker Compose-Datei private Images enthält, fügen Sie --docker-registry-server-* Parameter hinzu, wie im vorherigen Beispiel gezeigt.

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

Um CI/CD aus der Containerregistrierung für Ihre App zu konfigurieren, führen Sie az webapp deployment container config mit dem Parameter --enable-cd aus. Der Befehl gibt die Webhook-URL aus. Sie müssen den Webhook jedoch in einem separaten Schritt manuell in der Registrierung erstellen. Im folgenden Beispiel wird CI/CD in Ihrer App aktiviert und anschließend die Webhook-URL in der Ausgabe verwendet, um den Webhook in der Azure-Containerregistrierung zu erstellen.

ci_cd_url=$(az webapp deployment container config --name <app-name> --resource-group <group-name> --enable-cd true --query CI_CD_URL --output tsv)

az acr webhook create --name <webhook-name> --registry <registry-name> --resource-group <group-name> --actions push --uri $ci_cd_url --scope '<image>:<tag>'