Freigeben über

Konfigurieren einer Java-App für Azure App Service

  • Artikel

Hinweis

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

Mit Azure App Service können Java-Entwickler ihre Java SE-, Tomcat- und JBoss EAP-Webanwendungen in einem vollständig verwalteten Dienst schnell erstellen, bereitstellen und skalieren. Stellen Sie Anwendungen mit Maven-Plug-Ins über die Befehlszeile oder in Editoren wie IntelliJ, Eclipse oder Visual Studio Code bereit.

Dieser Leitfaden enthält die wichtigsten Konzepte und Anweisungen für Java-Entwickler, die App Service verwenden. 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.

Java-Version anzeigen

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

az webapp config show --name <app-name> --resource-group <resource-group-name> --query "[javaVersion, javaContainer, javaContainerVersion]"

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

az webapp list-runtimes --os windows | grep java

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

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

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

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

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

Bereitstellen Ihrer App

Build-Tools

Maven

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

mvn com.microsoft.azure:azure-webapp-maven-plugin:2.11.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. Dann können Sie Ihre Java-App mit dem folgenden Befehl in Azure bereitstellen:

mvn package azure-webapp:deploy

Hier sehen Sie eine Beispielkonfiguration in pom.xml:

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

Gradle

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

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

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

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

  3. Installieren mit einem Befehl.

    gradle azureWebAppDeploy

IDEs

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

Kudu-API

Java SE

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

Tomcat

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.

JBoss EAP

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.

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

Aktivieren Sie die Diagnoseprotokollierung, indem Sie den folgenden Befehl in Cloud Shellausführen, um auf die Konsolenprotokolle zuzugreifen, die innerhalb des Anwendungscodes in App Service generiert wurden:

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

Mögliche Werte für --level sind Error, WarningInfo oder Verbose. Jede nachfolgende Ebene enthält die vorherige Ebene. Beispiel: Error enthält nur Fehlermeldungen, und Verbose enthält alle Meldungen.

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

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

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

Hinweis

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

Um das Protokollstreaming jederzeit zu beenden, geben Sie Ctrl+C ein.

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

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

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

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

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

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

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

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

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

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

SSH-Konsolenzugriff

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

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.

Zeitgesteuerte Aufzeichnung

