Partager via

Déployer et configurer une application Tomcat, JBoss ou Java SE dans Azure App Service

  • Article

Cet article vous montre la configuration de déploiement et d’exécution la plus courante pour les applications Java dans App Service. Si vous n’avez jamais utilisé Azure App Service, commencez par lire Démarrage rapide avec Java. Des questions générales sur l’utilisation d’App Service qui ne sont pas spécifiques au développement Java sont traitées dans Questions fréquentes (FAQ) sur App Service.

Azure App Service exécute des applications web Java sur un service complètement managé en trois variantes :

  • Java SE : peut exécuter une application déployée en tant que package JAR qui contient un serveur incorporé (par exemple Spring Boot, Dropwizard, Quarkus ou avec un serveur Tomcat ou Jetty incorporé).
  • Tomcat : le serveur Tomcat intégré peut exécuter une application déployée en tant que package WAR.
  • JBoss EAP : pris en charge pour les applications Linux dans les niveaux tarifaires Premium v3 et Isolé v2 uniquement. Le serveur JBoss EAP intégré peut exécuter une application déployée en tant que package WAR ou EAR.

Remarque

Pour les applications Spring, nous vous recommandons d’utiliser Azure Spring Apps. Toutefois, vous pouvez toujours utiliser Azure App Service comme destination. Pour obtenir des conseils, consultez l’Aide de destination de la charge de travail Java.

Afficher la version de Java

Pour afficher la version actuelle de Java, exécutez la commande suivante dans Cloud Shell :

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

Pour afficher toutes les versions prises en charge de Java, exécutez la commande suivante dans Cloud Shell :

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

Pour plus d’informations sur la prise en charge des versions, consultez la Stratégie de prise en charge du runtime du langage App Service.

Déploiement de votre application

Outils de build

Maven

Avec le plug-in Maven pour Azure Web Apps, vous pouvez facilement préparer votre projet Java Maven pour Azure Web App avec une seule commande à la racine de votre projet :

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

Cette commande ajoute un plug-in azure-webapp-maven-plugin et une configuration associée en vous invitant à sélectionner une instance Azure Web App existante ou à en créer une nouvelle. Pendant la configuration, il tente de détecter si votre application doit être déployée sur Java SE, Tomcat ou (Linux uniquement) JBoss EAP. Ensuite, vous pouvez déployer votre application Java sur Azure à l’aide de la commande suivante :

mvn package azure-webapp:deploy

Voici un exemple de configuration dans 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. Configurez le plug-in Gradle pour Azure Web Apps en ajoutant le plug-in à votre build.gradle :

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

  2. Configurez les détails de votre application web. Les ressources Azure correspondantes sont créées si elles n’existent pas. Voici un exemple de configuration. Pour plus de détails, consultez ce document.

    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. Effectuez le déploiement avec une seule commande.

    gradle azureWebAppDeploy

IDE

Azure fournit une expérience de développement Java App Service transparente dans des IDE Java populaires, à savoir :

API Kudu

Pour déployer des fichiers .jar dans Java SE, utilisez le point de terminaison /api/publish du site Kudu. Pour plus d’informations sur cette API, consultez cette documentation.

Notes

Vous devez nommer votre application. jar app.jar pour qu’App Service puisse identifier et exécuter votre application. Le plug-in Maven le fait automatiquement pendant le déploiement. Si vous ne souhaitez pas renommer votre JAR en app.jar, vous pouvez charger un script d’interpréteur de commandes avec la commande pour exécuter votre application .jar. Collez le chemin d’accès absolu à ce script dans la zone de texte Fichier de démarrage, dans la section Configuration du portail. Le script de démarrage ne s’exécute pas dans le répertoire dans lequel il est placé. Par conséquent, utilisez toujours des chemins d’accès absolus pour référencer les fichiers dans votre script de démarrage (par exemple : java -jar /home/myapp/myapp.jar).

Pour déployer des fichiers .war sur Tomcat, utilisez le point de terminaison /api/wardeploy/ pour effectuer un POST de votre fichier d’archive. Pour plus d’informations sur cette API, consultez cette documentation.

Pour déployer des fichiers .war sur JBoss, utilisez le point de terminaison /api/wardeploy/ pour effectuer un POST de votre fichier d’archive. Pour plus d’informations sur cette API, consultez cette documentation.

