Partager via

Migrer des applications WebSphere vers Azure Kubernetes Service (AKS)

  • Article

Ce guide décrit ce que vous devez savoir quand vous voulez migrer une charge de travail IBM WebSphere Application Server (WAS) existante vers IBM WebSphere Liberty ou Open Liberty 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 WAS vers Azure consiste à sélectionner la cible de migration la plus appropriée.

WAS s’exécute correctement sur des machines virtuelles Azure. 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 analogue à celle que vous avez sur place.

On peut également migrer vers des conteneurs en convertissant la charge de travail traditionnelle WAS en conteneurs d’applications. Vous pouvez exécuter la cible conteneur sur Azure Kubernetes Service (AKS) et Azure Red Hat OpenShift. 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 avec des conteneurs. Bien qu’une solution basée sur des conteneurs soit moins coûteuse, vous devez limiter votre application pour qu’elle s’adapte aux exigences de la plateforme d’orchestration des conteneurs.

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 WebSphere vers des machines virtuelles Azure.

Si vous pouvez vous accommoder de la conversion de votre application pour qu’elle s’exécute dans des conteneurs et ainsi réduire les coûts d’exécution, envisagez une migration basée sur AKS ou Azure Red Hat OpenShift.

Pour la migration basée sur AKS, vous pouvez commencer avec le niveau Gratuit. Bénéficiez d’une gestion gratuite des clusters et payez uniquement les machines virtuelles, le stockage associé et les ressources réseau utilisées. Dans ce cas, consultez la section Migrer des applications WebSphere vers Azure Kubernetes Service.

Pour la migration basée sur Azure Red Hat OpenShift, en plus des coûts de calcul et d’infrastructure, les nœuds d’application ont un autre coût pour le composant de licence OpenShift. Celui-ci est facturé en fonction du nombre de nœuds d’application et du type d’instance. Utilisez une tarification à la demande ou des instances réservées, selon l’option la plus adaptée aux besoins de votre charge de travail et de votre entreprise. Dans ce cas, consultez la section Migrer des applications WebSphere vers Azure Red Hat OpenShift.

Les guides pratiques de la documentation Azure Red Hat OpenShift abordent certains aspects pertinents pour la migration. Pour obtenir la liste complète des guides pratiques, consultez la documentation Azure Red Hat OpenShift.

Déterminez si l’offre préconstruite d’Azure Marketplace est un bon point de départ

Après avoir décidé qu’AKS est la cible de déploiement appropriée, vous devez accepter que l’opérateur IBM WebSphere Liberty ou Open Liberty Operator (l’opérateur) est le seul moyen d’exécuter Liberty 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 :

  • IBM et Microsoft ont créé cette offre pour vous permettre de provisionner rapidement Liberty sur AKS. Ce concept est expliquée de manière détaillée ci-dessous.
  • À un niveau élevé, l’offre automatise les étapes suivantes pour vous.
    • Prenez une image d’application existante, si vous le souhaitez.
    • Provisionnez un cluster AKS et une instance Azure Container Registry (ACR), le cas échéant.
    • Installez et configurez l’opérateur IBM WebSphere Liberty ou Open Liberty sur AKS.
    • Utilisez l’opérateur pour exécuter l’ensemble. L’opérateur déploie et gère des applications Liberty conteneurisées dans AKS. Vous pouvez consulter la documentation de référence dans l’opérateur IBM WebSphere Liberty et l’opérateur Open Liberty.

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 est disponible dans l’opérateur IBM WebSphere Liberty et l’opérateur Open Liberty.

Maintenant que vous avez pris connaissance des différentes façons de gérer Liberty 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 de Liberty est compatible

Vous avez besoin de l’opérateur Open Liberty ou de l’opérateur WebSphere Liberty pour déployer et gérer des applications sur des clusters Kubernetes. Vérifiez que votre version de Liberty est prise en charge par l’opérateur. Les versions d’Open Liberty sont conservées dans GitHub OpenLiberty/open-liberty. IBM conserve les versions d’IBM WebSphere Application Server Liberty. Pour en savoir plus, reportez-vous à WebSphere Application Server Liberty.

