Introducción a la migración de aplicaciones

Artículo
02/05/2025

Nota:

Los planes de Básico, Estándar y Enterprise quedarán en desuso a partir de mediados de marzo de 2025, con un período de retiro de 3 años. Se recomienda realizar la transición a Azure Container Apps. Para más información, consulte el anuncio de retirada de Azure Spring Apps.

El plan de consumo estándar y dedicado quedará obsoleto a partir del 30 de septiembre de 2024, con un cierre completo al cabo de seis meses. Se recomienda realizar la transición a Azure Container Apps. Para obtener más información, consulte Migrar el plan de consumo y dedicado Azure Spring Apps Standard a Azure Container Apps.

Este artículo se aplica a: Enterprise ✅ Básico/Estándar ✅

Este artículo proporciona información general sobre un enfoque de migración de aplicaciones de Azure Spring Apps a Azure Container Apps.

Requisitos previos

Una instancia de Azure Spring Apps existente.
Una instancia de Azure Container Apps existente. Para obtener más información, consulte Inicio rápido: implementación de la primera aplicación contenedora mediante Azure Portal.

Implementar una aplicación

Azure Container Apps permite realizar la implementación desde registros de contenedor, como Azure Container Registry (ACR) o Docker Hub. Para la implementación, puede usar herramientas como Azure Portal, la CLI de Azure u otras. En el ejemplo siguiente, se muestra cómo implementar una aplicación en el entorno administrado de destino my-container-apps. Para obtener más información, consulte Implementar su primera aplicación de contenedor con containerapp up o Implementar su primera aplicación de contenedor con Azure Portal.

az containerapp up \
    --resource-group my-container-apps \
    --name my-container-app \
    --location centralus \
    --environment 'my-container-apps' \
    --image mcr.microsoft.com/k8se/quickstart:latest \
    --target-port 80 \
    --ingress external

Azure Container Apps ofrece ahora una característica en versión preliminar para las aplicaciones Java. Esta característica permite a los usuarios implementar aplicaciones directamente desde un archivo JAR o código fuente desde un repositorio local o de código. Se recomienda implementar aplicaciones de contenedor utilizando una imagen de contenedor.

Variables de entorno

Azure Container Apps permite configurar variables de entorno. Puede configurarlas cuando cree una nueva aplicación o posteriormente mediante la creación de una nueva revisión.

Para cambiar las variables de entorno en Azure Portal, debe crear una nueva revisión explícitamente. Cuando utilice la CLI de Azure, puede actualizar la aplicación con el comando az containerapp update, como se muestra en el ejemplo siguiente, que crea una nueva revisión automáticamente. Es importante no duplicar las variables de entorno. Si varias variables tienen el mismo nombre, solo surte efecto la última de la lista.

az containerapp update \
    --resource-group <RESOURCE_GROUP_NAME> \
    --name <APP NAME> \
    --set-env-vars <VAR_NAME>=<VAR_VALUE>

Azure Container Apps también proporciona variables de entorno integradas. Estas ofrecen metadatos de plataforma útiles durante el tiempo de ejecución. Para obtener más información, consulte la sección Variables de entorno integradas de Administración de variables de entorno en Azure Container Apps.

Secretos

Azure Container Apps permite almacenar de forma segura valores de configuración confidenciales, denominados secretos. Estos secretos se definen a nivel de aplicación como pares de nombre/valor y son accesibles para todas las revisiones de la aplicación de contenedor.

Se recomienda guardar los secretos en Azure Key Vault, en lugar de escribirlos directamente. Puede hacer referencia al valor de cada secreto en Azure Key Vault utilizando uno de los siguientes formatos:

https://myvault.vault.azure.net/secrets/mysecret hace referencia a la versión más reciente de un secreto.
https://myvault.vault.azure.net/secrets/mysecret/<version-ID> hace referencia a una versión específica de un secreto.

En este enfoque, debe habilitar la identidad administrada para la aplicación de contenedor y concederle acceso a Key Vault. La directiva de acceso de Key Vault debe permitir que la aplicación use GET para obtener secretos. Como alternativa, si Key Vault usa el control de acceso basado en roles de Azure, debe asignar el rol de Key Vault Secrets User. Después de configurar la identidad administrada, puede agregar una referencia de Key Vault como un secreto en la aplicación especificando el URI del secreto. A continuación, la aplicación puede recuperar el secreto en el tiempo de ejecución utilizando la identidad administrada.

Tenga en cuenta las siguientes reglas:

