Compartir a través de


Migración de aplicaciones de Spring Boot a Azure Container Apps

En esta guía se describe lo que hay que tener en cuenta para migrar una aplicación de Spring Boot existente para que se ejecute en Azure Container Apps.

Antes de la migración

Para asegurarse de que la migración se realiza correctamente, antes de empezar, complete los pasos de evaluación e inventario descritos en las secciones siguientes.

Si no puede cumplir alguno de los requisitos previos a la migración, consulte las siguientes guías de migración complementarias:

  • Migración de aplicaciones JAR ejecutables a contenedores en Azure Kubernetes Service (planeada)
  • Migración de aplicaciones JAR ejecutables a Azure Virtual Machines (planeada)

Inspección de los componentes de la aplicación

Identificación del estado local

En entornos PaaS, no se garantiza que ninguna aplicación se ejecute exactamente una vez en un momento dado. Aunque configure una aplicación para que se ejecute en una sola instancia, se puede crear una instancia duplicada en los casos siguientes:

  • La aplicación se debe reubicar en un host físico debido a un error o a una actualización del sistema.
  • La aplicación se está actualizando.

En cualquiera de estos casos, la instancia original se queda ejecutándose hasta que la nueva instancia termine de iniciarse. Este patrón puede tener las siguientes implicaciones potencialmente significativas para la aplicación:

  • No se puede garantizar que ningún singleton sea realmente único.
  • Los datos que no se conservan en el almacenamiento externo probablemente se perderán antes de lo que lo harían en un solo servidor físico o máquina virtual.

Antes de migrar a Azure Container Apps, asegúrese de que el código no presente el estado local que no se debe perder ni duplicar. Si el estado local existe, cambie el código para almacenar ese estado fuera de la aplicación. Las aplicaciones compatibles con la nube normalmente almacenan el estado de la aplicación en ubicaciones, como en las siguientes opciones:

Determinación de si se usa el sistema de archivos y cómo

Busque cualquier instancia en la que los servicios lean o escriban en el sistema de archivos local. Identifique dónde se escriben y se leen los archivos temporales o a corto plazo, y dónde se escriben y se leen los archivos de larga duración.

Azure Container Apps ofrece varios tipos de almacenamiento. El almacenamiento efímero puede leer y escribir datos temporales y estar disponible para un contenedor o réplica en ejecución. Azure File incluye almacenamiento permanente y se puede compartir en varios contenedores. Para obtener más información, consulte Uso de montajes de almacenamiento en Azure Container Apps.

Contenido estático de solo lectura

Si su aplicación actualmente trabaja con contenido estático, necesitará una ubicación alternativa para él. Es posible que le convenga mover el contenido estático a Azure Blob Storage y agregar Azure CDN para que las descargas sean mucho más rápidas globalmente. Para más información, consulte Hospedaje de sitios web estáticos en Azure Storage e Inicio rápido: Integración de una cuenta de una instancia de Azure Storage con Azure CDN.

Contenido estático publicado dinámicamente

Si la aplicación admite contenido estático, ya sea cargado o generado por la propia aplicación, que permanece sin cambios después de crearse, puede integrar Azure Blob Storage y Azure CDN. También puede usar una función de Azure para administrar las cargas y activar actualizaciones de CDN cuando sea necesario. Hemos proporcionado una implementación de ejemplo para su uso en Cargar y carga previa en CDN de contenido estático con Azure Functions.

Determinación de si alguno de los servicios contiene código específico del sistema operativo

Si la aplicación contiene código con dependencias en el sistema operativo del host, deberá refactorizarla para quitar esas dependencias. Por ejemplo, es posible que tenga que reemplazar cualquier uso de / o \ en las rutas del sistema de archivos con File.Separator o Paths.get si la aplicación se ejecuta en Windows.

Cambio a una plataforma compatible

Si crea el Dockerfile de forma manual e implementa una aplicación contenedorizada en Azure Container Apps, tendrá control total sobre la implementación, incluidas las versiones de JRE/JDK.

