Auf Englisch lesen

Teilen über

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

  • Artikel
Wählen Sie, wie Ihre Java-App gehostet wird

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 „Free“, „Premium v3“ und „V2 isoliert“ unterstützt. Der integrierte JBoss EAP-Server kann eine als WAR- oder EAR-Paket bereitgestellte App ausführen.

Java-Version anzeigen

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

Azure CLI 
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:

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

Java-Version im Linux-Container abrufen

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:

Bash 
java -version

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

Bash 
sh /usr/local/tomcat/version.sh

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

Bash 
find / -name "version.sh"

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

Bash 
$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.

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:

shell 
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:

shell 
mvn package azure-webapp:deploy

Hier sehen Sie eine Beispielkonfiguration in pom.xml:

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:

    groovy 
    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.

    groovy 
    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.

    shell 
    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:

Azure CLI 
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:

Azure CLI 
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.

shell 
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.)

shell 
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.

Azure CLI 
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.

shell 
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:

XML 
<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:

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

Starten Sie Ihre Anwendung anschließend neu:

Azure CLI 
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:

XML 
<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.

„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.

Ausführen der JBoss-CLI

In der SSH-Sitzung Ihrer JBoss-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 im Serverlebenszyklus befindet, können Sie u. U. 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. Um dauerhafte Änderungen am JBoss-Server vorzunehmen, verwenden Sie ein benutzerdefiniertes Startskript oder einen Startbefehl. Ein End-to-End-Beispiel finden Sie unter Konfigurieren von Datenquellen für eine Tomcat-, JBoss- oder Java SE-App in Azure App Service.

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

Azure CLI 
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 hier:

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. 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.

Diagramm mit einer in das VNet integrierten JBoss-App Service-App, die auf drei Instanzen aufskaliert 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 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.

JBoss-Serverlebenszyklus

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

Details sowie Möglichkeiten zum Anpassen finden Sie in den entsprechenden Abschnitten unten (z. B. über App-Einstellungen).

1. Phase zum Einrichten der Umgebung

  • Der SSH-Dienst wird gestartet, um sichere SSH-Sitzungen mit dem Container zu aktivieren.
  • Der Keystore der Java-Runtime 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 in diesem Schritt im Java-Keystore geladen werden, werden die Eigenschaften javax.net.ssl.keyStore, javax.net.ssl.keyStorePassword und javax.net.ssl.keyStoreType der Umgebungsvariablen JAVA_TOOL_OPTIONS hinzugefügt.
  • Einige anfängliche JVM-Konfigurationen werden bestimmt, etwa Protokollierungsverzeichnisse und Java-Speicherheapparameter:
    • 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_LIMIT konfigurieren, 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 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 verwendet werden sollen, in der Umgebungsvariablen WEBSITE_PRIVATE_PORTS und startet JBoss 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

  • Starten von JBoss in der clustering-Konfiguration:
    • Jede JBoss-Instanz empfängt einen internen Bezeichner zwischen 0 und der Anzahl der Instanzen, auf die die App aufskaliert wird.
    • Wenn im Transaktionsspeicherpfad einige Dateien für diese Serverinstanz (anhand des internen Bezeichners) gefunden werden, bedeutet dies, dass diese Serverinstanz die Stelle einer identischen Dienstinstanz übernimmt, die zuvor abgestürzt ist und Transaktionen zurückgelassen hat, für die noch kein Commit ausgeführt wurde. Der Server ist so konfiguriert, dass die Arbeit an diesen Transaktionen fortgesetzt wird.
  • Unabhängig davon, ob JBoss in der clustering- oder in der standalone-Konfiguration gestartet wird, wird die Konfiguration aktualisiert, um das Elytron-Subsystem aus Sicherheitsgründen zu aktivieren, wenn die Serverversion 7.4 oder höher ist und die Laufzeit Java 17 verwendet.
  • 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 beeinflussen.

