Personnaliser le plan de migration pour les VM Linux

Avant d'exécuter un plan de migration, vous devez le vérifier et éventuellement le personnaliser. Les détails de votre plan de migration sont utilisés pour l'extraction des artefacts de conteneur de charge de travail de la VM source, ainsi que pour la génération des fichiers de déploiement Kubernetes qui permettent de déployer l'image de conteneur sur d'autres clusters, tels qu'un cluster de production.

Cette section décrit le contenu du plan de 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 qui en résulte.

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 :

Téléchargez le plan de migration. Le plan de migration des charges de travail Linux est représenté par LinuxMigrationCommonSpec:
```
migctl migration get my-migration
```
Modifiez le plan de migration téléchargé, my-migration.yaml, dans un éditeur de texte.
Une fois les modifications effectuées, enregistrez et importez le plan de migration révisé :
```
migctl migration update my-migration --main-config my-migration.yaml
```
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 des charges de travail Linux est représenté par l'objet CRD LinuxMigrationCommonSpec:

Ouvrez la page "Migrate to Containers" dans la console Google Cloud.

Accéder à la page "Migrate to Containers".
Cliquez sur l'onglet Migrations pour afficher un tableau contenant les migrations disponibles.
Sur la ligne de la migration souhaitée, sélectionnez le Nom de la migration pour ouvrir l'onglet Détails.
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.
Modifiez le plan de migration si nécessaire.
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 des charges de travail Linux est représenté par la CRD LinuxMigrationCommonSpec:

Obtenez le nom de l'élément AppXGenerateArtifactsFlow :
```
kubectl get migrations.anthos-migrate.cloud.google.com -n v2k-system -o jsonpath={.status.migrationPlanRef.name} my-migration
```
Le modèle de dénomination est renvoyé au format appx-generateartifactsflow-id.

Récupérez le plan de migration par nom et écrivez dans un fichier nommé my-plan.yaml :

kubectl -n v2k-system get appxgenerateartifactsflows.anthos-migrate.cloud.google.com -o jsonpath={.spec.appXGenerateArtifactsConfig} appx-generateartifactsflow-id > my-plan.yaml

Modifiez le plan de migration si nécessaire.

Appliquez le fichier :

kubectl patch appxgenerateartifactsflows.anthos-migrate.cloud.google.com --type merge -n v2k-system --patch '{"spec": {"appXGenerateArtifactsConfig": '"$(jq -n --rawfile plan my-plan.yaml '$plan')"'}}' appx-generateartifactsflow-id

Spécifier le contenu à exclure de la migration

Par défaut, Migrate to Containers exclut le contenu de VM standard qui n'est pas pertinent dans le contexte de GKE. Vous pouvez personnaliser ce filtre.

La valeur du champ filters regroupe les chemins qui doivent être exclus de la migration et qui ne font pas partie de l'image du conteneur. La valeur du champ répertorie les règles de filtre rsync qui spécifient les fichiers à transférer et ceux à ignorer. Un signe moins précédant les chemins d'accès et les fichiers de la liste indique que l'élément doit être exclu de la migration. La liste est traitée selon l'ordre des lignes dans le fichier YAML, et les exclusions/inclusions sont évaluées en conséquence.

Pour en savoir plus, consultez la section sur les règles d'inclusion/exclusion de la page de manuel de la commande rsync.

Les fichiers trop volumineux pour être inclus dans l'image Docker seront regroupés dans le fichier YAML. Les fichiers dont la taille dépasse 1 Go seront signalés. Les images Docker trop volumineuses ou supérieures à 15 Go risquent d'échouer pendant la migration.

Vous pouvez modifier la liste YAML pour ajouter ou supprimer des chemins. Consultez un exemple de code YAML ci-dessous, qui inclut des exemples d'exclusions, ainsi que des notifications pour les fichiers volumineux et creux. Suivez les instructions intégrées pour choisir l'une des options suivantes:

