Migra una VM monolítica: Migración e implementación

Importante: La IU de Migrate to Containers en la consola de Google Cloud, migctl y las CRD que usan clústeres de procesamiento para migrar cargas de trabajo a Google Cloud están obsoletas. Se admitirán para los usuarios existentes hasta mayo de 2024, después de lo cual dejarán de estar disponibles. Si eres nuevo en Migrate to Containers, usa la CLI de Migrate to Containers para realizar migraciones en tu máquina local. Para obtener más información, consulta Arquitectura de la CLI de Migrate to Containers.

Con una configuración de clúster de procesamiento y Migrate to Containers instalados, estás listo para realizar la migración. Primero, debes agregar una fuente de migración relevante para el clúster de procesamiento y generar un plan de migración para la VM. Después de revisar y personalizar el plan según tus necesidades, puedes generar y, luego, implementar artefactos de Kubernetes en el clúster de GKE en el que ya se está ejecutando el resto de tu aplicación.

Objetivos

Al final de este instructivo, habrás aprendido lo siguiente:

• Agrega una fuente de migración
• Crear un plan de migración a partir de tu carga de trabajo de VM.
• Revisar y personalizar el plan de migración.
• Generar y, luego, implementar artefactos de migración en tu clúster de GKE.

Antes de comenzar

Este instructivo es un seguimiento del instructivo Descubrimiento y evaluación. Antes de comenzar este instructivo, sigue las instrucciones de esa página para ejecutar las herramientas de descubrimiento en la VM monolítica y crear tu clúster de procesamiento.

Detén la VM monolítica

Antes de realizar la migración, debes detener la VM monolítica para evitar interrupciones no intencionales o daños en los datos, que pueden ocurrir si los datos se encuentran en movimiento durante los procesos de migración.

Nota: En un entorno de producción, puedes decidir programar el tiempo de inactividad planificado para tus usuarios o puedes migrar un duplicado de la VM que no se usa en producción.

1. En la consola de Google Cloud, ve a la página Instancias de VM.

   Ir a la página Instancias de VM

2. Selecciona la casilla de verificación en el extremo izquierdo de la fila de la VM ledgermonolith-service.

3. En la parte superior de la página, haz clic en el botón Detener para detener la VM.

4. Espera a que la VM se detenga por completo. Esto puede llevar entre 1 y 2 minutos

Migra la VM

Antes de migrar la VM, debes crear una fuente de migración que represente la plataforma de origen (Compute Engine o VMWare).

Agregar un origen

1. Abre la página Migrate to Containers en la consola de Google Cloud.

   Ir a la página Migrate to Containers

2. En la pestaña Fuentes y candidatos, haz clic en Agregar fuente.

3. En Select processing cluster, elige el clúster de procesamiento de migración de la lista desplegable y haz clic en Siguiente.

4. Especifica el nombre de la fuente, como ledgermonolith-source.

5. Establece el Tipo de fuente en Compute Engine y haz clic en Siguiente.

6. Asegúrate de que el proyecto correcto esté seleccionado como el proyecto de origen.

7. Crea una cuenta de servicio que te permita usar Compute Engine como fuente de migración y selecciona Crear una cuenta de servicio nueva.

8. Haz clic en Continuar y, luego, en Agregar fuente.

Crea una migración

1. Abre la página Migrate to Containers en la consola de Google Cloud.

   Ir a la página Migrate to Containers

2. En la pestaña Migraciones, haz clic en Crear migración.

3. Configura el Nombre de la migración como ledgermonolith-migration.

4. Selecciona la fuente de migración que creaste en el paso anterior: ledgermonolith-source.

5. Configura el Tipo de carga de trabajo como Linux system container.

6. Establece Nombre de la instancia de origen como ledgermonolith-service.

7. Haz clic en Crear migración. Esto puede llevar entre 1 y 2 minutos

   Cuando la migración se complete, la columna Estado mostrará Migration plan generated.

8. En la tabla, haz clic en el Nombre de tu migración ledgermonolith-migration para abrir la página de detalles.

9. En la pestaña Configuración de datos, crea un volumen nuevo para migrar la base de datos de PostgreSQL de la VM, /var/lib/postgresql. La configuración debería verse así:

   volumes:
    - deploymentPvcName: ledgermonolith-db
      folders:
     # Folders to include in the data volume, e.g. "/var/lib/postgresql"
     # Included folders contain data and state, and therefore are automatically excluded from a generated container image
      - /var/lib/postgresql
      newPvc:
        spec:
          accessModes:
          - ReadWriteOnce
          resources:
            requests:
              storage: 10G
   

   Esto garantizará que conserves la base de datos durante la migración. Haga clic en Guardar.

10. En el plan de migración, en deployment, asegúrate de que el servicio tengo el nombre ledgermonolith-service, el puerto 8080 y el protocolo TCP. El objeto debería verse así:

    ...
    endpoints:
      - name: ledgermonolith-service
        port: 8080
        protocol: TCP
    ...
    

11. Haz clic en Guardar y generar artefactos para comenzar el proceso de migración. Este proceso tardará entre 7 y 8 minutos.

    Los artefactos que genera Migrate to Containers para esta VM son los siguientes:

    • Una imagen de Docker del proceso de VM.
    • Un StatefulSet y un servicio para ejecutar el proceso recién migrado
    • Un Namespace y un DaemonSet para conservar el entorno de ejecución del contenedor.
    • Un PersistentVolumeClaim y un PersistentVolume para contener la base de datos de PostgreSQL.

Implementa la carga de trabajo migrada