3. Phase für die Serverkonfiguration

  • Zu Beginn dieser Phase wartet App Service zunächst, bis der JBoss-Server und die Administratorschnittstelle zum Empfangen von Anforderungen bereit sind, bevor der Vorgang fortgesetzt wird. Dies kann ein paar Sekunden länger dauern, wenn Application Insights aktiviert ist.
  • Wenn sowohl JBoss Server als auch die Administratorschnittstelle bereit sind, führt App Service die folgenden Aktionen aus:
    • Hinzufügen des JBoss-Moduls azure.appservice, das Hilfsprogrammklassen 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
    • Aktualisieren der Bindungs-IP-Adressen der WSDL- und Verwaltungsschnittstellen
    • Hinzufügen des JBoss-Moduls azure.appservice.easyauth für die Integration mit App Service-Authentifizierung und Microsoft Entra ID
    • 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 in den App Service-App-Einstellungen automatisch. Wenn gültige JDBC-URLs für PostgreSQL, MySQL, MariaDB, Oracle, SQL Server oder Azure SQL-Datenbank vorhanden sind, werden dem Server die entsprechenden Treiber und eine Datenquelle für jede JDBC-URL hinzugefügt und der JNDI-Name für jede Datenquelle auf java:jboss/env/jdbc/<app-setting-name>_DS festgelegt. Dabei ist <app-setting-name> der Name der App-Einstellung.
  • Wenn die clustering-Konfiguration aktiviert ist, wird die zu konfigurierende Konsolenprotokollierung überprüft.
  • Wenn JAR-Dateien im Verzeichnis /home/site/libs 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 lautet wie folgt:
    • Wenn Sie einen Startbefehl (im Azure-Portal, mit der Azure CLI usw.) konfiguriert haben, führen Sie ihn aus. Oder:
    • Wenn der Pfad /home/site/scripts/startup.sh vorhanden ist, verwenden Sie ihn. Oder:
    • Wenn der Pfad /home/startup.sh vorhanden ist, verwenden Sie ihn.

Der benutzerdefinierte Startbefehl oder das benutzerdefinierte Startskript wird als Stammbenutzer ausgeführt (sudo ist nicht erforderlich), sodass Linux-Pakete installiert werden können oder die JBoss-CLI gestartet werden kann, um weitere Befehle zur JBoss-Installation/-Anpassung auszuführen (Erstellen von Datenquellen, Installieren von Ressourcenadaptern usw.). 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 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.
  • Wenn /home/site/wwwroot/app.war vorhanden ist, führen Sie die Bereitstellung durch.
  • Wenn andere EAR- und WAR-Dateien in /home/site/wwwroot vorhanden sind, stellen Sie sie bereit.
  • Wenn /home/site/wwwroot/webapps vorhanden ist, stellen Sie die Dateien und Verzeichnisse darin 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 noch keine bereitstellbaren Dateien gefunden werden, stellen Sie die standardmäßige Willkommensseite (Parkseite) im Stammkontext bereit.

5. Phase für das erneute Laden des Servers

  • Sobald die Bereitstellungsschritte abgeschlossen sind, wird der JBoss-Server erneut geladen, um alle Änderungen anzuwenden, die ein erneutes Laden des Servers erfordern.
  • Nachdem der Server erneut 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-Server in der clustering-Konfiguration fehlerbedingt beendet wird, wird eine endgültige Funktion namens emit_alert_tx_store_not_empty ausgeführt. Die Funktion überprüft, ob der JBoss-Prozess eine nicht leere Transaktionsspeicherdatei auf dem Datenträger hinterlassen hat. Falls 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-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

XML 
<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
  • 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 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 connectionTimeout, maxThreads und maxConnections ändern können:

Azure CLI 
az webapp config appsettings set --resource-group myResourceGroup --name myApp --settings WEBSITE_TOMCAT_CONNECTION_TIMEOUT=120000
Azure CLI 
az webapp config appsettings set --resource-group myResourceGroup --name myApp --settings WEBSITE_CATALINA_MAXTHREADS=100
Azure CLI 
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

XML 
<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

XML 
<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 entspricht WEBSITE_HTTPLOGGING_RETENTION_DAYS, der Standardwert ist 7. Dies entspricht dem Standardwert für die Application Logging-Plattform

Unter Linux weist es dieselben Anpassungen auf, sowie:

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

    XML 
    <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.