Configurer une application Java pour Azure App Service

Article
04/18/2024

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.

Azure App Service permet aux développeurs Java de rapidement générer, déployer et mettre à l’échelle leurs applications web Java SE, Tomcat et JBoss EAP sur un service complètement managé. Déployez des applications avec les plug-ins Maven à partir de la ligne de commande ou dans des éditeurs comme IntelliJ, Eclipse ou Visual Studio Code.

Ce guide fournit les concepts et instructions clés aux développeurs Java qui utilisent 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.

Afficher la version de Java

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

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

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

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

Pour 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.11.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. 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 11</javaVersion>
    </runtime>
    <deployment>
      <resources>
        <resource>
          <type>jar</type>
          <directory>${project.basedir}/target</directory>
          <includes>
            <include>*.jar</include>
          </includes>
        </resource>
      </resources>
    </deployment>
  </configuration>
</plugin>

Gradle

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.7.1"
}
```

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 9.0' // or 'Java SE' if you want to run an executable jar
      javaVersion = 'Java 8'
    }
    appSettings {
        <key> = <value>
    }
    auth {
        type = 'azure_cli' // support azure_cli, oauth2, device_code and service_principal
    }
}

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 :

VS Code : Java Web Apps avec Visual Studio Code
IntelliJ IDEA : Créer une application web Hello World pour Azure App Service à l’aide d’IntelliJ
Eclipse : Créer une application web Hello World pour Azure App Service à l’aide d’Eclipse

API Kudu

Java SE

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

Tomcat

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.

JBoss EAP

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

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

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

Journalisation et débogage des applications

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

Diffuser les journaux de diagnostic

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

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

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

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

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

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

Notes

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

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

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

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

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

Java Profiler

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

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

Boîte noire SQL

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

Enregistrement chronométré

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

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

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

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 lui-même, 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. La journalisation sur l’instance du système de fichiers App Service locale est désactivée 12 heures après avoir été configurée. Si vous en avez besoin plus longtemps, configurez l’application pour écrire la sortie sur un conteneur de stockage d’objets blob. Vous trouverez vos journaux d’application Java et Tomcat dans le répertoire /home/LogFiles/Application/ .

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 pour Java SE ou CATALINA_OPTS pour Tomcat 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.

Sécuriser les applications

Les applications Java exécutées dans App Service exigent les mêmes bonnes pratiques de sécurité que les autres applications.

Authentifier les utilisateurs (authentification facile)

Configurez l’authentification de l’application dans le portail Azure avec l’option Authentification et autorisation. À partir de là, vous pouvez activer l’authentification en utilisant Microsoft Entra ID ou des infos d’identification des réseaux sociaux tels que Facebook, Google ou GitHub. La configuration du portail Azure fonctionne seulement si vous configurez un seul fournisseur d’authentification. Si vous souhaitez obtenir plus d’informations, consultez Configurer votre application App Service pour utiliser une connexion Microsoft Entra et les articles connexes pour d’autres fournisseurs d’identités. Si vous devez activer plusieurs fournisseurs de connexion, suivez les instructions de l’article Personnaliser les connexions et les déconnexions.

Java SE

Les développeurs Spring Boot peuvent utiliser le démarreur Spring Boot Microsoft Entra pour sécuriser des applications en tirant parti d’API et d’annotations Spring Security connues. Veillez à augmenter la taille d’en-tête maximale dans votre fichier application.properties. Nous vous suggérons une valeur de 16384.

Tomcat

Votre application Tomcat peut accéder directement aux revendications de l’utilisateur à partir du servlet en forçant le type de l’objet Principal en objet Map. L’objet Map mappe chaque type de revendication avec une collection des revendications de ce type. Dans l’exemple de code suivant, request est une instance de HttpServletRequest.

Map<String, Collection<String>> map = (Map<String, Collection<String>>) request.getUserPrincipal();

Vous pouvez maintenant inspecter l’objet Map pour une revendication spécifique. Par exemple, l’extrait de code suivant effectue une itération dans tous les types de revendications et imprime le contenu de chaque collection.

for (Object key : map.keySet()) {
        Object value = map.get(key);
        if (value != null && value instanceof Collection {
            Collection claims = (Collection) value;
            for (Object claim : claims) {
                System.out.println(claims);
            }
        }
    }

Pour déconnecter les utilisateurs, utilisez le chemin /.auth/ext/logout. Pour effectuer d’autres actions, consultez la documentation relative à la Personnalisation des connexions et des déconnexions. Il existe également une documentation officielle sur l’interface HttpServletRequest de Tomcat et ses méthodes. Les méthodes servlet suivantes sont également alimentées en fonction de la configuration de votre App Service :

public boolean isSecure()
public String getRemoteAddr()
public String getRemoteHost()
public String getScheme()
public int getServerPort()

Pour désactiver cette fonctionnalité, créez un paramètre d’application nommé WEBSITE_AUTH_SKIP_PRINCIPAL avec la valeur 1. Pour désactiver tous les filtres de servlet ajoutés par App Service, créez un paramètre nommé WEBSITE_SKIP_FILTERS avec la valeur 1.

Configurer TLS/SSL

Pour charger un certificat TLS/SSL existant et le lier au nom de domaine de votre application, suivez les instructions de l’article Sécuriser un nom DNS personnalisé avec une liaison TLS/SSL dans Azure App Service. Vous pouvez également configurer l’application pour appliquer TLS/SSL.

Utiliser des références KeyVault

Azure Key Vault fournit une gestion des secrets centralisée avec des stratégies d’accès et un historique d’audit. Vous pouvez stocker des secrets (tels que des mots de passe ou chaînes de connexion) dans KeyVault et accéder à ces secrets dans votre application via des variables d’environnement.

Tout d’abord, suivez les instructions pour autoriser votre application à accéder au coffre de clés et pour créer une référence du Coffre de clés à votre secret dans un Paramètre d’application. Vous pouvez vérifier la résolution de la référence en secret en imprimant la variable d’environnement tout en accédant à distance au terminal App Service.

Pour injecter ces secrets dans votre fichier de configuration Spring ou Tomcat, utilisez la syntaxe d’injection de variable d’environnement (${MY_ENV_VAR}). Pour les fichiers de configuration Spring, consultez cette documentation sur les configurations externalisées.

Utiliser le magasin de clés Java

Par défaut, tous les certificats publics ou privés chargés sur App Service Linux sont chargés dans les magasins de clés Java respectifs au démarrage du conteneur. Après le chargement de votre certificat, vous devrez redémarrer votre App Service afin de le charger dans Java Key Store. Les certificats publics sont chargés dans le magasin de clés sur $JRE_HOME/lib/security/cacerts, et les certificats privés sont stockés dans $JRE_HOME/lib/security/client.jks.

Une configuration supplémentaire peut être nécessaire pour chiffrer votre connexion JDBC avec des certificats dans le magasin de clés Java. Reportez-vous à la documentation du pilote JDBC que vous avez choisi.

Initialiser le magasin de clés Java

Pour initialiser l’objet import java.security.KeyStore, chargez le fichier de magasin de clés avec le mot de passe. Le mot de passe par défaut pour les deux magasins de clés est changeit.

KeyStore keyStore = KeyStore.getInstance("jks");
keyStore.load(
    new FileInputStream(System.getenv("JRE_HOME")+"/lib/security/cacerts"),
    "changeit".toCharArray());

KeyStore keyStore = KeyStore.getInstance("pkcs12");
keyStore.load(
    new FileInputStream(System.getenv("JRE_HOME")+"/lib/security/client.jks"),
    "changeit".toCharArray());

Charger manuellement le magasin de clés

Vous pouvez charger les certificats manuellement dans le magasin de clés. Créez un paramètre d'application, SKIP_JAVA_KEYSTORE_LOAD, avec une valeur de 1 pour désactiver le chargement automatique des certificats dans le magasin de clés. Tous les certificats publics chargés sur App Service via le portail Azure sont stockés sous /var/ssl/certs/. Les certificats privés sont stockés sous /var/ssl/private/.

Vous pouvez interagir ou déboguer l'outil Java Key Tool en ouvrant une connexion SSH sur votre App Service et en exécutant la commande keytool. Consultez la documentation de Key Tool pour obtenir une liste des commandes. Pour plus d’informations sur l’API KeyStore, consultez la documentation officielle.

Configurer des plateformes d’APM

Cette section explique comment connecter des applications Java déployées sur Azure App Service avec Azure Monitor Application Insights, NewRelic et des plateformes de surveillance des performances d’application AppDynamics.

Configurer Application Insights

Azure Monitor Application Insights est un service de surveillance des applications natif cloud, qui permet aux clients d’observer les défaillances, les goulots d’étranglement et les modèles d’utilisation pour améliorer les performances des applications et réduire le temps moyen de résolution. Quelques clics ou commandes de l’interface CLI suffisent pour activer la supervision de vos applications Node.js ou Java, journaux de collecte automatique, métriques et traces distribuées, éliminant ainsi la nécessité d’inclure un kit de développement logiciel (SDK) dans votre application. Pour plus d’informations sur les paramètres d’application disponibles pour la configuration de l’agent, consultez la documentation Application Insights.

Portail Azure

Pour activer Application Insights à partir du portail Azure, accédez à Application Insights dans le menu de gauche, puis sélectionnez Activer Application Insights. Par défaut, une nouvelle ressource Application Insights du même nom que votre application web est utilisée. Vous pouvez choisir d’utiliser une ressource Application Insights existante ou de modifier le nom. Sélectionnez Appliquer en bas.

Azure CLI

Pour activer Application Insights via Azure CLI, vous devez créer une ressource Application Insights et définir deux paramètres d’application sur le portail Azure pour connecter Application Insights à votre application web.

Activer l’extension Application Insights

az extension add -n application-insights

Créez une ressource Application Insights à l’aide de la commande CLI suivante. Remplacez les espaces réservés par le nom de ressource et le groupe de votre choix.
```
az monitor app-insights component create --app <resource-name> -g <resource-group> --location westus2  --kind web --application-type web
```
Notez les valeurs de connectionString et instrumentationKey, car vous en aurez besoin à l’étape suivante.

Pour récupérer une liste d’autres emplacements, exécutez la commande az account list-locations.

Définissez la clé d’instrumentation, la chaîne de connexion et la version de l’agent de surveillance en tant que paramètres d’application sur l’application web. Remplacez <instrumentationKey> et <connectionString> par les valeurs notées à l’étape précédente.

az webapp config appsettings set -n <webapp-name> -g <resource-group> --settings "APPINSIGHTS_INSTRUMENTATIONKEY=<instrumentationKey>" "APPLICATIONINSIGHTS_CONNECTION_STRING=<connectionString>" "ApplicationInsightsAgent_EXTENSION_VERSION=~3" "XDT_MicrosoftApplicationInsights_Mode=default" "XDT_MicrosoftApplicationInsights_Java=1"

az webapp config appsettings set -n <webapp-name> -g <resource-group> --settings "APPINSIGHTS_INSTRUMENTATIONKEY=<instrumentationKey>" "APPLICATIONINSIGHTS_CONNECTION_STRING=<connectionString>" "ApplicationInsightsAgent_EXTENSION_VERSION=~3" "XDT_MicrosoftApplicationInsights_Mode=default"

Configurer New Relic

Créez un compte NewRelic sur NewRelic.com
Téléchargez l’agent Java à partir de NewRelic. Il a un nom de fichier similaire à newrelic-java-x.x.x.zip.
Copiez votre clé de licence, vous en avez besoin pour configurer l’agent par la suite.
Connectez-vous avec SSH à votre instance App Service et créez un répertoire /home/site/wwwroot/apm.
Chargez les fichiers de l’agent Java de NewRelic décompressés dans un répertoire sous /home/site/wwwroot/apm. Les fichiers de votre agent doivent se trouver dans /home/site/wwwroot/apm/newrelic.
Modifiez le fichier YAML dans /home/site/wwwroot/apm/newrelic/newrelic.yml et remplacez la valeur de la licence d’espace réservé par votre propre clé de licence.
Dans le portail Azure, accédez à votre application dans App Service et créez un paramètre d’application.
- Pour les applications Java SE, créez une variable d’environnement nommée JAVA_OPTS avec la valeur -javaagent:/home/site/wwwroot/apm/newrelic/newrelic.jar.
- Pour Tomcat, créez une variable d’environnement nommée CATALINA_OPTS avec la valeur -javaagent:/home/site/wwwroot/apm/newrelic/newrelic.jar.

Créez un compte NewRelic sur NewRelic.com
Téléchargez l’agent Java à partir de NewRelic. Il a un nom de fichier similaire à newrelic-java-x.x.x.zip.
Copiez votre clé de licence, vous en aurez besoin pour configurer l’agent par la suite.
Connectez-vous avec SSH à votre instance App Service et créez un répertoire /home/site/wwwroot/apm.
Chargez les fichiers de l’agent Java de NewRelic décompressés dans un répertoire sous /home/site/wwwroot/apm. Les fichiers de votre agent doivent se trouver dans /home/site/wwwroot/apm/newrelic.
Modifiez le fichier YAML dans /home/site/wwwroot/apm/newrelic/newrelic.yml et remplacez la valeur de la licence d’espace réservé par votre propre clé de licence.
Dans le portail Azure, accédez à votre application dans App Service et créez un paramètre d’application.
- Pour les applications Java SE, créez une variable d’environnement nommée JAVA_OPTS avec la valeur -javaagent:/home/site/wwwroot/apm/newrelic/newrelic.jar.
- Pour Tomcat, créez une variable d’environnement nommée CATALINA_OPTS avec la valeur -javaagent:/home/site/wwwroot/apm/newrelic/newrelic.jar.

Si vous avez déjà une variable d’environnement pour JAVA_OPTS ou CATALINA_OPTS, ajoutez l’option -javaagent:/... à la fin de la valeur actuelle.

Configurer AppDynamics

Créez un compte AppDynamics sur AppDynamics.com
Téléchargez l’agent Java à partir du site web AppDynamics. Le nom de fichier est similaire à AppServerAgent-x.x.x.xxxxx.zip
Utilisez la console Kudu pour créer un répertoire /home/site/wwwroot/apm.
Chargez les fichiers de l’agent Java dans un répertoire sous /home/site/wwwroot/apm. Les fichiers de votre agent doivent se trouver dans /home/site/wwwroot/apm/appdynamics.
Dans le portail Azure, accédez à votre application dans App Service et créez un paramètre d’application.
- Pour les applications Java SE, créez une variable d’environnement nommée JAVA_OPTS avec la valeur -javaagent:/home/site/wwwroot/apm/appdynamics/javaagent.jar -Dappdynamics.agent.applicationName=<app-name>, où <app-name> est le nom de votre instance App Service.
- Pour les applications Tomcat, créez une variable d’environnement nommée CATALINA_OPTS avec la valeur -javaagent:/home/site/wwwroot/apm/appdynamics/javaagent.jar -Dappdynamics.agent.applicationName=<app-name>, où <app-name> est le nom de votre instance App Service.

Créez un compte AppDynamics sur AppDynamics.com
Téléchargez l’agent Java à partir du site web AppDynamics. Le nom de fichier est similaire à AppServerAgent-x.x.x.xxxxx.zip
Connectez-vous avec SSH à votre instance App Service et créez un répertoire /home/site/wwwroot/apm.
Chargez les fichiers de l’agent Java dans un répertoire sous /home/site/wwwroot/apm. Les fichiers de votre agent doivent se trouver dans /home/site/wwwroot/apm/appdynamics.
Dans le portail Azure, accédez à votre application dans App Service et créez un paramètre d’application.
- Pour les applications Java SE, créez une variable d’environnement nommée JAVA_OPTS avec la valeur -javaagent:/home/site/wwwroot/apm/appdynamics/javaagent.jar -Dappdynamics.agent.applicationName=<app-name>, où <app-name> est le nom de votre instance App Service.
- Pour les applications Tomcat, créez une variable d’environnement nommée CATALINA_OPTS avec la valeur -javaagent:/home/site/wwwroot/apm/appdynamics/javaagent.jar -Dappdynamics.agent.applicationName=<app-name>, où <app-name> est le nom de votre instance App Service.

Notes

Si vous avez déjà une variable d’environnement pour JAVA_OPTS ou CATALINA_OPTS, ajoutez l’option -javaagent:/... à la fin de la valeur actuelle.

Configurer des sources de données

Java SE

Pour vous connecter à des sources de données dans des applications Spring Boot, nous vous suggérons de créer des chaînes de connexion et de les injecter dans votre fichier application.properties.

Dans la section « Configuration » de la page App Service, définissez un nom pour la chaîne, collez votre chaîne de connexion JDBC dans le champ de valeur, puis définissez le type sur « Personnalisé ». Vous pouvez éventuellement définir cette chaîne de connexion en tant que paramètre d’emplacement.

Cette chaîne de connexion est accessible à notre application en tant que variable d’environnement nommée CUSTOMCONNSTR_<your-string-name>. Par exemple : CUSTOMCONNSTR_exampledb.
Dans votre fichier application.properties, référencez cette chaîne de connexion avec le nom de variable d’environnement. Dans notre exemple, nous utiliserions ce qui suit.
```
app.datasource.url=${CUSTOMCONNSTR_exampledb}
```

Pour plus d’informations, consultez la documentation Spring Boot sur l’accès aux données et les configurations externalisées.

Tomcat

Ces instructions s’appliquent à toutes les connexions de base de données. Vous devez remplir les espaces réservés avec le nom de la classe du pilote de la base de données que vous avez choisie ainsi que le fichier JAR. Vous disposez d’une table contenant des noms de classes et de téléchargements de pilotes pour les bases de données courantes.

Base de données	Nom de la classe du pilote	Pilote JDBC
PostgreSQL	`org.postgresql.Driver`	Télécharger
MySQL	`com.mysql.jdbc.Driver`	Télécharger (sélectionnez « Indépendant de la plateforme »)
SQL Server	`com.microsoft.sqlserver.jdbc.SQLServerDriver`	Télécharger

Pour configurer Tomcat afin d’utiliser Java Database Connectivity (JDBC) ou l’API Java Persistence (JPA), commencez par personnaliser la variable d’environnement CATALINA_OPTS lue par Tomcat au démarrage. Définissez ces valeurs via un paramètre d’application dans le plug-in Maven App Service :

<appSettings>
    <property>
        <name>CATALINA_OPTS</name>
        <value>"$CATALINA_OPTS -Ddbuser=${DBUSER} -Ddbpassword=${DBPASSWORD} -DconnURL=${CONNURL}"</value>
    </property>
</appSettings>

Ou définissez les variables d’environnement dans la page Configuration>Paramètres d’application du portail Azure.

Ensuite, déterminez si la source de données doit être mise à la disposition d’une seule application ou de toutes les applications exécutées sur le servlet Tomcat.

Sources de données au niveau de l’application

Créez un fichier context.xml dans le répertoire META-INF / de votre projet. Créez le répertoire META-INF/ s’il n’existe pas.

Dans context.xml, ajoutez un élément Context pour lier la source de données à une adresse JNDI. Remplacez l’espace réservé driverClassName par le nom de la classe de votre pilote à l’aide du tableau ci-dessus.

<Context>
    <Resource
        name="jdbc/dbconnection"
        type="javax.sql.DataSource"
        url="${connURL}"
        driverClassName="<insert your driver class name>"
        username="${dbuser}"
        password="${dbpassword}"
    />
</Context>

Mettez à jour le fichier web.xml de votre application pour utiliser la source de données dans votre application.

<resource-env-ref>
    <resource-env-ref-name>jdbc/dbconnection</resource-env-ref-name>
    <resource-env-ref-type>javax.sql.DataSource</resource-env-ref-type>
</resource-env-ref>

Ressources au niveau du serveur partagées

Les installations Tomcat sur App Service sur Windows existent dans l’espace partagé sur le plan App Service. Vous ne pouvez pas modifier directement une installation Tomcat pour une configuration à l’ensemble du serveur. Pour apporter des modifications de configuration au niveau du serveur à votre installation Tomcat, vous devez copier Tomcat dans un dossier local, dans lequel vous pouvez modifier la configuration de Tomcat.

Automatisation de la création d’une application personnalisée Tomcat au démarrage de l’application

Vous pouvez utiliser un script de démarrage pour effectuer des actions avant le démarrage d’une application web. Le script de démarrage pour la personnalisation de Tomcat doit effectuer les étapes suivantes :

Vérifier si Tomcat a déjà été copié et configuré localement. Si c’est le cas, le script de démarrage peut se terminer ici.
Copier Tomcat localement.
Apporter les modifications de configuration requises.
Indiquer que la configuration a été correctement effectuée.

Pour les applications Windows, créez un fichier nommé startup.cmd ou startup.ps1 dans le répertoire wwwroot. Ce fichier est automatiquement exécuté avant le démarrage du serveur Tomcat.

Voici un script PowerShell qui effectue ces étapes :

    # Check for marker file indicating that config has already been done
    if(Test-Path "$Env:LOCAL_EXPANDED\tomcat\config_done_marker"){
        return 0
    }

    # Delete previous Tomcat directory if it exists
    # In case previous config isn't completed or a new config should be forcefully installed
    if(Test-Path "$Env:LOCAL_EXPANDED\tomcat"){
        Remove-Item "$Env:LOCAL_EXPANDED\tomcat" --recurse
    }

    # Copy Tomcat to local
    # Using the environment variable $AZURE_TOMCAT90_HOME uses the 'default' version of Tomcat
    Copy-Item -Path "$Env:AZURE_TOMCAT90_HOME\*" -Destination "$Env:LOCAL_EXPANDED\tomcat" -Recurse

    # Perform the required customization of Tomcat
    {... customization ...}

    # Mark that the operation was a success
    New-Item -Path "$Env:LOCAL_EXPANDED\tomcat\config_done_marker" -ItemType File

Transformations

Un cas d’usage courant pour la personnalisation d’une version de Tomcat consiste à modifier les fichiers de configuration server.xml, context.xml ou web.xml de Tomcat. App Service modifie déjà ces fichiers pour fournir des fonctionnalités de plateforme. Pour continuer à utiliser ces fonctionnalités, il est important de conserver le contenu de ces fichiers lorsque vous y apportez des modifications. Pour ce faire, nous vous recommandons d’utiliser une transformation XSL (XSLT). Utilisez une transformation XSL pour apporter des modifications aux fichiers XML tout en conservant le contenu d’origine du fichier.

Exemple de fichier XSLT

Cet exemple de transformation ajoute un nouveau nœud de connecteur à server.xml. Notez la transformation d’identité, qui conserve le contenu d’origine du fichier.

    <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
    <xsl:output method="xml" indent="yes"/>

    <!-- Identity transform: this ensures that the original contents of the file are included in the new file -->
    <!-- Ensure that your transform files include this block -->
    <xsl:template match="@* | node()" name="Copy">
      <xsl:copy>
        <xsl:apply-templates select="@* | node()"/>
      </xsl:copy>
    </xsl:template>

    <xsl:template match="@* | node()" mode="insertConnector">
      <xsl:call-template name="Copy" />
    </xsl:template>

    <xsl:template match="comment()[not(../Connector[@scheme = 'https']) and
                                   contains(., '&lt;Connector') and
                                   (contains(., 'scheme=&quot;https&quot;') or
                                    contains(., &quot;scheme='https'&quot;))]">
      <xsl:value-of select="." disable-output-escaping="yes" />
    </xsl:template>

    <xsl:template match="Service[not(Connector[@scheme = 'https'] or
                                     comment()[contains(., '&lt;Connector') and
                                               (contains(., 'scheme=&quot;https&quot;') or
                                                contains(., &quot;scheme='https'&quot;))]
                                    )]
                        ">
      <xsl:copy>
        <xsl:apply-templates select="@* | node()" mode="insertConnector" />
      </xsl:copy>
    </xsl:template>

    <!-- Add the new connector after the last existing Connnector if there's one -->
    <xsl:template match="Connector[last()]" mode="insertConnector">
      <xsl:call-template name="Copy" />

      <xsl:call-template name="AddConnector" />
    </xsl:template>

    <!-- ... or before the first Engine if there's no existing Connector -->
    <xsl:template match="Engine[1][not(preceding-sibling::Connector)]"
                  mode="insertConnector">
      <xsl:call-template name="AddConnector" />

      <xsl:call-template name="Copy" />
    </xsl:template>

    <xsl:template name="AddConnector">
      <!-- Add new line -->
      <xsl:text>&#xa;</xsl:text>
      <!-- This is the new connector -->
      <Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true" 
                 maxThreads="150" scheme="https" secure="true" 
                 keystoreFile="${{user.home}}/.keystore" keystorePass="changeit"
                 clientAuth="false" sslProtocol="TLS" />
    </xsl:template>

    </xsl:stylesheet>

Fonction pour la transformation XSL

PowerShell offre des outils intégrés permettant de transformer des fichiers XML à l’aide de transformations XSL. Le script suivant est un exemple de fonction que vous pouvez utiliser dans startup.ps1 pour effectuer la transformation :

    function TransformXML{
        param ($xml, $xsl, $output)

        if (-not $xml -or -not $xsl -or -not $output)
        {
            return 0
        }

        Try
        {
            $xslt_settings = New-Object System.Xml.Xsl.XsltSettings;
            $XmlUrlResolver = New-Object System.Xml.XmlUrlResolver;
            $xslt_settings.EnableScript = 1;

            $xslt = New-Object System.Xml.Xsl.XslCompiledTransform;
            $xslt.Load($xsl,$xslt_settings,$XmlUrlResolver);
            $xslt.Transform($xml, $output);

        }

        Catch
        {
            $ErrorMessage = $_.Exception.Message
            $FailedItem = $_.Exception.ItemName
            Write-Host  'Error'$ErrorMessage':'$FailedItem':' $_.Exception;
            return 0
        }
        return 1
    }

Paramètres de l’application

La plateforme doit également savoir où votre version personnalisée de Tomcat est installée. Vous pouvez définir l’emplacement de l’installation dans le paramètre d’application CATALINA_BASE.

Vous pouvez utiliser Azure CLI pour changer ce paramètre :

    az webapp config appsettings set -g $MyResourceGroup -n $MyUniqueApp --settings CATALINA_BASE="%LOCAL_EXPANDED%\tomcat"

Ou vous pouvez modifier manuellement le paramètre dans le portail Azure :

Accédez à Paramètres>Configuration>Paramètres d’application.
Sélectionnez + New application setting (+ Nouveau paramètre d’application).
Utilisez ces valeurs pour créer le paramètre :
1. Nom : CATALINA_BASE
2. Valeur : "%LOCAL_EXPANDED%\tomcat"

Exemple avec startup.ps1

L’exemple de script suivant copie un fichier Tomcat personnalisé vers un dossier local, exécute une transformation XSL et indique que la transformation a réussi :

    # Locations of xml and xsl files
    $target_xml="$Env:LOCAL_EXPANDED\tomcat\conf\server.xml"
    $target_xsl="$Env:HOME\site\server.xsl"

    # Define the transform function
    # Useful if transforming multiple files
    function TransformXML{
        param ($xml, $xsl, $output)

        if (-not $xml -or -not $xsl -or -not $output)
        {
            return 0
        }

        Try
        {
            $xslt_settings = New-Object System.Xml.Xsl.XsltSettings;
            $XmlUrlResolver = New-Object System.Xml.XmlUrlResolver;
            $xslt_settings.EnableScript = 1;

            $xslt = New-Object System.Xml.Xsl.XslCompiledTransform;
            $xslt.Load($xsl,$xslt_settings,$XmlUrlResolver);
            $xslt.Transform($xml, $output);
        }

        Catch
        {
            $ErrorMessage = $_.Exception.Message
            $FailedItem = $_.Exception.ItemName
            echo  'Error'$ErrorMessage':'$FailedItem':' $_.Exception;
            return 0
        }
        return 1
    }

    $success = TransformXML -xml $target_xml -xsl $target_xsl -output $target_xml

    # Check for marker file indicating that config has already been done
    if(Test-Path "$Env:LOCAL_EXPANDED\tomcat\config_done_marker"){
        return 0
    }

    # Delete previous Tomcat directory if it exists
    # In case previous config isn't completed or a new config should be forcefully installed
    if(Test-Path "$Env:LOCAL_EXPANDED\tomcat"){
        Remove-Item "$Env:LOCAL_EXPANDED\tomcat" --recurse
    }

    md -Path "$Env:LOCAL_EXPANDED\tomcat"

    # Copy Tomcat to local
    # Using the environment variable $AZURE_TOMCAT90_HOME uses the 'default' version of Tomcat
    Copy-Item -Path "$Env:AZURE_TOMCAT90_HOME\*" "$Env:LOCAL_EXPANDED\tomcat" -Recurse

    # Perform the required customization of Tomcat
    $success = TransformXML -xml $target_xml -xsl $target_xsl -output $target_xml

    # Mark that the operation was a success if successful
    if($success){
        New-Item -Path "$Env:LOCAL_EXPANDED\tomcat\config_done_marker" -ItemType File
    }

Finaliser la configuration

Enfin, placez les fichiers du pilote JAR dans le classpath Tomcat, puis redémarrez votre App Service. Veillez à ce que les fichiers du pilote JDBC soient disponibles pour le chargeur de classes Tomcat en les mettant dans le répertoire /home/site/lib. Dans Cloud Shell, exécutez az webapp deploy --type=lib pour chaque fichier JAR de pilote :

az webapp deploy --resource-group <group-name> --name <app-name> --src-path <jar-name>.jar --type=lib --target-path <jar-name>.jar

Tomcat

Base de données	Nom de la classe du pilote	Pilote JDBC
PostgreSQL	`org.postgresql.Driver`	Télécharger
MySQL	`com.mysql.jdbc.Driver`	Télécharger (sélectionnez « Indépendant de la plateforme »)
SQL Server	`com.microsoft.sqlserver.jdbc.SQLServerDriver`	Télécharger

<appSettings>
    <property>
        <name>CATALINA_OPTS</name>
        <value>"$CATALINA_OPTS -Ddbuser=${DBUSER} -Ddbpassword=${DBPASSWORD} -DconnURL=${CONNURL}"</value>
    </property>
</appSettings>

Ou définissez les variables d’environnement dans la page Configuration>Paramètres d’application du portail Azure.

Ensuite, déterminez si la source de données doit être mise à la disposition d’une seule application ou de toutes les applications exécutées sur le servlet Tomcat.

Sources de données au niveau de l’application

Créez un fichier context.xml dans le répertoire META-INF / de votre projet. Créez le répertoire META-INF/ s’il n’existe pas.

<Context>
    <Resource
        name="jdbc/dbconnection"
        type="javax.sql.DataSource"
        url="${connURL}"
        driverClassName="<insert your driver class name>"
        username="${dbuser}"
        password="${dbpassword}"
    />
</Context>

Mettez à jour le fichier web.xml de votre application pour utiliser la source de données dans votre application.

<resource-env-ref>
    <resource-env-ref-name>jdbc/dbconnection</resource-env-ref-name>
    <resource-env-ref-type>javax.sql.DataSource</resource-env-ref-type>
</resource-env-ref>

Ressources au niveau du serveur partagées

Pour ajouter une source de données partagée au niveau du serveur, vous devez modifier le fichier server.xml de Tomcat. Tout d’abord, téléchargez un script de démarrage et définissez le chemin d’accès au script dans Configuration>Commande de démarrage. Vous pouvez télécharger le script de démarrage à l’aide de FTP.

Votre script de démarrage crée une transformation xsl sur le fichier server.xml et génère le fichier xml résultant sur /usr/local/tomcat/conf/server.xml. Le script de démarrage doit installer libxslt via apk. Votre fichier xsl et votre script de démarrage peuvent être téléchargés via FTP. Vous trouverez ci-dessous un exemple de script de démarrage.

# Install libxslt. Also copy the transform file to /home/tomcat/conf/
apk add --update libxslt

# Usage: xsltproc --output output.xml style.xsl input.xml
xsltproc --output /home/tomcat/conf/server.xml /home/tomcat/conf/transform.xsl /usr/local/tomcat/conf/server.xml

L’exemple de fichier XSL suivant ajoute un nouveau nœud de connecteur au fichier server.xml Tomcat.

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:output method="xml" indent="yes"/>

  <xsl:template match="@* | node()" name="Copy">
    <xsl:copy>
      <xsl:apply-templates select="@* | node()"/>
    </xsl:copy>
  </xsl:template>

  <xsl:template match="@* | node()" mode="insertConnector">
    <xsl:call-template name="Copy" />
  </xsl:template>

  <xsl:template match="comment()[not(../Connector[@scheme = 'https']) and
                                 contains(., '&lt;Connector') and
                                 (contains(., 'scheme=&quot;https&quot;') or
                                  contains(., &quot;scheme='https'&quot;))]">
    <xsl:value-of select="." disable-output-escaping="yes" />
  </xsl:template>

  <xsl:template match="Service[not(Connector[@scheme = 'https'] or
                                   comment()[contains(., '&lt;Connector') and
                                             (contains(., 'scheme=&quot;https&quot;') or
                                              contains(., &quot;scheme='https'&quot;))]
                                  )]
                      ">
    <xsl:copy>
      <xsl:apply-templates select="@* | node()" mode="insertConnector" />
    </xsl:copy>
  </xsl:template>

  <!-- Add the new connector after the last existing Connnector if there's one -->
  <xsl:template match="Connector[last()]" mode="insertConnector">
    <xsl:call-template name="Copy" />

    <xsl:call-template name="AddConnector" />
  </xsl:template>

  <!-- ... or before the first Engine if there's no existing Connector -->
  <xsl:template match="Engine[1][not(preceding-sibling::Connector)]"
                mode="insertConnector">
    <xsl:call-template name="AddConnector" />

    <xsl:call-template name="Copy" />
  </xsl:template>

  <xsl:template name="AddConnector">
    <!-- Add new line -->
    <xsl:text>&#xa;</xsl:text>
    <!-- This is the new connector -->
    <Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true" 
               maxThreads="150" scheme="https" secure="true" 
               keystoreFile="${{user.home}}/.keystore" keystorePass="changeit"
               clientAuth="false" sslProtocol="TLS" />
  </xsl:template>

</xsl:stylesheet>

Finaliser la configuration

Enfin, placez les fichiers du pilote JAR dans le classpath Tomcat puis redémarrez votre App Service.

Veillez à ce que les fichiers du pilote JDBC soient disponibles pour le chargeur de classes Tomcat en les mettant dans le répertoire /home/site/lib. Dans Cloud Shell, exécutez az webapp deploy --type=lib pour chaque fichier JAR de pilote :

az webapp deploy --resource-group <group-name> --name <app-name> --src-path <jar-name>.jar --type=lib --path <jar-name>.jar

Si vous avez créé une source de données de niveau serveur, redémarrez l’application App Service Linux. Tomcat rétablit CATALINA_BASE sur /home/tomcat et utilise la configuration mise à jour.

Sources de données JBoss EAP

Il existe trois étapes de base lors de l’inscription d’une source de données avec JBoss EAP : chargement du pilote JDBC, ajout du pilote JDBC en tant que module et inscription du module. App Service est un service d’hébergement sans état. Par conséquent, les commandes de configuration pour l’ajout et l’inscription du module de source de données doivent être scriptées et appliquées au démarrage du conteneur.

Obtenez le pilote JDBC de votre base de données.

Créez un fichier de définition de module XML pour le pilote JDBC. L’exemple suivant montre une définition de module pour PostgreSQL.

<?xml version="1.0" ?>
<module xmlns="urn:jboss:module:1.1" name="org.postgres">
    <resources>
    <!-- ***** IMPORTANT : REPLACE THIS PLACEHOLDER *******-->
    <resource-root path="/home/site/deployments/tools/postgresql-42.2.12.jar" />
    </resources>
    <dependencies>
        <module name="javax.api"/>
        <module name="javax.transaction.api"/>
    </dependencies>
</module>

Placez vos commandes d’interface de ligne de commande JBoss dans un fichier nommé jboss-cli-commands.cli. Les commandes JBoss doivent ajouter le module et l’inscrire en tant que source de données. L’exemple suivant montre les commandes d’interface CLI JBoss pour PostgreSQL.

#!/usr/bin/env bash
module add --name=org.postgres --resources=/home/site/deployments/tools/postgresql-42.2.12.jar --module-xml=/home/site/deployments/tools/postgres-module.xml

/subsystem=datasources/jdbc-driver=postgres:add(driver-name="postgres",driver-module-name="org.postgres",driver-class-name=org.postgresql.Driver,driver-xa-datasource-class-name=org.postgresql.xa.PGXADataSource)

data-source add --name=postgresDS --driver-name=postgres --jndi-name=java:jboss/datasources/postgresDS --connection-url=${POSTGRES_CONNECTION_URL,env.POSTGRES_CONNECTION_URL:jdbc:postgresql://db:5432/postgres} --user-name=${POSTGRES_SERVER_ADMIN_FULL_NAME,env.POSTGRES_SERVER_ADMIN_FULL_NAME:postgres} --password=${POSTGRES_SERVER_ADMIN_PASSWORD,env.POSTGRES_SERVER_ADMIN_PASSWORD:example} --use-ccm=true --max-pool-size=5 --blocking-timeout-wait-millis=5000 --enabled=true --driver-class=org.postgresql.Driver --exception-sorter-class-name=org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter --jta=true --use-java-context=true --valid-connection-checker-class-name=org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker

Créez un script de démarrage, startup_script.sh, qui appelle les commandes d’interface de ligne de commande JBoss. L'exemple suivant montre comment nommer votre jboss-cli-commands.cli. Plus tard, vous configurerez App Service pour exécuter ce script au démarrage du conteneur.
```
$JBOSS_HOME/bin/jboss-cli.sh --connect --file=/home/site/deployments/tools/jboss-cli-commands.cli
```
À l’aide d’un client FTP de votre choix, chargez votre pilote JDBC, jboss-cli-commands.cli, startup_script.sh et la définition du module dans /site/deployments/tools/.
Configurez votre site pour qu’il exécute startup_script.sh au démarrage du conteneur. Dans le portail Azure, accédez à Configuration>Paramètres généraux>Commande de démarrage. Définissez le champ de commande de démarrage sur /home/site/deployments/tools/startup_script.sh. Enregistrez les changements apportés.

Pour confirmer que la source de source a été ajoutée au serveur JBoss, connectez-vous avec SSH dans votre application web et exécutez $JBOSS_HOME/bin/jboss-cli.sh --connect. Une fois connecté à JBoss, exécutez /subsystem=datasources:read-resource pour imprimer une liste des sources de données.

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.

JBoss EAP

Clustering dans JBoss EAP

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

Remarque

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

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

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 Services pour JBoss EAP

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

Configuration de la base de référence Tomcat sur App Services

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.

Notez que les dernières versions de Tomcat ont server.xml (version 8.5.58 et 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.

Configurer une application Java pour Azure App Service

Afficher la version de Java

Déploiement de votre application

Outils de build

Maven

Gradle

IDE

API Kudu

Java SE

Tomcat

JBoss EAP

Journalisation et débogage des applications

Diffuser les journaux de diagnostic

Accès à la console SSH

Outils de résolution des problèmes

Java Profiler

Boîte noire SQL

Enregistrement chronométré

Enregistrement continu

Analyser les fichiers .jfr

Journalisation des applications

Personnalisation et réglage

Copiez le contenu de l’application localement

Définir les options de runtime Java

Activer les sockets web

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

Précompiler les fichiers JSP

Sécuriser les applications

Authentifier les utilisateurs (authentification facile)

Java SE

Tomcat

Configurer TLS/SSL

Utiliser des références KeyVault

Utiliser le magasin de clés Java

Initialiser le magasin de clés Java

Charger manuellement le magasin de clés

Configurer des plateformes d’APM

Configurer Application Insights

Portail Azure

Azure CLI

Configurer New Relic

Configurer AppDynamics

Configurer des sources de données

Java SE

Tomcat

Sources de données au niveau de l’application

Ressources au niveau du serveur partagées

Automatisation de la création d’une application personnalisée Tomcat au démarrage de l’application

Transformations

Exemple de fichier XSLT

Fonction pour la transformation XSL

Paramètres de l’application

Exemple avec startup.ps1

Finaliser la configuration

Tomcat

Sources de données au niveau de l’application

Ressources au niveau du serveur partagées

Finaliser la configuration

Sources de données JBoss EAP

robots933456 dans les journaux

Choix d’une version du runtime Java

JBoss EAP

Clustering dans JBoss EAP

Règles de mise à l’échelle automatique

Plans App Services pour JBoss EAP

Configuration de la base de référence Tomcat sur App Services

Connecteur

Hôte

Valve

Étapes suivantes

Ressources supplémentaires

Analyser les fichiers `.jfr`