Personaliza un plan de migración

Vista previa

Este producto o función está sujeto a las "Condiciones de las Ofertas de Fase Previa a la DG" de la sección Condiciones Generales del Servicio de las Condiciones específicas del Servicio. Los productos y las funciones que se encuentran en la fase previa a la DG están disponibles “tal cual” y podrían tener asistencia limitada. Para obtener más información, consulta las descripciones de la etapa de lanzamiento.

Debes revisar el archivo del plan de migración que se generó cuando se creó la migración. Personaliza el archivo antes de ejecutar la migración. Los detalles de tu plan de migración se usan para extraer los artefactos de contenedor de la carga de trabajo de la fuente.

En esta sección, se describe el contenido de la migración y los tipos de personalizaciones que puedes tener en cuenta antes de ejecutar la migración y generar artefactos de implementación.

Antes de comenzar

• En este tema, se supone que ya creaste una migración y que tienes el archivo del plan de migración.

Edita el plan de migración

Puedes editar el plan de migración con la herramienta migctl o la consola de Google Cloud.

migctl

Debes descargar el plan de migración para poder editarlo:

1. Descarga el plan de migración. El plan se representa con GenerateArtifactsFlow:

   migctl migration get my-migration
   

2. Edita el plan de migración descargado, my-migration.yaml, en un editor de texto.

3. Cuando completes tus cambios, guarda y sube el plan de migración revisado:

   migctl migration update my-migration --file my-migration.yaml
   

4. Repite estos pasos si se necesitan más cambios.

Console

Edita el plan de migración en la consola de Google Cloud con el editor de YAML. La CRD de WebSphereGenerateArtsFlow representa el plan de migración:

1. Abre la página Migrate for Anthos and GKE en Cloud Console.

   Ir a la página Migrar a contenedores.

2. Haz clic en la pestaña Migraciones para ver una tabla con las migraciones disponibles.

3. En la fila de la migración deseada, selecciona el Nombre de la migración para abrir la pestaña Detalles.

4. Selecciona la pestaña YAML.

   Nota: También puedes seleccionar Descargar plan de migración para descargar una copia local.

5. Edita el plan de migración según sea necesario.

6. Cuando termines de editar, puedes optar por una de las siguientes acciones:

   1. Guarda el plan de migración. Luego, deberás ejecutar la migración de forma manual para generar los artefactos de migración. Usa el procedimiento que se muestra en Ejecuta una migración.

   2. Guarda y genera los artefactos. Ejecuta la migración mediante tus ediciones para generar los artefactos de migración. El proceso es el mismo que se describe en Ejecuta una migración. Luego, puedes supervisar la migración como se describe en Supervisa una migración.

CRD

Debes descargar el plan de migración, editarlo, y aplicarlo. La CRD de WebSphereGenerateArtsFlow representa el plan de migración:

1. Obtén el nombre de GenerateArtifactsFlow:

   kubectl get migrations.anthos-migrate.cloud.google.com -n v2k-system my-migration -o jsonpath={.status.resources.generateArtifacts.name}

   El patrón de nombres se muestra en el formato generate-artifacts-flow-id.

2. Obtén el GenerateArtifactsFlow por nombre y escribe en un archivo llamado my-plan.yaml:

   kubectl get generateartifactsflows.anthos-migrate.cloud.google.com -n v2k-system generate-artifacts-flow-id -o yaml > my-plan.yaml

3. Edita el plan de migración según sea necesario.

4. Aplica el siguiente archivo:

   kubectl apply -f my-plan.yaml

Revisa los detalles de tu plan de migración y los comentarios guías para agregar información según sea necesario. En particular, considera las ediciones en las siguientes secciones:

Especifica la imagen de Docker

En el plan de migración, generamos una etiqueta de imagen de la comunidad de Docker basada en la versión de Tomcat, la versión de Java y el proveedor de Java.

• Versión de Tomcat: La versión de Tomcat se detecta y se convierte en una versión principal (no se admiten versiones secundarias). Si no detectamos una versión de Tomcat, fromImage contendrá una string vacía.
• Versión de Java: La versión de Java se configura con la información de la colección de evaluación de ajuste. Si CATALINA_BASE o CATALINA_HOME se ingresan de forma manual o si la evaluación de ajustes no pudo recopilar la versión de Java, la versión de Java se establece en 11 de forma predeterminada.
• Proveedor de Java: El proveedor de Java se establece en una constante: openjdk.

En el plan de migración, el campo fromImage representa la etiqueta de imagen de Docker que se usa como base de la imagen del contenedor.

Las versiones originales de Tomcat y Java detectadas en la VM de origen se encuentran en discovery-report.yaml, que se genera mediante el descubrimiento inicial.

Si deseas cambiar la imagen de la comunidad de Docker o proporcionar tu propia imagen de Docker, puedes modificar el fromImageTag en tu plan de migración con el siguiente formato:

tomcatServers:
    - name: latest
      . . .
      images:
        - name: tomcat-latest
          . . .
          fromImage: tomcat:9.0-jdk11-openjdk

Configura SSL

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 secretos 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 … 

Nota: El orden en el que enumeras tus objetos secretos cuando ejecutas secrets.sh debe coincidir con el orden de los objetos secretos del plan de migración.

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.

Importante: 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 recopilación de registros y transmitir a una solución de recopilación de registros (como Google Cloud Logging).

Nota: Cuando migras a una imagen de contenedor, Migrate for Anthos and GKE filtran el directorio logs del servidor de Tomcat para omitir los registros antiguos.

Asignación de memoria:

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

Estos valores se basan en el valor de tamaño máximo de Java (-Xmx/-XX:MaxHeapSize) que se recopila de la instancia de origen mediante la evaluación de ajuste (mfit). Los valores serán los siguientes: limit=200%Xmx, request=125%Xmx.

Nota: Migrate for Anthos and GKE solo admiten argumentos de JVM Xmx,MaxHeapSize.

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

tomcatServers:
    - name: latest
      . . .
      images:
        - name: tomcat-latest
          . . .
          resources:
            memory:
              limit: 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-jdk11-openjdk

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

Esto define el tamaño inicial y máximo como un 50% del valor límite. Esto permitirá que el tamaño de la asignación de montón de Tomcat para Java cambie según cualquier cambio con el límite de memoria del Pod.

Nota: Si el campo catalinaOpts contiene una variable -Xms/InitialRAMPrecentage/InitialRAMFraction/InitialHeapSize, no se establecerá la variable de entorno InitialRAMPercentage=50.

Configura variables de entorno 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. En el siguiente ejemplo, se muestra un campo catalineOpts actualizado:

tomcatServers:
    - name: latest
      . . .
      images:
        - name: tomcat-latest
          . . .
          resources:
            . . .
          catalinaOpts: "-Xss10M"

Migrate for Anthos and GKE analizarán tus datos de catalinaOpts en tu Dockerfile: En el siguiente ejemplo, se muestra el resultado del análisis:

FROM 8.5-jdk11-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.0 -XX:InitialRAMPercentage=50.0 -Xss10M"

También puedes configurar variables de entorno de Tomcat mediante la secuencia de comandos setenv.sh, que se encuentra en la carpeta /bin del 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.

Nota: Si configuras -Xmx, se reemplaza -XX:MaxRAMPercentage. Si configuras -Xms, se reemplaza -XX:InitialRAMPercentage.

Nota: Migrate for Anthos y GKE no evalúan contenido de setenv.sh. Como resultado, se recomienda que agregues las variables de entorno de Tomcat directamente a CATALINA_OPTS.

Próximos pasos

Ejecuta una migración