Leer en inglés

Compartir vía

Implementar y configurar una aplicación Tomcat, JBoss o Java SE en Azure App Service

  • Artículo
Elija cómo se hospeda la aplicación Java

En este artículo se muestra la configuración más común de implementación y runtime para aplicaciones Java en App Service. Si nunca ha usado Azure App Service, debe leer primero la Guía de inicio rápido de Java. Encontrará respuestas a las preguntas generales sobre el uso de App Service que no son específicas del desarrollo de Java en Preguntas más frecuentes sobre Azure App Service.

Azure App Service ejecuta aplicaciones web Java en un servicio totalmente administrado en tres variantes:

  • Java SE: puede ejecutar una aplicación implementada como un paquete JAR que contenga un servidor incrustado (como Spring Boot, Dropwizard, Quarkus o uno con un servidor de Tomcat o Jetty incrustado).
  • Tomcat: el servidor de Tomcat integrado puede ejecutar una aplicación implementada como un paquete WAR.
  • JBoss EAP: admitido para aplicaciones Linux en los niveles de precios, Premium v3 y Aislado v2. El servidor JBoss EAP integrado puede ejecutar una aplicación implementada como un paquete WAR o EAR.

Visualización de la versión de Java

Para mostrar la versión actual de Java, ejecute el siguiente comando en Cloud Shell:

Azure CLI 
az webapp config show --resource-group <resource-group-name> --name <app-name> --query linuxFxVersion

Para mostrar todas las versiones compatibles de Java, ejecute el siguiente comando en Cloud Shell:

Azure CLI 
az webapp list-runtimes --os linux | grep "JAVA\|TOMCAT\|JBOSSEAP"

Obtención de la versión de Java en el contenedor de Linux

Para obtener información de versión más detallada en el contenedor de Linux, abra una sesión SSH con el contenedor. Estos son algunos ejemplos de lo que puede ejecutar.

Para ver la versión de Java en la sesión SSH:

Bash 
java -version

Para ver la versión del servidor de Tomcat en la sesión SSH:

Bash 
sh /usr/local/tomcat/version.sh

O bien, si el servidor de Tomcat está en una ubicación personalizada, busque version.sh con:

Bash 
find / -name "version.sh"

Para ver la versión del servidor de JBoss en la sesión SSH:

Bash 
$JBOSS_HOME/bin/jboss-cli.sh --connect --commands=:product-info

Para obtener más información sobre la compatibilidad con versiones, consulte Directiva de compatibilidad de runtime de idiomas de App Service.

Implementación de la aplicación

Build Tools

Maven

Con el complemento Maven para Azure Web Apps, puede preparar fácilmente el proyecto de Java de Maven con un comando en la raíz del proyecto:

shell 
mvn com.microsoft.azure:azure-webapp-maven-plugin:2.13.0:config

Este comando agrega un complemento azure-webapp-maven-plugin y una configuración relacionada al pedirle que seleccione una aplicación web de Azure existente o que cree una nueva. Durante la configuración, intenta detectar si la aplicación debe implementarse en Java SE, Tomcat o (solo Linux) JBoss EAP. Luego, puede implementar la aplicación Java en Azure mediante el siguiente comando:

shell 
mvn package azure-webapp:deploy

Esta es una configuración de ejemplo de pom.xml:

XML 
<plugin> 
  <groupId>com.microsoft.azure</groupId>  
  <artifactId>azure-webapp-maven-plugin</artifactId>  
  <version>2.11.0</version>  
  <configuration>
    <subscriptionId>111111-11111-11111-1111111</subscriptionId>
    <resourceGroup>spring-boot-xxxxxxxxxx-rg</resourceGroup>
    <appName>spring-boot-xxxxxxxxxx</appName>
    <pricingTier>B2</pricingTier>
    <region>westus</region>
    <runtime>
      <os>Linux</os>      
      <webContainer>Java SE</webContainer>
      <javaVersion>Java 17</javaVersion>
    </runtime>
    <deployment>
      <resources>
        <resource>
          <type>jar</type>
          <directory>${project.basedir}/target</directory>
          <includes>
            <include>*.jar</include>
          </includes>
        </resource>
      </resources>
    </deployment>
  </configuration>
</plugin>

Gradle

  1. Configure el complemento Gradle para Azure Web Apps mediante su incorporación a build.gradle:

    groovy 
    plugins {
  id "com.microsoft.azure.azurewebapp" version "1.10.0"
}

  2. Configure los detalles de la aplicación web. Los recursos de Azure correspondientes se crean si no existen. Esta es una configuración de ejemplo. Para obtener detalles, vea este documento.

    groovy 
    azurewebapp {
    subscription = '<your subscription id>'
    resourceGroup = '<your resource group>'
    appName = '<your app name>'
    pricingTier = '<price tier like 'P1v2'>'
    region = '<region like 'westus'>'
    runtime {
      os = 'Linux'
      webContainer = 'Tomcat 10.0' // or 'Java SE' if you want to run an executable jar
      javaVersion = 'Java 17'
    }
    appSettings {
        <key> = <value>
    }
    auth {
        type = 'azure_cli' // support azure_cli, oauth2, device_code and service_principal
    }
}

  3. Implemente con un comando.

    shell 
    gradle azureWebAppDeploy

