Moderniza las cargas de trabajo tradicionales

En este tema, se describe cómo modernizar las cargas de trabajo basadas en VM en contenedores que se ejecutan en Google Kubernetes Engine (GKE), el clúster de GKE Enterprise o la plataforma de Cloud Run. Puedes migrar cargas de trabajo desde VMs que se ejecutan en VMware o Compute Engine, lo que te da la flexibilidad de crear contenedores para las cargas de trabajo existentes.

Para realizar la modernización (también conocida como migración), usa un clúster de procesamiento que creaste con los pasos en Instala Migrate to Containers.

El flujo básico para migrar una carga de trabajo es similar en todos los tipos de cargas de trabajo compatibles. Existen algunas diferencias entre los tipos de cargas de trabajo, por lo que debes identificar tu tipo de carga de trabajo en las siguientes secciones para obtener un resumen del procedimiento y la información detallada por paso.

Cargas de trabajo admitidas

Migra una VM de Linux

Procedimiento de migración

En el siguiente diagrama, se ilustran los pasos de migración para una carga de trabajo de Linux:

Diagrama de los pasos para migrar con Migrate to Containers
  1. Agrega una fuente de migración

    Para iniciar una migración, debes configurar una fuente que represente la plataforma de origen desde la que realizarás la migración. Si ya tienes una fuente de una migración anterior y las VM que migras provienen de la misma fuente, puedes volver a usarla.

  2. Crea una migración.

    Crea un objeto de migración con un plan de migración inicial.

  3. Migra datos de Linux.

    Elige si deseas o no migrar datos.

  4. Personaliza tu plan de migración.

    Edita el plan de migración para tus requisitos específicos antes de ejecutar la migración.

  5. Ejecuta la migración.

    Ejecuta la migración para extraer los artefactos del contenedor, incluida la imagen del contenedor y el Dockerfile. Utiliza estos artefactos para implementar el contenedor en el entorno de pruebas o en la producción.

  6. Supervisa una migración.

    Supervisa el progreso de una migración y, luego, inspecciona los registros de actividad de migración.

  7. Borra una migración.

    Borra la migración para liberar cualquier recurso que esta use.

Migra una aplicación de Windows IIS

Procedimiento de migración

En el siguiente diagrama, se ilustran los pasos de migración para una carga de trabajo de Windows:

Diagrama de los pasos para migrar con Migrate to Containers

Los pasos para migrar con Migrate to Containers son los siguientes:

  1. Agrega una fuente de migración

    Para comenzar una migración, debes configurar una fuente que represente la plataforma de origen desde la que realizas la migración. Si ya tienes una fuente de una migración anterior y las VM que migras provienen de la misma fuente, puedes volver a usarla.

  2. Crea un plan de migración.

    Crea un objeto de migración con un plan de migración inicial.

  3. Personaliza tu plan de migración.

    Edita el plan de migración para tus requisitos específicos antes de ejecutar la migración.

  4. Ejecuta la migración.

    Ejecuta la migración para extraer los artefactos del contenedor, que incluyen el Dockerfile y otros archivos necesarios para compilar una imagen de contenedor.

  5. Supervisa la migración.

    Supervisa el progreso de una migración y, luego, inspecciona los registros de actividad de migración.

  6. Compila una imagen de contenedor de Windows.

    Usa los artefactos generados para compilar un contenedor de Windows que puedas implementar luego en un clúster.

  7. Borra una migración.

    Borra la migración para liberar cualquier recurso que esta use.

Funciones admitidas

Migrate to Containers: Windows admite actualmente la migración de sitios de framework .NET de IIS. Puedes dividir los sitios en imágenes de un solo propósito o agruparlos como desees.

Para tener una mejor indicación de qué sitios se pueden migrar en una VM de origen, intenta ejecutar la evaluación sin conexión de la CLI de cliente de descubrimiento del Centro de migraciones.

Migra un servidor de Tomcat

En el siguiente diagrama, se ilustran los pasos de migración para una carga de trabajo de Tomcat:

Diagrama de los pasos para migrar con Migrate to Containers

