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

En esta guía se describe lo que debe tener en cuenta cuando quiera 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 (guía planeada)
• Migración de aplicaciones JAR ejecutables a Azure Virtual Machines (guía 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 verdaderamente singular.
• 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 contenga 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:

• Azure Cache for Redis
• Azure Cosmos DB
• Otra base de datos externa, como Azure SQL, Azure Database for MySQL o Azure Database for PostgreSQL.
• Azure Storage, que se usa para almacenar datos no estructurados o incluso objetos serializados.

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 proporciona almacenamiento permanente y se puede compartir entre varios contenedores. Para obtener más información, consulte Cómo utilizar los 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 desee considerar mover contenido estático a Azure Blob Storage y agregar Azure CDN para descargas ultrarrápidas a nivel global. Para obtener más información, vea Static website hosting in Azure Storage and Quickstart: Integrate an Azure storage account with 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 su 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 cuando sea necesario. Hemos proporcionado una implementación de ejemplo para su uso en Uploading y la precarga de contenido estático de CDN 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, puede que tenga que reemplazar cualquier uso de / o \ en las rutas de acceso 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 manualmente e implementa una aplicación contenedorizada en Azure Container Apps, tendrá control total sobre la implementación, incluidas las versiones jrE/JDK.

Para la implementación desde 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 admitidas de Java en su entorno actual y, a continuación, continúe con los pasos de migración restantes. 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.

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 obtener versiones compatibles de Java, Spring Boot y Spring Cloud, así como instrucciones para actualizarlas, consulte Java en Azure Container Apps información general.

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

La aplicación efímera, como los trabajos cron de Unix o las aplicaciones en corto plazo basadas en el marco de Spring Batch, debe ejecutarse como un trabajo en Azure Container Apps. Para obtener más información, consulte Jobs en Azure Container Apps. Si la aplicación es una aplicación de larga duración y ejecuta tareas periódicamente mediante un marco de programación como Cuarzo o Spring Batch, Azure Container Apps puede 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 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 , como la versión del complemento :

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 los agentes de gestión del rendimiento que utilizan 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 medir el rendimiento de la aplicación, pero aún no ha integrado ningún APM, considere la posibilidad de 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:

• Repositorios de JPA
• Repositorios de JDBC
• Repositorios de Cassandra
• Repositorios de MongoDB

Intermediarios de mensajes JMS

Identifique el broker o los brokers en uso buscando 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 identificado el broker o los brokers 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.

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 sesión se almacenan en caché a través de Spring Session buscando la configuración respectiva (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:

• Para la configuración de OAuth2, consulte la referencia de Spring Security.
• Para más información sobre la configuración de Auth0 en Spring Security, consulte la documentación de Auth0 en Spring Security.
• Para más información sobre la configuración de PingFederate en Spring Security, consulte las instrucciones sobre cómo usar Auth0 con PingFederate.

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 configurar mediante un archivo de configuración o una variable de entorno según sea necesario.

Todos los demás recursos externos

No es factible documentar todas las dependencias externas posibles en esta guía. Es su responsabilidad verificar que pueda satisfacer todas las dependencias externas de su 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.

Distribución y replicación geográfica de documentos

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

Creación de un entorno de Azure Container Apps e implementación de aplicaciones

Aprovisione una instancia de Azure Container Apps en la suscripción de Azure. El entorno de hospedaje seguro se crea junto con él. Para obtener más información, consulte Quickstart: Implementación de la primera aplicación contenedora mediante el portal de Azure.

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

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

Después de implementar 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 incluir Azure Monitor Log Analytics, Azure Centro de eventos 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 instrucciones de configuración detalladas, consulte Log storage and monitoring options in 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 para montar en el contenedor a través de los ajustes de la aplicación y alinearla 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 todos los certificados a KeyVault

Azure Containers Apps admite 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 proporcionado por Azure Container Apps. Usar Azure Key Vault para administrar certificados es un enfoque recomendado. Para obtener más información, vea Certificates 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 desde una imagen de contenedor como desde el 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 la aplicación no usa un APM compatible, Azure Application Insights es una opción. Para obtener más información, consulte Using Azure Monitor Application Insights with Spring Boot.

Implementación de la aplicación

Implemente cada uno de los microservicios migrados (no incluidos Spring Cloud Config Server y Spring Cloud Service Registry), como se describe en Deploy 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 Administrar 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 identidades es Microsoft Entra ID, no se deben realizar cambios.
• 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 el tema Instalación personalizada de Microsoft Entra Connect para configurar la federación con Microsoft Entra ID. Como alternativa, considere usar Spring Security para integrar su proveedor de identidad 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 una dirección URL de aplicación. Si su aplicación está desplegada en el contexto de un entorno administrado con su propia red virtual, debe determinar el nivel de accesibilidad de la aplicación para permitir el ingreso público o el ingreso únicamente desde su red virtual. Para obtener más información, consulte Networking in Azure Container Apps environment.

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, vea Configuración de la configuración del componente Eureka Server for Spring en Azure Container Apps. A continuación, modifique los clientes de la aplicación para que usen el Load Balancer de Spring Client. Spring Client Load Balancer permite al cliente obtener direcciones de todas las instancias en ejecución de la aplicación y buscar una instancia que funcione si otra instancia se daña o no responde. Para obtener más información, consulte Spring Tips: Spring Cloud Load Balancer 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 proporciona un único punto de conexión 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 Configuración de la configuración del componente Config Server for 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 configuración de Git, 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 comparten entre todas las aplicaciones del 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.

• Considere agregar el componente gestionado por Admin para Spring para habilitar una interfaz administrativa para las aplicaciones web de Spring Boot que expongan los endpoints del actuator. Para obtener más información, consulte Configurar el componente administrador 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 para GitHub Actions.

• 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, consulte el Despliegue Blue-Green en Azure Container Apps.

• Considere la posibilidad de agregar enlaces de servicio para conectar la aplicación a 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.

• Considere la posibilidad de habilitar la pila de desarrollo de Java para recopilar métricas principales de JVM para las aplicaciones. Para obtener más información, consulte Java métricas para aplicaciones de Java en Azure Container Apps.

• Considere la posibilidad de agregar Azure Monitor reglas de alertas y grupos de acciones para detectar y abordar rápidamente condiciones aberantes. Para obtener más información, consulte Configurar alertas en Azure Container Apps.

• Considere la posibilidad de replicar la aplicación en las zonas de la región habilitando la redundancia de zona 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 Reliability en Azure Container Apps.

• Considere la posibilidad de proteger Azure Container Apps frente a vulnerabilidades de seguridad comunes mediante 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.