Migration d’applications WebSphere vers Azure Red Hat OpenShift

  • Article

Ce guide décrit ce que vous devez savoir quand vous souhaitez migrer une charge de travail WebSphere Application Server (WAS) existante vers IBM WebSphere Liberty ou Open Liberty qui s’exécute sur Azure Red Hat OpenShift.

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 WAS vers Azure consiste à sélectionner la cible de migration la plus appropriée.

WAS s’exécute correctement sur Azure Machines Virtuelles. 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 analogue à ce que vous avez en local.

Une autre option consiste à migrer vers des conteneurs en convertissant la charge de travail traditionnelle WAS en conteneurs d’applications. Vous pouvez exécuter la cible de conteneur sur Azure Kubernetes Service (AKS) et Azure Red Hat OpenShift. 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 les conteneurs. Bien qu’une solution basée sur un conteneur coûte moins cher d’être exécutée, vous devez contraindre votre application à s’adapter aux exigences de la plateforme d’orchestration de conteneurs.

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 WebSphere vers Azure Machines Virtuelles.

Si vous pouvez tolérer la conversion de votre application pour qu’elle s’exécute dans des conteneurs afin de 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 à utiliser le niveau Gratuit. Bénéficiez de la gestion gratuite des clusters et payez uniquement pour les machines virtuelles, le stockage associé et les ressources réseau consommées. Dans ce cas, consultez 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. Ce coût est facturé en fonction du nombre de nœuds d’application et du type d’instance. Utilisez la tarification à la demande ou les instances réservées, selon les besoins de votre charge de travail et de votre entreprise. Dans ce cas, consultez Migrer des applications WebSphere vers Azure Red Hat OpenShift.

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

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’Azure Red Hat OpenShift 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) soit la seule façon d’exécuter Liberty 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 :

  • IBM et Microsoft ont créé cette offre pour vous permettre de provisionner rapidement Liberty sur Azure Red Hat OpenShift. Ce concept est expliqué plus en détail dans le contenu suivant.
  • À un niveau élevé, l’offre automatise les étapes suivantes pour vous.
    • Prenez une image d’application existante, si vous le souhaitez.
    • Provisionnez un cluster Azure Red Hat OpenShift, si vous le souhaitez.
    • Installez et configurez l’opérateur IBM WebSphere Liberty ou Open Liberty sur Azure Red Hat OpenShift.
    • Utilisez l’opérateur pour exécuter l’ensemble de la chose. L’opérateur déploie et gère des applications Liberty conteneurisées dans Azure Red Hat OpenShift. Vous trouverez la documentation de référence sur l’opérateur IBM WebSphere Liberty et l’opérateur Open Liberty.

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

Maintenant que vous avez été introduit dans les différentes façons de gérer Liberty sur Azure Red Hat OpenShift, 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 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 existante est l’une des versions prises en charge par l’opérateur. Les versions d’Open Liberty sont conservées dans GitHub OpenLiberty/open-liberty. IBM gère les versions d’IBM WebSphere Application Server Liberty. Pour plus d’informations, consultez WebSphere Application Server Liberty.

L’offre Place de marché Azure prédéfinie 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 l’affichage des informations de licence pour l’opérateur WebSphere Liberty. Pour plus d’informations, consultez Exécution de WebSphere Liberty sur Microsoft Azure.

Si votre édition de produit est autre que le serveur d’applications IBM WebSphere par défaut (base), vous .spec.license.edition value devez spécifier votre édition de produit. D’autres valeurs disponibles sont IBM WebSphere Application Server Liberty Core et IBM WebSphere Application Server Network Deployment. L’offre Place de marché Azure prédéfinie vous permet de sélectionner l’édition de produit prise en charge.

Différences d’inventaire à 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 pour identifier les différences entre votre environnement actuel et les technologies de votre nouvel environnement Liberty, tels que Java EE 7 ou Java EE 8 et Java SE 8 ou Java SE 11. Pour plus d’informations, consultez Migration d’applications vers Liberty.

Inventorier la capacité des serveurs

