Compartir a través de

Implementación y configuración de una aplicación java SE, Tomcat o JBoss EAP en Azure App Service

En este artículo se muestra la configuración más común de implementación y tiempo de ejecución para aplicaciones Java en Azure App Service. Si es la primera vez que usa Azure App Service, primero debe leer el inicio rápido de Java. Puede encontrar las respuestas a preguntas generales sobre el uso de App Service que no son específicos del desarrollo de Java en las preguntas más frecuentes de App Service.

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

  • Java Standard Edition (SE): puede ejecutar una aplicación implementada como un paquete java Archive (JAR) que contenga un servidor incrustado (como Spring Boot, Quarkus, Dropwizard o una aplicación con un servidor de Tomcat o Jetty incrustado).
  • Tomcat: el servidor de Tomcat integrado puede ejecutar una aplicación implementada como un paquete de archivo de aplicaciones web (WAR).
  • JBoss Enterprise Application Platform (EAP): el servidor JBoss EAP integrado puede ejecutar una aplicación implementada como un paquete war o enterprise archive (EAR). Compatible con aplicaciones Linux en un conjunto de planes de tarifa que incluye Free, Premium v3 y Isolated v2.gti

Mostrar la versión de Java

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

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

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

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:

java -version

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

sh /usr/local/tomcat/version.sh

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

find / -name "version.sh"

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

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

Para obtener más información sobre la compatibilidad con versiones, consulte Política de soporte del entorno de ejecución de idiomas de App Service.

¿Qué ocurre con los tiempos de ejecución obsoletos en App Service?

Los tiempos de ejecución obsoletos están en desuso por parte de la organización de mantenimiento o han detectado que tienen vulnerabilidades significativas. En consecuencia, se eliminan de las páginas de creación y configuración en el portal. Cuando un tiempo de ejecución obsoleto está oculto en el portal, cualquier aplicación que siga usando ese tiempo de ejecución continúa ejecutándose.

Si quiere crear una aplicación con una versión en tiempo de ejecución obsoleta que ya no se muestra en el portal, use la CLI de Azure, la plantilla de ARM o Bicep. Estas alternativas de implementación permiten crear entornos de ejecución en desuso que se han quitado en el portal, pero aún se admiten.

Si un entorno de ejecución se quita completamente de la plataforma de App Service, el propietario de la suscripción de Azure recibe un aviso por correo electrónico antes de la eliminación.

Implementación de la aplicación

Herramientas de compilación

Entendido

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

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

Este comando agrega un azure-webapp-maven-plugin complemento y la configuración relacionada; para ello, se le pide 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. A continuación, puede implementar la aplicación de Java en Azure mediante el comando siguiente:

mvn package azure-webapp:deploy

Esta es una configuración de ejemplo de pom.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 agregando el complemento a build.gradle:

    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 más información, consulte este documento.

    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.

    gradle azureWebAppDeploy

IDE

Azure proporciona una experiencia de desarrollo perfecta de Java App Service en entornos de desarrollo integrados (IDE) de Java populares, entre los que se incluyen:

API de Kudu y OneDeploy

Los clientes de implementación, como la extensión de Maven, las acciones de GitHub mediante azure/webapps-deploy@v3 y versiones más recientes, o el comando az webapp deploy usan OneDeploy, que se invoca llamando al punto de conexión /api/publish del sitio de Kudu en segundo plano. Para más información sobre esta API, consulte esta documentación.

Cuando se usan estos métodos de implementación, cambiará automáticamente el nombre del archivo JAR proporcionado a app.jar durante el proceso de implementación. Esto se colocará debajo de /home/site/wwwwroot. Para implementar archivos JAR en Java SE, consulte esta documentación.

Nota

Si usa métodos alternativos como FTP o LAS API de ZipDeploy anteriores, este método para cambiar el nombre del archivo JAR proporcionado no se invocará. Tome nota de esto si usa el cuadro de texto Archivo de inicio de la sección Configuración del portal para llamar explícitamente al archivo JAR.

Puede implementar archivos WAR en la aplicación Tomcat siguiendo esta documentación. Cuando se usen estos métodos de implementación anteriores, cambiarán automáticamente el nombre del archivo War proporcionado a app.war durante el proceso de implementación. Esto se colocará en /home/site/wwwwroot y, de forma predeterminada, solo admite la implementación de un archivo WAR en wwwroot. Esto no se colocará en el directorio /home/site/wwwroot/webapps como se ve al usar API de implementación como WarDeploy. Para evitar problemas con conflictos de estructura de archivos, se recomienda usar solo uno o el otro tipo de implementación.

