Migrer des applications WebLogic Server vers Azure Kubernetes Service

Ce guide décrit ce que vous devez savoir quand vous souhaitez migrer une application WebLogic Server (WLS) existante à exécuter sur Azure Kubernetes Service (AKS).

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 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 l’offre Place de marché Azure prédéfinie est un bon point de départ

Une fois que vous avez décidé qu’AKS est la cible de déploiement appropriée, vous devez accepter que l’opérateur Kubernetes Oracle WLS (l’opérateur) soit le seul moyen d’exécuter WLS sur Kubernetes. Après avoir accepté ce fait, vous devez décider si l’offre Place de marché Azure prédéfinie est un bon point de départ. Voici quelques éléments à prendre en compte sur l’offre Place de marché Azure prédéfinie.

• Oracle et Microsoft ont créé cette offre pour vous permettre de provisionner rapidement WLS sur AKS à l’aide du type de source d’accueil du domaine Image . Ce concept est expliqué plus en détail plus loin dans cet article.
• À un niveau élevé, l’offre automatise les étapes suivantes pour vous.
  • Prenez un déploiement WAR ou EAR existant, si vous le souhaitez.
  • Encapsulez-le dans un conteneur à l’aide de l’outil WebLogic Image Tool (WIT). Pour plus d’informations, consultez WebLogic Image Tool dans la documentation Oracle.
  • Installez et configurez l’opérateur Kubernetes WebLogic sur AKS.
  • Utilisez l’opérateur pour exécuter l’ensemble de la chose. L’opérateur appelle WebLogic Deploy Tooling (WDT) pour mettre en place des environnements WebLogic et effectuer des opérations de cycle de vie de domaine de manière reproductible basée sur un modèle de métadonnées. Pour plus d’informations, consultez WebLogic Deploy Tooling dans la documentation Oracle.
• Bien que l’offre prédéfinie fournit de nombreuses intégrations de service Azure, telles que App Gateway, la journalisation élastique, l’intégration de base de données, etc., il rend de nombreuses hypothèses simplifiées. Ces hypothèses rendent l’offre moins flexible que la maîtrise et l’utilisation de l’opérateur vous-même.

Si vous n’utilisez pas l’offre Place de marché Azure prédéfinie, vous devez apprendre à utiliser l’opérateur directement. La maîtrise de l’opérateur dépasse la portée de cet article. La documentation complète de l’opérateur Kubernetes WLS est disponible sur Oracle.

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.

Tout d’abord, vous devez comprendre le concept de « domaine » WLS. Un domaine est un groupe logique de ressources WLS. Pour obtenir la définition canonique du domaine WLS, consultez la documentation Oracle. L’exécution de WLS sur AKS nécessite de déterminer la façon dont AKS traite les domaines. Les différents choix sont appelés « type de source d’accueil de domaine ». L’opérateur Kubernetes WLS prend en charge trois choix de type source d’accueil de domaine. L’offre Place de marché Azure prédéfinie utilise la première dans ce tableau.

Type de source d’accueil du domaine	Description	Aspects positifs	Aspects négatifs
Modèle dans l’image	WLS et les applications se trouvent dans l’image conteneur, et tout le reste est conservé en dehors de cette image.	Prise en charge par l’offre prédéfinie. Documenté en tant qu’exemple officiel ; voir Oracle. La plupart utilise WDT. La plupart des options « cloud natives ». Intégration CI/CD la plus simple.	La plus grande courbe d’apprentissage.
Domaine en PV	Le domaine réside sur un volume persistant Kubernetes.	Conceptuellement similaire à l’exécution sur des machines virtuelles. Vous pouvez utiliser la console WLS pour apporter des modifications et conserver ces modifications sur les redémarrages de pod AKS. Documenté en tant qu’exemple officiel ; voir Oracle.	Certains défis liés à NFS doivent être atténués. Pour plus d’informations, consultez Oracle. Cette approche est la technique la moins « cloud native » ; l’état réside entièrement en dehors du cluster AKS.
Domaine dans l’image	Le domaine réside dans une image conteneur. Les applications sont contenues dans une image conteneur superposée sur l’image de domaine.	Plus « cloud natif » que le domaine en PV. Plus facile pour CI/CD.	Impossible d’utiliser la console WLS. Doit conserver davantage d’images conteneur.

