Personnaliser un plan de migration

Preview

Ce produit ou cette fonctionnalité est soumis aux "Conditions des offres de pré-DG" dans la section "Conditions d'utilisation générales" des Conditions spécifiques au service. Les produits et fonctionnalités pré-DG sont disponibles "en l'état" et peuvent bénéficier d'une assistance limitée. Pour en savoir plus, consultez les descriptions des étapes de lancement.

Vous devez examiner le fichier de plan de migration résultant de la création d'une migration. Personnalisez le fichier avant d'exécuter la migration. Les détails de votre plan de migration sont utilisés pour extraire les artefacts de conteneur de charge de travail de la source.

Cette section décrit le contenu de la migration et les types de personnalisations que vous pouvez envisager avant d'exécuter la migration et de générer des artefacts de déploiement.

Avant de commencer

• Cet article suppose que vous avez déjà créé une migration et que vous disposez du fichier de plan de migration.

Modifier le plan de migration

Vous pouvez modifier le plan de migration à l'aide de l'outil migctl ou de Google Cloud Console.

migctl

Vous devez télécharger le plan de migration avant de pouvoir le modifier :

1. Téléchargez le plan de migration. Le plan est représenté par GenerateArtifactsFlow :

   migctl migration get my-migration
   

2. Modifiez le plan de migration téléchargé, my-migration.yaml, dans un éditeur de texte.

3. Une fois les modifications effectuées, enregistrez et importez le plan de migration révisé :

   migctl migration update my-migration --file my-migration.yaml
   

4. Répétez ces étapes si d'autres modifications sont nécessaires.

Console

Modifiez le plan de migration dans Google Cloud Console à l'aide de l'éditeur YAML. Le plan de migration est représenté par la CRD GenerateArtifactsFlow :

1. Ouvrez la page Migrate for Anthos and GKE dans Cloud Console.

   Accédez à la page "Migrer vers des conteneurs".

2. Cliquez sur l'onglet Migrations pour afficher un tableau contenant les migrations disponibles.

3. Sur la ligne de la migration souhaitée, sélectionnez le Nom de la migration pour ouvrir l'onglet Détails.

4. Sélectionnez l'onglet YAML.

   Remarque : Vous pouvez également sélectionner Télécharger le plan de migration pour télécharger une copie locale.

5. Modifiez le plan de migration si nécessaire.

6. Une fois les modifications terminées, vous pouvez effectuer l'une des opérations suivantes :

   1. Enregistrez le plan de migration. Vous devrez ensuite exécuter manuellement la migration pour générer les artefacts de migration. Suivez la procédure décrite dans la section Exécuter une migration.

   2. Enregistrez et générez les artefacts. Exécutez la migration en utilisant vos modifications pour générer les artefacts de migration. Le processus est le même que celui décrit dans la section Exécuter une migration. Vous pouvez ensuite surveiller la migration, comme décrit dans la section Surveiller une migration.

CRD

Vous devez télécharger le plan de migration, le modifier, puis l'appliquer. Le plan de migration est représenté par la CRD GenerateArtifactsFlow :

1. Obtenez le nom de l'élément GenerateArtifactsFlow :

   kubectl get migrations.anthos-migrate.cloud.google.com -n v2k-system my-migration -o jsonpath={.status.resources.generateArtifacts.name}

   Le modèle de dénomination est renvoyé au format generate-artifacts-flow-id.

2. Écrivez le code suivant dans un fichier nommé my-plan.yaml en utilisant le nom de la CRD GenerateArtifactsFlow :

   kubectl get generateartifactsflows.anthos-migrate.cloud.google.com -n v2k-system generate-artifacts-flow-id -o yaml > my-plan.yaml

3. Modifiez le plan de migration si nécessaire.

4. Appliquez le fichier :

   kubectl apply -f my-plan.yaml

Passez en revue les détails de votre plan de migration et les commentaires d'orientation, et ajoutez des informations si nécessaire. Vous pouvez plus précisément envisager des modifications telles qu'elles sont décrites dans les sections suivantes :

Spécifier l'image Docker

Dans le plan de migration, nous générons un tag d'image de la communauté Docker basé sur la version Tomcat, la version Java et le fournisseur Java.

