Migrer des applications WebLogic Server vers des machines virtuelles Azure

  • Article

Ce guide décrit ce que vous devez savoir quand vous voulez migrer une application WebLogic existante pour l’exécuter sur des machines virtuelles Azure. Pour obtenir une vue d’ensemble des solutions WebLogic Server disponibles dans Place de marché Azure, consultez Quelles sont les solutions pour l’exécution d’Oracle WebLogic Server sur Azure Machines Virtuelles ?

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.

Définir ce que vous entendez par « migration terminée »

Ce guide et les offres de la Place de marché Azure correspondantes constituent un point de départ pour accélérer la migration de vos charges de travail WebLogic Server vers Azure. Il est important de définir l’étendue de vos efforts de migration. Par exemple, vous tenez-vous à un strict « lift-and-shift » entre votre infrastructure existante et les machines virtuelles Azure ? Si c’est le cas, vous pouvez être tenté d’apporter des améliorations au fur et à mesure de la migration.

Il est préférable de s’en tenir le plus possible à un « lift-and-shift » pur et dur, tout en tenant compte des changements nécessaires, comme détaillé dans ce guide. Définissez ce que vous entendez par « migration terminée » afin de savoir quand vous avez atteint cet objectif. Une fois que vous avez atteint votre « migration terminée », vous pouvez prendre une capture instantanée de vos machines virtuelles, comme décrit dans Créer une capture instantanée. Une fois que vous avez vérifié que vous pouvez effectuer une restauration à partir de votre instantané, vous pouvez effectuer les améliorations sans craindre de perdre la progression de la migration que vous avez obtenue jusqu’à présent.

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 WLS vers Azure consiste à sélectionner la cible de migration la plus appropriée. WLS s’exécute correctement sur des machines virtuelles Azure ou Azure Kubernetes Service (AKS). 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 très analogue à ce que vous avez en local. Le compromis pour cette facilité est le coût économique. En règle générale, le coût par minute d’une solution basée sur une machine virtuelle est plus élevé que celui d’AKS. Bien qu’une solution BASÉE sur AKS coûte moins cher d’être exécutée, vous devez limiter votre application aux exigences d’AKS. 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 WebLogic vers Azure Machines Virtuelles. Si vous pouvez tolérer la conversion de votre application pour qu’elle s’exécute dans Kubernetes afin de réduire les coûts d’exécution, envisagez une migration basée sur AKS. Dans ce cas, poursuivez avec migrer des applications WebLogic Server vers Azure Kubernetes Service.

Déterminer si les offres Place de marché Azure prédéfinies sont un bon point de départ

Oracle et Microsoft ont collaboré pour apporter un ensemble de modèles de solution Azure à Place de marché Azure pour fournir un point de départ solide pour la migration vers Azure. Pour obtenir la liste des offres et choisir celle qui correspond le plus à votre déploiement existant, consultez la documentation Oracle Fusion Middleware. Vous pouvez consulter la liste des offres dans l’article de présentation Qu’est-ce qu’Oracle WebLogic Server sur Azure ?

Si aucune des offres existantes n’est un bon point de départ, vous devez reproduire le déploiement à l’aide des ressources de machine virtuelle Azure. Vous trouverez les instructions pas à pas dans Installer Oracle WebLogic Server sur Azure Machines Virtuelles manuellement. Pour plus d’informations, consultez Qu’est-ce que l’IaaS ?

Déterminer si la version WebLogic est compatible

Votre version WebLogic existante doit être compatible avec la version des offres IaaS. Pour afficher les offres pour WebLogic version 12.2.1.3, interrogez Place de marché Azure pour Oracle WebLogic 12.2.1.3. Si votre version WebLogic existante n’est pas compatible avec cette version, vous devez reproduire le déploiement à l’aide de ressources Azure IaaS. Pour plus d’informations, consultez la documentation 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 demandes et l’utilisation des ressources. Ces informations doivent indiquer le choix de la taille de la machine virtuelle. Pour en savoir plus, consultez la rubrique Tailles de services cloud.

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>

Valider le bon fonctionnement de la version Java prise en charge

Tous les chemins de migration pour WebLogic vers Azure 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

Remarque

Lors de la migration vers WLS sur des machines virtuelles Azure, les conditions requises pour les versions Java spécifiques sont déterminées par le Java préinstallé sur les machines virtuelles. Lors de la migration vers WLS sur AKS, la version Java spécifique est déterminée par l’image conteneur choisie. Il existe un large éventail de choix, mais tous utilisent le JDK Oracle.

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 trois options :

  • Coherence*Web peut s’exécuter avec WebLogic Server sur les machines virtuelles Azure, mais vous devez configurer manuellement cette option après avoir provisionné l’offre. Si vous utilisez la solution Coherence autonome, vous pouvez aussi l’exécuter sur une machine virtuelle Azure, mais vous devez configurer manuellement cette option après avoir provisionné l’offre.
  • 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 la gestion sur REST est utilisée

