Partager via

Migration d’applications WebSphere vers JBoss EAP sur Azure App Service

  • Article

Ce guide décrit les éléments à connaître lorsque vous souhaitez migrer une application WebSphere 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.

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

Vérifiez toutes les propriétés et tous les fichiers de configuration sur le ou les serveurs de production pour tout secret ou mot 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. Il peut s’agir, pour les applications Spring Boot, des 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, comme 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 les modules WebSphere partagés ou par votre code d’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 le contenu statique vers Azure Blob Storage et d'ajouter Azure CDN pour des téléchargements rapides à l'échelle mondiale. 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.

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.

Contenu dynamique ou interne

Pour les fichiers fréquemment écrits et lus par votre application (comme les fichiers de données temporaires) ou les fichiers statiques uniquement visibles pour votre application, vous pouvez monter le Stockage Azure dans le système de fichiers App Service. Pour en savoir plus, consultez Monter Azure Storage en tant que partage local dans App Service.

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 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 votre application utilise des API propres à WebSphere

Si votre application utilise des API spécifiques à WebSphere, vous devrez remanier votre application pour ne pas les utiliser. 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 style EJB 2.x, vous devez refactoriser votre application pour supprimer ces dépendances.

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é Java EE Application Client, vous devez refactoriser vos applications clientes et votre application (serveur) de manière à ce qu’elles utilisent 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 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 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.

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 à WebSphere, vous devez refactoriser votre application pour supprimer la dépendance au 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 au bon endroit dans les répertoires du 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 façon dont il 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 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 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 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 ce 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 en savoir plus, consultez la section Définir les options de runtime Java dans Déployer et configurer une application Tomcat, JBoss ou Java SE dans Azure App Service.

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 en savoir plus, consulter Utiliser des références Key Vault en tant que paramètres d’application pour App Service et Azure Functions.

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 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 des sources de données, suivez les étapes décrites dans Configurer des sources de données pour une application Tomcat, JBoss ou Java SE dans Azure App Service.

Migrez toutes les dépendances de chemin de classe au niveau du serveur supplémentaires. Pour en savoir plus, consulter Configurer des sources de données pour une application Tomcat, JBoss ou Java SE dans Azure App Service.

Migrez toutes les autres ressources JDNI au niveau du serveur partagées. Pour en savoir plus, consulter Configurer des sources de données pour une application Tomcat, JBoss ou Java SE dans Azure App Service.

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 terminé, nous vous fournissons des recommandations pour rendre votre application plus native dans le cloud.

Recommandations