Notes de version de la CLI Migrate to Containers

Cette page répertorie les mises à jour en production de la CLI Migrate to Containers. Consultez-la régulièrement pour obtenir des informations sur les fonctionnalités nouvelles ou mises à jour, les corrections de bugs, les problèmes connus et les fonctionnalités obsolètes.

3 janvier 2024

Le 3 janvier 2024, nous avons lancé la version 1.4.1 des plug-ins de modernisation Migrate to Containers, qui inclut des corrections de bugs pour les migrations Tomcat.

4 décembre 2023

Le 4 décembre 2023, nous avons lancé la version 1.2.2 de la CLI Migrate to Containers.

Obsolète

Le plug-in websphere-traditional est désormais obsolète. Pour les clients existants, ce plug-in restera compatible jusqu'en décembre 2023, après quoi il ne sera plus disponible. Si vous débutez avec la modernisation des charges de travail WebSphere, utilisez plutôt le plug-in websphere-container avec la CLI Migrate to Containers.

2 novembre 2023

Le 2 novembre 2023, nous avons lancé la version 1.2.1 de la CLI Migrate to Containers, qui inclut des corrections de bugs.

30 octobre 2023

Le 30 octobre 2023, nous avons lancé la version 1.2.0 de la CLI Migrate to Containers.

Fonctionnalités

Ajout de la compatibilité avec la migration d'applications Linux hors connexion

La CLI Migrate to Containers permet désormais de travailler sans connexion à Internet à l'aide du nouveau mode hors connexion. Le mode hors connexion vous permet de migrer des applications Linux dans un environnement hors connexion.

Cela est utile si votre environnement local, qui inclut les machines locales et sources et le cluster de déploiement, se trouve dans un réseau sécurisé nécessitant une approbation et une analyse de sécurité pour le téléchargement de fichiers et de binaires externes. Avec le mode hors connexion, nous avons simplifié le processus de réception des mises à jour logicielles depuis les sources externes vers un réseau sécurisé en ajoutant des options de regroupement de fichiers et de dissociation. En outre, vous pouvez spécifier un registre local et sécurisé en tant que source pour les artefacts requis pour l'application migrée.

Pour configurer les migrations hors connexion, procédez comme suit après avoir téléchargé la CLI Migrate to Containers :

  1. Téléchargez le groupe de plug-ins de la CLI Migrate to Containers hors connexion :

    curl -O https://storage.googleapis.com/modernize-plugins-prod/$(curl -s https://storage.googleapis.com/modernize-plugins-prod/latest)/m2c-offline-bundle-linux.tar

  2. Si nécessaire, copiez la CLI Migrate to Containers et le groupe de plug-ins de la CLI Migrate to Containers hors connexion dans l'environnement hors connexion.

  3. Décompressez le groupe de plug-ins de la CLI Migrate to Containers hors connexion :

    ./m2c plugins unpack -i m2c-offline-bundle-linux.tar

    Pour ajouter la compatibilité avec la migration de données hors connexion, spécifiez un registre de conteneurs disponible dans votre réseau local :

    ./m2c plugins unpack -i m2c-offline-bundle-linux.tar --registry HOSTNAME

    Remplacez HOSTNAME par le nom d'hôte du registre de conteneurs.

Pour plus d'informations, consultez la page Configurer la migration hors connexion.

22 août 2023

Le 22 août 2023, nous avons lancé la version 1.1.0 de la CLI Migrate to Containers.

Fonctionnalités

Ajout de la prise en charge de la migration des services Windows IIS

La CLI Migrate to Containers est désormais compatible avec la migration des services Windows IIS. La migration des services Windows IIS nécessite l'exécution de la CLI Migrate to Containers sur une machine Windows.

Pour moderniser les services Windows IIS, procédez comme suit :

  1. Exportez les images disque de la VM source vers des fichiers VHD.

    Par exemple, pour exporter une image à partir de Compute Engine, exportez-la d'abord vers Cloud Storage, puis téléchargez l'image sur votre ordinateur local :

    gcloud compute images export \
    --export-format vhdx \
    --destination-uri DESTINATION_URI \
    --image IMAGE_NAME
gcloud storage cp DESTINATION_URI LOCAL_PATH

  2. Analysez les images du disque pour créer un plan de migration :

    ./m2c analyze \
   -s PATH_TO_IMAGE \
   -p windows-iis-container \
   -o ANALYSIS_OUTPUT_PATH

  3. Modifiez le plan de migration.

  4. Générez des artefacts de migration à partir des images disque et du plan de migration :

    ./m2c generate \
   -i ANALYSIS_PATH \
   -o OUTPUT_ARTIFACTS_PATH

Prise en charge améliorée pour la migration des applications IBM WebSphere

La prise en charge IBM WebSphere a été modifiée et étendue. Le plug-in existant est compatible avec WebSphere Application Server traditionnel en tant que source de migration. Un nouveau plug-in a été ajouté pour supporter WebSphere Application Server Liberty en tant que source de migration.