IDE

Azure proporciona una experiencia de desarrollo de Java App Service eficiente en los entornos de desarrollo de Java más populares, incluidos:

API de Kudu

Para implementar archivos .jar en Java SE, use el punto de conexión /api/publish del sitio de Kudu. Para más información sobre esta API, consulte esta documentación.

Nota

La aplicación .jar debe tener el nombre app.jar para App Service y así poder identificar y ejecutar la aplicación. El complemento Maven lo hace automáticamente durante la implementación. Si no quiere cambiar el nombre de archivo JAR a app.jar, puede cargar un script de shell con el comando para ejecutar la aplicación .jar. Pegue la ruta de acceso absoluta 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).

Para implementar archivos .war en Tomcat, utilice el punto de conexión /api/wardeploy/ para realizar el conjunto de rutinas POST en el archivo. Para más información sobre esta API, consulte esta documentación.

Para implementar archivos .war en JBoss, use el punto de conexión /api/wardeploy/ para realizar la instrucción POST en el archivo. Para más información sobre esta API, consulte esta documentación.

Para implementar archivos .ear, use FTP. La aplicación .ear se implementa en la raíz de contexto definida en la configuración de la aplicación. Por ejemplo, si la raíz de contexto de la aplicación es <context-root>myapp</context-root>, puede examinar el sitio en la ruta de acceso /myapp: http://my-app-name.azurewebsites.net/myapp. Si desea que se atienda a la aplicación web en la ruta de acceso raíz, asegúrese de que la aplicación establece la raíz del contexto en la ruta de acceso raíz: <context-root>/</context-root>. Para obtener más información, vea Establecimiento del contexto raíz de una aplicación web.

No implemente el archivo .war o .jar con el FTP. La herramienta FTP está diseñada para cargar los scripts de inicio, dependencias u otros archivos en tiempo de ejecución. Tenga en cuenta que no es la opción óptima para realizar la implementación de aplicaciones web.

Reescritura o redireccionamiento de la dirección URL

Para volver a escribir o redirigir la dirección URL, use una de las herramientas de reescritura de direcciones URL disponibles, como UrlRewriteFilter.

Tomcat también proporciona una válvula de reescritura.

JBoss también proporciona una válvula de reescritura.

Registro y depuración de aplicaciones

Encontrará informes de rendimiento, visualizaciones de tráfico y comprobaciones de mantenimiento de cada aplicación a través de Azure Portal. Para más información, consulte Introducción a los diagnósticos de Azure App Service.

Transmisión de registros de diagnóstico

Puede acceder a los registros de consola generados desde dentro del contenedor.

En primer lugar, active el registro de contenedores mediante la ejecución del siguiente comando:

Azure CLI 
az webapp log config --name <app-name> --resource-group <resource-group-name> --docker-container-logging filesystem

Reemplace <app-name> y <resource-group-name> por los nombres adecuados para su aplicación web.

Una vez que se active el registro de contenedor, ejecute el siguiente comando para ver el flujo del registro:

Azure CLI 
az webapp log tail --name <app-name> --resource-group <resource-group-name>

Si no ve los registros de la consola de inmediato, vuelve a comprobarlo en 30 segundos.

Para detener el streaming de registro en cualquier momento, escriba Ctrl+C.

Los archivos de registro también se pueden inspeccionar en un explorador en https://<app-name>.scm.azurewebsites.net/api/logs/docker.

Para más información, consulte Registros de secuencias en Cloud Shell.

Acceso a la consola SSH en Linux

Para que una sesión de SSH directa sea abierta con el contenedor, la aplicación debe estar en ejecución.

Pegue la siguiente dirección URL en el explorador y reemplace <app-name> por el nombre de la aplicación:

https://<app-name>.scm.azurewebsites.net/webssh/host

Si aún no está autenticado, será preciso que se autentique con su suscripción a Azure para conectarse. Una vez autenticado, verá un shell del explorador en el que puede ejecutar comandos dentro del contenedor.

Conexión SSH

Nota

Los cambios que realice fuera del directorio /home se almacenan en el propio contenedor y no se conservan después del primer reinicio de la aplicación.

Para abrir una sesión remota de SSH desde un equipo local, consulte Abrir sesión SSH desde un shell remoto.

Herramientas de solución de problemas de Linux

Las imágenes de Java integradas usan el sistema operativo Alpine Linux. Use el administrador de paquetes apk para instalar todas las herramientas o comandos para la solución de problemas.

Java Profiler

