Esta página se ha traducido con Cloud Translation API.

Lista de servicios personalizados bloqueados

De forma predeterminada, Migrate to Containers inhabilita los servicios innecesarios 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 quieras inhabilitar en un contenedor migrado mediante una lista de bloqueo personalizada. Con una lista de bloqueo, puedes especificar uno o varios servicios que quieras inhabilitar en un contenedor migrado.

Definir la lista de bloqueo

Define tu lista de bloqueo personalizada en un archivo .yaml con el siguiente formato:

service_list:
  - name: <var>group-name-1</var>
    services:
      - <var>service-name</var>
  - name: <var>group-name-2</var>
    services:
      - <var>service-name</var>
      - <var>ervice-name</var>

Donde:

Los grupos son una colección lógica de servicios que te permite reunir servicios similares en un solo grupo. Especifica cualquier valor de cadena 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:

service_list:
  - name: lvm-related
    services:
      - lvm2-lvmetad
  - name: hardware-related
    services:
      - microcode
      - microcode.ctl

Aplicar una lista de bloqueo personalizada

Para aplicar tu lista de bloqueo personalizada a un contenedor, puedes hacer lo siguiente:

Crear un configmap de Kubernetes que contenga la lista de bloqueo y añadirlo a la especificación de despliegue del contenedor.

Este método te permite añadir la lista de bloqueo sin tener que volver a crear el contenedor. Sin embargo, debes volver a crear el configmap en cada clúster que se use para alojar el contenedor.
Edita el Dockerfile del contenedor y vuelve a compilar la imagen del contenedor.

Para usar este método, debes volver a compilar la imagen del contenedor para añadir la lista de bloqueo. Como la lista de bloqueo ahora está incluida en el contenedor, no es necesario realizar ninguna configuración adicional en el clúster antes de la implementación.

Usar un configmap

Para crear una lista de bloqueo con un configmap, sigue estos pasos:

Migra la VM de origen a un contenedor.
Crea un archivo .yaml de lista de bloqueo como se muestra arriba que incluya el servicio que quieras inhabilitar. En este ejemplo, el archivo se llama my-blocklist.yaml.

Crea un configmap a partir del archivo .yaml de la lista de bloqueo:

kubectl create configmap configmap-name --from-file=path-to-yaml

En este ejemplo, el configmap se llama blocklistcm:

kubectl create configmap blocklistcm --from-file=./my-blocklist.yaml

Consulta el configmap:
```
kubectl describe configmaps
```
Edita el deployment_spec.yaml creado al migrar el contenedor:
```
vi deployment_spec.yaml
```
En la especificación de la implementación, añade lo siguiente:
1. Añade un nuevo volumen para configmap en volumes:
```
volumes:
- configMap: 
     name: blocklistcm # Name of the config map you created above. 
   name: blocklistvol # Name of the configmap volume.
```
2. Añade un montaje de volumen para el configmap:
```
spec:
  containers: 
    volumeMounts: 
    - mountPath: /etc/bl # Mount path for the configmap volume. 
      name: blocklistvol # Name of the configmap volume. 
```
3. Añade una variable de entorno llamada HC_CUSTOM_SERVICE_BLOCKLIST que especifique la ruta al archivo .yaml de la lista de bloqueo. El nombre de la variable de entorno debe ser HC_CUSTOM_SERVICE_BLOCKLIST:
```
containers:
 - image: container-image-location
   env:
   - name: HC_CUSTOM_SERVICE_BLOCKLIST
     value: "/etc/bl/my-blocklist.yaml"
```
  La ruta especificada por el valor es la concatenación de mountPath de configmap y el nombre del archivo .yaml de la lista de bloqueo, my-blocklist.yaml.
4. Guarda el archivo.
Despliega el contenedor:
```
kubectl apply -f deployment_spec.yaml
```

Una vez que se haya implementado el contenedor, podrá examinarlo para asegurarse 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```

Editar el archivo Dockerfile

En esta sección se describe cómo crear una lista de bloqueo personalizada editando el archivo Dockerfile creado por la migración.

Migra la VM de origen a un contenedor.
Abre el archivo Dockerfile en un editor.
Añade el siguiente comando COPY para añadir el archivo .yaml de la lista de bloqueo al sistema de archivos del contenedor:
```
COPY src dest 
```
Por ejemplo:
```
COPY my-blocklist.yaml /etc/mybl/my-blocklist.yaml
```
La ruta de destino puede ser cualquier ruta del contenedor.
Añade una variable de entorno llamada HC_CUSTOM_SERVICE_BLOCKLIST que especifique la ruta al archivo .yaml de la lista de bloqueo en función del destino del archivo especificado por el comando COPY. El nombre de la variable de entorno debe ser HC_CUSTOM_SERVICE_BLOCKLIST:
```
ENV HC_CUSTOM_SERVICE_BLOCKLIST /file-path
```
Por ejemplo:
```
ENV HC_CUSTOM_SERVICE_BLOCKLIST /etc/mybl/my-blocklist.yaml
```
Actualiza la imagen del contenedor.

La forma de actualizar la imagen del contenedor depende de tu entorno de compilación. Puedes usar:
1. gcloud para compilar la imagen y subirla a Container Registry, como se describe en la guía de inicio rápido sobre compilación.
2. docker build, tal como se describe en Compilar y ejecutar la imagen .
Después de crear la nueva imagen, 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 has usado gcloud para compilar la imagen y la has subido a Container Registry.
Despliega el contenedor:
```
kubectl apply -f deployment_spec.yaml
```

Una vez que se haya implementado el contenedor, podrá examinarlo para asegurarse 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