Ce document est destiné aux propriétaires d'applications et aux architectes cloud qui souhaitent migrer des applications Java exécutées sur IBM WebSphere Application Server (WAS) vers des conteneurs exécutés dans Google Kubernetes Engine (GKE) ou GKE Enterprise. Il vous guide dans le processus de migration des applications traditionnelles WAS vers des conteneurs à partir d'un environnement source sur site, dans un environnement d'hébergement privé ou dans l'environnement d'un autre fournisseur cloud. Il souligne également les avantages de l'utilisation de Migrer vers des conteneurs pour automatiser votre migration.
Vous devez disposer de connaissances antérieures de WebSphere avant d'essayer de migrer des VM WebSphere vers des conteneurs avec Migrate to Containers
Ce document contient également des points importants à prendre en compte lors de la planification d'une migration d'applications WAS vers des conteneurs. Il fait partie d'une série d'articles sur la migration vers Google Cloud. Si vous êtes intéressé par une présentation de la série, consultez la section Migration vers Google Cloud : choisir votre chemin de migration.
Lisez ce document si vous prévoyez de migrer des applications traditionnelles WAS exécutant un WAS compatible sur un système d'exploitation compatible, comme Linux, d'un environnement source compatible vers un environnement GKE ou GKE Enterprise avec Migrate to Containers. Ces environnements sources peuvent inclure les éléments suivants :
- Un environnement Compute Engine
- Un environnement VMware vSphere
- Un environnement de VM Microsoft Azure
- Un environnement Amazon Elastic Compute Cloud (Amazon EC2)
Migrate to Containers automatise l'utilisation du kit de migration IBM pour les binaires d'application afin de détecter, d'inspecter et de migrer toutes vos applications traditionnelles WAS dans vos machines virtuelles traditionnelles WAS. Il divise ensuite ces applications traditionnelles WAS en conteneurs traditionnels WebSphere individuels.
La migration des applications WAS traditionnelles à l'aide de Migrate to Containers nécessite un faible encombrement (minimum 1 Go de RAM et 2 Go d'image) et des coûts de licence réduits (jusqu'à 70% de remise sur un abonnement au déploiement réseau WAS).
En migrant des applications traditionnelles WAS avec Migrate to Containers, vous bénéficiez de plusieurs aspects d'un environnement conteneurisé. Il est possible de profiter des coûts de licence réduits décrits précédemment. Il est également possible de moderniser davantage les frameworks cloud intégrés en créant des conteneurs WAS Liberty ou Open Liberty pour vos applications.
WAS Liberty est un environnement d'exécution de production léger pour un développement et un déploiement rapides d'applications Web et cloud. Il est basé sur le projet Open Source Open Liberty. Les entreprises utilisent à la fois WAS Liberty et Open Liberty pour créer des microservices Java basés sur le cloud.
La migration vers Anthos ou GKE transfère la fonctionnalité de gestionnaire de déploiement réseau WAS vers les produits suivants :
Le schéma suivant montre comment GKE ou GKE Enterprise gère des fonctionnalités centralisées (haute disponibilité, placement des charges de travail et configuration centralisée, par exemple) qui étaient précédemment gérées par le déploiement réseau WAS. La configuration spécifique à l'application est gérée au moment de la création de l'image Docker. L'utilisation d'une configuration basée sur des images Docker assure la reproductibilité et l'automatisation via des processus CI/CD.
La migration des applications traditionnelles WAS vers des conteneurs avec Migrate to Containers est l'une des étapes possibles de votre processus de modernisation de la charge de travail. La migration vous aide à transformer les applications afin qu'elles s'exécutent dans un environnement cloud et à éviter les réécritures coûteuses nécessaires pour moderniser les applications traditionnelles WAS.
Les applications de migration idéales sont des applications exécutées sur un déploiement réseau WebSphere, WebSphere Base ou des versions Java compatibles pour lesquelles la modernisation via une réécriture complète est trop coûteuse (en termes de ressources) ou impossible. Pour en savoir plus sur les candidats à la migration idéaux, consultez la page Migrer des VM vers des conteneurs avec Migrate to Containers.
Concevoir la migration vers Google Cloud
Pour migrer vos applications traditionnelles WAS de votre environnement source vers des conteneurs s'exécutant dans Google Cloud, suivez le framework décrit dans la série Migration vers Google Cloud.
Le diagramme suivant illustre le parcours de votre migration.
Le framework illustré dans le schéma précédent se compose de quatre phases :
- Évaluation : au cours de cette phase, vous évaluez votre environnement source, vous déterminez les applications que vous souhaitez migrer vers Google Cloud et vous identifiez les applications WAS traditionnelles adaptées à la migration.
- Plan : au cours de cette phase, vous créez l'infrastructure de base pour Migrate to Containers, telle que la gestion de la hiérarchie des ressources et la configuration de l'accès au réseau.
- Déploiement : au cours de cette phase, vous migrez les applications traditionnelles de WAS de l'environnement source vers GKE ou GKE Enterprise avec Migrate to Containers.
- Optimisation : Au cours de cette phase, vous commencez à exploiter les technologies et des fonctionnalités cloud.
Évaluer l'environnement source et les applications
Au cours de la phase d'évaluation, vous rassemblez des informations sur votre environnement source et sur les applications que vous souhaitez migrer. Vous pouvez ainsi redimensionner les ressources dont vous avez besoin pour la migration et pour votre environnement cible.
Lors de la phase d'évaluation, vous effectuez les tâches suivantes :
- Dresser un inventaire complet de vos applications.
- Cataloguer vos applications en fonction de leurs propriétés et de leurs dépendances
- Former et préparer vos équipes sur Google Cloud
- Élaborer un test et une démonstration de faisabilité sur Google Cloud.
- Calculer le coût total de possession (TCO) de l'environnement cible
- Choisir les applications que vous souhaitez migrer en premier.
Les sections suivantes s'appuient sur la page Migration vers Google Cloud : évaluer et découvrir vos charges de travail. Cependant, elles fournissent des informations spécifiques à l'évaluation des applications WAS traditionnelles que vous souhaitez migrer vers des conteneurs avec Migrate to Containers.
Créer vos inventaires
Pour couvrir votre migration, vous devez comprendre votre environnement traditionnel WAS. Pour comprendre votre environnement, rassemblez des informations sur vos applications et leurs dépendances.
La section Créer un inventaire de vos applications décrit comment créer un inventaire de vos charges de travail dans votre environnement traditionnel WAS et de leurs dépendances. Suivez ces conseils et créez vos inventaires. Lorsque vous avez terminé, lisez ce document.
Maintenant que vous avez créé l'inventaire de vos charges de travail et de leurs dépendances, vous pouvez affiner l'inventaire. Évaluez les aspects et les fonctionnalités qui sont intéressants pour votre organisation lors de la migration de ses applications traditionnelles WAS avec Migrate to Containers.
Avant d'évaluer votre environnement WAS pour la migration, effectuez les tâches d'évaluation décrites dans les pages Migrer des VM vers des conteneurs avec Migrate to Containers et Migration vers Google Cloud : évaluer et découvrir vos charges de travail. Lorsque vous avez terminé, procédez à l'inventaire de vos charges de travail.
Pour terminer l'inventaire de vos charges de travail, tenez compte des points suivants :
- Systèmes d'exploitation exécutés sur vos VM WAS : collectez des informations sur les systèmes d'exploitation et leurs licences exécutées sur vos VM WAS, et assurez-vous que le système d'exploitation est un système d'exploitation Linux 64 bits répertorié dans la section Systèmes d'exploitation compatibles et versions de Kubernetes.
Versions WAS exécutant vos applications : collectez des informations sur les versions WAS exécutant vos applications et assurez-vous de leur compatibilité avec Migrate to Containers. Migrate to Containers est compatible avec la migration des applications WAS traditionnelles (WebSphere Application Server 8.5.5.x et WebSphere Application Server 9.0.5.x) pour les deux environnements de base WAS et de déploiement réseau WAS.
Applications déployées dans votre WAS : identifiez les applications déployées dans chaque WAS. Mappez ensuite les dépendances entre vos applications, et entre vos applications et les services externes. Ensuite, rassemblez les informations sur les sources de configuration de vos charges de travail. Par exemple, lequels des éléments suivants utilisez-vous ?
- Variables d'environnement
- Chemins d'installation WAS non standards
- Registres d'utilisateurs LDAP
- Mappages des rôles de sécurité
- Modifications pour appliquer une classe à votre commande de chargeur
Score d'adéquation Migrate to Containers : déterminez si vos applications traditionnelles WAS sont adaptées à la migration avec Migrate to Containers. Migrate to Containers fournit un outil d'évaluation de l'adéquation que vous pouvez exécuter sur vos applications traditionnelles WAS pour calculer un score d'adéquation. Migrate to Containers a un ensemble d'exigences minimales pour migrer correctement les applications traditionnelles WAS. Il présente également certaines limites lors de l'automatisation de la migration des applications traditionnelles WAS. Vous pouvez contourner ces limites en configurant manuellement les applications lors de leur migration.
Authentification : WAS fournit plusieurs mécanismes d'authentification, tels que Simple WebSphere Authentication Mechanism (SWAM), Lightweight Third Party Authentication (LTPA) et Kerberos. Vous ne pouvez configurer qu'une seule mise en œuvre de registre d'utilisateurs en tant que registre d'utilisateurs actifs du domaine de sécurité WAS. Migrate to Containers ne migre pas automatiquement les détails d'authentification. Cela signifie que la configuration de l'authentification nécessite normalement une configuration manuelle pendant la migration.
Accès aux données (JDBC) : L'architecture de connecteur J2EE définit un adaptateur de ressources standard qui connecte WAS aux systèmes d'information de l'entreprise. L'adaptateur assure la connectivité entre le système d'information de l'entreprise, le serveur d'applications et les applications. Migrate to Containers migre automatiquement la configuration JDBC vers le conteneur WAS modernisé. Assurez-vous d'avoir activé la connectivité entre vos applications migrées et les datastores existants.
Messagerie (JMS) : WAS est compatible avec la communication asynchrone via l'interface de programmation du service de messagerie Java (JMS, Java Messaging Service). Migrate to Containers migre automatiquement les informations de configuration de JMS. Cependant, certaines migrations manuelles sont nécessaires pour des configurations spécifiques, telles que SSL.
Mail : WAS permet d'envoyer des e-mails via l'API JavaMail. Migrate to Containers ne migre pas automatiquement les fichiers de configuration JavaMail. Configurez manuellement ces fichiers pendant la phase de migration.
Terminer l'évaluation
Après avoir créé les inventaires liés à votre environnement et à vos charges de travail WAS traditionnelles, effectuez les autres étapes de la phase d'évaluation décrites dans la page Migration vers Google Cloud : évaluer et découvrir vos charges de travail. Lorsque vous avez terminé, lisez ce document.
Planifier et établir vos fondations
Après avoir suivi les instructions de la section Planifier et créer votre infrastructure de base lors de la migration de VM, établissez votre base WAS :
- Confirmer le nom du bucket Cloud Storage.
Importez le fichier
binaryAppScanner.jardisponible dans le kit de migration IBM WebSphere Application Server pour les binaires d'application en procédant comme suit :- Téléchargez le
fichier du programme d'installation
binaryAppScannerInstaller.jar. Vous devez accepter le contrat de licence dans le cadre du téléchargement. Exécutez la commande suivante pour extraire le fichier binaryAppScanner.jar et accepter le contrat de licence :
java -jar binaryAppScannerInstaller.jar --acceptLicense --verboseSpécifiez le répertoire cible pour l'extraction, par exemple
/tmp. Le programme d'installation crée un répertoire nommé/wamtdans le répertoire cible.Accédez au répertoire
/wamt, par exemple :cd /tmp/wamtImportez le fichier
binaryAppScanner.jarà la racine d'un bucket Cloud Storage :gsutil cp binaryAppScanner.jar gs://BUCKET_NAMEOù BUCKET_NAME est le nom de votre bucket Cloud Storage.
- Téléchargez le
fichier du programme d'installation
La page Configurer Migrate to Containers explique comment provisionner et configurer Migrate to Containers et ses dépendances. Suivez ces instructions pour configurer Migrate to Containers.
Lorsque vous avez terminé, lisez ce document.
Migrer vos applications traditionnelles WAS vers des conteneurs
Pour en savoir plus sur la phase de déploiement de la migration, suivez les instructions de la page Migrer vos VM vers des conteneurs.
Générer et examiner le plan de migration
Créez un plan de migration Migrate to Containers pour vos applications traditionnelles WAS :
- Configurer les environnements sources en tant que sources de migration Migrate to Containers : pour migrer vos applications traditionnelles WAS, Migrate to Containers a besoin d'informations sur les environnements sources dans lesquels vos VM s'exécutent. Vous avez collecté ces informations en effectuant les tâches décrites dans la section Créer vos inventaires de ce document. Pour en savoir plus sur la configuration des environnements sources, consultez la page Ajouter une source de migration.
Créer des plans de migration : pour spécifier les applications WAS traditionnelles que vous souhaitez migrer d'un environnement source vers un environnement cible compatible, créez un plan de migration. Par exemple, vous pouvez configurer l'emplacement dans lequel vous souhaitez stocker vos données persistantes.
Pour en savoir plus sur la création et la surveillance des plans de migration, consultez la section Créer une migration.
Pour créer la migration, vous devez utiliser la ligne de commande. Vous ne pouvez pas utiliser la console Google Cloud. La commande complète est la suivante :
migctl migration create my-migration --source my-was-src --vm-id PROJECT_ID --intent Image --os-type Linux --app-type websphere-traditionalOù PROJECT_ID est l'ID attribué à votre projet de migration et
Imageest la valeur de l'option intent. Vous utilisez "Image" en raison de la nature sans état de la charge de travail.Examiner et personnaliser les plans de migration : après avoir généré des plans de migration pour chacune des VM que vous souhaitez migrer, examinez et personnalisez chaque plan de migration pour vous assurer qu'il répond à vos besoins. Pour en savoir plus sur la personnalisation des plans de migration, consultez la section Personnaliser un plan de migration.
Générer des artefacts de migration et des descripteurs de déploiement
Pour générer les artefacts WAS cibles pour vos applications, Migrate to Containers extrait les applications exécutées dans les VM que vous avez configurées dans les plans de migration. Il crée ensuite plusieurs artefacts et les place dans un bucket Cloud Storage. Migrate to Containers génère les descripteurs de déploiement que vous pouvez personnaliser et utiliser pour déployer des instances des images de conteneurs dans l'environnement cible.
Pour chaque application migrée, Migrate to Containers crée un dossier contenant le contexte Docker, les binaires de l'application, un script de compilation et un script de configuration WAS.
Vous pouvez surveiller la progression des artefacts de conteneur que vous créez et migrez. Pour en savoir plus sur la surveillance d'une migration, consultez la page Surveiller les charges de travail migrées.
Vérifier et valider les ressources et les descripteurs générés
Après avoir généré des artefacts de conteneur et des descripteurs de déploiement avec Migrate to Containers, examinez et mettez à jour ces artefacts et descripteurs de sorte qu'ils répondent à vos besoins. Par exemple, prenez en compte les aspects suivants :
- Descripteurs d'images de conteneurs : consultez les descripteurs d'images de conteneurs que vous avez générés avec Migrate to Containers et vérifiez qu'ils sont adaptés à la charge de travail des conteneurs. Si vous devez mettre à jour les descripteurs d'image de conteneur, consultez la section Créer une image d'application. Vous pouvez ajouter des propriétés et installer iFixes.
- Journalisation au niveau de l'application : Migrate to Containers écrivent automatiquement les journaux WAS au format JSON. Pour passer à la journalisation de base, consultez la section Configuration de journalisation.
Pour en savoir plus sur l'examen des artefacts de conteneur et des descripteurs de déploiement, consultez la page Examiner les fichiers de déploiement générés.
Déployer et valider des charges de travail conteneurisées sur GKE ou GKE Enterprise
Lorsque les descripteurs de déploiement pour vos charges de travail sont prêts, vous effectuez les opérations suivantes :
Créer une image de conteneur d'application : créez une image de conteneur d'application pour votre charge de travail migrée dans le dossier d'artefacts d'application que vous souhaitez créer.
bash ./build.shDéployer vos applications migrées dans l'environnement cible : déployez vos applications migrées :
kubectl apply -f deployment_spec.yamlSurveiller les charges de travail migrées : après avoir déployé votre conteneur d'applications traditionnel WAS, vous pouvez collecter des informations sur leurs performances dans l'environnement cible. Pour en savoir plus, consultez la page Surveiller les charges de travail migrées.
Intégrer vos charges de travail migrées : une fois que les charges de travail déployées dans l'environnement cible fonctionnent, intégrez les processus de génération et de déploiement d'artefacts de conteneur des charges de travail à vos processus de déploiement et à vos pipelines. Si vous n'avez pas de processus de déploiement automatisé en place et que vous déployez manuellement vos charges de travail, il est recommandé de passer des déploiements manuels aux déploiements automatisés.
Désinstaller Migrate to Containers
Une fois la migration de vos charges de travail avec Migrate to Containers terminée, il est recommandé d'effectuer les opérations suivantes :
- Assurez-vous de disposer de toutes les références aux artefacts générés par Migrate to Containers lors de la migration.
- Désinstallez Migrate to Containers.
Lorsque vous avez terminé le travail décrit dans cette section, revenez à ce document.
Optimiser votre environnement après la migration
Pour effectuer votre migration, consultez les consignes de la page Optimiser votre environnement après la migration.
Vous pouvez effectuer ces optimisations spécifiques à WAS pour vos applications WAS traditionnelles migrées :
- Externaliser votre configuration : lorsque vous créez un conteneur WAS traditionnel, des modifications de configuration peuvent se produire entre les environnements. Pour éviter de recréer le conteneur pour chaque environnement, il est recommandé d'externaliser la configuration WAS dans des propriétés et d'utiliser ConfigMaps pour définir ces propriétés au démarrage du conteneur.
- Sécuriser les données sensibles : les mots de passe et toutes les autres données sensibles doivent être placés dans des secrets Kubernetes. Utilisez les secrets Kubernetes pour remplacer les espaces réservés de configuration au démarrage du conteneur.
Étape suivante
- Découvrez les bonnes pratiques concernant la création et l'exploitation des conteneurs.
- Découvrez les bonnes pratiques pour l'exécution d'applications Kubernetes à coût optimisé sur GKE.
- Migrer des VM vers des conteneurs avec Migrate to Containers
- Découvrez des architectures de référence, des schémas et des bonnes pratiques concernant Google Cloud. Consultez notre Centre d'architecture cloud.