L’offre préconstruite d’Azure Marketplace vous permet de sélectionner vos images d’application à partir du registre public, et prend donc implicitement en charge toutes les versions.

Déterminer si une licence est nécessaire

Pour IBM WebSphere Liberty, vous devez accepter les termes du contrat de licence correspondant à la version du programme IBM dans le conteneur d’applications. Pour obtenir le contrat de licence applicable à ce programme IBM, consultez Afficher les informations de licence pour l’opérateur WebSphere Liberty. Pour en savoir plus, consultez Exécution de WebSphere Liberty sur Microsoft Azure.

Si l’édition de votre produit est différente de l’édition par défaut d’IBM WebSphere Application Server (base), la .spec.license.edition value doit spécifier l’édition de votre produit. D’autres valeurs disponibles sont IBM WebSphere Application Server Liberty Core et IBM WebSphere Application Server Network Deployment. L’offre préconstruite d’Azure Marketplace vous permet de sélectionner l’édition de produit prise en charge.

Inventorier les différences à l’aide des outils de migration IBM

Pour déplacer vos applications vers WebSphere Application Server Liberty ou Open Liberty, vous devez planifier votre migration, analyser vos applications et mettre à jour votre code source. IBM fournit des outils de migration qui permettent d’identifier les différences entre votre environnement actuel et les technologies de votre nouvel environnement Liberty, notamment Java EE 7 ou Java EE 8 et Java SE 8 ou Java SE 11. Pour en savoir plus, consultez Migration d’applications vers Liberty.

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 WAS, 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. Vous pouvez également trouver des fichiers de configuration contenant des mots de passe ou des informations d’identification au sein de votre application. WAS stocke les données de configuration dans plusieurs documents dans une hiérarchie en cascade de répertoires. La plupart des documents de configuration ont du contenu XML. Pour en savoir plus, consultez Documents de configuration et 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 les articles suivants :

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, configurez-les à l’aide des articles suivants :

Valider le bon fonctionnement de la version Java prise en charge

L’utilisation de Liberty nécessite une version spécifique de Java. Vous devez donc vérifier que votre application s’exécute correctement avec cette version prise en charge.

Le runtime de WebSphere Application Server Liberty a des exigences spécifiques pour le niveau minimal de Java Runtime Environment (JRE). Pour en savoir plus, consultez Dépendances de la version Java pour les fonctionnalités.

Open Liberty nécessite un runtime Java SE. Il peut s’exécuter à l’aide d’un environnement Java Runtime (JRE) ou d’une distribution JDK (Java SE Development Kit). Pour en savoir plus, consultez Versions de Java SE prises en charge.

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 en savoir plus sur les ressources et les bases de données JNDI, consultez WebSphere Data Sources dans la documentation IBM. D’autres ressources liées à JNDI, telles que les répartiteurs de messages JMS, peuvent nécessiter une migration ou une reconfiguration. Pour en savoir plus sur la configuration de JMS, consultez Utilisation des ressources JMS.

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. Pour WebSphere Liberty sur AKS, vous pouvez rendre un objet disponible dans l’espace de noms Java Naming and Directory Interface (JNDI) par défaut. Pour en savoir plus, consultez Développement avec l’espace de noms JNDI par défaut dans une fonctionnalité Liberty. Pour Open Liberty, consultez Java Naming and Directory Interface.

Inspecter la configuration de votre profil

L’unité de configuration principale dans WAS est le profil. C’est pourquoi le fichier resources.xml contient une multitude de configurations que vous devez prendre bien en considération pour la migration. Le fichier contient des références à d’autres fichiers XML qui sont stockés dans des sous-répertoires. Pour en savoir plus, consultez Gestion des profils sur les systèmes d’exploitation IBM i et distribués.

Au sein de votre application

Inspectez le fichier deployment.xml et/ou le fichier WEB-INF/web.xml.

