Partager via

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

Cet article vous présente la configuration de déploiement et d’exécution les plus courantes pour les applications Java dans Azure App Service. S’il s’agit de votre première utilisation d’Azure App Service, vous devez d’abord lire le guide de démarrage rapide Java. Vous trouverez les réponses aux questions générales sur l’utilisation d’App Service qui ne sont pas spécifiques au développement Java dans le FAQ App Service.

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

  • Java Standard Edition (SE) : peut exécuter une application déployée en tant que package JAR (Java Archive) qui contient un serveur incorporé (par exemple Spring Boot, Snapshotus, Dropwizard ou une application 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 (Web Application Archive).
  • JBoss Enterprise Application Platform (EAP) : le serveur JBoss EAP intégré peut exécuter une application déployée en tant que package WAR ou enterprise archive (EAR). Pris en charge pour les applications Linux dans un ensemble de niveaux de tarification incluant Gratuit, Premium v3 et Isolé v2.gti

Remarque

JBoss EAP sur App Service prend désormais en charge la facturation BYOL (Bring Your Own License), ce qui permet aux clients disposant d’abonnements Red Hat existants d’appliquer ces licences directement à leurs déploiements JBoss EAP sur Azure App Service. En savoir plus.

Afficher la version de Java

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

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

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

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

Obtenir la version Java dans le conteneur Linux

Pour obtenir des informations de version plus détaillées dans le conteneur Linux, ouvrez une session SSH avec le conteneur. Voici quelques exemples de ce que vous pouvez exécuter.

Pour afficher la version Java dans la session SSH :

java -version

Pour afficher la version du serveur Tomcat dans la session SSH :

sh /usr/local/tomcat/bin/version.sh

Autrement, si votre serveur Tomcat se trouve dans un emplacement personnalisé, trouvez recherchez version.sh avec :

find / -name "version.sh"

Pour afficher la version du serveur JBoss EAP dans la session SSH :

$JBOSS_HOME/bin/jboss-cli.sh --connect --commands=:product-info

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

Que se passe-t-il pour les runtimes obsolètes dans App Service ?

Les runtimes obsolètes sont déconseillés par l’organisation de maintenance ou présentent des vulnérabilités importantes. En conséquence, ils sont supprimés de la création et de la configuration des pages dans le portail. Lorsqu’un runtime obsolète est masqué dans le portail, toute application qui utilise toujours ce runtime continue à s’exécuter.

Si vous souhaitez créer une application avec une version d’exécution obsolète qui n’est plus affichée sur le portail, utilisez Azure CLI, un modèle ARM ou Bicep. Ces alternatives de déploiement vous permettent de créer des moteurs d’exécution obsolètes qui ont été supprimés du portail, mais qui sont toujours pris en charge.

Si un runtime est entièrement supprimé de la plateforme App Service, le propriétaire de votre abonnement Azure reçoit un e-mail avant la suppression.

Déploiement de votre application

Outils de génération

Maven

En utilisant le plug-in Maven pour Azure Web Apps, vous pouvez facilement préparer votre projet avec une commande dans la racine de votre projet :

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

Cette commande ajoute un azure-webapp-maven-plugin plug-in et la configuration associée en vous invitant à sélectionner une application web Azure 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. Vous pouvez ensuite 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 à 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 d’informations, reportez-vous à 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 offre une expérience de développement Java App Service transparente dans les environnements de développement intégrés Java populaires, notamment :

API Kudu et OneDeploy

Les clients de déploiement tels que le plug-in Maven, GitHub Actions utilisant azure/webapps-deploy@v3 et les versions ultérieures, ou la commande az webapp deploy utilisent OneDeploy, qui est invoqué par l'appel du /api/publish point de terminaison du site Kudu en arrière-plan. Pour plus d’informations sur cette API, consultez cette documentation.

Lorsque ces méthodes de déploiement sont utilisées, elles renomment automatiquement le fichier app.jar JAR fourni pendant le processus de déploiement. Cela sera placé sous /home/site/wwwwroot. Pour déployer des fichiers JAR sur Java SE, consultez cette documentation.

Remarque

Si vous utilisez d’autres méthodes telles que FTP ou des API ZipDeploy plus anciennes, cette méthode de renommage du fichier JAR fourni n’est pas appelée. Notez cela si vous utilisez la zone de texte Fichier de démarrage dans la section Configuration du portail pour appeler explicitement votre fichier JAR.

Vous pouvez déployer des fichiers WAR sur votre application Tomcat en suivant cette documentation. Lorsque ces méthodes de déploiement ci-dessus sont utilisées, elles renomment automatiquement le fichier app.war War fourni pendant le processus de déploiement. Cette opération est placée sous /home/site/wwwwroot et par défaut prend uniquement en charge le déploiement d’un fichier WAR sous wwwroot. Cette opération ne sera pas placée sous le répertoire comme indiqué lors de l’utilisation /home/site/wwwroot/webapps d’API de déploiement telles que WarDeploy. Pour éviter tout problème lié aux conflits de structure de fichiers, il est recommandé d’utiliser uniquement un ou l’autre type de déploiement.

Pour déployer des fichiers WAR sur JBoss EAP, consultez cette documentation. Lorsque OneDeploy est utilisé, le fichier WAR sera automatiquement renommé en app.war et placé sous /home/site/wwwroot.

Pour déployer des fichiers EAR, utilisez FTP. Votre application EAR est déployée sur la racine de contexte définie dans la configuration de votre application. 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 Définition de la racine de contexte d’une application web.

Ne déployez pas votre fichier WAR ou JAR à l’aide de 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 une URL

Pour réécrire ou rediriger une URL, utilisez l’un des réwriters d’URL disponibles, tels que UrlRewriteFilter.

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

JBoss EAP 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 la vue d’ensemble des diagnostics Azure App Service.

Diffuser les journaux de diagnostic

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

Pour activer la journalisation des conteneurs, exécutez la commande suivante :

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

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

Après avoir activé la journalisation des conteneurs, exécutez la commande suivante pour afficher le flux de journaux :

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

Si les journaux de console ne s’affichent pas immédiatement, vérifiez à nouveau dans 30 secondes.

Pour arrêter le streaming des logs (journaux) à tout moment, utilisez le raccourci clavier Ctrl+C.

Pour plus d’informations, consultez Stream logs in Cloud Shell.

Accès à la console SSH dans Linux

Votre application doit être en cours d’exécution si vous souhaitez ouvrir une session SSH directe avec votre conteneur.

Utilisez la commande az webapp ssh .

Si vous n’êtes pas authentifié, vous devez vous authentifier avec votre abonnement Azure pour vous connecter. Une fois authentifié, vous voyez apparaître un interpréteur de commandes dans votre navigateur. Celui-ci vous permet d’exécuter des commandes dans votre conteneur.

Connexion SSH

Remarque

Toutes les modifications que vous apportez en dehors du /home répertoire sont stockées dans le conteneur lui-même et ne sont pas conservées au-delà d’un redémarrage de l’application.

Pour ouvrir une session SSH distante à partir de votre ordinateur local, consultez Ouvrir une session SSH à partir de l’interpréteur de commandes distant.

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.

Profileur Java

Tous les runtimes Java sur Azure App Service sont fournis avec l’enregistreur de vol JDK (Java Development Kit) pour le profilage des charges de travail Java. Vous pouvez l’utiliser pour enregistrer des événements JVM (Java Virtual Machine), système et application, et pour résoudre les problèmes dans vos applications.

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

Enregistreur de vol Java

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 application et résoudre les problèmes dans vos applications Java.

Connectez-vous à App Service et exécutez la jcmd commande pour afficher la liste de tous les processus Java en cours d’exécution. En plus de jcmd lui-même, votre application Java doit s’exécuter avec un numéro d’ID 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. Il profile la machine virtuelle JVM et crée un fichier JFR (Java Flight Recorder) nommé jfr_example.jfr dans le répertoire de base. 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 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 passé à la java commande 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 actuelles à tout moment à l’aide de la JFR.dump commande.

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 (JMC). Pour obtenir des instructions sur l’utilisation de Java Mission Control, consultez la documentation JMC et les instructions d’installation.

Journalisation des applications

Pour configurer App Service afin d’écrire la sortie de la console standard de votre application et les flux d’erreurs de la console standard dans le système de fichiers local ou dans Stockage Blob Azure, procédez comme suit. Activez la journalisation des applications via le portail Azure ou dans Azure CLI. Si vous avez besoin d’une rétention plus longue, configurez l’application pour écrire la sortie dans un conteneur de stockage Blob.

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

La journalisation du Stockage Blob Azure pour les applications Linux peut être configurée uniquement à l’aide d’Azure Monitor.

Si votre application utilise Logback ou Log4j pour le suivi, vous pouvez transférer ces traces pour révision dans Azure Application Insights. Utilisez les instructions de configuration de l’infrastructure de journalisation dans Explorer les journaux de suivi Java dans Application Insights.

Remarque

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

Personnalisation et réglage

Azure App Service prend en charge l’optimisation et la personnalisation prêtes à l’emploi via le portail Azure et Azure CLI. Consultez les articles suivants pour configurer des applications web spécifiques non-Java :

Copier 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. JAVA_COPY_ALL n’est pas compatible avec la convention héritée de déploiement vers /home/site/wwwroot/webapps.

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 nommé JAVA_OPTS qui inclut 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 nommé CATALINA_OPTS qui inclut 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.

Par défaut, App Service définit la taille maximale du tas de la JVM à 70 % de la mémoire totale disponible pour le plan App Service. Pour désactiver le paramètre par défaut, vous pouvez utiliser le paramètre d’application WEBSITE_DISABLE_JAVA_HEAP_CONFIGURATION="true ».

Améliorer les performances de votre application sur la plateforme peut impliquer l’ajustement de la taille du tas pour mieux répondre à vos besoins spécifiques. Lorsque vous réglez les paramètres du tas d’applications, passez en revue les détails de votre plan App Service et tenez compte des exigences de plusieurs applications et emplacements de déploiement pour 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 à l’aide d’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 nommé JAVA_OPTS avec la valeur -Dfile.encoding=UTF-8.

Vous pouvez également configurer le paramètre d’application à l’aide du plug-in App Service Maven. 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 utiliser ce fichier de build Ant.

Ignorer le message robots933456 dans les logs informatiques

Le message suivant peut s’afficher dans les journaux d’activité 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. App Service l’utilise pour vérifier si le conteneur est capable de traiter les demandes. Une réponse d’erreur « 404 » indique que le chemin d’accès n’existe pas et signale à App Service que le conteneur est sain et prêt à répondre aux demandes.

Choisir une version du runtime Java

App Service permet aux utilisateurs de choisir la version principale de la machine virtuelle JVM, telle que Java 8 ou Java 11, et la version corrective, comme 1.8.0_232 ou 11.0.5. Vous pouvez également choisir de mettre automatiquement à jour la version corrective à mesure que de nouvelles versions mineures deviennent disponibles. Dans la plupart des cas, les applications de production doivent utiliser des versions correctives épinglées de la JVM, qui évitent les pannes inattendues lors d’une mise à jour automatique de 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 fixer la version corrective de Tomcat. La version corrective de la JVM est également épinglée, mais elle 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 vérifié 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 EAP, vous pouvez exécuter l’interface CLI JBoss avec la commande suivante :

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

Selon l’emplacement où JBoss EAP 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 sont pas conservées 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 EAP, 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 Java SE, Tomcat ou JBoss EAP dans Azure App Service.

Vous pouvez également configurer manuellement App Service pour qu’il exécute n’importe quel fichier au démarrage. 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 :

Regroupement

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 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 JBoss EAP 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 de réseau virtuel à partir de l’interface CLI ou du portail, cette propriété est définie automatiquement pour vous.

Lorsque le clustering est activé, les instances JBoss EAP utilisent le FILE_PING protocole de découverte JGroups pour découvrir de nouvelles instances et conserver les informations de cluster (par exemple, 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 EAP en supprimant les fichiers de découverte obsolètes au démarrage de votre application.

Les types de plan App Service v3, Premium V4 et V2 isolé peuvent éventuellement être distribués entre les zones de disponibilité afin d’améliorer la résilience et la fiabilité de vos charges de travail critiques 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

Lorsque vous configurez des règles de mise à l’échelle automatique pour la mise à l’échelle horizontale, il est important de supprimer des instances de manière incrémentielle (une à la fois) pour vous assurer que chaque instance supprimée peut transférer son activité (par exemple, gérer une transaction de base de données) vers un autre membre du cluster. Lorsque 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 par »
  • Refroidissement : « 5 minutes » ou plus
  • Nombre d’instances : 1

Vous n’avez pas besoin d’ajouter des instances de façon incrémentielle (scale-out). Vous pouvez ajouter plusieurs instances au cluster à la fois.

Plans App Service

JBoss EAP est disponible dans les niveaux tarifaires suivants : F1, P0v3, P1mv3, P2mv3, P3mv3, P4mv3, P5mv3, P0v4, P1mv4, P2mv4, P3mv4, P4mv4 et P5mv4.

Cycle de vie du serveur JBoss EAP

Une application JBoss EAP dans App Service passe par cinq phases distinctes avant de lancer le serveur :

  1. Phase de configuration de l’environnement
  2. Phase de lancement du serveur
  3. Phase de configuration du serveur
  4. Phase de déploiement d’application
  5. Phase de rechargement du serveur

Pour plus d’informations et d’opportunités de personnaliser (par exemple, via les paramètres de l’application), consultez les sections suivantes.

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 l’annuaire /var/ssl/certs et sont chargés sur $JRE_HOME/lib/security/cacerts.
    • Les certificats privés sont fournis par la plateforme dans l’annuaire /var/ssl/private et sont chargés sur $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.keyStoreet javax.net.ssl.keyStorePasswordjavax.net.ssl.keyStoreTypesont ajoutées à la variable d’environnementJAVA_OPTS.
  • Certaines configurations JVM initiales sont définies, telles que les répertoires de journalisation et les paramètres de tas de mémoire de la JVM :
    • 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 WEBSITES_CONTAINER_STOP_TIME_LIMITd’application, la valeur est transmise à la propriété org.wildfly.sigterm.suspend.timeoutruntime, qui contrôle le temps d’attente maximal d’arrêt (en secondes) lorsque JBoss EAP 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 WEBSITE_PRIVATE_PORTS d’environnement et lance JBoss EAP à l’aide de la clustering configuration. Sinon, la configuration standalone est utilisée.
    • Pour la clustering configuration, le fichier standalone-azure-full-ha.xml de configuration du serveur est utilisé.
    • Pour la standalone configuration, le fichier standalone-full.xml de configuration du serveur est utilisé.

2. Phase de lancement du serveur

  • Si JBoss EAP est lancé dans la clustering configuration :
    • Chaque instance JBoss EAP 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. L’autre instance du service s’est bloquée auparavant et a laissé des transactions non validées en suspens. Le serveur est configuré pour reprendre le travail sur ces transactions.
  • Indépendamment du démarrage ou de la clusteringstandalone configuration de JBoss EAP, 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 EAP.

3. Phase de configuration du serveur

  • Au début de cette phase, App Service attend d’abord que le serveur JBoss EAP et l’interface d’administration soient prêts à recevoir des demandes avant de continuer. Ce processus peut prendre quelques secondes supplémentaires si Application Insights est activé.

  • Lorsque JBoss EAP Server et l’interface d’administration sont prêts, App Service effectue les actions suivantes :

    • Ajoute le module azure.appserviceJBoss EAP, qui fournit des classes utilitaires pour la journalisation et l’intégration à App Service.
    • Met à jour l’enregistreur d’événements de la console pour qu’il utilise un mode sans couleur afin que les fichiers journaux ne soient pas pleins de séquences d’échappement en couleur.
    • Configure l’intégration aux journaux d’Azure Monitor.
    • Met à jour les adresses IP de liaison des interfaces WSDL (Web Services Description Language) et de gestion.
    • Ajoute le module JBoss EAP 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 WEBSITE_SKIP_AUTOCONFIGURE_DATABASE d’application est défini, App Service détecte automatiquement les URL JDBC (Java Database Connectivity) 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 les pilotes correspondants au serveur, ajoute une source de données pour chacune des URL JDBC et définit le nom Java Naming and Directory Interface (JNDI) pour chaque source java:jboss/env/jdbc/<app-setting-name>_DSde données, 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 /home/site/libs répertoire, 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. La logique de recherche pour le script de démarrage personnalisé est définie comme suit :

    • Si vous avez configuré une commande de démarrage (par exemple, via le portail Azure ou Azure CLI), exécutez-la ; autrement
    • Si le chemin /home/site/scripts/startup.sh existe, utilisez-le ; sinon,
    • Si le chemin /home/startup.sh existe, utilisez-le.

La commande ou le script de démarrage personnalisé s'exécute en tant qu'utilisateur root (pas besoin de sudo), ce qui leur permet d'installer des paquets Linux ou de lancer le CLI JBoss pour exécuter d'autres commandes d'installation et de personnalisation de JBoss EAP, comme la création de sources de données et l'installation d'adaptateurs de ressources. 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 EAP 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.
  • S'il existe d'autres fichiers EAR et WAR dans /home/site/wwwroot, déployez-les.
  • Si /home/site/wwwroot/webapps existe, déployez les fichiers et les répertoires qui s’y trouvent. 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, /home/site/wwwrootcopiez-les à la racine du serveur web et déployez-les en tant qu’application web.
  • Si aucun fichier déployable n’est 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 EAP 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 EAP quitte anormalement la clustering configuration, une fonction finale appelée emit_alert_tx_store_not_empty est exécutée. La fonction vérifie si le processus JBoss EAP a laissé un fichier de stockage de transactions non vide sur le 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 transactions non vides pour reprendre le travail (voir 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 : lorsque vous comprenez les détails de configuration du fichier server.xml et de Tomcat, vous pouvez ajuster les paramètres du serveur en fonction des 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. Ce processus inclut la vérification des journaux du serveur, l’examen des fichiers de configuration et l’identification des erreurs qui peuvent 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. Lorsque vous comprenez 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. Vous devez comprendre ces détails 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 officielle d’Apache Tomcat pour obtenir des informations détaillées, notamment la configuration par défaut de Tomcat Web Server.

En outre, certaines transformations sont appliquées au démarrage sur le fichier server.xml pour la distribution de Tomcat. Ces transformations incluent les modifications apportées aux paramètres du connecteur, de l’hôte et de la vanne .

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.
  • connectionTimeout est défini sur WEBSITE_TOMCAT_CONNECTION_TIMEOUT, qui est défini par défaut sur 240000.
  • maxThreads est défini sur WEBSITE_CATALINA_MAXTHREADS, qui est défini par défaut sur 200.
  • maxConnections est défini sur WEBSITE_CATALINA_MAXCONNECTIONS, qui est défini par défaut sur 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 connectionTimeout, maxThreadsou 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.

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 est défini sur AZURE_SITE_APP_BASE, qui est défini par défaut sur local WebappsLocalPath.
  • xmlBase est défini sur AZURE_SITE_HOME, qui est défini par défaut sur /site/wwwroot.
  • unpackWARs est défini sur AZURE_UNPACK_WARS, qui est défini par défaut sur true.
  • workDir est défini sur JAVA_TMP_DIR, ce qui prend par défaut la valeur TMP.
  • errorReportValveClass utilise notre vanne 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 défini sur WEBSITE_HTTPLOGGING_RETENTION_DAYS, qui est défini par défaut sur 7. Cette valeur s’aligne sur la plateforme de journalisation des applications par défaut.

Sur Linux, il a toutes les mêmes personnalisations et ajoute des pages d’erreur et de création de rapports à la vanne :

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

Contenu connexe

Visitez le Centre des développeurs Azure pour Java pour trouver des guides de démarrage rapide, des didacticiels et une documentation de référence Java Azure.

  • Last updated on