Migración de aplicaciones de Spring Boot a Azure App Service

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

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)

Cambio a una plataforma compatible

App Service ofrece versiones específicas de Java SE. Para garantizar la compatibilidad, migre la aplicación a una de las versiones admitidas de su entorno actual antes de continuar con cualquiera de los pasos 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 la versión actual que usa Azure App Service, descargue Zulu 8 si tiene previsto usar el tiempo de ejecución de Java 8, o Zulu 11 si tiene previsto usar el tiempo de ejecución de Java 11.

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/directory, en un archivo llamado application.properties o application.yml. Además, compruebe las variables de entorno de la implementación de producción para obtener las opciones de configuración pertinentes.

Bases de datos

Identifique la cadena de conexión de todas las bases de datos SQL.

En el caso de una aplicación de Spring Boot, las cadenas de conexión suelen aparecer en los archivos de configuración.

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

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 de Spring Boot que usan agentes exclusivos suelen contener las dependencias directamente en las bibliotecas de controladores de JMS de los agentes. A continuación se muestra un ejemplo de un archivo build.gradle:

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

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.

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=tryandguess

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: big$ecr3t

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:

• 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.

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 de un servicio de aplicación.

Secretos de inventario

Contraseñas y cadenas seguras

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, es probable que estas cadenas se encuentren 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 back-end 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>

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

Para usar el sistema de archivos en el servidor de aplicaciones será necesario cambiar la configuración o, en raras ocasiones, la arquitectura. Puede identificar algunos o todos los escenarios siguientes.

Contenido estático de solo lectura

Si su aplicación actualmente sirve contenido estático, necesitará una ubicación alternativa para él. Quizás quiera considerar la posibilidad de mover el contenido estático a Azure Blob Storage y agregar Azure CDN para tener descargas de alta velocidad 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 su aplicación permite que haya contenido estático que la aplicación carga o produce, pero que es inmutable una vez creado, puede usar Azure Blob Storage y Azure CDN con una función de Azure para controlar las cargas y la actualización de la red CDN. Hemos proporcionado una implementación de ejemplo para su uso en Cargar y carga previa en CDN de contenido estático con Azure Functions.

Casos especiales

Algunos escenarios de producción pueden requerir otros cambios o imponer limitaciones adicionales. Aunque estos escenarios no son frecuentes, es importante asegurarse de que no son aplicables a la aplicación o que se han resuelto correctamente.

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

Los trabajos programados, como las tareas del programador de Quartz o los trabajos de cron, no se pueden usar con App Service. App Service no le impedirá implementar internamente una aplicación que contenga tareas programadas. Sin embargo, si la aplicación se escala horizontalmente, un mismo trabajo programado se podría ejecutar más de una vez por cada período programado. Esta situación puede tener consecuencias no deseadas.

Haga un inventario de todos los trabajos programados, dentro o fuera del proceso de las aplicaciones.

Determinación de si la aplicación contiene código específico del sistema operativo

Si la aplicación contiene código con dependencias en el sistema operativo host, deberá refactorizarla para quitar esas dependencias. Por ejemplo, puede que necesite reemplazar el uso de / o \ en las rutas de acceso del sistema de archivos por File.Separator o Paths.get.

Identificación de todos los procesos externos o demonios en ejecución en los servidores de producción

Tendrá que migrar a otra parte o eliminar los procesos que se ejecuten fuera del servidor de aplicaciones, como los demonios de supervisión.

Identificación del control de solicitudes que no son HTTP o de varios puertos

App Service solo admite un punto de conexión HTTP en un solo puerto. Si la aplicación escucha en varios puertos o acepta solicitudes mediante protocolos distintos de HTTP, no utilice Azure App Service.

Migración

Parametrización de la configuración

Asegúrese de que todas las coordenadas de recursos externos (como las cadenas de conexión de base de datos) y otras configuraciones personalizables se pueden leer desde las variables de entorno. Si va a migrar una aplicación de Spring Boot, toda la configuración debe ser ya externalizable. Para más información, consulte Configuración externalizada en la documentación de Spring Boot.

Este es un ejemplo que hace referencia a una SERVICEBUS_CONNECTION_STRING variable de entorno desde un archivo SERVICEBUS_CONNECTION_STRING

spring.jms.servicebus.connection-string=${SERVICEBUS_CONNECTION_STRING}
spring.jms.servicebus.topic-client-id=contoso1
spring.jms.servicebus.idle-timeout=10000

Aprovisionamiento de un plan de App Service

En la lista de planes de servicio disponibles, seleccione el plan cuyas especificaciones sean igual o superiores a las del hardware de producción actual.

Cree el plan de App Service.

Creación e implementación de aplicaciones web

Tendrá que crear una aplicación web en el plan de App Service (con "Java SE" como pila en tiempo de ejecución) para cada archivo JAR ejecutable que quiera ejecutar.

Aplicaciones de Maven

Si la aplicación se ha creado a partir de un archivo POM de Maven, usaeel complemento Webapp para Maven para crear la aplicación web e implementarla. Para más información, consulte Inicio rápido: Creación de una aplicación de Java en Azure App Service.