Important

Si vous choisissez le domaine dans le type de source PV, nous vous recommandons vivement NFS au lieu de S Mo. NFS a évolué à partir du système d’exploitation UNIX et d’autres variantes telles que GNU/Linux. Pour cette raison, lors de l’utilisation de NFS avec des technologies de conteneur telles que Docker, il est moins susceptible d’avoir des problèmes pour les lectures simultanées et le verrouillage de fichiers.

Veillez à activer NFS v4.1. Les versions antérieures à la version 4.1 rencontreront des problèmes.

La documentation de l’opérateur inclut également un tableau utile comparant les différentes options. Pour plus d’informations, consultez Choisir un type de source d’accueil de domaine.

Pour obtenir une idée de l’offre Place de marché Azure prédéfinie, consultez Démarrage rapide : Déployer WebLogic Server sur Azure Kubernetes Service à l’aide de la Portail Azure. Pour obtenir la documentation de référence sur l’offre Place de marché Azure prédéfinie, consultez Oracle.

Pour obtenir une idée de l’utilisation directe de l’opérateur, essayez les exemples dans la documentation de l’opérateur.

Maintenant que vous avez été introduit dans les différentes façons de gérer les domaines WLS sur AKS, vous pouvez mieux choisir d’utiliser l’offre Place de marché Azure prédéfinie ou de le faire vous-même à l’aide de l’opérateur directement.

Déterminer si la version WebLogic est compatible

Votre version WLS existante doit être l’une des versions prises en charge par l’opérateur. Oracle gère ces versions dans Oracle Container Registry (OCR). Pour afficher la liste des versions prises en charge, procédez comme suit.

1. Visitez le site web Oracle Container Registry et connectez-vous. Pour plus d’informations, consultez https://container-registry.oracle.com/.
2. Si vous disposez d’un droit de support, sélectionnez Middleware, puis recherchez weblogic_cpu. Sélectionnez weblogic_cpu.
3. Si vous n’avez pas de droit de support auprès d’Oracle, sélectionnez Middleware, puis recherchez weblogic. Sélectionnez weblogic.

Remarque

Obtenez un droit d’utilisation support auprès d’Oracle avant de passer en production. Si vous ne le faites pas, vous risquez d’exploiter des images non sécurisées qui ne sont pas corrigées pour les failles de sécurité critiques. Pour plus d’informations sur les mises à jour des correctifs critiques d’Oracle, consultez les Mises à jour de correctifs critiques, alertes de sécurité et bulletins.

L’offre Place de marché Azure prédéfinie vous permet de sélectionner les images WLS à partir d’OCR et d’Azure Container Registry (ACR), et prend donc implicitement en charge toutes les versions disponibles à partir de l’OCR. Si vous dirigez l’offre pour extraire une image d’ACR, assurez-vous qu’elle est dérivée de l’une des versions prises en charge répertoriées dans OCR.

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, de guider la sélection de la taille des machines virtuelles dans votre pool de nœuds, la quantité de mémoire à utiliser par le conteneur et le nombre de partages d’UC dont le conteneur a besoin.

Il est possible de redimensionner les pools de nœuds dans AKS. Pour en savoir plus, consultez Redimensionner des pools de nœuds dans Azure Kubernetes Service (AKS).

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.

Une fois que vous avez un inventaire solide des secrets, consultez la documentation de l’opérateur concernant les secrets. Pour plus d’informations, consultez Secrets.

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 installer directement avec l’offre Place de marché Azure prédéfinie. Pour plus d’informations, consultez configuration TLS/SSL. Si vous utilisez l’opérateur directement, consultez Mise à jour des certificats externes de l’opérateur.

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.

Si vous utilisez l’offre Place de marché Azure prédéfinie, l’ensemble de ressources JNDI que vous pouvez personnaliser au moment du déploiement est limité à ce que l’offre prend en charge. Recherchez JNDI dans la documentation de l’offre. Si vous utilisez directement l’opérateur, les ressources JDNI peuvent être définies en fonction du type de source d’accueil de votre domaine choisi. Pour domaine en PV, vous pouvez les définir de la façon habituelle, avec WLST ou avec la console d’administration. Pour domaine dans image ou modèle, consultez remplacements classiques.

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.