Exclure les dossiers détectés en annulant la mise en commentaire et en les plaçant dans la section "Filtres globaux".
Déplacer les dossiers détectés vers un volume persistant en annulant la mise en commentaire et en les plaçant dans la section "Dossier de données".

Vous pouvez également envisager d'exclure ou de déplacer les fichiers fragmentés détectés de la même manière.

  global:
    # Files and directories to exclude from the migration, in rsync format.
    filters:
      - "- *.swp"
      - "- /etc/fstab"
      - "- /boot/"
      - "- /tmp/*"
      - "- /var/log/*.log*"
      - "- /var/log/*/*.log*"
      - "- /var/cache/*"

    ## The data folders below are too large to be included in the docker image.
    ## Consider uncommenting and placing them under either the global filters
    ## or the data folder section.
      # - '- /a' # (1.8GB, last access 2022-02-02 10:50:30, last modified 2020-02-02 10:50:30)
      # - '- /a/c' # (1.8GB, last access 2022-02-02 10:50:30, last modified 2020-02-02 10:50:30)

    ## Sparse files will fail the run of a docker image. Consider excluding the below
    ## detected files and any other sparse files by uncommenting and placing them in
    ## the global filters section, or export them to a persistent volume by specifying
    ## them in the data folder section.
      # - '- /a/b' # (1.8GB, last access 2022-02-02 10:50:30, last modified 2020-02-02 10:50:30)
      # - '- /a/d' # (1.8GB, last access 2022-02-02 10:50:30, last modified 2020-02-02 10:50:30)

Définir le nom de l'image de conteneur

La valeur du champ image définit le nom et l'emplacement de deux images créées à partir d'une VM migrée. Vous pouvez modifier ces valeurs si vous préférez utiliser d'autres noms.

Pendant la migration, Migrate to Containers copie les fichiers et les répertoires représentant votre charge de travail de migration vers Container Registry (par défaut) pour les utiliser lors de la migration. Le processus de migration adapte la charge de travail extraite à une image exécutable sur GKE.

Migrate to Containers conserve les fichiers et les répertoires de la VM d'origine (au niveau du chemin base) dans le registre. Cette image fonctionne comme une couche de base non exécutable qui inclut les fichiers de charge de travail extraits, qui sont ensuite associés à la couche logicielle de l'environnement d'exécution Migrate to Containers pour créer une image de conteneur exécutable.

L'utilisation de couches distinctes simplifie les mises à jour ultérieures de l'image de conteneur en autorisant des mises à jour distinctes de la couche de base ou de la couche logicielle Migrate to Containers, selon les besoins.

Cette image n'est pas exécutable, mais elle permet à Migrate to Containers de mettre à jour le conteneur à partir de l'original lors de la mise à jour de Migrate to Containers.

Les valeurs des champs base et name spécifient les images créées dans le registre.

base : nom de l'image créée à partir des fichiers et répertoires de VM copiés depuis la plate-forme source. Cette image ne peut pas être exécutée sur GKE, car elle n'a pas été adaptée pour le déploiement à cet emplacement.
name : nom de l'image exécutable utilisée pour le conteneur. Cette image inclut à la fois le contenu de la VM source et l'environnement d'exécution Migrate to Containers qui permet son exécution.

        image:
          # Review and set the name for extracted non-runnable base image,
          # if an image tag is not specified, a random tag is auto-generated when the image is built.
          base: "centos-mini-non-runnable-base"

          # Review and set the name for runnable container image,
          # if an image tag is not specified, a random tag is auto-generated when the image is built.
          name: "centos-mini"

Par défaut, un tag correspondant à l'horodatage de la migration est automatiquement appliqué à ces valeurs. Ce tag se présente au format suivant :

MM-DD-YYYY--hh:mm:ss

Pour appliquer votre propre tag et remplacer le tag par défaut, modifiez la CRD et ajoutez-la comme indiqué ci-dessous :

        image:
          # Review and set the name for extracted non-runnable base image,
          # if an image tag is not specified, a random tag is auto-generated when the image is built.
          base: "centos-mini-non-runnable-base:tag"

          # Review and set the name for runnable container image,
          # if an image tag is not specified, a random tag is auto-generated when the image is built.
          name: "centos-mini:tag"