La eliminación o modificación de un secreto no afecta automáticamente a las revisiones existentes. Al actualizar o eliminar secretos, debe implementar una nueva revisión o reiniciar una existente para reflejar los cambios.
También puede usar secretos en las reglas de escalado.

Puede usar secretos en las aplicaciones de contenedor haciendo referencia a ellos en variables de entorno o montándolos en volúmenes. En las variables de entorno, el valor del secreto se rellena automáticamente. Como alternativa, puede montar secretos en volúmenes. En este caso, cada secreto se almacena como un archivo con el nombre del secreto como el nombre de archivo y su valor como el contenido del archivo. Esta flexibilidad permite controlar los secretos de forma segura y acceder a ellos dentro del entorno de la aplicación. Para obtener más información, consulte Secretos administrados en Azure Container Apps.

Si la carga de trabajo protege la configuración confidencial y recupera las propiedades de Key Vault con la biblioteca de spring-cloud-azure-starter-keyvault-secrets, puede usar Azure SDK o Spring KeyVault PropertySource en Azure Container Apps. No es necesario cambiar el código durante la migración.

Opciones de JVM

Para imprimir las opciones de JVM en Azure Container Apps, siga los pasos descritos en Compilar una imagen de contenedor desde un archivo JAR o WAR para incluir contenedorizar la aplicación. Puede agregar -XX:+PrintFlagsFinal en el ENTRYPOINT del Dockerfile, como se muestra en el ejemplo siguiente:

# filename: JAR.dockerfile

FROM mcr.microsoft.com/openjdk/jdk:17-mariner

ARG JAR_FILENAME

COPY $JAR_FILENAME /opt/app/app.jar
ENTRYPOINT ["java", "-XX:+PrintFlagsFinal", "-jar", "/opt/app/app.jar"]

Para consultar las opciones de JVM en Azure Container Apps, use la siguiente consulta:

ContainerAppConsoleLogs_CL
| where ContainerAppName_s == "<APP_NAME>"
| where Log_s has_any ('{default}', '{command line}', '{ergonomic}')

El siguiente registro es un ejemplo que muestra las opciones de JVM después de ejecutar una consulta:

size_t MinHeapSize = 8388608 {product} {ergonomic}
size_t MaxHeapSize = 268435456 {product} {ergonomic}

Para ajustar las opciones de JVM en Azure Container Apps, puede agregar opciones de JVM en el ENTRYPOINT del Dockerfile, como se muestra en el ejemplo siguiente:

# filename: JAR.dockerfile

FROM mcr.microsoft.com/openjdk/jdk:17-mariner

ARG JAR_FILENAME

COPY $JAR_FILENAME /opt/app/app.jar
ENTRYPOINT ["java", "-XX:+PrintFlagsFinal", "-Xmx400m", "-Xss200m", "-jar", "/opt/app/app.jar"]

Para obtener más información sobre las opciones de JVM, consulte Opciones de VM de Java HotSpot y Configuración de opciones de JVM.

Storage

Azure Spring Apps y Azure Container Apps admiten el almacenamiento con ámbito de contenedor, lo que significa que los datos almacenados en el contenedor solo están disponibles mientras se ejecuta el contenedor. En Azure Spring Apps, el almacenamiento total de una aplicación es de 5 GiB. Azure Container Apps ofrece un almacenamiento que oscila entre 1 GiB y 8 GiB, según el número total de vCPU asignadas. Este almacenamiento incluye todo el almacenamiento efímero asignado a cada réplica. Para obtener más información, consulte la sección Almacenamiento efímero de Uso de montajes de almacenamiento en Azure Container Apps.

Azure Spring Apps y Azure Container Apps admiten el almacenamiento permanente a través de Azure Files. Azure Container Apps admite el montaje de recursos compartidos de archivos mediante protocolos SMB y NFS. Debe crear una definición de almacenamiento en el entorno administrado y, a continuación, definir un volumen de AzureFile (SMB) o NfsAzureFile (NFS) en una revisión. Puede completar toda la configuración de AzureFile (SMB) en Azure Portal. Para obtener más información, consulte Creación de un montaje de volumen Azure Files en Azure Container Apps. La compatibilidad con el montaje de recursos compartidos NFS está actualmente en versión preliminar. Puede configurarlo utilizando una plantilla de ARM o la CLI de Azure. Para obtener más información, consulte Recursos compartidos de archivos de NFS Azure y la sección Creación de un recurso compartido de archivos de NFS Azure del Tutorial: Creación de un recurso compartido de archivos de NFS Azure y montaje en una máquina virtual Linux utilizando Azure Portal.

