Migrer des applications WebSphere vers JBoss EAP sur Azure App Service

  • Article

Ce guide décrit ce que vous devez savoir quand vous souhaitez migrer une application WebSphere existante à exécuter sur Azure App Service à l’aide de JBoss EAP.

Prémigration

Pour garantir la réussite de la migration, avant de commencer, effectuez les étapes d’évaluation et d’inventaire décrites dans les sections suivantes.

Inventorier la capacité des serveurs

Documentez le matériel (mémoire, processeur, disque) du ou des serveurs de production actuels ainsi que le nombre moyen et maximal de requêtes et l’utilisation des ressources. Vous aurez besoin de ces informations, quel que soit le chemin de migration que vous choisissez. Il est utile, par exemple, de guider la sélection du plan App Service.

La liste des niveaux de plan App Service disponibles affiche les informations de mémoire, de cœurs de processeur, de stockage et de tarification. Notez que JBoss EAP sur App Service est disponible uniquement sur les niveaux de plan App Service Premium V3 et Isolé V2 .

Inventorier tous les secrets

Vérifiez toutes les propriétés et tous les fichiers de configuration sur le serveur de production ou les serveurs pour les secrets et mots de passe. Veillez à vérifier ibm-web-bnd.xml dans vos fichiers WAR. Vous pouvez également trouver des fichiers de configuration contenant des mots de passe ou des informations d’identification au sein de votre application. Ces fichiers peuvent inclure, pour les applications Spring Boot, les fichiers application.properties ou application.yml .

Inventorier tous les certificats

Documentez tous les certificats utilisés pour les points de terminaison SSL publics. Vous pouvez voir tous les certificats présents sur les serveurs de production en exécutant la commande suivante :

keytool -list -v -keystore <path to keystore>

Valider le bon fonctionnement de la version Java prise en charge

JBoss EAP sur Azure App Service prend en charge Java 8 et 11. Vous devez donc vérifier que votre application peut s’exécuter correctement avec cette version prise en charge. Cette validation s’avère particulièrement importante si votre serveur actuel utilise un JDK pris en charge (comme Oracle JDK ou IBM OpenJ9).

Pour obtenir votre version actuelle de Java, connectez-vous à votre serveur de production et exécutez la commande suivante :

java -version

Inventorier les ressources JNDI

Inventoriez toutes les ressources JNDI. Certaines ressources, telles que les répartiteurs de messages JMS, peuvent nécessiter une migration ou une reconfiguration.

Au sein de votre application

Inspectez le fichier WEB-INF/ibm-web-bnd.xml et/ou le fichier WEB-INF/web.xml .

Déterminer si les bases de données sont utilisées

Si votre application utilise des bases de données, vous devez capturer les informations suivantes :

  • Nom de la source de données.
  • Configuration du pool de connexions.
  • Emplacement du fichier JAR du pilote JDBC.

Déterminer si le système de fichiers est utilisé et de quelle manière

Toute utilisation du système de fichiers sur le serveur d’applications nécessite une reconfiguration ou, dans de rares cas, des modifications architecturales. Le système de fichiers peut être utilisé par des modules partagés WebSphere ou par le code de votre application. Vous pouvez identifier une partie ou l’ensemble des scénarios suivants.

Contenu statique en lecture seule

Si votre application sert actuellement du contenu statique, vous aurez besoin d’un autre emplacement pour lui. Vous pouvez envisager de déplacer du contenu statique vers le Stockage Blob Azure et d’ajouter Azure CDN pour accélérer globalement les téléchargements. Pour plus d’informations, consultez Hébergement de sites web statiques dans le service Stockage Azure et Démarrage rapide : Intégrer un compte de stockage Azure à Azure CDN. Vous pouvez également déployer directement le contenu statique sur une application dans le plan Azure Spring Apps Enterprise. Pour plus d’informations, consultez Déployer des fichiers statiques web.

Contenu statique publié dynamiquement