Personnaliser la liste des services

Par défaut, Migrate to Containers désactive les services inutiles présents sur une VM en cas de migration vers un conteneur. Ces services peuvent parfois entraîner des problèmes au niveau du conteneur migré, ou ils ne sont pas nécessaires dans le contexte du conteneur.

Outre les services désactivés automatiquement par Migrate to Containers, vous pouvez désactiver d'autres services si vous le souhaitez :

Migrate to Containers détecte automatiquement les services que vous pouvez éventuellement désactiver et les répertorie dans le plan de migration. Ces services, tels que ssh ou un serveur Web, peuvent ne pas être requis dans votre charge de travail migrée, mais il vous incombe de prendre cette décision. Si nécessaire, modifiez le plan de migration pour désactiver ces services.
Migrate to Containers ne répertorie pas tous les services exécutés sur la VM source. Par exemple, il omet les services liés au système d'exploitation. Vous pouvez éventuellement modifier le plan de migration pour ajouter votre propre liste de services à désactiver dans le conteneur migré.

Le champ systemServices spécifie la liste des services détectés par Migrate to Containers. Exemple :

    systemServices:
    - enabled: true|false
      name: service-name
      probed: true|false
    - enabled: true|false
      name: service-name
      probed: true|false
      ...

Pour désactiver un service, définissez l'option enabled sur false.

Migrate to Containers ne répertorie pas tous les services exécutés sur la VM source, tels que les services liés au système d'exploitation. Vous pouvez également y ajouter d'autres services. Par exemple, pour désactiver service2 et le service cron, procédez comme suit :

    systemServices:
    - enabled: true
      name: service1
      probed: false
    - enabled: false
      name: service2
      probed: false
    - enabled: false
      name: cron
      probed: false

Lorsque vous exécutez une migration pour générer les artefacts de migration, Migrate to Containers crée le fichier blocklist.yaml. Ce fichier répertorie les services de conteneurs à désactiver en fonction de vos paramètres dans le plan de migration. Exemple :

service_list:
- name: disabled-services
  services:
  # Because you used systemServices above to disabled service2 and cron:
  - service2
  - cron

Pour modifier ultérieurement la liste des services désactivés, procédez comme suit :

Modifiez la liste des services du plan de migration.
Exécutez la migration pour générer à nouveau les artefacts de migration, y compris les fichiers blocklist.yaml, deployment_spec.yaml et Dockerfile mis à jour.

Après avoir exécuté une migration pour générer les artefacts de migration, vous pouvez également modifier directement le fichier blocklist.yaml, puis recompiler et transférer l'image de conteneur vous-même. Exemple :

Mettez à jour le fichier blocklist.yaml.
Recompilez et transférez l'image du conteneur.

La manière dont vous recompilez et transférez l'image de conteneur dépend de votre environnement de compilation. Vous pouvez indiquer :
1. gcloud pour recompiler l'image et la transférer vers Container Registry, comme décrit dans le Guide de démarrage rapide : compilation.
2. docker build, comme décrit sur la page Build and run your image (Compiler et exécuter votre image).
Après avoir recompilé et transféré la nouvelle image, ouvrez le fichier deployment_spec.yaml dans un éditeur pour mettre à jour son emplacement :
```
spec:
 containers:
   - image: new-image-location
```
Par exemple, new-image-location pourrait être my-new-image:v1.0 si vous avez utilisé gcloud pour recompiler l'image et la transférer vers Container Registry.

Personnaliser des points de terminaison de service

Le plan de migration inclut le tableau endpoints qui définit les ports et les protocoles utilisés pour créer les services Kubernetes fournis par la charge de travail migrée. Vous pouvez ajouter, modifier ou supprimer des définitions de points de terminaison pour personnaliser le plan de migration.

Pour chaque point de terminaison de service, ajoutez la définition suivante au plan de migration :

    endpoints:
    - port: PORT_NUMBER
      protocol: PORT_PROTOCOL
      name: PORT_NAME

