Partager via

Migrer des applications WebLogic Server vers Azure Kubernetes Service (AKS)

  • Article

Ce guide décrit ce que vous devez savoir lorsque vous souhaitez migrer une application WebLogic Server (WLS) existante pour l'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.

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 l’offre préconstruite d’Azure Marketplace 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 Oracle WLS Kubernetes (l’opérateur) est le seul moyen d’exécuter WLS sur Kubernetes. Après avoir accepté ce fait, vous devez décider si l’offre préconstruite d’Azure Marketplace est un bon point de départ. Voici quelques éléments à prendre en compte concernant l’offre préconstruite d’Azure Marketplace.

  • Oracle et Microsoft ont créé cette offre pour vous permettre de provisionner rapidement WLS sur AKS en utilisant le type de source d’origine Model in Image domain. Ce concept est expliqué plus en détail dans la suite de 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.
    • Enveloppez-le dans un conteneur à l’aide de l’outil WebLogic Image Tool (WIT). Pour plus d’informations, voir WebLogic Image Tool dans la documentation Oracle.
    • Installez et configurez l’opérateur WebLogic Kubernetes sur AKS.
    • Utilisez l’opérateur pour exécuter l’ensemble. L’opérateur invoque 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 répétée sur la base d’un modèle de métadonnées. Pour plus d’informations, voir WebLogic Deploy Tooling dans la documentation Oracle.
  • Bien que l’offre préconstruite fournisse de nombreuses intégrations de services Azure, telles que App Gateway, Elastic logging, l’intégration de bases de données, et plus encore, elle émet de nombreuses hypothèses simplificatrices. Ces hypothèses font que l’offre n’est pas aussi flexible que la maîtrise et l’utilisation de l’opérateur par vous-même.

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

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

Décider d’utiliser l’offre préconstruite d’Azure Marketplace

Tout d’abord, vous devez comprendre le concept de « domaine » WLS. Un domaine est un groupe de ressources WLS liées logiquement entre elles. Pour la définition canonique du domaine WLS, voir la documentation Oracle. L’exécution de WLS sur AKS nécessite de décider de la manière dont AKS traite les domaines. Les différents choix sont appelés « type de source d’origine du domaine ». L’opérateur WLS Kubernetes prend en charge trois choix de type de source d’origine du domaine. L’offre préconstruite d’Azure Marketplace utilise le premier choix de ce tableau.

Type de source d’origine du domaine Description Aspects positifs Aspects négatifs
Modèle dans l’image WLS et les applications sont dans l’image du conteneur, et tout le reste est conservé en dehors de cette image. Pris en charge par une offre préconstruite. Documenté en tant qu’échantillon officiel ; voir Oracle. Utilise le plus le WDT. Option la plus « cloud-native ». Intégration CI/CD la plus simple. Plus grande courbe d’apprentissage.
Domaine dans 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 ces modifications persistent à travers les redémarrages de pods AKS. Documenté en tant qu’échantillon officiel ; voir Oracle. Certains problèmes liés à NFS doivent être résolus. Pour plus d’informations, voir Oracle. Cette approche est la technique la moins « cloud-native » ; l’état réside entièrement en dehors du cluster AKS.
Domain dans l’image Le domaine réside dans une image de conteneur. Les applications sont contenues dans une image de conteneur qui est superposée à l’image du domaine. Plus « cloud-native » que Domain dans le Domain dans PV. Plus facile pour CI/CD. Ne peut pas utiliser la console WLS. Nécessité de maintenir plus d’images de conteneurs.

Important

Si vous choisissez le type de source Domain dans PV, nous vous recommandons vivement d’utiliser NFS plutôt que SMB. NFS est issu du système d’exploitation UNIX et d’autres variantes telles que GNU/Linux. C’est pourquoi, lorsque vous utilisez NFS avec des technologies de conteneurs telles que Docker, il est moins probable que vous rencontriez des problèmes de lecture simultanée et de verrouillage de fichiers.

Veillez à activer la version 4.1 de NFS. Les versions inférieures à la v4.1 posent des problèmes.

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

Pour vous faire une idée de l’offre pré-construite d’Azure Marketplace, consultez Démarrage rapide : Déployez WebLogic Server sur Azure Kubernetes Service à l’aide du portail Azure. Pour la documentation de référence sur l’offre préconstruite d’Azure Marketplace, voir Oracle.

Pour vous familiariser avec l’utilisation directe de l’opérateur, essayez les exemples figurant dans la documentation de l’opérateur.