En la sección anterior, migró correctamente su VM monolítica a un conjunto de recursos de Kubernetes que pueden implementarse en un clúster. Ahora puedes implementar estos recursos en el clúster de Bank for Anthos, volver a configurar la aplicación para que apunte al extremo correcto del servicio de registro recién migrado y verificar que todo funcione.

1. Ahora que se generaron los artefactos de migración, puedes conectarte al clúster de procesamiento y descargar los artefactos en tu entorno de Cloud Shell.

   gcloud container clusters get-credentials migration-processing --zone COMPUTE_ZONE --project PROJECT_ID
   cd ${HOME}/bank-of-anthos/src/ledgermonolith/
   migctl migration get-artifacts ledgermonolith-migration
   

2. Conéctate al clúster de Bank for Anthos e implementa los recursos generados de Kubernetes. Además, instala un entorno de ejecución de contenedores mediante migctl para que el clúster pueda ejecutar el Pod recién migrado.

   gcloud container clusters get-credentials boa-cluster --zone COMPUTE_ZONE --project=PROJECT_ID
   migctl setup install --runtime
   kubectl apply -f ${HOME}/bank-of-anthos/src/ledgermonolith/deployment_spec.yaml
   

   Fetching cluster endpoint and auth data.
   kubeconfig entry generated for boa-cluster.
   
   applying resources to the cluster
   namespace/v2k-system created
   daemonset.apps/runtime-deploy-node created
   
   statefulset.apps/ledgermonolith-service created
   service/ledgermonolith-service-java created
   persistentvolumeclaim/data-pvc-0-4e1b2e0e-021f-422a-8319-6da201a960e5 created
   persistentvolume/pvc-4d41e0f2-569e-415d-87d9-019490f18b1c created
   

3. Edita el ConfigMap que contiene los hosts de registro para que apunten a tu nuevo Pod de Kubernetes, en lugar de la VM de aplicación monolítica de registro que ya no está en servicio.

   sed -i 's/'.c.PROJECT_ID.internal'//g' ${HOME}/bank-of-anthos/src/ledgermonolith/config.yaml
   kubectl apply -f ${HOME}/bank-of-anthos/src/ledgermonolith/config.yaml
   

4. Borra todos los Pods para volver a crearlos con tu configuración nueva.

   kubectl delete pods --all
   

   Puedes ver el estado de los Pods con el siguiente comando:

   kubectl get pods
   

   Es posible que todos los Pods tarden unos minutos en estar en funcionamiento.

   NAME                           READY   STATUS    RESTARTS   AGE
   accounts-db-0                  1/1     Running   0          5m43s
   contacts-d5dcdc87c-jbrhf       1/1     Running   0          5m44s
   frontend-5768bd978-xdvpl       1/1     Running   0          5m44s
   ledgermonolith-service-0       1/1     Running   0          5m44s
   loadgenerator-8485dfd-582xv    1/1     Running   0          5m44s
   userservice-8477dfcb46-rzw7z   1/1     Running   0          5m43s
   

5. Una vez que todos los Pods estén configurados como Running, puedes encontrar la dirección IP externa del servicio LoadBalancer de frontend.

   kubectl get service frontend
   

   NAME       TYPE           CLUSTER-IP      EXTERNAL-IP     PORT(S)        AGE
   frontend   LoadBalancer   10.79.248.161   ##.##.##.##.    80:31304/TCP   46m
   

6. Abre un navegador y visita la página web en la dirección IP externa que se encontró antes (asegúrate de usar HTTP, en lugar de HTTPS).

   http://EXTERNAL_IP
   

   Debería poder acceder con las credenciales predeterminadas y ver las transacciones. Las transacciones que ves provienen de la aplicación monolítica de registro que ahora se migró a un contenedor de Kubernetes.

   

¿Qué sigue?

Ahora que aprendiste a crear y personalizar un plan de migración desde tu carga de trabajo de VM, además de realizar la migración de tu VM a artefactos en contenedores, puedes pasar a la siguiente sección del instructivo, Optimización.

Si terminas el instructivo aquí, no olvides limpiar tu proyecto y tus recursos de Google Cloud.

Limpia

Para evitar cargos innecesarios de Google Cloud, debes borrar los recursos que se usaron en este instructivo en cuanto termines. Estos recursos son los siguientes:

• El clúster de GKE boa-cluster
• El clúster de GKE migration-processing
• La VM de Compute Engine ledgermonolith-service

Puedes borrar estos recursos de forma manual o seguir los pasos que se indican a continuación para borrar tu proyecto, lo que también eliminará todos los recursos.

Precaución: Borrar un proyecto tiene estas consecuencias:

• Se borra todo en el proyecto. Si usaste un proyecto existente para las tareas de este documento, cuando lo borres, también se borrará cualquier otro trabajo que hayas realizado en el proyecto.
• Se pierden los ID personalizados de proyectos. Cuando creaste este proyecto, es posible que hayas creado un ID del proyecto personalizado que desees utilizar en el futuro. Para conservar las URL que utilizan el ID del proyecto, como una URL appspot.com, borra los recursos seleccionados dentro del proyecto en lugar de borrar todo el proyecto.

Si planeas explorar varias infraestructuras, instructivos y guías de inicio rápido la reutilización de proyectos puede ayudarte a evitar exceder los límites de las cuotas del proyecto.

En la consola de Google Cloud, ve a la página Administrar recursos.

Ir a Administrar recursos

En la lista de proyectos, elige el proyecto que quieres borrar y haz clic en Borrar.

En el diálogo, escribe el ID del proyecto y, luego, haz clic en Cerrar para borrar el proyecto.

¿Qué sigue?

• Obtén información sobre la optimización (día 2).