Für eine zeitgesteuerte Aufzeichnung benötigen Sie die PID (Prozess-ID) der Java-Anwendung. Öffnen Sie zum Ermitteln der PID einen Browser mit der SCM-Website Ihrer Web-App (https://<your-site-name>.scm.azurewebsites.net/ProcessExplorer/). Auf dieser Seite werden die in Ihrer Web-App ausgeführten Prozesse angezeigt. Suchen Sie in der Tabelle den Prozess mit dem Namen „Java“, und kopieren Sie die entsprechende PID (Prozess-ID).

Öffnen Sie dann auf der oberen Symbolleiste der SCM-Website die Debugging-Konsole, und führen Sie den folgenden Befehl aus. Ersetzen Sie <pid> durch die Prozess-ID, die Sie zuvor kopiert haben. Dieser Befehl startet eine 30-sekündige Profileraufzeichnung der Java-Anwendung und generiert eine Datei mit dem Namen timed_recording_example.jfr im Verzeichnis C:\home.

jcmd <pid> JFR.start name=TimedRecording settings=profile duration=30s filename="C:\home\timed_recording_example.JFR"

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

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

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

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

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

Fortlaufende Aufzeichnung

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

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

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

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

Analysieren von .jfr-Dateien

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

App-Protokollierung

Aktivieren Sie die Anwendungsprotokollierung über das Azure-Portal oder die Azure-Befehlszeilenschnittstelle, um App Service so zu konfigurieren, dass die Streams mit der Standardkonsolenausgabe und den Standardkonsolenfehlern Ihrer Anwendung in das lokale Dateisystem oder Azure Blob Storage geschrieben werden. Die Protokollierung in der lokalen App Service-Dateisysteminstanz wird 12 Stunden nach der Konfiguration deaktiviert. 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/ .

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 Webanwendung eine neue Anwendungseinstellung mit dem Namen JAVA_OPTS für Java SE oder CATALINA_OPTS für Tomcat, die weitere Einstellungen wie -Xms512m -Xmx1204m enthält.

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

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

Hinweis

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

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

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

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

Aktivieren von Websockets

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

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

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

Starten Sie Ihre Anwendung anschließend neu:

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

Festlegen der Standardzeichencodierung

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

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

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

Vorkompilieren von JSP-Dateien

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

Sichere Anwendungen

Für in App Service ausgeführte Java-Anwendungen gelten dieselben bewährten Sicherheitsmethoden wie für andere Anwendungen.

Authentifizieren von Benutzern (einfache Authentifizierung)

Richten Sie die App-Authentifizierung im Azure-Portal über die Option Authentifizierung und Autorisierung ein. Von dort aus können Sie die Authentifizierung mithilfe von Azure Active Directory oder sozialen Netzwerke wie Facebook, Google oder GitHub aktivieren. Die Konfiguration des Azure-Portals funktioniert nur, wenn Sie einen einzelnen Authentifizierungsanbieter konfigurieren. Weitere Informationen finden Sie unter Konfigurieren Ihrer App Service-App zur Verwendung der Azure Active Directory-Anmeldung und in den entsprechenden Artikeln für andere Identitätsanbieter. Wenn Sie mehrere Anmeldedatenanbieter aktivieren müssen, folgen Sie den Anweisungen unter Anpassen der An- und Abmeldung.

Java SE

Spring Boot-Entwickler können die Azure Active Directory-Startoption für Spring Boot verwenden, um Anwendungen mithilfe von vertrauten Spring Security-Anmerkungen und -APIs absichern. Achten Sie darauf, dass Sie die maximale Headergröße in Ihrer application.properties-Datei erhöhen. Wir empfehlen den Wert 16384.

Tomcat

Ihre Tomcat-Anwendung kann direkt aus dem Servlet auf die Ansprüche des Benutzers zugreifen, indem sie das Principal-Objekt in ein Map-Objekt umwandelt. Das Map-Objekt ordnet jeden Anspruchstyp einer Sammlung der Ansprüche für diesen Typ zu. Im folgenden Codebeispiel ist request eine Instanz von HttpServletRequest.

Map<String, Collection<String>> map = (Map<String, Collection<String>>) request.getUserPrincipal();

Nun können Sie das Map-Objekt auf bestimmte Ansprüche überprüfen. Der folgende Codeausschnitt durchläuft beispielsweise alle Anspruchstypen und gibt den Inhalt der einzelnen Sammlungen aus.

for (Object key : map.keySet()) {
        Object value = map.get(key);
        if (value != null && value instanceof Collection {
            Collection claims = (Collection) value;
            for (Object claim : claims) {
                System.out.println(claims);
            }
        }
    }

Um Benutzer abzumelden, verwenden Sie den Pfad /.auth/ext/logout. Weitere Aktionen finden Sie in der Dokumentation zu Anpassen der An- und Abmeldungen. Es gibt auch eine offizielle Dokumentation zur HttpServletRequest-Schnittstelle von Tomcat und ihren Methoden. Die folgenden Servletmethoden werden auch basierend auf Ihrer App Service-Konfiguration aktualisiert:

public boolean isSecure()
public String getRemoteAddr()
public String getRemoteHost()
public String getScheme()
public int getServerPort()

Um dieses Feature zu deaktivieren, erstellen Sie eine Anwendungseinstellung mit dem Namen WEBSITE_AUTH_SKIP_PRINCIPAL und dem Wert 1. Um alle Servletfilter zu deaktivieren, die von App Service hinzugefügt wurden, erstellen Sie eine Einstellung namens WEBSITE_SKIP_FILTERS mit dem Wert 1.

Konfigurieren von TLS/SSL

Um ein vorhandenes TLS/SSL-Zertifikat hochzuladen und an den Domänennamen Ihrer Anwendung zu binden, folgen Sie den Anweisungen unter Schützen eines benutzerdefinierten DNS-Namens mit einer TLS/SSL-Bindung in Azure App Service. Sie können die App auch zum Erzwingen von TLS/SSL konfigurieren.

Verwenden von KeyVault-Verweisen

Azure KeyVault bietet eine zentrale Verwaltung von Geheimnissen mit Zugriffsrichtlinien und Überprüfungsverlauf. Sie können in KeyVault Geheimnisse (wie Kennwörter oder Verbindungszeichenfolgen) speichern und über Umgebungsvariablen auf diese Geheimnisse in Ihrer Anwendung zugreifen.

Befolgen Sie zunächst die Anweisungen zum Gewähren des Zugriffs auf einen Schlüsseltresor Ihre App und zum Erstellen eines KeyVault-Verweises auf Ihr Geheimnis in einer Anwendungseinstellung. Sie können überprüfen, ob der Verweis auf das Geheimnis aufgelöst wird, indem Sie die Umgebungsvariable ausgeben, während Sie remote auf das App Service-Terminal zugreifen.

Um diese Geheimnisse in Ihre Spring- oder Tomcat-Konfigurationsdatei einzufügen, verwenden Sie die Syntax der Umgebungsvariablen (${MY_ENV_VAR}). Für Spring-Konfigurationsdateien, siehe diese Dokumentation über externalisierte Konfigurationen.

Verwenden des Java-Keystores

Standardmäßig werden alle öffentlichen oder privaten Zertifikate, die in App Service (Linux) hochgeladen wurden, beim Start des Containers in den jeweiligen Java Key Store geladen. Nach dem Hochladen Ihres Zertifikats müssen Sie Ihre App Service-Instanz neu starten, damit es in den Java-Keystore geladen wird. Öffentliche Zertifikate werden unter $JRE_HOME/lib/security/cacerts in den Schlüsselspeicher geladen, und private Zertifikate werden unter $JRE_HOME/lib/security/client.jks gespeichert.

Für die Verschlüsselung Ihrer JDBC-Verbindung (Java Database Connectivity) mit Zertifikaten im Java Key Store kann eine weitere Konfiguration erforderlich sein. Lesen Sie die Dokumentation für den von Ihnen gewählten JDBC-Treiber.

Initialisieren des Java-Schlüsselspeichers

Zum Initialisieren des import java.security.KeyStore-Objekts laden Sie die Schlüsselspeicherdatei mit dem Kennwort. Das Standardkennwort für beide Schlüsselspeicher lautet changeit.

KeyStore keyStore = KeyStore.getInstance("jks");
keyStore.load(
    new FileInputStream(System.getenv("JRE_HOME")+"/lib/security/cacerts"),
    "changeit".toCharArray());

KeyStore keyStore = KeyStore.getInstance("pkcs12");
keyStore.load(
    new FileInputStream(System.getenv("JRE_HOME")+"/lib/security/client.jks"),
    "changeit".toCharArray());

Manuelles Laden des Schlüsselspeichers

Sie können Zertifikate manuell in den Schlüsselspeicher laden. Erstellen Sie die App-Einstellung SKIP_JAVA_KEYSTORE_LOAD mit dem Wert 1, damit die Zertifikate nicht automatisch von App Service in den Keystore geladen werden. Alle öffentlichen Zertifikate, die über das Azure-Portal in App Service hochgeladen werden, werden unter /var/ssl/certs/ gespeichert. Private Zertifikate werden unter /var/ssl/private/ gespeichert.

Sie können mit dem Java-Schlüsseltool interagieren oder Debuggingschritte ausführen, indem Sie eine SSH-Verbindung mit Ihrer App Service-Instanz herstellen und den Befehl keytoolausführen. Eine Liste mit Befehlen finden Sie in der Dokumentation des Schlüsseltools. Weitere Informationen über die KeyStore-API finden Sie in der offiziellen Dokumentation.

Konfigurieren von APM-Plattformen

In diesem Abschnitt wird veranschaulicht, wie Sie Java-Anwendungen, die in Azure App Service mit Azure Monitor Application Insights bereitgestellt werden, mit den Plattformen NewRelic und AppDynamics für die Überwachung der Anwendungsleistung (Application Performance Monitoring, APM) verbinden.

Application Insights konfigurieren

Azure Monitor Application Insights ist ein Cloud-nativer Anwendungsüberwachungsdienst, der es Kunden ermöglicht, Ausfälle, Engpässe und Nutzungsmuster zu beobachten, um die Anwendungsleistung zu verbessern und die mittlere Zeit bis zur Lösung (MTTR) zu reduzieren. Mit wenigen Mausklicks oder CLI-Befehlen können Sie die Überwachung für Ihre Node.js- oder Java-Apps aktivieren, wobei Protokolle, Metriken und verteilte Ablaufverfolgungen automatisch erfasst werden, sodass Sie in Ihrer App kein SDK bereitstellen müssen. Weitere Informationen zu den verfügbaren App-Einstellungen zum Konfigurieren des Agents finden Sie in der Application Insights-Dokumentation.

Azure-Portal

Um Application Insights über das Azure-Portal zu aktivieren, wechseln Sie im Menü auf der linken Seite zu Application Insights und wählen Application Insights aktivieren aus. Standardmäßig wird eine neue Application Insights-Ressource mit demselben Namen wie Ihre Web-App verwendet. Sie können eine vorhandene Application Insights-Ressource verwenden oder den Namen ändern. Wählen Sie unten Anwenden aus.

Azure CLI

Zum Aktivieren über die Azure CLI müssen Sie eine Application Insights-Ressource erstellen und einige App-Einstellungen im Azure-Portal festlegen, um Application Insights mit Ihrer Web-App zu verbinden.

  1. Aktivieren der Applications Insights-Erweiterung

    az extension add -n application-insights

  2. Erstellen Sie mit dem folgenden CLI-Befehl eine Application Insights-Ressource. Ersetzen Sie die Platzhalter durch Ihren gewünschten Ressourcennamen und die Gruppe.

    az monitor app-insights component create --app <resource-name> -g <resource-group> --location westus2  --kind web --application-type web

    Notieren Sie sich die Werte für connectionString und instrumentationKey. Sie benötigen diese Werte im nächsten Schritt.

    Um eine Liste anderer Standorte abzurufen, führen Sie az account list-locations aus.

  1. Legen Sie den Instrumentierungsschlüssel, die Verbindungszeichenfolge und die Version des Überwachungs-Agents als App-Einstellungen für die Web-App fest. Ersetzen Sie <instrumentationKey> und <connectionString> durch die Werte aus dem vorherigen Schritt.

    az webapp config appsettings set -n <webapp-name> -g <resource-group> --settings "APPINSIGHTS_INSTRUMENTATIONKEY=<instrumentationKey>" "APPLICATIONINSIGHTS_CONNECTION_STRING=<connectionString>" "ApplicationInsightsAgent_EXTENSION_VERSION=~3" "XDT_MicrosoftApplicationInsights_Mode=default" "XDT_MicrosoftApplicationInsights_Java=1"

  1. Legen Sie den Instrumentierungsschlüssel, die Verbindungszeichenfolge und die Version des Überwachungs-Agents als App-Einstellungen für die Web-App fest. Ersetzen Sie <instrumentationKey> und <connectionString> durch die Werte aus dem vorherigen Schritt.

    az webapp config appsettings set -n <webapp-name> -g <resource-group> --settings "APPINSIGHTS_INSTRUMENTATIONKEY=<instrumentationKey>" "APPLICATIONINSIGHTS_CONNECTION_STRING=<connectionString>" "ApplicationInsightsAgent_EXTENSION_VERSION=~3" "XDT_MicrosoftApplicationInsights_Mode=default"

Konfigurieren von NewRelic

  1. Erstellen Sie ein NewRelic-Konto unter NewRelic.com.

  2. Laden Sie den Java-Agent von NewRelic herunter. Der Dateiname hat das Format newrelic-java-x.x.x.zip.

  3. Kopieren Sie Ihren Lizenzschlüssel. Sie benötigen ihn später zum Konfigurieren des Agents.

  4. Stellen Sie eine SSH-Verbindung mit Ihrer App Service-Instanz her, und erstellen Sie das neue Verzeichnis /home/site/wwwroot/apm.

  5. Laden Sie die entpackten Dateien für den NewRelic-Java-Agent in ein Verzeichnis unter /home/site/wwwroot/apm herunter. Die Dateien für Ihren Agenten sollten Sie unter /home/site/wwwroot/apm/newrelic finden.

  6. Ändern Sie die YAML-Datei unter /home/site/wwwroot/apm/newrelic/newrelic.yml, und ersetzen Sie den Platzhalter-Lizenzwert durch Ihren eigenen Lizenzschlüssel.

  7. Navigieren Sie im Azure-Portal zu Ihrer Anwendung in App Service, und erstellen Sie eine neue Anwendungseinstellung.

    • Erstellen Sie für Java SE-Apps eine Umgebungsvariable namens JAVA_OPTS mit dem Wert -javaagent:/home/site/wwwroot/apm/newrelic/newrelic.jar.
    • Erstellen Sie für Tomcat-Apps eine Umgebungsvariable namens CATALINA_OPTS mit dem Wert -javaagent:/home/site/wwwroot/apm/newrelic/newrelic.jar.

  1. Erstellen Sie ein NewRelic-Konto unter NewRelic.com.

  2. Laden Sie den Java-Agent von NewRelic herunter. Der Dateiname hat das Format newrelic-java-x.x.x.zip.

  3. Kopieren Sie Ihren Lizenzschlüssel. Sie benötigen ihn später zum Konfigurieren des Agents.

  4. Stellen Sie eine SSH-Verbindung mit Ihrer App Service-Instanz her, und erstellen Sie das neue Verzeichnis /home/site/wwwroot/apm.

  5. Laden Sie die entpackten Dateien für den NewRelic-Java-Agent in ein Verzeichnis unter /home/site/wwwroot/apm herunter. Die Dateien für Ihren Agenten sollten Sie unter /home/site/wwwroot/apm/newrelic finden.

  6. Ändern Sie die YAML-Datei unter /home/site/wwwroot/apm/newrelic/newrelic.yml, und ersetzen Sie den Platzhalter-Lizenzwert durch Ihren eigenen Lizenzschlüssel.

  7. Navigieren Sie im Azure-Portal zu Ihrer Anwendung in App Service, und erstellen Sie eine neue Anwendungseinstellung.

    • Erstellen Sie für Java SE-Apps eine Umgebungsvariable namens JAVA_OPTS mit dem Wert -javaagent:/home/site/wwwroot/apm/newrelic/newrelic.jar.
    • Erstellen Sie für Tomcat-Apps eine Umgebungsvariable namens CATALINA_OPTS mit dem Wert -javaagent:/home/site/wwwroot/apm/newrelic/newrelic.jar.

Falls Sie bereits über eine Umgebungsvariable für JAVA_OPTS oder CATALINA_OPTS verfügen, können Sie die Option -javaagent:/... am Ende des aktuellen Werts anhängen.

Konfigurieren von AppDynamics

  1. Erstellen Sie unter AppDynamics.com ein AppDynamics-Konto.

  2. Laden Sie den Java-Agent von der AppDynamics-Website herunter. Der Dateiname hat das Format AppServerAgent-x.x.x.xxxxx.zip

  3. Verwenden Sie die Kudu-Konsole, um ein neues Verzeichnis namens /home/site/wwwroot/apm zu erstellen.

  4. Laden Sie die Dateien für den Java-Agent in ein Verzeichnis unter /home/site/wwwroot/apm herunter. Die Dateien für Ihren Agenten sollten Sie unter /home/site/wwwroot/apm/appdynamics finden.

  5. Navigieren Sie im Azure-Portal zu Ihrer Anwendung in App Service, und erstellen Sie eine neue Anwendungseinstellung.

    • Erstellen Sie für Java SE-Apps eine Umgebungsvariable namens JAVA_OPTS mit dem Wert -javaagent:/home/site/wwwroot/apm/appdynamics/javaagent.jar -Dappdynamics.agent.applicationName=<app-name>, wobei <app-name> für Ihren App Service-Namen steht.
    • Erstellen Sie für Tomcat-Apps eine Umgebungsvariable namens CATALINA_OPTS mit dem Wert -javaagent:/home/site/wwwroot/apm/appdynamics/javaagent.jar -Dappdynamics.agent.applicationName=<app-name>, wobei <app-name> für Ihren App Service-Namen steht.

  1. Erstellen Sie unter AppDynamics.com ein AppDynamics-Konto.

  2. Laden Sie den Java-Agent von der AppDynamics-Website herunter. Der Dateiname hat das Format AppServerAgent-x.x.x.xxxxx.zip

  3. Stellen Sie eine SSH-Verbindung mit Ihrer App Service-Instanz her, und erstellen Sie das neue Verzeichnis /home/site/wwwroot/apm.

  4. Laden Sie die Dateien für den Java-Agent in ein Verzeichnis unter /home/site/wwwroot/apm herunter. Die Dateien für Ihren Agenten sollten Sie unter /home/site/wwwroot/apm/appdynamics finden.

  5. Navigieren Sie im Azure-Portal zu Ihrer Anwendung in App Service, und erstellen Sie eine neue Anwendungseinstellung.

    • Erstellen Sie für Java SE-Apps eine Umgebungsvariable namens JAVA_OPTS mit dem Wert -javaagent:/home/site/wwwroot/apm/appdynamics/javaagent.jar -Dappdynamics.agent.applicationName=<app-name>, wobei <app-name> für Ihren App Service-Namen steht.
    • Erstellen Sie für Tomcat-Apps eine Umgebungsvariable namens CATALINA_OPTS mit dem Wert -javaagent:/home/site/wwwroot/apm/appdynamics/javaagent.jar -Dappdynamics.agent.applicationName=<app-name>, wobei <app-name> für Ihren App Service-Namen steht.

Hinweis

Falls Sie bereits über eine Umgebungsvariable für JAVA_OPTS oder CATALINA_OPTS verfügen, können Sie die Option -javaagent:/... am Ende des aktuellen Werts anhängen.

Konfigurieren von Datenquellen

Java SE

Für das Verbinden mit Datenquellen in Spring Boot-Anwendungen wird empfohlen, Verbindungszeichenfolgen zu erstellen und in Ihre Datei application.properties einzufügen.

  1. Legen Sie auf der App Service-Seite im Abschnitt „Konfiguration“ einen Namen für die Zeichenfolge fest, fügen Sie Ihre JDBC-Verbindungszeichenfolge in das Feld für den Wert ein, und legen Sie den Typ auf „Benutzerdefiniert“ fest. Sie können diese Verbindungszeichenfolge optional als Sloteinstellung festlegen.

    Diese Verbindungszeichenfolge ist für die Anwendung als die Umgebungsvariable CUSTOMCONNSTR_<your-string-name> verfügbar. Beispiel: CUSTOMCONNSTR_exampledb.

  2. Verweisen Sie in Ihrer Datei application.properties über den Namen der Umgebungsvariable auf diese Verbindungszeichenfolge. In unserem Beispiel würden wir Folgendes verwenden.

    app.datasource.url=${CUSTOMCONNSTR_exampledb}

Weitere Informationen finden Sie in der Spring Boot-Dokumentation zum Datenzugriff und unter externalisierte Konfigurationen.

Tomcat

Diese Anweisungen gelten für alle Datenbankverbindungen. Für die Platzhalter müssen der Treiberklassenname und die JAR-Datei der ausgewählten Datenbank angegeben werden. In der folgenden Tabelle finden Sie Klassennamen und Treiberdownloads für gängige Datenbanken:

Datenbank Treiberklassenname JDBC-Treiber
PostgreSQL org.postgresql.Driver Download
MySQL com.mysql.jdbc.Driver Download (Wählen Sie „Platform Independent“ (Plattformunabhängig) aus.)
SQL Server com.microsoft.sqlserver.jdbc.SQLServerDriver Download

Wenn Sie Tomcat für die Verwendung von Java Database Connectivity (JDBC) oder der Java-Persistenz-API (JPA) konfigurieren möchten, passen Sie zuerst die Umgebungsvariable CATALINA_OPTS an, die von Tomcat beim Start eingelesen wird. Diese Werte können mithilfe einer App-Einstellung im App Service-Maven-Plug-In festgelegt werden:

<appSettings>
    <property>
        <name>CATALINA_OPTS</name>
        <value>"$CATALINA_OPTS -Ddbuser=${DBUSER} -Ddbpassword=${DBPASSWORD} -DconnURL=${CONNURL}"</value>
    </property>
</appSettings>

Alternativ können Sie die Umgebungsvariablen im Azure-Portal auf der Seite Konfiguration>Anwendungseinstellungen festlegen.

Legen Sie als Nächstes fest, ob die Datenquelle nur für eine einzelne Anwendung oder für alle im Tomcat-Servlet ausgeführten Anwendungen verfügbar sein soll.

Datenquellen auf Anwendungsebene

  1. Erstellen Sie eine context.xml-Datei im Verzeichnis META-INF/ Ihres Projekts. Erstellen Sie das Verzeichnis META-INF/, falls es noch nicht vorhanden ist.

  2. Fügen Sie in context.xml ein Element vom Typ Context hinzu, um die Datenquelle mit einer JNDI-Adresse zu verknüpfen. Ersetzen Sie den Platzhalter driverClassName durch den Klassennamen Ihres Treibers aus der obigen Tabelle.

    <Context>
    <Resource
        name="jdbc/dbconnection"
        type="javax.sql.DataSource"
        url="${connURL}"
        driverClassName="<insert your driver class name>"
        username="${dbuser}"
        password="${dbpassword}"
    />
</Context>

  3. Aktualisieren Sie die Datei web.xml Ihrer Anwendung, sodass die Datenquelle in Ihrer Anwendung verwendet wird.

    <resource-env-ref>
    <resource-env-ref-name>jdbc/dbconnection</resource-env-ref-name>
    <resource-env-ref-type>javax.sql.DataSource</resource-env-ref-type>
</resource-env-ref>

Gemeinsam verwendete Ressourcen auf Serverebene

Tomcat-Installationen auf App Service unter Windows sind im freigegebenen Bereich im App Service-Plan vorhanden. Sie können eine Tomcat-Installation nicht direkt für die serverweite Konfiguration ändern. Um Konfigurationsänderungen auf Serverebene an Ihrer Tomcat-Installation vorzunehmen, müssen Sie Tomcat in einen lokalen Ordner kopieren, in dem Sie die Konfiguration von Tomcat ändern können.

Automatisieren der Erstellung von benutzerdefiniertem Tomcat beim App-Start

Sie können ein Startskript verwenden, um Aktionen auszuführen, bevor eine Web-App gestartet wird. Das Startskript zum Anpassen von Tomcat muss die folgenden Schritte ausführen:

  1. Überprüfen, ob Tomcat bereits kopiert und lokal konfiguriert wurde. Wenn dies der Fall ist, kann das Startskript hier enden.
  2. Tomcat lokal kopieren.
  3. Die erforderlichen Konfigurationsänderungen vornehmen.
  4. Angeben, dass die Konfiguration erfolgreich abgeschlossen wurde.

Erstellen Sie für Windows-Apps im Verzeichnis wwwroot eine Datei mit dem Namen startup.cmd oder startup.ps1. Diese Datei wird automatisch ausgeführt, bevor der Tomcat-Server gestartet wird.

Hier sehen Sie ein PowerShell-Skript, mit dem diese Schritte ausgeführt werden:

    # Check for marker file indicating that config has already been done
    if(Test-Path "$Env:LOCAL_EXPANDED\tomcat\config_done_marker"){
        return 0
    }

    # Delete previous Tomcat directory if it exists
    # In case previous config isn't completed or a new config should be forcefully installed
    if(Test-Path "$Env:LOCAL_EXPANDED\tomcat"){
        Remove-Item "$Env:LOCAL_EXPANDED\tomcat" -Recurse
    }

    # Copy Tomcat to local
    # Using the environment variable $AZURE_TOMCAT90_HOME uses the 'default' version of Tomcat
    New-Item "$Env:LOCAL_EXPANDED\tomcat" -ItemType Directory
    Copy-Item -Path "$Env:AZURE_TOMCAT90_HOME\*" -Destination "$Env:LOCAL_EXPANDED\tomcat" -Recurse

    # Perform the required customization of Tomcat
    {... customization ...}

    # Mark that the operation was a success
    New-Item -Path "$Env:LOCAL_EXPANDED\tomcat\config_done_marker" -ItemType File
Transformationen

Ein häufiger Anwendungsfall zum Anpassen einer Tomcat-Version ist das Ändern der Konfigurationsdateien server.xml, context.xml oder web.xml für Tomcat. App Service ändert diese Dateien bereits, um Plattformfunktionen zur Verfügung zu stellen. Um diese Funktionen weiterhin zu verwenden, ist es wichtig, den Inhalt dieser Dateien zu erhalten, wenn Sie Änderungen daran vornehmen. Um dies zu erreichen, wird empfohlen, eine XSL-Transformation (XSLT) zu verwenden. Verwenden Sie eine XSL-Transformation, um Änderungen an den XML-Dateien vorzunehmen, während der ursprüngliche Inhalt der Datei beibehalten wird.

XSLT-Beispieldatei

Diese Beispieltransformation fügt einen neuen Connector-Knoten zu server.xml hinzu. Beachten Sie die Identitätstransformation, die den ursprünglichen Inhalt der Datei beibehält.

    <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
    <xsl:output method="xml" indent="yes"/>

    <!-- Identity transform: this ensures that the original contents of the file are included in the new file -->
    <!-- Ensure that your transform files include this block -->
    <xsl:template match="@* | node()" name="Copy">
      <xsl:copy>
        <xsl:apply-templates select="@* | node()"/>
      </xsl:copy>
    </xsl:template>

    <xsl:template match="@* | node()" mode="insertConnector">
      <xsl:call-template name="Copy" />
    </xsl:template>

    <xsl:template match="comment()[not(../Connector[@scheme = 'https']) and
                                   contains(., '&lt;Connector') and
                                   (contains(., 'scheme=&quot;https&quot;') or
                                    contains(., &quot;scheme='https'&quot;))]">
      <xsl:value-of select="." disable-output-escaping="yes" />
    </xsl:template>

    <xsl:template match="Service[not(Connector[@scheme = 'https'] or
                                     comment()[contains(., '&lt;Connector') and
                                               (contains(., 'scheme=&quot;https&quot;') or
                                                contains(., &quot;scheme='https'&quot;))]
                                    )]
                        ">
      <xsl:copy>
        <xsl:apply-templates select="@* | node()" mode="insertConnector" />
      </xsl:copy>
    </xsl:template>

    <!-- Add the new connector after the last existing Connnector if there's one -->
    <xsl:template match="Connector[last()]" mode="insertConnector">
      <xsl:call-template name="Copy" />

      <xsl:call-template name="AddConnector" />
    </xsl:template>

    <!-- ... or before the first Engine if there's no existing Connector -->
    <xsl:template match="Engine[1][not(preceding-sibling::Connector)]"
                  mode="insertConnector">
      <xsl:call-template name="AddConnector" />

      <xsl:call-template name="Copy" />
    </xsl:template>

    <xsl:template name="AddConnector">
      <!-- Add new line -->
      <xsl:text>&#xa;</xsl:text>
      <!-- This is the new connector -->
      <Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true" 
                 maxThreads="150" scheme="https" secure="true" 
                 keystoreFile="${{user.home}}/.keystore" keystorePass="changeit"
                 clientAuth="false" sslProtocol="TLS" />
    </xsl:template>

    </xsl:stylesheet>