Todos los entornos de ejecución de Java en Azure App Service vienen con JDK Flight Recorder para la generación de perfiles de cargas de trabajo de Java. Puede usarla para grabar eventos de JVM, de aplicación y del sistema, así como para solucionar los problemas de las aplicaciones.

Para más información sobre Java Profiler, visite la documentación de Azure Application Insights.

Caja negra SQL

Todos los entornos de ejecución de Java en App Service incluyen Java Flight Recorder. Puede usarlo para grabar eventos JVM, de aplicación y del sistema, así como para solucionar los problemas de las aplicaciones Java.

Conéctese a App Service mediante SSH y ejecute el comando jcmd para ver una lista de todos los procesos de Java en ejecución. Además del jcmd propio, debería ver la aplicación de Java que se ejecuta con un número de Id. de proceso (pid).

shell 
078990bbcd11:/home# jcmd
Picked up JAVA_TOOL_OPTIONS: -Djava.net.preferIPv4Stack=true
147 sun.tools.jcmd.JCmd
116 /home/site/wwwroot/app.jar

Ejecute el siguiente comando para iniciar una grabación de 30 segundos de la JVM. Así se generará el perfil de JVM y se creará un archivo JFR denominado jfr_example.jfr en el directorio principal. (reemplace 116 por el pid de la aplicación de Java).

shell 
jcmd 116 JFR.start name=MyRecording settings=profile duration=30s filename="/home/jfr_example.jfr"

Durante el intervalo de 30 segundos puede validar que la grabación se lleva a cabo mediante la ejecución de jcmd 116 JFR.check. Esto mostrará todas las grabaciones del proceso de Java dado.

Grabación continua

Puede usar Zulu Flight Recorder para generar perfiles continuamente de una aplicación Java con un impacto mínimo en el rendimiento del entorno de ejecución. Para ello, ejecute el siguiente comando de la CLI de Azure para crear una configuración de aplicación denominada JAVA_OPTS con la configuración necesaria. El contenido de la configuración de la aplicación de JAVA_OPTS se pasa al comando java cuando se inicia la aplicación.

Azure CLI 
az webapp config appsettings set -g <your_resource_group> -n <your_app_name> --settings JAVA_OPTS=-XX:StartFlightRecording=disk=true,name=continuous_recording,dumponexit=true,maxsize=1024m,maxage=1d

Cuando se inicie la grabación, puede volcar los datos de grabación actuales en cualquier momento mediante el comando JFR.dump.

shell 
jcmd <pid> JFR.dump name=continuous_recording filename="/home/recording1.jfr"

Análisis de archivos .jfr

Use FTPS para descargar el archivo JFR en el equipo local. Para analizar el archivo JFR, descargue e instale Java Mission Control. Para obtener instrucciones sobre Java Mission Control, consulte la documentación de JMC y las instrucciones de instalación.

Registro de aplicaciones

Habilite el registro de aplicaciones a través de Azure Portal o la CLI de Azure para configurar App Service para que escriba los flujos de salida y de error de la consola estándar en el sistema de archivos local o en Azure Blob Storage. Si necesita una retención más prolongada, configure la aplicación para escribir la salida en un contenedor de Blob Storage.

Los registros de aplicación de Java y Tomcat pueden encontrarse en el directorio /home/LogFiles/Application/ .

El registro de Azure Blob Storage para aplicaciones basadas en Linux solo se puede configurar mediante Azure Monitor.

Si la aplicación usa Logback o Log4j para el seguimiento, puede reenviar estos seguimientos para su revisión en Azure Application Insights mediante las instrucciones de configuración del marco de registro en Exploración de los registros de seguimiento de Java en Application Insights.

Nota

Debido a la vulnerabilidad conocida CVE-2021-44228, asegúrese de usar la versión 2.16 o posterior de Log4j.

Personalización y optimización

Azure App Service admite la optimización y la personalización de serie a través de Azure Portal y de la CLI de Azure. Consulte los artículos siguientes para conocer la configuración de aplicaciones web específicas que no son de Java:

Copia local del contenido de la aplicación

Establezca la configuración JAVA_COPY_ALL de la aplicación en true para copiar el contenido de la aplicación en el trabajo local desde el sistema de archivos compartido. Esta configuración ayuda a solucionar problemas de bloqueo de archivos.

Definición de las opciones de Java Runtime

Para establecer la memoria asignada u otras opciones de runtime de JVM, cree una configuración de la aplicación denominada JAVA_OPTS con las opciones. App Service pasa esta configuración como variable de entorno para Java Runtime cuando se inicia.

En Azure Portal, en Configuración de la aplicación para la aplicación web, cree un nuevo valor de la aplicación denominado JAVA_OPTS que incluya otras opciones, como -Xms512m -Xmx1204m.

En Azure Portal, en Configuración de la aplicación para la aplicación web, cree un nuevo valor de la aplicación denominado CATALINA_OPTS que incluya otras opciones, como -Xms512m -Xmx1204m.