Cuando usas Migrate to Containers para migrar tus cargas de trabajo de Tomcat, puedes aprovechar las funciones y la arquitectura de Tomcat para realizar las siguientes acciones:

  • Separa automáticamente los subconjuntos de aplicaciones en contenedores individuales.
  • Conserva los almacenes de claves, los truststores y los certificados existentes de tu aplicación de Tomcat desde la VM de origen.
  • Determina de forma dinámica la asignación de memoria óptima para aplicaciones de JVM.
  • Copia volúmenes de datos y reclamaciones de volúmenes de datos específicos desde tus VM de origen.

Requisitos previos

  • Una versión 8.5 y posterior del servidor de apps de Apache Tomcat basado en VM de Linux.
  • Determina la idoneidad de la carga de trabajo para la migración mediante la ejecución de una evaluación sin conexión.
  • Configura un clúster de Cloud para migrar VMs de Linux.

Procedimiento de migración

Los pasos para migrar con Migrate to Containers son los siguientes:

  1. Agrega una fuente de migración

    Para comenzar una migración, debes configurar una fuente que represente la plataforma de origen desde la que realizas la migración. Si ya tienes una fuente de una migración anterior y las VM que migras provienen de la misma fuente, puedes volver a usarla.

  2. Crea una migración.

    Crea un objeto de migración con un plan de migración inicial.

  3. Migra datos de Tomcat

    Elige si deseas o no migrar datos.

  4. Personaliza tu plan de migración.

    Edita el plan de migración para tus requisitos específicos antes de ejecutar la migración.

  5. Ejecuta la migración.

    Ejecuta la migración para extraer los artefactos del contenedor, que incluyen el Dockerfile y otros archivos necesarios para compilar una imagen de contenedor.

  6. Supervisa la migración.

    Supervisa el progreso de una migración y, luego, inspecciona los registros de actividad de migración.

  7. Compila una imagen de contenedor de Tomcat

    Usa los artefactos generados para compilar un contenedor que puedas implementar luego en un clúster.

  8. Borra una migración.

    Borra la migración para liberar cualquier recurso que esta use.

Características no compatibles

Las siguientes funciones de Tomcat no son compatibles:

  • Replicación de sesiones o agrupamiento en clústeres.

  • Compatibilidad con Windows para migraciones de Tomcat mediante cargas de trabajo de Windows

Migra aplicaciones tradicionales de WebSphere

Descripción general de la migración

La infraestructura tradicional de IBM WebSphere Application Server (WAS) es un marco de trabajo de software que aloja cargas de trabajo basadas en Java. Migrate to Containers te permite modernizar las cargas de trabajo de las apps que se ejecutan en WAS tradicional mediante su conversión en contenedores de aplicaciones. Luego, puedes implementar los contenedores de la app en el clúster de GKE o GKE Enterprise en Google Cloud.

Acerca de la migración de apps tradicionales de WebSphere Application Server

Una VM tradicional de WAS puede contener varias apps. Migrate to Containers te ayuda a automatizar la modernización de las apps de WAS a los contenedores mediante la detección de apps implementadas en la VM de origen y la sugerencia automática de la configuración para la modernización.

Google requiere que migres cada app a su propia imagen de contenedor (ibmcom/websphere-traditional, ibmcom/websphere-liberty o openliberty/open-liberty). Luego, puedes probar y, además, implementar las apps migradas de forma individual, en lugar de tener que probar y, además, implementar varias aplicaciones en conjunto.

Migra apps de WAS a contenedores individuales de apps.

La fuente de migración puede ser WAS ND o WAS base. El destino será un contenedor base de Liberty o WAS tradicional, y las características del agrupamiento en clústeres ND correspondiente se delegarán a Kubernetes.

Requisitos

Confirma que los entornos de migración y de implementación sean compatibles con Migrate to Containers mediante la revisión de los siguientes requisitos del sistema.

Requisitos para la migración de apps tradicionales de WAS

Antes de comenzar la migración, asegúrate de que tu entorno tradicional de IBM WAS y el clúster de procesamiento de migración cumpla con los requisitos que se describen a continuación.

