Migrer des charges de travail Tomcat

Migrate for Anthos and GKE permet d'accélérer la conteneurisation des charges de travail et le déploiement traditionnels dans les clusters GKE et Anthos.

Présentation de la migration

Cette offre en version bêta publique vous permet désormais de moderniser vos charges de travail Tomcat exécutées sur des VM Linux en les convertissant en conteneurs d'applications. Vous pouvez ensuite déployer les conteneurs d'applications vers :

Lorsque vous utilisez Migrate for Anthos and GKE, vous pouvez migrer vos charges de travail Tomcat en tirant parti des fonctionnalités et de l'architecture de Tomcat pour effectuer les opérations suivantes :

  • 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

Pour migrer vos applications Tomcat, vous devez remplir les conditions suivantes :

Processus de migration

Le processus de migration des applications Tomcat est semblable au processus de migration Linux actuel, avec les mises en garde suivantes :

  • Considérations sur l'adéquation :

    • Vous devez exécuter mfit l'outil d'évaluation de l'adéquation avant de lancer la migration de votre charge de travail Tomcat pour terminer la phase de collecte des données.
    • Vous pouvez utiliser plusieurs règles mfit spécifiques à Tomcat pour évaluer votre charge de travail. Pour plus d'informations sur les règles mfit Tomcat spécifiques, consultez la documentation Tomcat mfit.
    • Ne spécifiez pas l'option --readonly. L'option --readonly empêche mfit de stocker les données collectées sur Tomcat sur la VM, et empêche Migrate for Anthos and GKE d'accéder à ces données.
    • N'utilisez pas l'option ./mfit discover. Vous devez exécuter le script de collecte de données sur une VM pour récupérer les informations requises pour la conteneurisation à l'aide des images de la communauté Tomcat OSS.

  • Autres points à noter :

    • Vous devez spécifier l'option --workload–type avec l'option tomcat lors de l'exécution de migctl pour créer le plan de migration.
    • Pour personnaliser votre migration, modifiez le fichier YAML de votre plan de migration. Ce fichier possède un format spécifique à Tomcat détaillé ci-dessous dans la section Personnaliser le plan de migration.
    • Lorsque vous générez les artefacts de migration, Migrate for Anthos and GKE crée un fichier build.sh que vous utiliserez ensuite pour créer l'image de conteneur du déploiement.

    • Pour effectuer la migration des données avec la migration de l'application Tomcat, vous pouvez modifier le fichier YAML de configuration des données (my-migration.data.yaml)).

      Pour en savoir plus sur le format du fichier yaml de configuration des données, consultez la section Personnaliser la configuration de la migration des données ci-dessous.

Effectuer une migration des charges de travail Tomcat