Funktion für XSL-Transformation

PowerShell verfügt über integrierte Tools zum Transformieren von XML-Dateien mithilfe von XSL-Transformationen. Das folgende Skript ist eine Beispielfunktion, die Sie in startup.ps1 verwenden können, um die Transformation auszuführen:

    function TransformXML{
        param ($xml, $xsl, $output)

        if (-not $xml -or -not $xsl -or -not $output)
        {
            return 0
        }

        Try
        {
            $xslt_settings = New-Object System.Xml.Xsl.XsltSettings;
            $XmlUrlResolver = New-Object System.Xml.XmlUrlResolver;
            $xslt_settings.EnableScript = 1;

            $xslt = New-Object System.Xml.Xsl.XslCompiledTransform;
            $xslt.Load($xsl,$xslt_settings,$XmlUrlResolver);
            $xslt.Transform($xml, $output);

        }

        Catch
        {
            $ErrorMessage = $_.Exception.Message
            $FailedItem = $_.Exception.ItemName
            Write-Host  'Error'$ErrorMessage':'$FailedItem':' $_.Exception;
            return 0
        }
        return 1
    }
App-Einstellungen

Der Plattform muss auch bekannt sein, wo Ihre benutzerdefinierte Version von Tomcat installiert ist. Sie können den Speicherort der Installation in der CATALINA_BASE App-Einstellung festlegen.