Para definir la configuración de la aplicación desde el complemento MavenLinux, agregue las etiquetas setting/value a la sección de complementos de Azure. En el ejemplo siguiente se establece un tamaño del montón de Java mínimo y máximo específico:

XML 
<appSettings>
    <property>
        <name>JAVA_OPTS</name>
        <value>-Xms1024m -Xmx1024m</value>
    </property>
</appSettings>

Nota

No es necesario crear un archivo web.config al usar Tomcat en Windows App Service.

Los desarrolladores que ejecutan una sola aplicación con una ranura de implementación en su plan de App Service pueden usar las siguientes opciones:

  • Instancias de S1 y B1: -Xms1024m -Xmx1024m
  • Instancias de S2 y B2: -Xms3072m -Xmx3072m
  • Instancias de S3 y B3: -Xms6144m -Xmx6144m
  • Instancias de P1v2: -Xms3072m -Xmx3072m
  • Instancias de P2v2: -Xms6144m -Xmx6144m
  • Instancias de P3v2: -Xms12800m -Xmx12800m
  • Instancias de P1v3: -Xms6656m -Xmx6656m
  • Instancias de P2v3: -Xms14848m -Xmx14848m
  • Instancias de P3v3: -Xms30720m -Xmx30720m
  • Instancias de I1: -Xms3072m -Xmx3072m
  • Instancias de I2: -Xms6144m -Xmx6144m
  • Instancias de I3: -Xms12800m -Xmx12800m
  • Instancias de I1v2: -Xms6656m -Xmx6656m
  • Instancias de I2v2: -Xms14848m -Xmx14848m
  • Instancias de I3v2: -Xms30720m -Xmx30720m

Cuando optimice la configuración del montón de la aplicación, revise los detalles de su plan de App Service y tenga en cuenta distintas necesidades de aplicaciones y ranuras de implementación para encontrar la asignación óptima de memoria.

Activación de sockets web

Active la compatibilidad con sockets web en Azure Portal en Configuración de la aplicación para la aplicación. Debe reiniciar la aplicación para que la configuración surta efecto.

Active la compatibilidad con los sockets web mediante la CLI de Azure con el comando siguiente:

Azure CLI 
az webapp config set --name <app-name> --resource-group <resource-group-name> --web-sockets-enabled true

A continuación, reinicie su aplicación:

Azure CLI 
az webapp stop --name <app-name> --resource-group <resource-group-name>
az webapp start --name <app-name> --resource-group <resource-group-name>

Definición de la codificación de caracteres predeterminada

En Azure Portal, en Configuración de la aplicación para la aplicación web, cree un nuevo valor de la aplicación denominado JAVA_OPTS con el valor -Dfile.encoding=UTF-8.

También puede configurar el valor de la aplicación mediante el complemento de Maven de App Service. Agregue las etiquetas setting y value del valor en la configuración del complemento:

XML 
<appSettings>
    <property>
        <name>JAVA_OPTS</name>
        <value>-Dfile.encoding=UTF-8</value>
    </property>
</appSettings>

Precompilación de archivos JSP

Para mejorar el rendimiento de las aplicaciones Tomcat, puede compilar los archivos JSP antes de realizar la implementación en App Service. Puede usar el complemento Maven proporcionado por Apache Sling o este archivo de compilación Ant.

robots933456 en registros

Puede ver el mensaje siguiente en los registros del contenedor:

2019-04-08T14:07:56.641002476Z "-" - - [08/Apr/2019:14:07:56 +0000] "GET /robots933456.txt HTTP/1.1" 404 415 "-" "-"

Puede omitir este mensaje sin problemas. /robots933456.txt es una ruta de acceso de la dirección URL ficticia que utiliza App Service para comprobar si el contenedor es capaz de atender las solicitudes. Una respuesta 404 simplemente indica que la ruta de acceso no existe, pero permite a App Service saber que el contenedor está en buen estado y listo para responder a las solicitudes.

Selección de la versión del entorno de ejecución de Java

App Service permite a los usuarios elegir la versión principal de JVM (por ejemplo, Java 8 o Java 11) y la versión de revisión (por ejemplo, 1.8.0_232 o 11.0.5). También puede elegir que la versión de revisión se actualice automáticamente a medida que vayan estando disponibles. En la mayoría de los casos, las aplicaciones de producción deben usar versiones revisadas de JVM ancladas. Así se evitan interrupciones imprevistas durante la actualización automática de una versión revisada. Todas las aplicaciones web de Java usan JMS de 64 bits, lo que no es configurable.

Si usa Tomcat, puede optar por anclar la versión de revisión de Tomcat. En Windows, puede anclar las versiones de revisión de JVM y Tomcat de forma independiente. En Linux, puede anclar la versión de revisión de Tomcat; la versión de revisión de JVM también se ancla, pero no se puede configurar por separado.

