Migración de aplicaciones de Tomcat a Azure Container Apps

Esta guía le guía por el proceso de migración de una aplicación de Tomcat existente a Azure Container Apps. Abarca la evaluación previa a la migración, la propia migración y la optimización posterior a la migración.

Prerrequisitos

evaluación previa a la migración

Antes de iniciar la migración, complete los pasos de evaluación e inventario descritos en las secciones siguientes.

Recursos externos de inventario

Usted inyecta recursos externos, como fuentes de datos, agentes de mensajes JMS y otros, mediante Java Naming and Directory Interface (JNDI). Algunos de estos recursos pueden requerir migración o reconfiguración.

Dentro de la aplicación

Inspeccione el archivo meta-INF/context.xml . Busque los elementos <Resource> dentro del elemento <Context>.

En los servidores de aplicaciones

Inspeccione los archivos $CATALINA_BASE/conf/context.xml y $CATALINA_BASE/conf/server.xml . Inspeccione también los archivos .xml en $CATALINA_BASE/conf/<engine-name/>host-name<> directorios.

En los archivos context.xml, se describen los recursos JNDI usando elementos <Resource> dentro del elemento de nivel superior <Context>.

En los archivos server.xml, se describen los recursos JNDI mediante el elemento <Resource> dentro del elemento <GlobalNamingResources>.

Orígenes de datos

Las fuentes de datos son recursos JNDI con el atributo type establecido en javax.sql.DataSource. Para cada origen de datos, documente la siguiente información:

  • ¿Cuál es el nombre del origen de datos?
  • ¿Cuál es la configuración del grupo de conexiones?
  • ¿Dónde está el archivo JAR del controlador JDBC?

Para obtener más información, consulte Procedimientos de orígenes de datos JNDI en la documentación de Tomcat.

Todos los demás recursos externos

No es factible documentar todas las dependencias externas posibles en esta guía. Su equipo es responsable de comprobar que pueden satisfacer todas las dependencias externas de su aplicación después de la migración.

Inventario de secretos y certificados

Contraseñas y cadenas seguras

Compruebe todas las propiedades y archivos de configuración en los servidores de producción en busca de textos y contraseñas secretas. Asegúrese de comprobar server.xml y context.xml en $CATALINA_BASE/conf. También puede encontrar archivos de configuración que contengan contraseñas o credenciales dentro de la aplicación, incluidos meta-INF/context.xml y, para aplicaciones de Spring Boot, application.properties o archivos application.yml .

Certificados

Documente todos los certificados utilizados para los puntos de conexión SSL públicos o la comunicación con las bases de datos de backend y otros sistemas. Para ver todos los certificados en los servidores de producción, ejecute el comando siguiente:

keytool -list -v -keystore <path to keystore>

Revisión del uso del sistema de archivos

Identifique las instancias en las que los servicios leen o escriben en el sistema de archivos local. Tenga en cuenta qué archivos son de corta duración o temporales y qué archivos son de larga duración.

Azure Container Apps ofrece varios tipos de almacenamiento. Mediante el almacenamiento efímero, puede leer y escribir datos temporales dentro de un contenedor o réplica en ejecución. Mediante Azure Files, puede proporcionar almacenamiento permanente que varios contenedores pueden compartir. Para obtener más información, consulte Cómo utilizar los montajes de almacenamiento en Azure Container Apps.

Si la aplicación proporciona contenido estático de solo lectura, considere la posibilidad de moverla a Azure Blob Storage y agregar Azure CDN para la distribución global. Para obtener más información, vea Static website hosting in Azure Storage and Quickstart: Integrate an Azure storage account with Azure CDN.

Si la aplicación controla el contenido estático publicado dinámicamente (contenido cargado o generado que no cambia después de la creación), puede integrar Azure Blob Storage y Azure CDN. También puede usar una función de Azure para administrar cargas y desencadenar actualizaciones de red CDN. Para obtener una implementación de ejemplo, consulte Carga y precarga de contenido estático de CDN con Azure Functions.

Si la aplicación actualmente atiende contenido estático desde el directorio webapps/ de Tomcat, planee mover ese contenido a una solución de almacenamiento externo como parte de la migración.

Comprobación del código específico del sistema operativo

Si la aplicación contiene código con dependencias en el sistema operativo host, refactorice para quitar esas dependencias. Por ejemplo, reemplace cualquier uso de / o \ en las rutas de acceso del sistema de archivos con File.Separator o Paths.get.

