Best Practices für die Bereitstellung

Jedes Entwicklungsteam verfügt über spezifische Anforderungen, die die Implementierung einer effizienten Bereitstellungspipeline in einem beliebigen Clouddienst erschweren können. In diesem Artikel werden die drei Hauptkomponenten der Bereitstellung in Azure App Service vorgestellt: Bereitstellungsquellen, Buildpipelines und Bereitstellungsmechanismen. Dieser Artikel behandelt außerdem einige bewährte Methoden und Tipps für bestimmte Sprachenstapel.

Bereitstellungskomponenten

In diesem Abschnitt werden die drei Hauptkomponenten der Bereitstellung in App Service beschrieben.

Bereitstellungsquelle

Eine Bereitstellungsquelle ist der Speicherort Ihres Anwendungscodes. Bei Produktions-Apps handelt es sich bei der Bereitstellungsquelle normalerweise um ein Repository, das von Software zur Versionskontrolle wie GitHub, Bitbucket oder Azure Repos gehostet wird. Bei Dev/Test-Szenarien kann die Bereitstellungsquelle ein Projekt auf Ihrem lokalen Computer sein.

Buildpipeline

Sobald Sie sich für eine Bereitstellungsquelle entschieden haben, besteht Ihr nächster Schritt in der Auswahl einer Buildpipeline. Eine Buildpipeline liest Ihren Quellcode aus der Bereitstellungsquelle und führt eine Reihe von Schritten aus, um die Anwendung in einen ausführbaren Zustand zu bringen.

Die Schritte können das Kompilieren von Code, das Minimieren von HTML und JavaScript, das Ausführen von Tests und das Packen von Komponenten umfassen. Die von der Buildpipeline ausgeführten spezifischen Befehle hängen von Ihrem Sprachenstapel ab. Sie können diese Vorgänge auf einem Buildserver, z. B. Azure Pipelines, oder lokal ausführen.

Bereitstellungsmechanismus

Der Bereitstellungsmechanismus ist die Aktion, mit der Ihre erstellte Anwendung im Verzeichnis /home/site/wwwroot Ihrer Web-App abgelegt wird. Das Verzeichnis /wwwroot ist ein eingebundener Speicherort, der von allen Instanzen Ihrer Web-App gemeinsam verwendet wird. Wenn der Bereitstellungsmechanismus Ihre Anwendung in diesem Verzeichnis ablegt, erhalten Ihre Instanzen eine Benachrichtigung, um sich mit den neuen Dateien zu synchronisieren.

App Service unterstützt die folgenden Bereitstellungsmechanismen:

• Kudu-Endpunkte: Kudu ist das Open Source-Produktivitätstool für Entwickler, das in Windows App Service als gesonderter Prozess ausgeführt wird. Es wird in Linux App Service als zweiter Container ausgeführt. Kudu verarbeitet fortlaufende Bereitstellungen und bietet HTTP-Endpunkte für die Bereitstellung, z. B. zipdeploy.
• FTP und WebDeploy: Unter Verwendung Ihrer Website- oder Benutzeranmeldeinformationen können Sie Dateien über FTP oder WebDeploy hochladen. Diese Mechanismen durchlaufen nicht Kudu.

Bereitstellungstools wie Azure Pipelines, Jenkins und Editor-Plug-Ins verwenden einen dieser Bereitstellungsmechanismen.

Verwenden von Bereitstellungsslots

Verwenden Sie nach Möglichkeit immer Bereitstellungsslots beim Bereitstellen eines neuen Produktionsbuilds. Mit einem App Service-Plantarif „Standard“ oder besser können Sie Ihre App in einer Stagingumgebung bereitstellen, Ihre Änderungen überprüfen und Buildüberprüfungstests durchführen. Wenn Sie bereit sind, tauschen Sie Ihre Staging- und Produktionsslots gegeneinander aus. Durch den Tauschvorgang werden die erforderlichen Workerinstanzen kontrolliert auf Ihr Produktionsniveau gebracht, wodurch Ausfallzeiten beseitigt werden.

Kontinuierliches Bereitstellen von Code

Wenn Ihr Projekt für Tests, QA und Staging vorgesehene Branches aufweist, sollte jeder dieser Branches kontinuierlich in einem Stagingslot bereitgestellt werden. Dieser Ansatz wird als Gitflow-Design bezeichnet. Dieses Design ermöglicht es den Projektbeteiligten, den bereitgestellten Branch einfach zu bewerten und zu testen.