Requisitos de sistemas tradicionales de WAS

Migrate to Containers admite la migración de apps alojadas en las siguientes versiones de IBM WAS:

  • Servidor de aplicaciones tradicional de WebSphere 8.5.5.x
  • Servidor de aplicaciones tradicional de WebSphere 9.0.5.x

Para que Migrate to Containers procese una VM que contiene una app tradicional de WAS, Migrate to Containers extrae dos tipos de configuraciones de la VM:

  • La configuración de cada aplicación.

  • La configuración del perfil de destino. Un perfil define el entorno de tiempo de ejecución de un WAS que incluye los puertos, la configuración de JVM y mucho más.

El software de Migrate to Containers automatiza el uso de Migration Toolkit for Application Binaries de IBM WebSphere Application Server en el clúster de GKE Enterprise o GKE para descubrir, evaluar y generar informes de migración y secuencias de comandos de configuración. Eres el único responsable de obtener, licenciar y usar el kit de herramientas.

Antes de comenzar una migración, debes subir el kit de herramientas a un bucket de Google Cloud Storage en tu cuenta. Consulta Configura el objeto binarioAppScanner.jar para este procedimiento.

Sistemas operativos de VM compatibles

Migrate to Containers admite migraciones de aplicaciones tradicionales de WAS desde VMs instaladas con los sistemas operativos Linux de 64 bits que se mencionan en Sistemas operativos de VMs compatibles.

Procesa los requisitos del clúster

Usa un clúster de Google Kubernetes Engine (GKE) o GKE Enterprise para ejecutar los componentes de Migrate to Containers que realizan las transformaciones necesarias para migrar una app desde una VM de origen a un contenedor de destino. Para apps en una VM de WAS:

El clúster de procesamiento debe usar un sistema operativo Linux que se enumera en Sistemas operativos de clústeres de procesamiento compatibles.

Consulta Elige el tipo de clúster de procesamiento para obtener información sobre cómo crear cada tipo de clúster de procesamiento.

Requisitos para implementar apps migradas

Después de migrar las apps, asegúrate de que el entorno de la aplicación y el clúster de destino cumplan con los requisitos que se describen a continuación.

Requisitos del clúster de destino

Usa un clúster de Google Kubernetes Engine (GKE), GKE Enterprise en Google Cloud o Virtual Distributed Cloud Virtual para Bare Metal. El clúster de destino debe usar un sistema operativo Linux que se enumera en Sistemas operativos de clústeres de cargas de trabajo compatibles.

Como parte de la migración, Migrate to Containers crea una imagen de Docker que representa una app de WAS migrada y la sube a un registro de Docker. Debes asegurarte de que el clúster de destino tenga acceso de lectura al registro de Docker, como se describe aquí.

Contenedores de destino compatibles
  • Servidor de aplicaciones tradicional de WebSphere
  • WebSphere Application Server Liberty
  • Open Liberty

Antes de comenzar

Antes de comenzar una migración, debes realizar las tareas que se indican a continuación.

Instala Migrate to Containers

Instala Migrate to Containers en tu clúster de procesamiento. Un clúster de procesamiento es un clúster de Google Kubernetes Engine (GKE) o de GKE Enterprise con componentes de Migrate to Containers instalados, y que usas para migrar las VMs. Consulta la descripción general de la instalación para ver todas las instrucciones de instalación.

De manera opcional, configura Migrate to Virtual Machines

Para usar Migrate to Containers a fin de migrar cargas de trabajo de Websphere a Google Cloud desde VMware, debes configurar Migrate to Virtual Machines, que controla el transporte.

Para obtener más información, consulta Configura Migrate to Virtual Machines.

Configura el binarioAppScanner.jar

Migrate to Containers automatiza el uso del binaryAppScanner.jar, disponible como parte de Migration Toolkit for Application Binaries de IBM WebSphere Application Server, a fin de extraer la información y los archivos de configuración para las aplicaciones de WAS presentes en la VM de origen.

Antes de poder realizar una migración, debes hacer lo siguiente:

Para configurar binaryAppScanner.jar:

  1. Descarga el archivo de instalación, binaryAppScannerInstaller.jar, de Asistencia de IBM.Debes aceptar el contrato de licencia como parte de la descarga.

  2. Ejecuta el siguiente comando para extraer el archivo binaryAppScanner.jar y aceptar el Contrato de Licencia:

    java -jar binaryAppScannerInstaller.jar --acceptLicense --verbose
    
  3. Especifica el directorio de destino para la extracción. Por ejemplo, /tmp. El instalador crea un directorio llamado /wamt debajo del directorio de destino.

  4. Navega al directorio /wamt. Por ejemplo:

    cd /tmp/wamt
    
  5. Crea dos Dockerfiles con los siguientes comandos:

    FROM us-docker.pkg.dev/migrate-modernize-public/modernize-plugins-prod/websphere-traditional-container-discover:1.3.1
    ADD binaryAppScanner.jar /
    
    FROM us-docker.pkg.dev/migrate-modernize-public/modernize-plugins-prod/websphere-traditional-container-extract:1.3.1
    ADD binaryAppScanner.jar /
    
  6. Compila y envía las imágenes de Docker:

    gcloud builds submit --timeout 1h -t gcr.io/PROJECT_ID/websphere-traditional-container-discover-with-scanner:1.3.1 --project PROJECT_ID
    gcloud builds submit --timeout 1h -t gcr.io/PROJECT_ID/websphere-traditional-container-extract-with-scanner:1.3.1 --project PROJECT_ID
    
  7. Edita el complemento CRD para agruparlo con el análisis binario de la siguiente manera:

    $ kubectl edit appxplugins.anthos-migrate.cloud.google.com -n v2k-system websphere-traditional-container
    
    # Set the value of spec.discoveryImage and spec.generateArtifactsImage:
    
    apiVersion: anthos-migrate.cloud.google.com/v1beta2
    kind: AppXPlugin
    metadata:
      namespace: v2k-system
      name: websphere-traditional-container
      labels:
        anthos-migrate.cloud.google.com/preview-type: public
      annotations:
        anthos-migrate.cloud.google.com/display-name: WebSphere traditional container
    spec:
      discoverImage: gcr.io/PROJECT_ID/websphere-traditional-container-discover-with-scanner:1.3.1
      discoverCommand:
      - /ko-app/websphere-traditional
      - discover
      generateArtifactsImage: gcr.io/PROJECT_ID/websphere-traditional-container-extract-with-scanner:1.3.1
      generateArtifactsCommand:
      - /ko-app/websphere-traditional
      - extract
      parameterDefs:
      - name: was-home
        usage: Path of the WebSphere WAS_HOME on the original instance.
        envVar: APPX_WAS_HOME
    
  8. Guarda el CRD.

Procedimiento de migración

En el siguiente diagrama se ilustran los pasos de migración para una carga de trabajo de WebSphere:

Migra apps de WAS a contenedores individuales de apps.

Los pasos para migrar con Migrate to Containers son los siguientes:

  1. Agrega una fuente de migración

    Agrega la fuente de migración que representa la plataforma de origen.

  2. Crea una migración.

    Crea un objeto de migración con un plan de migración inicial.

  3. Migra datos de WebSphere.

    Elige si deseas o no migrar datos.

  4. Personaliza el plan de migración.

    Edita el plan de migración para tus requisitos específicos antes de ejecutar la migración. Debes migrar una app de WAS por migración.

  5. Ejecuta la migración.

    Ejecuta la migración para extraer los artefactos del contenedor, que incluyen el Dockerfile y otros archivos necesarios para compilar una imagen de contenedor.

  6. Genera y revisa artefactos de migración.

    Realiza la migración para generar el contenedor de la app. Puedes supervisar el proceso de migración y, cuando termines, revisa los artefactos a fin de prepararte para compilar la imagen de la app que se puede implementar.

  7. Supervisa la migración.

    Supervisa el progreso de una migración y, luego, inspecciona los registros de actividad de migración.

  8. Compila una imagen de contenedor de app.

    Usa los artefactos generados para compilar un contenedor que puedas implementar luego en un clúster.

  9. Implementa un contenedor de apps en un clúster de destino

    Implementar la imagen en tu clúster de destino.

  10. Borra una migración.

    Borra la migración para liberar cualquier recurso que esta use.

