Freigeben über

Bereitstellen und Konfigurieren einer Tomcat-, JBoss- oder Java SE-App in Azure App Service

  • Artikel

In diesem Artikel wird die am häufigsten verwendete Bereitstellungs- und Laufzeitkonfiguration für Java-Apps in App Service erläutert. Wenn Sie Azure App Service noch nie verwendet haben, lesen Sie zunächst den Java-Schnellstart. Allgemeine Fragen zur Verwendung von App Service, die sich nicht speziell auf die Java-Entwicklung beziehen, werden unter Häufig gestellte Fragen (FAQ) zu App Service beantwortet.

Azure App Service führt Java-Webanwendungen auf einem vollständig verwalteten Dienst in drei Varianten aus:

  • Java SE: Kann eine App ausführen, die als JAR-Paket bereitgestellt wird, das einen eingebetteten Server enthält (z. B. Spring Boot, Dropwizard, Quarkus oder eine App mit einem eingebetteten Tomcat- oder Jetty-Server).
  • Tomcat: Der integrierte Tomcat-Server kann eine als WAR-Paket bereitgestellte App ausführen.
  • JBoss EAP: Wird nur für Linux-Apps in den Tarifen Premium v3 und Isolated v2 unterstützt. Der integrierte JBoss EAP-Server kann eine als WAR- oder EAR-Paket bereitgestellte App ausführen.

Hinweis

Für Spring-Anwendungen wird die Verwendung von Azure Spring Apps empfohlen. Sie können Azure App Service jedoch weiterhin als Ziel verwenden. Weitere Informationen finden Sie unter Java-Workload-Zielleitfaden.

Java-Version anzeigen

Führen Sie in Cloud Shell den folgenden Befehl aus, um die aktuelle Java-Version anzuzeigen:

az webapp config show --resource-group <resource-group-name> --name <app-name> --query linuxFxVersion

Führen Sie in Cloud Shell den folgenden Befehl aus, um alle unterstützten Java-Versionen anzuzeigen:

az webapp list-runtimes --os linux | grep "JAVA\|TOMCAT\|JBOSSEAP"

Weitere Informationen zur Versionsunterstützung finden Sie in der Supportrichtlinie für App Service-Sprachlaufzeiten.

Bereitstellen Ihrer App

Build-Tools

Maven

Mit demMaven Plugin für Azure Web Appskönnen Sie Ihr Maven-Java-Projekt auf einfache Weise für Azure-Web-Apps mit einem Befehl im Projektstamm vorbereiten:

mvn com.microsoft.azure:azure-webapp-maven-plugin:2.13.0:config

Dieser Befehl fügt das Plug-In azure-webapp-maven-plugin und eine zugehörige Konfiguration hinzu, indem Sie aufgefordert werden, eine vorhandene Azure-Web-App auszuwählen oder eine neue zu erstellen. Während der Konfiguration wird versucht, zu erkennen, ob Ihre Anwendung in Java SE, Tomcat oder (nur Linux) JBoss EAP bereitgestellt werden soll. Dann können Sie Ihre Java-App mit dem folgenden Befehl in Azure bereitstellen:

mvn package azure-webapp:deploy

Hier sehen Sie eine Beispielkonfiguration in pom.xml:

<plugin> 
  <groupId>com.microsoft.azure</groupId>  
  <artifactId>azure-webapp-maven-plugin</artifactId>  
  <version>2.11.0</version>  
  <configuration>
    <subscriptionId>111111-11111-11111-1111111</subscriptionId>
    <resourceGroup>spring-boot-xxxxxxxxxx-rg</resourceGroup>
    <appName>spring-boot-xxxxxxxxxx</appName>
    <pricingTier>B2</pricingTier>
    <region>westus</region>
    <runtime>
      <os>Linux</os>      
      <webContainer>Java SE</webContainer>
      <javaVersion>Java 17</javaVersion>
    </runtime>
    <deployment>
      <resources>
        <resource>
          <type>jar</type>
          <directory>${project.basedir}/target</directory>
          <includes>
            <include>*.jar</include>
          </includes>
        </resource>
      </resources>
    </deployment>
  </configuration>
</plugin>