Si elige anclar la versión secundaria, tiene que actualizar periódicamente la versión secundaria de JVM en la aplicación. Para asegurarse de que la aplicación se ejecute en la versión secundaria más reciente, cree un espacio de ensayo e incremente en él la versión secundaria. Cuando confirme que la aplicación se ejecuta correctamente en la nueva versión secundaria, puede intercambiar los espacios de ensayo y de producción.

Ejecución de la CLI de JBoss

En la sesión SSH de la aplicación JBoss, puede ejecutar la CLI de JBoss con el siguiente comando:

$JBOSS_HOME/bin/jboss-cli.sh --connect

En función de dónde se encuentra JBoss en el ciclo de vida del servidor, es posible que no pueda conectarse. Espere unos minutos y pruebe otra vez. Este enfoque es útil para comprobar rápidamente el estado actual del servidor (por ejemplo, para ver si un origen de datos está configurado correctamente).

Además, los cambios que realice en el servidor con JBoss CLI en la sesión SSH no persisten después de reiniciar la aplicación. Cada vez que se inicia la aplicación, el servidor JBoss EAP comienza con una instalación limpia. Durante el ciclo de vida de inicio, App Service realiza las configuraciones de servidor necesarias e implementa la aplicación. Para realizar cambios persistentes en el servidor JBoss, use un script de inicio personalizado o un comando de inicio. Para ver un ejemplo completo, consulte Configuración de orígenes de datos para una aplicación Tomcat, JBoss o Java SE en Azure App Service.

Como alternativa, puede configurar manualmente App Service para que ejecute cualquier archivo al iniciarse. Por ejemplo:

Azure CLI 
az webapp config set --resource-group <group-name> --name <app-name> --startup-file /home/site/scripts/foo.sh

Para obtener más información sobre los comandos de la CLI que puede ejecutar, consulte:

Clustering

App Service admite la agrupación en clústeres para las versiones 7.4.1 y posteriores de JBoss EAP. Para habilitar la agrupación en clústeres, la aplicación web debe integrarse con una red virtual. Cuando la aplicación web se integra con una red virtual, se reinicia y la instalación de JBoss EAP se inicia automáticamente con una configuración en clúster. Cuando se ejecutan varias instancias con auto escalado, las instancias de JBoss EAP se comunican entre sí a través de la subred especificada en la integración de red virtual. Puede deshabilitar la agrupación en clústeres mediante la creación de una configuración de aplicación denominada WEBSITE_DISABLE_CLUSTERING con cualquier valor.

Diagrama en el que se muestra una aplicación de JBoss App Service integrada en la red virtual, que se escala horizontalmente a tres instancias.

Nota

Si va a habilitar la integración de red virtual con una plantilla de ARM, debe establecer manualmente la propiedad vnetPrivatePorts en un valor de 2. Si habilita la integración de red virtual desde la CLI o el portal, esta propiedad se establece automáticamente.

Cuando la agrupación en clústeres está habilitada, las instancias de EAP de JBoss usan el protocolo de detección de JGroups de FILE_PING para detectar nuevas instancias y conservar la información del clúster, como los miembros del clúster, sus identificadores y sus direcciones IP. En App Service, estos archivos se encuentran en /home/clusterinfo/. La primera instancia de EAP que se inicia obtiene los permisos de lectura y escritura en el archivo de pertenencia al clúster. Otras instancias leen el archivo, buscan el nodo principal y se coordinan con ese nodo para incluirlo en el clúster y agregarlo al archivo.

Nota

Puede evitar tiempos de espera de agrupación en clústeres de JBoss eliminando los archivos de detección obsoletos durante el inicio de la aplicación.

De manera opcional, los tipos de plan de App Service Premium V3 y V2 aislado se pueden distribuir entre zonas de disponibilidad para mejorar la resistencia y la confiabilidad de las cargas de trabajo críticas para la empresa. Esta arquitectura también se conoce como redundancia de zona. La característica de agrupación en clústeres de JBoss EAP es compatible con la característica de redundancia de zona.

Reglas de autoescalado

Al configurar reglas de escalado automático para el escalado horizontal, es importante eliminar las instancias de forma incremental (una a la vez) para asegurarse de que cada instancia eliminada puede transferir su actividad (por ejemplo, controlar una transacción de base de datos) a otro miembro del clúster. Al configurar las reglas de escalado automático en el portal para reducir verticalmente, use las siguientes opciones:

  • Operación: "Reducir recuento en"
  • Tiempo de finalización: "5 minutos" o superior
  • Recuento de instancias: 1

No es necesario agregar instancias de forma incremental (escalado horizontal), puede agregar varias instancias al clúster a la vez.

Planes de App Service

JBoss EAP está disponible en los siguientes planes de tarifa: F1, P0v3, P1mv3, P2mv3, P3mv3, P4mv3 y P5mv3.