Aplicaciones que no son de Maven

Si no puede usar el complemento de Maven, debe aprovisionar la aplicación web con otros mecanismos, como:

• Azure Portal
• CLI de Azure
• Azure PowerShell

Una vez creada la aplicación web, use uno de los mecanismos de implementación disponibles para implementar la aplicación. Si es posible, la aplicación debe cargarse en /home/site/wwwroot/app.jar. Si no quiere cambiar el nombre de archivo JAR a app.jar, puede cargar un script de shell con el comando para ejecutar el archivo JAR. A continuación, pegue la ruta de acceso completa a este script en el cuadro de textoArchivo de inicio de la sección Configuración del portal. El script de inicio no se ejecuta desde el directorio en el que se encuentra. Por lo tanto, use siempre rutas de acceso absolutas para hacer referencia a los archivos del script de inicio (por ejemplo: java -jar /home/myapp/myapp.jar).

Migración de las opciones de tiempo de ejecución de JVM

Si la aplicación requiere opciones de tiempo de ejecución específicas, use el mecanismo más adecuado para especificarlas.

Configuración del dominio personalizado y SSL

Si la aplicación va a ser visible en un dominio personalizado, tendrá que asignarle su aplicación web. Para más información, consulte Tutorial: Asignación de un nombre DNS personalizado existente a Azure App Service.

Después, tendrá que enlazar el certificado SSL de ese dominio a la aplicación web de App Service. Para más información, consulte Protección de un nombre DNS personalizado con un enlace SSL en Azure App Service.

Importación de certificados de back-end

Todos los certificados que se van a comunicar con los sistemas de back-end, como las bases de datos, deben estar disponibles para App Service. Para más información, consulte Adición de un certificado SSL en App Service.

Migración de las coordenadas de recursos externos y otras opciones

Siga estos pasos para migrar las cadenas de conexión y otras opciones de configuración.

spring.jms.servicebus.connection-string=${CUSTOMCONNSTR_SERVICE_BUS}
spring.jms.servicebus.topic-client-id=contoso1
spring.jms.servicebus.idle-timeout=1800000

Migración de los trabajos programados

Para ejecutar trabajos programados en Azure, considere la posibilidad de usar un desencadenador de temporizador para Azure Functions. No es necesario migrar el propio código de trabajo a una función. La función simplemente puede invocar una dirección URL en la aplicación para desencadenar el trabajo. Si estas ejecuciones de trabajos se deben invocar dinámicamente o hay que hacer un seguimiento centralizado, considere la posibilidad de usar Spring Batch.

También puede crear una aplicación lógica con un desencadenador de periodicidad para invocar la dirección URL sin escribir ningún código fuera de la aplicación. Para más información, consulte Introducción: ¿Qué es Azure Logic Apps? y Creación, programación y ejecución de tareas y flujos de trabajo periódicos con el desencadenador de periodicidad en Azure Logic Apps.

Migración y habilitación del proveedor de identidades

Si su aplicación requiere autenticación o autorización, use las siguientes instrucciones para asegurarse de que estén configuradas para tener acceso al proveedor de identidades:

• Si el proveedor de identidades es Azure Active Directory, no es necesario hacer ningún cambio.
• Si el proveedor de identidades es un bosque de Active Directory local, considere la posibilidad de implementar una solución de identidad híbrida con Azure Active Directory. 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 Azure AD Connect para configurar la federación con Azure Active Directory. Como alternativa, considere la posibilidad de usar Spring Security para usar el proveedor de identidades mediante OAuth2/OpenID Connect o SAML.

Reinicio y prueba de humo

Por último, tendrá que reiniciar la aplicación web para aplicar todos los cambios de la configuración. Tras completar el reinicio, compruebe que la aplicación se está ejecutando correctamente.

Después de la migración

Ahora que ha migrado la aplicación a Azure App Service, debe comprobar que funciona como se espera. Una vez hecho esto, tenemos algunas recomendaciones que pueden hacer que su aplicación sea más nativa de la nube.

Recomendaciones

• Si ha optado por usar el directorio /home para el almacenamiento de archivos, considere la posibilidad de reemplazarlo por Azure Storage.

• Si tiene una configuración en el directorio /home que contiene cadenas de conexión, claves SSL y otra información secreta, considere la posibilidad de usar Azure Key Vault y una inyección de parámetros con la configuración de la aplicación siempre que sea posible.

• Considere la posibilidad de usar espacios de implementación para realizar implementaciones confiables sin tiempo de inactividad.

• Diseñe e implemente una estrategia de DevOps. Para mantener la confiabilidad y, al mismo tiempo, aumentar la velocidad de desarrollo, considere la posibilidad de automatizar las implementaciones y pruebas con Azure Pipelines. Si usa espacios de implementación, puede automatizar la implementación en un espacio y después cambiar de espacio.

• Diseñe e implemente una estrategia de continuidad empresarial y recuperación ante desastres. En el caso de las aplicaciones críticas, considere la posibilidad de usar una arquitectura de implementación de varias regiones.