Para implementar archivos WAR en JBoss EAP, consulte esta documentación. Cuando se usa OneDeploy, esto cambiará automáticamente el nombre del archivo WAR a app.war y se colocará en /home/site/wwwroot.

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. 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 despliegue su WAR o JAR usando 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 redirección de una dirección URL

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

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

JBoss EAP 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.

Para activar el registro de contenedores, ejecute el siguiente comando:

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 la aplicación web.

Después de activar el registro de contenedores, ejecute el siguiente comando para ver la secuencia de registro:

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

Si los registros de consola no aparecen inmediatamente, vuelva a comprobar en 30 segundos.

Para detener el streaming de registros en cualquier momento, seleccione Ctrl+C.

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

Acceso a la consola SSH en Linux

Para abrir una sesión SSH directa con el contenedor, la aplicación debe ejecutarse.

Use el comando az webapp ssh .

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 en el explorador, donde puede ejecutar comandos dentro del contenedor.

Conexión SSH

Nota

Los cambios que realice fuera del /home directorio se almacenan en el propio contenedor y no se conservan más allá de un 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.

Generador de perfiles de Java

Todos los entornos de ejecución de Java en Azure App Service incluyen la grabadora de vuelos del Kit de desarrollo de Java (JDK) para generar perfiles de cargas de trabajo de Java. Puede usarlo para registrar la máquina virtual Java (JVM), los eventos del sistema y de la aplicación, y para solucionar problemas en las aplicaciones.

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

Java Flight Recorder (Grabador de Vuelos de Java)

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

Conéctese a App Service y ejecute el jcmd comando para ver una lista de todos los procesos de Java que se ejecutan. Además de jcmd, debería ver que la aplicación Java se ejecuta con un número de identificador de proceso (PID).

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. Genera perfiles de JVM y crea un archivo Java Flight Recorder (JFR) denominado jfr_example.jfr en el directorio principal. Reemplace por 116 el PID de la aplicación de Java.

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 Java Flight Recorder para generar perfiles continuamente de su 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 JAVA_OPTS aplicación se pasa al java comando cuando se inicia la aplicación.

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

Una vez iniciada la grabación, puede volcar los datos de grabación actuales en cualquier momento mediante el JFR.dump comando .

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 (JMC). Para obtener instrucciones sobre cómo usar Java Mission Control, consulte la documentación de JMC y las instrucciones de instalación.

Registro de aplicaciones

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

Los registros de aplicaciones de Java y Tomcat se pueden encontrar en el /home/LogFiles/Application/ directorio .

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. Use las instrucciones de configuración del marco de registro en Exploración de registros de seguimiento de Java en Application Insights.

Nota

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

Personalización y optimización

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

Copiar contenido de la aplicación localmente

Establezca la configuración JAVA_COPY_ALL de la aplicación en true para copiar el contenido de la aplicación al trabajador 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 configurar la aplicación desde el plugin de Maven, agregue las etiquetas de configuración/valor en la sección del plugin de Azure. En el ejemplo siguiente se establece un tamaño del montón de Java mínimo y máximo específico:

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

De manera predeterminada, App Service establece el tamaño máximo del montón de JVM en el 70 % de la memoria total disponible para el plan de App Service. Para deshabilitar la configuración predeterminada, puede usar la configuración de la aplicación WEBSITE_DISABLE_JAVA_HEAP_CONFIGURATION="true".

Mejorar el rendimiento de la aplicación en la plataforma puede implicar ajustar el tamaño del montón para adaptarse mejor a sus necesidades específicas. Al ajustar la configuración del montón de aplicaciones, revise los detalles del plan de App Service y tenga en cuenta los requisitos de varias aplicaciones y ranuras de implementación para encontrar la asignación de memoria óptima.

Activa los 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 sockets web mediante la CLI de Azure con el siguiente comando:

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

A continuación, reinicie su aplicación:

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.

Como alternativa, puede configurar la configuración de la aplicación mediante el complemento Maven de App Service. Agregue las etiquetas de nombre y valor de configuración en la configuración del complemento:

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

Precompilar 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 usar este archivo de compilación ant.