Ciclo de vida del servidor JBoss

Una aplicación JBoss EAP en App Service pasa por cinco fases distintas antes de iniciar realmente el servidor.

Consulte las secciones correspondientes a continuación para obtener más información, así como las posibilidades de personalización (por ejemplo, a través de la configuración de la aplicación).

1. Fase de configuración del entorno

  • El servicio SSH se inicia para habilitar sesiones SSH seguras con el contenedor.
  • El almacén de claves del entorno de ejecución de Java se actualiza con los certificados públicos y privados definidos en Azure Portal.
    • La plataforma proporciona certificados públicos en el directorio /var/ssl/certs y se cargan en $JRE_HOME/lib/security/cacerts.
    • La plataforma proporciona certificados privados en el directorio /var/ssl/private y se cargan en $JRE_HOME/lib/security/client.jks.
  • Si se cargan certificados en el almacén de claves de Java en este paso, las propiedades javax.net.ssl.keyStore, javax.net.ssl.keyStorePassword y javax.net.ssl.keyStoreType se agregan a la JAVA_TOOL_OPTIONS variable de entorno.
  • Se determina alguna configuración inicial de JVM, como directorios de registro y parámetros del montón de memoria de Java:
    • Si proporcionas las marcas –Xms o –Xmx para la memoria en la configuración de la aplicaciónJAVA_OPTS, estos valores invalidan los proporcionados por la plataforma.
    • Si configura el parámetro appWEBSITES_CONTAINER_STOP_TIME_LIMIT, el valor se pasa a la propiedad runtimeorg.wildfly.sigterm.suspend.timeout, que controla el tiempo máximo de espera de apagado (en segundos) cuando JBoss se está deteniendo.
  • Si la aplicación está integrada con una red virtual, el tiempo de ejecución de App Service pasa una lista de puertos a utilizar para la comunicación entre servidores en la variable de entorno WEBSITE_PRIVATE_PORTS y lanza JBoss utilizando la clusteringconfiguración. De lo contrario, se standalone usa la configuración.
    • Para la clustering configuración, se usa el archivo de configuración del servidor standalone-azure-full-ha.xml.
    • Para la standalone configuración, se usa el archivo de configuración del servidor standalone-full.xml.

2. Fase de inicio del servidor

  • Si JBoss se inicia en la clustering configuración:
    • Cada instancia de JBoss recibe un identificador interno entre 0 y el número de instancias a las que se escala la aplicación.
    • Si algunos archivos se encuentran en la ruta de acceso del almacén de transacciones para esta instancia del servidor (mediante su identificador interno), significa que esta instancia del servidor está teniendo lugar de una instancia de servicio idéntica que se bloqueó anteriormente y dejó transacciones no confirmadas detrás. El servidor está configurado para reanudar el trabajo en estas transacciones.
  • Independientemente de si JBoss se inicia en la configuración clustering o standalone, si la versión del servidor es 7.4 o superior y el entorno de ejecución usa Java 17, la configuración se actualiza para habilitar el subsistema Elytron para la seguridad.
  • Si configura la configuración de la aplicaciónWEBSITE_JBOSS_OPTS, el valor se pasa al script del iniciador de JBoss. Esta configuración se puede usar para proporcionar rutas de acceso a archivos de propiedades y más marcas que influyen en el inicio de JBoss.

3. Fase de configuración del servidor

  • Al principio de esta fase, App Service espera primero que el servidor JBoss y la interfaz de administración estén listos para recibir solicitudes antes de continuar. Esto puede tardar unos segundos más si Application Insights está habilitado.
  • Cuando JBoss Server y la interfaz de administración estén listas, App Service hace lo siguiente:
    • Agrega el módulo JBoss azure.appservice, que proporciona clases de utilidad para el registro y la integración con App Service.
    • Actualiza el registrador de la consola para que utilice un modo sin color, de modo que los archivos de registro no estén llenos de secuencias de escape de color.
    • Configura la integración con los registros de Azure Monitor.
    • Actualiza las direcciones IP de enlace de las interfaces de administración y WSDL.
    • Agrega el módulo azure.appservice.easyauth JBoss para la integración con la autenticación de App Service y el identificador de Microsoft Entra.
    • Actualiza la configuración de registro de los registros de acceso y el nombre y la rotación del archivo de registro del servidor principal.
  • A menos que se defina la configuración WEBSITE_SKIP_AUTOCONFIGURE_DATABASE de la aplicación, App Service detecta automáticamente las direcciones URL de JDBC en la configuración de la aplicación de App Service. Si existen direcciones URL de JDBC válidas para PostgreSQL, MySQL, MariaDB, Oracle, SQL Server o base de datos de Azure SQL, agrega los controladores correspondientes al servidor y agrega un origen de datos para cada una de las direcciones URL de JDBC y establece el nombre JNDI de cada origen de datos enjava:jboss/env/jdbc/<app-setting-name>_DS, donde <app-setting-name> es el nombre de la configuración de la aplicación.
  • Si la clustering configuración está habilitada, se comprueba el registrador de consola que se va a configurar.
  • Si hay archivos JAR implementados en el directorio /home/site/libs, se crea un nuevo módulo global con todos estos archivos JAR.
  • Al final de la fase, App Service ejecuta el script de inicio personalizado, si existe alguno. La lógica de búsqueda para el script de inicio personalizado es la siguiente:
    • Si configuró un comando de inicio (en Azure Portal, con la CLI de Azure, etc.), ejecútelo; de otra manera,
    • Si existe la ruta de acceso /home/site/scripts/startup.sh, úsela; en caso contrario,
    • Si existe la ruta de acceso /home/startup.sh, úsela.

