Freigeben über

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

In diesem Artikel wird die am häufigsten verwendete Bereitstellungs- und Laufzeitkonfiguration für Java-Apps in Azure App Service erläutert. Wenn Sie Azure App Service zum ersten Mal verwenden, sollten Sie zuerst die Java-Schnellstartanleitung lesen. Sie finden die Antworten auf allgemeine Fragen zur Verwendung von App Service, die für die Java-Entwicklung nicht spezifisch sind, in den häufig gestellten Fragen zum App-Dienst.

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

  • Java Standard Edition (SE): Kann eine als Java Archive (JAR)-Paket bereitgestellte App ausführen, die einen eingebetteten Server enthält (z. B. Spring Boot, Quarkus, Dropwizard oder eine App mit einem eingebetteten Tomcat- oder Jetty-Server).
  • Tomcat: Der integrierte Tomcat-Server kann eine App ausführen, die als WAR-Paket (Web Application Archive) bereitgestellt wird.
  • JBoss Enterprise Application Platform (EAP): Der integrierte JBoss EAP-Server kann eine App ausführen, die als WAR- oder Enterprise-Archivpaket (EAR) bereitgestellt wird. Unterstützt für Linux-Apps in einer Reihe von Preisniveaus, einschließlich Free, Premium v3 und Isolated v2.gti

Anzeigen der Java-Version

Um die aktuelle Java-Version anzuzeigen, führen Sie den folgenden Befehl in Azure Cloud Shell aus:

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

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

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

Abrufen der Java-Version im Linux-Container

Für detailliertere Versionsinformationen im Linux-Container öffnen Sie eine SSH-Sitzung mit dem Container. Hier sind ein paar Beispiele dafür, was Sie ausführen können.

So zeigen Sie die Java-Version in der SSH-Sitzung an:

java -version

So zeigen Sie die Tomcat Server-Version in der SSH-Sitzung an:

sh /usr/local/tomcat/version.sh

Wenn sich Ihr Tomcat-Server an einem benutzerdefinierten Speicherort befindet, suchen Sie version.sh mit:

find / -name "version.sh"

So zeigen Sie die JBoss EAP-Serverversion in der SSH-Sitzung an:

$JBOSS_HOME/bin/jboss-cli.sh --connect --commands=:product-info

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

Was geschieht mit veralteten Laufzeiten in App Service?

Veraltete Laufzeiten werden von der Aufrechterhaltungsorganisation nicht mehr unterstützt oder festgestellt, dass erhebliche Sicherheitsrisiken auftreten. Dementsprechend werden sie aus dem Erstellen und Konfigurieren von Seiten im Portal entfernt. Wenn eine veraltete Laufzeit im Portal ausgeblendet ist, wird jede App, die diese Laufzeit verwendet, weiterhin ausgeführt.

Wenn Sie eine App mit einer veralteten Laufzeitversion erstellen möchten, die nicht mehr im Portal angezeigt wird, verwenden Sie die Azure CLI-, ARM-Vorlage oder Bicep. Mit diesen Bereitstellungsalternativen können Sie veraltete Laufzeiten erstellen, die im Portal entfernt wurden, aber weiterhin unterstützt werden.

Wenn eine Laufzeit vollständig von der App Service-Plattform entfernt wird, erhält Ihr Azure-Abonnementbesitzer vor dem Entfernen eine E-Mail-Benachrichtigung.

Bereitstellen Ihrer App

Buildtools

Experte

Mithilfe des Maven-Plug-Ins für Azure Web Apps können Sie Ihr Projekt ganz einfach mit einem Befehl im Projektstamm vorbereiten:

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

Mit diesem Befehl wird ein azure-webapp-maven-plugin Plug-In und die zugehörige Konfiguration hinzugefügt, 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. Anschließend 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 Plugin für Azure Web Apps ein, indem Sie das Plugin zu 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. Ausführliche Informationen 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 eine nahtlose Java App Service-Entwicklungsumgebung in beliebten Java Integrated Development Environments (IDEs), einschließlich:

Kudu- und OneDeploy-APIs