Pour déployer des fichiers .ear, utilisez FTP. Votre application. ear est déployée à la racine du contexte définie dans la configuration de votre application. Par exemple, si la racine du contexte de votre application est <context-root>myapp</context-root>, vous pouvez parcourir le site dans le chemin /myapp suivant : http://my-app-name.azurewebsites.net/myapp. Si vous souhaitez que votre application web soit servie dans le chemin d’accès racine, assurez-vous que votre application définit la racine du contexte sur le chemin d’accès racine : <context-root>/</context-root>. Pour plus d’informations, consultez le document Setting the context root of a web application.

Ne déployez pas votre fichier .war ou .jar à l’aide d’un FTP. L’outil FTP est conçu pour charger des scripts de démarrage, des dépendances ou d’autres fichiers de runtime. Il ne s’agit pas du meilleur choix pour un déploiement d’applications web.

Journalisation et débogage des applications

Vous trouverez des rapports de performances, des visualisations de trafic et des contrôles d’intégrité pour chaque application dans le portail Azure. Pour plus d’informations, consultez Présentation des diagnostics Azure App Service.

Diffuser les journaux de diagnostic

Pour accéder aux journaux de la console générés à l’intérieur du code de votre application dans App Service, activez la journalisation des diagnostics en exécutant la commande suivante dans Cloud Shell :

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

Les valeurs possibles pour --level sont : Error, Warning, Info et Verbose. Chaque niveau suivant comprend le niveau précédent. Par exemple : Error comprend uniquement les messages d’erreur et Verbose comprend tous les messages.

Une fois la journalisation des diagnostics activée, exécutez la commande suivante pour voir le flux de journal :

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

Si vous ne voyez pas les journaux d’activité de la console, attendez 30 secondes et vérifiez à nouveau.

Notes

Vous pouvez également inspecter les fichiers journaux à partir du navigateur sur https://<app-name>.scm.azurewebsites.net/api/logs/docker.

Pour arrêter le streaming des journaux à tout moment, appuyez sur Ctrl+C.

Pour plus d’informations, consultez Diffuser des journaux dans Cloud Shell.

Accès à la console SSH dans Linux

Pour établir une session SSH directe avec votre conteneur, votre application doit être en cours d’exécution.

Collez l’URL suivante dans votre navigateur et remplacez <app-name> par le nom de votre application :

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

Si vous n’êtes pas encore authentifié, vous devez le faire avec votre abonnement Azure pour vous connecter. Une fois authentifié, vous voyez un interpréteur de commandes dans le navigateur, vous permettant d’exécuter des commandes à l’intérieur de votre conteneur.

Connexion SSH

Notes

Les modifications apportées en dehors du répertoire /home sont stockées dans le conteneur lui-même et ne sont pas conservées après le redémarrage d’une application.

Pour ouvrir une session SSH à distance à partir de votre machine locale, consultez Ouvrir une session SSH à partir d’un interpréteur de commandes à distance.

Outils de résolution des problèmes Linux

Les images Java intégrées sont basées sur le système d’exploitation Alpine Linux. Utilisez le gestionnaire de package apk pour installer des outils ou commandes de résolution des problèmes.

Java Profiler

Tous les runtimes Java sur Azure App Service sont fournis avec l’enregistreur de vol JDK pour le profilage des charges de travail Java. Vous pouvez l’utiliser pour enregistrer les événements de la machine virtuelle Java, du système et de l’application, ainsi que pour résoudre les problèmes dans vos applications.

Pour en savoir plus sur le Profileur Java, consultez la documentation Azure Application Insights.

Boîte noire SQL

Tous les runtimes Java sur App Service sont fournis avec Java Flight Recorder. Vous pouvez l’utiliser pour enregistrer les événements JVM, système et d’application, ainsi que pour résoudre les problèmes dans vos applications Java.

Enregistrement chronométré

Pour prendre un enregistrement chronométré, vous avez besoin du PID (ID de processus) de l’application Java. Pour rechercher le PID, ouvrez un navigateur sur le site SCM de votre application web à l’adresse https://<your-site-name>.scm.azurewebsites.net/ProcessExplorer/. Cette page affiche les processus en cours d’exécution dans votre application web. Recherchez le processus nommé « java » dans le tableau et copiez le PID (ID de processus) correspondant.

Ouvrez ensuite la Console de débogage dans la barre d’outils supérieure du site GCL et exécutez la commande suivante. Remplacez <pid> par l’ID de processus que vous avez copié précédemment. Cette commande démarre un enregistrement de 30 secondes du profileur de votre application Java et génère un fichier nommé timed_recording_example.jfr dans le répertoire C:\home.

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

Analyser les fichiers .jfr

Utilisez FTPS pour télécharger votre fichier JFR sur votre ordinateur local. Pour analyser le fichier JFR, téléchargez et installez Java Mission Control. Pour obtenir des instructions sur Java Mission Control, consultez la documentation JMC et les instructions d’installation.