Documentez le matériel (mémoire, processeur, disque) des serveurs de production actuels et le nombre moyen et maximal de demandes et l’utilisation des ressources. Vous avez besoin de ces informations, quel que soit le chemin de migration que vous choisissez. Ces informations sont utiles, par exemple, pour guider la sélection de la taille des machines virtuelles dans votre nœud, la quantité de mémoire à utiliser par le conteneur et le nombre de partages d’UC dont le conteneur aurait besoin.

Pour tirer parti de la capacité inutilisée à des coûts significatifs, il est possible d’utiliser Azure Spot Machines Virtuelles dans Azure Red Hat OpenShift. Pour savoir comment utiliser Azure Spot Machines Virtuelles dans un cluster Azure Red Hat OpenShift.

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 tels que WAS, ces secrets se trouvent dans de nombreux fichiers de configuration et magasins de configuration 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 plus d’informations, consultez les documents de configuration et les 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 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 avez 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 à l’aide de cette version prise en charge.

Le runtime de WebSphere Application Server Liberty a des exigences spécifiques pour le niveau minimal de l’environnement java runtime (JRE). Pour plus d’informations, consultez les dépendances de 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 plus d’informations, consultez les versions 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 plus d’informations sur les ressources et bases de données JNDI, consultez la documentation IBM sur les sources de données WebSphere. 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 Utilisation des ressources JMS.

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. 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 plus d’informations, consultez Développement avec l’espace de noms JNDI par défaut dans une fonctionnalité Liberty. Pour Open Liberty, consultez l’interface d’affectation de noms et d’annuaire Java.

Inspecter la configuration de votre profil

L’unité de configuration principale dans WAS est le profil. Par conséquent, le fichier resources.xml contient une grande quantité de configuration que vous devez prendre en compte avec soin pour la migration. Le fichier inclut des références à d’autres fichiers XML stockés dans des sous-répertoires. Pour plus d’informations, consultez Gestion des profils sur les systèmes d’exploitation IBM i 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 conteneur exécutée par Azure Red Hat OpenShift. Lorsque vous utilisez 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 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 JEE 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 des sessions, 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 une base de données.
  • Vous pouvez refactoriser votre application pour utiliser une base de données pour la gestion des sessions.
  • Vous pouvez refactoriser votre application pour externaliser la session vers le service Redis Azure. 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 d’état de session HTTP. Les documents suivants vous aident à comprendre comment gérer des sessions HTTP dans Liberty :

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 WAS, consultez Utilisation de pilotes JDBC avec WebSphere Application Server.

La configuration JDBC est une configuration de serveur principale dans Liberty. Pour plus d’informations, consultez PILOTE JDBC.

L’offre Place de marché Azure prédéfinie 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, Administration Control, Administration Config, Administration App et Administration Task.
  • 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 ?
  • Les installations au niveau du système d’exploitation comme systemd celles utilisées pour provoquer le démarrage automatique des composants WAS 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 conteneur exécutée par Azure Red Hat OpenShift. Lorsque vous utilisez 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 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 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. Une stratégie pour ceux qui utilisent JMS consiste à utiliser Azure Service Bus et le protocole Advanced Message Queuing. Pour plus d’informations, consultez Utiliser JMS avec Azure Service Bus et AMQP 1.0.

Si vous avez configuré des magasins persistants JMS, vous devez capturer leur configuration et l’appliquer après la migration.

Si vous utilisez IBM MQ, vous pouvez migrer ce logiciel vers Azure Machines Virtuelles et l’utiliser tel quel.

Microsoft a 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 l’accès 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 au 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 Place de marché Azure prédéfinie. Pour plus d’informations, 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 pouvez avoir besoin de remplacer toute utilisation de / ou \ dans les chemins de système de fichiers par File.Separator ou Paths.get.

Liberty sur Azure Red Hat OpenShift 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 décrites dans 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 configuration d’IBM Integration Bus. Pour plus d’informations, consultez la documentation IBM Integration Bus.

IBM Integration Bus n’est pas directement pris en charge dans l’offre Place de marché Azure prédéfinie. Pour activer la fonctionnalité, suivez les instructions de l’activation de l’application JMS sur Liberty pour vous connecter au 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 leurs configurations. Pour plus d’informations, consultez Création du package d’archive d’entreprise (EAR) sur WebSphere.