Bereitstellungsclients wie das Maven-Plug-In, GitHub Actions, die azure/webapps-deploy@v3 verwenden und neuer, oder der Befehl az webapp deploy verwenden OneDeploy, was durch durch Anrufen des /api/publish-Endpunkts der Kudu-Seite im Hintergrund aufgerufen wird. Weitere Informationen zu dieser API finden Sie in dieser Dokumentation.

Wenn diese Bereitstellungsmethoden verwendet werden, wird die bereitgestellte JAR-Datei während des Bereitstellungsprozesses automatisch in app.jar umbenannt. Dies wird unter dem /home/site/wwwwroot platziert werden. Informationen zur Bereitstellung von JAR-Dateien in Java SE finden Sie in dieser Dokumentation.

Hinweis

Wenn Sie alternative Methoden wie FTP oder ältere ZipDeploy-APIs verwenden, wird diese Methode zum Umbenennen der bereitgestellten JAR-Datei nicht aufgerufen. Beachten Sie dies, wenn Sie das Textfeld "Startdatei " im Abschnitt "Konfiguration " des Portals verwenden, um Ihre JAR-Datei explizit aufzurufen.

Sie können WAR-Dateien in Ihrer Tomcat-Anwendung bereitstellen, indem Sie diese Dokumentation ausführen. Wenn diese oben genannten Bereitstellungsmethoden verwendet werden, wird die bereitgestellte WAR-Datei während des Bereitstellungsprozesses automatisch in app.war umbenannt. Dies wird unter /home/site/wwwwroot platziert und unterstützt standardmäßig nur die Bereitstellung einer WAR-Datei unter wwwroot. Dies wird nicht unter dem /home/site/wwwroot/webapps-Verzeichnis platziert, wie bei Verwendung von Bereitstellungs-APIs wie z. B. WarDeploy. Um Probleme mit Dateistrukturkonflikten zu vermeiden, wird empfohlen, nur einen oder den anderen Bereitstellungstyp zu verwenden.

Informationen zum Bereitstellen von WAR-Dateien in JBoss EAP finden Sie in dieser Dokumentation. Wenn OneDeploy verwendet wird, wird die WAR-Datei automatisch in app.war umbenannt und unter /home/site/wwwroot abgelegt.

Verwenden Sie FTP, um EAR-Dateien bereitzustellen. Ihre EAR-Anwendung wird im Kontextstamm bereitgestellt, der in der Konfiguration Ihrer Anwendung definiert ist. 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 Ihren WAR oder JAR nicht mithilfe von 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 Umleiten einer URL

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

Tomcat bietet auch ein Umschreibventil.

JBoss EAP 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-Diagnoseübersicht.

Übertragung von Diagnoseberichten

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

Führen Sie den folgenden Befehl aus, um die Containerprotokollierung zu aktivieren:

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 Namen, die für Ihre Web-App geeignet sind.

Nachdem Sie die Containerprotokollierung aktiviert haben, führen Sie den folgenden Befehl aus, um den Protokolldatenstrom anzuzeigen:

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

Wenn Konsolenprotokolle nicht sofort angezeigt werden, überprüfen Sie es in 30 Sekunden erneut.

Wenn Sie das Protokollstreaming jederzeit beenden möchten, wählen Sie STRG+C aus.

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.

Verwenden Sie den Befehl az webapp ssh .

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 /home Verzeichnisses vornehmen, werden im Container selbst gespeichert und bleiben nicht über einen App-Neustart hinaus bestehen.

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-Laufzeitumgebungen auf Azure App Service verfügen über den Flight Recorder des Java Development Kits (JDK) zur Profilerstellung von Java-Workloads. Sie können es verwenden, um Java Virtual Machine (JVM), System- und Anwendungsereignisse aufzuzeichnen und Probleme in Ihren Anwendungen zu beheben.

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

Java-Flugrekorder

Alle Java-Runtimes auf dem App Service enthalten den Java Flight Recorder. Sie können es verwenden, um JVM-, System- und Anwendungsereignisse aufzuzeichnen und Probleme in Ihren Java-Anwendungen zu beheben.