Journalisation des applications

Activez Journal des applications via le portail Azure ou Azure CLI pour configurer App Service de sorte à écrire la sortie de console standard de votre application et les flux d’erreur de console standard dans le système de fichiers local ou le service Stockage Blob Azure. La journalisation sur l’instance du système de fichiers App Service locale est désactivée 12 heures après l’avoir été activée. Si vous en avez besoin plus longtemps, configurez l’application pour écrire la sortie sur un conteneur de stockage d’objets blob.

Vous trouverez vos journaux d’application Java et Tomcat dans le répertoire /home/LogFiles/Application/ .

Si votre application utilise Logback ou Log4j pour le traçage, vous pouvez transférer ces traces pour révision vers Azure Application Insights en suivant les instructions de configuration des frameworks de journalisation dans Exploration des journaux d’activité de traces Java dans Application Insights.

Notes

En raison de la vulnérabilité connue CVE-2021-44228, veillez à utiliser Log4j version 2.16 ou ultérieure.

Personnalisation et réglage

Azure App Service prend en charge le réglage et la personnalisation prêts à l’emploi par le biais du portail Azure et de l’interface CLI. Consultez les articles suivants pour configurer des applications web spécifiques non-Java :

Copiez le contenu de l’application localement

Définissez le paramètre d’application JAVA_COPY_ALL sur true pour copier le contenu de votre application vers le worker local à partir du système de fichiers partagé. Ce paramètre permet de résoudre les problèmes de verrouillage de fichiers.

Définir les options de runtime Java

Pour définir la mémoire allouée ou d’autres options de runtime JVM, créez un paramètre d’application nommé JAVA_OPTS avec les options. App Service transmet ce paramètre comme variable d’environnement au runtime Java quand il démarre.

Dans le portail Azure, sous Paramètres d’application de l’application web, créez un paramètre d’application appelé JAVA_OPTS qui contient d’autres paramètres tels que -Xms512m -Xmx1204m.

Dans le portail Azure, sous Paramètres d’application de l’application web, créez un paramètre d’application appelé CATALINA_OPTS qui contient d’autres paramètres tels que -Xms512m -Xmx1204m.

Pour configurer le paramètre d’application à partir du plug-in Maven, ajoutez des étiquettes paramètre/valeur dans la section du plug-in Azure. L’exemple suivant définit une taille de segment de mémoire Java minimale et maximale spécifique :

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

Remarque

Vous n’avez pas besoin de créer un fichier de web.config lors de l’utilisation de Tomcat sur Windows App Service.

Les développeurs exécutant une seule application avec un seul emplacement de déploiement dans leur plan App Service peuvent utiliser les options suivantes :

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

Lors du réglage des paramètres de segment de mémoire de l’application, consultez les détails de votre plan App Service et prenez en compte qu’avec plusieurs applications et emplacements de déploiement, vous devez trouver l’allocation de mémoire optimale.

Activer les sockets web

Activez la prise en charge des sockets web dans le portail Azure dans les Paramètres d’application de l’application. Vous devez redémarrer l’application pour que le paramètre prenne effet.

Activez la prise en charge des sockets web via l’interface Azure CLI avec la commande suivante :

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

Redémarrez ensuite votre application :

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

Définir l’encodage de caractères par défaut

Dans le portail Azure, sous Paramètres d’application de l’application web, créez un paramètre d’application appelé JAVA_OPTS avec la valeur -Dfile.encoding=UTF-8.

Vous pouvez aussi configurer le paramètre d’application à l’aide du plug-in Maven App Service. Ajoutez le nom du paramètre et les étiquettes des valeurs dans la configuration du plug-in :

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

Précompiler les fichiers JSP

Pour améliorer les performances des applications Tomcat, vous pouvez compiler vos fichiers JSP avant le déploiement sur App Service. Vous pouvez utiliser le plug-in Maven fourni par Apache Sling, ou ce fichier de build Ant.

Remarque

robots933456 dans les journaux

Le message suivant peut s'afficher dans les journaux du conteneur :

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

Vous pouvez sans risque ignorer ce message. /robots933456.txt est un chemin d’URL factice utilisé par App Service pour vérifier si le conteneur est capable de traiter des requêtes. Une réponse 404 indique que le chemin d’accès n’existe pas, mais informe App Service que le conteneur est intègre et prêt à répondre aux requêtes.

Choix d’une version du runtime Java