Continuous Deployment sollte nie für Ihren Produktionsslot aktiviert werden. Stattdessen sollte Ihr Produktionsbranch (häufig der Hauptbranch) in einem Nicht-Produktionsslot bereitgestellt werden. Wenn Sie bereit sind, den Basisbranch freizugeben, tauschen Sie ihn in den Produktionsslot. Der Austausch in die Produktion, anstatt in der Produktion bereitzustellen, verhindert Ausfallzeiten und ermöglicht es Ihnen, ein Rollback der Änderungen auszuführen, indem Sie einen erneuten Austausch vornehmen.

Kontinuierliches Bereitstellen von Containern

Stellen Sie für benutzerdefinierte Container aus Docker oder anderen Containerregistrierungen das Image in einem Stagingslot bereit, und tauschen Sie in die Produktion, um Ausfallzeiten zu vermeiden. Die Automatisierung ist komplexer als die Codebereitstellung. Sie müssen das Image in eine Containerregistrierung pushen und das Imagetag in der „webapp“ aktualisieren.

Richten Sie für jeden Branch, den Sie in einem Slot bereitstellen möchten, eine Automatisierung ein, um bei jedem Commit in den Branch diese Aufgaben durchzuführen.

1. Erstellen Sie das Image, und kennzeichnen Sie es. Kennzeichnen Sie das Image als Teil der Buildpipeline mit der Git-Commit-ID, dem Zeitstempel oder anderen identifizierbaren Informationen. Es ist am besten, nicht das standardmäßige Tag Latest zu verwenden. Andernfalls ist es schwierig nachzuverfolgen, welcher Code aktuell bereitgestellt ist, was das Debuggen erschwert.
2. Pushen Sie das gekennzeichnete Image. Nachdem das Image erstellt und gekennzeichnet wurde, pusht die Pipeline das Image in die Containerregistrierung. Im nächsten Schritt pullt der Bereitstellungsslot das gekennzeichnete Image aus der Containerregistrierung.
3. Aktualisieren Sie den Bereitstellungsslot mit dem neuen Imagetag. Wenn diese Eigenschaft aktualisiert wird, startet die Site automatisch neu und pullt das neue Containerimage.

Dieser Artikel enthält Beispiele für gängige Automatisierungs-Frameworks.

Verwenden von Azure DevOps

App Service verfügt über integrierte Continuous Delivery für Container über das Bereitstellungscenter. Navigieren Sie im Azure-Portal zu Ihrer App. Klicken Sie unter Bereitstellung auf Bereitstellungscenter. Befolgen Sie die Anweisungen, um Ihr Repository und den Branch auszuwählen. Bei diesem Ansatz wird eine DevOps-Build- und -Releasepipeline so konfiguriert, dass Ihr Container automatisch erstellt, gekennzeichnet und bereitgestellt wird, wenn neue Commits in den ausgewählten Branch gepusht werden.

Verwenden von GitHub Actions

Sie können Ihre Containerbereitstellung auch mit GitHub Actions automatisieren. Die Workflowdatei erstellt und kennzeichnet den Container mit der Commit-ID, pusht ihn in eine Containerregistrierung und aktualisiert die angegebene Web-App mit dem neuen Imagetag.

on:
  push:
    branches:
    - <your-branch-name>

name: Linux_Container_Node_Workflow

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
    # checkout the repo
    - name: 'Checkout GitHub Action'
      uses: actions/checkout@main

    - uses: azure/docker-login@v1
      with:
        login-server: contoso.azurecr.io
        username: ${{ secrets.REGISTRY_USERNAME }}
        password: ${{ secrets.REGISTRY_PASSWORD }}

    - run: |
        docker build . -t contoso.azurecr.io/nodejssampleapp:${{ github.sha }}
        docker push contoso.azurecr.io/nodejssampleapp:${{ github.sha }} 

    - uses: azure/webapps-deploy@v2
      with:
        app-name: 'node-rnc'
        publish-profile: ${{ secrets.azureWebAppPublishProfile }}
        images: 'contoso.azurecr.io/nodejssampleapp:${{ github.sha }}'

Verwenden anderer Automatisierungsanbieter

Die oben aufgeführten Schritte gelten für andere Automatisierungshilfsprogramme wie CircleCI oder Travis CI. Im letzten Schritt müssen Sie allerdings Azure CLI verwenden, um die Bereitstellungsslots mit neuen Imagetags zu aktualisieren. Generieren Sie mithilfe des folgenden Befehls einen Dienstprinzipal, um Azure CLI in Ihrem Automatisierungsskript zu verwenden.