Pour effectuer une migration de la charge de travail Tomcat, procédez comme suit :

  1. Exécuter mfit : mfit est l'outil d'évaluation de l'adéquation qui permet d'évaluer la viabilité de votre charge de travail Tomcat existante pour la migration.

  2. Configurer un cluster de traitement : installez les composants Migrate for Anthos and GKE sur un cluster GKE que vous avez déjà créé pour traiter la migration et la conteneurisation de vos charges de travail basées sur des VM.

    Pour en savoir plus sur la configuration adéquate d'un cluster de traitement en fonction de l'environnement cible, consultez la page Installer Migrate for Anthos and GKE.

  3. Ajouter une source de migration : ajoutez la source de la migration qui représente la plate-forme source à partir de laquelle vous souhaitez effectuer la migration. Par exemple, si vous migrez une VM depuis Compute Engine : 

     migctl source create ce my-src --project my-project --json-key json-key-file

    Pour en savoir plus sur l'ajout de sources de migration et sur la syntaxe appropriée, consultez la documentation sur l'ajout d'une source de migration.

  4. Créer une migration : créez un plan de migration que vous pouvez examiner et personnaliser avant d'exécuter la migration.

    Pour créer un plan de migration pour les charges de travail Tomcat, vous pouvez utiliser la commande migctl suivante avec l'option --workload-type définie sur tomcat :

     migctl migration create my-migration --source my-src --vm-id my-vm --workload-type tomcat

    Où :

    • my-migration : indique le nom de la migration.
    • my-src : indique le nom de la source de migration que vous avez créée à l'étape précédente.

  5. Vérifier votre plan de migration : pour vérifier le fichier YAML contenant votre plan de migration (y compris la configuration de la mémoire requise et des limites de mémoire, les paramètres de segmentation des applications Tomcat et les paramètres de certificat), procédez comme suit :

    1. Téléchargez votre plan de migration (my-migration.yaml) et vos fichiers de configuration de migration de données (my-migration.data.yaml)) :

      migctl migration get my-migration

      Cette commande télécharge les fichiers nommés my-migration.yaml et my-migration.data.yaml.

    2. Ouvrez my-migration.yaml dans un éditeur de texte et affichez les détails de la migration. Modifiez les détails si nécessaire pour personnaliser le plan de migration. Pour en savoir plus sur la personnalisation de votre plan de migration, consultez la section Personnaliser le plan de migration ci-dessous.

    3. Une fois les modifications terminées, enregistrez le fichier modifié : 

      migctl migration update my-migration --main-config my-migration.yaml

  6. (Facultatif) Configurer la migration de données : Migrate for Anthos and GKE vous permet de migrer des dossiers persistants à partir de vos charges de travail Tomcat à l'aide du fichier de configuration de migration de données (my-migration.data.yaml). Le fichier my-migration.data.yaml est vide par défaut.

    Pour configurer my-migration.data.yaml, procédez comme suit :

    1. Téléchargez les fichiers de configuration de migration de données (my-migration.data.yaml) et du plan de migration (my-migration.yaml) à l'aide de la commande suivante :

      migctl migration get my-migration

      Cette commande renvoie les fichiers nommés my-migration.yaml et my-migration.data.yaml.

    2. Modifiez le fichier my-migration.data.yaml dans un éditeur de texte.

    3. Une fois les modifications terminées, enregistrez le fichier modifié :

      migctl migration update my-migration --data-config my-migration.data.yaml

  7. Générer des artefacts de migration : effectuez la migration pour générer les artefacts de conteneur :

    migctl migration generate-artifacts my-migration

    Pour plus d'informations sur la génération d'artefacts de migration, consultez la documentation Exécuter une migration.

  8. Vérifier les artefacts : examinez les artefacts en vue de créer l'image de conteneur déployable en exécutant la commande suivante :

    migctl migration get-artifacts my-migration

    Cette commande crée un répertoire distinct pour chaque serveur Tomcat répertorié dans votre plan de migration. Migrate for Anthos and GKE crée un répertoire imbriqué correspondant en fonction du plan de migration pour chacune des images de serveur. Ces répertoires imbriqués incluent des artefacts d'image permettant de créer et de déployer l'image.

    Chaque répertoire inclut plusieurs artefacts :

    • Le fichier build.sh que vous pouvez utiliser pour créer l'image de conteneur pour le serveur Tomcat
    • Le fichier deployment_spec.yaml que vous utilisez pour déployer l'image de conteneur
    • Le fichier cloudbuild.yaml que vous pouvez utiliser pour recréer l'image ultérieurement dans le cadre d'un pipeline CI/CD
    • Le fichier volumes.yaml contenant la répartition de vos volumes de données migrés

    Pour en savoir plus sur la vérification de vos artefacts de migration, consultez l'étape 9 : Vérifier volumes.yaml ci-dessous.

    .

  9. (Facultatif) Vérifier volumes.yaml :

    L'un des artefacts générés par Migrate for Anthos and GKE à la fin d'une migration est nommé volumes.yaml.

    Votre volumes.yaml contient des informations sur les PVC, les PV et les disques persistants dans lesquels les données ont été copiées dans le cadre de la migration de données. Vous pouvez choisir d'utiliser ces informations si vous souhaitez modifier la charge de travail migrée avant de la déployer afin de rendre les données copiées accessibles à votre charge de travail.

    Le format du fichier volumes.yaml est le suivant :

    volumes:
       deployment pvc name:
         pvc:
           full pvc yaml
         pv:
           full pvc yaml

    Pour en savoir plus sur la définition d'un fichier yaml PVC ou PV, consultez la documentation Kubernetes.

  10. Créer l'image de conteneur : utilisez le fichier build.sh créé dans les artefacts de migration pour créer l'image de conteneur de votre serveur Tomcat.

    1. Accédez au répertoire contenant les artefacts générés pour votre image Tomcat.

      Par exemple, pour accéder au répertoire d'un serveur Tomcat nommé latest et d'une image nommée app, exécutez la commande suivante :

      cd latest/app

    2. Définissez l'ID du projet Google Cloud et la version de l'image :

      export PROJECT_ID=my_project VERSION=latest

    3. Exécutez le script build.sh pour créer votre image de conteneur, puis importez-la dans Container Registry :

      bash ./build.sh

  11. Déployer le conteneur d'application : déployez l'application migrée vers votre cluster cible.

    sed -e "s/\${PROJECT_ID}/${PROJECT_ID}/g" -e "s/\${VERSION}/${VERSION}/g"
 deployment_spec.yaml | kubectl apply -f -

    Pour plus d'informations sur le déploiement de votre conteneur d'applications sur un cluster cible, consultez la documentation Déployer un conteneur d'application sur un cluster cible.