App Service permet aux utilisateurs de choisir la version principale de la JVM, telle que Java 8 ou Java 11, ainsi que sa version corrective, telle que 1.8.0_232 ou 11.0.5. Vous pouvez également décider de mettre automatiquement à jour la version corrective quand de nouvelles versions mineures sont disponibles. Dans la plupart des cas, les applications de production doivent utiliser des versions correctives épinglées de la JVM. Cela empêche des interruptions imprévues lors d’une mise à jour automatique de la version corrective. Toutes les applications web Java utilisent des JVM 64 bits, et cela n’est pas configurable.

Si vous utilisez Tomcat, vous pouvez choisir d’épingler la version corrective de Tomcat. Sur Windows, vous pouvez épingler les versions correctives de la JVM et Tomcat indépendamment. Sur Linux, vous pouvez épingler la version corrective de Tomcat. La version corrective de la machine virtuelle Java est également épinglée, mais n’est pas configurable séparément.

Si vous choisissez d’épingler la version mineure, vous devez mettre à jour régulièrement la version mineure de la JVM sur l’application. Pour vous assurer que votre application exécute la version mineure la plus récente, créez un emplacement de préproduction et incrémentez la version mineure sur l’emplacement de préproduction. Une fois que vous avez confirmé que l’application s’exécute correctement sur la nouvelle version mineure, vous pouvez permuter les emplacements de préproduction et de production.

Clustering

App Service prend en charge le clustering pour JBoss EAP versions 7.4.1 et ultérieures. Pour activer le clustering, votre application web doit être intégrée à un réseau virtuel. Lorsque l’application web est intégrée à un réseau virtuel, elle redémarre et l’installation de JBoss EAP démarre automatiquement avec une configuration en cluster. Les instances JBoss EAP communiquent sur le sous-réseau spécifié dans l’intégration du réseau virtuel, à l’aide des ports indiqués dans la WEBSITES_PRIVATE_PORTS variable d’environnement au moment de l’exécution. Vous pouvez désactiver le clustering en créant un paramètre d’application nommé WEBSITE_DISABLE_CLUSTERING avec n’importe quelle valeur.

Remarque

Si vous activez l’intégration de votre réseau virtuel avec un modèle ARM, vous devez définir manuellement la propriété vnetPrivatePorts sur la valeur 2. Si vous activez l’intégration du réseau virtuel à partir de l’interface CLI ou du portail, cette propriété est définie automatiquement.

Lorsque le clustering est activé, les instances de JBoss EAP utilisent le protocole de découverte JGroups FILE_PING pour découvrir de nouvelles instances et conserver les informations de cluster, comme les membres du cluster, leurs identificateurs et leurs adresses IP. Sur App Service, ces fichiers se trouvent sous /home/clusterinfo/. La première instance EAP à démarrer obtient des autorisations de lecture/écriture sur le fichier d’appartenance du cluster. D’autres instances lisent le fichier, recherchent le nœud principal et coordonnent le nœud à être inclus dans le cluster et sont ajoutés au fichier.

Remarque

Vous pouvez éviter les délais d’expiration du clustering JBOSS en nettoyant les fichiers de découverte obsolètes lors du démarrage de votre application

Les types de plans App Service Premium V3 et isolés V2 peuvent éventuellement être distribués entre les zones de disponibilité pour améliorer la résilience et la fiabilité de vos charges de travail vitales pour l’entreprise. Cette architecture est également appelée redondance de zone. La fonctionnalité de clustering JBoss EAP est compatible avec la fonctionnalité de redondance de zone.

Règles de mise à l’échelle automatique

Lors de la configuration des règles de mise à l’échelle automatique d’une mise à l’échelle horizontale, il est important de supprimer les instances de manière incrémentielle (une à la fois) pour garantir que chaque instance supprimée peut transférer son activité (comme la gestion d’une transaction de base de données) vers un autre membre du cluster. Quand vous configurez vos règles de mise à l’échelle automatique dans le portail pour effectuer un scale-down, utilisez les options suivantes :

  • Opération : « Diminuer le nombre de »
  • Délai d’attente : « 5 minutes » ou plus
  • Nombre d’instances : 1

Vous n’avez pas besoin d’ajouter des instances de manière incrémentielle (montée en charge). Vous pouvez ajouter plusieurs instances à la fois au cluster.

Plans App Service

JBoss EAP est disponible uniquement sur les types de plans App Service Premium v3 et Isolé v2. Les clients qui ont créé un site JBoss EAP sur un niveau différent pendant la préversion publique doivent effectuer un scale-up vers le niveau de matériel Premium ou Isolé pour éviter un comportement inattendu.

Configuration de base Tomcat

