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

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.

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.

Tomcat bietet auch ein Umschreibventil.

JBoss bietet auch ein Umschreibventil.

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.

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.

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.

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:

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:

• Dokumentation zu Red Hat JBoss EAP
• WildFly-CLI-Anleitungen

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.

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.

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.

• 1. Phase zum Einrichten der Umgebung
• 2. Phase für den Serverstart
• 3. Phase für die Serverkonfiguration
• 4. Phase für die App-Bereitstellung
• 5. Phase für das erneute Laden des Servers

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

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

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>