Personnaliser votre plan de migration

Lorsque vous créez le plan de migration, Migrate for Anthos and GKE génèrent un fichier YAML contenant des informations pour chaque serveur Tomcat en cours d'exécution détecté. Vous devez modifier le plan de migration pour personnaliser les propriétés de chaque serveur Tomcat avant de générer les artefacts de migration.

Pour personnaliser votre migration, vous devez modifier votre plan de migration (my-migration.yaml) :

tomcatServers:
    - name: latest
      catalinaBase: /opt/tomcat/latest
      catalinaHome: /opt/tomcat/home
      secrets: # files to extract from the server container images into secrets
        - name: my-vm-latest-ssl
          path: /usr/local/ssl
          files:
            - server.crt
            - server.pem
        - name: my-vm-latest-keystore
          path: /usr/home/tomcat
          files:
            - .keystore
            - .truststore
      images:
        - name: my-vm-latest-docs # name of the image for build and deployment
          fromImage: tomcat:8.5.66-jdk16-openjdk # for the resulting container image
          applications: # list of applications to include in the image
            - /opt/tomcat/latest/latest/webapps/docs
          additionalFiles: # external required paths
            - /opt/libraries/postgres.jar
          logConfigPaths: # of the contained web apps. Must be under catalina base
            - /opt/tomcat/latest/virtualHost/webapps/docs/WEB-INF/classes/log4j2.xml
          ports: # to create Kubernetes services associated with the resulting deployment
            - 8080
          resources:
            memory:
              limits: 2048M
              requests: 1280M
          secrets: # to mount in the container image
            - my-vm-latest-ssl
            - my-vm-latest-keystore
        - name: another-image
          . . .
    - name: another-server
      . . .

Dans my-migration.yaml :

  • name : spécifie le nom du serveur Tomcat, déterminé à partir du nom catalinaBase. Migrate for Anthos and GKE ajoute un suffixe en cas de conflit de noms.

  • catalinaBase/Home : défini au niveau du serveur Tomcat

  • secrets : les secrets peuvent être définis dans deux champs d'application, soit :

    • Champ d'application du serveur : vous pouvez définir les champs secrets name, path et files dans le champ d'application du serveur.
    • Champ d'application de l'image : vous pouvez définir des champs secrets sous la forme d'une liste de chemins de chaîne dans le champ d'application de l'image.

  • images : contient une entrée pour chaque application et une entrée pour toutes les applications. Si aucun serveur Tomcat n'a été détecté dans votre charge de travail, l'attribut images inclut un seul exemple d'entrée que vous pourrez définir lors de l'examen.

    • name : spécifie le nom de l'image de conteneur générée, au format suivant :

      tomcat-name

      Par exemple, pour un serveur Tomcat nommé latest, le champ imageName est :

      Tomcat-latest

    • fromImage : déterminé une seule fois pour toutes les applications du même serveur Tomcat.

  • additionalFiles : découverts au niveau du serveur et attribué à toutes les applications.

    • ports : définis dans votre serveur Tomcat, les connecteurs peuvent être associés à des applications pertinentes.
    • Resources : suggérées automatiquement pour l'image unifiée uniquement.
    • Une image contenant toutes les applications est également fournie.

Définir vos secrets et vos certificats

Lorsque vous créez une migration Tomcat, un processus de découverte analyse les configurations du serveur pour détecter l'utilisation des certificats. Les chemins de certificat sont mappés aux différentes applications détectées.

Ces certificats sont affichés dans le plan de migration au niveau du serveur et de l'image :

  • Champ d'application du serveur : les secrets que vous incluez au niveau du serveur seront exclus des artefacts d'image obtenus. Un script d'artefact dédié appelé secrets.sh automatise la création d'objets secrets Kubernetes à partir de leurs chemins d'accès locaux.

  • Champ d'application de l'image : les noms des secrets que vous incluez au niveau de l'image entraînent l'installation automatique des secrets correspondants dans les conteneurs déployés. Si vous avez défini un chemin d'accès secret en tant que chemin relatif dans le plan de migration, le chemin d'installation sera fixe par rapport au répertoire d'installation d'image de la communauté Tomcat.

Vous pouvez créer des objets secrets Kubernetes à l'aide de l'artefact secrets.sh avec Migrate for Anthos and GKE en exécutant la commande suivante :