Gradle

  1. Richten Sie das Gradle-Plug-In für Azure-Web-Apps ein, indem Sie das Plug-In Ihrem build.gradle hinzufügen:

    plugins {
  id "com.microsoft.azure.azurewebapp" version "1.10.0"
}

  2. Konfigurieren Sie die Details Ihrer Web-App. Die entsprechenden Azure-Ressourcen werden erstellt, wenn sie nicht vorhanden sind. Hier ist eine Beispielkonfiguration, Details finden Sie in diesem Dokument.

    azurewebapp {
    subscription = '<your subscription id>'
    resourceGroup = '<your resource group>'
    appName = '<your app name>'
    pricingTier = '<price tier like 'P1v2'>'
    region = '<region like 'westus'>'
    runtime {
      os = 'Linux'
      webContainer = 'Tomcat 10.0' // or 'Java SE' if you want to run an executable jar
      javaVersion = 'Java 17'
    }
    appSettings {
        <key> = <value>
    }
    auth {
        type = 'azure_cli' // support azure_cli, oauth2, device_code and service_principal
    }
}

  3. Installieren mit einem Befehl.

    gradle azureWebAppDeploy

IDEs

Azure bietet nahtlose Java App Service-Entwicklungserfahrung in gängigen Java-IDEs, einschließlich:

Kudu-API

Um JAR-Dateien in Java SE bereitzustellen, verwenden Sie den /api/publish-Endpunkt der Kudu-Website. Weitere Informationen zu dieser API finden Sie in dieser Dokumentation.

Hinweis

Ihre JAR-Anwendung muss mit app.jar benannt werden, damit App Service die Anwendung identifizieren und ausführen kann. Das Maven-Plug-In nimmt diese Umbenennung während der Bereitstellung automatisch vor. Wenn Sie Ihre JAR-Datei nicht in app.jar umbenennen möchten, können Sie ein Shellskript mit dem Befehl zum Ausführen Ihrer JAR-Datei hochladen. Fügen Sie den absoluten Pfad zu diesem Skript im Abschnitt „Konfiguration“ des Portals in das Textfeld Startdatei ein. Das Startskript wird nicht aus dem Verzeichnis ausgeführt, in dem es platziert wurde. Verwenden Sie daher immer absolute Pfade, um auf Dateien in Ihrem Startskript zu verweisen (z. B.: java -jar /home/myapp/myapp.jar).

Um WAR-Dateien in Tomcat bereitzustellen, verwenden Sie den /api/wardeploy/-Endpunkt, um Ihre Archivdatei mit POST zu veröffentlichen. Weitere Informationen zu dieser API finden Sie in dieser Dokumentation.

Um WAR-Dateien in JBoss bereitzustellen, verwenden Sie den /api/wardeploy/-Endpunkt, um Ihre Archivdatei mit POST zu veröffentlichen. Weitere Informationen zu dieser API finden Sie in dieser Dokumentation.

Zum Bereitstellen von EAR-Dateien verwenden Sie FTP. Ihre EAR-Anwendung wird im Kontextstamm bereitgestellt, der in der Konfiguration Ihrer Anwendung definiert ist. Wenn der Kontextstamm Ihrer App beispielsweise <context-root>myapp</context-root> ist, können Sie die Site unter diesem /myapp-Pfad durchsuchen: http://my-app-name.azurewebsites.net/myapp. Wenn Sie möchten, dass Ihre Web-App im Stammpfad bedient wird, stellen Sie sicher, dass Ihre App den Kontextstamm auf den Stammpfad festlegt: <context-root>/</context-root>. Weitere Informationen finden Sie unter Festlegen des Kontextstamms einer Webanwendung.

Stellen Sie Ihre WAR- oder JAR-Dateien nicht über FTP bereit. Der FTP-Tool dient zum Hochladen von Startskripts, Abhängigkeiten oder anderen Laufzeitdateien. Dies ist nicht die optimale Wahl für die Bereitstellung von Web-Apps.

Umschreiben oder Umleitungen einer URL

Verwenden Sie zum Umschreiben oder Umleiten einer URL den verfügbaren URL-Rewriter, z. B. UrlRewriteFilter.

Tomcat bietet auch ein Umschreibventil.

JBoss bietet auch ein Umschreibventil.