Modifications de la migration traditionnelle de IBM WebSphere Application Server

Les modifications suivantes ont été apportées à la migration traditionnelle du serveur d'applications IBM WebSphere :

  • Le plug-in websphere-traditional-container permet désormais de migrer des charges de travail traditionnelles du serveur d'applications IBM WebSphere.
  • Ajout de la compatibilité avec WebSphere Application Server Liberty en tant que cible.
  • Le paramètre was-home est désormais obligatoire, même si vous analysez la VM source à l'aide de mFit.

Pour migrer une charge de travail traditionnelle de serveur d'applications IBM WebSphere, exécutez la commande suivante :

./m2c analyze \
    -s PATH_TO_COPIED_FILESYSTEM \
    -p websphere-traditional-container -o ANALYSIS_OUTPUT_PATH \
    -r was-home=PATH_TO_WAS_HOME \
    --volume PATH_TO_BINARYAPPSCANNER:/binaryAppScanner.jar

Pour en savoir plus, consultez la page Créer un plan de migration pour les charges de travail WebSphere traditionnelles.

Ajout de la prise en charge de la migration IBM WebSphere Application Server Liberty

La modernisation de WebSphere Application Server Liberty est désormais en disponibilité générale avec le plug-in websphere-container.

Pour migrer une charge de travail IBM WebSphere Liberty, exécutez la commande suivante :

./m2c analyze \
    -s PATH_TO_COPIED_FILESYSTEM \
    -p websphere-container \
    -o ANALYSIS_OUTPUT_PATH \
    -r websphere-home=WEBSPHERE_HOME \
    -r websphere-java-home=WEBSPHERE_JAVA_HOME
    -r target-base-image=TARGET_BASE_IMAGE

Pour en savoir plus, consultez la page Créer un plan de migration pour les charges de travail WebSphere Application Server Liberty.

Le plug-in Tomcat a été mis à jour

Les paramètres de découverte du plug-in Tomcat ont été mis à jour.

  • Le paramètre java-version est maintenant ajouté en tant qu'entrée aux migrations Tomcat.
  • Le paramètre catalina-base peut désormais inclure plusieurs répertoires délimités par des signes deux-points (:).
  • Les paramètres java-version, catalina-base et catalina-home sont désormais obligatoires, même si vous analysez la VM source à l'aide de mFit.

Pour en savoir plus, consultez la page Créer un plan de migration pour les charges de travail Tomcat.

Le plug-in des conteneurs système Linux a été mis à jour

Les points de terminaison de service système Linux ne sont plus détectés automatiquement et doivent être spécifiés manuellement lors de la personnalisation du plan de migration Linux, même si vous analysez la VM source à l'aide de mFit.

Fixe

Dans les versions antérieures de la CLI Migrate to Containers, la commande copy pouvait échouer lors de la tentative d'utilisation d'un socket dans le répertoire /tmp, car il est automatiquement supprimé dans certains systèmes. Dans cette version, les valeurs par défaut ont été modifiées. Pour personnaliser l'emplacement du socket, vous pouvez définir la variable d'environnement SOCKDIR.

