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 page 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éé un plan de migration et que vous disposez du fichier de plan de migration qui en résulte.

Modifier le plan de migration

Une fois le système de fichiers copié et analysé, vous trouverez le plan de migration dans le nouveau répertoire qui est créé dans le chemin de sortie spécifié : ANALYSIS_OUTPUT_PATH/config.yaml.

Modifiez le plan de migration si nécessaire et enregistrez les modifications.

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

En savoir plus sur les règles de filtre rsync.

Les fichiers trop volumineux pour être inclus dans l'image Docker sont listé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 l'instruction intégrée pour effectuer l'une des actions 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 exclure ou 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 name de la section image définit le nom de l'image créée à partir d'une VM migrée qui est utilisée pour le conteneur. Vous pouvez modifier cette valeur si vous préférez utiliser un autre nom.

image:
     # Review and set the name for runnable container image.
     name: linux-system

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. Par 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. Par 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 un fichier blocklist.yaml 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 créer et déployer l'image de conteneur à l'aide de Skaffold.

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 récupérer les ports de points de terminaison, vérifiez les programmes qui écoutent les ports :

sudo netstat --programs --listening --tcp --udp [--sctp]

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

Par 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 définies par probe-v1-core dans la documentation de référence de probe-v1-core et partagent la même fonction que les champs correspondants de container-v1-core.

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

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

deployment:
  probes:
    livenessProbe:
      exec:
        command:
        - /ko-app/service-manager-runtime
        - /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.

Étape suivante