Identidad administrada

Cada aplicación de contenedor tiene una identidad administrada asignada por el sistema o varias identidades administradas asignadas por el usuario para acceder a los recursos protegidos de Azure. Para obtener información sobre cómo administrar las identidades y conceder los permisos, consulte Identidades administradas en Azure Container Apps.

Cada aplicación de contenedor tiene un punto de conexión REST interno, accesible a través de la variable de entorno IDENTITY_ENDPOINT, que difiere del punto de conexión usado en Azure Spring Apps. Si la aplicación usa una solicitud HTTP GET directa, debe ajustar el código para obtener el punto de conexión correcto. Si la aplicación usa una identidad administrada a través de la biblioteca cliente de Azure Identity, no necesita ningún cambio de código porque Azure Identity administra este detalle automáticamente.

Cuando una carga de trabajo accede a los recursos protegidos de Azure, debe capturar un token de acceso utilizando el Id. de aplicación o el Id. de cliente de una identidad administrada. En un entorno de Azure Spring Apps, puede establecer el id. de cliente de una identidad administrada asignada por el sistema o asignada por el usuario. Como alternativa, puede dejarlo vacío y dejar que el servicio seleccione el id. de aplicación de una de las identidades administradas. En Azure Container Apps, no se puede especificar explícitamente el id. de aplicación al usar una identidad administrada asignada por el sistema. Sin embargo, el id. de aplicación es necesario cuando se usa una identidad administrada asignada por el usuario.

Sondeos de estado

Azure Container Apps y Azure Spring Apps admiten los tres tipos de sondeos de estado, incluidos el sondeo de inicio, el sondeo de ejecución y el sondeo de preparación. En Azure Container Apps, los sondeos pueden usar el protocolo HTTP o TCP. exec aún no se admite.

En Azure Spring Apps, los valores de sondeo se configuran en el recurso de implementación. En cambio, en Azure Container Apps, la configuración de sondeo se define en el recurso de la aplicación de contenedor. Las siguientes configuraciones están disponibles:

Propiedad	Descripción	Azure Spring Apps	Azure Container Apps
`probeAction`	La acción del sondeo.	Admite `HTTPGetAction`, `TCPSocketAction` y `ExecAction`.	No hay ninguna propiedad para el tipo de acción. El usuario debe usar `httpGet` o `tcpSocket` directamente.
`disableProbe`	Indica si el sondeo está deshabilitado.	Booleano	Booleano
`initialDelaySeconds`	Número de segundos después del que se inicia la instancia de aplicación antes de que se inicien los sondeos.		El valor oscila entre 1 y 60.
`periodSeconds`	Frecuencia, en segundos, con la que se ejecuta el sondeo.	El valor mínimo es 1.	El valor oscila entre 1 y 240, con un valor predeterminado de 10.
`timeoutSeconds`	Número de segundos tras los cuales el sondeo agota el tiempo de espera.	El valor mínimo es 1.	El valor oscila entre 1 y 240, con un valor predeterminado de 1.
`failureThreshold`	El mínimo de errores consecutivos para que el sondeo se considere erróneo después de haberse realizado correctamente.	El valor mínimo es 1.	El valor oscila entre 1 y 10, con un valor predeterminado de 3.
`successThreshold`	El número mínimo de valores correctos consecutivos para que el sondeo se considere correcto después de que se haya producido un error.	El valor mínimo es 1.	El valor oscila entre 1 y 10, con un valor predeterminado de 1.
`terminationGracePeriodSeconds`	La duración opcional en segundos que el pod necesita para finalizar correctamente tras un error de sondeo.	El valor predeterminado es de 90 segundos.	El valor máximo es de 3600 segundos.

Actualmente, no puede configurar los sondeos para Azure Container Apps directamente en Azure Portal. En su lugar, debe configurarlos utilizando una plantilla de ARM o un archivo YAML de aplicación de contenedor a través de la CLI de Azure. Para obtener más información, consulte Sondeos de estado en Azure Container Apps.

Escala

Azure Container Apps admite el escalado horizontal a través de un conjunto de reglas de escalado. Cuando se agrega o cambia una regla, se crea una nueva revisión de la aplicación de contenedor.

El escalado tiene tres categorías de desencadenadores: HTTP, TCP y personalizados. HTTP y TCP se basan en el número de conexiones de solicitud o red. Para obtener más información, consulte Establecer reglas de escalado en Azure Container Apps.

Escala del desencadenador en función de la CPU o la memoria