Migra un servidor de JBoss

En el siguiente diagrama, se ilustran los pasos de migración para una carga de trabajo de JBoss:

Diagrama de los pasos para migrar con Migrate to Containers

Cuando usas Migrate to Containers para migrar tus cargas de trabajo de JBoss, puedes aprovechar las funciones y la arquitectura de JBoss para copiar volúmenes de datos y reclamaciones de volúmenes de datos específicos de tus VMs de origen.

Requisitos previos

  • Servidor de aplicaciones JBoss AS v8.1.0 y posteriores, o servidor de aplicaciones de JBoss EAP v7.0, v7.1, v7.2, v7.3 y v7.4.

  • Configura un clúster de Google Cloud para migrar VMs.

Procedimiento de migración

Los pasos para migrar con Migrate to Containers son los siguientes:

  1. Agrega una fuente de migración

    Para comenzar una migración, debes configurar una fuente que represente la plataforma de origen desde la que realizas la migración. Si ya tienes una fuente de una migración anterior y las VM que migras provienen de la misma fuente, puedes volver a usarla.

  2. Crea una migración.

    Crea un objeto de migración con un plan de migración inicial.

  3. Migra datos de JBoss.

    Elige si deseas o no migrar datos.

  4. Personaliza tu plan de migración.

    Edita el plan de migración para tus requisitos específicos antes de ejecutar la migración.

  5. Ejecuta la migración.

    Ejecuta la migración para extraer los artefactos del contenedor, que incluyen el Dockerfile y otros archivos necesarios para compilar una imagen de contenedor.

  6. Supervisa la migración.

    Supervisa el progreso de una migración y, luego, inspecciona los registros de actividad de migración.

  7. Compila una imagen de contenedor de JBoss

    Usa los artefactos generados para compilar un contenedor que puedas implementar luego en un clúster.

  8. Borra una migración.

    Borra la migración para liberar cualquier recurso que esta use.

Características no compatibles

Las siguientes funciones de JBoss no son compatibles:

  • Datos sensibles y Secrets: Los datos sensibles y los Secrets almacenados en el directorio JBOSS_HOME/standalone no se quitarán. Estos datos se incluirán en la imagen del contenedor.
  • Configuración del registrador JBoss: La configuración del registrador se tomará como está desde la máquina de origen. No se modificará durante el proceso de migración, a menos que jbossServer.tar.gz se modifique de forma manual antes de compilar el contenedor de JBoss.
  • Asignación de memoria: la asignación de recursos de máquinas virtuales Java (JVM) se tomará del contenedor de la comunidad y no dependerá de los recursos de JVM de origen.
  • Variables de entorno: Las variables de entorno y los parámetros de JVM de la máquina de origen no se migrarán a la imagen del contenedor.
  • Evaluación sin conexión: No se admite la determinación de la idoneidad de la carga de trabajo de JBoss para la migración.

Migra un servidor Apache

En el siguiente diagrama, se ilustran los pasos de migración para una carga de trabajo de Apache:

Diagrama de los pasos para migrar con Migrate to Containers

Cuando usas Migrate to Containers para migrar tus cargas de trabajo de Apache, puedes aprovechar las funciones y la arquitectura de Apache para realizar las siguientes acciones:

  • Copia volúmenes de datos y reclamaciones de volúmenes de datos específicos desde tus VM de origen.

Requisitos previos

  • Una VM de Linux basada en Apache 2 Webserver
  • Configura un clúster de Google Cloud para migrar VMs de Linux.

Procedimiento de migración

