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 seulement dans les niveaux de tarification Gratuit, Premium v3 et Isolé v2. 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 --resource-group <resource-group-name> --name <app-name> --query linuxFxVersion

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

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

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.

Réécrire ou rediriger l’URL

Pour réécrire ou rediriger l’URL, utilisez l’une des réécritures d’URL disponibles, telles que UrlRewriteFilter.

Tomcat fournit également une vanne de réécriture.

JBoss fournit également une vanne de réécriture.

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

Vous pouvez accéder aux journaux de la console générés à partir du conteneur.

Activez d’abord la journalisation du conteneur en exécutant la commande suivante :

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

Remplacez <app-name> et <resource-group-name> par les noms appropriés pour votre application web.

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

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

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

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

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

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.

Connectez-vous avec SSH à votre instance App Service et exécutez la commande jcmd pour afficher la liste de tous les processus Java en cours d’exécution. En plus de jcmd, vous devez voir votre application Java en cours d’exécution avec un numéro d’identification de processus (pid).

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

Exécutez la commande suivante pour démarrer un enregistrement de 30 secondes de la machine virtuelle Java. La machine virtuelle Java est profilée et un fichier JFR nommé jfr_example.jfr est créé dans le répertoire d’accueil. (Remplacez 116 par le pid de votre application Java.)

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

Pendant l’intervalle de 30 secondes, vous pouvez vérifier le déroulement de l’enregistrement en exécutant jcmd 116 JFR.check. Cette commande affiche tous les enregistrements du processus Java donné.

Enregistrement continu

Vous pouvez utiliser Java Flight Recorder pour profiler en continu votre application Java avec un impact minimal sur les performances du runtime. Pour ce faire, exécutez la commande d’Azure CLI suivante pour créer un paramètre d’application nommé JAVA_OPTS avec la configuration nécessaire. Le contenu du paramètre d’application JAVA_OPTS est transmis à la commande java au démarrage de votre application.

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

Une fois l’enregistrement démarré, vous pouvez vider les données d’enregistrement à tout moment à l’aide de la commande JFR.dump.

jcmd <pid> JFR.dump name=continuous_recording filename="/home/recording1.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. 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/ .

La journalisation du Stockage Blob Azure pour les applications Linux ne peut être configurée qu’avec Azure Monitor.

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.

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.

Exécuter l’interface CLI JBoss

Dans la session SSH de votre application JBoss, vous pouvez exécuter l’interface CLI JBoss avec la commande suivante :

$JBOSS_HOME/bin/jboss-cli.sh --connect

Selon l’emplacement où JBoss se trouve dans le cycle de vie du serveur, il se peut que vous ne puissiez pas vous connecter. Patientez quelques minutes, puis réessayez. Cette approche est utile pour vérifier rapidement l’état de votre serveur actuel (par exemple, pour voir si une source de données est correctement configurée).

En outre, les modifications que vous apportez au serveur avec l’interface CLI JBoss dans la session SSH ne persistent pas après le redémarrage de l’application. Chaque fois que l’application démarre, le serveur JBoss EAP commence par une nouvelle installation. Pendant le cycle de vie de démarrage, App Service effectue les configurations de serveur nécessaires et déploie l’application. Pour apporter des modifications persistantes au serveur JBoss, utilisez un script de démarrage personnalisé ou une commande de démarrage. Pour obtenir un exemple de bout en bout, consultez Configurer des sources de données pour une application Tomcat, JBoss ou Java SE dans Azure App Service.

Vous pouvez également configurer manuellement App Service pour qu’il exécute n’importe quel fichier au démarrage. Par exemple :

az webapp config set --resource-group <group-name> --name <app-name> --startup-file /home/site/scripts/foo.sh

Pour plus d’informations sur les commandes CLI que vous pouvez exécuter, consultez :

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. Lorsque vous exécutez plusieurs instances avec la mise à l’échelle automatique, les instances JBoss EAP communiquent entre elles sur le sous-réseau spécifié dans l’intégration du réseau virtuel. Vous pouvez désactiver le clustering en créant un paramètre d’application nommé WEBSITE_DISABLE_CLUSTERING avec n’importe quelle valeur.

Diagramme montrant une application App Service intégrée au réseau virtuel, mise à l’échelle vers trois instances.

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 dans les niveaux tarifaires suivants : F1, P0v3, P1mv3, P2mv3, P3mv3, P4mv3 et P5mv3.

