Compartir a través de

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

  • Artículo

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.

Nota:

Para las aplicaciones de Spring, se recomienda usar Azure Spring Apps. No obstante, todavía puede usar Azure App Service como destino. Consulte guía de destino de carga de trabajo de Java para obtener consejos.

Visualización de la versión de Java

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

az webapp config show --name <app-name> --resource-group <resource-group-name> --query "[javaVersion, javaContainer, javaContainerVersion]"

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

az webapp list-runtimes --os windows | grep java

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:

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:

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 mediante su incorporación 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 detalles, vea 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 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.

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

Para acceder a los registros de la consola generados desde el código de la aplicación en App Service, active el registro de diagnósticos, para lo que debe ejecutar el siguiente comando en Cloud Shell:

az webapp log config --resource-group <resource-group-name> --name <app-name> --docker-container-logging filesystem --level Verbose

Los valores posibles de --level son: Error, Warning, Info y Verbose. Todos los niveles incluyen el nivel anterior. Por ejemplo: Error incluye solo los mensajes de error, mientras que Verbose incluye todos los mensajes.

Una vez que se activa el registro de contenedor, ejecute el siguiente comando para ver la transmisión del registro:

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

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

Nota

También puede inspeccionar los archivos de registro desde el explorador en https://<app-name>.scm.azurewebsites.net/api/logs/docker.

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

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.

Grabación temporizada

Para realizar una grabación temporizada, necesita el PID (id. de proceso) de la aplicación Java. Para buscar el PID, abra un explorador en el sitio de SCM de la aplicación web en https://<your-site-name>.scm.azurewebsites.net/ProcessExplorer/. En esta página se muestran los procesos en ejecución en la aplicación web. Busque el proceso denominado "Java" en la tabla y copie el PID (identificador de proceso) correspondiente.

A continuación, abra la Consola de depuración en la barra de herramientas superior del sitio de SCM y ejecute el siguiente comando. Reemplace <pid> por el identificador de proceso que ha copiado anteriormente. Este comando inicia una grabación de 30 segundos del generador de perfiles de su aplicación Java y genera un archivo denominado timed_recording_example.jfr en el directorio C:\home.

jcmd <pid> JFR.start name=TimedRecording settings=profile duration=30s filename="C:\home\timed_recording_example.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. El registro en la instancia del sistema de archivos local de App Service se deshabilita 12 horas después de habilitarlo. 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/ .

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:

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

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.

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:

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

Nota:

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.

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. Las instancias de JBoss EAP se comunican a través de la subred especificada en la integración de red virtual, mediante los puertos que se muestran en la variable de entorno WEBSITES_PRIVATE_PORTS en tiempo de ejecución. 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.

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 solo está disponible en los tipos de plan Premium v3 y Aislado v2 de App Service. Los clientes que crearon un sitio de JBoss EAP en un nivel diferente durante la versión preliminar pública deben escalar verticalmente a un nivel de hardware Premium o Aislado para evitar un comportamiento inesperado.

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

<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.
  • conectionTimeout 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 comandos de la CLI de ejemplo que puede usar para modificar los valores de conectionTimeout, maxThreads o 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

Host

<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

<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 es WEBSITE_HTTPLOGGING_RETENTION_DAYS, que tiene como valor predeterminado 0 [para siempre]

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

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

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.