El comando de inicio personalizado o script se ejecuta como el usuario raíz (no es necesario), sudopor lo que pueden instalar paquetes de Linux o iniciar la CLI de JBoss para realizar más comandos de instalación/personalización de JBoss (creación de orígenes de datos, instalación de adaptadores de recursos), etc. Para obtener información sobre los comandos de administración de paquetes de Ubuntu, consulte ladocumentación de Ubuntu Server. Para ver los comandos de la CLI de JBoss, consulte la Guía de la CLI de administración de JBoss.

4. Fase de implementación de aplicaciones

El script de inicio implementa aplicaciones en JBoss buscando en las siguientes ubicaciones, en orden de prioridad:

  • Si configuró la configuración de la aplicaciónWEBSITE_JAVA_WAR_FILE_NAME, implemente el archivo designado por ella.
  • Si existe /home/site/wwwroot/app.war, impleméntelo.
  • Si existen otros archivos EAR y WAR en /home/site/wwwroot, impleméntelos.
  • Si existe /home/site/wwwroot/webapps, implemente los archivos y directorios en él. Los archivos WAR se implementan como aplicaciones y los directorios se implementan como aplicaciones web "explotadas" (sin comprimir).
  • Si existen páginas JSP independientes en /home/site/wwwroot, cópielas en la raíz del servidor web e impleméntelas como una aplicación web.
  • Si aún no se encuentran archivos implementables, implemente la página principal predeterminada (página de estacionamiento) en el contexto raíz.

5. Fase de recarga del servidor

  • Una vez completados los pasos de implementación, el servidor JBoss se vuelve a cargar para aplicar los cambios que requieran una recarga del servidor.
  • Después de que el servidor se vuelva a cargar, las aplicaciones implementadas en el servidor de JBoss EAP deben estar listas para responder a las solicitudes.
  • El servidor se ejecuta hasta que se detiene o reinicia la aplicación de App Service. Puede detener o reiniciar manualmente la aplicación de App Service o desencadenar un reinicio al implementar archivos o realizar cambios de configuración en la aplicación de App Service.
  • Si el servidor JBoss sale de forma anormal en la clusteringconfiguración, se ejecuta una última función llamadaemit_alert_tx_store_not_empty. La función comprueba si el proceso de JBoss deja un archivo de almacén de transacciones no vacío en el disco; Si es así, se registra un error en la consola: Error: finishing server with non-empty store for node XXXX. Cuando se inicia una nueva instancia de servidor, busca estos archivos de almacén de transacciones no vacíos para reanudar el trabajo (consulte 2. Fase de inicio del servidor).

Configuración de línea base de Tomcat

Nota

Esta sección solo se aplica a Linux.

Los desarrolladores de Java pueden personalizar la configuración del servidor, solucionar problemas e implementar aplicaciones en Tomcat con confianza si saben sobre el archivo de server.xml y los detalles de configuración de Tomcat. Entre las posibles personalizaciones se incluyen las siguientes:

  • Personalización de la configuración de Tomcat: al reconocer el archivo server.xml y los detalles de configuración de Tomcat, los desarrolladores pueden ajustar de manera precisa la configuración del servidor para satisfacer las necesidades de sus aplicaciones.
  • Depuración: cuando se implementa una aplicación en un servidor de Tomcat, los desarrolladores deben conocer la configuración del servidor para depurar los problemas que puedan surgir. Esto incluye comprobar los registros del servidor, examinar los archivos de configuración e identificar los errores que podrían producirse.
  • Solución de problemas de Tomcat: inevitablemente, los desarrolladores de Java encontrarán problemas con su servidor Tomcat, como problemas de rendimiento o errores de configuración. Al reconocer el archivo de server.xml y los detalles de configuración de Tomcat, los desarrolladores pueden diagnosticar y solucionar estos problemas rápidamente, lo que puede ahorrar tiempo y esfuerzo.
  • Implementación de aplicaciones en Tomcat: para implementar una aplicación web de Java en Tomcat, los desarrolladores deben saber cómo configurar el archivo server.xml y otras opciones de Configuración de Tomcat. Reconocer estos detalles es esencial para implementar aplicaciones correctamente y asegurarse de que se ejecutan sin problemas en el servidor.