Maintenant que vous avez pris connaissance des différentes façons de gérer les domaines WLS sur AKS, vous êtes mieux à même de choisir entre utiliser l’offre préconstruite d’Azure Marketplace ou le faire vous-même en utilisant directement l’opérateur.

Déterminer si la version WebLogic est compatible

Votre version existante de WLS doit être l’une des versions supportées par l’opérateur. Oracle maintient ces versions dans le Oracle Container Registry (OCR). Suivez les étapes suivantes pour consulter la liste des versions prises en charge.

  1. Visitez le site web du Container Registry d’Oracle et connectez-vous. Pour plus d’informations, consultez https://container-registry.oracle.com/.
  2. Si vous disposez d’un droit d’assistance, sélectionnez Middleware, puis recherchez weblogic_cpu. Sélectionnez weblogic_cpu.
  3. Si vous ne disposez pas d’un droit d’assistance de la part 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, voir Mises à jour des correctifs critiques, alertes et bulletins de sécurité.

L’offre préconstruite d’Azure Marketplace 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 d’OCR. Si vous demandez à l’offre de tirer 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. Cela est utile, par exemple, pour 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 parts CPU nécessaires pour le conteneur.

Il est possible de redimensionner les pools de nœuds dans AKS. Pour savoir comment, consultez la section Redimensionner les 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 disposez d’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 avez un solide inventaire de certificats, vous pouvez les installer directement avec l’offre préconstruite d’Azure Marketplace. Pour plus d’informations, voir la configuration TLS/SSL. Si vous utilisez l’opérateur directement, voir 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 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.

Si vous utilisez l’offre préconstruite d’Azure Marketplace, l’ensemble des 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’origine du domaine que vous avez choisi. Pour Domain dans PV, vous pouvez les définir de la manière habituelle, avec WLST ou avec la console d’administration. Pour Domain dans l’image ou le modèle dans l’image, voir Remplacements typiques.

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 préconstruite d’Azure Marketplace crée automatiquement une ressource de domaine. Si vous utilisez directement l’opérateur, vous pouvez entièrement personnaliser la représentation de votre domaine. Pour plus d’informations, 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 Azure Marketplace préconstruite prend en charge l'affinité de session via le contrôleur d'entrée de la passerelle d'application. L'affinité basée sur les cookies est activée par défaut. Vous pouvez sélectionner Désactiver l'affinité basée sur les cookies pour la désactiver. Recherchez les affinités basées 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 préconstruite d’Azure Marketplace prend en charge la plupart des bases de données courantes. Pour plus d’informations, voir Base de données. Pour Domain dans PV, vous pouvez les définir de la manière habituelle, avec WLST ou avec la console d’administration. Pour Domain dans l’image ou le modèle dans l’image, voir Remplacements typiques.

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 de conteneur exécutée par AKS. Pour l’offre Azure Marketplace préconstruite, de telles personnalisations sont mieux gérées en créant une image de 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, voir Sélection d’images. Si vous utilisez l’opérateur directement, voir Mémoire JVM et variables d’environnement de l’option Java.

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 domestique de domaine pour lequel il est logique de continuer à utiliser la gestion via REST est le domaine dans 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 à travers les redémarrages de pods.

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.

Ces bibliothèques peuvent être gérées en utilisant les mêmes techniques que celles décrites dans la section 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 le WAR ou EAR fourni à l’offre préconstruite d’Azure Marketplace ou en utilisant l’opérateur directement.

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.

WLS on AKS fonctionne sous Oracle Linux. Tout code spécifique au système d’exploitation doit être compatible avec Oracle Linux. Pour savoir comment découvrir des informations spécifiques sur le système d’exploitation, suivez les étapes de la section Déterminer si la version de 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 préconstruite d’Azure Marketplace. 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 préconstruite d’Azure Marketplace prend en charge les WAR et les 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’origine de domaine compatible avec l’utilisation de WLST est le Domain en PV. Pour plus d’informations, voir Domicile sur un PV.

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

Kubernetes traite les systèmes de fichiers avec des volumes persistants (PV). Le montage de volumes persistants est pris en charge dans l’offre préconstruite d’Azure Marketplace et lors de l’utilisation directe de l’opérateur. Si vous utilisez Domain dans 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 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 déploiement s’appuie sur des adaptateurs de ressources, l’option la plus supportée est Domain home on a 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 soutenue est le Domain home on a PV.

Déterminer si le clustering WebLogic est utilisé

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