Cycle de vie du serveur JBoss

Une application JBoss EAP dans App Service passe par cinq phases distinctes avant de lancer réellement le serveur.

Pour plus d’informations, consultez les sections ci-dessous, ainsi que les possibilités de personnalisation (par exemple, par le biais des paramètres d’application).

1. Phase de configuration de l’environnement

  • Le service SSH est démarré pour activer des sessions SSH sécurisées avec le conteneur.
  • Le magasin de clés du runtime Java est mis à jour avec tous les certificats publics et privés définis dans le portail Azure.
    • Les certificats publics sont fournis par la plateforme dans le répertoire /var/ssl/certs, et ils sont chargés dans $JRE_HOME/lib/security/cacerts.
    • Les certificats privés sont fournis par la plateforme dans le répertoire /var/ssl/private, et ils sont chargés dans $JRE_HOME/lib/security/client.jks.
  • Si des certificats sont chargés dans le magasin de clés Java dans cette étape, les propriétés javax.net.ssl.keyStore, javax.net.ssl.keyStorePassword et javax.net.ssl.keyStoreType sont ajoutées à la variable d’environnement JAVA_TOOL_OPTIONS.
  • Certaines configurations JVM initiales sont déterminées, telles que les répertoires de journalisation et les paramètres de tas de mémoire Java :
    • Si vous fournissez les indicateurs –Xms ou –Xmx pour la mémoire dans le paramètre d’application JAVA_OPTS, ces valeurs remplacent celles fournies par la plateforme.
    • Si vous configurez le paramètre d’application WEBSITES_CONTAINER_STOP_TIME_LIMIT, la valeur est transmise à la propriété de runtime org.wildfly.sigterm.suspend.timeout, qui contrôle le temps d’attente d’arrêt maximal (en secondes) lorsque JBoss est arrêté.
  • Si l’application est intégrée à un réseau virtuel, le runtime App Service transmet une liste de ports à utiliser pour la communication entre serveurs dans la variable d’environnement WEBSITE_PRIVATE_PORTS. Lancez JBoss à l’aide de la configuration clustering. Sinon, la configuration standalone est utilisée.
    • Pour la configuration clustering, le fichier de configuration du serveur standalone-azure-full-ha.xml est utilisé.
    • Pour la configuration standalone, le fichier de configuration du serveur standalone-full.xml est utilisé.

2. Phase de lancement du serveur

  • Si JBoss est lancé dans la configuration clustering :
    • Chaque instance JBoss reçoit un identificateur interne compris entre 0 et le nombre d’instances auxquelles l’application est mise à l’échelle.
    • Si certains fichiers se trouvent dans le chemin du magasin de transactions pour cette instance de serveur (à l’aide de son identificateur interne), cela signifie que cette instance de serveur prend la place d’une instance de service identique qui s’est bloquée précédemment et qui a laissé des transactions non validées derrière elle. Le serveur est configuré pour reprendre le travail sur ces transactions.
  • Que JBoss démarre dans la configuration clustering ou dans la configuration standalone, si la version du serveur est 7.4 ou ultérieure et que le runtime utilise Java 17, la configuration est mise à jour pour activer le sous-système Elytron pour la sécurité.
  • Si vous configurez le paramètre d’application WEBSITE_JBOSS_OPTS, la valeur est transmise au script du lanceur JBoss. Ce paramètre peut être utilisé pour fournir des chemins d’accès aux fichiers de propriétés et à d’autres indicateurs qui influencent le démarrage de JBoss.