L’offre Place de marché Azure prédéfinie 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 des systèmes de fichiers avec des volumes persistants (PV). Le montage de volumes persistants n’est pas pris en charge dans l’offre Place de marché Azure prédéfinie. Pour créer un Stockage Class Azure Files, suivez les instructions de la page Créer une classe Azure Files Stockage Class sur Azure Red Hat OpenShift 4.

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. 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 une vaste rubrique, mais les références suivantes peuvent donner une direction à vos efforts de migration :

  • Pour obtenir une énumération des rubriques générales relatives à la migration de la topologie de réseau vers Azure, consultez les topologies de déploiement réseau webSphere Application Server.
  • Étant donné que les sources de données sont des serveurs distincts dans un système Liberty, vous devez les considérer comme faisant partie de l’analyse de la topologie du réseau. Pour plus d’informations, consultez Les sources de données WebSphere Application Server Liberty.
  • Les sources de messagerie sont également des serveurs distincts. Pour plus d’informations, consultez WebSphere Application Server Liberty : Messagerie WebSphere MQ.
  • L’équilibrage de charge est un critère essentiel. Pour plus d’informations sur le côté Liberty de l’équilibrage de charge, consultez l’architecture collective WebSphere Application Server Liberty.

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 se connecter à d’autres systèmes d’entreprise, veillez à appliquer la configuration de ces artefacts au serveur Liberty s’exécutant sur AKS. Pour plus d’informations, consultez Vue d’ensemble des éléments de configuration JCA et de l’architecture du Connecter or Java.

Déterminer si le clustering est utilisé

L’opérateur gère le clustering pour toutes les façons possibles d’exécuter une charge de travail WAS sur Azure Red Hat OpenShift.

Inspecter votre clustering EJB

Si votre application utilise des haricots Java d’entreprise locaux (EJB), 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

L’offre Place de marché Azure prédéfinie utilise un itinéraire intégré OpenShift pour héberger l’application à une URL publique et un compte pour l’équilibrage de charge. Pour plus d’informations, consultez la configuration de l’itinéraire OpenShift.

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 IBM WebSphere Liberty et Open Liberty sur Azure Red Hat OpenShift. Sélectionnez Créer, puis utilisez les informations que vous avez collectées dans les étapes précédentes pour vous aider à remplir les champs de l’offre.

Tenir compte des magasins de clés

Vous devez tenir compte de la migration de tous les 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 effectuer de cloud sans maîtriser la journalisation. L’opérateur fournit différentes approches pour la surveillance. Pour plus d’informations, consultez Surveillance de l’environnement d’exécution du serveur Liberty. Il est utile de maîtriser le système de journalisation et de surveillance dans Red Hat OpenShift. Pour plus d’informations, consultez Présentation du sous-système de journalisation pour Red Hat OpenShift et à propos de l’analyse openShift Container Platform. Vous pouvez configurer Azure Monitor Container Insights pour Azure Red Hat OpenShift. Pour plus d’informations, consultez Configurer Azure Monitor Container Insights pour Azure Red Hat OpenShift. Si vous préférez utiliser Elastic Stack, Azure offre une excellente prise en charge d’Elastic. Pour plus d’informations, consultez Présentation de l’intégration d’Elastic à Azure ? Vous pouvez combiner les connaissances de ces ressources pour obtenir une solution de journalisation optimisée pour Liberty sur Azure Red Hat OpenShift.

Migrez vos applications

Que vous choisissiez ou non de fournir une image d’application au moment du déploiement, vous devez mettre à jour l’application via CI/CD. La documentation OpenShift contient des exemples qui montrent comment effectuer cette mise à jour. Pour plus d’informations, consultez la vue d’ensemble ci/CD OpenShift Container Platform.

Configurer des tests

Vous devez configurer tous les tests en conteneur sur des applications pour accéder aux nouveaux serveurs s’exécutant dans Azure. Comme pour les problèmes 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 en savoir plus, reportez-vous aux 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 :