Où :

PORT_NUMBER spécifie le numéro de port du conteneur vers lequel les requêtes adressées au service sont acheminées.
PORT_PROTOCOL spécifie le protocole de port, tel que HTTP, HTTPS ou TCP. Pour obtenir la liste complète des protocoles, consultez la section Protocoles pris en charge.
PORT_NAME spécifie le nom utilisé pour accéder au point de terminaison du service. Migrate to Containers génère une valeur PORT_NAME unique pour chaque définition de point de terminaison générée.

Par exemple, Migrate to Containers détecte les points de terminaison suivants :

  endpoints:
    - port: 80
      protocol: HTTP
      name: backend-server-nginx
    - port: 6379
      protocol: TCP
      name: backend-server-redis

Pour définir la valeur de la propriété name, Migrate to Containers combine le nom de la VM source, backend-server dans cet exemple, avec le nom du programme du service. Les noms générés sont compatibles avec les conventions de nommage Kubernetes et sont uniques dans le plan de migration. Par exemple, le plan de migration ci-dessus crée un service qui cible Nginx sur le port 80 via HTTP.

Pour les noms en double, Migrate to Containers ajoute un suffixe de compteur. Par exemple, si Nginx est associé à deux ports, le suffixe -2 est ajouté à name dans la deuxième définition :

  endpoints:
    - port: 80
      protocol: HTTP
      name: backend-server-nginx
    - port: 8080
      protocol: HTTPS
      name: backend-server-nginx-2
    - port: 6379
      protocol: TCP
      name: backend-server-redis

Lorsque vous exécutez une migration pour générer les artefacts de migration, Migrate to Containers crée une définition de service dans le fichier deployment_spec.yaml pour chaque point de terminaison.

L'exemple ci-dessous présente une définition Service dans le fichier deployment_spec.yaml :

apiVersion: v1
kind: Service
metadata:
  creationTimestamp: null
  name: backend-server-nginx
spec:
  ports:
  - port: 80
    protocol: HTTP
    targetPort: 80
  selector:
    app: backend-server
status:
  loadBalancer: {}

Personnaliser les installations NFS

Migrate to Containers inclut les installations NFS dans le plan de migration généré. Ces informations sont collectées à partir du fichier fstab et écrites dans le tableau nfsMounts du plan de migration. Vous pouvez ajouter ou modifier des définitions de points d'installation NFS pour personnaliser le plan de migration.

Lors de la génération du plan de migration, Migrate to Containers :

Ignore les installations NFS pour /sys et /dev.
Ignore les installations NFS d'un type autre que nfs ou nfs4.

Chaque installation NFS du plan de migration inclut l'adresse IP et le chemin d'accès local du serveur au format suivant :

    nfsMounts:
    - mountPoint: MOUNT_POINT
      exportedDirectory: DIR_NAME
      nfsServer: IP
      mountOptions:
         - OPTION_1
         - OPTION_2
      enabled: false|true

Où :

MOUNT_POINT spécifie le point d'installation obtenu de la commande fstab.
DIR_NAME spécifie le nom du répertoire partagé.
IP spécifie l'adresse IP du serveur qui héberge le point d'installation.
OPTION_N spécifie les options extraites de fstab pour le point d'installation.

Par exemple, pour l'entrée suivante dans fstab :

<file system>       <mount point>   <type>  <options>   <dump>  <pass>
10.49.232.26:/vol1  /mnt/test       nfs     rw,hard     0       0

Migrate to Containers génère l'entrée suivante dans le plan de migration :

    nfsMounts:
    - mountPoint: /mnt/test
      exportedDirectory: /vol1
      nfsServer: 10.49.232.26
      mountOptions:
         - rw
         - hard
      enabled: false

Pour configurer Migrate to Containers afin de traiter les entrées du tableau nfsMounts, définissez enabled sur true pour l'entrée mountPoint. Vous pouvez activer une, plusieurs ou toutes les entrées mountPoints, modifier les entrées ou ajouter vos propres entrées.