• Version Tomcat : la version Tomcat est détectée et convertie en version majeure (les versions mineures ne sont pas compatibles). Si nous ne parvenons pas à détecter une version Tomcat, le fichier fromImage contient une chaîne vide.
• Version Java : la version de Java est définie à l'aide des informations de la collection d'évaluation d'adéquation. Si CATALINA_BASE ou CATALINA_HOME sont saisis manuellement, ou si l'évaluation d'adéquation n'a pas pu collecter la version Java, la version Java est définie sur 11 par défaut.
• Fournisseur Java : le fournisseur Java est défini sur une constante : openjdk.

Sur le plan de migration, le champ fromImage représente le tag d'image Docker utilisé comme base de l'image du conteneur.

Les versions d'origine Tomcat et Java détectées sur la VM source sont contenues dans le fichier discovery-report.yaml, généré par la découverte initiale.

Si vous souhaitez modifier l'image de la communauté Docker ou fournir votre propre image Docker, vous pouvez modifier le tag fromImageTag dans votre plan de migration au format suivant :

tomcatServers:
    - name: latest
      . . .
      images:
        - name: tomcat-latest
          . . .
          fromImage: tomcat:9.0-jdk11-openjdk

Configurer SSL

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 … 

Remarque : L'ordre dans lequel vous répertoriez vos objets secrets lors de l'exécution de secrets.sh doit correspondre à l'ordre des objets secrets de votre plan de migration.

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.

Important : 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 la diffusion vers une solution de collecte de journaux (telle que Google Cloud Logging).

Remarque : Lors de la migration vers une image de conteneur, Migrate for Anthos and GKE filtre le répertoire logs du serveur Tomcat pour omettre les anciens journaux.

Allocation de mémoire

Au cours du processus de migration, Migrate for Anthos and GKE tente de localiser les limites de mémoire pour le tas de mémoire maximal du tas de mémoire Java Tomcat 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 requests sur initial et limits sur maximum pour de votre conteneur migré.

Ces valeurs sont basées sur la valeur Java du tas de mémoire maximal (-Xmx/-XX:MaxHeapSize) qui est collectée à partir de l'instance source à l'aide de l'évaluation d'adéquation (mfit). Les valeurs sont les suivantes : limit=200%Xmx, request=125%Xmx.

Remarque : Migrate for Anthos and GKE n'accepte que les arguments JVM Xmx,MaxHeapSize.

Si vous souhaitez spécifier les limites de mémoire des 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 modifier les limites de mémoire directement dans votre plan de migration au format suivant :

tomcatServers:
    - name: latest
      . . .
      images:
        - name: tomcat-latest
          . . .
          resources:
            memory:
              limit: 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-jdk11-openjdk

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

Ce fichier définit la taille initiale et la taille maximale à 50 % de la valeur limite. La taille d'allocation de segments de mémoire Java Tomcat pourra ainsi évoluer en fonction de modifications qui seraient apportées à la limite de mémoire du pod.

Remarque : Si le champ catalinaOpts contient une variable -Xms/InitialRAMPrecentage/InitialRAMFraction/InitialHeapSize, la variable d'environnement InitialRAMPercentage=50 ne sera pas définie.

Définir des 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 : L'exemple suivant montre un champ catalineOpts mis à jour :

tomcatServers:
    - name: latest
      . . .
      images:
        - name: tomcat-latest
          . . .
          resources:
            . . .
          catalinaOpts: "-Xss10M"

Migrate for Anthos and GKE analyse vos données catalinaOpts dans votre fichier Dockerfile : L'exemple suivant montre le résultat de l'analyse :

FROM 8.5-jdk11-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.0 -XX:InitialRAMPercentage=50.0 -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.

Remarque : La définition de -Xmx écrase -XX:MaxRAMPercentage. Si vous définissez -Xms, celui-ci écrase -XX:InitialRAMPercentage.

Remarque : Migrate for Anthos and GKE n'évalue pas le contenu setenv.sh. Par conséquent, il est recommandé d'ajouter directement les variables d'environnement Tomcat à CATALINA_OPTS.

Étapes suivantes

Exécuter une migration.