Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Liste de blocage des services personnalisés
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.
Vous pouvez également définir votre propre liste de services à désactiver dans un conteneur migré à l'aide d'une liste de blocage personnalisée. Avec une liste de blocage, vous pouvez spécifier un ou plusieurs services à désactiver dans un conteneur migré.
Définir la liste de blocage
Définissez votre liste de blocage personnalisée dans un fichier .yaml, au format suivant :
Les groupes sont des ensembles de services logiques qui vous permettent de collecter des services similaires dans un groupe unique. Indiquez une valeur de chaîne pour le nom du groupe.
Le nom du service spécifie le service à désactiver dans le conteneur migré.
Par exemple, définissez le fichier my-blocklist.yaml comme suit :
Appliquez votre liste de blocage personnalisée à un conteneur de l'une des manières suivantes :
Créez une ressource Kubernetes configmap contenant la liste de blocage et ajoutez-la à la spécification de déploiement du conteneur.
Cette méthode vous permet d'ajouter la liste de blocage sans avoir à recréer le conteneur. Vous devez toutefois recréer configmap sur chaque cluster utilisé pour héberger le conteneur.
Modifiez le fichier Dockerfile du conteneur et recréez l'image du conteneur.
Cette méthode nécessite de recréer l'image de conteneur pour ajouter la liste de blocage. La liste de blocage étant maintenant incluse dans le conteneur, il n'est pas nécessaire d'effectuer de configuration supplémentaire sur le cluster avant le déploiement.
Utiliser un fichier ConfigMap
Pour créer une liste de blocage à l'aide d'un fichier configmap, procédez comme suit :
Migrez la VM source vers un conteneur.
Créez un fichier .yaml de liste de blocage, comme indiqué ci-dessus, qui répertorie le service que vous souhaitez désactiver.
Dans cet exemple, nommez le fichier my-blocklist.yaml.
Créez un fichier configmap à partir du fichier .list de la liste de blocage :
Ajoutez une nouvelle variable d'environnement nommée HC_CUSTOM_SERVICE_BLOCKLIST spécifiant le chemin d'accès au fichier .yaml de la liste de blocage. Le nom de la variable d'environnement doit être HC_CUSTOM_SERVICE_BLOCKLIST :
Le chemin d'accès spécifié par la valeur est la concaténation des fichiers mountPath et ConfigMap et du nom du fichier .yaml de la liste de blocage, my-blocklist.yaml.
Enregistrez le fichier.
Déployez le conteneur :
kubectl apply -f deployment_spec.yaml
Une fois le conteneur déployé, vous pouvez l'examiner pour vous assurer que les services ne sont pas en cours d'exécution. Exemple :
# Get pod name.
$ kubectl get pod
# Connect to pod.
$ kubectl exec -it POD_NAME -- /bin/bash
# View running services. This step is OS dependent. For example:
$ service --status-all```
Modifier le fichier Dockerfile
Cette section décrit comment créer une liste de blocage personnalisée en modifiant le fichier Dockerfile créé par la migration.
Migrez la VM source vers un conteneur.
Ouvrez le fichier Dockerfile dans un éditeur.
Ajoutez la commande COPY suivante pour ajouter le fichier .yaml de la liste de blocage au système de fichiers du conteneur :
Le chemin de la destination peut être un chemin d'accès au sein du conteneur.
Ajoutez une variable d'environnement nommée HC_CUSTOM_SERVICE_BLOCKLIST spécifiant le chemin d'accès au fichier .yaml de la liste de blocage en vous basant sur la destination du fichier spécifiée par la commande COPY. Le nom de la variable d'environnement doit être HC_CUSTOM_SERVICE_BLOCKLIST :
Après avoir créé la nouvelle image, ouvrez le fichier deployment_spec.yaml dans un éditeur pour mettre à jour l'emplacement de l'image :
spec:
containers:
- image: new-image-location
Par exemple, new-image-location pourrait être gcr.io/my-project/my-new-image:v1.0 si vous avez utilisé gcloud pour créer l'image et l'avez importée dans Container Registry.
Déployez le conteneur :
kubectl apply -f deployment_spec.yaml
Une fois le conteneur déployé, vous pouvez l'examiner pour vous assurer que les services ne sont pas en cours d'exécution. Exemple :
# Get pod name.
$ kubectl get pod
# Connect to pod.
$ kubectl exec -it POD_NAME -- /bin/bash
# View running services. This step is OS dependent. For example:
$ service --status-all
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/09/04 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2025/09/04 (UTC)."],[],[],null,["# Custom services blocklist\n=========================\n\n| **Migrate to Containers version 1.7 added support\n| for defining custom blocklists by editing the migration plan. We recommend\n| that you now [use the migration plan](/migrate/containers/docs/customizing-a-migration-plan)\n| to define your custom blocklists.**\n\nBy default, Migrate to Containers [disables unneeded services](/migrate/containers/docs/planning-best-practices#disable_unneeded_services) on a VM when you migrate it to a container. These services can sometimes cause issues with the migrated container, or are not needed in a container context.\n\nYou can also define your own custom list of services to disable in a migrated container by using a custom *blocklist*. With a blocklist, you specify one or more services to disable in a migrated container.\n| **Note:** Add the custom blocklist to a container *after* migrating the source VM to a container. The custom blocklist is then applied to the container when you deploy the container.\n\nDefining the blocklist\n----------------------\n\nDefine your customized blocklist in a .yaml file, in the form: \n\n service_list:\n - name: \u003cvar\u003egroup-name-1\u003c/var\u003e\n services:\n - \u003cvar\u003eservice-name\u003c/var\u003e\n - name: \u003cvar\u003egroup-name-2\u003c/var\u003e\n services:\n - \u003cvar\u003eservice-name\u003c/var\u003e\n - \u003cvar\u003eervice-name\u003c/var\u003e\n\nWhere:\n\n- Groups are a logical collection of services so that you can collect similar services in a single group. Specify any string value for the group name.\n- The service name specifies the service to disable in the migrated container.\n\nFor example, define the file `my-blocklist.yaml` as: \n\n service_list:\n - name: lvm-related\n services:\n - lvm2-lvmetad\n - name: hardware-related\n services:\n - microcode\n - microcode.ctl\n\nApplying a custom blocklist\n---------------------------\n\nApply your custom blocklist to a container by either:\n\n- Creating a Kubernetes `configmap` containing the blocklist and adding it to the deployment spec of the container.\n\n This method lets you add the blocklist without having to rebuild the container. However, you have to recreate the `configmap` on every cluster used to host the container.\n- Edit the Dockerfile for the container and rebuild the container image.\n\n This method requires you to rebuild the container image to add the blocklist. Because the blocklist is now included in the container there is no need to perform any additional configuration on the cluster before deployment.\n\n### Using a configmap\n\nTo create a blocklist by using a `configmap`:\n\n1. Migrate the source VM to a container.\n\n2. Create a blocklist .yaml file as shown above that lists the service you want to disable.\n In this example, name the file `my-blocklist.yaml`.\n\n3. Create a `configmap` from the blocklist .yaml file:\n\n ```\n kubectl create configmap configmap-name --from-file=path-to-yaml\n ```\n\n In this example, the configmap is called `blocklistcm`: \n\n ```\n kubectl create configmap blocklistcm --from-file=./my-blocklist.yaml\n ```\n4. View the configmap:\n\n ```\n kubectl describe configmaps\n ```\n5. Edit the `deployment_spec.yaml` created when you migrated the container:\n\n ```\n vi deployment_spec.yaml\n ```\n6. In the deployment spec, add the following:\n\n 1. Add a new volume for the `configmap` under `volumes`:\n\n volumes:\n - configMap: \n name: blocklistcm # Name of the config map you created above. \n name: blocklistvol # Name of the configmap volume.\n\n 2. Add a volume mount for the configmap:\n\n spec:\n containers: \n volumeMounts: \n - mountPath: /etc/bl # Mount path for the configmap volume. \n name: blocklistvol # Name of the configmap volume. \n\n 3. Add a new environment variable named `HC_CUSTOM_SERVICE_BLOCKLIST` specifying the path to the blocklist .yaml file. The name of the environment variable is required to be `HC_CUSTOM_SERVICE_BLOCKLIST`:\n\n containers:\n - image: container-image-location\n env:\n - name: HC_CUSTOM_SERVICE_BLOCKLIST\n value: \"/etc/bl/my-blocklist.yaml\"\n\n The path specified by value is the concatenation of the mountPath of the configmap\n and the name of the blocklist .yaml file, `my-blocklist.yaml`.\n 4. Save the file.\n\n7. Deploy the container:\n\n ```\n kubectl apply -f deployment_spec.yaml\n ```\n8. After the container is deployed, you can then examine the container to ensure that the services are not running. For example:\n\n # Get pod name.\n $ kubectl get pod\n # Connect to pod.\n $ kubectl exec -it POD_NAME -- /bin/bash\n # View running services. This step is OS dependent. For example:\n $ service --status-all```\n\n### Editing the Dockerfile\n\nThis section describes how to create a custom blocklist by editing the Dockerfile created by the migration.\n\n1. Migrate the source VM to a container.\n\n2. Open the Dockerfile in an editor.\n\n3. Add the following `COPY` command to add the blocklist .yaml file to the filesystem of the container:\n\n ```text\n COPY src dest \n ```\n\n For example: \n\n ```text\n COPY my-blocklist.yaml /etc/mybl/my-blocklist.yaml\n ```\n\n The destination path can be any path within the container.\n4. Add a new environment variable named `HC_CUSTOM_SERVICE_BLOCKLIST` specifying the path to the blocklist .yaml file based on the file destination specified by the `COPY` command. The name of the environment variable is required to be `HC_CUSTOM_SERVICE_BLOCKLIST`:\n\n ```scdoc\n ENV HC_CUSTOM_SERVICE_BLOCKLIST /file-path\n ```\n\n For example: \n\n ```scdoc\n ENV HC_CUSTOM_SERVICE_BLOCKLIST /etc/mybl/my-blocklist.yaml\n ```\n5. Update the container image.\n\n The way you update the container image depends on your build environment. You can use:\n 1. `gcloud` to build the image and upload it to the Container Registry as described at [Quickstart: Build](/build/docs/build-push-docker-image).\n\n 2. `docker build` as described at [Build and run your image](https://docs.docker.com/get-started/part2/)\n .\n\n6. After you build the new image, open the `deployment_spec.yaml` file in an editor to update the image location:\n\n ```text\n spec:\n containers:\n - image: new-image-location\n ```\n\n For example, \u003cvar translate=\"no\"\u003enew-image-location\u003c/var\u003e could be `gcr.io/my-project/my-new-image:v1.0`\n if you used `gcloud` to build the image and uploaded it to the Container Registry.\n7. Deploy the container:\n\n ```\n kubectl apply -f deployment_spec.yaml\n ```\n8. After the container is deployed, you can then examine the container to ensure that the services are not running. For example:\n\n # Get pod name.\n $ kubectl get pod\n # Connect to pod.\n $ kubectl exec -it POD_NAME -- /bin/bash\n # View running services. This step is OS dependent. For example:\n $ service --status-all"]]
