값으로 지정된 경로는 configmap의 mountPath와 blocklist .yaml 파일 이름인 my-blocklist.yaml을 연결한 것입니다.
파일을 저장합니다.
컨테이너를 배포합니다.
kubectl apply -f deployment_spec.yaml
컨테이너 배포 후 컨테이너를 조사하여 서비스가 실행 중이 아닌지 확인할 수 있습니다. 예를 들면 다음과 같습니다.
# 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```
Dockerfile 수정
이 섹션에서는 마이그레이션으로 만들어진 Dockerfile을 편집하여 커스텀 차단 목록을 만드는 방법을 설명합니다.
소스 VM을 컨테이너에 마이그레이션합니다.
편집기에서 Dockerfile을 엽니다.
다음 COPY 명령어를 추가하여 컨테이너의 파일 시스템에 차단 목록 .yaml 파일을 추가합니다.
새 이미지를 빌드한 후 편집기에서 deployment_spec.yaml 파일을 열어 이미지 위치를 업데이트합니다.
spec:
containers:
- image: new-image-location
예를 들어 gcloud를 사용하여 이미지를 빌드하고 Container Registry에 업로드한 경우 new-image-location이 gcr.io/my-project/my-new-image:v1.0일 수 있습니다.
컨테이너를 배포합니다.
kubectl apply -f deployment_spec.yaml
컨테이너 배포 후 컨테이너를 조사하여 서비스가 실행 중이 아닌지 확인할 수 있습니다. 예를 들면 다음과 같습니다.
# 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
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 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"]]