Al crear una aplicación con Tomcat integrado para hospedar la carga de trabajo de Java (un archivo WAR o un archivo JAR), hay ciertas opciones de configuración que obtendrá para la configuración de Tomcat. Puede consultar el Documentación oficial de Apache Tomcat para obtener información detallada, incluida la configuración predeterminada para Tomcat Web Server.

Además, hay ciertas transformaciones que se aplican aún más sobre la server.xml para la distribución de Tomcat al iniciarse. Se trata de transformaciones en la configuración conector, host y válvula.

Las versiones más recientes de Tomcat tienen server.xml (8.5.58 y 9.0.38 en adelante). Las versiones anteriores de Tomcat no usan transformaciones y pueden tener un comportamiento diferente como resultado.

Conector

XML 
<Connector port="${port.http}" address="127.0.0.1" maxHttpHeaderSize="16384" compression="on" URIEncoding="UTF-8" connectionTimeout="${site.connectionTimeout}" maxThreads="${catalina.maxThreads}" maxConnections="${catalina.maxConnections}" protocol="HTTP/1.1" redirectPort="8443"/>
  • maxHttpHeaderSize se establezca en 16384.
  • URIEncoding se establezca en UTF-8.
  • connectionTimeout se establece en WEBSITE_TOMCAT_CONNECTION_TIMEOUT, cuyo valor predeterminado es 240000
  • maxThreads se establece en WEBSITE_CATALINA_MAXTHREADS, que tiene como valor predeterminado 200
  • maxConnections se establece en WEBSITE_CATALINA_MAXCONNECTIONS, que tiene como valor predeterminado 10000

Nota

La configuración de connectionTimeout, maxThreads y maxConnections se puede ajustar con la configuración de la aplicación

A continuación se muestran varios comandos de la CLI de ejemplo que puede usar para modificar los valores de connectionTimeout, maxThreads o maxConnections:

Azure CLI 
az webapp config appsettings set --resource-group myResourceGroup --name myApp --settings WEBSITE_TOMCAT_CONNECTION_TIMEOUT=120000
Azure CLI 
az webapp config appsettings set --resource-group myResourceGroup --name myApp --settings WEBSITE_CATALINA_MAXTHREADS=100
Azure CLI 
az webapp config appsettings set --resource-group myResourceGroup --name myApp --settings WEBSITE_CATALINA_MAXCONNECTIONS=5000
  • El conector usa la dirección del contenedor en lugar de 127.0.0.1

Host

XML 
<Host appBase="${site.appbase}" xmlBase="${site.xmlbase}" unpackWARs="${site.unpackwars}" workDir="${site.tempdir}" errorReportValveClass="com.microsoft.azure.appservice.AppServiceErrorReportValve" name="localhost" autoDeploy="true">
  • appBase se establece en AZURE_SITE_APP_BASE, que tiene como valor predeterminado local WebappsLocalPath
  • xmlBase se establece en AZURE_SITE_HOME, que tiene como valor predeterminado /site/wwwroot
  • unpackWARs se establece en AZURE_UNPACK_WARS, que tiene como valor predeterminado true
  • workDir se establece en JAVA_TMP_DIR, que tiene como valor predeterminado TMP
  • errorReportValveClass usa nuestra válvula de informe de errores personalizada

Válvula

XML 
<Valve prefix="site_access_log.${catalina.instance.name}" pattern="%h %l %u %t &quot;%r&quot; %s %b %D %{x-arr-log-id}i" directory="${site.logdir}/http/RawLogs" maxDays="${site.logRetentionDays}" className="org.apache.catalina.valves.AccessLogValve" suffix=".txt"/>
  • directory se establece en AZURE_LOGGING_DIR, que tiene como valor predeterminado home\logFiles
  • maxDays se establece en WEBSITE_HTTPLOGGING_RETENTION_DAYS, que tiene como valor predeterminado 7. Esto se alinea con el valor predeterminado de la plataforma de Application Logging

En Linux, tiene toda la misma personalización, además de:

  • Agrega algunas páginas de error e informes a la válvula:

    XML 
    <xsl:attribute name="appServiceErrorPage">
    <xsl:value-of select="'${appService.valves.appServiceErrorPage}'"/>
</xsl:attribute>

<xsl:attribute name="showReport">
    <xsl:value-of select="'${catalina.valves.showReport}'"/>
</xsl:attribute>

<xsl:attribute name="showServerInfo">
    <xsl:value-of select="'${catalina.valves.showServerInfo}'"/>
</xsl:attribute>

Pasos siguientes

Visite el centro de Azure para desarrolladores de Java para encontrar guías de inicio rápido de Azure, tutoriales y documentación de referencia de Java.