Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
Lista bloccata dei servizi personalizzati
Per impostazione predefinita, Migrate to Containers disattiva i servizi non necessari su una VM quando esegui la migrazione a un container. A volte questi servizi possono causare problemi con il contenitore di cui è stata eseguita la migrazione o non sono necessari in un contesto del contenitore.
Puoi anche definire un tuo elenco personalizzato di servizi da disattivare in un contenitore sottoposto a migrazione utilizzando una lista bloccata personalizzata. Con una lista bloccata, puoi specificare uno o più servizi da disattivare in un contenitore sottoposto a migrazione.
Definizione della lista bloccata
Definisci la lista bloccata personalizzata in un file .yaml, nel seguente formato:
I gruppi sono una raccolta logica di servizi che ti consente di raccogliere servizi simili in un unico gruppo. Specifica un valore di stringa per il nome del gruppo.
Il nome del servizio specifica il servizio da disattivare nel contenitore di cui è stata eseguita la migrazione.
Ad esempio, definisci il file my-blocklist.yaml come:
Applica la lista bloccata personalizzata a un contenitore:
Creare un configmap Kubernetes contenente la lista bloccata e aggiungerla alla specifica di deployment del contenitore.
Questo metodo ti consente di aggiungere la lista bloccata senza dover ricostruire il contenitore. Tuttavia, devi ricreare configmap su ogni cluster utilizzato per ospitare il contenitore.
Modifica il Dockerfile per il contenitore e ricostruisci l'immagine del contenitore.
Questo metodo richiede di ricostruire l'immagine del contenitore per aggiungere la lista bloccata. Poiché la lista bloccata è ora inclusa nel contenitore, non è necessario eseguire alcuna configurazione aggiuntiva sul cluster prima del deployment.
Utilizzo di un file configmap
Per creare una lista bloccata utilizzando un configmap:
Esegui la migrazione della VM di origine in un container.
Crea un file .yaml della lista bloccata come mostrato sopra che elenca il servizio che vuoi disattivare.
In questo esempio, assegna al file il nome my-blocklist.yaml.
Crea un configmap dal file .yaml della lista bloccata:
Aggiungi una nuova variabile di ambiente denominata HC_CUSTOM_SERVICE_BLOCKLIST che specifichi il percorso del file .yaml della lista bloccata. Il nome della variabile di ambiente deve essere HC_CUSTOM_SERVICE_BLOCKLIST:
Il percorso specificato per valore è la concatenazione del mountPath del configmap
e del nome del file .yaml della lista bloccata, my-blocklist.yaml.
Salva il file.
Esegui il deployment del contenitore:
kubectl apply -f deployment_spec.yaml
Dopo aver eseguito il deployment del contenitore, puoi esaminarlo per assicurarti che i servizi non siano in esecuzione. Ad esempio:
# 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```
Modifica del Dockerfile
Questa sezione descrive come creare una lista bloccata personalizzata modificando il file Dockerfile creato dalla migrazione.
Esegui la migrazione della VM di origine in un container.
Apri il file Dockerfile in un editor.
Aggiungi il seguente comando COPY per aggiungere il file .yaml della lista bloccata al file system del contenitore:
Il percorso di destinazione può essere qualsiasi percorso all'interno del contenitore.
Aggiungi una nuova variabile di ambiente denominata HC_CUSTOM_SERVICE_BLOCKLIST che specifica il percorso del file .yaml della lista bloccata in base alla destinazione del file specificata dal comando COPY. Il nome della variabile di ambiente deve essere HC_CUSTOM_SERVICE_BLOCKLIST:
Dopo aver creato la nuova immagine, apri il file deployment_spec.yaml in un editor per aggiornare la posizione dell'immagine:
spec:
containers:
- image: new-image-location
Ad esempio, new-image-location potrebbe essere gcr.io/my-project/my-new-image:v1.0
se hai utilizzato gcloud per creare l'immagine e l'hai caricata in Container Registry.
Esegui il deployment del contenitore:
kubectl apply -f deployment_spec.yaml
Dopo aver eseguito il deployment del contenitore, puoi esaminarlo per assicurarti che i servizi non siano in esecuzione. Ad esempio:
# 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
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Difficile da capire","hardToUnderstand","thumb-down"],["Informazioni o codice di esempio errati","incorrectInformationOrSampleCode","thumb-down"],["Mancano le informazioni o gli esempi di cui ho bisogno","missingTheInformationSamplesINeed","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 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"]]