3. Phase de configuration du serveur

  • Au début de cette phase, App Service attend d’abord que le serveur JBoss et l’interface d’administration soient prêts à recevoir des demandes avant de continuer. Cela peut prendre quelques secondes supplémentaires si Application Insights est activé.
  • Lorsque le serveur JBoss et l’interface d’administration sont prêts, App Service effectue les opérations suivantes :
    • Ajoute le module JBoss azure.appservice, qui fournit des classes utilitaires pour la journalisation et l’intégration à App Service.
    • Met à jour l’enregistreur d’événements de console pour qu’il utilise un mode sans couleur afin que les fichiers journaux ne soient pas pleins de séquences d’échappement de couleur.
    • Configure l’intégration aux journaux d’Azure Monitor.
    • Met à jour les adresses IP de liaison des interfaces WSDL et de gestion.
    • Ajoute le module JBoss azure.appservice.easyauth pour l’intégration à l’authentification App Service et Microsoft Entra ID.
    • Met à jour la configuration de journalisation des journaux d’accès et le nom et la rotation du fichier journal du serveur principal.
  • Sauf si le paramètre d’application WEBSITE_SKIP_AUTOCONFIGURE_DATABASE est défini, App Service détecte automatiquement les URL JDBC dans les paramètres de l’application App Service. Si des URL JDBC valides existent pour PostgreSQL, MySQL, MariaDB, Oracle, SQL Server ou Azure SQL Database, il ajoute le ou les pilotes correspondants au serveur et ajoute une source de données pour chacune des URL JDBC, et définit le nom JNDI de chaque source de données sur java:jboss/env/jdbc/<app-setting-name>_DS, où <app-setting-name> est le nom du paramètre d’application.
  • Si la configuration clustering est activée, l’enregistreur d’événements de console à configurer est activé.
  • S’il existe des fichiers JAR déployés dans le répertoire /home/site/libs, un nouveau module global est créé avec tous ces fichiers JAR.
  • À la fin de la phase, App Service exécute le script de démarrage personnalisé, s’il en existe un. Logique de recherche pour le script de démarrage personnalisé se présente ainsi :
    • Si vous avez configuré une commande de démarrage (dans le portail Azure, avec Azure CLI, etc.), exécutez-la ; sinon,
    • Si le chemin d’accès /home/site/scripts/startup.sh existe, utilisez-le ; sinon,
    • Si le chemin d’accès /home/startup.sh existe, utilisez-le.

La commande de démarrage ou le script personnalisé s’exécute en tant qu’utilisateur racine (aucun besoin de sudo), afin de pouvoir installer des packages Linux ou lancer l’interface CLI JBoss pour effectuer davantage de commandes d’installation ou de personnalisation JBoss (création de sources de données, installation d’adaptateurs de ressources), etc. Pour plus d’informations sur les commandes de gestion des packages Ubuntu, consultez la documentation Ubuntu Server. Pour connaître les commandes CLI JBoss, consultez le guide CLI de gestion JBoss.

4. Phase de déploiement de l’application

Le script de démarrage déploie des applications sur JBoss en recherchant les emplacements suivants, dans l’ordre de priorité :

  • Si vous avez configuré le paramètre d’application WEBSITE_JAVA_WAR_FILE_NAME, déployez le fichier désigné par celui-ci.
  • Si /home/site/wwwroot/app.war existe, déployez-le.
  • Si d’autres fichiers EAR et WAR existent dans /home/site/wwwroot, déployez-les.
  • Si /home/site/wwwroot/webapps existe, déployez les fichiers et les répertoires. Les fichiers WAR sont déployés en tant qu’applications, et les répertoires sont déployés en tant qu’applications web « éclatées » (non compressées).
  • Si des pages JSP autonomes existent dans /home/site/wwwroot, copiez-les à la racine du serveur web et déployez-les en tant qu’application web.
  • Si aucun fichier déployable n’est encore trouvé, déployez la page d’accueil par défaut (page de stationnement) dans le contexte racine.

5. Phase de rechargement du serveur

  • Une fois les étapes de déploiement terminées, le serveur JBoss est rechargé pour appliquer les modifications qui nécessitent un rechargement de serveur.
  • Une fois le serveur rechargé, les applications déployées sur le serveur JBoss EAP doivent être prêtes à répondre aux demandes.
  • Le serveur s’exécute jusqu’à ce que l’application App Service soit arrêtée ou redémarrée. Vous pouvez arrêter ou redémarrer manuellement l’application App Service, ou déclencher un redémarrage lorsque vous déployez des fichiers ou apportez des modifications de configuration à l’application App Service.
  • Si le serveur JBoss quitte anormalement la configuration clustering, une fonction finale appelée emit_alert_tx_store_not_empty est exécutée. La fonction vérifie si le processus JBoss a laissé un fichier de magasin de transactions vide sur disque. Si c’est le cas, une erreur est consignée dans la console : Error: finishing server with non-empty store for node XXXX. Quand une nouvelle instance de serveur est démarrée, elle recherche ces fichiers de magasin de transactions non vide pour reprendre le travail (consultez 2. Phase de lancement du serveur).

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.