Migrer des applications WebLogic Server vers JBoss EAP sur Azure App Service

  • Article

Ce guide décrit ce que vous devez savoir quand vous souhaitez migrer une application WebLogic Server 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.

Si vous ne pouvez pas répondre à l’une de ces conditions préalables à la migration, consultez le guide de migration complémentaire pour migrer vos applications vers Machines Virtuelles à la place : Migrer des applications WebLogic Server vers Azure Machines Virtuelles

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

Avant l’avènement des technologies de « configuration en tant que service » comme Azure Key Vault, le concept de « secrets » n’était pas bien défini. Vous aviez plutôt un ensemble disparate de paramètres de configuration qui fonctionnaient en réalité comme ce que nous appelons maintenant des « secrets ». Avec les serveurs d’applications comme WebLogic Server, ces secrets se trouvent dans de nombreux fichiers de configuration et magasins de configurations différents. Recherchez les secrets et mots de passe dans l’ensemble des propriétés et fichiers de configuration présents sur le ou les serveurs de production. Veillez à vérifier WebLogic.xml dans vos WAR. Vous pouvez également trouver des fichiers de configuration contenant des mots de passe ou des informations d’identification au sein de votre application. Pour plus d’informations, consultez Concepts de base d’Azure Key Vault.

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>

Inventorier les ressources JNDI

Inventoriez toutes les ressources JNDI. Par exemple, des sources de données comme les bases de données peuvent avoir un nom JNDI associé qui permet à JPA de lier correctement des instances de EntityManager à une base de données en particulier. Pour plus d’informations sur les ressources et les bases de données JNDI, consultez WebLogic Server Data Sources dans la documentation Oracle. D’autres ressources liées à JNDI, telles que les répartiteurs de messages JMS, peuvent nécessiter une migration ou une reconfiguration. Pour plus d’informations sur la configuration de JMS, consultez Oracle WebLogic Server 12.2.1.4.0.

Inspecter la configuration de votre domaine

L’unité de configuration principale dans WebLogic Server est le domaine. C’est pourquoi le fichier config.xml contient une multitude de configurations que vous devez prendre bien en considération pour la migration. Le fichier contient des références à des fichiers XML supplémentaires qui sont stockés dans des sous-répertoires. Oracle vous conseille d’utiliser normalement la console d’administration pour configurer les objets et services gérables de WebLogic Server et permettre à WebLogic Server de gérer le fichier config.xml. Pour plus d’informations, consultez Domain Configuration Files.

Au sein de votre application

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

Déterminer si la réplication de session est utilisée

Si votre application s’appuie sur la réplication de session, avec ou sans Oracle Coherence*Web, vous avez deux options :

  • Refactorisez votre application afin d’utiliser une base de données pour la gestion des sessions.
  • Refactorisez votre application pour externaliser la session dans Azure Redis Service. Pour plus d’informations, consultez Azure Cache pour Redis.

Pour toutes ces options, il est judicieux de maîtriser la façon dont WebLogic effectue la réplication de l’état de session HTTP. Pour plus d’informations, consultez HTTP Session State Replication dans la documentation Oracle.

Documenter les sources de données

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

  • Quel est le nom de la source de données ?
  • Quelle est la configuration du pool de connexions ?
  • Où trouver le fichier JAR du pilote JDBC ?

Pour plus d’informations sur les pilotes JDBC dans WebLogic, consultez Using JDBC Drivers with WebLogic Server.

Déterminer si WebLogic a été personnalisé

Déterminez quelles personnalisations parmi les suivantes ont été apportées et capturez ce qui a été fait.

  • Est-ce que les scripts de démarrage ont changé ? Ces scripts comprennent setDomainEnv, commEnv, startWebLogic et stopWebLogic.
  • Est-ce que des paramètres spécifiques ont été transmis à JVM ?
  • Est-ce que des fichiers JAR ont été ajoutés au classpath du serveur ?

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 vous utilisez vos propres bibliothèques Shared Java EE que vous avez créées

Si vous utilisez la fonctionnalité de bibliothèque Shared Java EE, vous avez deux options :

  • Refactorisez votre code d’application pour supprimer toutes les dépendances de vos bibliothèques et incorporez plutôt la fonctionnalité directement dans votre application.
  • Ajoutez les bibliothèques dans le classpath du serveur.