Protokollieren und Debuggen von Apps

Leistungsberichte, Datenverkehrsvisualisierungen und Integritätsprüfungen für die einzelnen Apps stehen über das Azure-Portal zur Verfügung. Weitere Informationen hierzu finden Sie unter Azure App Service-Pläne – Diagnoseübersicht.

Streamen von Diagnoseprotokollen

Sie können auf die Konsolenprotokolle zugreifen, die aus dem Container generiert werden.

Aktivieren Sie zuerst Containerprotokollierung, indem Sie den folgenden Befehl ausführen:

az webapp log config --name <app-name> --resource-group <resource-group-name> --docker-container-logging filesystem

Ersetzen Sie <app-name> und <resource-group-name> durch die entsprechenden Namen für Ihre Web-App.

Führen Sie den folgenden Befehl aus, um den Protokolldatenstrom anzuzeigen, nachdem die Containerprotokollierung aktiviert wurde:

az webapp log tail --name <app-name> --resource-group <resource-group-name>

Falls Sie nicht sofort Konsolenprotokolle sehen, können Sie es nach 30 Sekunden noch einmal versuchen.

Zum Beenden des Protokollstreamings können Sie jederzeit STRG+C drücken.

Sie können die Protokolldateien auch in einem Browser unter https://<app-name>.scm.azurewebsites.net/api/logs/docker untersuchen.

Weitere Informationen finden Sie unter Streamen von Protokollen in Cloud Shell.

SSH-Konsolenzugriff in Linux

Um eine direkte SSH-Sitzung mit Ihrem Container zu öffnen, sollte Ihre App ausgeführt werden.

Fügen Sie die folgende URL in Ihren Browser ein, und ersetzen Sie <app-name> durch den Namen Ihrer App:

https://<app-name>.scm.azurewebsites.net/webssh/host

Wenn Sie noch nicht authentifiziert sind, müssen Sie sich mit Ihrem Azure-Abonnement für die Verbindung authentifizieren. Nach der Authentifizierung wird im Browser eine Shell angezeigt, über die Sie Befehle innerhalb Ihres Containers ausführen können.

SSH-Verbindung

Hinweis

Alle Änderungen, die Sie, außerhalb des Verzeichnisses /home vornehmen, werden im Container selbst gespeichert und bleiben nicht über einen Neustart der App hinaus erhalten.

Informationen zum Öffnen einer SSH-Remotesitzung von Ihrem lokalen Computer aus finden Sie unter Öffnen einer SSH-Sitzung per Remote-Shell.

Problembehandlungstools für Linux

Die integrierten Java-Images basieren auf dem Alpine Linux-Betriebssystem. Verwenden Sie den apk-Paket-Manager zur Installation von Tools oder Befehlen zur Problembehandlung.

Java Profiler

Alle Java-Runtimes auf Azure App Service verfügen über den JDK Flight Recorder für die Profilerstellung von Java-Workloads. Sie können damit JVM-, System- und Anwendungsereignisse aufzeichnen und Probleme in Ihren Anwendungen beheben.

Weitere Informationen zum Java Profiler finden Sie in der Dokumentation zu Azure Application Insights.

Flight Recorder

Alle Java-Runtimes in App Service enthalten Java Flight Recorder. Sie können damit JVM-, System- und Anwendungsereignisse aufzeichnen und Probleme in Ihren Java-Anwendungen beheben.

Stellen Sie eine SSH-Verbindung mit Ihrem App Service her, und führen Sie den jcmd-Befehl aus, um eine Liste aller laufenden Java-Prozesse zu sehen. Neben jcmd sollten Sie auch Ihre ausgeführte Java-Anwendung mit einer Prozess-ID (pid) sehen.

078990bbcd11:/home# jcmd
Picked up JAVA_TOOL_OPTIONS: -Djava.net.preferIPv4Stack=true
147 sun.tools.jcmd.JCmd
116 /home/site/wwwroot/app.jar

Führen Sie den folgenden Befehl aus, um eine 30-sekündige Aufzeichnung der JVM zu starten. Der Befehl erstellt ein Profil der JVM und eine JFR-Datei namens jfr_example.jfr im Stammverzeichnis. (Ersetzen Sie 116 mit der pid Ihrer Java-App.)

