Migrer des applications JBoss EAP vers Azure Red Hat OpenShift

  • Article

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

Vérifiez 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 de machine virtuelle est le choix le plus simple, car elle ressemble le plus étroitement à un déploiement local. L’expérience d’administration et de déploiement pour les machines virtuelles est analogue à ce que vous avez en local. La sélection de machines virtuelles vous permet de différer la modernisation.

Red Hat OpenShift réunit des services testés et approuvés pour réduire les frictions liées au développement, à la modernisation, au déploiement, à l’exécution et à la gestion des applications. Azure Red Hat OpenShift est basé sur Kubernetes. Azure Red Hat OpenShift offre une expérience cohérente dans le cloud public, le cloud local, le cloud hybride ou l’architecture edge.

Si la réduction du changement est le facteur le plus important pour votre effort de migration, envisagez une migration basée sur une machine virtuelle. 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éterminer si l’offre Place de marché Azure prédéfinie est un bon point de départ

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

  • Red Hat et Microsoft ont créé cette offre pour permettre l’approvisionnement rapide de 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.
    • Générez une image d’application à l’aide du modèle eap-s2i-build. Pour plus d’informations sur l’image source à image (S2I), consultez Utilisation d’OpenJDK 11 source à image pour OpenShift.
    • Déployez l’application Java à l’aide de l’opérateur EAP. Pour plus d’informations, consultez la documentation de référence de l’opérateur EAP sur Red Hat.

Si vous n’utilisez pas l’offre Place de marché Azure prédéfinie, vous devez apprendre à utiliser l’opérateur EAP directement. La maîtrise de l’opérateur dépasse la portée 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 relatives à la décision d’utiliser l’offre Place de marché Azure prédéfinie ou l’utilisation directe de l’opérateur.

Déterminer si la version JBoss EAP est compatible

Votre version JBoss EAP existante doit être l’une des versions prises en charge par l’opérateur. Pour plus d’informations, consultez La compatibilité et la 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 avez besoin de ces informations, quel que soit le chemin de migration que vous choisissez. Les aspects suivants, et bien plus encore, bénéficient d’un inventaire détaillé de la capacité du serveur.

  • Pour guider la sélection de la taille des machines virtuelles dans votre pool de nœuds.
  • Pour comprendre la quantité de mémoire à utiliser par le conteneur.
  • Pour savoir combien de partages d’UC le conteneur a besoin.

Il est possible de redimensionner des pools de nœuds dans Azure Red Hat OpenShift. Pour plus d’informations, 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 à case activée 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 avez un inventaire solide des secrets, consultez la documentation de l’opérateur EAP concernant les secrets. Pour plus d’informations, 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 plus d’informations, consultez la 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 nécessitent une version Java spécifique, qui varie pour chaque chemin d’accès. Vous devez vérifier que votre application est en mesure de s’exécuter correctement à l’aide de 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 plus d’informations sur les ressources et les bases de données JNDI, consultez la documentation relative à la 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 plus d’informations 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 bien dans les machines virtuelles Azure, mais si vous utilisez un profil qui fournit des fonctionnalités de haute disponibilité, tenez compte de la configuration JGroups . Déterminez si votre système fonctionne en tant que domaine managé ou serveur autonome.
    • Si dans un domaine managé, les profils ha ou full-ha traitent avec JGroups.
    • Si, dans un serveur autonome, les fichiers de configuration autonome-ha.xml ou autonome-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 plus d’informations, consultez Utilisation de la haute disponibilité JBoss EAP 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 d’état de session HTTP. Pour plus d’informations, consultez À propos de la réplication de session HTTP 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 plus d’informations sur les pilotes JDBC dans JBoss EAP, consultez La 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 l’hôte, le eap_env, la version autonome et le domaine.
  • 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 plus d’informations, 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 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 souhaiterez 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 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.

Pour plus d’informations, consultez La 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ée .

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 en tant que fichier EAR, veillez à 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.

Prendre en compte les exigences d’équilibrage de charge

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

Migration

Les étapes décrites dans cette section supposent que votre analyse vous amène à décider d’utiliser l’offre Place de marché Azure prédéfinie.

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 a un exemple qui montre comment le faire manuellement si vous souhaitez déployer ultérieurement par vous-même. Pour plus d’informations, consultez le chapitre 2. Générez et exécutez 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 plus d’informations sur certaines améliorations potentielles après la migration, consultez les articles suivants :