Lorsque vous exécutez une migration pour générer les artefacts de migration, Migrate to Containers crée une définition volumes et volumeMounts, ainsi qu'une définition PersistentVolume et PersistentVolumeClaim dans le fichier deployment_spec.yaml pour chaque installation NFS activée.

L'exemple ci-dessous présente une définition volumeMounts dans le fichier deployment_spec.yaml :

    spec:
      containers:
          - image: gcr.io/myimage-1/image-name
            name: some-app
            volumeMounts:
                   - mountPath: /sys/fs/cgroup
                     name: cgroups
                   - mountPath: /mnt/test
                     name: nfs-pv

Où la valeur de name est un identifiant unique généré par Migrate to Containers.

Vous trouverez ci-dessous des exemples de définitions des éléments PersistentVolumeClaim et PersistentVolume dans le fichier deployment_spec.yaml :

apiVersion: v1
kind: PersistentVolumeClaim
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 1Mi
  storageClassName: ""
  volumeName: nfs-pv

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-pv
spec:
  mountOptions:
    - rw
    - hard
  nfs:
    path: /vol1
    server: 10.49.232.26

Personnaliser les données de journaux écrites dans Cloud Logging

En règle générale, une VM source écrit des informations dans un ou plusieurs fichiers journaux. Dans le cadre de la migration de la VM, vous pouvez configurer la charge de travail migrée pour qu'elle écrive ces informations de journal dans Cloud Logging.

Lorsque vous générez le plan de migration, Migrate to Containers recherche automatiquement les fichiers de destination des journaux sur la VM source. Migrate to Containers écrit ensuite des informations portant sur ces fichiers détectés dans la zone logPaths du plan de migration :

deployment:
    ...
    logPaths:
    - appName: APP_NAME
      globs:
      - LOG_PATH

Exemple :

deployment:
    ...
    logPaths:
    - appName: tomcat
      globs:
      - /var/log/tomcat*/catalina.out

Lorsque vous générez les artefacts de migration, Migrate to Containers génère le fichier logs.yaml à partir du plan de migration. Ce fichier contient la liste des fichiers journaux détectés sur la VM source. Par exemple, à partir de la définition logsPath ci-dessus, logs.yaml contient :

logs:
  tomcat:
  - /var/log/tomcat*/catalina.out

Dans cet exemple, lorsque vous déployez la charge de travail migrée, les informations de journal écrites dans catalina.out sont automatiquement écrites dans Cloud Logging.

Chaque entrée apparaît sur une ligne du journal sous la forme suivante :

DATE TIME APP_NAME LOG_OUTPUT

L'exemple ci-dessous montre à quoi ressemble une entrée provenant de Tomcat :

2019-09-22 12:43:08.681193976 +0000 UTC tomcat log-output

Pour configurer la journalisation, vous pouvez choisir parmi les deux options suivantes :

Modifier le plan de migration avant de générer les artefacts de migration pour ajouter, supprimer ou modifier des entrées logPaths. Lorsque vous générez les artefacts de migration, ces modifications sont reflétées dans le fichier logs.yaml.
Modifier logs.yaml après avoir généré les artefacts de migration pour ajouter, supprimer ou modifier des entrées logs.

L'avantage de modifier le plan de migration est que vos modifications sont reflétées dans logs.yaml chaque fois que vous générez les artefacts. Si vous modifiez directement logs.yaml, puis générez à nouveau les artefacts pour une raison quelconque, vous devez réappliquer vos modifications à logs.yaml.

Définir les vérifications d'état Linux v2kServiceManager

Vous pouvez surveiller l'état d'arrêt et l'état de préparation de vos conteneurs gérés en spécifiant des vérifications dans le plan de migration de votre serveur Web Tomcat. La surveillance de l'état peut réduire les temps d'arrêt des conteneurs migrés et améliorer la surveillance.

