Condividi tramite

Distribuire e configurare un'app Tomcat, JBoss o Java SE nel servizio app di Azure

  • Articolo

Questo articolo illustra la configurazione di distribuzione e runtime più comune per le app Java nel servizio app. Se il servizio app di Azure non è mai stato usato, è necessario leggere prima la guida introduttiva Java. Le domande generali sull'uso del servizio app non specifiche per lo sviluppo Java sono disponibili nelle domande frequenti sul servizio app.

Il servizio app di Azure esegue applicazioni Web Java in un servizio completamente gestito in tre varianti:

  • Java SE: può eseguire un'app distribuita come pacchetto JAR che contiene un server incorporato (ad esempio Spring Boot, Dropwizard, Quarkus o uno con un server Tomcat o Jetty incorporato).
  • Tomcat: il server Tomcat predefinito può eseguire un'app distribuita come pacchetto WAR.
  • JBoss EAP: supportato per le app Linux solo nei piani tariffari Premium v3 e Isolato v2. Il server JBoss EAP predefinito può eseguire un'app distribuita come pacchetto WAR o EAR.

Nota

Per le applicazioni Spring, è consigliabile usare Azure Spring Apps. Tuttavia, è comunque possibile usare il Servizio app di Azure come destinazione. Per consigli, vedere Indicazioni sulla destinazione del carico di lavoro Java.

Visualizzare la versione Java

Per visualizzare la versione corrente di Java, eseguire il comando seguente in Cloud Shell:

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

Per visualizzare tutte le versioni di Java supportate, eseguire il comando seguente in Cloud Shell:

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

Per altre informazioni sul supporto della versione, vedere Criteri di supporto del runtime del linguaggio del servizio app.

Distribuzione dell'app

Build Tools

Maven

Con il plug-in Maven per App Web di Azure, è possibile preparare facilmente il progetto Java Maven per App Web di Azure con un comando nella radice del progetto:

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

Questo comando aggiunge un plug-in azure-webapp-maven-plugin e la configurazione correlata richiedendo di selezionare un'app Web di Azure esistente o crearne una nuova. Durante la configurazione, tenta di rilevare se l'applicazione deve essere distribuita in Java SE, Tomcat o (solo Linux) JBoss EAP. Quindi è possibile distribuire l'app Java in Azure con il comando seguente:

mvn package azure-webapp:deploy

Ecco una configurazione di esempio in pom.xml:

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

Gradle

  1. Configurare il plug-in Gradle per app Web di Azure aggiungendo il plug-in a build.gradle:

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

  2. Configurare i dettagli dell'app Web. Le risorse di Azure corrispondenti vengono create se non esistono. Di seguito è riportato un esempio di configurazione. Per informazioni dettagliate, vedere questo documento.

    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. Eseguire la distribuzione con un unico comando.

    gradle azureWebAppDeploy

IDE

Azure offre un'esperienza di sviluppo ottimale del servizio app Java negli IDE Java più diffusi, tra cui:

API Kudu

Per distribuire file JAR in Java SE, usare l'endpoint /api/publish del sito Kudu. Per altre informazioni su questa API, vedere questa documentazione.

Nota

L'applicazione JAR deve essere denominata app.jar per consentire al servizio app di identificare ed eseguire l'applicazione. Il plug-in Maven esegue automaticamente questa operazione durante la distribuzione. Se non si vuole rinominare il file JAR in app.jar, è possibile caricare uno script della shell con il comando per eseguire l'app JAR. Incollare il percorso assoluto di questo script nella casella di testo File di avvio nella sezione Configurazione del portale. Lo script di avvio non viene eseguito dalla directory in cui si trova. Pertanto, usare sempre percorsi assoluti per fare riferimento ai file dello script di avvio, ad esempio java -jar /home/myapp/myapp.jar.

Per distribuire file con estensione war in Tomcat, usare l'endpoint /api/wardeploy/ per eseguire il comando POST per il file di archivio. Per altre informazioni su questa API, vedere questa documentazione.

Per distribuire file con estensione WAR in JBoss, usare l'endpoint /api/wardeploy/ per PUBBLICARE il file di archivio. Per altre informazioni su questa API, vedere questa documentazione.

Per distribuire file con estensione EAR, usare FTP. L'applicazione EAR viene distribuita nella radice del contesto definita nella configurazione dell'applicazione. Ad esempio, se la radice del contesto dell'app è <context-root>myapp</context-root>, è possibile esplorare il sito nel percorso /myapp: http://my-app-name.azurewebsites.net/myapp. Se si vuole che l'app Web venga servita nel percorso radice, assicurarsi che l'app imposti la radice del contesto sul percorso radice: <context-root>/</context-root>. Per altre informazioni, vedere Impostazione della radice del contesto di un'applicazione Web.