Vous devez capturer ces personnalisations dans l’image de conteneur exécutée par AKS. Si vous utilisez l’offre préconstruite d’Azure Marketplace, de telles personnalisations sont mieux gérées en créant une image de conteneur personnalisée et en la rendant disponible dans un registre public, puis en pointant vers ce registre au moment du déploiement.

Si vous utilisez une cellule WebSphere Application Server Network Deployment, chaque membre de cluster s’exécute dans une installation de WAS traditionnel. Liberty est un profil léger de WebSphere Application Server. Il s’agit d’un profil flexible et dynamique de WAS, qui permet au serveur WAS de déployer uniquement les fonctionnalités personnalisées requises au lieu de déployer un grand ensemble de composants Java EE disponibles.

Déterminer si la réplication de session est utilisée

Si votre application s’appuie sur la réplication de session, vous disposez des options suivantes :

  • Pour les sessions HTTP, selon le niveau de gestion de session, vous pouvez utiliser le cache ou une base de données pour collecter des données de session.
  • Pour les sessions distribuées, vous pouvez enregistrer des sessions dans une base de données à l’aide de la persistance de session de base de données.
  • Pour le cache dynamique, vous pouvez gérer les données de session dans le cache ou la base de données.
  • Vous pouvez refactoriser votre application afin d’utiliser une base de données pour la gestion des sessions.
  • Vous pouvez refactoriser 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 Liberty effectue la réplication de l’état de session HTTP. Les documents suivants vous aident à comprendre comment gérer des sessions HTTP dans Liberty :

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. Lors du déploiement de l’offre, sélectionnez Activer l’affinité basée sur les cookies.

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 en savoir plus sur les pilotes JDBC dans WAS, consultez Utilisation de pilotes JDBC avec WebSphere Application Server.

La configuration JDBC est une configuration de serveur principale dans Liberty. Pour en savoir plus, consulter Pilote JDBC.

L’offre pré-construite d’Azure Marketplace offre une prise en charge limitée des bases de données. Vous pouvez gérer la configuration dans les images d’application et utiliser l’image lorsque vous déployez l’offre.

Déterminer si WAS a été personnalisé

Déterminez quelles personnalisations parmi les suivantes ont été apportées et capturez ce qui a été fait.

  • Est-ce que les scripts de démarrage ont changé ? Ces scripts incluent wsadmin, AdminControl, AdminConfig, AdminApp et AdminTask.
  • 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 ?
  • Des installations au niveau du système d’exploitation, telles que systemd ont-elles été utilisées pour que les composants WAS démarrent automatiquement après le redémarrage d’un serveur ?

Vous devez tenir compte des considérations relatives à la migration en fonction des réponses à ces questions.

Vous devez capturer ces personnalisations dans l’image de conteneur exécutée par AKS. Si vous utilisez l’offre préconstruite d’Azure Marketplace, de telles personnalisations sont mieux gérées en créant une image de conteneur personnalisée et en la rendant disponible dans un registre public, puis en pointant vers ce registre au moment du déploiement.

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 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 vous avez configuré des magasins persistants JMS, vous devez capturer leur configuration et les appliquer après la migration.

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

Microsoft offre une solution pour intégrer IBM MQ à Logic Apps. Pour plus d’informations, consultez Se connecter à un serveur IBM MQ à partir d’un flux de travail dans Azure Logic Apps.

Déterminer si vous utilisez vos propres bibliothèques Shared Java EE que vous avez créées

Si vous utilisez la fonctionnalité de bibliothèque Shared Java EE, vous avez deux options :

  • Refactorisez votre code d’application pour supprimer toutes les dépendances de vos bibliothèques et incorporez plutôt la fonctionnalité directement dans votre application.
  • Ajoutez les bibliothèques dans le classpath du serveur.

Vous pouvez gérer ces bibliothèques à l’aide des mêmes techniques que celles décrites dans Accéder aux API tierces à partir d’une application Java EE.

Déterminer si les bundles OSGi sont utilisés

Si vous avez utilisé des bundles OSGi ajoutés à WAS, vous devez ajouter les fichiers JAR équivalents directement à votre application web.