Déterminer si les bundles OSGi sont utilisés

Si vous avez utilisé des bundles OSGi ajoutés à WebLogic Server, vous devez ajouter les fichiers JAR équivalents directement à votre application web.

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 Oracle Service Bus est en cours d’utilisation

Si votre application utilise Oracle Service Bus (OSB), vous devez capturer la façon dont il est configuré. Pour plus d’informations, consultez About the Oracle Service Bus Installation.

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 weblogic-application.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.

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

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 WLST (WebLogic Scripting Tool) est utilisé

Si vous utilisez actuellement WLST pour effectuer le déploiement, vous devez évaluer ce qu’il fait. Si WLST modifie les paramètres (runtime) de votre application dans le cadre du déploiement, vous devez vous assurer que ces paramètres sont conformes à l’une des options suivantes :

  • Ils sont externalisés en tant que paramètres d’application.
  • Ils sont incorporés dans votre application.
  • Ils utilisent l’interface CLI JBoss pendant le déploiement.

Si WLST fait plus que ce qui est mentionné ci-dessus, vous aurez un travail supplémentaire à effectuer pendant la migration.

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

Si votre application utilise des API spécifiques à WebLogic, vous devez refactoriser votre application pour ne pas les utiliser. Par exemple, si vous avez utilisé une classe mentionnée dans la Référence de l’API Java pour Oracle WebLogic Server, vous avez utilisé une API propre à WebLogic dans votre application. 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 entity beans ou EJB 2.x style CMP, vous devez refactoriser votre application pour ne pas les utiliser.

Déterminer si la fonctionnalité Java EE Application Client est utilisée

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

Déterminer si un plan de déploiement a été utilisé

Si un plan de déploiement a été utilisé pour effectuer le déploiement, vous devez évaluer ce que fait le plan de déploiement. Si le plan de déploiement correspond à un déploiement simple, vous pourrez déployer votre application web sans aucune modification. Si le plan de déploiement est plus élaboré, vous devez déterminer si vous pouvez utiliser l’interface CLI JBoss pour configurer correctement votre application dans le cadre du déploiement. S’il n’est pas possible d’utiliser l’interface CLI JBoss, vous devez refactoriser votre application de manière à ne plus avoir besoin d’un plan de déploiement.

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.

Valider si et comment le système de fichiers est utilisé

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 WebLogic 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, un autre emplacement pour ce contenu statique sera nécessaire. Vous pouvez envisager de déplacer du contenu statique vers Stockage Blob Azure et d’ajouter Azure CDN pour les téléchargements rapides à l’échelle mondiale.

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 fourni un exemple d’implémentation pour votre utilisation.

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 par votre application, Stockage Azure peuvent être montés dans le système de fichiers App Service.

Déterminer si des connecteurs JCA sont utilisés

Si votre application utilise des connecteurs JCA, vous devez valider que le connecteur JCA peut être utilisé sur JBoss EAP. Si l’implémentation JCA est liée à WebLogic, vous devez refactoriser votre application pour ne pas utiliser le connecteur JCA. S’il peut être utilisé, vous devez ajouter les fichiers JAR au chemin de classe du serveur 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 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 JAAS est utilisé

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 le clustering WebLogic est utilisé

Vous avez très probablement déployé votre application sur plusieurs serveurs WebLogic pour bénéficier d’une haute disponibilité. Azure App Service est capable de mettre à l’échelle, mais si vous avez utilisé l’API de cluster WebLogic, vous devez refactoriser votre code pour éliminer l’utilisation de cette API.

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 le plan App Service.

Créer et déployer une ou plusieurs 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.

Migrer des paramètres externalisés

Si vous devez utiliser des paramètres externes, vous devez les définir en tant que paramètres d’application. Pour plus d’informations, consultez Configuration des paramètres de l’application.

Migrer des scripts de démarrage

Si l’application d’origine a utilisé un script de démarrage personnalisé, vous devez la migrer vers un script Bash. Pour plus d’informations, consultez Personnaliser la configuration du serveur d’applications.

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.

Migrer des connecteurs JCA et des modules JAAS

Migrez les connecteurs JCA et les modules JAAS en suivant les instructions de l’installation des modules et des dépendances.

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 fait cela, nous avons quelques recommandations pour vous qui peuvent rendre votre application plus native dans le cloud.

Recommandations