Partager via

Migration d’applications WebLogic Server vers JBoss EAP sur Azure App Service

  • Article

Ce guide décrit les éléments à connaître lorsque vous souhaitez migrer une application WebLogic Server existante pour l'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 répondre à aucune de ces exigences de pré-migration, consultez le guide de migration complémentaire pour migrer vos applications vers des machines virtuelles à la place : Migrer des applications WebLogic Server vers des machines virtuelles Azure

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, pour guider la sélection du plan de service d’application.

La liste des niveaux de service d’application disponibles indique la mémoire, les cœurs de processeur, le stockage et les informations tarifaires. Notez que JBoss EAP on App Service n’est disponible que sur les niveaux Premium V3 et Isolated V2 App Service Plan.

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, voir 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 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 en savoir plus, consulter Utiliser Java Message Service 1.1 avec Azure Service Bus standard 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 devrez peut-être remplacer toute utilisation de / ou \ dans les chemins d'accès au système de fichiers par File.Separator ou Paths.get si votre application fonctionne sous Windows.

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 devrez évaluer ce qu'il fait. Si WLST modifie des paramètres (d'exécution) de votre application dans le cadre du déploiement, vous devrez 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 du travail supplémentaire à faire pendant la migration.

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

Si votre application utilise des API spécifiques à WebLogic, vous devrez remanier 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 boîte à outils de migration Red Hat pour les applications peut vous aider à supprimer et à remanier 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 type EJB 2.x, vous devrez remanier 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) en utilisant la fonctionnalité Java EE Application Client, vous devrez remanier à la fois vos applications clientes et votre application (serveur) pour utiliser les 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 devrez é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 timers EJB, vous devrez valider que le code du timer 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 timer EJB sera déclenché sur sa propre instance JBoss EAP.

Validez 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 les modules partagés de 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 le contenu statique vers Azure Blob Storage et d'ajouter Azure CDN pour des 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 de mise en œuvre pour votre usage.

Contenu dynamique ou interne

Pour les fichiers qui sont fréquemment écrits et lus par votre application (comme les fichiers de données temporaires), ou les fichiers statiques qui ne sont visibles que par votre application, Azure Storage peut être monté dans le système de fichiers d'App Service.

Déterminer si des connecteurs JCA sont utilisés

Si votre application utilise des connecteurs JCA, vous devrez valider que le connecteur JCA peut être utilisé sur JBoss EAP. Si l'implémentation JCA est liée à WebLogic, vous devrez remanier votre application pour ne PAS utiliser le connecteur JCA. S'il peut être utilisé, vous devrez ajouter les JAR au classpath du serveur et placer les fichiers de configuration nécessaires au bon endroit dans les répertoires du serveur JBoss EAP pour qu'il soit disponible.

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 l’AR fonctionne correctement, vous devez ajouter les JAR au chemin de classe du serveur de l’instance d’App Service et placer les fichiers de configuration nécessaires au bon endroit dans les répertoires du serveur JBoss EAP pour qu’ils soient disponibles.

Déterminer si JAAS est utilisé

Si votre application utilise JAAS, vous devrez déterminer comment JAAS est configuré. 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 se mettre à l'échelle, mais si vous avez utilisé l'API WebLogic Cluster, vous devrez remanier votre code pour éliminer l'utilisation de cette API.

Migration

Red Hat Migration Toolkit for Apps

Le Red Hat Migration Toolkit for Applications est une extension gratuite pour Visual Studio Code. Cette extension analyse le code et la configuration de votre application afin de fournir des recommandations pour la migration de vos applications Jakarta EE vers JBoss EAP à partir d’autres serveurs d’applications, comme la suppression des dépendances aux API propriétaires. L’extension fournira également des recommandations si vous migrez vers le cloud depuis des locaux. Pour plus d’informations, consultez la section Vue d’ensemble du Migration Toolkit for Applications.

Le contenu de ce guide vous aidera à aborder les autres composants du parcours de migration, tels que le choix du bon type de plan de service d’application, l’externalisation de l’état de votre 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 sont conformes ou supérieures à celles 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 devrez créer une application Web sur votre App Service Plan 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 de la rubrique Démarrage rapide : Créez 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 :

Après avoir créé l’application Web, utilisez l’un des mécanismes de déploiement disponibles pour déployer votre application. Pour plus d'informations, voir Déployer des fichiers vers 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 d'exécution Java de la section Configurer une application Java pour Azure App Service.

Migrer les paramètres externalisés

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

Migrer les scripts de démarrage

Si l'application d'origine utilisait un script de démarrage personnalisé, vous devrez le migrer vers un script Bash. Pour plus d'informations, voir Personnaliser la configuration du serveur d'application.

Renseigner les secrets

Utilisez des paramètres d’application pour stocker tous les secrets propres à votre application. Si vous avez l’intention d’utiliser le ou les mêmes secrets entre plusieurs applications, ou si vous avez besoin de stratégies d’accès à grain fin et de capacité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 la section Configurer une application Java pour Azure App Service.

Configurer le domaine personnalisé et le 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 devrez ensuite lier le certificat TLS/SSL pour ce domaine à votre App Service Web App. 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 les sources de données, suivez les étapes de la section Configurer les sources de données de Configurer une application Java pour Azure App Service.

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

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

Migrer les connecteurs JCA et les modules JAAS

Migrez les connecteurs JCA et les modules JAAS en suivant les instructions de la section Installer les modules et les dépendances.

Remarque

Si vous suivez l’architecture recommandée d’un WAR par application, envisagez de migrer les bibliothèques classpath au niveau du serveur et les ressources JNDI dans votre application. Cela simplifiera considérablement la gouvernance des composants et la gestion des changements. Si vous souhaitez déployer plus d’un WAR par application, vous devriez consulter l’un de nos guides complémentaires mentionnés au début de ce guide.

Migrer des tâches planifiées

Au minimum, vous devriez déplacer vos travaux planifiés vers une machine virtuelle Azure afin qu’ils ne fassent plus partie de votre application. Vous pouvez également opter pour leur modernisation en Java piloté par les événements à l’aide de services Azure tels que 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 cloud-native.

Recommandations