SSH in App Service und Führen Sie den jcmd Befehl aus, um eine Liste aller ausgeführten Java-Prozesse anzuzeigen. Zusätzlich zu jcmd sollten Sie Ihre Java-Anwendung mit einer Prozess-ID (PID)-Nummer laufen 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. Sie profilet das JVM und erstellt eine JFR-Datei (Java Flight Recorder), die im Startverzeichnis benannt ist jfr_example.jfr . Ersetzen Sie 116 durch die PID Ihrer Java-Anwendung.

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.

Kontinuierliche 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 dazu den folgenden Azure CLI-Befehl aus, um eine App-Einstellung JAVA_OPTS mit der erforderlichen Konfiguration zu erstellen. Der Inhalt der JAVA_OPTS App-Einstellung wird beim Starten der App an den java Befehl übergeben.

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 Daten der aktuellen Aufzeichnung jederzeit mithilfe des Befehls JFR.dump ausgeben.

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. Um die JFR-Datei zu analysieren, laden Sie Java Mission Control (JMC) herunter, und installieren Sie sie. Anweisungen zur Verwendung von Java Mission Control finden Sie in der JMC-Dokumentation und den Installationsanweisungen.

App-Protokollierung

Gehen Sie wie folgt vor, um app Service so zu konfigurieren, dass die Standardkonsolenausgabe und Standardkonsolenfehlerströme in das lokale Dateisystem oder Azure Blob Storage geschrieben werden. Aktivieren Sie die Anwendungsprotokollierung über das Azure-Portal oder in der Azure CLI. Wenn Sie eine längere Aufbewahrung benötigen, konfigurieren Sie die Anwendung so, dass die Ausgabe in einen Blob Storage-Container geschrieben wird.

Ihre Java- und Tomcat-App-Protokolle finden Sie im /home/LogFiles/Application/ Verzeichnis.

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

Wenn Ihre Anwendung Logback oder Log4j für die Ablaufverfolgung verwendet, können Sie diese Ablaufverfolgungen zur Überprüfung an Azure Application Insights weiterleiten. Verwenden Sie die Konfigurationsanweisungen des Protokollierungsframeworks in Java-Ablaufverfolgungsprotokolle in Application Insights erkunden.

Hinweis

Achten Sie aufgrund bekannter Sicherheitsanfälligkeiten CVE-2021-44228darauf, Log4j, Version 2.16 oder höher, zu verwenden.

Anpassung und Optimierung

Azure App Service unterstützt sofort einsatzbereite Optimierung und Anpassung über das Azure-Portal und die Azure 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 gemeinsamen 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.

Der App-Dienst legt standardmäßig die Größe von JVM Max Heap auf 70% des gesamt für den App-Serviceplan verfügbaren Arbeitsspeichers fest. Um die Standardeinstellung zu deaktivieren, können Sie die App-Einstellung WEBSITE_DISABLE_JAVA_HEAP_CONFIGURATION="true" verwenden.

Die Verbesserung der Leistung Ihrer Anwendung auf der Plattform kann dazu führen, die Heap-Größe entsprechend Ihren spezifischen Anforderungen anzupassen. Überprüfen Sie beim Anpassen der Heap-Einstellungen für Anwendungen die Details Ihres App Service-Plans und berücksichtigen Sie die Anforderungen mehrerer Anwendungen und Bereitstellungsslots, um die optimale Speicherzuweisung 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 mithilfe der Azure CLI mit dem folgenden Befehl:

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>

Standardzeichencodierung festlegen

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 mithilfe des App Service Maven-Plug-Ins 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>

Vorabkompilierung 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 verwenden oder diese Ant-Builddatei verwenden.

Ignorieren Sie die Roboter-Nachricht 933456 in den 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 gibt an, dass der Pfad nicht vorhanden ist, und signalisiert dem App-Dienst, dass der Container fehlerfrei ist und bereit ist, auf Anforderungen zu reagieren.

Auswählen einer Java-Laufzeitversion