Si votre application autorise le contenu statique chargé/produit par votre application mais immuable après sa création, vous pouvez utiliser le Stockage Blob Azure et Azure CDN comme décrit ci-dessus, avec une fonction Azure pour gérer les chargements et l’actualisation du réseau CDN. Nous avons mis à votre disposition un exemple d’implémentation dans Chargement et préchargement CDN de contenu statique avec Azure Functions. Vous pouvez également déployer directement le contenu statique sur une application dans le plan Azure Spring Apps Enterprise. Pour plus d’informations, consultez Déployer des fichiers statiques web.

Contenu dynamique ou interne

Pour les fichiers fréquemment écrits et lus par votre application (tels que les fichiers de données temporaires) ou les fichiers statiques visibles uniquement pour votre application, vous pouvez monter Stockage Azure dans votre système de fichiers App Service. Pour plus d’informations, voir Distribuer du contenu issu du Stockage Azure dans App Service sur Linux.

Déterminer si votre application s’appuie sur des tâches planifiées

Les tâches planifiées, comme les tâches Quartz Scheduler ou les travaux cron Unix, NE doivent PAS être utilisées avec Azure App Service. Azure App Service ne vous empêche pas de déployer une application contenant des tâches planifiées en interne. Toutefois, si votre application a fait l’objet d’un scale-out, la même tâche planifiée peut s’exécuter plusieurs fois par période planifiée. Cette situation peut entraîner des conséquences inattendues.

Pour exécuter des tâches planifiées sur Azure, envisagez d’utiliser Azure Functions avec un déclencheur de minuteur. Pour en savoir plus, consultez Déclencheur de minuteur pour Azure Functions. Vous n’avez pas besoin de migrer le code de la tâche lui-même dans une fonction. La fonction peut simplement appeler une URL dans votre application pour déclencher la tâche.

Remarque

Pour empêcher toute utilisation malveillante, vous devrez probablement veiller à ce que le point de terminaison d’appel de tâche demande des informations d’identification. Ainsi, la fonction du déclencheur a besoin de fournir les informations d’identification.

Déterminer si une connexion à un service local est nécessaire

Si votre application doit accéder à vos services locaux, vous devez provisionner l’un des services de connectivité d’Azure. Pour plus d'informations, consultez Choisir une solution pour connecter un réseau local à Azure. Vous avez également besoin de refactoriser votre application pour qu’elle utilise les API publiques disponibles que vos ressources locales exposent.

Déterminer si les files d’attente ou les rubriques JMS (Java Message Service) sont en cours d’utilisation

Si votre application utilise des files d’attente ou des rubriques JMS, vous devez les migrer vers un serveur JMS hébergé en externe. Azure Service Bus et le protocole AMQP (Advanced Message Queuing Protocol) peuvent être une excellente stratégie de migration pour ceux qui utilisent JMS. Pour plus d’informations, consultez Utiliser JMS avec Azure Service Bus et AMQP 1.0.

Si des magasins persistants JMS ont été configurés, vous devez capturer leur configuration et les appliquer après la migration.

Déterminer si votre application utilise des API propres à WebSphere

Si votre application utilise des API spécifiques à WebSphere, vous devez refactoriser votre application pour ne pas les utiliser. La migration Red Hat Shared Computer Toolkit for Apps peut vous aider à supprimer et à refactoriser ces dépendances.

Déterminer si votre application utilise des Entity Beans ou des CMP Beans de style EJB 2.x

Si votre application utilise des Entity Beans ou des CMP Beans de style EJB 2.x, vous devez refactoriser votre application pour supprimer ces dépendances.

Déterminer si la fonctionnalité Client d’application JavaEE est utilisée

Si vous avez des applications clientes qui se connectent à votre application (serveur) à l’aide de la fonctionnalité Client d’application JavaEE, vous devez refactoriser à la fois vos applications clientes et votre application (serveur) pour utiliser des API HTTP.

Déterminer si votre application contient du code propre au système d’exploitation

Si votre application contient du code avec des dépendances vis-à-vis du système d’exploitation hôte, vous devez la refactoriser pour supprimer ces dépendances. Par exemple, vous pouvez avoir besoin de remplacer toute utilisation de / ou \ dans les chemins de système de fichiers par File.Separator ou Paths.get.