jcmd 116 JFR.start name=MyRecording settings=profile duration=30s filename="/home/jfr_example.jfr"

Während des 30-Sekunden-Intervalls können Sie überprüfen, ob die Aufnahme stattfindet, indem Sie jcmd 116 JFR.check ausführen. Der Befehl zeigt alle Aufzeichnungen für den angegebenen Java-Prozess an.

Fortlaufende Aufzeichnung

Sie können Java Flight Recorder verwenden, um mit minimalen Auswirkungen auf die Laufzeitleistung fortlaufend ein Profil Ihrer Java-Anwendung zu erstellen. Führen Sie dafür den folgenden Azure CLI-Befehl aus, um eine App-Einstellung namens JAVA_OPTS mit der notwendigen Konfiguration zu erschaffen. Der Inhalt der JAVA_OPTS-App-Einstellung wird an den java-Befehl übermittelt, wenn Ihre App gestartet wird.

az webapp config appsettings set -g <your_resource_group> -n <your_app_name> --settings JAVA_OPTS=-XX:StartFlightRecording=disk=true,name=continuous_recording,dumponexit=true,maxsize=1024m,maxage=1d

Nachdem die Aufzeichnung gestartet wurde, können Sie die aktuellen Aufzeichnungsdaten jederzeit mithilfe des JFR.dump-Befehls sichern.

jcmd <pid> JFR.dump name=continuous_recording filename="/home/recording1.jfr"

Analysieren von .jfr-Dateien

Verwenden Sie FTPS zum Herunterladen Ihrer JFR-Datei auf Ihren lokalen Computer. Laden Sie zum Analysieren der JFR-Datei das Tool Java Mission Control herunter, und installieren Sie es. Weitere Informationen zu Java Mission Control finden Sie in der JMC-Dokumentation und den Installationsanweisungen.

App-Protokollierung

Aktivieren Sie die Anwendungsprotokollierung über das Azure-Portal oder die Azure-Befehlszeilenschnittstelle, um App Service so zu konfigurieren, dass die Streams mit der Standardkonsolenausgabe und den Standardkonsolenfehlern Ihrer Anwendung in das lokale Dateisystem oder Azure Blob Storage geschrieben werden. Wenn Sie eine längere Beibehaltung benötigen, konfigurieren Sie die Anwendung für die Ausgabe in einen Blob Storage-Container.

Ihre Java- und Tomcat-App-Protokolle befinden sich im Verzeichnis /home/LogFiles/Application/ .

Die Protokollierung von Azure Blob Storage für Linux-basierte Apps kann nur mit Azure Monitor konfiguriert werden.

Wenn Ihre Anwendung Logback oder Log4j für die Ablaufverfolgung verwendet, können Sie diese Ablaufverfolgungen mithilfe der Konfigurationsanweisungen für das Protokollierungsframework unter Untersuchen von Java-Ablaufverfolgungsprotokollen in Application Insights zur Überprüfung an Azure Application Insights weiterleiten.

Hinweis

Aufgrund des bekannten Sicherheitsrisikos CVE-2021-44228 sollten Sie Log4j Version 2.16 oder höher verwenden.

Anpassung und Optimierung

Azure App Service unterstützt eine sofort verfügbare Optimierung und Anpassung über das Azure-Portal und die CLI. Lesen Sie die folgenden Artikel zur nicht Java-spezifischen Web-App-Konfiguration:

Lokales Kopieren von App-Inhalten

Legen Sie die App-Einstellung JAVA_COPY_ALL auf true fest, um Ihre App-Inhalte aus dem freigegebenen Dateisystem in den lokalen Worker zu kopieren. Diese Einstellung hilft beim Beheben von Problemen mit Dateisperren.

Festlegen von Java-Runtimeoptionen

Um reservierten Arbeitsspeicher oder andere JVM-Runtimeoptionen festzulegen, erstellen Sie mit den Optionen eine App-Einstellung mit dem Namen JAVA_OPTS. App Service übergibt diese Einstellung beim Start als Umgebungsvariable an die Java-Runtime.

Erstellen Sie im Azure-Portal unter Anwendungseinstellungen für die Web-App eine neue App-Einstellung namens JAVA_OPTS, welche andere Einstellungen enthält, z. B. -Xms512m -Xmx1204m.

