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.
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 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
ounfs4
.
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 fichierlogs.yaml
.Modifier
logs.yaml
après avoir généré les artefacts de migration pour ajouter, supprimer ou modifier des entréeslogs
.
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
- Découvrez comment exécuter la migration.