Déterminer si des minuteurs EJB sont en cours d’utilisation

Si votre application utilise des minuteurs EJB, vous devez vérifier que le code du minuteur EJB peut être déclenché par chaque instance JBoss EAP indépendamment. Cette validation est nécessaire, car lorsque votre App Service est mis à l’échelle horizontalement, chaque minuteur EJB est déclenché sur sa propre instance JBoss EAP.

Déterminer si des connecteurs JCA sont utilisés

Si votre application utilise des connecteurs JCA, vous devez vérifier que le connecteur JCA peut être utilisé sur JBoss EAP. Si l’implémentation JCA est liée à WebSphere, vous devez refactoriser votre application pour supprimer la dépendance du connecteur JCA. Si le connecteur JCA peut être utilisé, vous devez ajouter les fichiers JAR au chemin de classe du serveur. Vous devez également placer les fichiers de configuration nécessaires à l’emplacement approprié dans les répertoires de serveur JBoss EAP pour qu’ils soient disponibles.

Déterminer si JAAS est en cours d’utilisation

Si votre application utilise JAAS, vous devez capturer la configuration de JAAS. Si elle utilise une base de données, vous pouvez la convertir en domaine JAAS sur JBoss EAP. S’il s’agit d’une implémentation personnalisée, vous devez valider qu’elle peut être utilisée sur JBoss EAP.

Déterminer si votre application utilise un adaptateur de ressource

Si votre application nécessite un adaptateur de ressources (RA), il doit être compatible avec JBoss EAP. Déterminez si l’adaptateur RA fonctionne correctement sur une instance autonome de JBoss EAP en le déployant sur le serveur et en le configurant correctement. Si la ra fonctionne correctement, vous devez ajouter les fichiers JAR au chemin de classe du serveur de l’instance App Service et placer les fichiers de configuration nécessaires à l’emplacement approprié dans les répertoires de serveur JBoss EAP pour qu’ils soient disponibles.

Déterminer si votre application est composée de plusieurs WAR

Si votre application est composée de plusieurs WAR, vous devez traiter chacun de ces WAR comme des applications distinctes et suivre ce guide pour chacun d’entre eux.

Déterminer si votre application est empaquetée en tant que fichier EAR

Si votre application est empaquetée en tant que fichier EAR, veillez à examiner les fichiers application.xml et ibm-application-bnd.xml et à capturer leurs configurations.

Identifier tous les processus et démons extérieurs exécutés sur les serveurs de production

Si vous avez des processus qui s’exécutent en dehors du serveur d’applications, comme les démons de supervision, vous devez les éliminer ou les migrer ailleurs.

Migration

Red Hat Migration Shared Computer Toolkit for Apps

La Shared Computer Toolkit de migration Red Hat pour Applications est une extension gratuite pour Visual Studio Code. Cette extension analyse le code et la configuration de votre application pour fournir des recommandations pour la migration de vos applications Jakarta EE vers JBoss EAP à partir d’autres serveurs d’applications, telles que la suppression de dépendances sur les API propriétaires. L’extension fournit également des recommandations si vous migrez vers le cloud à partir d’un emplacement local. Pour plus d’informations, consultez Migration Shared Computer Toolkit pour la vue d’ensemble des applications.

Le contenu de ce guide vous aidera à traiter les autres composants du parcours de migration, tels que le choix du type de plan App Service approprié, la externalisation de votre état de session et l’utilisation d’Azure pour gérer vos instances EAP au lieu de l’interface de gestion JBoss.

Provisionner un plan App Service

Dans la liste des plans de service disponibles, sélectionnez le plan dont les spécifications répondent ou dépassent les spécifications du matériel de production actuel.

Remarque

Si vous envisagez d’exécuter des déploiements de préproduction/contrôle de validité ou d’utiliser des emplacements de déploiement, le plan App Service doit inclure cette capacité supplémentaire. Nous vous recommandons d’utiliser des plans Premium ou plus élevés pour les applications Java.

Créez ce plan App Service.

Créer et déployer des applications web

Vous devez créer une application web sur votre plan App Service pour chaque fichier WAR déployé sur votre serveur JBoss EAP.