L’offre Place de marché Azure prédéfinie crée automatiquement une ressource de domaine. Si vous utilisez directement l’opérateur, vous pouvez personnaliser complètement la façon dont votre domaine est représenté. Pour obtenir des informations complètes, consultez la ressource domaine.

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.

L’offre Place de marché Azure prédéfinie prend en charge l’affinité de session via le contrôleur d’entrée Application Gateway. Lors du déploiement de l’offre, sélectionnez Activer l’affinité basée sur les cookies. Recherchez l’affinité basée sur les cookies dans la documentation de l’offre.

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.

L’offre Place de marché Azure prédéfinie prend en charge les bases de données les plus populaires. Pour plus d’informations, consultez Base de données. Pour domaine en PV, vous pouvez les définir de la façon habituelle, avec WLST ou avec la console d’administration. Pour domaine dans image ou modèle, consultez remplacements classiques.

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 ?

Vous devez capturer ces personnalisations dans l’image conteneur exécutée par AKS. Pour l’offre Place de marché Azure prédéfinie, ces personnalisations sont mieux gérées en créant une image conteneur personnalisée et en la rendant disponible dans Azure Container Registry, puis en pointant vers ce registre au moment du déploiement. Pour plus d’informations, consultez Sélection d’images. Si vous utilisez l’opérateur directement, consultez les variables d’environnement de mémoire et d’option Java JVM.

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.

Le seul type de source d’accueil de domaine dans lequel il est judicieux de continuer à utiliser la gestion sur REST est Domaine en PV. Il est possible de l’utiliser avec les autres types de sources d’accueil de domaine, mais les modifications apportées sont éphémères et ne persistent pas dans les redémarrages de pod.

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.

Ces bibliothèques peuvent être gérées à l’aide des mêmes techniques que celles décrites dans Déterminer si WebLogic a été personnalisé.

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.

Vous pouvez les inclure dans war ou EAR fourni directement à l’offre Place de marché Azure prédéfinie ou à l’aide de l’opérateur.

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.

WLS sur AKS s’exécute sur Oracle Linux. Tout code spécifique au système d’exploitation doit être compatible avec Oracle Linux. Pour savoir comment découvrir des informations de système d’exploitation spécifiques, suivez les étapes décrites dans Déterminer si la version webLogic est compatible.

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.

OSB n’est pas directement pris en charge dans l’offre Place de marché Azure prédéfinie. Si vous devez utiliser OSB, vous devez utiliser l’opérateur directement.

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.

L’offre Place de marché Azure prédéfinie prend en charge les R WAR et EAR. L’utilisation directe de l’opérateur prend également en charge les WAR et les EAR.

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.

Le seul type de source d’accueil de domaine compatible avec l’utilisation de WLST est Domaine en PV. Pour plus d’informations, consultez La page d’accueil du domaine sur un pv.

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

Kubernetes traite des systèmes de fichiers avec des volumes persistants (PV). Le montage de volumes persistants est pris en charge dans l’offre Place de marché Azure prédéfinie et lors de l’utilisation directe de l’opérateur. Si vous utilisez un domaine en PV, le système de fichiers est un aspect central de la configuration.

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 déploiement s’appuie sur des adaptateurs de ressources, l’option la plus prise en charge est Domain home sur un PV.

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.

Si votre déploiement s’appuie sur des fournisseurs de sécurité, l’option la plus prise en charge est La maison de domaine sur un pv.

Déterminer si le clustering WebLogic est utilisé

L’opérateur gère le clustering pour toutes les façons possibles d’exécuter WLS sur AKS.

Inspecter votre clustering EJB

Si votre application utilise l’EJB local, vous devez les migrer vers l’EJB en cluster. Pour plus d’informations, consultez Clustered versus local EJB.

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 fournie par l’offre intégrée Place de marché Azure. Pour plus d’informations, consultez Tutoriel : Migrer un cluster WebLogic Server vers Azure avec Azure Application Gateway en tant qu’équilibreur de charge.

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