Non distribuire il file con estensione WAR o JAR tramite FTP. Lo strumento FTP è stato progettato per caricare script di avvio, dipendenze o altri file di runtime. Non è la scelta ottimale per la distribuzione di app Web.

Riscrivere o reindirizzare l'URL

Per riscrivere o reindirizzare l'URL, usare uno dei rewriter URL disponibili, ad esempio UrlRewriteFilter.

Tomcat fornisce anche una valvola di riscrittura.

JBoss fornisce anche una valvola di riscrittura.

Registrazione e debug delle app

Nel portale di Azure sono disponibili report sulle prestazioni, visualizzazioni del traffico e controlli dell'integrità per ogni app. Per altre informazioni, vedere Panoramica approfondita della diagnostica del Servizio app di Azure.

Eseguire lo streaming dei log di diagnostica

È possibile accedere ai log della console generati dall'interno del contenitore.

Prima di tutto attivare la registrazione del contenitore eseguendo questo comando:

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

Sostituire <app-name> e <resource-group-name> con i valori appropriati per l'app Web.

Dopo che la registrazione del contenitore è attivata, eseguire il comando seguente per visualizzare il flusso di registrazione:

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

Se i log di console non sono immediatamente visibili, controllare nuovamente dopo 30 secondi.

Per interrompere lo streaming dei log in qualsiasi momento, premere CTRL+C.

È anche possibile ispezionare i file di log in un browser all'indirizzo https://<app-name>.scm.azurewebsites.net/api/logs/docker.

Per altre informazioni, vedere Eseguire lo streaming dei log in Cloud Shell.

Accesso alla console SSH in Linux

Per aprire una sessione SSH diretta con il contenitore, l'app deve essere in esecuzione.

Incollare l'URL seguente nel browser e sostituire <app-name> con il nome dell'app:

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

Se non lo si è già fatto, per connettersi è necessario eseguire l'autenticazione con la sottoscrizione di Azure. Al termine dell'autenticazione viene visualizzata una shell nel browser, in cui è possibile eseguire i comandi all'interno del contenitore.

Connessione SSH

Nota

Le eventuali modifiche apportate all'esterno della directory /home vengono archiviate nel contenitore stesso e non persistono oltre il riavvio dell'app.

Per aprire una sessione SSH remota dal computer locale, vedere Aprire una sessione SSH dalla shell remota.

Strumento per la risoluzione dei problemi di Linux

Le immagini Java integrate sono basate sul sistema operativo Alpine Linux. Usare la gestione pacchetti apk per installare gli strumenti o i comandi per la risoluzione dei problemi.

Java Profiler

Tutti i runtime Java nel servizio app di Azure sono dotati di JDK Flight Recorder per la profilatura di carichi di lavoro Java. È possibile usarlo per registrare eventi di JVM, sistema e applicazioni e risolvere i problemi nelle applicazioni.

Per altre informazioni su Java Profiler, vedere la documentazione di Azure Application Insights.

Flight Recorder

Tutti i runtime Java nel servizio app sono dotati di Java Flight Recorder. È possibile usarli per registrare eventi di JVM, sistema e applicazioni e risolvere i problemi nelle applicazioni Java.

Eseguire SSH nel servizio app ed eseguire il comando jcmd per visualizzare un elenco di tutti i processi Java in esecuzione. Oltre a jcmd, l'applicazione Java dovrebbe essere in esecuzione con un numero ID processo (PID).

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

