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
- VM de Linux
- Aplicación Windows IIS
- Aplicación Tomcat
- Aplicaciones tradicionales de WebSphere
- JBoss
- Apache
- Sitios de WordPress
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:
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.
-
Crea un objeto de migración con un plan de migración inicial.
-
Elige si deseas o no migrar datos.
Personaliza tu plan de migración.
Edita el plan de migración para tus requisitos específicos antes de ejecutar 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.
-
Supervisa el progreso de una migración y, luego, inspecciona los registros de actividad de 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:
Los pasos para migrar con Migrate to Containers son los siguientes:
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.
-
Crea un objeto de migración con un plan de migración inicial.
Personaliza tu plan de migración.
Edita el plan de migración para tus requisitos específicos antes de ejecutar 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.
-
Supervisa el progreso de una migración y, luego, inspecciona los registros de actividad de migración.
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.
-
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:
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:
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.
-
Crea un objeto de migración con un plan de migración inicial.
-
Elige si deseas o no migrar datos.
Personaliza tu plan de migración.
Edita el plan de migración para tus requisitos específicos antes de ejecutar 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.
-
Supervisa el progreso de una migración y, luego, inspecciona los registros de actividad de migración.
Compila una imagen de contenedor de Tomcat
Usa los artefactos generados para compilar un contenedor que puedas implementar luego en un clúster.
-
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.
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 se puede implementar de la siguiente manera:
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:
Acepta el contrato de licencia y descarga Migration Toolkit for Application Binaries de IBM WebSphere Application Server y, luego, extrae el archivo
binaryAppScanner.jar
.Crea un Dockerfile y prepara el complemento incluido con el escáner binario.
Para configurar binaryAppScanner.jar
:
Descarga el archivo de instalación,
binaryAppScannerInstaller.jar
, de Asistencia de IBM.Debes aceptar el contrato de licencia como parte de la descarga.Ejecuta el siguiente comando para extraer el archivo
binaryAppScanner.jar
y aceptar el Contrato de Licencia:java -jar binaryAppScannerInstaller.jar --acceptLicense --verbose
Especifica el directorio de destino para la extracción. Por ejemplo,
/tmp
. El instalador crea un directorio llamado/wamt
debajo del directorio de destino.Navega al directorio /wamt. Por ejemplo:
cd /tmp/wamt
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 /
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
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
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:
Los pasos para migrar con Migrate to Containers son los siguientes:
Agrega una fuente de migración
Agrega la fuente de migración que representa la plataforma de origen.
-
Crea un objeto de migración con un plan de migración inicial.
-
Elige si deseas o no migrar datos.
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.
-
Ejecuta la migración para extraer los artefactos del contenedor, que incluyen el Dockerfile y otros archivos necesarios para compilar una imagen de contenedor.
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.
-
Supervisa el progreso de una migración y, luego, inspecciona los registros de actividad de migración.
Compila una imagen de contenedor de app.
Usa los artefactos generados para compilar un contenedor que puedas implementar luego en un clúster.
Implementa un contenedor de apps en un clúster de destino
Implementar la imagen en tu clúster de destino.
-
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:
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:
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.
-
Crea un objeto de migración con un plan de migración inicial.
-
Elige si deseas o no migrar datos.
Personaliza tu plan de migración.
Edita el plan de migración para tus requisitos específicos antes de ejecutar 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.
-
Supervisa el progreso de una migración y, luego, inspecciona los registros de actividad de migración.
Compila una imagen de contenedor de JBoss
Usa los artefactos generados para compilar un contenedor que puedas implementar luego en un clúster.
-
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:
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:
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.
-
Crea un objeto de migración con un plan de migración inicial.
-
Elige si deseas o no migrar datos.
Personaliza tu plan de migración.
Edita el plan de migración para tus requisitos específicos antes de ejecutar 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.
-
Supervisa el progreso de una migración y, luego, inspecciona los registros de actividad de migración.
Compila una imagen de contenedor de Apache
Usa los artefactos generados para compilar un contenedor que puedas implementar luego en un clúster.
-
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:
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.
-
Crea un objeto de migración con un plan de migración inicial.
Personaliza tu plan de migración.
Edita el plan de migración para tus requisitos específicos antes de ejecutar la migración.
-
Revisa y edita el plan de migración de datos para tus requisitos específicos antes de ejecutar 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.
-
Supervisa el progreso de una migración y, luego, inspecciona los registros de actividad de migración.
Compila una imagen de contenedor de WordPress
Usa los artefactos generados para compilar un contenedor que puedas implementar luego en un clúster.
-
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?
- Aprende a agregar una fuente de migración.