Problèmes

  • La compilation Skaffold pour les images Windows peut échouer sur une machine Windows, car Skaffold tente d'extraire l'image de base pour la mauvaise cible.

    Pour contourner ce problème, extrayez l'image manuellement à l'aide de la commande docker pull, puis exécutez à nouveau la compilation Skaffold.

  • Le déploiement de charges de travail Windows IIS peut être marqué comme non prêt en raison de délais d'expiration trop courts. Si vous déployez vos charges de travail à l'aide de Skaffold, le déploiement peut apparaître comme ayant échoué.

    Pour contourner ce problème, augmentez le délai avant expiration et la période de vérification de la préparation à l'aide de PowerShell :

    foreach ($file in (Get-ChildItem . -Recurse -Include "deployment_spec.yaml")) { (Get-Content $file).replace("periodSeconds: 10", "periodSe
conds: 30").replace("timeoutSeconds: 1", "timeoutSeconds: 10") | Set-Content $file }

27 juin 2023

Le 27 juin 2023, nous avons lancé la version 1.0.0 de la CLI Migrate to Containers.

Fonctionnalités

Mise à niveau de la version de l'API Skaffold

La CLI Migrate to Containers génère désormais la configuration Skaffold avec la version v4beta4 de l'API Skaffold au lieu de la version v2beta25.

Ajout de la compatibilité avec la conteneurisation de VM Linux

La CLI Migrate to Containers vous permet désormais de migrer des VM Linux vers des conteneurs système. Il découvre les fichiers d'application sources et les traite pour générer des artefacts de migration, qui incluent un Dockerfile, un fichier manifeste Kubernetes et des scripts de déploiement automatisé basés sur Skaffold.

La CLI Migrate to Containers utilise un conteneur système Linux prédéfini qui fonctionne comme un bootloader pour les services requis par l'application modernisée. Grâce à la CLI Migrate to Containers, vous pouvez moderniser un large éventail d'applications sans état basées sur Linux pour les exécuter sur des clusters GKE, Cloud Run ou GKE Enterprise.

Pour en savoir plus, consultez la section Créer un plan de migration pour un conteneur de VM Linux.

Amélioration de l'opération copy

Les améliorations suivantes sont maintenant disponibles pour l'opération copy :

  • L'opération copy de la CLI Migrate to Containers utilise maintenant un conteneur local pour copier le système de fichiers de la VM source dans un répertoire local au lieu d'utiliser un fichier tar local. Cette amélioration vous évite d'avoir à installer rsync sur votre ordinateur local et réduit l'espace disque requis pour copier le système de fichiers de la machine source.

  • En cas d'échec, la CLI Migrate to Containers poursuit maintenant le processus de copie à partir du point de défaillance.

Pour en savoir plus, consultez la page Copier le système de fichiers de la machine source.

Ajout de la possibilité de nettoyer le système de fichiers copié

Une fois la migration terminée, vous pouvez utiliser la nouvelle commande cleanup pour supprimer la copie du système de fichiers de la machine source que vous avez créée avec la commande copy sur votre ordinateur local, sans aucun problème d'autorisation.

Pour en savoir plus, consultez la page Nettoyer votre ordinateur local.

Ajout de la compatibilité avec la migration de données

Après avoir exécuté une migration, vous pouvez maintenant copier les répertoires de données dans une demande de volume persistant (PVC) nouvelle ou existante sur le cluster cible à l'aide de la nouvelle commande migrate-data.

Cette étape est nécessaire dans le cas où vous devrez peut-être migrer des répertoires de données persistants de la VM source vers des volumes persistants installés sur le conteneur cible.

Pour en savoir plus, consultez la page Migrer des données.

13 juin 2023

Le 13 juin 2023, nous avons annoncé que la CLI Migrate to Containers était désormais en disponibilité générale.

La CLI Migrate to Containers vous permet de moderniser les composants d'application exécutés sur des VM dans des conteneurs s'exécutant sur des clusters GKE, GKE Autopilot, Cloud Run ou GKE Enterprise.

Pour en savoir plus, consultez la page Migrer vos applications vers des charges de travail basées sur des conteneurs via la ligne de commande | Blog Google Cloud.

2 mai 2023

Le 2 mai 2023, nous avons lancé la CLI Migrate to Containers 0.2.0 en version preview. La CLI Migrate to Containers vous permet de moderniser les composants d'application exécutés sur des VM dans des conteneurs s'exécutant sur des clusters GKE, GKE Autopilot, Cloud Run ou GKE Enterprise. L'outil propose un flux simplifié composé de quatre étapes principales :

  1. Copie des fichiers d'application à partir d'une VM source à l'aide de SSH ou de gcloud CLI
  2. Analyse de la copie locale des fichiers d'application pour générer un plan de migration
  3. Modification des fichiers du plan de migration pour le personnaliser
  4. Génération des artefacts requis en tant qu'image de conteneur, fichier YAML de déploiement et fichier de configuration Skaffold

Pour en savoir plus, consultez À propos de Migrate to Containers | Google Cloud.

Fonctionnalités

Copier les fichiers de l'application source

Copiez les fichiers de votre application à partir d'une VM distante sur site via SSH ou d'une VM exécutée sur Google Cloud à l'aide de gcloud CLI.

Analyser les fichiers d'application pour les moderniser

Analysez les binaires et les fichiers de configuration de l'application, puis générez un rapport sur le fichier de plan de migration et le plan de migration à l'aide des paramètres extraits des fichiers copiés.

Générer des artefacts d'application à exécuter en tant que conteneur

Générez des artefacts dont vous avez besoin pour exécuter l'application en tant que conteneur avec un fichier de configuration Skaffold qui vous permet d'automatiser le déploiement des artefacts générés sur votre cluster cible.

Flux de modernisation compatibles

Avec la nouvelle CLI Migrate to Containers, vous pouvez travailler sur la modernisation de votre application dans votre environnement local et déployer les artefacts générés directement sur un cluster local ou distant.

La CLI Migrate to Containers est compatible avec les flux de modernisation suivants :

  • Application Tomcat dans un conteneur qui utilise une image de base de la communauté
  • Application Apache dans un conteneur qui utilise une image de base de la communauté
  • Application IBM JBoss dans un conteneur utilisant une image de base WildFly de la communauté
  • Serveur d'applications IBM WebSphere traditionnel dans un conteneur utilisant une image traditionnelle du serveur d'applications IBM WebSphere
  • Serveur d'applications IBM WebSphere traditionnel dans un conteneur qui utilise une image de conteneur Open Liberty