Sie können die Azure CLI (Azure-Befehlszeilenschnittstelle) nutzen, um diese Einstellung zu ändern:

    az webapp config appsettings set -g $MyResourceGroup -n $MyUniqueApp --settings CATALINA_BASE="%LOCAL_EXPANDED%\tomcat"

Alternativ können Sie die Einstellung im Azure-Portal manuell ändern:

  1. Gehen Sie zu Einstellungen>Konfiguration>Anwendungseinstellungen.
  2. Wählen Sie Neue Anwendungseinstellung aus.
  3. Verwenden Sie folgende Werte, um die Einstellung zu erstellen:
    1. Name: CATALINA_BASE
    2. Wert: "%LOCAL_EXPANDED%\tomcat"
Beispiel: „startup.ps1“

Das folgende Beispielskript kopiert einen benutzerdefinierten Tomcat in einen lokalen Ordner, führt eine XSL-Transformation aus und gibt an, dass die Transformation erfolgreich war:

    # Locations of xml and xsl files
    $target_xml="$Env:LOCAL_EXPANDED\tomcat\conf\server.xml"
    $target_xsl="$Env:HOME\site\server.xsl"

    # Define the transform function
    # Useful if transforming multiple files
    function TransformXML{
        param ($xml, $xsl, $output)

        if (-not $xml -or -not $xsl -or -not $output)
        {
            return 0
        }

        Try
        {
            $xslt_settings = New-Object System.Xml.Xsl.XsltSettings;
            $XmlUrlResolver = New-Object System.Xml.XmlUrlResolver;
            $xslt_settings.EnableScript = 1;

            $xslt = New-Object System.Xml.Xsl.XslCompiledTransform;
            $xslt.Load($xsl,$xslt_settings,$XmlUrlResolver);
            $xslt.Transform($xml, $output);
        }

        Catch
        {
            $ErrorMessage = $_.Exception.Message
            $FailedItem = $_.Exception.ItemName
            echo  'Error'$ErrorMessage':'$FailedItem':' $_.Exception;
            return 0
        }
        return 1
    }

    $success = TransformXML -xml $target_xml -xsl $target_xsl -output $target_xml

    # Check for marker file indicating that config has already been done
    if(Test-Path "$Env:LOCAL_EXPANDED\tomcat\config_done_marker"){
        return 0
    }

    # Delete previous Tomcat directory if it exists
    # In case previous config isn't completed or a new config should be forcefully installed
    if(Test-Path "$Env:LOCAL_EXPANDED\tomcat"){
        Remove-Item "$Env:LOCAL_EXPANDED\tomcat" --recurse
    }

    md -Path "$Env:LOCAL_EXPANDED\tomcat"

    # Copy Tomcat to local
    # Using the environment variable $AZURE_TOMCAT90_HOME uses the 'default' version of Tomcat
    Copy-Item -Path "$Env:AZURE_TOMCAT90_HOME\*" "$Env:LOCAL_EXPANDED\tomcat" -Recurse

    # Perform the required customization of Tomcat
    $success = TransformXML -xml $target_xml -xsl $target_xsl -output $target_xml

    # Mark that the operation was a success if successful
    if($success){
        New-Item -Path "$Env:LOCAL_EXPANDED\tomcat\config_done_marker" -ItemType File
    }