Los pasos para migrar con Migrate to Containers son los siguientes:

  1. Agrega una fuente de migración

    Para comenzar una migración, debes configurar una fuente que represente la plataforma de origen desde la que realizas la migración. Si ya tienes una fuente de una migración anterior y las VM que migras provienen de la misma fuente, puedes volver a usarla.

  2. Crea una migración.

    Crea un objeto de migración con un plan de migración inicial.

  3. Migra datos.

    Elige si deseas o no migrar datos.

  4. Personaliza tu plan de migración.

    Edita el plan de migración para tus requisitos específicos antes de ejecutar la migración.

  5. Ejecuta la migración.

    Ejecuta la migración para extraer los artefactos del contenedor, que incluyen el Dockerfile y otros archivos necesarios para compilar una imagen de contenedor.

  6. Supervisa la migración.

    Supervisa el progreso de una migración y, luego, inspecciona los registros de actividad de migración.

  7. Compila una imagen de contenedor de Apache

    Usa los artefactos generados para compilar un contenedor que puedas implementar luego en un clúster.

  8. Borra una migración.

    Borra la migración para liberar cualquier recurso que esta use.

Características no compatibles

Las cargas de trabajo de Apache 1 no son compatibles.

Las siguientes funciones de Apache no son compatibles:

  • Certificados.

  • Compatibilidad con Windows para migraciones de Apache mediante cargas de trabajo de Windows.

Migra un sitio de WordPress

Cuando usas Migrate to Containers para migrar tus cargas de trabajo de WordPress, puedes aprovechar las funciones y la arquitectura de WordPress para copiar volúmenes de datos y reclamaciones de volúmenes de datos específicos de tus VMs de origen.

Requisitos previos

  • Versión de WordPress 4.0 o posterior, que se ejecuta en un servidor web Apache 2 basado en VM de Linux.
  • Configura un clúster de Google Cloud para migrar VMs de Linux.

Procedimiento de migración

Los pasos para migrar con Migrate to Containers son los siguientes:

  1. Agrega una fuente de migración

    Para comenzar una migración, debes configurar una fuente que represente la plataforma de origen desde la que realizas la migración. Si ya tienes una fuente de una migración anterior y las VM que migras provienen de la misma fuente, puedes volver a usarla.

  2. Crea una migración.

    Crea un objeto de migración con un plan de migración inicial.

  3. Personaliza tu plan de migración.

    Edita el plan de migración para tus requisitos específicos antes de ejecutar la migración.

  4. Migra datos de WordPress.

    Revisa y edita el plan de migración de datos para tus requisitos específicos antes de ejecutar la migración.

  5. Ejecuta la migración.

    Ejecuta la migración para extraer los artefactos del contenedor, que incluyen el Dockerfile y otros archivos necesarios para compilar una imagen de contenedor.

  6. Supervisa la migración.

    Supervisa el progreso de una migración y, luego, inspecciona los registros de actividad de migración.

  7. Compila una imagen de contenedor de WordPress

    Usa los artefactos generados para compilar un contenedor que puedas implementar luego en un clúster.

  8. Borra una migración.

    Borra la migración para liberar cualquier recurso que esta use.

Características no compatibles

Los sitios de WordPress que se ejecutan en hosts que no sean el servidor web Apache 2 basado en VM de Linux no son compatibles.

Las siguientes funciones de WordPress no son compatibles:

  • Migración de la base de datos de WordPress.

    Para obtener más información sobre cómo migrar una aplicación que depende de una base de datos, consulta Asegúrate de que se pueda acceder a las bases de datos.

  • Exportar datos almacenados de forma local en el servidor de WordPress, como cargas de contenido multimedia, complementos y temas, a una unidad NFS.

    Para obtener más información sobre la exportación de datos almacenados de forma local a NFS, consulta Define activaciones de NFS como volúmenes persistentes.

  • Escalamiento horizontal de la implementación migrada.

    Los datos almacenados de forma local en el servidor de WordPress se exportan al disco persistente de Compute Engine, que está activado en el pod de implementación migrado. Un disco persistente de Compute Engine no se puede conectar a varios pods y, por lo tanto, evita el escalamiento horizontal de la implementación migrada.

  • Exportar certificados y datos sensibles a objetos secretos de Kubernetes.

¿Qué sigue?