Partager via

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 une vue d’ensemble des solutions WebLogic Server disponibles sur Azure Marketplace, voir Quelles sont les solutions pour exécuter Oracle WebLogic Server sur des machines virtuelles Azure ?

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. Après avoir vérifié que vous pouvez restaurer avec succès votre snapshot, vous pouvez procéder aux améliorations sans craindre de perdre les progrès réalisés jusqu’à présent en matière de migration.

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 WLS vers Azure consiste à sélectionner la cible de migration la plus appropriée. WLS fonctionne bien sur les machines virtuelles (VM) Azure ou sur Azure Kubernetes Service (AKS). 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 très analogue à celle que vous avez sur place. La contrepartie de cette facilité est le coût économique. D’une manière générale, le coût par minute d’une solution basée sur une machine virtuelle est plus élevé que celui d’une solution AKS. Bien qu’une solution basée sur l’AKS soit moins coûteuse, vous devez contraindre votre application à s’adapter aux exigences de l’AKS. 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 la section Migrer des applications WebLogic vers des machines virtuelles Azure. Si vous pouvez tolérer de convertir votre application pour qu’elle s’exécute au sein de Kubernetes afin de réduire les coûts d’exécution, envisagez une migration basée sur AKS. Dans ce cas, continuez avec Migrer les applications WebLogic Server vers Azure Kubernetes Service.

Déterminez si les offres prédéfinies Azure Marketplace sont un bon point de départ

Oracle et Microsoft se sont associés pour proposer un ensemble de modèles de solutions Azure sur Azure Marketplace afin de 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 ne constitue un bon point de départ, vous devez reproduire le déploiement à la main en utilisant les ressources de la machine virtuelle Azure. Vous trouverez les conseils étape par étape dans Installer manuellement Oracle WebLogic Server sur des machines virtuelles Azure. 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 voir les offres pour WebLogic version 12.2.1.4, interrogez Azure Marketplace pour Oracle WebLogic 12.2.1.4. Si votre version existante de WebLogic n'est pas compatible avec cette version, vous devez reproduire le déploiement à la main en utilisant les 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 exigences relatives aux versions spécifiques de Java sont déterminées par le Java préinstallé sur les machines virtuelles. Lors de la migration vers WLS sur AKS, la version spécifique de Java est déterminée par l’image de conteneur choisie. Il existe une grande variété de choix, mais tous utilisent le JDK d’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, 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 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 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.

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 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.

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 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.

Déterminer la topologie réseau

L’ensemble actuel d’offres Azure Marketplace 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 un tutoriel sur cette rubrique, voir Tutoriel : Migrer un cluster de serveurs WebLogic vers Azure avec Azure Application Gateway comme é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.

Lors du déploiement d’une offre, il vous est demandé de 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 à tenir compte des secrets de base de données et des chaînes d’accès impliqués.

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

Après avoir connecté les bases de données, vous pouvez configurer JMS. Pour plus d’informations, voir Fusion Middleware Administrer les ressources JMS pour 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 les connexions LDAP dans WebLogic Server. Pour plus d’informations, voir Créer et configurer un domaine géré par Microsoft Entra Domain Services et Configurer un LDAP sécurisé pour un domaine géré par Microsoft Entra Domain Services.

Tenir compte de la journalisation

Utilisez l’intégration avec 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 synthèse Quelles sont les solutions pour exécuter Oracle WebLogic Server sur des machines virtuelles Azure ? Des tutoriels 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 des machines virtuelles Azure pour migrer les 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 prévoit pour autoriser l’accès depuis votre pipeline CI/CD ou votre 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 possibles après la migration, consultez les recommandations suivantes :