Las reglas de escalado de aplicaciones de contenedor personalizadas se basan en un escalador KEDA basado en ScaledObject. Puede lograr el escalado con aplicaciones de contenedor basadas en el uso de CPU o memoria mediante el Escalador de CPU y el Escalador de memoria de KEDA.

En el ejemplo siguiente, se muestra una configuración donde se produce un escalado horizontal cuando el uso medio de memoria supera el 25 %. El uso de memoria incluye la memoria usada por la aplicación de contenedor actual y también los pods pertinentes, como los contenedores sidecar internos. KEDA incluye una configuración integrada para evitar que la aplicación de contenedor oscile. Para obtener más información sobre la configuración interna, consulte Establecer reglas de escalado en Azure Container Apps. Debe comprobar el comportamiento durante el tiempo de ejecución para asegurarse de que cumple sus necesidades.

az containerapp create \
    --resource-group MyResourceGroup \
    --name my-containerapp \
    --image my-queue-processor --environment MyContainerappEnv \
    --min-replicas 1 --max-replicas 10 \
    --scale-rule-name memory-scaler \
    --scale-rule-type memory \
    --scale-rule-metadata "type=Utilization" \
                          "value=25"

Escala del desencadenador en función de la métrica de Java

KEDA ofrece un Escalador de Azure Monitor, que permite el escalado en función de las métricas disponibles en Azure Monitor. Puede usar esta característica para escalar las aplicaciones dinámicamente en función de las métricas específicas de Java publicadas en Azure Monitor.

Requisitos previos

Registrar una aplicación en Microsoft Entra ID. Para obtener más información, consulte Inicio rápido: registrar una aplicación con la plataforma de identidad de Microsoft.
Conceda permisos. Asigne a la aplicación registrada el rol de Monitoring Reader para el recurso de Azure Container Apps.

Pasos

Añada secretos. Use el siguiente comando para almacenar el id. de cliente y el secreto de la aplicación de Microsoft Entra en Azure Container Apps como secretos:

az containerapp secret set \
    --resource-group MyResourceGroup \
    --name my-containerapp \
    --secrets activeDirectoryClientId=<Microsoft-Entra-Application-Client-ID> \
              activeDirectoryClientPassword=<Microsoft-Entra-Application-Client-Password>

Defina una regla de escalado. Use el comando siguiente para crear una regla de escalado personalizada que use el escalador de Azure Monitor. Esta regla desencadena acciones de escalado basadas en una métrica de Java específica, como JvmThreadCount, supervisada a través de Azure Monitor.

az containerapp create \
    --resource-group MyResourceGroup \
    --name my-containerapp \
    --image my-queue-processor --environment MyContainerappEnv \
    --min-replicas 1 --max-replicas 10 \
    --scale-rule-name thread-count \
    --scale-rule-type azure-monitor \
    --scale-rule-auth "activeDirectoryClientId=activeDirectoryClientId" \
                      "activeDirectoryClientPassword=activeDirectoryClientPassword" \
    --scale-rule-metadata "activationTargetValue=1" \
                          "metricAggregationInterval=0:1:0" \
                          "metricAggregationType=Maximum" \
                          "metricName=JvmThreadCount" \
                          "resourceGroupName=MyResourceGroup" \
                          "resourceURI=MyContainerAppShortURI" \
                          "subscriptionId=MyResourceID" \
                          "targetValue=30" \
                          "tenantId=MyTenantID"

Detalles de clave

Administración de secretos: las credenciales de la aplicación (id. de cliente y contraseña) se almacenan de forma segura como secretos.
Criterios de escalado: el parámetro metricName identifica la métrica de Java (JvmThreadCount en este caso) que se usa para evaluar cuándo debe producirse el escalado.
Valor de destino: el parámetro targetValue establece el umbral para el escalado, por ejemplo, el escalado cuando el número de subprocesos supera los 30.

Al configurar esta regla, la aplicación de contenedor puede ajustar dinámicamente el número de instancias en función de métricas de rendimiento específicas de Java, lo que mejora la capacidad de respuesta y el uso de recursos.

Compartir a través de

Introducción a la migración de aplicaciones

Requisitos previos

Implementar una aplicación

Variables de entorno

Secretos

Opciones de JVM

Storage

Identidad administrada

Sondeos de estado

Escala

Escala del desencadenador en función de la CPU o la memoria

Escala del desencadenador en función de la métrica de Java

Requisitos previos

Pasos

Detalles de clave

Comentarios

Recursos adicionales