Des états de santé inconnus peuvent entraîner une dégradation des disponibilités, une surveillance des disponibilités suggérant un faux positif et une perte potentielle de données. Sans vérification d'état, kubelet ne peut supposer que l'état d'un conteneur et peut envoyer du trafic vers une instance de conteneur qui n'est pas prête. Cela peut entraîner une perte de trafic. Kubelet peut également ne pas détecter les conteneurs dans un état figé et ne les redémarrera pas.

Une vérification de l'état fonctionne en exécutant une petite instruction scriptée au démarrage du conteneur. Le script recherche les conditions de réussite, qui sont définies par le type de vérification utilisé, à chaque période. La période est définie dans le plan de migration par un champ periodSeconds. Vous pouvez exécuter ou définir ces scripts manuellement.

Pour en savoir plus sur les vérifications de kubelet, consultez la section Configurer des vérifications d'activité, d'aptitude et de démarrage dans la documentation de Kubernetes.

Vous pouvez configurer deux types de vérifications : les deux vérifications sont constituées de la vérification vérificateur v1-cœur définie dans la documentation de référence de vérification-v1-cœur et partagent la même fonction que les champs correspondants de container-v1-cœur

Vérification d'activité : les vérifications d'activité permettent de savoir quand redémarrer un conteneur.

Remarque : Si un processus de votre conteneur peut planter seul lorsqu'il rencontre un problème ou s'il n'est plus opérationnel, vous n'avez pas besoin d'une vérification d'activité. Le kubelet effectuera automatiquement l'action appropriée conformément au restartPolicy du pod.

Vérification d'aptitude : les vérifications d'aptitude permettent de savoir quand un conteneur est prêt à accepter du trafic. Pour commencer à envoyer du trafic à un pod uniquement lorsqu'une vérification réussit, spécifiez une vérification d'aptitude. Une vérification d'aptitude peut agir de la même manière qu'une vérification d'activité, mais une vérification d'aptitude indiquée dans les spécifications indique qu'un pod démarre sans recevoir de trafic et ne commence à recevoir du trafic qu'une fois la vérification réussie.

Une fois la détection effectuée, la configuration de la vérification est ajoutée au plan de migration. Les vérifications peuvent être utilisées dans leur configuration par défaut, comme indiqué ci-dessous. Pour désactiver les vérifications, supprimez la section probes du fichier yaml.

v2kServiceManager: true
deployment:
  probes:
    livenessProbe:
      exec:
        command:
        - gamma
        - /probe

    readinessProbe:
      exec:
        command:
        - gamma
        - /probe
      initialDelaySeconds: 60
      periodSeconds: 5

image:
  # Disable system services that do not need to be executed at the migrated workload containers.
  # Enable the 'probed' property to include system services in the container health checks.
  systemServices:
  - enabled: true
    name: apache2
    probed: true
  - enabled: true
    name: atd
    probed: false

Par défaut, toutes les vérifications de service sont désactivées. Vous devez définir le sous-ensemble de services qui sera surveillé.

Il existe quatre méthodes prédéfinies pour vérifier un conteneur à l'aide d'une vérification. Chaque vérification doit définir exactement l'un de ces quatre mécanismes :

exec : exécute une commande spécifiée dans le conteneur. L'exécution est considérée comme réussie si le code d'état de sortie est 0.
grpc : effectue un appel de procédure à distance à l'aide de gRPC. Les vérifications "gRPC" sont une fonctionnalité alpha.
httpGet : exécute une requête HTTP GET sur l'adresse IP du pod sur un port et un chemin d'accès spécifiés. La requête est considérée comme réussie si le code d'état est supérieur ou égal à 200 et inférieur à 400.
tcpSocket : effectue une vérification TCP sur l'adresse IP du pod sur un port spécifié. Le diagnostic est considéré comme réussi si le port est ouvert.

Par défaut, un plan de migration active la méthode de vérification exec. Utilisez la configuration manuelle pour votre plan de migration afin d'activer une autre méthode.

Pour ajouter des dépendances externes pour la vérification d'aptitude tout en utilisant la vérification d'activité par défaut, définissez une vérification d'aptitude d'exécution et un script qui met en œuvre la logique.

Étapes suivantes

Découvrez comment exécuter la migration.