Prepara un clúster de Linux para la implementación

En esta página, se describe cómo preparar tu clúster de destino para la implementación.

Antes de comenzar

En este documento, se supone que ya completaste la migración y que tienes los artefactos generados.

Asegúrate de que el clúster de destino tenga acceso de lectura al registro de Docker

Como parte de la migración, Migrate to Containers sube las imágenes de Docker que representan una VM migrada a un registro de Docker. Estas imágenes de Docker representan los archivos y directorios de la VM que se migra.

En el registro de Docker, puedes elegir usar lo siguiente:

Para obtener más información, consulta Define repositorios de datos.

Implementa una carga de trabajo en un proyecto de Google Cloud que no sea el que se usa para la migración

A menudo, tendrás varios proyectos de Google Cloud en tu entorno. Si realizas una migración en un proyecto de Google Cloud, pero luego deseas implementar la carga de trabajo migrada en un clúster alojado en un proyecto diferente, debes asegurarte de tener los permisos configurados correctamente.

Por ejemplo, si realizas la migración en el proyecto A. En este caso, la carga de trabajo migrada se copia en un bucket de Container Registry en el proyecto A. Por ejemplo:

gcr.io/project-a/image_name:image_tag

Luego, quieres implementar la carga de trabajo en un clúster del proyecto B. Si no configuras los permisos correctamente, el Pod de carga de trabajo no se ejecuta porque el clúster del proyecto B no tiene acceso para extraer imágenes en el proyecto A. Entonces, verás un evento en el Pod que contiene un mensaje con el siguiente formato:

Failed to pull image "gcr.io/project-a/image_name:image_tag...
pull access denied...
repository does not exist or may acquire 'docker login'...

Todos los proyectos que tienen habilitada la API de Compute Engine tienen una cuenta de servicio predeterminada, cuya dirección de correo electrónico es la siguiente:

PROJECT_NUMBER-compute@developer.gserviceaccount.com

En este ejemplo, PROJECT_NUMBER es el número de proyecto para el proyecto B.

Para solucionar este problema, asegúrate de que la cuenta de servicio predeterminada de Compute Engine del proyecto B tenga los permisos necesarios para acceder al bucket de Container Registry. Por ejemplo, puedes usar el siguiente comando de gsutil para habilitar el acceso:

gsutil iam ch serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com:objectViewer gs://artifacts.project-a.appspot.com

Implementa cargas de trabajo en el clúster de procesamiento

Puedes implementar la carga de trabajo migrada en el mismo clúster que usaste para realizar la migración, el cual es el clúster de procesamiento de Migrate to Containers. En la mayoría de las situaciones, no es necesario que realices ninguna configuración adicional en el clúster de procesamiento porque el clúster ya requiere acceso de lectura o escritura al registro de Docker para realizar una migración.

Implementa en un clúster de destino con Container Registry como registro de Docker

Para asegurarte de que un clúster de destino tenga acceso a Container Registry, crea un secreto de Kubernetes que contenga las credenciales necesarias para acceder a Container Registry:

  1. Crea una cuenta de servicio para implementar una migración como se describe en Crea una cuenta de servicio para acceder a Container Registry y Cloud Storage.

    Este proceso te permite descargar un archivo de claves JSON con el nombre m4a-install.json.

  2. Crea un secreto de Kubernetes que contenga las credenciales necesarias para acceder a Container Registry:

    kubectl create secret docker-registry gcr-json-key \
 --docker-server=gcr.io --docker-username=_json_key --docker-password="$(cat ~/m4a-install.json.json)" \
 --docker-email=account@project.iam.gserviceaccount.com

    Dónde:

    • docker-registry especifica el nombre del secreto de Kubernetes, que se trata de gcr-json-key en este ejemplo.
    • docker-server=gcr.io especifica Container Registry como el servidor.
    • docker-username=_json_key especifica que el nombre de usuario está contenido en el archivo de claves JSON.
    • docker-password especifica que se use una contraseña del archivo de claves JSON.
    • docker-email especifica la dirección de correo electrónico de la cuenta de servicio.

  3. Configura el Secret de Kubernetes de las siguientes maneras:

    • Cambia el valor imagePullSecrets predeterminado:

      kubectl patch serviceaccount default -p '{"imagePullSecrets": [{"name": "gcr-json-key"}]}'

    • Edita el archivo deployment_spec.yaml para agregar el valor imagePullSecrets a la definición spec.template.spec. Al usar WebSphere tradicional, el archivo de implementación YAML se llama twas_deployment_spec.yaml, liberty_deployment_spec.yaml o openliberty_deployment_spec.yaml, según cuál sea tu destino.

      spec:
  containers:
  - image: gcr.io/PROJECT_ID/mycontainer-instance:v1.0.0
    name: mycontainer-instance
    ...
  volumes:
  - hostPath:
      path: /sys/fs/cgroup
      type: Directory
    name: cgroups
  imagePullSecrets:
  - name: gcr-json-key

      Reemplaza PROJECT_ID con el ID del proyecto.

  4. Implementa el secreto de carga de trabajo, si existe secrets.yaml. Habrá un archivo de secretos para cargas de trabajo basadas en Tomcat y cargas de trabajo basadas en WebSphere tradicional con Liberty. El archivo de Liberty se llama liberty-secrets.yaml.

    kubectl apply -f secrets.yaml

Implementa en un clúster de destino con un registro de Docker con autenticación básica

Si usas un registro de Docker para almacenar imágenes de migración, el registro debe admitir la autenticación básica con un nombre de usuario y una contraseña. Debido a que existen muchas formas de configurar una conexión de solo lectura en un registro de Docker, debes usar el método que sea adecuado para tu plataforma de clúster y registro de Docker.

¿Qué sigue?