Si le cycle de vie de votre application comprend l’utilisation de la gestion sur REST, vous devez capturer les ports qui sont utilisés pour accéder à l’API REST et déterminer comment ils sont authentifiés et exposés. Après la migration, vous devez vous assurer que ces mêmes ports et mécanismes d’authentification sont exposés afin de permettre au cycle de vie de votre application de fonctionner de la même manière qu’avant la migration. Pour plus d’informations, consultez Administering Oracle WebLogic Server with RESTful Management Services.

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.

Si vous utilisez Oracle Message Broker, vous pouvez migrer ce logiciel vers des machines virtuelles Azure et l’utiliser tel quel.

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.

Déterminer si WLST (WebLogic Scripting Tool) est utilisé

Si vous utilisez actuellement WLST pour effectuer votre déploiement, vous devez évaluer ce qu’il fait. Si WLST change les paramètres (runtime) de votre application dans le cadre du déploiement, vous devez vous assurer que ce comportement continue de fonctionner quand vous allez tester votre application après la migration.

Déterminer si le système de fichiers est utilisé et de quelle manière

Les systèmes de fichiers de machine virtuelle fonctionnent de la même façon que les systèmes de fichiers locaux au niveau de la persistance, du démarrage et de l’arrêt. Cela dit, il est important de connaître vos besoins en système de fichiers et de s’assurer que les machines virtuelles ont une taille de stockage et des performances adéquates.

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 du contenu statique vers le Stockage Blob Azure et d’ajouter Azure CDN pour accélérer globalement les téléchargements. 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. Vous pouvez également déployer directement le contenu statique sur une application dans le plan Azure Spring Apps Enterprise. Pour plus d’informations, consultez Déployer des fichiers statiques web.

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. Vous pouvez également déployer directement le contenu statique sur une application dans le plan Azure Spring Apps Enterprise. Pour plus d’informations, consultez Déployer des fichiers statiques web.

Déterminer la topologie réseau

L’ensemble actuel d’offres Place de marché Azure est un point de départ pour votre migration. Si l’offre ne couvre pas les aspects de votre architecture que vous devez migrer, vous devez capturer la topologie réseau de votre déploiement existant et la reproduire dans Azure, même après avoir placé l’offre de base avec l’un des modèles de solution.

Le sujet est très vaste, mais les références suivantes peuvent vous guider dans vos efforts de migration :

  • Cette référence énumère les principaux thèmes sur la migration de la topologie réseau vers Azure : Fast Track Deployment Guide.
  • Cette référence décrit des points importants liés au clustering, qui a un impact sur la topologie réseau : WebLogic Server Clustering.
  • Étant donné que les sources de données sont des serveurs distincts dans un système WebLogic, vous devez les prendre en compte dans le cadre de l’analyse de la topologie réseau. WebLogic Server Data Sources.
  • Les sources de messagerie sont également des serveurs distincts. WebLogic Server Messaging
  • L’équilibrage de charge est un critère essentiel. Cette référence couvre le côté WebLogic Server de l’équilibrage de charge : Load Balancing in a Cluster.

Compte pour l’utilisation des adaptateurs JCA et des adaptateurs de ressources

Si votre application existante utilise des adaptateurs JCA et/ou des adaptateurs de ressources pour se connecter à d’autres systèmes de l’entreprise, vérifiez que la configuration pour ces artefacts s’applique à WebLogic Server qui s’exécute sur les machines virtuelles Azure. Pour plus d’informations, consultez Creating and Configuring Resource Adapters.

Compte pour l’utilisation de fournisseurs de sécurité personnalisés et de JAAS

Si votre application utilise JAAS, vous devez vous assurer que la configuration des fournisseurs de sécurité est correctement migrée. Pour plus d’informations, consultez About Configuring WebLogic Security Providers dans la documentation Oracle.

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é. Vous pouvez migrer ces clusters directement de votre installation locale vers WebLogic exécuté sur des machines Virtuelles Azure. Pour plus d’informations, consultez Domain Configuration Files dans la documentation Oracle.

Prendre en compte les exigences d’équilibrage de charge

L’équilibrage de charge est un élément essentiel du processus de migration de votre cluster Oracle WebLogic Server vers Azure. La solution la plus simple consiste à utiliser la prise en charge intégrée pour Azure Application Gateway fournie dans l’offre de la Place de marché Azure pour le cluster Oracle WebLogic Server. Pour obtenir un didacticiel sur cette rubrique, consultez Tutoriel : Migrer un cluster WebLogic Server vers Azure avec Azure Application Gateway en tant qu’équilibreur de charge.

Pour un résumé des fonctionnalités Azure Application Gateway par rapport aux autres solutions d’équilibrage de charge Azure, consultez Présentation des options d’équilibrage de charge Azure.

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

Si votre application utilise la fonctionnalité Java EE Application Client, celle-ci devrait continuer à fonctionner de la même manière après la migration vers des machines virtuelles Azure. Pour plus d’informations, consultez Using Java EE Client Application Modules.

