Migra cargas de trabajo de Tomcat

Migrate for Anthos and GKE ayuda a acelerar la creación de contenedores de cargas de trabajo tradicionales y la implementación en clústeres de GKE y Anthos.

Descripción general de la migración

Esta oferta de vista previa pública ahora te permite modernizar tus cargas de trabajo de Tomcat que se ejecutan en las VM de Linux, ya que se convierten en contenedores de aplicaciones. Luego, puedes implementar los contenedores de la aplicación en los siguientes entornos:

Cuando usas Migrate for Anthos and GKE para migrar las cargas de trabajo de Tomcat, puedes aprovechar las funciones y la arquitectura de Tomcat.

  • Separa automáticamente los subconjuntos de aplicaciones en contenedores individuales.
  • Mantén 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

Para migrar tus aplicaciones de Tomcat, debes hacer lo siguiente:

Proceso de migración

El proceso de migración para las aplicaciones de Tomcat es similar al proceso de migración de Linux actual con las siguientes advertencias:

  • Consideraciones sobre mfit:

    • Debes ejecutar mfitla herramienta de evaluación de aptitud antes de comenzar la migración de la carga de trabajo de Tomcat para completar la fase de recopilación de datos.
    • Hay varias reglas mfit específicas de Tomcat que puedes usar para evaluar tu carga de trabajo. Para obtener más información sobre las reglas mfit específicas de Tomcat, consulta la documentación de mfit de Tomcat.
    • No especifiques la opción --readonly. La opción --readonly evita que mfit almacene datos recopilados sobre Tomcat en la VM y bloquea el acceso de Migrate for Anthos and GKE a esos datos.
    • No uses la opción ./mfit discover. Debes ejecutar la secuencia de comandos de recopilación de datos en una VM a fin de recuperar la información necesaria para la creación de contenedores mediante las imágenes de la comunidad de OSS de Tomcat.

  • Otras consideraciones

    • Debes especificar la marca --workload–type con la opción tomcat cuando ejecutes migctl para crear el plan de migración.
    • Para personalizar la migración, edita el archivo YAML del plan de migración. Este archivo tiene un formato específico de Tomcat que se detalla a continuación en Personaliza el plan de migración.
    • Cuando generas los artefactos de migración, Migrate for Anthos and GKE crean un archivo build.sh que luego usas para compilar la imagen del contenedor de implementación.

    • Para realizar la migración de datos junto con la migración de la aplicación de Tomcat, puedes editar el archivo YAML de configuración de datos (my-migration.data.yaml)).

      Para obtener más información sobre el formato del archivo YAML de configuración de datos, consulta Personaliza la configuración de migración de datos a continuación.

Realiza una migración de carga de trabajo de Tomcat