Comprobación de la compatibilidad de la plataforma

Si crea manualmente el Dockerfile e implementa una aplicación en contenedor en Azure Container Apps, tiene control total sobre la implementación, incluidas las versiones JRE/JDK y las versiones de Tomcat.

Antes de crear imágenes de contenedor, migre la aplicación a las versiones JDK y Tomcat que quiere usar en Container Apps. Pruebe la aplicación exhaustivamente para garantizar la compatibilidad y el rendimiento.

Nota:

Esta validación es especialmente importante si el servidor actual se ejecuta en un JDK no compatible, como Oracle JDK o IBM OpenJ9.

Para comprobar la versión actual de Java, inicie sesión en el servidor de producción y ejecute el siguiente comando:

java -version

Identificación del mecanismo de persistencia de sesión

Para identificar el administrador de persistencia de sesión en uso, inspeccione los archivos context.xml en la aplicación y la configuración de Tomcat. Busque el <Manager> elemento y, a continuación, anote el valor del className atributo .

Las implementaciones integradas de PersistentManager de Tomcat, como StandardManager o FileStore, no están diseñadas para su uso con una plataforma distribuida y escalada como Azure Container Apps. Container Apps puede equilibrar la carga entre varias instancias y reiniciar de forma transparente cualquier instancia en cualquier momento, por lo que no se recomienda conservar el estado mutable en un sistema de archivos.

Si necesita persistencia de sesión, use una implementación alternativa PersistentManager que escriba en un almacén de datos externo, como VMware Tanzu Session Manager con Redis Cache.

Identificación de trabajos programados

No puede usar trabajos programados, como tareas del Quartz Scheduler o tareas cron, con implementaciones de Tomcat en contenedores. Si escala horizontalmente la aplicación, un trabajo programado podría ejecutarse más de una vez por período programado, lo que puede provocar consecuencias no deseadas.

Realice un inventario de los trabajos programados, dentro o fuera del servidor de aplicaciones. Las tareas en lote o de corta duración son buenas candidatas para los trabajos de Container Apps. Para obtener más información, consulte Jobs en Azure Container Apps.

Determinar si se usa MemoryRealm

MemoryRealm requiere un archivo XML persistente. En Azure Container Apps, debe agregar este archivo a la imagen de contenedor o cargarlo en el almacenamiento compartido que se hace disponible para los contenedores. Para obtener más información, consulte la sección Identificación del mecanismo de persistencia de sesión . Debe modificar el pathName parámetro en consecuencia.

Para determinar si MemoryRealm se usa actualmente, inspeccione los archivos server.xml y context.xml . Busque elementos <Realm> donde el atributo className esté establecido a org.apache.catalina.realm.MemoryRealm.

Parametrizar la configuración

Durante la pre-migración, es probable que haya identificado secretos y dependencias externas, como fuentes de datos, en los archivos server.xml y context.xml. Para cada elemento, reemplace cualquier nombre de usuario, contraseña, cadena de conexión o dirección URL por una variable de entorno.

Nota:

Use el flujo de autenticación más seguro disponible. El flujo de autenticación descrito en este procedimiento, como para bases de datos, memorias caché, mensajería o servicios de inteligencia artificial, requiere un grado de confianza muy alto en la aplicación y conlleva riesgos que no están presentes en otros flujos. Use este flujo solo cuando las opciones más seguras, como las identidades administradas para conexiones sin contraseña o sin claves, no sean viables. En el caso de las operaciones de máquina local, prefiera identidades de usuario para conexiones sin contraseña o sin claves.

Por ejemplo, supongamos que el archivo context.xml contiene el siguiente elemento:

<Resource
    name="jdbc/dbconnection"
    type="javax.sql.DataSource"
    url="jdbc:postgresql://postgresdb.contoso.com/wickedsecret?ssl=true"
    driverClassName="org.postgresql.Driver"
    username="postgres"
    password="{password}"
/>

Puede cambiarlo como se muestra en el ejemplo siguiente:

<Resource
    name="jdbc/dbconnection"
    type="javax.sql.DataSource"
    url="${postgresdb.connectionString}"
    driverClassName="org.postgresql.Driver"
    username="${postgresdb.username}"
    password="${postgresdb.password}"
/>

Evaluación del registro y APM