Abschließen der Konfiguration

Platzieren Sie abschließend die JAR-Dateien des Treibers im Tomcat-Klassenpfad, und starten Sie Ihre App Service-Instanz neu. Stellen Sie sicher, dass die JDBC-Treiberdateien für den Tomcat-Klassenladeprogramm verfügbar sind, indem Sie sie im Verzeichnis /home/site/lib ablegen. Führen Sie in der Cloud Shell az webapp deploy --type=lib für jede Treiber-JAR-Datei aus:

az webapp deploy --resource-group <group-name> --name <app-name> --src-path <jar-name>.jar --type=lib --target-path <jar-name>.jar

Tomcat

Diese Anweisungen gelten für alle Datenbankverbindungen. Für die Platzhalter müssen der Treiberklassenname und die JAR-Datei der ausgewählten Datenbank angegeben werden. In der folgenden Tabelle finden Sie Klassennamen und Treiberdownloads für gängige Datenbanken:

Datenbank Treiberklassenname JDBC-Treiber
PostgreSQL org.postgresql.Driver Download
MySQL com.mysql.jdbc.Driver Download (Wählen Sie „Platform Independent“ (Plattformunabhängig) aus.)
SQL Server com.microsoft.sqlserver.jdbc.SQLServerDriver Download

Wenn Sie Tomcat für die Verwendung von Java Database Connectivity (JDBC) oder der Java-Persistenz-API (JPA) konfigurieren möchten, passen Sie zuerst die Umgebungsvariable CATALINA_OPTS an, die von Tomcat beim Start eingelesen wird. Diese Werte können mithilfe einer App-Einstellung im App Service-Maven-Plug-In festgelegt werden:

<appSettings>
    <property>
        <name>CATALINA_OPTS</name>
        <value>"$CATALINA_OPTS -Ddbuser=${DBUSER} -Ddbpassword=${DBPASSWORD} -DconnURL=${CONNURL}"</value>
    </property>
</appSettings>

Alternativ können Sie die Umgebungsvariablen im Azure-Portal auf der Seite Konfiguration>Anwendungseinstellungen festlegen.

Legen Sie als Nächstes fest, ob die Datenquelle nur für eine einzelne Anwendung oder für alle im Tomcat-Servlet ausgeführten Anwendungen verfügbar sein soll.

Datenquellen auf Anwendungsebene

  1. Erstellen Sie eine context.xml-Datei im Verzeichnis META-INF/ Ihres Projekts. Erstellen Sie das Verzeichnis META-INF/, falls es noch nicht vorhanden ist.

  2. Fügen Sie in context.xml ein Element vom Typ Context hinzu, um die Datenquelle mit einer JNDI-Adresse zu verknüpfen. Ersetzen Sie den Platzhalter driverClassName durch den Klassennamen Ihres Treibers aus der obigen Tabelle.

    <Context>
    <Resource
        name="jdbc/dbconnection"
        type="javax.sql.DataSource"
        url="${connURL}"
        driverClassName="<insert your driver class name>"
        username="${dbuser}"
        password="${dbpassword}"
    />