Mit app Service können Benutzer die Hauptversion des JVM auswählen, z. B. Java 8 oder Java 11, und die Patchversion, z. B. 1.8.0_232 oder 11.0.5. Sie können auch auswählen, dass die Patchversion automatisch aktualisiert wird, sobald neue Nebenversionen verfügbar sind. In den meisten Fällen sollten Produktions-Apps angeheftete Patch-JVM-Versionen verwenden, die unerwartete Ausfälle während einer AutoUpdate-Patchversion verhindern. 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 von JVM ist ebenfalls angeheftet, kann aber nicht separat konfiguriert werden.

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.

Ausführen der JBoss-Befehlszeilenschnittstelle

In der SSH-Sitzung Ihrer JBoss-EAP-App können Sie die JBoss CLI mit dem folgenden Befehl ausführen:

$JBOSS_HOME/bin/jboss-cli.sh --connect

Je nachdem, wo sich JBoss EAP im Serverlebenszyklus befindet, können Sie möglicherweise keine Verbindung herstellen. Warten Sie einige Minuten, und versuchen Sie erneut. Dieser Ansatz ist hilfreich für die schnelle Überprüfung des aktuellen Serverzustands (z. B. um festzustellen, ob eine Datenquelle ordnungsgemäß konfiguriert ist).

Außerdem werden Änderungen, die Sie am Server mit der JBoss CLI in der SSH-Sitzung vornehmen, nach dem Neustart der App nicht beibehalten. Jedes Mal, wenn die App gestartet wird, beginnt der JBoss EAP-Server mit einer Neuinstallation. Während des Startlebenszyklus nimmt App Service die erforderlichen Serverkonfigurationen vor und stellt die App bereit. Wenn Sie dauerhafte Änderungen am JBoss-EAP-Server vornehmen möchten, verwenden Sie ein benutzerdefiniertes Startskript oder einen Startbefehl. Ein vollständiges Beispiel finden Sie unter Konfigurieren von Datenquellen für eine Java SE-, Tomcat- oder JBoss EAP-Anwendung im Azure App Service.

Alternativ können Sie App Service manuell so konfigurieren, dass beim Start eine beliebige Datei ausgeführt wird. Zum Beispiel:

az webapp config set --resource-group <group-name> --name <app-name> --startup-file /home/site/scripts/foo.sh

Weitere Informationen zu den CLI-Befehlen, die Sie ausführen können, finden Sie unter:

Clusterbildung

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. Wenn Sie mehrere Instanzen mit automatischer Skalierung ausführen, kommunizieren die JBoss EAP-Instanzen über das in der VNet-Integration angegebene Subnetz miteinander. Sie können das Clustering deaktivieren, indem Sie eine App-Einstellung namens WEBSITE_DISABLE_CLUSTERING mit einem beliebigen Wert erstellen.

Ein Diagramm, das eine in das virtuelle Netzwerk integrierte JBoss EAP App Service-App zeigt, die auf drei Instanzen skaliert wurde.

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 für Sie festgelegt.

Wenn das Clustering aktiviert ist, verwenden die JBoss-EAP-Instanzen das FILE_PING JGroups Discovery-Protokoll, um neue Instanzen zu ermitteln und Clusterinformationen zu speichern (z. B. die Clustermitglieder, ihre Bezeichner und ihre IP-Adressen). 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 EAP-Clusteringzeitüberschreitungen vermeiden, indem Sie veraltete Erkennungsdateien beim Starten Ihrer App bereinigen.

Die Typen "Premium V3", "Premium V4" und "Isolierter V2-App-Dienstplan" können optional über Verfügbarkeitszonen verteilt werden, um Die Ausfallsicherheit und Zuverlässigkeit ihrer geschäftskritischen Workloads zu verbessern. Diese Architektur wird auch als Zonenredundanz bezeichnet. Das Feature für JBoss EAP-Clustering ist mit der Zonenredundanzfunktion kompatibel.

Autoskalierungsregeln

Wenn Sie Regeln für die automatische Skalierung für die horizontale Skalierung konfigurieren, ist es wichtig, Instanzen inkrementell (jeweils einzeln) zu entfernen, 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 so konfigurieren, dass sie herunterskaliert werden, 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 (Aufskalieren). Sie können dem Cluster mehrere Instanzen gleichzeitig hinzufügen.

App Service-Pläne

