Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Lista de bloqueio de serviços personalizados
Por padrão, o Migrate to Containers desativa os serviços desnecessários em uma VM quando ela é migrada para um contêiner. Esses serviços às vezes podem causar problemas no contêiner migrado ou não são necessários em um contexto de contêiner.
Também é possível definir sua própria lista personalizada de serviços que será desativada em um contêiner migrado usando uma lista de bloqueio personalizada. Com uma lista de bloqueio, você especifica um ou mais serviços a serem desativados no contêiner migrado.
Como definir a lista de bloqueio
Defina sua lista de bloqueio personalizada em um arquivo .yaml no formulário:
Grupos são uma coleção lógica de serviços para que você possa coletar serviços semelhantes em um único grupo. Especifique qualquer valor de string para o nome do grupo.
O nome do serviço especifica o serviço a ser desativado no contêiner migrado.
Por exemplo, defina o arquivo my-blocklist.yaml como:
Aplique sua lista de bloqueio personalizada a um contêiner:
Como criar um configmap do Kubernetes que contenha a lista de bloqueio e adicioná-lo à especificação de implantação do contêiner.
Esse método permite que você adicione a lista de bloqueio sem ter que recriar o contêiner. No entanto, é necessário recriar o configmap em todos os clusters usados para hospedar o contêiner.
Edite o Dockerfile do contêiner e recrie a imagem.
Esse método requer que você recrie a imagem do contêiner para adicionar a lista de bloqueio. Como a lista de bloqueio agora está incluída no contêiner, não é necessário executar outras configurações no cluster antes da implantação.
Como usar um configmap
Para criar uma lista de bloqueio usando um configmap:
Migre a VM de origem para um contêiner.
Crie um arquivo .yaml de lista de bloqueio, conforme mostrado acima, que lista o serviço que você quer desativar.
Neste exemplo, nomeie o arquivo my-blocklist.yaml.
Crie um configmap a partir do arquivo .yaml de lista de bloqueio:
Adicione uma nova variável de ambiente chamada HC_CUSTOM_SERVICE_BLOCKLIST especificando o caminho para o arquivo .yaml de lista de bloqueio. O nome da variável de ambiente precisa ser HC_CUSTOM_SERVICE_BLOCKLIST:
O caminho especificado por valor é a concatenação do mountPath do configmap
e do nome do arquivo .yaml de lista de bloqueio, my-blocklist.yaml.
Salve o arquivo.
Implantar o contêiner:
kubectl apply -f deployment_spec.yaml
Depois que o contêiner for implantado, examine-o para garantir que os serviços não estarão em execução. Exemplo:
# 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```
Como editar o Dockerfile
Esta seção descreve como criar uma lista de bloqueio personalizada editando o Dockerfile criado pela migração.
Migre a VM de origem para um contêiner.
Abra o Dockerfile em um editor.
Adicione o seguinte comando COPY para adicionar o arquivo .yaml de lista de bloqueio ao sistema de arquivos do contêiner:
O caminho de destino pode ser qualquer caminho dentro do contêiner.
Adicione uma nova variável de ambiente chamada HC_CUSTOM_SERVICE_BLOCKLIST especificando o caminho para o arquivo .yaml de lista de bloqueio com base no destino do arquivo especificado pelo comando COPY. O nome da variável de ambiente precisa ser HC_CUSTOM_SERVICE_BLOCKLIST:
Depois de criar a nova imagem, abra o arquivo deployment_spec.yaml em um editor para atualizar o local da imagem:
spec:
containers:
- image: new-image-location
Por exemplo, new-image-location pode ser gcr.io/my-project/my-new-image:v1.0,
se você usou gcloud para criar a imagem e enviá-la ao Container Registry.
Implantar o contêiner:
kubectl apply -f deployment_spec.yaml
Depois que o contêiner for implantado, examine-o para garantir que os serviços não estarão em execução. Exemplo:
# 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 entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-08-19 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"]]