Para realizar la implementación a partir de artefactos, Azure Container Apps también ofrece versiones específicas de Java (8, 11, 17 y 21) y versiones específicas de los componentes de Spring Boot y Spring Cloud. Para garantizar la compatibilidad, migre primero la aplicación a una de las versiones de Java admitidas en su entorno actual antes de continuar con los pasos restantes de la migración. Asegúrese de probar por completo la configuración resultante. Use la versión estable más reciente de la distribución de Linux en dichas pruebas.

Nota:

Esta validación es especialmente importante si el servidor actual se está ejecutando en un JDK no compatible (como Oracle JDK o IBM OpenJ9).

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

java -version

Para conocer las versiones compatibles de Java, Spring Boot y Spring Cloud, así como las instrucciones para actualizarlas, consulte Introducción a Java en Azure Container Apps.

Determinación de si la aplicación se basa en trabajos programados

Las aplicaciones efímeras, como los trabajos cron de Unix o las aplicaciones de corta duración basadas en plataforma de Spring Batch, deben ejecutarse como un trabajo en Azure Container Apps. Para obtener más información, consulta Trabajos en Azure Container Apps. Si la aplicación es una aplicación de larga duración y ejecuta tareas periódicamente mediante un modelo de programación como Quartz o Spring Batch, Azure Container Apps podrá hospedar esa aplicación. Sin embargo, la aplicación debe controlar el escalado correctamente para evitar las condiciones de carrera en las que las mismas instancias de la aplicación se ejecutan más de una vez por período programado durante el escalado horizontal o la actualización gradual.

Realice un inventario de todas las tareas programadas que se ejecutan en los servidores de producción, dentro o fuera del código de la aplicación.

Identificación de las versiones de Spring Boot

Examine las dependencias de cada aplicación que se va a migrar para determinar su versión de Spring Boot.

Maven

En los proyectos de Maven, la versión de Spring Boot se encuentra normalmente en el elemento <parent> del archivo POM:

    <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>3.3.3</version>
        <relativePath/> <!-- lookup parent from repository -->
    </parent>
Gradle

En los proyectos de Gradle, la versión de Spring Boot se encontrará normalmente en la sección plugins, como la versión del complemento org.springframework.boot:

plugins {
  id 'org.springframework.boot' version '3.3.3'
  id 'io.spring.dependency-management' version '1.1.6'
  id 'java'
}

Para cualquier aplicación que use versiones de Spring Boot anteriores a la 3.x, consulte la guía de migración de Spring Boot 2.0 o la Guía de migración de Spring Boot 3.0 para actualizarlas a una versión de Spring Boot compatible. Para ver las versiones compatibles, consulte las versiones de Spring Boot y Spring Cloud.

Identificación de soluciones de agregación de registros

Identifique todas las soluciones de agregación de registros que estén usando las aplicaciones que va a migrar. Debe configurar los ajustes de diagnóstico en la migración para que los eventos registrados estén disponibles para su consumo. Para obtener más información, consulte la sección Asegurar el registro de la consola y configurar las opciones de diagnóstico.

Identificación de los agentes de administración del rendimiento de la aplicación (APM)

Identifique qué agentes de gestión del rendimiento de las aplicaciones que usen sus aplicaciones. Azure Containers Apps no ofrece compatibilidad integrada con la integración de APM. Debe preparar la imagen de contenedor o integrar la herramienta de APM directamente en el código. Si quiere analizar el rendimiento de la aplicación, pero aún no ha integrado ningún APM, puede usar Azure Application Insights. Para obtener más información, consulte la sección Migración.

Recursos externos de inventario

Identifique los recursos externos, tales como los orígenes de datos, los agentes de mensajes JMS y las direcciones URL de otros servicios. En las aplicaciones de Spring Boot, normalmente encontrará la configuración de estos recursos en la carpeta src/main/resources, en un archivo llamado application.properties o application.yml.

Bases de datos

En el caso de una aplicación de Spring Boot, las cadenas de conexión suelen aparecer en archivos de configuración cuando depende de una base de datos externa. A continuación se muestra un ejemplo de un archivo application.properties:

spring.datasource.url=jdbc:mysql://localhost:3306/mysql_db
spring.datasource.username=dbuser
spring.datasource.driver-class-name=com.mysql.jdbc.Driver