Identifique las soluciones de agregación de registros que usan las aplicaciones que va a migrar. Debe configurar las opciones de diagnóstico durante la migración para que los eventos registrados estén disponibles para su consumo. Para obtener más información, consulte la sección Configuración del registro y diagnóstico .

Identifique cualquier agente de administración de rendimiento de aplicaciones (APM) que usen las aplicaciones. Azure Container Apps no ofrece compatibilidad integrada con APM. Prepare la imagen del contenedor o integre la herramienta APM directamente en el código. Si quiere medir el rendimiento de la aplicación, pero aún tiene que integrar cualquier APM, considere la posibilidad de usar Aplicación de Azure Insights con el agente de Java de instrumentación automática. Para más información, consulte Habilitación de OpenTelemetry de Azure Monitor para aplicaciones Java.

Arquitectura de implementación de documentos

Documente la siguiente información para la aplicación tomcat:

  • Número de instancias en ejecución.
  • Número de CPU asignadas a cada instancia.
  • Cantidad de RAM asignada a cada instancia.

Determine también si distribuye las instancias de la aplicación entre varias regiones o centros de datos. Documente los requisitos de tiempo de actividad y el Acuerdo de Nivel de Servicio para las aplicaciones que va a migrar.

Migración

Creación de un entorno de Container Apps

Cree un entorno de Container Apps en la suscripción de Azure. Para obtener más información, consulte Quickstart: Implementación de la primera aplicación contenedora mediante el portal de Azure.

Configuración del registro y diagnóstico

Configura el registro para dirigir toda la salida a la consola en lugar de a los archivos.

Después de implementar la aplicación en Azure Container Apps, puede configurar las opciones de registro en el entorno de Container Apps para definir uno o varios destinos de registro. Estos destinos pueden incluir Azure Monitor Log Analytics, Azure Event Hubs o soluciones de supervisión que no son de Microsoft. También puede deshabilitar el almacenamiento de datos de registro y ver los registros solo en tiempo de ejecución. Para obtener instrucciones de configuración, consulte Opciones de almacenamiento y supervisión de registros en Azure Container Apps.

Configuración de almacenamiento persistente

Si alguna parte de la aplicación lee o escribe en el sistema de archivos local, configure el almacenamiento persistente para reemplazarla. Por ejemplo, si la aplicación de Tomcat escribe archivos de registro o sube archivos a /opt/tomcat/data, cree un recurso compartido de Azure Files y móntelo en el mismo directorio:

az containerapp update \
    --resource-group <RESOURCE_GROUP> \
    --name <APP_NAME> \
    --set-env-vars "UPLOAD_DIR=/opt/tomcat/data"

Especifique la ruta de acceso que se va a montar en el contenedor a través de la configuración de la aplicación y alinéela con la ruta de acceso que usa la aplicación. Para obtener más información, consulte Cómo utilizar los montajes de almacenamiento en Azure Container Apps.

Migración de certificados a Azure Key Vault

Azure Container Apps admite la comunicación segura entre aplicaciones. La aplicación no necesita administrar el proceso de establecimiento de comunicaciones seguras. Puede cargar un certificado privado en Azure Container Apps o usar un certificado administrado gratuito. El uso de Azure Key Vault para administrar certificados es el enfoque recomendado.

Para almacenar un certificado en Key Vault y hacer referencia a él desde la aplicación contenedora:

  1. Importe el certificado en Azure Key Vault. Para más información, consulte Importación de un certificado en Azure Key Vault.
  2. Habilite una identidad administrada en la aplicación de contenedor y concédale el rol Usuario de secretos de Key Vault en el almacén.
  3. Configure la aplicación contenedora para usar el certificado de Key Vault para dominios personalizados.

Para obtener más información, vea Certificates en Azure Container Apps.

Prepara los artefactos de implementación

Clona el repositorio de GitHub del Tomcat on Containers Quickstart. Este repositorio contiene archivos de configuración dockerfile y Tomcat con muchas optimizaciones recomendadas. En los pasos siguientes se describen las modificaciones que es probable que necesite realizar en estos archivos antes de compilar la imagen de contenedor e implementarla en Container Apps.

Nota:

Algunas implementaciones de Tomcat ejecutan varias aplicaciones en un único servidor de Tomcat. Si esta configuración coincide con la implementación, ejecute cada aplicación en una aplicación de contenedor independiente. Mediante este enfoque, puede optimizar el uso de recursos para cada aplicación, a la vez que minimiza la complejidad y el acoplamiento.