</Context>

  3. Aktualisieren Sie die Datei web.xml Ihrer Anwendung, sodass die Datenquelle in Ihrer Anwendung verwendet wird.

    <resource-env-ref>
    <resource-env-ref-name>jdbc/dbconnection</resource-env-ref-name>
    <resource-env-ref-type>javax.sql.DataSource</resource-env-ref-type>
</resource-env-ref>

Gemeinsam verwendete Ressourcen auf Serverebene

Wenn Sie eine freigegebene Datenquelle auf Serverebene hinzufügen, müssen Sie die Datei „server.xml“ von Tomcat bearbeiten. Laden Sie zunächst ein Startskript hoch, und legen Sie unter Konfiguration>Startbefehl den Pfad des Skripts fest. Das Startskript kann per FTP hochgeladen werden.

Ihr Startskript führt eine XSL-Transformation für die Datei „server.xml“ durch und gibt die resultierende XML-Datei unter /usr/local/tomcat/conf/server.xml aus. Das Startskript muss „libxslt“ per APK installieren. Die XSL-Datei und das Startskript können per FTP hochgeladen werden. Im Anschluss finden Sie ein Beispiel für ein Startskript:

# Install libxslt. Also copy the transform file to /home/tomcat/conf/
apk add --update libxslt

# Usage: xsltproc --output output.xml style.xsl input.xml
xsltproc --output /home/tomcat/conf/server.xml /home/tomcat/conf/transform.xsl /usr/local/tomcat/conf/server.xml

Die folgende XSL-Beispieldatei fügt der Datei „server.xml“ von Tomcat einen neuen Connectorknoten hinzu.

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:output method="xml" indent="yes"/>

  <xsl:template match="@* | node()" name="Copy">
    <xsl:copy>
      <xsl:apply-templates select="@* | node()"/>
    </xsl:copy>
  </xsl:template>

  <xsl:template match="@* | node()" mode="insertConnector">
    <xsl:call-template name="Copy" />
  </xsl:template>

  <xsl:template match="comment()[not(../Connector[@scheme = 'https']) and
                                 contains(., '&lt;Connector') and
                                 (contains(., 'scheme=&quot;https&quot;') or
                                  contains(., &quot;scheme='https'&quot;))]">
    <xsl:value-of select="." disable-output-escaping="yes" />
  </xsl:template>

  <xsl:template match="Service[not(Connector[@scheme = 'https'] or
                                   comment()[contains(., '&lt;Connector') and
                                             (contains(., 'scheme=&quot;https&quot;') or
                                              contains(., &quot;scheme='https'&quot;))]
                                  )]
                      ">
    <xsl:copy>
      <xsl:apply-templates select="@* | node()" mode="insertConnector" />
    </xsl:copy>
  </xsl:template>

  <!-- Add the new connector after the last existing Connnector if there's one -->
  <xsl:template match="Connector[last()]" mode="insertConnector">
    <xsl:call-template name="Copy" />

    <xsl:call-template name="AddConnector" />
  </xsl:template>

  <!-- ... or before the first Engine if there's no existing Connector -->
  <xsl:template match="Engine[1][not(preceding-sibling::Connector)]"
                mode="insertConnector">
    <xsl:call-template name="AddConnector" />

    <xsl:call-template name="Copy" />
  </xsl:template>

  <xsl:template name="AddConnector">
    <!-- Add new line -->
    <xsl:text>&#xa;</xsl:text>
    <!-- This is the new connector -->
    <Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true" 
               maxThreads="150" scheme="https" secure="true" 
               keystoreFile="${{user.home}}/.keystore" keystorePass="changeit"
               clientAuth="false" sslProtocol="TLS" />
  </xsl:template>

</xsl:stylesheet>

Abschließen der Konfiguration

