Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
Lista de anunciantes bloqueados de servicios personalizados
De forma predeterminada, Migrate to Containers inhabilita los servicios que no son necesarios en una VM cuando la migras a un contenedor. A veces, estos servicios pueden causar problemas con el contenedor migrado o no son necesarios en un contexto de contenedor.
También puedes definir tu propia lista personalizada de servicios que inhabilitar en un contenedor migrado con una lista personalizada de entidades bloqueadas. Con una lista de entidades bloqueadas, se especifican uno o más servicios para inhabilitarlos en un contenedor migrado.
Define la lista de entidades bloqueadas
Define tu lista de entidades bloqueadas personalizada en un archivo .yaml, de la siguiente manera:
Los grupos son un conjunto lógico de servicios para que puedas recopilar servicios similares en un solo grupo. Especifica cualquier valor de string para el nombre del grupo.
El nombre del servicio especifica el servicio que se va a inhabilitar en el contenedor migrado.
Por ejemplo, define el archivo my-blocklist.yaml de la siguiente manera:
Aplica una lista personalizada de entidades bloqueadas
Para aplicar tu lista de bloqueo personalizada a un contenedor, sigue estos pasos:
Crea un configmap de Kubernetes que contenga la lista de entidades bloqueadas y agrégala a la especificación de implementación del contenedor.
Este método te permite agregar la lista sin necesidad de volver a compilar el contenedor. Sin embargo, debes volver a crear el configmap en cada clúster que se usa para alojar el contenedor.
Edita el Dockerfile para el contenedor y vuelve a compilar la imagen del contenedor.
Este método requiere que vuelvas a compilar la imagen de contenedor para agregar la lista de entidades bloqueadas. Debido a que la lista ahora está incluida en el contenedor, no es necesario realizar ninguna configuración adicional en el clúster antes de la implementación.
Usa un configmap
Para crear una lista de entidades bloqueadas con un configmap, sigue estos pasos:
Migra la VM de origen a un contenedor.
Crea un archivo .yaml de lista de entidades bloqueadas de bloqueo, como se mostró antes, que enumere el servicio que deseas inhabilitar.
En este ejemplo, asigna un nombre al archivo my-blocklist.yaml.
Crea un configmap desde el archivo .yaml de bloqueo:
Agrega una variable de entorno nueva llamada HC_CUSTOM_SERVICE_BLOCKLIST que especifique la ruta al archivo .yaml de lista de entidades bloqueadas. El nombre de la variable de entorno debe ser HC_CUSTOM_SERVICE_BLOCKLIST:
La ruta de acceso especificada por el valor es la concatenación de mountPath del mapa de configuración y el nombre del archivo .yaml de lista de entidades bloqueadas, my-blocklist.yaml.
Guarda el archivo.
Implementa el contenedor:
kubectl apply -f deployment_spec.yaml
Después de implementar el contenedor, puedes examinarlo para asegurarte de que los servicios no se estén ejecutando. Por ejemplo:
# 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```
Edita el Dockerfile
En esta sección, se describe cómo crear una lista de entidades bloqueadas personalizada mediante la edición del Dockerfile creado por la migración.
Migra la VM de origen a un contenedor.
Abre el Dockerfile en un editor.
Agrega el siguiente comando COPY para agregar el archivo .yaml de la lista de entidades bloqueadas al sistema de archivos del contenedor:
La ruta de destino puede ser cualquier ruta dentro del contenedor.
Agrega una variable de entorno nueva llamada HC_CUSTOM_SERVICE_BLOCKLIST que especifique la ruta al archivo .yaml de lista de entidades bloqueadas según el destino del archivo que especifique el comando COPY. El nombre de la variable de entorno debe ser HC_CUSTOM_SERVICE_BLOCKLIST:
Después de compilar la imagen nueva, abre el archivo deployment_spec.yaml en un editor para actualizar la ubicación de la imagen:
spec:
containers:
- image: new-image-location
Por ejemplo, new-image-location podría ser gcr.io/my-project/my-new-image:v1.0 si usaste gcloud para compilar la imagen y subirla a Container Registry.
Implementa el contenedor:
kubectl apply -f deployment_spec.yaml
Después de implementar el contenedor, puedes examinarlo para asegurarte de que los servicios no se estén ejecutando. Por ejemplo:
# 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
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Información o código de muestra incorrectos","incorrectInformationOrSampleCode","thumb-down"],["Faltan la información o los ejemplos que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 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"]]