A continuación se muestra un ejemplo de un archivo application.yaml:

spring:
  data:
    mongodb:
      uri: mongodb://mongouser:deepsecret@mongoserver.contoso.com:27017

Consulte la documentación de Spring Data para ver posibles escenarios de configuración:

Agentes de mensajes de JMS

Identifique a los agentes en uso; para ello, busque las dependencias pertinentes en el manifiesto de compilación (normalmente, un archivo pom.xml o build.gradle).

Por ejemplo, una aplicación de Spring Boot con ActiveMQ normalmente contendría esta dependencia en su archivo pom.xml:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-activemq</artifactId>
</dependency>

Las aplicaciones Spring Boot que utilizan brokers comerciales suelen contener dependencias directas de las bibliotecas de controladores JMS de los brokers. A continuación se muestra un ejemplo de un archivo build.gradle:

    dependencies {
      ...
      compile("com.ibm.mq:com.ibm.mq.allclient:9.4.0.5")
      ...
    }

Una vez identificados los agentes en uso, busque la configuración correspondiente. En las aplicaciones de Spring Boot, normalmente se encuentran en los archivos application.properties y application.yml, en el directorio de la aplicación.

Nota:

Microsoft recomienda usar 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.

A continuación, se muestra un ejemplo de ActiveMQ de un archivo application.properties:

spring.activemq.brokerurl=broker:(tcp://localhost:61616,network:static:tcp://remotehost:61616)?persistent=false&useJmx=true
spring.activemq.user=admin
spring.activemq.password=<password>

Para más información sobre la configuración de ActiveMQ, consulte la documentación de Spring Boot sobre mensajería.

A continuación, se muestra un ejemplo de IBM MQ de un archivo application.yaml:

ibm:
  mq:
    queueManager: qm1
    channel: dev.ORDERS
    connName: localhost(14)
    user: admin
    password: <password>

Para más información sobre la configuración de IBM MQ, consulte la documentación IBM MQ Spring sobre componentes.

Identificación de cachés externas

Identifique cualquier caché externa en uso. Con frecuencia, Redis se usa a través de Spring Data Redis. Para más información de configuración, consulte la documentación de Spring Data Redis.

Determine si los datos de la sesión se almacenan en memoria caché mediante Spring Session; para ello, consulte la configuración correspondiente (en Java o XML).

Proveedores de identidades

Identifique los proveedores de identidades que la aplicación usa. Para más información sobre cómo configurar los proveedores de identidades, consulte lo siguiente:

Identificación de clientes que dependan de un puerto no estándar

Azure Container Apps permite exponer el puerto según la configuración de recursos de Azure Container Apps. Por ejemplo, una aplicación de Spring Boot escucha el puerto 8080 de forma predeterminada, pero se puede establecer con server.port o la variable de entorno SERVER_PORT según proceda.

Todos los demás recursos externos

No es factible documentar todas las dependencias externas posibles en esta guía. Es responsabilidad del equipo comprobar que puede cumplir todas las dependencias externas de la aplicación después de la migración.

Orígenes y secretos de configuración de inventario

Contraseñas y cadenas seguras de inventario

Compruebe si hay cadenas secretas y contraseñas en todas las propiedades, los archivos de configuración y las variables de entorno de las implementaciones de producción. En una aplicación de Spring Boot, estas cadenas se encuentran normalmente en application.properties o application.yml.

Certificados de inventario

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 de los servidores de producción, ejecute el siguiente comando:

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

Inspección de la arquitectura de implementación

Requisitos de hardware para cada servicio

Documente la siguiente información de la aplicación de Spring Boot:

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

Documentación de la distribución y replicación geográfica

Determine si las instancias de la aplicación de Spring Boot están distribuidas actualmente entre varias regiones o centros de datos. Documente los requisitos de tiempo de actividad o el Acuerdo de Nivel de Servicio de las aplicaciones que va a migrar.

Migración

Crear un entorno de Azure Container Apps e implementar aplicaciones

Aprovisione una instancia de Azure Container Apps en su suscripción de Azure. El entorno de hospedaje seguro se crea junto con él. Para obtener más información, consulte Inicio rápido: implementación de la primera aplicación contenedora mediante Azure Portal.

Comprobación del registro de la consola y configuración de los valores de diagnóstico

Configure el registro para garantizar todo lo que se genere se enrute a la consola y no a los archivos.

Una vez implementada una 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 los registros. Estos destinos pueden ser Azure Monitor Log Analytics, Azure Event Hubs o incluso otras soluciones de supervisión de terceros. También tiene la opción de deshabilitar los datos de registro y ver los registros solo en tiempo de ejecución. Para obtener indicaciones detalladas sobre la 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, deberá configurar el almacenamiento persistente para reemplazar el sistema de archivos local. Puede indicar la ruta de acceso que se va a montar en el contenedor a través de los ajustes de la aplicación y enlazarla con la ruta de acceso que usa la aplicación. Para obtener más información, consulte Uso de montajes de almacenamiento en Azure Container Apps.

Migración de todos los certificados a KeyVault

Azure Containers Apps acepta la comunicación segura entre aplicaciones. La aplicación no necesita administrar el proceso de establecimiento de comunicaciones seguras. Puede cargar el certificado privado en Azure Container Apps o usar un certificado administrado gratuito facilitado por Azure Container Apps. Se recomienda usar Azure Key Vault para administrar certificados. Para obtener más información, consulte Certificados en Azure Container Apps.

Configuración de las integraciones de administración del rendimiento de la aplicación (APM)

Tanto si la aplicación se implementa a partir de una imagen de contenedor como del código, Azure Container Apps no interfiere con la imagen o el código. Por lo tanto, la integración de la aplicación con una herramienta de APM depende de sus propias preferencias e implementación.

Si su aplicación no utiliza un APM compatible, tiene la opción de usar Azure Application Insights. Para más información, consulte Uso de Application Insights de Azure Monitor con Spring Boot.

Implementación de la aplicación

Implemente cada uno de los microservicios migrados (sin incluir Spring Cloud Config Server y Spring Cloud Service Registry), tal como se describe en Implementación de Azure Container Apps con el comando az containerapp up.

Configuración de secretos por servicio y configuraciones externalizadas

Puede insertar opciones de configuración en cada aplicación como variables de entorno. Puede establecer estas variables como entradas manuales o como referencias a secretos. Para obtener más información sobre la configuración, consulte Administración de variables de entorno en Azure Container Apps.

Migración y habilitación del proveedor de identidades

Si alguna de las aplicaciones de Spring Cloud requiere autenticación o autorización, asegúrese de que estén configuradas para tener acceso al proveedor de identidades:

  • Si el proveedor de identidad es Microsoft Entra ID, no debería ser necesario realizar ningún cambio.
  • Si el proveedor de identidad 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 identidad es otra solución local, como PingFederate, consulte el tema Instalación personalizada de Microsoft Entra Connect para configurar la federación con Microsoft Entra ID. Como alternativa, considere la posibilidad de usar Spring Security para usar el proveedor de identidades mediante OAuth2/OpenID Connect o SAML.

Exposición de la aplicación

De forma predeterminada, se puede acceder a una aplicación implementada en Azure Container Apps a través de la dirección URL de una aplicación. Si la aplicación se implementa en el contexto de un entorno administrado con su propia red virtual, debe determinar el nivel de accesibilidad de la aplicación para permitir solo la entrada o entrada pública a través de la red virtual. Para más información, consulte Redes en el entorno de Azure Container Apps.

Después de la migración

Ahora que ha completado la migración, compruebe que la aplicación funciona como se espera. Después, tenga en cuenta las recomendaciones siguientes para que su aplicación se comporte de forma más nativa en la nube.

  • Considere la posibilidad de habilitar la aplicación para que funcione con el registro de Spring Cloud. Este componente permite que otras aplicaciones de Spring y clientes implementados detecten dinámicamente la aplicación. Para obtener más información, consulte Configurar las opciones de Eureka Server para el componente de Spring en Azure Container Apps. A continuación, modifique los clientes de la aplicación para que usen el equilibrador de carga de Spring Client. El equilibrador de carga de Spring Client permite al cliente obtener direcciones de todas las instancias en ejecución de la aplicación y detectar una instancia que funcione si otra instancia queda dañada o deja de responder. Para obtener más información, consulte Consejos sobre Spring: Equilibrador de carga de Spring Cloud en el blog de Spring.

  • En lugar de convertir la aplicación en pública, considere la posibilidad de agregar una instancia de Spring Cloud Gateway. Spring Cloud Gateway ofrece un punto de conexión único para todas las aplicaciones implementadas en el entorno de Azure Container Apps. Si ya hay implementada una instancia de Spring Cloud Gateway, asegúrese de que haya configurada una regla destinada a dirigir el tráfico a la aplicación recién implementada.

  • Tiene la opción de agregar un servidor de Spring Cloud Config Server para administrar de forma centralizada y configurar el control de versiones de todas las aplicaciones de Spring Cloud. En primer lugar, cree un repositorio de Git para hospedar la configuración y configurar la instancia de la aplicación para usarla. Para obtener más información, consulte Configurar las opciones de Config Server para el componente de Spring en Azure Container Apps. A continuación, migre la configuración siguiendo estos pasos:

    1. En el directorio src/main/resources de la aplicación, cree el archivo bootstrap.yml con el siguiente contenido:

        spring:
          application:
            name: <your-application-name>
      
    2. En el repositorio de Git de configuración, cree el archivo <your-application-name>.yml, donde your-application-name es el mismo que en el paso anterior. Mueva los ajustes del archivo application.yml en src/main/resources al nuevo archivo que acaba de crear. Si la configuración estaba anteriormente en un archivo .properties, deberá convertirlo primero a formato YAML. Puede encontrar herramientas en línea o complementos de IntelliJ para realizar esta conversión.

    3. Cree el archivo application.yml en el directorio anterior. Puede usar este archivo para definir la configuración y los recursos que se van a compartir entre todas las aplicaciones en el entorno de Azure Container Apps. Estos valores suelen incluir orígenes de datos, configuración de registro, configuración de Spring Boot Actuator y otros.

    4. Confirme e inserte estos cambios en el repositorio de Git.

    5. Elimine el archivo application.properties o application.yml de la aplicación.

  • Podría agregar el componente administrado Admin para Spring para habilitar una interfaz administrativa para las aplicaciones web de Spring Boot que expongan los puntos conexión del accionador. Para obtener más información, consulte Configuración del componente Admin de Spring Boot en Azure Container Apps.

  • Considere la posibilidad de agregar una canalización de implementación para realizar implementaciones automáticas y coherentes. Hay instrucciones disponibles para Azure Pipelines y Acciones de GitHub.

  • Tenga en cuenta que puede usar revisiones de aplicaciones de contenedor, etiquetas de revisión y volúmenes de tráfico de entrada para habilitar la implementación azul-verde, lo que le permite probar los cambios en el código en fase de producción antes de que estén disponibles para algunos o todos los usuarios finales. Para obtener más información sobre la implementación azul-verde, consulte Implementación azul-verde en Azure Container Apps.

  • Considere la posibilidad de agregar enlaces de servicio para conectar la aplicación a las bases de datos de Azure admitidas. Estos enlaces de servicio eliminarán la necesidad de proporcionar información de conexión, incluidas las credenciales, a las aplicaciones de Spring Cloud.

  • Tiene la opción de habilitar la pila de desarrollo de Java para recabar los indicadores principales de JVM para las aplicaciones. Para obtener más información, consulte Métricas de Java para aplicaciones Java en Azure Container Apps.

  • Considere la posibilidad de agregar reglas de alerta y grupos de acciones de Azure Monitor para detectar y resolver rápidamente las condiciones anómalas. Para obtener más información, consulte Crear alertas en Azure Container Apps.

  • Plantéese la posibilidad de replicar la aplicación en las zonas de la región habilitando la redundancia de zona de Azure Container Apps. 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 obtener más información sobre la configuración redundante, consulte Fiabilidad en Azure Container Apps.

  • Considere la posibilidad de proteger Azure Container Apps de ataques y vulnerabilidades comunes mediante Web Application Firewall en Application Gateway. Para obtener más información, consulte Proteger Azure Container Apps con Web Application Firewall en Application Gateway.