Para realizar una migración de carga de trabajo de Tomcat, sigue los pasos que se indican a continuación:

  1. Ejecuta mfit: mfit es la herramienta de evaluación de idoneidad que puede evaluar la viabilidad de la carga de trabajo de Tomcat existente para la migración.

  2. Configura un clúster de procesamiento: Instala los componentes de Migrate for Anthos and GKE en un clúster de GKE que ya creaste para procesar la migración y la creación de contenedores de las cargas de trabajo basadas en VM. .

    Para obtener más información sobre cómo configurar correctamente un clúster de procesamiento según el entorno de destino, consulta Instala Migrate for Anthos and GKE.

  3. Agrega una fuente de migración: Agrega la fuente de migración que representa la plataforma de origen desde la que migrarás. Por ejemplo, si migras una VM desde Compute Engine: 

     migctl source create ce my-src --project my-project --json-key json-key-file

    A fin de obtener más información sobre cómo agregar fuentes de migración y la sintaxis adecuada para fuentes de migración, consulta la documentación de Agrega una fuente de migración.

  4. Crea una migración: Crea un plan de migración que puedas revisar y personalizar antes de ejecutar la migración.

    A fin de crear un plan de migración para las cargas de trabajo de Tomcat, puedes usar el siguiente comando migctl con la marca --workload-type establecida en tomcat:

     migctl migration create my-migration --source my-src --vm-id my-vm --workload-type tomcat

    Aquí:

    • my-migration: Especifica el nombre de la migración.
    • my-src: Especifica el nombre de la fuente de migración que creaste en el paso anterior.

  5. Verifica tu plan de migración: para verificar el archivo YAML que contiene tu plan de migración (incluida la configuración de los límites de memoria y memoria requeridos, la configuración de división de la aplicación de Tomcat y la configuración del certificado), sigue estos pasos:

    1. Descarga tus archivos de plan de migración (my-migration.yaml) y de configuración de migración de datos (my-migration.data.yaml)):

      migctl migration get my-migration

      Este comando descarga los archivos llamados my-migration.yaml y my-migration.data.yaml.

    2. Abre my-migration.yaml en un editor de texto y visualiza los detalles de la migración. Cambia los detalles según sea necesario para personalizar el plan de migración. Para obtener información sobre cómo personalizar el plan de migración, consulta Personaliza el plan de migración a continuación.

    3. Cuando tus ediciones estén completas, carga el archivo editado. 

      migctl migration update my-migration --main-config my-migration.yaml

  6. Configura la configuración de migración de datos (opcional): Con Migrate for Anthos and GKE, puedes migrar carpetas persistentes desde tus cargas de trabajo de Tomcat mediante el archivo de configuración de migración de datos (my-migration.data.yaml). El archivo my-migration.data.yaml está vacío de forma predeterminada.

    Para configurar my-migration.data.yaml, sigue los pasos a que se indican a continuación:

    1. Descarga los archivos de configuración de migración de datos (my-migration.data.yaml) y de plan de migración (my-migration.yaml) mediante el siguiente comando:

      migctl migration get my-migration

      Este comando muestra los archivos llamados my-migration.yaml y my-migration.data.yaml.

    2. Edita my-migration.data.yaml en un editor de texto.

    3. Cuando tus ediciones estén completas, carga el archivo editado.

      migctl migration update my-migration --data-config my-migration.data.yaml

  7. Genera artefactos de migración: Realiza la migración para generar los artefactos de contenedor:

    migctl migration generate-artifacts my-migration

    Para obtener más información sobre la generación de artefactos de migración, consulta la documentación de Ejecuta una migración.

  8. Revisa los artefactos: Revisa los artefactos a fin de prepararte para compilar la imagen de contenedor implementable mediante la ejecución del siguiente comando:

    migctl migration get-artifacts my-migration

    Mediante este comando, se crea un directorio separado para cada servidor de Tomcat que aparece en el plan de migración. Migrate for Anthos and GKE crea un directorio anidado correspondiente según tu plan de migración para cada una de las imágenes del servidor. Estos directorios anidados incluyen artefactos de imagen para compilar y, luego, implementar la imagen.

    En cada directorio, puedes encontrar varios artefactos:

    • El archivo build.sh que puedes usar para compilar la imagen de contenedor del servidor de Tomcat
    • El archivo deployment_spec.yaml que se usa para implementar la imagen de contenedor
    • El archivo cloudbuild.yaml que puedes usar para volver a compilar la imagen más adelante como parte de una canalización de CI/CD
    • El archivo volumes.yaml que contiene un desglose de los volúmenes de datos migrados

    Para obtener más información sobre cómo verificar los artefactos de migración, consulta a continuación el Paso 9: Verifica volumes.yaml.

  9. Verifica volumes.yaml (opcional):

    Uno de los artefactos que Migrate for Anthos and GKE genera cuando se completa una migración se llama volumes.yaml.

    Tu volumes.yaml contiene información sobre las PVC, los PV y los PD en los que se copiaron los datos como parte de la migración de datos. Puedes usar esta información si deseas modificar la carga de trabajo migrada antes de implementarla con el fin de que los datos copiados sean accesibles para tu carga de trabajo.

    El formato del archivo volumes.yaml es el siguiente:

    volumes:
       deployment pvc name:
         pvc:
           full pvc yaml
         pv:
           full pvc yaml

    Para obtener más información sobre cómo definir un archivo yaml de PVC o PV, consulta la documentación de Kubernetes.

  10. Compila la imagen de contenedor: Usa el archivo build.sh creado en los artefactos de migración a fin de compilar la imagen de contenedor para el servidor de Tomcat.

    1. Cambia al directorio que contiene los artefactos generados para la imagen de Tomcat.

      Por ejemplo, para cambiar al directorio de un servidor de Tomcat llamado latest y una imagen llamada app, ejecuta el siguiente comando:

      cd latest/app

    2. Configura el ID del proyecto de Google Cloud y la versión de la imagen:

      export PROJECT_ID=my_project VERSION=latest

    3. Ejecuta la secuencia de comandos build.sh para compilar tu imagen de contenedor y súbela a Container Registry:

      bash ./build.sh

  11. Implementa el contenedor de la app: Implementa la app migrada en el clúster de destino.

    sed -e "s/\${PROJECT_ID}/${PROJECT_ID}/g" -e "s/\${VERSION}/${VERSION}/g"
 deployment_spec.yaml | kubectl apply -f -

    Para obtener más información sobre la implementación del contenedor de app en un clúster de destino, consulta la documentación de Implementa un contenedor de app en un clúster de destino.