JBoss EAP ist in den folgenden Preisstufen verfügbar: F1, P0v3, P1mv3, P2mv3, P3mv3, P4mv3, P5mv3, P0v4, P1mv4, P2mv4, P3mv4, P4mv4 und P5mv4.

JBoss EAP-Serverlebenszyklus

Eine JBoss-EAP-App in App Service durchläuft fünf verschiedene Phasen, bevor der Server gestartet wird:

  1. Umgebungseinrichtungsphase
  2. Serverstartphase
  3. Serverkonfigurationsphase
  4. Phase der App-Bereitstellung
  5. Server-Neuladephase

Ausführliche Informationen und Möglichkeiten zum Anpassen (z. B. über App-Einstellungen) finden Sie in den folgenden Abschnitten.

1. Phase zum Einrichten der Umgebung

  • Der SSH-Dienst wird gestartet, um sichere SSH-Sitzungen mit dem Container zu aktivieren.
  • Der Java-Runtime-Keystore wird mit allen öffentlichen und privaten Zertifikaten aktualisiert, die im Azure-Portal definiert sind.
    • Öffentliche Zertifikate werden von der Plattform im Verzeichnis /var/ssl/certs bereitgestellt und in $JRE_HOME/lib/security/cacerts geladen.
    • Private Zertifikate werden von der Plattform im Verzeichnis /var/ssl/private bereitgestellt und in $JRE_HOME/lib/security/client.jks geladen.
  • Wenn Zertifikate im Java-Schlüsselspeicher in diesem Schritt geladen werden, werden die Eigenschaften javax.net.ssl.keyStore, , javax.net.ssl.keyStorePasswordund javax.net.ssl.keyStoreType werden der JAVA_OPTS Umgebungsvariable hinzugefügt.
  • Einige anfängliche JVM-Konfigurationen werden bestimmt, z. B. Protokollierungsverzeichnisse und Java-Speicherheap-Parameter.
    • Wenn Sie die Flags –Xms oder –Xmx für den Speicher in der App-Einstellung JAVA_OPTS angeben, überschreiben diese Werte die von der Plattform bereitgestellten Werte.
    • Wenn Sie die App-Einstellung WEBSITES_CONTAINER_STOP_TIME_LIMITkonfigurieren, wird der Wert an die Laufzeiteigenschaft org.wildfly.sigterm.suspend.timeoutübergeben, die die maximale Wartezeit für das Herunterfahren (in Sekunden) steuert, wenn JBoss EAP beendet wird.
  • Wenn die App in ein virtuelles Netzwerk integriert ist, übergibt die App Service-Laufzeit eine Liste der Ports, die für die Kommunikation zwischen servern in der Umgebungsvariable WEBSITE_PRIVATE_PORTS verwendet werden sollen, und startet JBoss EAP mithilfe der clustering Konfiguration. Andernfalls wird die standalone-Konfiguration verwendet.
    • Für die clustering Konfiguration wird die Serverkonfigurationsdatei standalone-azure-full-ha.xml verwendet.
    • Für die standalone Konfiguration wird die Serverkonfigurationsdatei standalone-full.xml verwendet.

2. Phase für den Serverstart

  • Wenn JBoss EAP in der clustering Konfiguration gestartet wird:
    • Jede JBoss EAP-Instanz empfängt einen internen Bezeichner zwischen 0 und der Anzahl der Instanzen, auf die die App skaliert wird.
    • Wenn einige Dateien im Transaktionsspeicherpfad für diese Serverinstanz (mithilfe des internen Bezeichners) gefunden werden, bedeutet dies, dass diese Serverinstanz die Stelle einer identischen Dienstinstanz übernimmt. Die andere Dienstinstanz stürzte zuvor ab und hat nicht abgeschlossene Transaktionen zurückgelassen. Der Server ist so konfiguriert, dass die Arbeit an diesen Transaktionen fortgesetzt wird.
  • Unabhängig davon, ob JBoss EAP in der clustering Oder standalone Konfiguration gestartet wird, wenn die Serverversion 7.4 oder höher ist und die Laufzeit Java 17 verwendet, wird die Konfiguration aktualisiert, um das Elytron-Subsystem für sicherheit zu aktivieren.
  • Wenn Sie die App-Einstellung WEBSITE_JBOSS_OPTS konfigurieren, wird der Wert an das JBoss-Startprogrammskript übergeben. Diese Einstellung kann verwendet werden, um Pfade zu Eigenschaftsdateien und mehr Flags bereitzustellen, die den Start von JBoss EAP beeinflussen.