Inspectez votre clustering EJB

Si votre application utilise des EJB locaux, vous devez les migrer vers des EJB en cluster. Pour plus d’informations, voir EJB en cluster ou en local.

Prendre en compte les exigences d’équilibrage de charge

La meilleure façon de prendre en compte l’équilibrage de la charge est d’utiliser l’intégration App Gateway fournie par l’offre intégrée Azure Marketplace. Pour plus d’informations, voir Tutoriel : Migrer un cluster de serveurs WebLogic vers Azure avec Azure Application Gateway comme équilibreur de charge.

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

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

Déterminez si plusieurs images de conteneur sont nécessaires

Un domaine WebLogic Server peut contenir plusieurs clusters. Par exemple, une application à plusieurs niveaux peut être représentée dans un seul domaine, mais avoir deux clusters, disons « frontend » et « backend ». Il est utile de pouvoir mettre à jour le frontend sans mettre à jour le backend, et vice versa. Cependant, avec le type de source d’origine du domaine Model dans Image, l’ensemble du domaine est représenté dans une image conteneur. Pour répondre à ce cas d’utilisation, vous devez séparer les clusters dans leurs propres domaines, chacun avec sa propre image de conteneur. L’opérateur peut gérer plusieurs domaines dans plusieurs espaces de noms. Pour plus d’informations, voir Choisir une stratégie de sélection de l’espace de noms du 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 une chaîne personnalisée comme indiqué à la section Déterminer s’il est nécessaire d’activer l’accès aux hôtes inconnus.

Déterminez s’il est nécessaire d’activer l’accès aux hôtes inconnus

Vous devrez peut-être activer l’accès aux hôtes inconnus en appliquant un patch à WebLogic pour les scénarios suivants :

  • Autoriser l’accès T3 depuis des clients externes à AKS vers des clusters WLS dans AKS via une chaîne personnalisée.
  • Autoriser l’accès T3 entre différents domaines WLS dans AKS via une chaîne personnalisée.

Pour obtenir les détails du patch, suivez les instructions de la section Comment utiliser la recherche de patch dans My Oracle Support (MOS) et recherchez le patch 30656708.

Une fois le patch appliqué, reportez-vous à la section Activation de l’accès aux hôtes inconnus.

Migration

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

Provisionner l’offre

Pour ouvrir l’offre dans le portail Azure, voir https://aka.ms/wlsaks Sélectionnez Créer, puis suivez les instructions de la documentation relative à l’offre. Utilisez les informations que vous avez recueillies dans les étapes précédentes pour vous aider à remplir les champs de l’offre.

Migrer les domaines

Une fois l’offre provisionnée, produisez le domaine en suivant les étapes suivantes.

Si vous avez quitté la page Déploiement en cours, procédez comme suit pour y revenir. Si vous êtes toujours sur la page (qui indique 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 de gauche, dans la section Paramètres, sélectionnez Déploiements pour afficher une liste ordonnée des déploiements vers ce groupe de ressources, en commençant par le plus récent.

  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.

    Capture d’écran du portail Azure montrant la liste des déploiements du groupe de ressources.

  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 de WebLogic on AKS.

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

  7. Recherchez la sortie nommée shellCmdtoOutputWlsDomainYaml. Collez la valeur de la sortie dans un interpréteur de commande Bash et exécutez la commande. Cette commande produit la ressource du domaine sous la forme d’un fichier YAML.

  8. Maintenant que vous disposez du YAML du domaine du déploiement actuel, vous pouvez appliquer les connaissances acquises dans Déploiement des fichiers YAML de ressources de domaine et consulter ce guide pour obtenir plus d’indices sur la manière de migrer les domaines. Ces conseils doivent être adaptés pour s’appliquer à la façon de faire de Kubernetes, mais il est toujours utile de les 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 faire du cloud sans maîtriser le journal. L’opérateur fournit des exemples d’utilisation d’Elasticsearch et de Kibana. Pour plus d’informations, consultez la documentation de l’opérateur. Azure offre un excellent support pour Elastic. Pour plus d’informations, consultez la section Qu’est-ce que l’intégration élastique avec Azure ?. Vous pouvez combiner les connaissances de ces deux ressources pour obtenir une solution de journalisation optimisée par Azure pour WLS sur AKS.

Migration de vos applications

Que vous ayez choisi 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, voir la mise à jour 3. Les autres exemples de mise à jour concernent la migration et méritent d’être explorateurs.

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 :