Migration d’applications JBoss EAP vers Azure Red Hat OpenShift

  • Article

Ce guide explique tout ce qu’il faut savoir pour migrer une application JBoss EAP existante dans le but de l’exécuter sur Azure Red Hat OpenShift.

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.

Assurez-vous que la cible est la cible appropriée pour votre effort de migration.

La première étape d’une migration réussie d’une application JBoss EAP vers Azure consiste à sélectionner la cible de migration la plus appropriée. JBoss EAP s’exécute correctement sur des machines virtuelles Azure ou Azure Red Hat OpenShift.

La cible machine virtuelle est le choix le plus facile, car elle ressemble le plus à un déploiement local. L’expérience d’administration et de déploiement des machines virtuelles est analogue à celle que vous avez sur place. La sélection de machines virtuelles vous permet de différer la modernisation.

La base Red Hat OpenShift regroupe des services testés et approuvés pour réduire la friction du développement, de la modernisation, du déploiement, de l’exécution et de la gestion d’applications. Azure Red Hat OpenShift est basé sur Kubernetes. Azure Red Hat OpenShift offre une expérience cohérente dans des architectures de cloud public, locales, hybrides ou en périphérie.

Si la minimisation des changements est le facteur le plus important pour votre effort de migration, envisagez une migration basée sur des machines virtuelles. Dans ce cas, consultez Migrer des applications JBoss EAP vers JBoss EAP sur des machines virtuelles Azure. Si vous pouvez tolérer la conversion de votre application pour qu’elle s’exécute dans Red Hat OpenShift afin de réduire les coûts d’exécution, envisagez une migration basée sur Azure Red Hat OpenShift. Dans ce cas, poursuivez avec Migrer des applications JBoss EAP vers JBoss EAP sur Azure Red Hat OpenShift. Pour comprendre les différences entre JBoss EAP et JBoss EAP pour OpenShift, consultez Comparaison : JBoss EAP et JBoss EAP pour OpenShift.

Déterminez si l’offre préconstruite d’Azure Marketplace est un bon point de départ

Tout d’abord, déterminez si Azure Red Hat OpenShift est la cible de déploiement appropriée. Ensuite, déterminez si l’offre Azure Marketplace prédéfinie est un bon point de départ. Tenez compte des points suivants concernant l’offre Azure Marketplace prédéfinie :

  • Red Hat et Microsoft ont créé cette offre pour permettre de provisionner rapidement JBoss EAP sur Azure Red Hat OpenShift.
  • À un niveau élevé, l’offre automatise les étapes suivantes pour vous.
    • Installez l’opérateur EAP sur Azure Red Hat OpenShift.
    • Créer une image d’application à l’aide du modèle eap-s2i-build. Pour en savoir plus sur la source-image (S2I), consultez Utilisation de la source-image OpenJDK 11 pour OpenShift.
    • Déployez l’application Java à l’aide de l’opérateur EAP. Pour en savoir plus, consultez la documentation de référence pour l’opérateur EAP sur Red Hat.

Si vous n’utilisez pas l’offre préconstruite d’Azure Marketplace, vous devez apprendre à utiliser l’opérateur EAP directement. La maîtrise de l’opérateur dépasse le cadre de cet article. La documentation complète de l’opérateur EAP est disponible sur Red Hat.

Le reste de cette section fournit quelques considérations pour décider d’utiliser l’offre préconstruite d’Azure Marketplace ou d’utiliser l’opérateur directement.

Déterminez si la version de JBoss EAP est compatible

Votre version existante de JBoss EAP doit être l’une des versions supportées par l’opérateur. Pour en savoir plus, consultez Compatibilité et prise en charge des versions dans la documentation Red Hat.

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. Les aspects suivants, et d’autres, bénéficient d’un inventaire détaillé de la capacité du serveur.

  • Pour vous aider à choisir la taille des machines virtuelles dans votre pool de nœuds.
  • Pour déterminer la quantité de mémoire qui doit être utilisée par le conteneur.
  • Pour connaître le nombre de partages de processeur dont le conteneur a besoin.

Il est possible de redimensionner des pools de nœuds dans Azure Red Hat OpenShift. Pour en savoir plus, consultez Redimensionnement d’un cluster--Microsoft Azure dans la documentation Red Hat.

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 JBoss EAP, 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 les fichiers de configuration tels que custom-config.xml ou jboss-web.xml dans vos applications. 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.

Une fois que vous disposez d’un inventaire solide des secrets, consultez la documentation de l’opérateur EAP concernant les secrets. Pour en savoir plus, consultez Création d’un secret dans la documentation Red Hat.

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>