Personaliza tu plan de migración

Cuando creas el plan de migración, Migrate for Anthos and GKE genera un archivo YAML que contiene la información para cada servidor de Tomcat en ejecución que se detecta. Debes editar el plan de migración para personalizar las propiedades de cada servidor de Tomcat antes de generar los artefactos de migración.

Para personalizar la migración, debes editar el plan de migración (my-migration.yaml):

tomcatServers:
    - name: latest
      catalinaBase: /opt/tomcat/latest
      catalinaHome: /opt/tomcat/home
      secrets: # files to extract from the server container images into secrets
        - name: my-vm-latest-ssl
          path: /usr/local/ssl
          files:
            - server.crt
            - server.pem
        - name: my-vm-latest-keystore
          path: /usr/home/tomcat
          files:
            - .keystore
            - .truststore
      images:
        - name: my-vm-latest-docs # name of the image for build and deployment
          fromImage: tomcat:8.5.66-jdk16-openjdk # for the resulting container image
          applications: # list of applications to include in the image
            - /opt/tomcat/latest/latest/webapps/docs
          additionalFiles: # external required paths
            - /opt/libraries/postgres.jar
          logConfigPaths: # of the contained web apps. Must be under catalina base
            - /opt/tomcat/latest/virtualHost/webapps/docs/WEB-INF/classes/log4j2.xml
          ports: # to create Kubernetes services associated with the resulting deployment
            - 8080
          resources:
            memory:
              limits: 2048M
              requests: 1280M
          secrets: # to mount in the container image
            - my-vm-latest-ssl
            - my-vm-latest-keystore
        - name: another-image
          . . .
    - name: another-server
      . . .

En my-migration.yaml:

  • name: Especifica el nombre del servidor de Tomcat, que se determina a partir del nombre catalinaBase. Migrate for Anthos and GKE agrega un sufijo en caso de colisión de nombres.

  • catalinaBase/Home: Se define en el nivel del servidor Tomcat.

  • secrets: Los Secrets se pueden definir en dos permisos:

    • Permiso del servidor: Puedes definir los campos secrets name, path y files en el permiso del servidor.
    • Permiso de la imagen: Puedes definir los campos secrets como una lista de rutas de acceso de string en el permiso de la imagen.

  • images: Contiene una entrada para cada aplicación y una entrada para todas las aplicaciones juntas. Si no se descubrieron servidores de Tomcat en la carga de trabajo, el atributo images incluirá una única entrada de ejemplo para que las definas en la revisión.

    • name: Especifica el nombre de la imagen de contenedor generada, de la siguiente manera:

      tomcat-name

      Por ejemplo, para un servidor de Tomcat llamado latest, el imageName es el siguiente:

      Tomcat-latest

    • fromImage: Se determina una vez para todas las aplicaciones en el mismo servidor de Tomcat.

  • additionalFiles: Se descubre a nivel del servidor y se asigna a todas las aplicaciones.

    • ports: Se define en tu servidor Tomcat, Conectores se puede asociar con aplicaciones relevantes.
    • Resources: Sugerido automáticamente solo para la imagen unificada.
    • También se proporcionará una imagen con todas las aplicaciones.

Define tus Secrets y certificados

Cuando creas una migración de Tomcat nueva, un proceso de descubrimiento analiza la configuración del servidor para detectar el uso de certificados. Las rutas de acceso de certificados se asignan según las diferentes aplicaciones que se detectan.

Estos certificados se muestran en el plan de migración a nivel del servidor y de la imagen:

  • Permiso del servidor: Los Secrets que incluyas en el permiso del servidor se excluirán de los artefactos de imagen resultantes. Una secuencia de comandos de artefactos dedicada llamada secrets.sh automatiza la creación de objetos Secret de Kubernetes desde sus rutas de acceso locales.

  • Permiso de la imagen: Los nombres de los Secrets que incluyas en el permiso de la imagen generarán una activación automática de los Secrets correspondientes en los contenedores implementados. Si tienes una ruta de acceso de Secret configurada como una ruta relativa en el plan de migración, la ruta de activación se corregirá en relación con el directorio de instalación de la imagen de la comunidad de Tomcat.