Remarque

Cette section concerne uniquement Linux.

Les développeurs Java peuvent personnaliser les paramètres du serveur, résoudre les problèmes et déployer des applications sur Tomcat en toute confiance s’ils connaissent les détails liés au fichier server.xml et à la configuration de Tomcat. Les personnalisations possibles sont les suivantes :

  • Personnalisation de la configuration de Tomcat : en ayant une bonne compréhension du fichier server.xml et de la configuration de Tomcat, vous pouvez affiner les paramètres du serveur pour répondre aux besoins de leurs applications.
  • Débogage : lorsqu’une application est déployée sur un serveur Tomcat, les développeurs doivent connaître la configuration du serveur pour déboguer les problèmes qui peuvent survenir. Cela inclut la vérification des journaux du serveur, l’examen des fichiers de configuration et l’identification des erreurs susceptibles de se produire.
  • Résolution des problèmes Tomcat : inévitablement, les développeurs Java rencontrent des problèmes avec leur serveur Tomcat, tels que des problèmes de performances ou des erreurs de configuration. En comprenant le fichier server.xml et les détails de configuration de Tomcat, les développeurs peuvent diagnostiquer et résoudre rapidement ces problèmes, ce qui peut gagner du temps et des efforts.
  • Déploiement d’applications sur Tomcat : pour déployer une application web Java sur Tomcat, les développeurs doivent savoir comment configurer le fichier server.xml et d’autres paramètres Tomcat. Comprendre ces détails est essentiel pour déployer des applications correctement et s’assurer qu’elles s’exécutent correctement sur le serveur.

Lorsque vous créez une application avec Tomcat intégré pour héberger votre charge de travail Java (un fichier WAR ou un fichier JAR), certains paramètres sont disponibles pour la configuration de Tomcat. Vous pouvez consulter la documentation Apache Tomcat officielle pour obtenir des informations détaillées, notamment la configuration par défaut du serveur web Tomcat.

En outre, certaines transformations sont appliquées au-delà du fichier server.xml pour la distribution de Tomcat au démarrage. Il s’agit de transformations apportées aux paramètres Connector, Host et Valve.

Les dernières versions de Tomcat ont server.xml (8.5.58 et à partir de 9.0.38). Les versions antérieures de Tomcat n’utilisent pas de transformations et peuvent donc avoir un comportement différent.

Connecteur

<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 est défini sur 16384
  • URIEncoding est défini sur UTF-8
  • conectionTimeout est défini sur WEBSITE_TOMCAT_CONNECTION_TIMEOUT, qui est défini par défaut sur le 240000
  • maxThreads est défini sur WEBSITE_CATALINA_MAXTHREADS, qui est défini par défaut sur le 200
  • maxConnections est défini sur WEBSITE_CATALINA_MAXCONNECTIONS, qui est défini par défaut sur le 10000

Remarque

Les paramètres connectionTimeout, maxThreads et maxConnections peuvent être ajustés avec les paramètres de l’application

Voici des exemples de commandes CLI que vous pouvez utiliser pour modifier les valeurs de conectionTimeout, maxThreads ou 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
  • Le connecteur utilise l’adresse du conteneur au lieu de 127.0.0.1

Hôte

<Host appBase="${site.appbase}" xmlBase="${site.xmlbase}" unpackWARs="${site.unpackwars}" workDir="${site.tempdir}" errorReportValveClass="com.microsoft.azure.appservice.AppServiceErrorReportValve" name="localhost" autoDeploy="true">
  • appBase est défini sur AZURE_SITE_APP_BASE, qui est défini par défaut sur le WebappsLocalPath local
  • xmlBase est défini sur AZURE_SITE_HOME, qui est défini par défaut sur le /site/wwwroot
  • unpackWARs est défini sur AZURE_UNPACK_WARS, qui est défini par défaut sur le true
  • workDir est défini sur JAVA_TMP_DIR, qui est défini par défaut sur le TMP
  • errorReportValveClass utilise notre valve de rapport d’erreurs personnalisée

Valve

<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 est défini sur AZURE_LOGGING_DIR, qui est défini par défaut sur home\logFiles
  • maxDays est à WEBSITE_HTTPLOGGING_RETENTION_DAYS, qui est défini par défaut sur 0 [forever]

Sur Linux, elle les mêmes personnalisations, ainsi que :

  • Ajoute des pages d’erreur et de création de rapports à la valve :

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

Étapes suivantes

Visitez le centre Azure pour les développeurs Java pour trouver des guides de démarrage rapide Azure, des tutoriels et la documentation de référence Java.