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

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.

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.

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

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

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.

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.

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.

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 :

• Documentation Red Hat JBoss EAP
• Recettes CLI WildFly

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.

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.

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.

• 1. Phase de configuration de l’environnement
• 2. Phase de lancement du serveur
• 3. Phase de configuration du serveur
• 4. Phase de déploiement de l’application
• 5. Phase de rechargement du 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

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

Voici des exemples de commandes CLI que vous pourrez utiliser pour modifier les valeurs de connectionTimeout, 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 défini sur WEBSITE_HTTPLOGGING_RETENTION_DAYS, qui a comme valeur par défaut 7. Ceci s’aligne avec la plateforme de journalisation des applications par défaut.

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>