Platzieren Sie abschließend die JAR-Dateien des Treibers im Tomcat-Klassenpfad, und starten Sie Ihre App Service-Instanz neu.

  1. Stellen Sie sicher, dass die JDBC-Treiberdateien für den Tomcat-Klassenladeprogramm verfügbar sind, indem Sie sie im Verzeichnis /home/site/lib ablegen. Führen Sie in der Cloud Shell az webapp deploy --type=lib für jede Treiber-JAR-Datei aus:
az webapp deploy --resource-group <group-name> --name <app-name> --src-path <jar-name>.jar --type=lib --path <jar-name>.jar

Wenn Sie eine Datenquelle auf Serverebene erstellt haben, starten Sie die App Service-Linux-Anwendung neu. Tomcat setzt CATALINA_BASE auf /home/tomcat zurück und verwendet die aktualisierte Konfiguration.

JBoss EAP-Datenquellen

Das Registrieren einer Datenquelle in JBoss EAP umfasst drei Hauptschritte: Hochladen des JDBC-Treibers, Hinzufügen des JDBC-Treibers als Modul und Registrieren des Moduls. App Service ist ein zustandsloser Hostingdienst, weshalb die Konfigurationsbefehle zum Hinzufügen und Registrieren des Datenquellenmoduls als Skript geschrieben und beim Start des Containers angewendet werden müssen.

  1. Rufen Sie den JDBC-Treiber Ihrer Datenbank ab.

  2. Erstellen Sie eine XML-Moduldefinitionsdatei für den JDBC-Treiber. Das folgende Beispiel zeigt eine Moduldefinition für PostgreSQL.

    <?xml version="1.0" ?>
<module xmlns="urn:jboss:module:1.1" name="org.postgres">
    <resources>
    <!-- ***** IMPORTANT : REPLACE THIS PLACEHOLDER *******-->
    <resource-root path="/home/site/deployments/tools/postgresql-42.2.12.jar" />
    </resources>
    <dependencies>
        <module name="javax.api"/>
        <module name="javax.transaction.api"/>
    </dependencies>
</module>

  3. Fügen Sie Ihre JBoss-CLI-Befehle in eine Datei namens jboss-cli-commands.cli ein. Die JBoss-Befehle müssen das Modul hinzufügen und es als Datenquelle registrieren. Das folgende Beispiel zeigt die JBoss-CLI-Befehle für PostgreSQL.

    #!/usr/bin/env bash
module add --name=org.postgres --resources=/home/site/deployments/tools/postgresql-42.2.12.jar --module-xml=/home/site/deployments/tools/postgres-module.xml

/subsystem=datasources/jdbc-driver=postgres:add(driver-name="postgres",driver-module-name="org.postgres",driver-class-name=org.postgresql.Driver,driver-xa-datasource-class-name=org.postgresql.xa.PGXADataSource)

data-source add --name=postgresDS --driver-name=postgres --jndi-name=java:jboss/datasources/postgresDS --connection-url=${POSTGRES_CONNECTION_URL,env.POSTGRES_CONNECTION_URL:jdbc:postgresql://db:5432/postgres} --user-name=${POSTGRES_SERVER_ADMIN_FULL_NAME,env.POSTGRES_SERVER_ADMIN_FULL_NAME:postgres} --password=${POSTGRES_SERVER_ADMIN_PASSWORD,env.POSTGRES_SERVER_ADMIN_PASSWORD:example} --use-ccm=true --max-pool-size=5 --blocking-timeout-wait-millis=5000 --enabled=true --driver-class=org.postgresql.Driver --exception-sorter-class-name=org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter --jta=true --use-java-context=true --valid-connection-checker-class-name=org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker

  4. Erstellen Sie ein Startskript namens startup_script.sh, das die JBoss-CLI-Befehle aufruft. Das folgende Beispiel zeigt, wie Sie jboss-cli-commands.cli aufrufen. Später konfigurieren Sie App Service dazu, dieses Skript beim Starten des Containers auszuführen.

    $JBOSS_HOME/bin/jboss-cli.sh --connect --file=/home/site/deployments/tools/jboss-cli-commands.cli

  5. Wenn Sie einen FTP-Client Ihrer Wahl verwenden, laden Sie Ihren JDBC-Treiber, jboss-cli-commands.cli, startup_script.sh und die Moduldefinition in /site/deployments/tools/ hoch.

  6. Konfigurieren Sie Ihre Website so, dass sie startup_script.sh beim Start des Containers ausführt. Navigieren Sie im Azure-Portal zu Konfiguration>Allgemeine Einstellungen>Startbefehl. Legen Sie das Feld „Startbefehl“ auf /home/site/deployments/tools/startup_script.sh fest. Speichern Sie die Änderungen.

Um sich zu vergewissern, dass die Datenquelle dem JBoss-Server hinzugefügt wurde, stellen Sie eine SSH-Verbindung mit Ihrer Web-App her, und führen Sie $JBOSS_HOME/bin/jboss-cli.sh --connect aus. Sobald Sie mit JBoss verbunden sind, führen Sie /subsystem=datasources:read-resource aus, um eine Liste der Datenquellen auszugeben.

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

JBoss EAP

Clustering in JBoss EAP

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

Hinweis

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

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

Hinweis

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

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

Regeln für die Autoskalierung

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

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

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

JBoss EAP App Service-Pläne

JBoss EAP ist nur für die App Service-Plantypen „Premium v3“ und „Isoliert v2“ verfügbar. Kunden, die während der öffentlichen Vorschauphase eine JBoss EAP-Site in einem anderen Tarif erstellt haben, sollten auf die Hardwareebene „Premium“ oder „Isoliert“ hochskalieren, um unerwartetes Verhalten zu vermeiden.

Tomcat-Baseline-Konfiguration in App Services

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

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

Connector

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

Hinweis

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

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

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

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

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

Host

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

Ventil

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

Unter Linux weist es dieselben Anpassungen auf, sowie:

  • Fügt dem Ventil einige Fehler- und Berichterstellungsseiten hinzu:
               <xsl:attribute name="appServiceErrorPage">
                   <xsl:value-of select="'${appService.valves.appServiceErrorPage}'"/>
               </xsl:attribute>

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

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

Nächste Schritte

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