Vous pouvez inclure les offres groupées dans l’image fournie à l’offre préconstruite d’Azure Marketplace. Pour en savoir plus, consultez Configuration des bibliothèques pour les applications OSGi.

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.

Liberty sur AKS s’exécute sur Linux x86_64. Tout code spécifique au système d’exploitation doit être compatible avec 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 Liberty est compatible.

Déterminer si IBM Integration Bus est en cours d’utilisation

Si votre application utilise IBM Integration Bus, vous devez capturer la façon dont il est configuré. Pour en savoir plus, consultez la documentation d’IBM Integration Bus.

IBM Integration Bus n’est pas directement pris en charge dans l’offre préconstruite d’Azure Marketplace. Pour activer la fonctionnalité, suivez les instructions suivantes : Activation de l’application JMS sur Liberty pour se connecter à un bus d’intégration de service dans la documentation IBM.

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, ibm-application-bnd.xmi et ibm-application-ext.xmi et à capturer leur configuration. Pour en savoir plus, consultez Création du package d’archive d’entreprise (EAR) sur WebSphere.

L’offre préconstruite d’Azure Marketplace vous permet d’utiliser une image conteneur existante. Vous pouvez préparer l’application en fonction des besoins de votre entreprise.

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 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 n’est pas pris en charge dans l’offre préconstruite d’Azure Marketplace. Pour activer plusieurs options de stockage, suivez les instructions dans Options de stockage pour les applications dans Azure Kubernetes Service.

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 l’architecture que vous devez migrer, il faut capturer la topologie de réseau de votre déploiement existant. Ensuite, vous devez reproduire cette topologie dans Azure, même après avoir mis en place l’offre de base avec l’un des modèles de solution.

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

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

Si votre application existante utilise des adaptateurs JCA ou des adaptateurs de ressources pour vous connecter à d’autres systèmes d’entreprise, veillez à appliquer la configuration de ces artefacts au serveur Liberty s’exécutant sur Azure Kubernetes Service (AKS). Pour en savoir plus, consultez Vue d’ensemble des éléments de configuration JCA et Architecture du connecteur Java.

Déterminer si le clustering est utilisé

L’opérateur gère le clustering pour toutes les manières possibles d’exécuter la charge de travail WAS sur AKS.

Inspectez votre clustering EJB

Si votre application utilise des beans Java d’entreprise (EJB) locaux, vous devrez peut-être les migrer vers un EJB en cluster. Pour plus d’informations, consultez Développement d’applications EJB sur Liberty.

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.

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, consultez IBM WebSphere Liberty et Open Liberty sur Azure Kubernetes Service. Sélectionnez Créer, puis utilisez les informations que vous avez collectées lors des étapes précédentes pour remplir les champs de l’offre.

Tenir compte des magasins de clés

Vous devez tenir compte de la migration des magasins de clés SSL/TLS 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 de la section Vue d’ensemble des éléments de configuration JCA dans la documentation IBM.

Tenir compte de la journalisation

Vous ne pouvez pas faire du cloud sans maîtriser le journal. L’opérateur fournit différentes approches pour la surveillance. Pour en savoir plus, consultez Surveillance de l’environnement d’exécution de serveur Liberty. Si vous préférez utiliser Elastic Stack, Azure offre une excellente prise en charge d’Elastic. Pour de plus amples informations, consultez Qu’est-ce que l’intégration d’Elastic à Azure ? Vous pouvez combiner les connaissances de ces deux ressources pour obtenir une solution de journalisation optimisée par Azure pour Liberty sur AKS.

Migrez vos applications

Que vous choisissiez ou non de fournir une image d’application lors du déploiement, vous devez mettre à jour l’application via CI/CD. La documentation IBM contient un exemple qui montre comment effectuer cette mise à jour. Pour en savoir plus, consultez Déploiement d’applications dans Liberty.

Configurer des tests

Vous devez configurer tous les tests en conteneur sur les applications 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. Les articles suivants fournissent des informations sur les améliorations post-migration :