Remarque

Même s’il est possible de déployer plusieurs fichiers WAR dans une seule application web, ce choix n’est vraiment pas souhaitable. Le déploiement de plusieurs fichiers WAR sur une seule application web empêche en effet chaque application de se mettre à l’échelle en fonction de ses propres besoins. Il complique également les pipelines de déploiement ultérieurs. Si plusieurs applications ont besoin d’être disponibles sur une seule URL, envisagez d’utiliser une solution de routage comme Azure Application Gateway.

Applications Maven

Si votre application est générée à partir d’un fichier POM Maven, utilisez le plug-in Webapp pour Maven pour créer l’application web et déployer votre application. Pour plus d’informations, consultez la section Configurer le plug-in Maven du guide de démarrage rapide : Créer une application Java sur Azure App Service.

Applications non-Maven

Si vous ne pouvez pas utiliser le plug-in Maven, vous devez provisionner l’application web par le biais d’autres mécanismes, comme :

Une fois que vous avez créé l’application web, utilisez l’un des mécanismes de déploiement disponibles pour déployer votre application. Pour plus d’informations, consultezDéployer des fichiers sur App Service.

Migrer des options de runtime JVM

Si votre application exige des options de runtime spécifiques, utilisez le mécanisme le plus approprié pour les spécifier. Pour plus d’informations, consultez la section Définir les options de runtime Java de Configurer une application Java pour Azure App Service.

Renseigner les secrets

Utilisez des paramètres d’application pour stocker tous les secrets propres à votre application. Si vous envisagez d’utiliser le même secret ou les mêmes secrets parmi plusieurs applications, ou si vous avez besoin de stratégies d’accès affinées et de fonctionnalités d’audit, utilisez plutôt des références Azure Key Vault. Pour plus d’informations, consultez la section Utiliser les références KeyVault de Configurer une application Java pour Azure App Service.

Configurer un domaine personnalisé et SSL

Si votre application web est visible sur un domaine personnalisé, elle devra être mappée à ce domaine. Pour plus d’informations, consultez Tutoriel : Mapper un nom DNS personnalisé existant à Azure App Service.

Vous devez ensuite lier le certificat TLS/SSL pour ce domaine à votre application web App Service. Pour plus d’informations, consultez Sécuriser un nom DNS personnalisé avec une liaison TLS/SSL dans Azure App Service.

Migrer des sources de données, des bibliothèques et des ressources JNDI

Pour migrer des sources de données, suivez les étapes décrites dans la section Configurer les sources de données de Configurer une application Java pour Azure App Service.

Migrez toutes les dépendances classpath au niveau du serveur supplémentaires en suivant les instructions de la section JBoss EAP de Configurer une application Java pour Azure App Service.

Migrez toutes les ressources JDNI au niveau du serveur partagé supplémentaires. Pour plus d’informations, consultez la section JBoss EAP de Configurer une application Java pour Azure App Service.

Remarque

Si vous suivez l’architecture recommandée d’une war par application, envisagez de migrer des bibliothèques classpath au niveau du serveur et des ressources JNDI dans votre application. Cela simplifie considérablement la gouvernance des composants et la gestion des changements. Si vous souhaitez déployer plusieurs war par application, vous devez passer en revue l’un de nos guides complémentaires mentionnés au début de ce guide.

Migrer des tâches planifiées

Au minimum, vous devez déplacer vos travaux planifiés vers une machine virtuelle Azure afin qu’ils ne fassent plus partie de votre application. Vous pouvez également choisir de les moderniser en Java piloté par les événements à l’aide de services Azure tels qu’Azure Functions, SQL Database et Event Hubs.

Redémarrage et test de détection de fumée

Enfin, vous avez besoin de redémarrer votre application web pour appliquer tous les changements de configuration. Une fois le redémarrage terminé, vérifiez que votre application s’exécute correctement.

Post-migration

Maintenant que vous avez migré votre application vers Azure App Service, vous devez vérifier qu’elle fonctionne comme prévu. Une fois que vous avez terminé, nous vous fournissons des recommandations pour rendre votre application plus native dans le cloud.

Recommandations