3. Phase für die Serverkonfiguration

  • Zu Beginn dieser Phase wartet der App Service zunächst darauf, dass sowohl der JBoss EAP Server als auch die Administratorschnittstelle bereit sind, Anfragen empfangen zu können, bevor er fortfährt. Dieser Vorgang kann einige Sekunden dauern, wenn Application Insights aktiviert ist.

  • Wenn sowohl JBoss EAP-Server als auch die Administratorschnittstelle bereit sind, führt App Service die folgenden Aktionen aus:

    • Fügt das JBoss EAP-Modul azure.appservicehinzu, das Hilfsklassen für die Protokollierung und Integration in App Service bereitstellt.
    • Aktualisieren der Konsolenprotokollierung, sodass sie einen farblosen Modus verwendet und Protokolldateien nicht voll von Escapesequenzen für Farbe sind
    • Einrichten der Integration in Azure Monitor-Protokolle
    • Aktualisiert die Bindungs-IP-Adressen der Webdienstbeschreibungssprache (Web Services Description Language, WSDL) und der Verwaltungsschnittstellen.
    • Fügt das JBoss EAP-Modul azure.appservice.easyauth für die Integration mit der App Service-Authentifizierung und der Microsoft Entra-ID hinzu.
    • Aktualisieren der Protokollierungskonfiguration von Zugriffsprotokollen sowie des Namens und der Rotation der Hauptserverprotokolldatei

  • Sofern die App-Einstellung WEBSITE_SKIP_AUTOCONFIGURE_DATABASE nicht definiert ist, erkennt App Service JDBC-URLs (Java Database Connectivity) in den App Service-App-Einstellungen automatisch. Wenn gültige JDBC-URLs für PostgreSQL, MySQL, MariaDB, Oracle, SQL Server oder Azure SQL Database vorhanden sind, fügt es die entsprechenden Treiber zum Server hinzu, fügt eine Datenquelle für jede der JDBC-URLs hinzu und legt den JNDI-Namen (Java Naming and Directory Interface) für jede Datenquelle auf java:jboss/env/jdbc/<app-setting-name>_DS fest, wobei <app-setting-name> der Name der App-Einstellung ist.

  • Wenn die clustering-Konfiguration aktiviert ist, wird die zu konfigurierende Konsolenprotokollierung überprüft.

  • Wenn JAR-Dateien im /home/site/libs Verzeichnis bereitgestellt werden, wird mit all diesen JAR-Dateien ein neues globales Modul erstellt.

  • Am Ende der Phase führt App Service das benutzerdefinierte Startskript aus, sofern vorhanden. Die Suchlogik für das benutzerdefinierte Startskript wird wie folgt definiert:

    • Wenn Sie einen Startbefehl (z. B. über das Azure-Portal oder die Azure CLI) konfiguriert haben, führen Sie ihn aus. sonst
    • Wenn der Pfad /home/site/scripts/startup.sh vorhanden ist, verwenden Sie ihn; andernfalls
    • Wenn der Pfad /home/startup.sh vorhanden ist, verwenden Sie ihn.

Der benutzerdefinierte Startbefehl oder das Benutzerdefinierte Skript wird als Stammbenutzer ausgeführt (keine Notwendigkeit sudo), sodass sie Linux-Pakete installieren oder die JBoss CLI starten können, um weitere JBoss EAP-Installations-/Anpassungsbefehle auszuführen, z. B. das Erstellen von Datenquellen und das Installieren von Ressourcenadaptern. Informationen zu Ubuntu-Paketverwaltungsbefehlen finden Sie in der Ubuntu Server-Dokumentation. Informationen zu JBoss-CLI-Befehlen finden Sie im Leitfaden zur JBoss-Verwaltungs-CLI.

4. Phase für die App-Bereitstellung