Migration

Sélectionner une offre WebLogic sur machines virtuelles Azure

Les offres suivantes sont disponibles pour WebLogic sur machines virtuelles Azure.

Pendant le déploiement d’une offre, vous êtes invité à choisir la taille de la machine virtuelle pour vos nœuds de serveur WebLogic. Il est important de prendre en compte tous les aspects de dimensionnement (mémoire, processeur, disque) dans le choix de la taille de machine virtuelle. Pour plus d’informations, consultez la documentation Azure sur la taille des machines virtuelles.

Un seul nœud WebLogic Server sans serveur d’administration

Cette offre crée une seule machine virtuelle et y installe WebLogic, mais ne configure pas de domaines, ce qui est utile pour les scénarios où vous disposez d’une configuration de domaine très personnalisée.

Un seul nœud WebLogic Server avec serveur d’administration

Cette offre approvisionne une seule machine virtuelle et y installe WebLogic Server. Elle crée un domaine et démarre le serveur d’administration.

Cluster à N-nœud WebLogic Server

Cette offre crée un cluster hautement disponible de machines virtuelles WebLogic Server.

Cluster dynamique à N-nœud WebLogic Server

Cette offre crée un cluster dynamique scalable et hautement disponible de machines virtuelles WebLogic Server.

Provisionner l’offre

Une fois que vous avez sélectionné l’offre avec laquelle commencer, suivez les instructions de la documentation sur les offres pour la provisionner. Veillez à choisir le nom de domaine qui correspond à votre nom de domaine existant. Vous pouvez même faire correspondre le mot de passe du domaine au mot de passe de votre domaine existant.

Migrer les domaines

Une fois que vous avez provisionné l’offre, vous pouvez examiner la configuration de domaine et suivre ce guide pour des détails sur la migration des domaines.

Connecter les bases de données

Après avoir effectué la migration des domaines, vous pouvez connecter les bases de données en suivant les instructions de la documentation de l’offre. Ces instructions vous aident à prendre en compte les secrets de base de données et les chaînes d’accès impliquées.

Tenir compte des magasins de clés

Vous devez tenir compte de la migration des magasins de clés SSL utilisés par votre application. Pour plus d’informations, consultez Configuring Keystores.

Connecter les sources JMS

Une fois que vous avez connecté les bases de données, vous pouvez configurer JMS. Pour plus d’informations, consultez Fusion Middleware Administration istering JMS Resources for Oracle WebLogic Server dans la documentation WebLogic.

Prendre en compte l’authentification et l’autorisation

La plupart des applications présente une forme d’authentification et d’autorisation. Si vous utilisez LDAP pour l’authentification, vous pouvez configurer Microsoft Entra Domain Services avec LDAP sécurisé et configurer des connexions LDAP dans WebLogic Server. Pour plus d’informations, consultez Créer et configurer un domaine managé Microsoft Entra Domain Services et configurer le protocole LDAP sécurisé pour un domaine managé Microsoft Entra Domain Services.

Tenir compte de la journalisation

Utilisez l’intégration à Elastic sur Azure fournie par les modèles de solution de la Place de marché Oracle WebLogic Server. Cette approche est le moyen le plus simple de prendre en compte la journalisation. Vous pouvez voir la liste des offres dans l’article de vue d’ensemble Quelles sont les solutions pour l’exécution d’Oracle WebLogic Server sur Azure Machines Virtuelles ? Des didacticiels complets pour configurer Elastic sont fournis dans :

Si l’intégration d’Elastic n’est pas adaptée, vous devez reporter la configuration de journalisation existante lorsque vous migrez le domaine. Pour plus d’informations, consultez Configure java.util.logging logger levels et Configuring Log Files and Filtering Log Messages for Oracle WebLogic Server dans la documentation Oracle.

Migration de vos applications

Les techniques utilisées pour déployer des applications de l’équipe de développement sur des serveurs de test, de préproduction et de production varient considérablement d’un cas à l’autre. Dans certains cas, une plateforme CI/CD très évoluée permet de déployer les applications sur WebLogic Server. Dans d’autres cas, le processus peut être plus manuel. L’un des avantages de l’utilisation d’Azure Machines Virtuelles pour migrer des applications WebLogic vers le cloud est que vos processus existants continuent de fonctionner.

Vous devez configurer le groupe de sécurité réseau que l’offre provisionne pour autoriser l’accès à partir de votre pipeline CI/CD ou du système de déploiement manuel. Pour plus d’informations, consultez Groupes de sécurité réseau.

Test

Tous les tests en conteneur sur les applications doivent être configurés pour accéder aux nouveaux serveurs qui s’exécutent dans Azure. Comme pour CI/CD, vous devez vous assurer que les règles de sécurité réseau nécessaires permettent à vos tests d’accéder aux applications déployées sur Azure. Pour plus d’informations, consultez Groupes de sécurité réseau.

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 obtenir des conseils sur certaines améliorations potentielles après la migration, consultez les recommandations suivantes :