Moderniser les charges de travail traditionnelles
Cet article explique comment moderniser les charges de travail basées sur des VM en conteneurs s'exécutant sur Google Kubernetes Engine (GKE), sur un cluster GKE, ou sur la plate-forme Cloud Run. Vous pouvez migrer des charges de travail à partir de VM s'exécutant sur VMware ou Compute Engine, ce qui vous permet de conteneuriser vos charges de travail existantes.
Pour effectuer la modernisation (également appelée migration), utilisez un cluster de traitement que vous avez créé en suivant la procédure de la page Installer Migrate to Containers.
Le flux de base pour migrer une charge de travail est similaire dans les types de charges de travail compatibles. Il existe certaines différences entre les types de charges de travail. Vous devez donc identifier votre type de charge de travail dans les sections ci-dessous pour obtenir un aperçu de la procédure et des informations détaillées par étape.
Charges de travail compatibles
- VM Linux
- Application Windows IIS
- Application Tomcat
- Applications traditionnelles WebSphere
- JBoss
- Apache
- Sites WordPress
Migrer une VM Linux
Procédure de migration
Le schéma suivant illustre les étapes de migration d'une charge de travail Linux :
Ajoutez une source de migration.
Pour démarrer une migration, configurez une source qui représente la plate-forme source à partir de laquelle vous effectuez la migration. Si vous disposez déjà d'une source issue d'une migration précédente et que les VM que vous migrez proviennent de la même source, vous pouvez la réutiliser.
-
Créez un objet de migration avec un plan de migration initial.
-
Indiquez si vous souhaitez migrer des données.
Personnalisez votre plan de migration.
Modifiez le plan de migration en fonction de vos besoins spécifiques avant de procéder à la migration.
-
Exécutez la migration pour extraire les artefacts du conteneur, y compris l'image de conteneur et le Dockerfile. Utilisez ces artefacts pour déployer le conteneur dans votre environnement de test ou en production.
-
Suivez la progression de la migration et inspectez les journaux d'activité de migration.
-
Supprimez la migration pour libérer toutes les ressources qu'elle utilise.
Migrer une application Windows IIS
Procédure de migration
Le schéma suivant illustre les étapes de migration d'une charge de travail Windows :
Voici les étapes à suivre pour migrer avec Migrate to Containers :
Ajoutez une source de migration.
Pour commencer une migration, vous devez configurer une source qui représente la plate-forme source à partir de laquelle vous effectuez la migration. Si vous disposez déjà d'une source issue d'une migration précédente et que les VM que vous migrez proviennent de la même source, vous pouvez la réutiliser.
-
Créez un objet de migration avec un plan de migration initial.
Personnalisez votre plan de migration.
Modifiez le plan de migration en fonction de vos besoins spécifiques avant de procéder à la migration.
-
Exécutez la migration pour extraire les artefacts du conteneur, qui comprennent le Dockerfile et d'autres fichiers nécessaires pour créer une image de conteneur.
-
Suivez la progression de la migration et inspectez les journaux d'activité de migration.
Créer une image de conteneur Windows
Utilisez les artefacts générés pour créer un conteneur Windows déployable sur un cluster.
-
Supprimez la migration pour libérer toutes les ressources qu'elle utilise.
Fonctionnalités compatibles
Migrate to Containers : actuellement, Windows permet de migrer des sites du framework IIS .NET. Vous pouvez diviser les sites en images à usage unique ou les regrouper comme vous le souhaitez.
Pour mieux déterminer les sites pouvant être migrés sur une VM source, essayez d'exécuter l'évaluation hors connexion de la CLI du client de découverte du centre de migration.
Migrer un serveur Tomcat
Le schéma suivant illustre les étapes de migration d'une charge de travail Tomcat :
Lorsque vous utilisez Migrate to Containers pour migrer vos charges de travail Tomcat, vous pouvez tirer parti des fonctionnalités et de l'architecture Tomcat pour :
- Séparer automatiquement des sous-ensembles d'applications en conteneurs individuels.
- Gérer les keystores, les truststores et les certificats de votre application Tomcat à partir de la VM source.
- Déterminer de manière dynamique l'allocation de mémoire optimale pour les applications JVM.
- Copier des volumes de données spécifiques et des demandes de volume de données à partir de vos VM sources.
Prérequis
- Serveur d'applications Apache Tomcat v8.5 et ultérieure basé sur une VM Linux.
- Déterminez si la charge de travail est adaptée à la migration en exécutant une évaluation hors connexion.
- Configurez un cluster Cloud pour la migration des VM Windows.
Procédure de migration
Voici les étapes à suivre pour migrer avec Migrate to Containers :
Ajoutez une source de migration.
Pour commencer une migration, vous devez configurer une source qui représente la plate-forme source à partir de laquelle vous effectuez la migration. Si vous disposez déjà d'une source issue d'une migration précédente et que les VM que vous migrez proviennent de la même source, vous pouvez la réutiliser.
-
Créez un objet de migration avec un plan de migration initial.
-
Indiquez si vous souhaitez migrer des données.
Personnalisez votre plan de migration.
Modifiez le plan de migration en fonction de vos besoins spécifiques avant de procéder à la migration.
-
Exécutez la migration pour extraire les artefacts du conteneur, qui comprennent le Dockerfile et d'autres fichiers nécessaires pour créer une image de conteneur.
-
Suivez la progression de la migration et inspectez les journaux d'activité de migration.
Créez une image de conteneur Tomcat
Utilisez les artefacts générés pour créer un conteneur déployable sur un cluster.
-
Supprimez la migration pour libérer toutes les ressources qu'elle utilise.
Fonctionnalités non compatibles
Les fonctionnalités Tomcat suivantes ne sont pas compatibles :
Clustering/Réplication de session.
Compatibilité avec Windows pour les migrations Tomcat à l'aide de charges de travail Windows.
Migrer les applications WebSphere traditionnelles
Présentation de la migration
IBM WebSphere Application Server (WAS) traditionnel est un framework logiciel qui héberge des charges de travail Java. Migrate to Containers vous permet de moderniser les charges de travail des applications exécutées dans le système WAS traditionnel en les convertissant en conteneurs d'applications. Vous pouvez ensuite déployer les conteneurs d'applications sur un cluster GKE ou GKE Enterprise sur Google Cloud.
À propos de la migration des applications WebSphere Application Server traditionnel
Une VM WAS traditionnel peut contenir plusieurs applications. Migrate to Containers vous permet d'automatiser la modernisation des applications WAS vers des conteneurs en détectant les applications déployées sur la VM source et en suggérant automatiquement la configuration pour la modernisation.
Google exige de migrer chaque application vers sa propre image de conteneur (ibmcom/websphere-traditional
, ibmcom/websphere-liberty
ou openliberty/open-liberty
). Vous pouvez ensuite tester et déployer les applications migrées individuellement, plutôt que de devoir tester et déployer plusieurs applications ensemble.
La source de migration peut être de type WAS ND ou WAS base. La cible sera un conteneur de base WAS ou Free, et les fonctionnalités de clustering ND respectives seront déléguées à Kubernetes.
Conditions requises
Vérifiez que vos environnements de migration et de déploiement sont compatibles avec Migrate to Containers en consultant la configuration système suivante.
Conditions requises pour la migration des applications WAS traditionnel
Avant de commencer la migration, assurez-vous que votre environnement traditionnel WAS et vos clusters de traitement de migration répondent aux exigences décrites ci-dessous.
Configuration système requise pour les systèmes WAS traditionnels
Migrate to Containers est compatible avec la migration des applications hébergées sur les versions suivantes d'IBM WAS :
- WebSphere Application Server traditionnel 8.5.5.x
- WebSphere Application Server traditionnel 9.0.5.x
Pour que Migrate to Containers puisse traiter une VM contenant une application traditionnelle WAS, Migrate to Containers extrait deux types de configurations à partir de la VM :
Configuration de chaque application.
Configuration du profil cible. Un profil définit l'environnement d'exécution d'un WAS, y compris les ports, les paramètres JVM, etc.
Le logiciel Migrate to Containers automatise l'utilisation du kit de migration IBM WebSphere Application Server pour les binaires d'application dans votre cluster GKE Enterprise ou GKE afin de découvrir, évaluer et générer des rapports de migration et des scripts de configuration. Vous êtes seul responsable de l'obtention, de la licence et de l'utilisation du kit.
Avant de pouvoir lancer une migration, vous devez importer le kit dans un bucket Google Cloud Storage de votre compte. Consultez la section Configurer le fichier binaryAppScanner.jar pour cette procédure.
Systèmes d'exploitation de VM compatibles
Migrate to Containers permet la migration des applications WAS traditionnel à partir de VM installées avec les systèmes d'exploitation Linux 64 bits répertoriés sur la page Systèmes d'exploitation de VM compatibles.
Traiter les exigences du cluster
Utiliser un cluster Google Kubernetes Engine (GKE) ou GKE Enterprise pour exécuter les composants Migrate to Containers qui effectuent les transformations nécessaires à la migration d'une application à partir d'une source VM vers un conteneur cible. Pour les applications dans une VM WAS :
Vous pouvez déployer le cluster de traitement en tant que :
Le cluster de traitement doit utiliser un système d'exploitation Linux répertorié sur la page Systèmes d'exploitation de cluster de traitement compatibles.
Consultez la section Choisir le type de cluster de traitement pour en savoir plus sur la création de chaque type de cluster de traitement.
Conditions requises pour le déploiement d'applications migrées
Après avoir migré vos applications, assurez-vous que votre environnement d'application et votre cluster cible répondent aux exigences décrites ci-dessous.
Configuration requise pour le cluster cible
Utilisez un cluster Google Kubernetes Engine (GKE), GKE Enterprise sur Google Cloud ou Google Distributed Cloud Virtual pour Bare Metal. Le cluster cible doit utiliser un système d'exploitation Linux répertorié sur la page Systèmes d'exploitation de cluster de charge de travail compatibles.
Lors du processus de migration, Migrate to Containers crée une image Docker représentant une application WAS migrée et l'importe dans un registre Docker. Vous devez vous assurer que le cluster cible dispose d'un accès en lecture au registre Docker, comme décrit ici.
Conteneurs cibles compatibles
- WebSphere Application Server traditionnel
- WebSphere Application Server Liberty
- Open Liberty
Avant de commencer
Avant de commencer une migration, vous devez d'abord effectuer les tâches suivantes.
Installer Migrate to Containers
Installez Migrate to Containers sur votre cluster de traitement. Un cluster de traitement est un cluster Google Kubernetes Engine (GKE) ou GKE Enterprise avec des composants Migrate to Containers installés, que vous utilisez pour migrer des VM. Consultez la section Présentation de l'installation pour connaître toutes les instructions d'installation.
Configurer Migrate to Virtual Machines (facultatif)
Pour migrer des charges de travail Websphere vers Google Cloud à partir de VMware à l'aide de Migrate to Containers, vous devez configurer Migrate to Virtual Machines qui gère le transport.
Pour plus d'informations, consultez la section Configurer Migrate to Virtual Machines.
Configurer le fichier binaryAppScanner.jar
Migrate to Containers automatise l'utilisation de binaryAppScanner.jar
, disponible dans le cadre du kit de migration IBM WebSphere Application Server pour les binaires d'application, pour extraire les informations de configuration et les fichiers des applications WAS dans la VM source.
Avant de pouvoir effectuer une migration, vous devez effectuer les étapes ci-dessous :
Acceptez le contrat de licence et téléchargez le kit de migration IBM WebSphere Application Server pour les binaires d'application, puis extrayez le fichier
binaryAppScanner.jar
.Créez un Dockerfile et préparez le plug-in fourni avec l'outil d'analyse binaire.
Pour configurer binaryAppScanner.jar
, procédez comme suit :
Téléchargez le fichier d'installation
binaryAppScannerInstaller.jar
auprès de l'assistance IBM. 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 --verbose
Spécifiez le répertoire cible pour l'extraction. Par exemple,
/tmp
. Le programme d'installation crée un répertoire nommé/wamt
sous le répertoire cible.Accédez au répertoire /wamt. Exemple :
cd /tmp/wamt
Créez deux fichiers Dockerfile à l'aide des commandes suivantes :
FROM us-docker.pkg.dev/migrate-modernize-public/modernize-plugins-prod/websphere-traditional-container-discover:1.3.1 ADD binaryAppScanner.jar /
FROM us-docker.pkg.dev/migrate-modernize-public/modernize-plugins-prod/websphere-traditional-container-extract:1.3.1 ADD binaryAppScanner.jar /
Créez et transférez les images Docker :
gcloud builds submit --timeout 1h -t gcr.io/PROJECT_ID/websphere-traditional-container-discover-with-scanner:1.3.1 --project PROJECT_ID gcloud builds submit --timeout 1h -t gcr.io/PROJECT_ID/websphere-traditional-container-extract-with-scanner:1.3.1 --project PROJECT_ID
Modifiez le CRD du plug-in pour le grouper avec un analyseur binaire comme suit :
$ kubectl edit appxplugins.anthos-migrate.cloud.google.com -n v2k-system websphere-traditional-container # Set the value of spec.discoveryImage and spec.generateArtifactsImage: apiVersion: anthos-migrate.cloud.google.com/v1beta2 kind: AppXPlugin metadata: namespace: v2k-system name: websphere-traditional-container labels: anthos-migrate.cloud.google.com/preview-type: public annotations: anthos-migrate.cloud.google.com/display-name: WebSphere traditional container spec: discoverImage: gcr.io/PROJECT_ID/websphere-traditional-container-discover-with-scanner:1.3.1 discoverCommand: - /ko-app/websphere-traditional - discover generateArtifactsImage: gcr.io/PROJECT_ID/websphere-traditional-container-extract-with-scanner:1.3.1 generateArtifactsCommand: - /ko-app/websphere-traditional - extract parameterDefs: - name: was-home usage: Path of the WebSphere WAS_HOME on the original instance. envVar: APPX_WAS_HOME
Enregistrez le CRD.
Procédure de migration
Le schéma suivant illustre les étapes de migration d'une charge de travail WebSphere :
Voici les étapes à suivre pour migrer avec Migrate to Containers :
Ajoutez une source de migration.
Ajoutez la source de migration qui représente la plate-forme source.
-
Créez un objet de migration avec un plan de migration initial.
-
Indiquez si vous souhaitez migrer des données.
Personnaliser le plan de migration.
Modifiez le plan de migration en fonction de vos besoins spécifiques avant de procéder à la migration. Vous migrez une application WAS par migration.
-
Exécutez la migration pour extraire les artefacts du conteneur, qui comprennent le Dockerfile et d'autres fichiers nécessaires pour créer une image de conteneur.
Générez et examinez les artefacts de migration.
Effectuez la migration pour générer le conteneur d'application. Vous pouvez surveiller le processus de migration et, une fois terminé, examiner les artefacts en vue de créer l'image d'application déployable.
-
Suivez la progression de la migration et inspectez les journaux d'activité de migration.
Créez une image de conteneur d'application.
Utilisez les artefacts générés pour créer un conteneur déployable sur un cluster.
Déployez un conteneur d'application sur un cluster cible.
Déployez l'image sur votre cluster cible.
-
Supprimez la migration pour libérer toutes les ressources qu'elle utilise.
Migrer un serveur JBoss
Le schéma suivant illustre les étapes de migration d'une charge de travail JBoss :
Lorsque vous utilisez Migrate to Containers pour migrer vos charges de travail JBoss, vous pouvez tirer parti des fonctionnalités et de l'architecture de JBoss pour copier des volumes de données et des demandes de volume de données spécifiques à partir de vos VM sources.
Prérequis
Serveur d'applications JBoss v8.1.0 et version ultérieure, ou serveur d'applications JBoss EAP v7.0, v7.1, v7.2, v7.3 et v7.4.
Configurez un cluster Google Cloud pour la migration de VM.
Procédure de migration
Voici les étapes à suivre pour migrer avec Migrate to Containers :
Ajoutez une source de migration.
Pour commencer une migration, vous devez configurer une source représentant la plate-forme source à partir de laquelle vous effectuez la migration. Si vous disposez déjà d'une source issue d'une migration précédente et que les VM que vous migrez proviennent de la même source, vous pouvez la réutiliser.
-
Créez un objet de migration avec un plan de migration initial.
-
Indiquez si vous souhaitez migrer des données.
Personnalisez votre plan de migration.
Modifiez le plan de migration en fonction de vos besoins spécifiques avant de procéder à la migration.
-
Exécutez la migration pour extraire les artefacts du conteneur, qui comprennent le Dockerfile et d'autres fichiers nécessaires pour créer une image de conteneur.
-
Suivez la progression de la migration et inspectez les journaux d'activité de migration.
Créer une image de conteneur JBoss
Utilisez les artefacts générés pour créer un conteneur déployable sur un cluster.
-
Supprimez la migration pour libérer toutes les ressources qu'elle utilise.
Fonctionnalités non compatibles
Les fonctionnalités JBoss suivantes ne sont pas compatibles :
- Secrets et données sensibles : les données sensibles et les secrets stockés dans le répertoire
JBOSS_HOME/standalone
ne seront pas supprimés. Ces données seront incluses dans l'image du conteneur. - Configuration de l'enregistreur JBoss : la configuration de l'enregistreur est issue de la machine source. Elle ne sera pas modifiée lors du processus de migration, sauf si le fichier
jbossServer.tar.gz
est modifié manuellement avant la création du conteneur JBoss. - Allocation de mémoire : l'allocation des ressources de machine virtuelle Java (JVM) est issue du conteneur de la communauté et ne dépend pas des ressources JVM de la machine source.
- Variables d'environnement : les variables d'environnement et les paramètres JVM de la machine source ne seront pas migrés vers l'image de conteneur.
- Évaluation hors connexion : Il n'est pas possible de déterminer l'adéquation de votre charge de travail JBoss pour la migration.
Migrer un serveur Apache
Le diagramme suivant illustre les étapes de migration d'une charge de travail Apache :
Lorsque vous utilisez Migrate to Containers pour migrer vos charges de travail Apache, vous pouvez tirer parti des fonctionnalités et de l'architecture Apache pour :
- Copier des volumes de données spécifiques et des demandes de volume de données à partir de vos VM sources.
Prérequis
- Un serveur Web Apache 2 basé sur une VM Linux.
- Configurez un cluster Google Cloud pour la migration des VM Windows.
Procédure de migration
Voici les étapes à suivre pour migrer avec Migrate to Containers :
Ajoutez une source de migration.
Pour commencer une migration, vous devez configurer une source qui représente la plate-forme source à partir de laquelle vous effectuez la migration. Si vous disposez déjà d'une source issue d'une migration précédente et que les VM que vous migrez proviennent de la même source, vous pouvez la réutiliser.
-
Créez un objet de migration avec un plan de migration initial.
-
Indiquez si vous souhaitez migrer des données.
Personnalisez votre plan de migration.
Modifiez le plan de migration en fonction de vos besoins spécifiques avant de procéder à la migration.
-
Exécutez la migration pour extraire les artefacts du conteneur, qui comprennent le Dockerfile et d'autres fichiers nécessaires pour créer une image de conteneur.
-
Suivez la progression de la migration et inspectez les journaux d'activité de migration.
Créer une image de conteneur Apache
Utilisez les artefacts générés pour créer un conteneur déployable sur un cluster.
-
Supprimez la migration pour libérer toutes les ressources qu'elle utilise.
Fonctionnalités non compatibles
Les charges de travail Apache 1 ne sont pas compatibles.
Les fonctionnalités Apache suivantes ne sont pas compatibles :
Certificats.
Compatibilité avec Windows pour les migrations Apache à l'aide de charges de travail Windows.
Migrer un site WordPress
Lorsque vous utilisez Migrate to Containers pour migrer vos charges de travail WordPress, vous pouvez tirer parti des fonctionnalités et de l'architecture de WordPress pour copier des volumes de données et des demandes de volume de données spécifiques à partir de vos VM sources.
Prérequis
- WordPress version 4.0 ou ultérieure, s'exécutant sur un serveur Web Apache 2 basé sur une VM Linux
- Configurez un cluster Google Cloud pour la migration des VM Windows.
Procédure de migration
Voici les étapes à suivre pour migrer avec Migrate to Containers :
Ajoutez une source de migration.
Pour commencer une migration, vous devez configurer une source représentant la plate-forme source à partir de laquelle vous effectuez la migration. Si vous disposez déjà d'une source issue d'une migration précédente et que les VM que vous migrez proviennent de la même source, vous pouvez la réutiliser.
-
Créez un objet de migration avec un plan de migration initial.
Personnalisez votre plan de migration.
Modifiez le plan de migration en fonction de vos besoins spécifiques avant de procéder à la migration.
-
Examinez et modifiez le plan de migration de données en fonction de vos exigences spécifiques avant de procéder à la migration.
-
Exécutez la migration pour extraire les artefacts du conteneur, qui comprennent le Dockerfile et d'autres fichiers nécessaires pour créer une image de conteneur.
-
Suivez la progression de la migration et inspectez les journaux d'activité de migration.
Créer une image de conteneur WordPress
Utilisez les artefacts générés pour créer un conteneur déployable sur un cluster.
-
Supprimez la migration pour libérer toutes les ressources qu'elle utilise.
Fonctionnalités non compatibles
Les sites WordPress exécutés sur des hôtes autres que le serveur Web Apache 2 basé sur des VM Linux ne sont pas compatibles.
Les fonctionnalités WordPress suivantes ne sont pas compatibles :
Migration de base de données WordPress.
Pour en savoir plus sur la migration d'une application reposant sur une base de données, consultez la page Vérifier que les bases de données sont accessibles.
Exporter des données stockées localement sur le serveur WordPress, telles que des importations multimédias, des plug-ins et des thèmes, vers un lecteur NFS.
Pour plus d'informations sur l'exportation de données stockées localement vers NFS, consultez la section Définir des installations NFS en tant que volumes persistants.
Scaling horizontal du déploiement migré.
Les données stockées localement sur le serveur WordPress sont exportées vers le disque persistant Compute Engine, qui est installé sur le pod de déploiement migré. Un disque persistant Compute Engine ne peut pas être associé à plusieurs pods et empêche donc le scaling horizontal du déploiement migré.
Exporter des certificats et des données sensibles vers des objets secrets Kubernetes
Étapes suivantes
- Découvrez comment ajouter une source de migration.