az ad sp create-for-rbac --name "myServicePrincipal" --role contributor \
   --scopes /subscriptions/{subscription}/resourceGroups/{resource-group} \
   --sdk-auth

Melden Sie sich in Ihrem Skript mit az login --service-principal an, und geben Sie dabei die Informationen des Prinzipals an. Anschließend können Sie az webapp config container set verwenden, um den Containernamen, das Tag, die Registrierungs-URL und das Registrierungskennwort festzulegen. Weitere Informationen finden Sie unter Anmelden bei der Azure CLI in Circle CI.

Sprachspezifische Erwägungen

Beachten Sie die folgenden Überlegungen für Java-, Node- und .NET-Implementierungen.

Java

Verwenden Sie die Kudu-API zipdeploy für die Bereitstellung von JAR-Anwendungen. Verwenden Sie wardeploy für WAR-Apps. Wenn Sie Jenkins verwenden, können Sie diese APIs direkt in der Bereitstellungsphase verwenden. Weitere Informationen finden Sie unter Bereitstellen in Azure App Service mit Jenkins.

Node

Standardmäßig führt Kudu die Buildschritte für Ihre Node-Anwendung (npm install) aus. Wenn Sie einen Builddienst wie Azure DevOps verwenden, ist der Kudu-Build unnötig. Um den Kudu-Build zu deaktivieren, erstellen Sie eine App-Einstellung SCM_DO_BUILD_DURING_DEPLOYMENT mit dem Wert false.

.NET

Standardmäßig führt Kudu die Buildschritte für Ihre .NET-Anwendung (dotnet build) aus. Wenn Sie einen Builddienst wie Azure DevOps verwenden, ist der Kudu-Build unnötig. Um den Kudu-Build zu deaktivieren, erstellen Sie eine App-Einstellung SCM_DO_BUILD_DURING_DEPLOYMENT mit dem Wert false.

Sonstige Überlegungen zur Bereitstellung

Weitere Überlegungen umfassen den lokalen Cache und die hohe CPU- oder der Arbeitsspeicherauslastung.

Lokaler Cache

Azure App Service-Inhalt wird in Azure Storage gespeichert und dauerhaft als Inhaltsfreigabe bereitgestellt. Manche Apps benötigen jedoch lediglich einen hochleistungsfähigen, schreibgeschützten Inhaltsspeicher, aus dem sie mit Hochverfügbarkeit ausgeführt werden können. Diese Apps können von der Verwendung eines lokalen Caches profitieren. Weitere Informationen finden Sie in der Übersicht über den lokalen Cache von Azure App Service.

Um Ausfallzeiten zu verhindern, verwenden Sie immer einen lokalen Cache mit Bereitstellungsslots. Informationen zur Verwendung dieser Features in Kombination finden Sie unter Bewährte Methoden.

Hohe CPU- oder Arbeitsspeicherauslastung

Wenn Ihr App Service-Plan mehr als 90 % der verfügbaren CPU oder des Arbeitsspeichers verwendet, hat der zugrunde liegende virtuelle Computer möglicherweise Probleme beim Verarbeiten Ihrer Bereitstellung. Wenn dies der Fall ist, skalieren Sie die Anzahl Ihrer Instanzen vorübergehend hoch, um die Bereitstellung auszuführen. Nachdem die Bereitstellung abgeschlossen ist, können Sie die Anzahl der Instanzen auf den vorherigen Wert zurücksetzen.

Unter Azure App Service-Diagnose finden Sie weitere Informationen zu umsetzbaren bewährten Methoden, die für Ihre Ressource spezifisch sind.

1. Navigieren Sie im Azure-Portal zu Ihrer Web-App.

2. Wählen Sie im linken Navigationsbereich die Option Diagnose und Problembehandlung aus, um die App Service-Diagnose zu öffnen.

3. Wählen Sie die Option Verfügbarkeit und Leistung aus, oder erkunden Sie andere Optionen, z. B. Analyse hoher CPU-Auslastung.

   Zeigen Sie den aktuellen Zustand Ihrer App in Bezug auf diese bewährten Methoden an.

Sie können auch den folgenden Link nutzen, um die App Service-Diagnose für Ihre Ressource direkt zu öffnen: https://portal.azure.com/?websitesextension_ext=asd.featurePath%3Ddetectors%2FParentAvailabilityAndPerformance#@microsoft.onmicrosoft.com/resource/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Web/sites/{siteName}/troubleshoot.

Zugehöriger Inhalt

• Referenz zu Umgebungsvariablen und App-Einstellungen