Puedes crear los objetos secretos de Kubernetes mediante el artefacto secrets.sh con Migrate for Anthos and GKE mediante la ejecución del siguiente comando:

bash ./secrets.sh namespace of deployments secret file secret file …

Registro de apps web

Migrate for Anthos and GKE admite el registro con log4j v2, logback y log4j v1.x que residen en CATALINA_HOME. Las rutas de acceso fuera de CATALINA_HOME no se admiten.

Migrate for Anthos and GKE creará un archivo adicional con opciones de configuración de registro modificadas y convertirá todos los adjuntadores de tipos de archivos en adjuntadores de consola. Puedes usar el contenido de este archivo como referencia para habilitar la transmisión y recopilación de registros a una solución de recopilación de registros (como Google Cloud Logging).

Asignación de memoria:

Durante el proceso de migración, Migrate for Anthos and GKE intentan ubicar los límites de memoria del montón máximo de montón de Tomcat para Java en las VM de origen. Si se detectan límites de memoria en una VM de origen, conjuntos de Migrate for Anthos and GKEinicial (requests ) ymáximo (limits ) de tu contenedor migrado.

Si deseas especificar límites de memoria de las aplicaciones migradas a contenedores individuales, o si no se encontraron límites de memoria dentro de tus VM de origen, puedes editar los límites de memoria directamente en tu plan de migración con el siguiente formato:

tomcatServers:
    - name: latest
      . . .
      images:
        - name: tomcat-latest
          . . .
          resources:
            memory:
              limits: 2048M
              requests: 1280M

Si se definieron límites de memoria en tu plan de migración, el Dockerfile (que se generó junto con otros artefactos después de una migración exitosa) reflejará tu declaración:

FROM tomcat:8.5.66-jdk16-openjdk

# Add JVM environment variables for tomcat
ENV CATALINA_OPTS="${CATALINA_OPTS} -XX:MaxRAMPercentage=50 -XX:InitialRAMPercentage=50 -XX:+UseContainerSupport <additional variables>"

Configura las variables de entorno de Tomcat

Si deseas configurar CATLINA_OPTS en tu Dockerfile (que se genera junto con otros artefactos después de una migración exitosa), primero puedes agregar información al campo catalinaOpts en el plan de migración:

tomcatServers:
    - name: latest
      . . .
      images:
        - name: tomcat-latest
          . . .
          resources:
            . . .
          catalinaOpts: "-Xms512M -Xmx1024M"

Migrate for Anthos and GKE analizarán tus datos de catalinaOpts en tu Dockerfile:

FROM 8.5.66-jdk16-openjdk-slim

## setenv.sh script detected.
## Modify env variables on the script and add definitions to the migrated tomcat server,
## if needed (less recommended than adding env variables directly to CATALINA_OPTS) by uncomment the line below
#ADD --chown=root:root setenv.sh /usr/local/tomcat/bin/setenv.sh

    # Add JVM environment variables for the tomcat server
ENV CATALINA_OPTS="${CATALINA_OPTS} -XX:MaxRAMPercentage=50 -XX:InitialRAMPercentage=50 -Xss10M"

También puedes configurar variables de entorno Tomcat mediante la secuencia de comandos setenv.sh (ubicada en la carpeta /bin de tu servidor de Tomcat). Para obtener más información sobre las variables de entorno de Tomcat, consulta la documentación de Tomcat.

Si eliges usar setenv.sh para configurar las variables de entorno de Tomcat, deberás editar el Dockerfile.

Personaliza la configuración de migración de datos

Migrate for Anthos and GKE te permiten especificar volúmenes de datos o reclamaciones de volúmenes de datos que se migrarán desde tus cargas de trabajo de Tomcat durante el proceso de migración.

Para habilitar la migración de datos en el proceso de migración, deberás proporcionar información sobre tu volumen o reclamación de datos de destino en el archivo de configuración de datos (my-migration.data.yaml) con el formato indicado a continuación:

dataConfig:
      volumes:
        - deploymentPvcName:
          existingPvc:
            Name: my-pvc
          folders:
            - /bin
            - /opt
        - newPvc:
            accessModes:
            - ReadWriteOnce
            resources:
              requests:
                storage: 10G
          folders:
            - /bin
            - /opt