bash ./secrets.sh namespace of deployments secret file secret file …

Journalisation des applications Web

Migrate for Anthos and GKE accepte la journalisation avec log4j v2, logback et log4j v1.x qui résident dans CATALINA_HOME. Les chemins situés en dehors de CATALINA_HOME ne sont pas acceptés.

Migrate for Anthos and GKE crée un fichier d'archive supplémentaire avec des configurations de journal modifiées et convertit tous les avenants de type de fichier en appenders de console. Vous pouvez utiliser le contenu de cette archive comme référence pour activer la collecte de journaux et leur diffusion vers une solution de collecte de journaux (telle que Google Cloud Logging).

Allocation de mémoire

Au cours du processus de migration, Migrate for Anthos and GKE tente de localiser les limites de mémoire du segment de mémoire maximal de Tomcat Java sur les VM sources. Si des limites de mémoire sont détectées sur une VM source, Migrate for Anthos and GKE définit les valeurs initiales (requests) et maximales (limits) de votre conteneur migré.

Si vous souhaitez spécifier des limites de mémoire pour les applications migrées vers des conteneurs individuels, ou si aucune limite de mémoire n'a été trouvée dans vos VM sources, vous pouvez les modifier directement dans votre plan de migration en utilisant le format suivant :

tomcatServers:
    - name: latest
      . . .
      images:
        - name: tomcat-latest
          . . .
          resources:
            memory:
              limits: 2048M
              requests: 1280M