Omitir el mensaje robots933456 en los registros

Es posible que vea el mensaje siguiente en los registros de 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 URL ficticia que utiliza App Service para comprobar si el contenedor es capaz de procesar las solicitudes. Una respuesta 404 indica que la ruta de acceso no existe y indica a App Service que el contenedor está en buen estado y listo para responder a las solicitudes.

Elección de una versión en tiempo de ejecución de Java

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

Si usa Tomcat, puede elegir anclar la versión de revisión de Tomcat. En Windows, puede fijar las versiones de parche de JVM y Tomcat en forma independiente. En Linux, puede anclar la versión de revisión de Tomcat. La versión de parche de JVM también está fijada, 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. Después de confirmar que la aplicación se ejecuta correctamente en la nueva versión secundaria, puede intercambiar las ranuras de ensayo y producción.

Ejecución de la CLI de JBoss

En la sesión SSH de la aplicación JBoss EAP, 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 EAP 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 realizados en el servidor con la CLI de JBoss en la sesión ssh no se conservan 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 EAP, 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 java SE, Tomcat o JBoss EAP en Azure App Service.

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

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:

Agrupamiento

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.

Un diagrama que muestra una aplicación de App Service de JBoss EAP integrada en la red virtual, escalada 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 se habilita la agrupación en clústeres, las instancias de JBoss EAP usan el FILE_PING protocolo de detección de JGroups para detectar nuevas instancias y conservar la información del clúster (por ejemplo: 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

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

Los tipos Premium V3, Premium V4 y Aislado V2 del plan de App Service se pueden distribuir opcionalmente 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 escalado automático

Al configurar reglas de escalado automático para el escalado horizontal, es importante quitar 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 la escala, use las siguientes opciones:

  • Operación: "Disminuir recuento por"
  • Esporádico: "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, P5mv3, P0v4, P1mv4, P2mv4, P3mv4, P4mv4 y P5mv4.

Ciclo de vida del servidor JBoss EAP

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

  1. Fase de configuración del entorno
  2. Fase de inicio del servidor
  3. Fase de configuración del servidor
  4. Fase de implementación de aplicaciones
  5. Fase de recarga del servidor

Consulte las secciones siguientes para obtener detalles y oportunidades de personalizar (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 en tiempo 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 /var/ssl/certs directorio y se cargan en $JRE_HOME/lib/security/cacerts.
    • La plataforma proporciona certificados privados en el /var/ssl/private directorio 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.keyStorePasswordy javax.net.ssl.keyStoreType se agregan a la variable de JAVA_OPTS 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 ajuste WEBSITES_CONTAINER_STOP_TIME_LIMIT de la aplicación, el valor se pasa a la propiedad de tiempo de ejecución org.wildfly.sigterm.suspend.timeout, que controla el tiempo máximo de espera de apagado (en segundos) cuando se detiene JBoss EAP.
  • Si la aplicación se integra con una red virtual, el entorno de ejecución de App Service pasa una lista de puertos que se usarán para la comunicación entre servidores en la variable WEBSITE_PRIVATE_PORTS de entorno e inicia JBoss EAP mediante la clustering configuración. De lo contrario, se standalone usa la configuración.
    • Para la clustering configuración, se usa el archivo standalone-azure-full-ha.xml de configuración del servidor.
    • Para la standalone configuración, se usa el archivo standalone-full.xml de configuración del servidor.

2. Fase de inicio del servidor

  • Si JBoss EAP se inicia en la configuración de clustering:
    • Cada instancia de JBoss EAP recibe un identificador interno entre 0 y el número de instancias a las que se escala horizontalmente la aplicación.
    • Si se encuentran algunos archivos 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á ocupando el lugar de una instancia de servicio idéntica. La otra instancia de servicio se bloqueó anteriormente y dejó transacciones no confirmadas pendientes. El servidor está configurado para reanudar el trabajo en estas transacciones.
  • Independientemente de si JBoss EAP se inicia en la clustering configuración o standalone , si la versión del servidor es 7.4 o posterior y el runtime 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 propiedad y más marcas que influyen en el inicio de JBoss EAP.

3. Fase de configuración del servidor

  • Al principio de esta fase, App Service primero espera a que el servidor JBoss EAP y la interfaz de administración estén listos para recibir solicitudes antes de continuar. Este proceso puede tardar unos segundos más si Application Insights está habilitado.

  • Cuando JBoss EAP Server y la interfaz de administración estén listas, App Service realiza las siguientes acciones:

    • Agrega el módulo azure.appserviceJBoss EAP , que proporciona clases de utilidad para el registro y la integración con App Service.
    • Actualiza el registrador de consola para usar un modo sin color para 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 del lenguaje de descripción de servicios web (WSDL) y las interfaces de administración.
    • Agrega el módulo azure.appservice.easyauth de JBoss EAP para la integración con la autenticación de App Service y Microsoft Entra ID.
    • 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 Java Database Connectivity (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 Azure SQL Database, agrega los controladores correspondientes al servidor, agrega un origen de datos para cada una de las direcciones URL JDBC y establece el nombre de Java Naming and Directory Interface (JNDI) para cada origen de datos java:jboss/env/jdbc/<app-setting-name>_DSen , 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 /home/site/libs directorio, 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 del script de inicio personalizado se define de la siguiente manera:

    • Si configuró un comando de inicio (por ejemplo, a través de Azure Portal o la CLI de Azure), ejecútelo; de otra manera
    • Si la ruta de acceso /home/site/scripts/startup.sh existe, úsela; de lo contrario,
    • Si la ruta de acceso /home/startup.sh existe, úsela.

El comando de inicio personalizado o script se ejecuta como el usuario raíz (no es necesario usar sudo), por lo que se pueden instalar paquetes de Linux o iniciar la CLI de JBoss para realizar más comandos de instalación o personalización de JBoss EAP, como crear fuentes de datos e instalar adaptadores de recursos. Para obtener información sobre los comandos de administración de paquetes de Ubuntu, consulte la documentació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 EAP 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 /home/site/wwwroot/app.war existe, impleméntelo.
  • Si existen otros archivos EAR y WAR en /home/site/wwwroot, impleméntelos.
  • Si /home/site/wwwroot/webapps existe, 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 en una única aplicación web.
  • Si no se encuentra ningún archivo implementable, 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 EAP se vuelve a cargar para aplicar los cambios que requieren una recarga de servidor.
  • Después de volver a cargar el servidor, las aplicaciones implementadas en el servidor 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 EAP sale anómalamente en la clustering configuración, se ejecuta una función final llamada emit_alert_tx_store_not_empty . La función comprueba si el proceso de JBoss EAP 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: cuando comprende el archivo server.xml y los detalles de configuración de Tomcat, puede ajustar 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. Este proceso incluye comprobar los registros del servidor, examinar los archivos de configuración e identificar los errores que puedan 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. Cuando comprenda los detalles de configuración del archivo de server.xml y 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. Debe comprender estos detalles 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 la 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 sobre el server.xml para la distribución de Tomcat al iniciarse. Estas transformaciones incluyen cambios 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

<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 está establecido en 16384.
  • URIEncoding está establecido en UTF-8.
  • connectionTimeout se establece en WEBSITE_TOMCAT_CONNECTION_TIMEOUT, que tiene 240000como valor predeterminado .
  • maxThreads se establece en WEBSITE_CATALINA_MAXTHREADS, que tiene 200como valor predeterminado .
  • maxConnections se establece en WEBSITE_CATALINA_MAXCONNECTIONS, que tiene 10000como valor predeterminado .

Nota

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

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

az webapp config appsettings set --resource-group myResourceGroup --name myApp --settings WEBSITE_TOMCAT_CONNECTION_TIMEOUT=120000

az webapp config appsettings set --resource-group myResourceGroup --name myApp --settings WEBSITE_CATALINA_MAXTHREADS=100

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.

Anfitrión

<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 /site/wwwrootcomo valor predeterminado .
  • unpackWARs se establece en AZURE_UNPACK_WARS, que tiene truecomo valor predeterminado .
  • workDir se establece en JAVA_TMP_DIR, que tiene TMPcomo valor predeterminado .
  • errorReportValveClass utiliza nuestra válvula de informe de errores personalizada.

Válvula

<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 home\logFilescomo valor predeterminado .
  • maxDays se establece en WEBSITE_HTTPLOGGING_RETENTION_DAYS, que tiene 7como valor predeterminado . Este valor se alinea con el valor predeterminado de la plataforma de registro de aplicaciones.

En Linux, tiene toda la misma personalización y agrega algunas páginas de error e informes a la válvula:

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

Contenido relacionado

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.