Si votre déploiement s’appuie sur des clients d’application Java EE, il est préférable d’utiliser l’opérateur directement. Pour plus d’informations, consultez Clients externes.

Déterminer si plusieurs images conteneur sont nécessaires

Un domaine WebLogic Server peut contenir plusieurs clusters. Par exemple, une application multiniveau peut être représentée dans un seul domaine, mais avoir deux clusters, par exemple « frontend » et « backend ». Il est utile de pouvoir mettre à jour le serveur frontal, sans mettre à jour le serveur principal, et vice versa. Toutefois, avec le modèle dans le type de source d’accueil du domaine Image , l’intégralité du domaine est représentée dans une image conteneur. Pour prendre en charge ce cas d’usage, vous devez séparer les clusters en leurs propres domaines, chacun avec leur propre image conteneur. L’opérateur peut gérer plusieurs domaines dans plusieurs espaces de noms. Pour plus d’informations, consultez Choisir une stratégie de sélection d’espace de noms de domaine

L’adoption de plusieurs domaines peut introduire des problèmes d’accès T3 entre les domaines. Pour résoudre ces problèmes, activez un canal personnalisé comme décrit dans Déterminer si l’activation de l’accès hôte inconnu est nécessaire.

Déterminer si l’activation de l’accès à l’hôte inconnu est nécessaire

Vous devrez peut-être activer l’accès hôte inconnu en appliquant un correctif à WebLogic pour les scénarios suivants :

• Autorisez l’accès T3 à partir de clients externes en dehors d’AKS à des clusters WLS dans AKS via un canal personnalisé.
• Autorisez l’accès T3 entre différents domaines WLS dans AKS via un canal personnalisé.

Pour plus d’informations sur le correctif, suivez les instructions de la section Guide pratique pour utiliser la recherche de correctifs dans Mon support Oracle (MOS) et recherchez le correctif 30656708.

Une fois le correctif appliqué, consultez Activation de l’accès à l’hôte inconnu.

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 https://aka.ms/wlsaks. Sélectionnez Créer, puis suivez les instructions de la documentation de l’offre. Utilisez les informations que vous avez collectées dans les étapes précédentes pour vous aider à remplir les champs de l’offre.

Migrer les domaines

Une fois que vous avez provisionné l’offre, affichez le domaine en suivant ces étapes.

Si vous vous éloignez de la page Déploiement en cours , les étapes suivantes vous montrent comment revenir à cette page. Si vous êtes toujours sur la page indiquant que votre déploiement est terminé, vous pouvez passer à l’étape 5.

1. Dans le coin supérieur gauche de n’importe quelle page du portail, sélectionnez le menu hamburger, puis Groupes de ressources.

2. Dans la zone avec le texte Filtrer pour n’importe quel champ, entrez les premiers caractères du groupe de ressources que vous avez créé précédemment. Si vous avez suivi la convention recommandée, entrez vos initiales, puis sélectionnez le groupe de ressources approprié.

3. Dans le volet de navigation gauche, dans la section Paramètres, sélectionnez Déploiements pour afficher une liste triée des déploiements sur ce groupe de ressources, avec la première version la plus récente.

4. Faites défiler la liste jusqu’à l’entrée la plus ancienne. Cette entrée correspond au déploiement que vous avez démarré dans la section précédente. Sélectionnez le déploiement le plus ancien, comme illustré dans la capture d’écran suivante.

   

5. Dans le panneau de gauche, sélectionnez Sorties. La liste affiche les valeurs de sortie du déploiement. Des informations utiles sont incluses dans les sorties. Nous sommes intéressés par les sorties qui nous permettent d’inspecter le domaine et d’interagir avec l’opérateur. Les autres valeurs des sorties sont expliquées en détail dans le guide de l’utilisateur WebLogic sur AKS.

6. Recherchez la sortie nommée shellCmdtoConnectAks. Collez la valeur de la sortie dans un interpréteur de commandes Bash et exécutez la commande. Cette commande vous permet d’utiliser kubectl comme décrit dans Connecter au cluster.