Das Startskript stellt Apps in JBoss EAP bereit, indem es in der angegebenen Reihenfolge an den folgenden Speicherorten sucht:

  • Wenn Sie die App-Einstellung WEBSITE_JAVA_WAR_FILE_NAME konfiguriert haben, stellen Sie die von ihr festgelegte Datei bereit.
  • Stellen Sie /home/site/wwwroot/app.war bereit, sofern vorhanden.
  • Falls andere EAR- und WAR-Dateien in /home/site/wwwroot vorhanden sind, stellen Sie sie bereit.
  • Falls /home/site/wwwroot/webapps vorhanden, stellen Sie die Darin enthaltenen Dateien und Verzeichnisse bereit. WAR-Dateien werden als Anwendungen selbst bereitgestellt, und Verzeichnisse werden als „explodierte“ (nicht komprimierte) Web-Apps bereitgestellt.
  • Wenn eigenständige JSP-Seiten in /home/site/wwwroot vorhanden sind, kopieren Sie sie in den Webserverstamm, und stellen Sie sie als eine Web-App bereit.
  • Wenn keine bereitstellbaren Dateien gefunden werden, stellen Sie die Standard-Willkommensseite (Parkseite) im Stammkontext bereit.

5. Phase für das erneute Laden des Servers

  • Nachdem die Bereitstellungsschritte abgeschlossen sind, wird der JBoss EAP-Server neu geladen, um alle Änderungen anzuwenden, für die ein Server neu geladen werden muss.
  • Nachdem der Server neu geladen wurde, sollten die auf dem JBoss EAP-Server bereitgestellten Anwendungen bereit sein, auf Anforderungen zu reagieren.
  • Der Server wird ausgeführt, bis die App Service-App beendet oder neu gestartet wird. Sie können die App Service-App manuell beenden oder neu starten oder einen Neustart auslösen, wenn Sie Dateien bereitstellen oder Konfigurationsänderungen an der App Service-App vornehmen.
  • Wenn der JBoss-EAP-Server in der clustering-Konfiguration unerwartet beendet wird, wird eine abschließende Funktion namens emit_alert_tx_store_not_empty ausgeführt. Die Funktion überprüft, ob der JBoss-EAP-Prozess eine nicht abgelaufene Transaktionsspeicherdatei auf dem Datenträger hinterlassen hat. Wenn ja, wird ein Fehler in der Konsole protokolliert: Error: finishing server with non-empty store for node XXXX. Wenn eine neue Serverinstanz gestartet wird, sucht sie nach diesen nicht leeren Transaktionsspeicherdateien, um die Arbeit fortzusetzen (siehe 2. Phase für den Serverstart).

Tomcat-Grundkonfiguration

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 die Konfigurationsdetails der server.xml und der Konfiguration von Tomcat verstehen, können Sie die Servereinstellungen so optimieren, dass sie den Anforderungen ihrer Anwendungen entsprechen.
  • Debuggen: Wenn eine Anwendung auf einem Tomcat-Server bereitgestellt wird, müssen Entwickler die Serverkonfiguration kennen, um etwaige Probleme zu debuggen. Dieser Prozess umfasst das Überprüfen der Serverprotokolle, die Untersuchung 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 tomcat verstehen, 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. Sie müssen diese Details verstehen, 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 zu „server.xml“ für die Tomcat-Distribution angewendet werden. Zu diesen Transformationen gehören Änderungen an den 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.

Verbinder

<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 ist auf 16384 eingestellt.
  • URIEncoding ist auf UTF-8 eingestellt.
  • connectionTimeout 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 connectionTimeout, maxThreads und maxConnections-Einstellungen können mit App-Einstellungen abgestimmt werden.

Mit den folgenden CLI-Beispielbefehlen können Sie die Werte von connectionTimeout, maxThreads und maxConnections ändern:

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.

Gastgeber

<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, was standardmäßig auf lokales WebappsLocalPath zurückgreift.
  • 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 7. Dieser Wert entspricht der Standardeinstellung für die Anwendungsprotokollierungsplattform.

Unter Linux verfügt es über alle dieselbe Anpassung und 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>

Verwandte Inhalte

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