Eseguire il comando seguente per avviare una registrazione di 30 secondi della JVM. Esegue la profilatura della JVM e crea un file JFR denominato jfr_example.jfr nella home directory. (Sostituire 116 con il PID dell'app Java.)

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

Durante l'intervallo di 30 secondi, è possibile verificare che la registrazione avvenga eseguendo jcmd 116 JFR.check. Il comando mostra tutte le registrazioni per il processo Java specificato.

Registrazione continua

È possibile usare Java Flight Recorder per profilare continuamente l'applicazione Java con un impatto minimo sulle prestazioni di runtime. A tale scopo, eseguire il comando dell'interfaccia della riga di comando di Azure seguente per creare un'impostazione dell'app denominata JAVA_OPTS con la configurazione necessaria. Il contenuto dell'impostazione dell'app JAVA_OPTS viene trasmesso al comando java quando l'app viene avviata.

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

Dopo l'avvio della registrazione, è possibile eseguire il dump dei dati di registrazione correnti in qualsiasi momento usando il comando JFR.dump.

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

Analizzare i file .jfr

Usare FTPS per scaricare il file JFR nel computer locale. Per analizzare il file JFR, scaricare e installare Java Mission Control. Per istruzioni su Java Mission Control, vedere la documentazione di JMC e le istruzioni di installazione.

Registrazione dell'app

Abilitare la registrazione dell'applicazione tramite il portale di Azure o l'interfaccia della riga di comando di Azure per configurare il servizio app per scrivere l'output della console standard dell'applicazione e i flussi di errori della console standard nel file system locale o in Archiviazione BLOB di Azure. Se è necessario un periodo di conservazione più lungo, configurare l'applicazione per scrivere l'output in un contenitore di archiviazione BLOB.

I log delle app Java e Tomcat sono reperibili nella directory /home/LogFiles/Application/.

La registrazione di Archivio BLOB di Azure per le app basate su Linux può essere configurata solo usando Monitoraggio di Azure.

Se l'applicazione usa Logback o Log4j per la traccia, è possibile inoltrare queste tracce per la revisione ad Azure Application Insights usando le istruzioni di configurazione del framework di registrazione illustrate in Esplorare i log di traccia Java in Application Insights.

Nota

A causa della vulnerabilità nota CVE-2021-44228, assicurarsi di usare Log4j versione 2.16 o successiva.

Personalizzazione e ottimizzazione

Il servizio app di Azure supporta l'ottimizzazione e la personalizzazione predefinite tramite il portale di Azure e l'interfaccia della riga di comando. Per la configurazione delle app Web non specifiche di Java, vedere gli articoli seguenti:

Copiare il contenuto dell'app in locale

Configurare l'impostazione dell'app JAVA_COPY_ALL su true per copiare il contenuto dell'app nel ruolo di lavoro locale dal file system condiviso. Questa impostazione consente di risolvere i problemi di blocco dei file.

Impostare le opzioni di runtime Java

Per impostare la memoria allocata o altre opzioni di runtime JVM, creare un'impostazione dell'app denominata JAVA_OPTS con le opzioni. Il servizio app passa questa impostazione come variabile di ambiente al runtime Java all'avvio.

Nel portale di Azure, in Impostazioni applicazione per l'app Web creare una nuova impostazione dell'app denominata JAVA_OPTS che include altre impostazioni, ad esempio -Xms512m -Xmx1204m.

Nel portale di Azure, in Impostazioni applicazione per l'app Web creare una nuova impostazione dell'app denominata CATALINA_OPTS che include altre impostazioni, ad esempio -Xms512m -Xmx1204m.

Per configurare l'impostazione dell'app dal plug-in Maven, aggiungere i tag setting/value nella sezione dei plug-in di Azure. L'esempio seguente imposta le dimensioni heap Java specifiche minime e massime:

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

Nota

Non è necessario creare un file web.config quando si usa Tomcat nel servizio app di Windows.

Gli sviluppatori che eseguono una singola applicazione con uno slot di distribuzione nel piano di servizio app possono usare le opzioni seguenti:

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

Quando si ottimizzano le impostazioni heap delle applicazioni, esaminare i dettagli del piano di servizio app e tenere in considerazione le esigenze di più applicazioni e slot di distribuzione per trovare l'allocazione ottimale della memoria.

Attivare i Web Socket

Attivare il supporto per i Web Socket nel portale di Azure in Impostazioni applicazione per l'applicazione. È necessario riavviare l'applicazione per rendere effettiva l'impostazione.

Attivare il supporto per i Web Socket usando l'interfaccia della riga di comando di Azure con il comando seguente:

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

Riavviare quindi l'applicazione:

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

Impostare la codifica dei caratteri predefinita

Nel portale di Azure, sotto Impostazioni applicazione per l'app Web creare una nuova impostazione dell'app denominata JAVA_OPTS con il valore -Dfile.encoding=UTF-8.

In alternativa, è possibile configurare l'impostazione dell'app usando il plug-in Maven del servizio app. Aggiungere i tag name e value dell'impostazione nella configurazione del plug-in:

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

Pre-compilare i file JSP

Per migliorare le prestazioni delle applicazioni Tomcat, è possibile compilare i file JSP prima della distribuzione nel Servizio app di Azure. È possibile usare il plug-in Maven fornito da Apache Sling o questo file di compilazione Ant.

Nota

robots933456 nei log

È possibile che nei log del contenitore venga visualizzato il messaggio seguente:

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

Questo messaggio può tranquillamente essere ignorato. /robots933456.txt è un percorso URL fittizio usato dal servizio app per verificare se il contenitore è in grado di gestire le richieste. Una risposta 404 indica semplicemente che il percorso non esiste, ma consente al servizio app di capire che il contenitore è integro e pronto per rispondere alle richieste.

Scelta di una versione di runtime Java

Il servizio app consente agli utenti di scegliere la versione principale della JVM, ad esempio Java 8 o Java 11, e la versione della patch, ad esempio 1.8.0_232 o 11.0.5. È anche possibile scegliere di aggiornare automaticamente la versione della patch man mano che diventano disponibili nuove versioni secondarie. Nella maggior parte dei casi, le app di produzione devono usare versioni JVM con patch aggiunte. In questo modo si evitano interruzioni impreviste durante l'aggiornamento automatico di una versione patch. Tutte le app Web Java usano JVM a 64 bit e non sono configurabili.

Se si usa Tomcat, è possibile scegliere di aggiungere la versione patch di Tomcat. In Windows è possibile aggiungere le versioni patch di JVM e Tomcat in modo indipendente. In Linux è possibile aggiungere la versione patch di Tomcat; anche la versione patch della JVM viene aggiunta ma non è configurabile separatamente.

Se si sceglie di aggiungere la versione secondaria, è necessario aggiornare periodicamente la versione secondaria di JVM nell'app. Per assicurarsi che l'applicazione venga eseguita nella versione secondaria più recente, creare uno slot di staging e incrementare la versione secondaria nello slot di staging. Dopo aver verificato che l'applicazione venga eseguita correttamente nella nuova versione secondaria, è possibile scambiare gli slot di gestione temporanea e di produzione.

Cluster

Il servizio app supporta il clustering per JBoss EAP versioni 7.4.1 e successive. Per abilitare il clustering, l'app Web deve essere integrata con una rete virtuale. Quando l'app Web è integrata con una rete virtuale, viene riavviata e l'installazione di JBoss EAP viene avviata automaticamente con una configurazione in cluster. Le istanze di JBoss EAP comunicano sulla subnet specificata nell'integrazione della rete virtuale, usando le porte visualizzate nella variabile di ambiente WEBSITES_PRIVATE_PORTS in fase di esecuzione. È possibile disabilitare il clustering creando un'impostazione dell'app denominata WEBSITE_DISABLE_CLUSTERING con qualsiasi valore.

Nota

Se si abilita l'integrazione della rete virtuale con un modello di Resource Manager, è necessario impostare manualmente la proprietà vnetPrivatePorts su un valore di 2. Se si abilita l'integrazione della rete virtuale dall'interfaccia della riga di comando o dal portale, questa proprietà viene impostata automaticamente.

Quando il clustering è abilitato, le istanze JBoss EAP usano il protocollo di individuazione FILE_PING JGroups per individuare nuove istanze e rendere persistenti le informazioni del cluster, ad esempio i membri del cluster, i relativi identificatori e i relativi indirizzi IP. Nel servizio app questi file si trovano in /home/clusterinfo/. La prima istanza EAP da avviare ottiene le autorizzazioni di lettura/scrittura nel file di appartenenza al cluster. Altre istanze leggono il file, trovano il nodo primario e si coordinano con il nodo da includere nel cluster e aggiunte al file.

Nota

È possibile evitare timeout del clustering JBOSS pulendo i file di individuazione obsoleti durante l'avvio dell'app

I tipi di piano di servizio app Premium V3 e Isolated V2 possono essere distribuiti facoltativamente tra zone di disponibilità per migliorare la resilienza e l'affidabilità per i carichi di lavoro critici per l'azienda. Questa architettura è nota anche come ridondanza della zona. La funzionalità di clustering JBoss EAP è compatibile con la funzionalità di ridondanza della zona.

Regole di scalabilità automatica

Quando si configurano regole di scalabilità automatica per il ridimensionamento orizzontale, è importante rimuovere le istanze in modo incrementale (una alla volta) per assicurarsi che ogni istanza rimossa possa trasferire l'attività (ad esempio la gestione di una transazione di database) a un altro membro del cluster. Quando si configurano le regole di scalabilità automatica nel portale per ridurre le prestazioni, usare le opzioni seguenti:

  • Operazione: "Riduci conteggio per"
  • Disattivazione: "5 minuti" o superiore
  • Numero di istanze: 1

Non è necessario aggiungere istanze in modo incrementale (aumento del numero di istanze), è possibile aggiungere più istanze al cluster alla volta.

Piani del servizio app

JBoss EAP è disponibile nei piani tariffari seguenti: F1, P0v3, P1mv3, P2mv3, P3mv3, P4mv3 e P5mv3.

Configurazione della baseline Tomcat

Nota

Questa sezione si applica solo a Linux.

Gli sviluppatori Java possono personalizzare le impostazioni del server, risolvere i problemi e distribuire applicazioni in Tomcat con sicurezza se conoscono i dettagli di configurazione e file server.xml di Tomcat. Le possibili personalizzazioni includono:

  • Personalizzazione della configurazione di Tomcat: comprendendo i dettagli di configurazione di server.xml e Tomcat, è possibile ottimizzare le impostazioni del server in base alle esigenze delle applicazioni.
  • Debug: quando un'applicazione viene distribuita in un server Tomcat, gli sviluppatori devono conoscere la configurazione del server per eseguire il debug di eventuali problemi che potrebbero verificarsi. Sono inclusi il controllo dei log del server, l'analisi dei file di configurazione e l'identificazione di eventuali errori che potrebbero verificarsi.
  • Risoluzione dei problemi di Tomcat: inevitabilmente, gli sviluppatori Java riscontrano problemi con il server Tomcat, ad esempio problemi di prestazioni o errori di configurazione. Comprendendo i dettagli di configurazione del file di server.xml e Tomcat, gli sviluppatori possono diagnosticare e risolvere rapidamente questi problemi, risparmiando tempo e fatica.
  • Distribuzione di applicazioni in Tomcat: per distribuire un'applicazione Web Java in Tomcat, gli sviluppatori devono sapere come configurare il file server.xml e altre impostazioni Tomcat. Comprendere questi dettagli è essenziale per distribuire correttamente le applicazioni e garantire che vengano eseguite senza problemi nel server.

Quando si crea un'app con Tomcat predefinito per ospitare il carico di lavoro Java (un file WAR o un file JAR), sono disponibili alcune impostazioni predefinite per la configurazione di Tomcat. È possibile fare riferimento alla documentazione ufficiale di Apache Tomcat per informazioni dettagliate, inclusa la configurazione predefinita per Il server Web Tomcat.

Esistono inoltre alcune trasformazioni che vengono ulteriormente applicate al server.xml per la distribuzione Tomcat all'avvio. Si tratta di trasformazioni per le impostazioni Connettore, Host e Valvola.

Le versioni più recenti di Tomcat hanno server.xml (8.5.58 e 9.0.38 e versioni successive). Le versioni precedenti di Tomcat non usano trasformazioni e potrebbero avere un comportamento diverso.

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 è impostato su 16384
  • URIEncoding è impostato su UTF-8
  • conectionTimeout è impostato su WEBSITE_TOMCAT_CONNECTION_TIMEOUT, che per impostazione predefinita è 240000
  • maxThreads è impostato su WEBSITE_CATALINA_MAXTHREADS, che per impostazione predefinita è 200
  • maxConnections è impostato su WEBSITE_CATALINA_MAXCONNECTIONS, che per impostazione predefinita è 10000

Nota

Le impostazioni connectionTimeout, maxThreads e maxConnections possono essere ottimizzate con le impostazioni dell'app

Di seguito sono riportati i comandi dell'interfaccia della riga di comando di esempio che è possibile usare per modificare i valori di conectionTimeout, maxThreads o maxConnections:

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
  • Il connettore usa l'indirizzo del contenitore anziché 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 è impostato su AZURE_SITE_APP_BASE, che per impostazione predefinita è WebappsLocalPath locale
  • xmlBase è impostato su AZURE_SITE_HOME, che per impostazione predefinita è /site/wwwroot
  • unpackWARs è impostato su AZURE_UNPACK_WARS, che per impostazione predefinita è true
  • workDir è impostato su JAVA_TMP_DIR, che per impostazione predefinita è TMP
  • errorReportValveClass usa la valvola di segnalazione degli errori personalizzata

Valvola

<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 è impostato su AZURE_LOGGING_DIR, che per impostazione predefinita è home\logFiles
  • maxDays è impostato su WEBSITE_HTTPLOGGING_RETENTION_DAYS, che per impostazione predefinita è 0 [per sempre]

In Linux include tutte le stesse personalizzazioni, oltre a:

  • Aggiunge alcune pagine di errore e segnalazione alla valvola:

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

Passaggi successivi

Per trovare guide introduttive di Azure, esercitazioni e documentazione di riferimento su Java, visitare la pagina Azure per sviluppatori Java.