Si des limites de mémoire ont été définies dans votre plan de migration, le fichier Dockerfile (généré avec d'autres artefacts après une migration réussie) reflète votre déclaration :

FROM tomcat:8.5.66-jdk16-openjdk

# Add JVM environment variables for tomcat
ENV CATALINA_OPTS="${CATALINA_OPTS} -XX:MaxRAMPercentage=50 -XX:InitialRAMPercentage=50 -XX:+UseContainerSupport <additional variables>"

Définir les variables d'environnement Tomcat

Si vous souhaitez définir CATLINA_OPTS dans votre fichier Dockerfile (généré avec d'autres artefacts après une migration réussie), vous pouvez d'abord ajouter le champ catalinaOpts à votre plan de migration :

tomcatServers:
    - name: latest
      . . .
      images:
        - name: tomcat-latest
          . . .
          resources:
            . . .
          catalinaOpts: "-Xms512M -Xmx1024M"

Migrate for Anthos and GKE analysent vos données catalinaOpts dans votre fichier Dockerfile :

FROM 8.5.66-jdk16-openjdk-slim

## setenv.sh script detected.
## Modify env variables on the script and add definitions to the migrated tomcat server,
## if needed (less recommended than adding env variables directly to CATALINA_OPTS) by uncomment the line below
#ADD --chown=root:root setenv.sh /usr/local/tomcat/bin/setenv.sh

    # Add JVM environment variables for the tomcat server
ENV CATALINA_OPTS="${CATALINA_OPTS} -XX:MaxRAMPercentage=50 -XX:InitialRAMPercentage=50 -Xss10M"

Vous pouvez également définir des variables d'environnement Tomcat à l'aide du script setenv.sh (situé dans le dossier /bin de votre serveur Tomcat). Pour en savoir plus sur les variables d'environnement Tomcat, consultez la documentation Tomcat.

Si vous choisissez d'utiliser setenv.sh pour définir vos variables d'environnement Tomcat, vous devez modifier le fichier Dockerfile.

Personnaliser la configuration de la migration de données

Migrate for Anthos and GKE vous permet de spécifier des volumes de données ou des revendications de volume de données à migrer depuis vos charges de travail Tomcat pendant le processus de migration.

Pour activer la migration de données dans votre processus de migration, vous devez fournir des informations sur le volume de données cible ou la revendication dans votre fichier de configuration de données (my-migration.data.yaml) au format indiqué ci-dessous :

dataConfig:
      volumes:
        - deploymentPvcName:
          existingPvc:
            Name: my-pvc
          folders:
            - /bin
            - /opt
        - newPvc:
            accessModes:
            - ReadWriteOnce
            resources:
              requests:
                storage: 10G
          folders:
            - /bin
            - /opt

Où :

  • deploymentPvcName : est le nom du PVC qui sera utilisé par Migrate for Anthos and GKE dans votre charge de travail déployée pour accéder à ce volume. (Non utilisé dans les migrations Tomcat).

  • existingPvc:

    • name : est le nom d'un PVC existante. Indiquez si vous souhaitez migrer des volumes de données vers un PVC existant. Doit être nil dans les autres cas.

  • newPvc : indiquez si vous souhaitez migrer vos volumes de données vers un nouveau PVC. Vous pouvez définir votre PVC à l'aide de la spécification PVC standard.

    Pour en savoir plus sur la spécification PVC Kubernetes, consultez la documentation de Kubernetes.

  • folders :

Vous pouvez modifier votre fichier de configuration de données pour plusieurs cas d'utilisation de la migration de données, y compris :

Aucune migration de données

Si vous ne souhaitez pas migrer de données pendant la migration, vous devez laisser vide le fichier de configuration de données généré (my-migration.data.yaml). Par défaut, votre fichier de configuration de données est créé vide.

Utiliser un PersistentVolumeClaim (PVC) existant

Vous pouvez migrer vos données à l'aide d'un PersistentVolumeClaim (PVC) existant si vous avez déjà alloué le stockage souhaité pour vos données migrées et que vous disposez d'un PVC dans lequel vous souhaitez stocker vos données.

Vous pouvez définir un PVC existant dans votre fichier de configuration de données (my-migration.data.yaml) en transmettant votre volume existant dans le champ existingPvc.

Votre PVC doit exister avant votre migration. Dans ce cas, votre fichier de configuration de données ressemblerait à ceci :

dataConfig:
      volumes:
        - deploymentPvcName:
          existingPvc:
            name: my-pvc
          newPvc: # must be nil
          folders:
            - /bin
            - /opt

Créer des volumes de données sur vos VM migrées

Si vous n'avez pas alloué d'espace de stockage à l'avance et que vous souhaitez que celui-ci soit créé pendant le processus de migration, vous pouvez transmettre un champ existingPvc vide et spécifier l'espace de stockage que vous souhaitez créer dans le champ newPvc :

dataConfig:
      volumes:
        - deploymentPvcName:
          existingPvc: #must be nil
          newPvc:
            accessModes:
            - ReadWriteOnce
            resources:
              requests:
                storage: 10G
          folders:
            - /bin
            - /opt

Si vous ne souhaitez pas vous soucier des spécificités de votre stockage de sauvegarde, vous devez utiliser une chaîne vide pour la classe de stockage.

Si vous souhaitez déclarer une classe de stockage spécifique, vous devez préparer un objet de classe de stockage dans le même cluster qui crée votre espace de stockage en fonction de vos besoins.

Migrer plusieurs PVC avec plusieurs chemins de fichiers

Vous pouvez spécifier l'ensemble de répertoires sous le champ de liste folders de chaque entrée de la liste volume pour chaque PVC répertorié dans votre fichier de configuration de données (my-migration.data.yaml) :

dataConfig:
      volumes:
        - deploymentPvcName:
          existingPvc:
            name: my-pvc
          folders:
            - /bin
            - /opt
        - newPvc:
            accessModes:
            - ReadWriteOnce
            resources:
              requests:
                storage: 10G
          folders:
            - /bin
            - /opt

Les chemins d'accès que vous répertoriez sous folders dans le fichier de configuration sont copiés sur les mêmes chemins d'accès dans les PVC cibles.

Migration des données : étapes suivantes

Une fois votre fichier de configuration de données validé, vous devez passer à l'Étape 7 : Générer des artefacts du processus de migration.

Vous pouvez vérifier vos volumes migrés avec l'artefact volumes.yaml produit lors du processus de migration Tomcat.

Fonctionnalités non compatibles

Les fonctionnalités Tomcat suivantes ne sont pas compatibles avec cette version :

  • Migration des versions : Migrate for Anthos and GKE n'accepte pas la migration vers des images avec différentes versions de Tomcat et Java.

  • Clustering/Réplication de session.

  • Compatibilité avec Windows pour les migrations Tomcat à l'aide de charges de travail Windows.

  • Détection de versions/fournisseurs Java : Migrate for Anthos and GKE suggère une version et un fournisseur Java prédéfinis qui sont ensuite utilisés pour sélectionner l'image Tomcat, au lieu de la détecter automatiquement.

Dépannage

Au cours du processus de migration de votre charge de travail pour Tomcat, vous pouvez rencontrer des erreurs.

  • Si vous recevez une erreur build.sh : 

    manifest for ... not found: manifest unknown: manifest unknown

Ce message d'erreur indique que l'image parente de votre charge de travail est manquante. Il existe deux solutions pour limiter cette erreur :

  • Modifiez votre fichier de configuration d'extraction avec une image existante, puis réexécutez l'Étape 7 : Générer des artefacts.
  • Modifiez la déclaration dockerfile FROM pour référencer une image existante et réexécuter build.sh.