Une fois que vous disposez d’un inventaire solide des certificats, vous pouvez les configurer dans Azure Red Hat OpenShift. Pour en savoir plus, consultez Configuration TLS dans OpenShift Container Platform(replace) dans la documentation Red Hat.

Valider le bon fonctionnement de la version Java prise en charge

Tous les chemins de migration pour JBoss EAP vers Azure Red Hat OpenShift demandent une version spécifique de Java, qui varie pour chaque chemin. Vous devez vérifier que votre application peut s’exécuter correctement avec cette version prise en charge.

Remarque

Cette validation s’avère particulièrement importante si votre serveur actuel s’exécute sur un JDK non 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. 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 en savoir plus sur les ressources et les bases de données JNDI, consultez Gestion des sources de données dans la documentation Red Hat. D’autres ressources liées à JNDI, telles que les répartiteurs de messages ActiveMQ Artemis, peuvent nécessiter une migration ou une reconfiguration. Pour en savoir plus sur la configuration d’ActiveMQ Artemis, consultez Configuration de la messagerie dans la documentation Red Hat.

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 Infinispan, vous avez trois options :

  • Infinispan fonctionne correctement dans les machines virtuelles Azure, mais si vous utilisez un profil qui fournit des fonctionnalités de haute disponibilité, tenez compte de la configuration de JGroups. Déterminez si votre système fonctionne en tant que domaine managé ou serveur autonome.
    • Dans le premier cas, les profils ha ou full-ha traitent avec JGroups.
    • Dans le cas d’un serveur autonome, les fichiers de configuration standalone-ha.xml ou standalone-full-ha.xml traitent avec JGroups.
    • Microsoft Azure ne prend pas en charge les protocoles de découverte JGroups basés sur la multidiffusion UDP. Pour en savoir plus, consultez Utilisation de JBoss EAP High Availability dans Microsoft Azure dans la documentation Red Hat.
  • 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 JBoss EAP effectue la réplication de l’état de session HTTP. Pour en savoir plus, consultez À propos de HTTP Session State Replication dans la documentation Red Hat.

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 en savoir plus sur les pilotes JDBC dans JBoss EAP, consultez Gestion des sources de données dans la documentation Red Hat.

Déterminer si JBoss EAP 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 incluent host, eap_env, standalone et domain.
  • 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 ?

Ces personnalisations doivent être capturées dans l’image conteneur s’exécutant sur Azure Red Hat OpenShift. Pour en savoir plus, consultez Configuration de l’image JBoss EAP pour OpenShift pour votre application Java dans la documentation Red Hat.

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 voudrez peut-être 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.

Pour en savoir plus, consultez Configuration de la messagerie dans la documentation Red Hat.

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.

Vous pouvez gérer ces bibliothèques à l’aide des mêmes techniques que celles décrites dans la section Déterminer si JBoss EAP a été personnalisé.

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.

Azure Red Hat OpenShift s’exécute sur OpenShift 4 en utilisant Red Hat Enterprise Linux CoreOS (RHCOS) comme système d’exploitation pour tous les nœuds de plan de contrôle et worker. Tout code spécifique au système d’exploitation doit être compatible avec RHCOS.

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 sous forme de fichier EAR, veillez à capturer les 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.

Prendre en compte les exigences d’équilibrage de charge

La meilleure façon de prendre en compte l’équilibrage de la charge est d’utiliser l’intégration App Gateway. Pour plus d’informations, consultez Présentation d’Azure Application Gateway.

Migration

Les étapes de cette section supposent que votre analyse vous a amené à décider d’utiliser l’offre préconstruite d’Azure Marketplace.

Provisionner l’offre

Pour ouvrir l’offre dans le portail Azure, consultez JBoss EAP sur Azure Red Hat OpenShift. Sélectionnez Créer, puis suivez les instructions de l’offre.

Migration de vos applications

L’offre prend en charge le processus source-image (S2I) pour générer et exécuter une application Java sur l’image JBoss EAP pour OpenShift. Red Hat dispose d’un exemple qui montre comment le faire manuellement si vous souhaitez effectuer un déploiement par vous-même ultérieurement. Pour en savoir plus, consultez Chapitre 2. Générer et exécuter une application Java sur l’image JBoss EAP pour OpenShift dans la documentation Red Hat.

Postmigration

Une fois que vous avez atteint les objectifs de migration que vous aviez définis dans l’étape de prémigration, effectuez des tests d’acceptation de bout en bout pour vérifier que tout fonctionne comme prévu. Pour des informations sur certaines améliorations potentielles après migration, consultez les articles suivants :