Añadir recursos JNDI

Edite server.xml para agregar los recursos que preparó en los pasos previos a la migración, como orígenes de datos, como se muestra en el ejemplo siguiente:

Nota:

Use el flujo de autenticación más seguro disponible. El flujo de autenticación descrito en este procedimiento, como para bases de datos, memorias caché, mensajería o servicios de inteligencia artificial, requiere un alto grado de confianza en la aplicación y conlleva riesgos que no están presentes en otros flujos. Use este flujo solo cuando las opciones más seguras, como las identidades administradas para conexiones sin contraseña o sin claves, no sean viables. En el caso de las operaciones de máquina local, prefiera identidades de usuario para conexiones sin contraseña o sin claves.

<!-- Global JNDI resources
      Documentation at /docs/jndi-resources-howto.html
-->
<GlobalNamingResources>
    <!-- Editable user database that can also be used by
         UserDatabaseRealm to authenticate users
    -->
    <Resource name="UserDatabase" auth="Container"
              type="org.apache.catalina.UserDatabase"
              description="User database that can be updated and saved"
              factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
              pathname="conf/tomcat-users.xml"
               />

    <!-- Migrated datasources here: -->
    <Resource
        name="jdbc/dbconnection"
        type="javax.sql.DataSource"
        url="${postgresdb.connectionString}"
        driverClassName="org.postgresql.Driver"
        username="${postgresdb.username}"
        password="${postgresdb.password}"
    />
    <!-- End of migrated datasources -->
</GlobalNamingResources>

Para obtener más instrucciones sobre el origen de datos, consulte las secciones siguientes de procedimientos de origen de datos JNDI en la documentación de Tomcat:

Compilación e inserción de la imagen

La manera más sencilla de compilar y cargar la imagen en Azure Container Registry (ACR) para su uso por Container Apps es usar el az acr build comando . Este comando no requiere que Docker esté instalado en el equipo. Por ejemplo, si tiene el Dockerfile desde el repositorio tomcat-container-quickstart y el paquete de aplicación pet clinic.war en el directorio actual, puede compilar la imagen de contenedor en ACR con el siguiente comando:

az acr build \
    --registry $acrName \
    --image "${acrName}.azurecr.io/petclinic:{{.Run.ID}}" \
    --build-arg APP_FILE=petclinic.war \
    --build-arg SERVER_XML=prod.server.xml .

Puede omitir el --build-arg APP_FILE... parámetro si el archivo WAR se denomina ROOT.war. Puede omitir el --build-arg SERVER_XML... parámetro si el archivo XML del servidor se denomina server.xml. Ambos archivos deben estar en el mismo directorio que el Dockerfile.

Como alternativa, puede usar la CLI de Docker para compilar la imagen localmente mediante los siguientes comandos. Este enfoque puede simplificar las pruebas y refinar la imagen antes de la implementación inicial en ACR. Sin embargo, requiere que se instale Docker CLI y que se ejecute Docker daemon.

# Build the image locally.
docker build . --build-arg APP_FILE=petclinic.war -t "${acrName}.azurecr.io/petclinic:1"

# Run the image locally.
docker run -d -p 8080:8080 "${acrName}.azurecr.io/petclinic:1"

# You can now access your application with a browser at http://localhost:8080.

# Sign in to ACR.
az acr login --name $acrName

# Push the image to ACR.
docker push "${acrName}.azurecr.io/petclinic:1"

Nota:

En Linux, es posible que tenga que prefijar los docker comandos con sudo si el usuario no está en el docker grupo.

Para más información, consulte Compilación y almacenamiento de imágenes de contenedor con Azure Container Registry.

Implementación en Azure Container Apps

El comando siguiente muestra una implementación de ejemplo:

az containerapp create \
    --resource-group <RESOURCE_GROUP> \
    --name <APP_NAME> \
    --environment <ENVIRONMENT_NAME> \
    --image <IMAGE_NAME> \
    --target-port 8080 \
    --ingress 'external' \
    --registry-server <REGISTRY_SERVER> \
    --min-replicas 1

Para obtener una guía de inicio rápido más detallada, consulte Inicio rápido: Implementación de la primera aplicación de contenedor.

Configuración de secretos y variables de entorno