Erstellen Sie im Azure-Portal unter Anwendungseinstellungen für die Web-App eine neue App-Einstellung namens CATALINA_OPTS, welche andere Einstellungen enthält, z. B. -Xms512m -Xmx1204m.

Um die App-Einstellung über das Maven-Plug-In zu konfigurieren, fügen Sie Einstellungs-/Werttags im Azure-Plug-In-Abschnitt hinzu. Im folgenden Beispiel werden bestimmte Mindest- und Höchstwerte für die Java-Heapgröße festgelegt:

<appSettings>
    <property>
        <name>JAVA_OPTS</name>
        <value>-Xms1024m -Xmx1024m</value>
    </property>
</appSettings>

Hinweis

Sie müssen keine web.config-Datei erstellen, wenn Sie Tomcat in Windows App Service verwenden.

Entwickler, die eine einzige Anwendung mit einem Bereitstellungsslot in ihrem App Service-Plan ausführen, können die folgenden Optionen verwenden:

  • B1- und S1-Instanzen: -Xms1024m -Xmx1024m
  • B2- und S2-Instanzen: -Xms3072m -Xmx3072m
  • B3- und S3-Instanzen: -Xms6144m -Xmx6144m
  • P1v2-Instanzen: -Xms3072m -Xmx3072m
  • P2v2-Instanzen: -Xms6144m -Xmx6144m
  • P3v2-Instanzen: -Xms12800m -Xmx12800m
  • P1v3-Instanzen: -Xms6656m -Xmx6656m
  • P2v3-Instanzen: -Xms14848m -Xmx14848m
  • P3v3-Instanzen: -Xms30720m -Xmx30720m
  • I1 Instanzen: -Xms3072m -Xmx3072m
  • I2 Instanzen: -Xms6144m -Xmx6144m
  • I3 Instanzen: -Xms12800m -Xmx12800m
  • I1v2-Instanzen: -Xms6656m -Xmx6656m
  • I2v2-Instanzen: -Xms14848m -Xmx14848m
  • I3v2-Instanzen: -Xms30720m -Xmx30720m

Überprüfen Sie beim Optimieren Ihrer Anwendungsheapeinstellungen Ihre App Service-Plandetails, und berücksichtigen Sie mehrere Anwendungs- und Bereitstellungsslotanforderungen, um die optimale Zuordnung von Arbeitsspeicher zu ermitteln.

Aktivieren von Websockets

Aktivieren Sie die Unterstützung für Websockets im Azure-Portal in den Anwendungseinstellungen für die Anwendung. Sie müssen die Anwendung neu starten, damit die Einstellung wirksam wird.

Aktivieren Sie die Websocketunterstützung über die Azure CLI mithilfe des folgenden Befehls:

az webapp config set --name <app-name> --resource-group <resource-group-name> --web-sockets-enabled true

Starten Sie Ihre Anwendung anschließend neu:

az webapp stop --name <app-name> --resource-group <resource-group-name>
az webapp start --name <app-name> --resource-group <resource-group-name>

Festlegen der Standardzeichencodierung

Erstellen Sie im Azure-Portal unter Anwendungseinstellungen für die Web-App eine neue App-Einstellung namens JAVA_OPTS mit dem Wert -Dfile.encoding=UTF-8.

Alternativ können Sie die App-Einstellung mit dem App Service-Maven-Plug-In konfigurieren. Fügen Sie die name- und value-Tags der Einstellung in der Plug-In-Konfiguration hinzu:

<appSettings>
    <property>
        <name>JAVA_OPTS</name>
        <value>-Dfile.encoding=UTF-8</value>
    </property>
</appSettings>

Vorkompilieren von JSP-Dateien

Zur Verbesserung der Leistung von Tomcat-Anwendungen können Sie die JSP-Dateien kompilieren, bevor sie in App Service bereitgestellt werden. Sie können das von Apache Sling bereitgestellte Maven-Plug-In oder diese Ant-Builddatei verwenden.

Hinweis

„robots933456“ in Protokollen

Möglicherweise wird die folgende Meldung in den Containerprotokollen angezeigt:

