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

Migrer une VM Linux

Procédure de migration

Le schéma suivant illustre les étapes de migration d'une charge de travail Linux :

Schéma des étapes de migration avec Migrate to Containers
  1. 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.

  2. Créez une migration.

    Créez un objet de migration avec un plan de migration initial.

  3. Migrez des données Linux.

    Indiquez si vous souhaitez migrer des données.

  4. Personnalisez votre plan de migration.

    Modifiez le plan de migration en fonction de vos besoins spécifiques avant de procéder à la migration.

  5. Exécutez 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.

  6. Contrôlez une migration.

    Suivez la progression de la migration et inspectez les journaux d'activité de migration.

  7. Supprimez une 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 :

Schéma des étapes de migration avec Migrate to Containers

Voici les étapes à suivre pour migrer avec Migrate to Containers :

  1. 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.

  2. Crée un plan de migration.

    Créez un objet de migration avec un plan de migration initial.

  3. Personnalisez votre plan de migration.

    Modifiez le plan de migration en fonction de vos besoins spécifiques avant de procéder à la migration.

  4. Exécutez 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.

  5. Surveillez la migration.

    Suivez la progression de la migration et inspectez les journaux d'activité de migration.

  6. 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.

  7. Supprimez une migration.

    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 :

Schéma des étapes de migration avec Migrate to Containers

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 :

  1. 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.

  2. Créez une migration.

    Créez un objet de migration avec un plan de migration initial.

  3. Migrer des données Tomcat

    Indiquez si vous souhaitez migrer des données.

  4. Personnalisez votre plan de migration.

    Modifiez le plan de migration en fonction de vos besoins spécifiques avant de procéder à la migration.

  5. Exécutez 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.

  6. Surveillez la migration.

    Suivez la progression de la migration et inspectez les journaux d'activité de migration.

  7. Créez une image de conteneur Tomcat

    Utilisez les artefacts générés pour créer un conteneur déployable sur un cluster.

  8. Supprimez une migration.

    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.

Migrez des applications WAS vers des conteneurs d'applications individuels.

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 :

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 :

Pour configurer binaryAppScanner.jar, procédez comme suit :

  1. 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.

  2. Exécutez la commande suivante pour extraire le fichier binaryAppScanner.jar et accepter le contrat de licence :

    java -jar binaryAppScannerInstaller.jar --acceptLicense --verbose
    
  3. 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.

  4. Accédez au répertoire /wamt. Exemple :

    cd /tmp/wamt
    
  5. 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 /
    
  6. 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
    
  7. 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
    
  8. Enregistrez le CRD.

Procédure de migration

Le schéma suivant illustre les étapes de migration d'une charge de travail WebSphere :

Migrez des applications WAS vers des conteneurs d'applications individuels.

Voici les étapes à suivre pour migrer avec Migrate to Containers :

  1. Ajoutez une source de migration.

    Ajoutez la source de migration qui représente la plate-forme source.

  2. Créez une migration.

    Créez un objet de migration avec un plan de migration initial.

  3. Migrez les données WebSphere.

    Indiquez si vous souhaitez migrer des données.

  4. 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.

  5. Exécutez 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.

  6. 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.

  7. Surveillez la migration.

    Suivez la progression de la migration et inspectez les journaux d'activité de migration.

  8. 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.

  9. Déployez un conteneur d'application sur un cluster cible.

    Déployez l'image sur votre cluster cible.

  10. Supprimez une migration.

    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 :

Schéma des étapes de migration avec Migrate to Containers

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 :

  1. 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.

  2. Créez une migration.

    Créez un objet de migration avec un plan de migration initial.

  3. Migrez les données JBoss.

    Indiquez si vous souhaitez migrer des données.

  4. Personnalisez votre plan de migration.

    Modifiez le plan de migration en fonction de vos besoins spécifiques avant de procéder à la migration.

  5. Exécutez 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.

  6. Surveillez la migration.

    Suivez la progression de la migration et inspectez les journaux d'activité de migration.

  7. Créer une image de conteneur JBoss

    Utilisez les artefacts générés pour créer un conteneur déployable sur un cluster.

  8. Supprimez une migration.

    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 :

Schéma des étapes de migration avec Migrate to Containers

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 :

  1. 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.

  2. Créez une migration.

    Créez un objet de migration avec un plan de migration initial.

  3. Migrez les données.

    Indiquez si vous souhaitez migrer des données.

  4. Personnalisez votre plan de migration.

    Modifiez le plan de migration en fonction de vos besoins spécifiques avant de procéder à la migration.

  5. Exécutez 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.

  6. Surveillez la migration.

    Suivez la progression de la migration et inspectez les journaux d'activité de migration.

  7. Créer une image de conteneur Apache

    Utilisez les artefacts générés pour créer un conteneur déployable sur un cluster.

  8. Supprimez une migration.

    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 :

  1. 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.

  2. Créez une migration.

    Créez un objet de migration avec un plan de migration initial.

  3. Personnalisez votre plan de migration.

    Modifiez le plan de migration en fonction de vos besoins spécifiques avant de procéder à la migration.

  4. Migrez des données WordPress.

    Examinez et modifiez le plan de migration de données en fonction de vos exigences spécifiques avant de procéder à la migration.

  5. Exécutez 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.

  6. Surveillez la migration.

    Suivez la progression de la migration et inspectez les journaux d'activité de migration.

  7. Créer une image de conteneur WordPress

    Utilisez les artefacts générés pour créer un conteneur déployable sur un cluster.

  8. Supprimez une migration.

    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