Inserte los valores de configuración en cada aplicación como variables de entorno. Establezca estas variables como entradas manuales o como referencias a secretos. Para más información, consulte Administración de variables de entorno en Azure Container Apps y Administración de secretos en Azure Container Apps.

Configuración de la identidad y la autenticación

Si la aplicación tomcat requiere autenticación o autorización, asegúrese de que la configuración esté establecida para acceder al proveedor de identidades:

  • Si el proveedor de identidades es Microsoft Entra ID, no realice ningún cambio.
  • Si el proveedor de identidades es un bosque de Active Directory local, considere implementar una solución de identidad híbrida con Microsoft Entra ID. Para más información, consulte Documentación de identidad híbrida.
  • Si el proveedor de identidades es otra solución local, como PingFederate, consulte Instalación personalizada de Microsoft Entra Connect para configurar la federación con el identificador de Microsoft Entra.

Si su aplicación utiliza un Realm de Tomcat para la autenticación (por ejemplo, MemoryRealm o JDBCRealm), planifique migrar a un proveedor de identidades externo o configure el Realm dentro de la imagen del contenedor.

Exposición de la aplicación

De forma predeterminada, no se puede acceder a una aplicación implementada en Azure Container Apps desde fuera del entorno. Para habilitar el acceso externo, configure la entrada:

az containerapp ingress enable \
    --resource-group <RESOURCE_GROUP> \
    --name <APP_NAME> \
    --type external \
    --target-port 8080 \
    --transport auto

Si implementa la aplicación en un entorno administrado con su propia red virtual, determine el nivel de accesibilidad de la aplicación para permitir solo la entrada pública o únicamente desde la red virtual. Para obtener más información, consulte Networking in Azure Container Apps environment.

Después de la migración

Después de completar la migración, compruebe que la aplicación funciona según lo previsto. En las secciones siguientes se describen las recomendaciones para hacer que la aplicación sea más nativa de la nube y sea operativamente sólida.

Mejora de la preparación operativa

Las siguientes recomendaciones le ayudan a reforzar las prácticas de confiabilidad, observabilidad e implementación de la aplicación migrada.

  • Canalizaciones de CI/CD: agregue una canalización de implementación para implementaciones automáticas y coherentes. Las instrucciones están disponibles para Azure Pipelines y Acciones de GitHub.
  • Implementación azul-verde: use revisiones de aplicaciones de contenedor, etiquetas de revisión y pesos de tráfico de entrada para probar los cambios de código en producción antes de que estén disponibles para los usuarios finales. Para obtener más información, vea Despliegue Azul-Verde en Azure Container Apps.
  • Enlaces de servicio: agregue enlaces de servicio para conectar la aplicación a bases de datos de Azure admitidas. Los enlaces de servicio eliminan la necesidad de proporcionar información de conexión, incluidas las credenciales, a las aplicaciones de Spring Boot.
  • Métricas de JVM: Permite a la pila de desarrollo de Java recopilar métricas del núcleo de la JVM. Para obtener más información, consulte Java métricas para aplicaciones de Java en Azure Container Apps.
  • Alertas: agregue reglas de alertas y grupos de acciones de Azure Monitor para detectar y abordar rápidamente condiciones aberantes. Para obtener más información, consulte Configurar alertas en Azure Container Apps.
  • Redundancia de zona: replique la aplicación entre zonas de disponibilidad habilitando la redundancia de zona. La carga del tráfico se equilibra y se dirige automáticamente a las réplicas si se produce una interrupción en la zona. Para más información, consulte Confiabilidad en Azure Container Apps.
  • Firewall de aplicaciones web: proteja su aplicación de contenedor de vulnerabilidades comunes mediante el uso de Web Application Firewall en Application Gateway. Para obtener más información, consulte Proteger Aplicaciones de Contenedor de Azure con el Firewall de Aplicaciones Web en una Puerta de Enlace de Aplicación.

Recomendaciones específicas de Tomcat

  • Para mejorar el rendimiento, evalúe los elementos del archivo logging.properties . Considere la posibilidad de eliminar o reducir el volumen de la salida de registros.

  • Considere la posibilidad de supervisar el tamaño de la caché de código y agregar los parámetros -XX:InitialCodeCacheSize y -XX:ReservedCodeCacheSize a la JAVA_OPTS variable del Dockerfile para optimizar aún más el rendimiento. Para obtener más información, consulte Códecache Tuning en la documentación de Oracle.

Contenido relacionado

  • Last updated on