2019-04-08T14:07:56.641002476Z "-" - - [08/Apr/2019:14:07:56 +0000] "GET /robots933456.txt HTTP/1.1" 404 415 "-" "-"

Diese Meldung können Sie problemlos ignorieren. /robots933456.txt ist ein Dummy-URL-Pfad, den App Service verwendet, um zu überprüfen, ob der Container in der Lage ist, Anforderungen zu verarbeiten. Eine 404-Antwort zeigt lediglich an, dass der Pfad nicht vorhanden ist, informiert App Service aber darüber, dass der Container fehlerfrei und bereit ist, um auf Anforderungen zu antworten.

Auswählen einer Java Runtime-Version

App Service ermöglicht es Benutzer*innen, die JVM-Hauptversion (z. B. Java 8 oder Java 11) und die Patchversion (z. B. 1.8.0_232 oder 11.0.5) auszuwählen. Sie können auch festlegen, dass die Patchversion automatisch aktualisiert wird, sobald neue Nebenversionen verfügbar werden. In den meisten Fällen sollten Produktions-Apps angeheftete JVM-Patchversionen verwenden. Dadurch werden unerwartete Ausfälle während der automatischen Aktualisierung einer Patchversion verhindert. Alle Java-Web-Apps verwenden 64-Bit-JVMs, was nicht konfigurierbar ist.

Wenn Sie Tomcat verwenden, können Sie die Patchversion von Tomcat anheften. Unter Windows können Sie die Patchversionen von JVM und Tomcat unabhängig voneinander anheften. Unter Linux können Sie die Patchversion von Tomcat anheften. Die Patchversion der JVM wird ebenfalls angeheftet, ist aber nicht separat konfigurierbar.

Wenn Sie sich für das Anheften der Nebenversion entscheiden, müssen Sie die JVM-Nebenversion regelmäßig in der App aktualisieren. Um sicherzustellen, dass Ihre Anwendung mit der neueren Nebenversion funktioniert, erstellen Sie einen Stagingslot, und erhöhen Sie die Nebenversion im Stagingslot. Nachdem Sie bestätigt haben, dass die Anwendung mit der neuen Nebenversion ordnungsgemäß ausgeführt wird, können Sie den Stagingslot gegen den Produktionsslot austauschen.

Clustering

App Service unterstützt Clustering für JBoss EAP-Versionen ab 7.4.1. Zum Aktivieren des Clusterings muss Ihre Web-App in ein virtuelles Netzwerk integriert sein. Wenn die Web-App in ein virtuelles Netzwerk integriert ist, wird sie neu gestartet, und die JBoss EAP-Installation wird automatisch mit einer Clusterkonfiguration gestartet. Die JBoss EAP-Instanzen kommunizieren über das in der Integration des virtuellen Netzwerks angegebene Subnetz, wobei sie die Ports verwenden, die zur Laufzeit in der Umgebungsvariable WEBSITES_PRIVATE_PORTS angezeigt werden. Sie können das Clustering deaktivieren, indem Sie eine App-Einstellung namens WEBSITE_DISABLE_CLUSTERING mit einem beliebigen Wert erstellen.

Hinweis

Wenn Sie die Integration Ihres virtuellen Netzwerks mit einer Azure Resource Manager (ARM)-Vorlage aktivieren, müssen Sie die vnetPrivatePorts-Eigenschaft manuell auf den Wert 2 festlegen. Wenn Sie die Integration des virtuellen Netzwerks über die CLI oder das Portal aktivieren, wird diese Eigenschaft automatisch festgelegt.

Wenn Clustering aktiviert ist, verwenden die JBoss EAP-Instanzen das JGroups-Ermittlungsprotokoll „FILE_PING“, um neue Instanzen zu ermitteln und die Clusterinformationen wie die Clustermitglieder, deren Bezeichner sowie deren IP-Adressen dauerhaft zu speichern. In App Service befinden sich diese Dateien unter /home/clusterinfo/. Die erste zu startende EAP-Instanz erhält Lese-/Schreibberechtigungen für die Clustermitgliedschaftsdatei. Andere Instanzen lesen die Datei, suchen den primären Knoten und koordinieren sich mit diesem Knoten, damit sie in den Cluster aufgenommen und der Datei hinzugefügt werden.

Hinweis