7. Recherchez la sortie nommée shellCmdtoOutputWlsDomainYaml. Collez la valeur de la sortie dans un interpréteur de commandes Bash et exécutez la commande. Cette commande génère la ressource de domaine en tant que fichier YAML.

8. Maintenant que vous disposez du yaML de domaine du déploiement actuel, vous pouvez appliquer les connaissances dans le déploiement des fichiers YAML des ressources de domaine et passer en revue ces conseils pour obtenir plus d’indices sur la migration des domaines. Cette aide nécessite une adaptation pour s’appliquer à la façon de faire des choses Kubernetes, mais il est toujours utile de connaître.

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 en suivant les instructions dans Fusion Middleware Administering JMS Resources for Oracle WebLogic Server dans la documentation WebLogic.

Tenir compte de la journalisation

Vous ne pouvez pas effectuer de cloud sans maîtriser la journalisation. L’opérateur fournit des exemples pour utiliser Elasticsearch et Kibana. Pour plus d’informations, consultez la documentation de l’opérateur. Azure offre une excellente prise en charge d’Elastic. Pour plus d’informations, consultez Qu’est-ce que l’intégration élastique à Azure ?. Vous pouvez combiner les connaissances de ces deux ressources pour obtenir une solution de journalisation optimisée pour Azure pour WLS sur AKS.

Migration de vos applications

Que vous choisissiez ou non de fournir un fichier WAR ou EAR au moment du déploiement, vous devez mettre à jour l’application via CI/CD. La documentation de l’opérateur contient un exemple qui montre comment effectuer cette mise à jour. Pour plus d’informations, consultez Update 3. Les autres exemples de mise à jour sont pertinents pour la migration et méritent d’être explorés.

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 :

• Mise à l’échelle. La mise à l’échelle dynamique est une proposition de valeur clé pour justifier la complexité de l’utilisation de Kubernetes. Combinez les connaissances du didacticiel : Mettre à l’échelle des applications dans Azure Kubernetes Service (AKS) avec la section mise à l’échelle de la documentation de l’opérateur pour obtenir une solution de mise à l’échelle optimisée Kubernetes native WLS. Il est parfaitement possible d’utiliser des solutions populaires hors-plateau telles que Prometheus et Grafana pour la mise à l’échelle avec WLS sur AKS. Pour plus d’informations, consultez Utilisation de Prometheus et de Grafana pour surveiller WebLogic Server sur Kubernetes. Azure dispose d’un service Grafana managé. Pour plus d’informations, consultez Qu’est-ce qu’Azure Managed Grafana ?.

• Si vous avez déployé WebLogic Server avec Azure Application Gateway en suivant les étapes de l’offre, vous pouvez effectuer davantage de configuration sur Application Gateway. Pour plus d’informations, consultez Présentation de la configuration d’Application Gateway.

• Améliorer votre topologie réseau avec des services d’équilibrage de charge avancés. Pour plus d’informations, consultez Utilisation des services d’équilibrage de charge dans Azure.

• Obtenez une surveillance des performances des applications optimisées pour Java avec Azure Monitor et application Recommandations. Pour plus d’informations, consultez La supervision des applications d’instrumentation Zéro pour Kubernetes - Application Azure Monitor Recommandations.

• Utilisez Stockage Azure pour servir du contenu statique monté sur AKS. Pour plus d'informations, consultez Options de stockage pour les applications dans Azure Kubernetes Service (AKS). Combinez cette connaissance avec la section de documentation de l’opérateur fournissant l’accès à une revendication de volume persistant.

• Déployer vos applications sur votre cluster WebLogic migré avec Azure DevOps. Pour plus d’informations, consultez la documentation Bien démarrer avec Azure DevOps.

• Utilisez les identités managées Azure pour gérer les secrets et attribuer un accès en fonction du rôle aux ressources Azure. Pour en savoir plus, consultez en quoi consistent les identités managées pour les ressources Azure ?

• Intégrez l’authentification et l’autorisation WebLogic Java EE à l’ID Microsoft Entra. Pour plus d’informations, consultez le guide de prise en main de Microsoft Entra.