Aquí:

  • deploymentPvcName: El nombre de PVC que usará Migrate for Anthos and GKE en la carga de trabajo implementada para acceder a este volumen. (No usado en migraciones de Tomcat).

  • existingPvc:

    • name: Nombre de una PVC existente. Define si deseas migrar volúmenes de datos a una PVC existente. De lo contrario, debe ser nil.

  • newPvc: Define si deseas migrar los volúmenes de datos a una PVC nueva. Puedes definir tu PVC con la sintaxis de especificación de PVC estándar.

    Para obtener más información sobre las especificaciones de PVC de Kubernetes, consulta la documentación de Kubernetes.

  • folders:

Puedes editar el archivo de configuración de datos para varios casos de uso de migración de datos, incluidos los siguientes:

Sin migración de datos

Si no deseas migrar ningún dato durante la migración, debes dejar el archivo de configuración de datos generado (my-migration.data.yaml) vacío. De forma predeterminada, el archivo de configuración de datos se crea vacío.

Uso de una PersistentVolumeClaim existente (PVC)

Puedes migrar tus datos con una PersistentVolumeClaim existente (PVC) si ya asignaste el almacenamiento que deseas para tus datos migrados y tienes una PVC en la que deseas que se almacenen los datos.

Puedes definir una PVC existente en tu archivo de configuración de datos (my-migration.data.yaml) si pasas el volumen existente en el campo existingPvc.

Tu PVC debe existir antes de la migración. En este caso, el archivo de configuración de datos se vería de la siguiente manera:

dataConfig:
      volumes:
        - deploymentPvcName:
          existingPvc:
            name: my-pvc
          newPvc: # must be nil
          folders:
            - /bin
            - /opt

Creación de volúmenes de datos nuevos en las VM migradas

Si no asignaste almacenamiento con anticipación y deseas que se cree tu almacenamiento durante el proceso de migración, puedes pasar un campo existingPvc vacío y especificar el almacenamiento que deseas crear en el campo newPvc:

dataConfig:
      volumes:
        - deploymentPvcName:
          existingPvc: #must be nil
          newPvc:
            accessModes:
            - ReadWriteOnce
            resources:
              requests:
                storage: 10G
          folders:
            - /bin
            - /opt

Si no quieres preocuparte por los detalles del almacenamiento de copia de seguridad, debes usar una string vacía para la clase de almacenamiento.

Si deseas declarar una clase de almacenamiento específica, debes preparar un objeto de clase de almacenamiento en el mismo clúster que crea tu almacenamiento según tus requisitos.

Migración de varias PVC con varias rutas de archivos

Puedes especificar el conjunto de directorios en el campo de lista folders de cada entrada en la lista volume para cada PVC que aparece en el archivo de configuración de datos (my-migration.data.yaml):

dataConfig:
      volumes:
        - deploymentPvcName:
          existingPvc:
            name: my-pvc
          folders:
            - /bin
            - /opt
        - newPvc:
            accessModes:
            - ReadWriteOnce
            resources:
              requests:
                storage: 10G
          folders:
            - /bin
            - /opt

Las rutas de acceso que enumeras en folders en el archivo de configuración se copian en las mismas rutas en las PVC de destino.

Migración de datos: próximos pasos

Una vez que hayas verificado el archivo de configuración de datos, debes continuar con el Paso 7: Genera artefactos del proceso de migración.

Puedes verificar los volúmenes migrados con el artefacto volumes.yaml que se produjo durante el proceso de migración de Tomcat.

Características no compatibles

Las siguientes funciones de Tomcat no son compatibles con esta versión:

  • Migración de versiones: Migrate for Anthos and GKE no admite la migración a imágenes con diferentes versiones de Tomcat y Java.

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

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

  • Descubrimiento de versiones y proveedores de Java: Migrate for Anthos and GKE sugieren una versión y un proveedor predefinidos de Java que se usan para seleccionar la imagen de Tomcat, en lugar de descubrirla de forma automática.

Soluciona problemas

Durante el proceso de migración de tu carga de trabajo para Tomcat, es posible que encuentres errores.

  • Si recibes un error de lectura build.sh: 

    manifest for ... not found: manifest unknown: manifest unknown

Este mensaje de error indica que falta la imagen superior de la carga de trabajo. Existen dos soluciones para mitigar este error:

  • Editar el archivo de configuración de extracción con una imagen existente y volver a ejecutar el Paso 7: Genera artefactos
  • Editar la declaración FROM del Dockerfile para hacer referencia a una imagen existente y volver a ejecutar build.sh