Sie können JBOSS-Clusteringtimeouts vermeiden, indem Sie veraltete Ermittlungsdateien während des App-Startvorgangs bereinigen.

Die App Service-Plantypen „Premium V3“ und „Isoliert V2“ können optional auf Verfügbarkeitszonen verteilt werden, um die Resilienz und Zuverlässigkeit für Ihre geschäftskritischen Workloads zu verbessern. Diese Architektur wird auch als Zonenredundanz bezeichnet. Das Feature für JBoss EAP-Clustering ist mit der Zonenredundanzfunktion kompatibel.

Regeln für die Autoskalierung

Wenn Sie Autoskalierungsregeln für die horizontale Skalierung konfigurieren, ist es wichtig, dass Instanzen inkrementell (eine nach der anderen) entfernt werden, um sicherzustellen, dass jede entfernte Instanz ihre Aktivität (z. B. die Verarbeitung einer Datenbanktransaktion) an ein anderes Mitglied des Clusters übertragen kann. Wenn Sie Ihre Regeln für die automatische Skalierung im Portal für das Herunterskalieren konfigurieren, verwenden Sie die folgenden Optionen:

  • Vorgang: „Anzahl verringern um“
  • Abkühlen: „5 Minuten“ oder mehr
  • Instanzenanzahl: 1

Sie müssen Instanzen nicht inkrementell hinzufügen (Aufskalierung), sondern können mehrere Instanzen gleichzeitig zum Cluster hinzufügen.

App Service-Pläne

JBoss EAP ist in den folgenden Tarifen verfügbar: F1, P0v3, P1mv3, P2mv3, P3mv3, P4mv3 und P5mv3.

Tomcat-Baselinekonfiguration

Hinweis

Dieser Abschnitt gilt nur für Linux.

Java-Entwickler können die Servereinstellungen anpassen, Probleme beheben und Anwendungen in Tomcat guten Gewissens bereitstellen, wenn sie die server.xml-Datei- und Konfigurationsdetails von Tomcat kennen. Folgende Anpassungen sind möglich:

  • Anpassen der Tomcat-Konfiguration: Wenn Sie über grundlegende Kenntnisse der Konfigurationsdetails der Datei „server.xml“ und von Tomcat verfügen, können Sie die Servereinstellungen entsprechend den Anforderungen Ihrer Anwendungen optimieren.
  • Debuggen: Wenn eine Anwendung auf einem Tomcat-Server bereitgestellt wird, müssen Entwickler die Serverkonfiguration kennen, um etwaige Probleme zu debuggen. Dazu gehören das Überprüfen der Serverprotokolle, das Untersuchen der Konfigurationsdateien und das Identifizieren von Fehlern, die auftreten können.
  • Problembehandlung bei Tomcat-Problemen: Zwangsläufig treffen Java-Entwickler auf Probleme mit ihrem Tomcat-Server, z. B. Leistungsprobleme oder Konfigurationsfehler. Wenn sie die Konfigurationsdetails der server.xml-Datei und von Tomcat kennen, können Entwickler diese Probleme schnell diagnostizieren und beheben, was Zeit und Aufwand sparen kann.
  • Bereitstellen von Anwendungen in Tomcat: Um eine Java-Webanwendung für Tomcat bereitzustellen, müssen Entwickler wissen, wie Sie die server.xml-Datei und andere Tomcat-Einstellungen konfigurieren. Das Verständnis dieser Details ist wichtig, um Anwendungen erfolgreich bereitzustellen und sicherzustellen, dass sie reibungslos auf dem Server ausgeführt werden.

Wenn Sie eine App mit einer integrierten Tomcat-Instanz zum Hosten Ihrer Java-Workload (eine WAR-Datei oder eine JAR-Datei) erstellen, sind bestimmte Einstellungen standardmäßig für die Tomcat-Konfiguration verfügbar. Detaillierte Informationen, einschließlich der Standardkonfiguration für Tomcat-Webserver, finden Sie in der offiziellen Apache Tomcat-Dokumentation.

Darüber hinaus gibt es bestimmte Transformationen, die beim Start zusätzlich auf die server.xml für die Tomcat-Verteilung angewendet werden. Hierbei handelt es sich um Transformationen in die Einstellungen „Connector“, „Host“ und „Valve“.

