Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Sperrliste für benutzerdefinierte Dienste
Standardmäßig deaktiviert Migrate to Containers nicht benötigte Dienste auf einer VM, wenn Sie sie in einen Container migrieren. Diese Dienste können manchmal Probleme mit dem migrierten Container verursachen oder werden in einem Containerkontext nicht benötigt.
Sie können auch eine eigene benutzerdefinierte Liste mit Diensten definieren, die in einem migrierten Container mithilfe einer benutzerdefinierten Sperrliste deaktiviert werden sollen. Mit einer Sperrliste geben Sie einen oder mehrere Dienste an, die in einem migrierten Container deaktiviert werden sollen.
Sperrliste definieren
Legen Sie Ihre benutzerdefinierte Sperrliste in einer YAML-Datei im folgenden Format fest:
Gruppen sind eine logische Sammlung von Diensten, mit denen Sie ähnliche Dienste in einer einzigen Gruppe sammeln können. Geben Sie einen beliebigen Stringwert als Gruppennamen ein.
Der Dienstname gibt den Dienst an, der im migrierten Container deaktiviert werden soll.
Definieren Sie die Datei my-blocklist.yaml beispielsweise so:
Sie können Ihre benutzerdefinierte Sperrliste auf einen Container anwenden, indem Sie entweder:
einen Kubernetes-configmap mit der Sperrliste erstellen und der Bereitstellungsspezifikation des Containers hinzufügen.
Mit dieser Methode können Sie die Sperrliste hinzufügen, ohne den Container neu erstellen zu müssen. Sie müssen jedoch configmap auf jedem Cluster, der zum Hosten des Containers verwendet wird, neu erstellen.
das Dockerfile für den Container bearbeiten und das Container-Image neu erstellen.
Bei dieser Methode müssen Sie das Container-Image neu erstellen, um die Sperrliste hinzuzufügen. Da die Sperrliste jetzt im Container enthalten ist, müssen Sie vor der Bereitstellung keine weitere Konfiguration im Cluster vornehmen.
ConfigMaps verwenden
So erstellen Sie eine Sperrliste mithilfe eines configmap:
Migrieren Sie die Quell-VM zu einem Container.
Erstellen Sie eine Sperrlistendatei im .yaml-Format wie oben gezeigt, in der der Dienst aufgeführt ist, den Sie deaktivieren möchten.
In diesem Beispiel trägt die Datei den Namen my-blocklist.yaml.
Erstellen Sie configmap aus der Sperrliste im .yaml-Format:
Fügen Sie eine neue Umgebungsvariable mit dem Namen HC_CUSTOM_SERVICE_BLOCKLIST hinzu, die den Pfad zur Sperrliste im .yaml-Format angibt. Der Name der Umgebungsvariablen muss HC_CUSTOM_SERVICE_BLOCKLIST sein:
Der durch den Wert angegebene Pfad ist die Verkettung von mountPath der configmap und der Name der Sperrliste im .yaml-Format my-blocklist.yaml.
Speichern Sie die Datei.
Stellen Sie den Container bereit:
kubectl apply -f deployment_spec.yaml
Nachdem der Container bereitgestellt wurde, können Sie den Container prüfen, um sicherzustellen, dass die Dienste nicht ausgeführt werden. Beispiele:
# 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 bearbeiten
In diesem Abschnitt wird beschrieben, wie Sie eine benutzerdefinierte Sperrliste erstellen, indem Sie das von der Migration erstellte Dockerfile bearbeiten.
Migrieren Sie die Quell-VM zu einem Container.
Öffnen Sie das Dockerfile in einem Editor.
Fügen Sie den folgenden COPY-Befehl hinzu, um die Sperrliste im .yaml-Format dem Dateisystem des Containers hinzuzufügen:
Der Zielpfad kann ein beliebiger Pfad innerhalb des Containers sein.
Fügen Sie eine neue Umgebungsvariable namens HC_CUSTOM_SERVICE_BLOCKLIST hinzu, die den Pfad zur Sperrliste im .yaml-Format auf der Grundlage des im Befehl COPY angegebenen Dateiziels angibt. Der Name der Umgebungsvariablen muss HC_CUSTOM_SERVICE_BLOCKLIST sein:
Nachdem Sie das neue Image erstellt haben, öffnen Sie die Datei deployment_spec.yaml in einem Editor, um den Image-Speicherort zu aktualisieren:
spec:
containers:
- image: new-image-location
Beispiel: new-image-location könnte gcr.io/my-project/my-new-image:v1.0 sein, wenn Sie das Image mit gcloud erstellt und in Container Registry hochgeladen haben.
Stellen Sie den Container bereit:
kubectl apply -f deployment_spec.yaml
Nachdem der Container bereitgestellt wurde, können Sie den Container prüfen, um sicherzustellen, dass die Dienste nicht ausgeführt werden. Beispiele:
# 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
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-08-31 (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"]]