Die aktuellen Versionen von Tomcat enthalten eine Datei namens „server.xml“ (8.5.58 und ab 9.0.38). Ältere Versionen von Tomcat verwenden keine Transformationen und weisen daher möglicherweise ein anderes Verhalten auf.

Connector

<Connector port="${port.http}" address="127.0.0.1" maxHttpHeaderSize="16384" compression="on" URIEncoding="UTF-8" connectionTimeout="${site.connectionTimeout}" maxThreads="${catalina.maxThreads}" maxConnections="${catalina.maxConnections}" protocol="HTTP/1.1" redirectPort="8443"/>
  • maxHttpHeaderSize auf 16384
  • URIEncoding auf UTF-8
  • conectionTimeout ist auf WEBSITE_TOMCAT_CONNECTION_TIMEOUT festgelegt, standardmäßig 240000
  • maxThreads ist auf WEBSITE_CATALINA_MAXTHREADS festgelegt, standardmäßig 200
  • maxConnections ist auf WEBSITE_CATALINA_MAXCONNECTIONS festgelegt, standardmäßig 10000

Hinweis

Die Einstellungen „connectionTimeout“, „maxThreads“ und „maxConnections“ können in den App-Einstellungen vorgenommen werden.

Im Folgenden finden Sie CLI-Beispielbefehle, mit denen Sie die Werte von conectionTimeout, maxThreads oder maxConnections ändern können:

az webapp config appsettings set --resource-group myResourceGroup --name myApp --settings WEBSITE_TOMCAT_CONNECTION_TIMEOUT=120000

az webapp config appsettings set --resource-group myResourceGroup --name myApp --settings WEBSITE_CATALINA_MAXTHREADS=100

az webapp config appsettings set --resource-group myResourceGroup --name myApp --settings WEBSITE_CATALINA_MAXCONNECTIONS=5000
  • Connector verwendet die Adresse des Containers anstelle von 127.0.0.1.

Host

<Host appBase="${site.appbase}" xmlBase="${site.xmlbase}" unpackWARs="${site.unpackwars}" workDir="${site.tempdir}" errorReportValveClass="com.microsoft.azure.appservice.AppServiceErrorReportValve" name="localhost" autoDeploy="true">
  • appBase ist auf AZURE_SITE_APP_BASE festgelegt, standardmäßig WebappsLocalPath (lokal)
  • xmlBase ist auf AZURE_SITE_HOME festgelegt, standardmäßig /site/wwwroot
  • unpackWARs ist auf AZURE_UNPACK_WARS festgelegt, standardmäßig true
  • workDir ist auf JAVA_TMP_DIR festgelegt, standardmäßig TMP
  • errorReportValveClass verwendet unser benutzerdefiniertes Valve-Element für den Fehlerbericht.

Ventil

<Valve prefix="site_access_log.${catalina.instance.name}" pattern="%h %l %u %t &quot;%r&quot; %s %b %D %{x-arr-log-id}i" directory="${site.logdir}/http/RawLogs" maxDays="${site.logRetentionDays}" className="org.apache.catalina.valves.AccessLogValve" suffix=".txt"/>
  • directory ist auf AZURE_LOGGING_DIR festgelegt, standardmäßig home\logFiles
  • maxDays ist auf WEBSITE_HTTPLOGGING_RETENTION_DAYS festgelegt, standardmäßig 0 [dauerhaft]

Unter Linux weist es dieselben Anpassungen auf, sowie:

  • Fügt dem Ventil einige Fehler- und Berichterstellungsseiten hinzu:

    <xsl:attribute name="appServiceErrorPage">
    <xsl:value-of select="'${appService.valves.appServiceErrorPage}'"/>
</xsl:attribute>

<xsl:attribute name="showReport">
    <xsl:value-of select="'${catalina.valves.showReport}'"/>
</xsl:attribute>

<xsl:attribute name="showServerInfo">
    <xsl:value-of select="'${catalina.valves.showServerInfo}'"/>
</xsl:attribute>

Nächste Schritte

Besuchen Sie das Center Azure für Java-Entwickler, um Azure-Schnellstarts, Tutorials und Java-Referenzdokumentation zu finden.