你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn

在 Azure 应用服务中部署和配置 Tomcat、JBoss 或 Java SE 应用

本文介绍应用服务中 Java 应用的最常见部署和运行时配置。 如果你从未用过 Azure 应用服务,首先应该通读 Java 快速入门应用服务常见问题解答中解答了有关使用应用服务且非特定于 Java 开发的一般问题。

Azure 应用服务以三种形式在完全托管的服务上运行 Java Web 应用程序:

  • Java SE - 可以运行作为 JAR 包(其中包含嵌入式服务器)部署的应用(例如 Spring Boot、Dropwizard、Quarkus,或包含嵌入式 Tomcat 或 Jetty 服务器的应用)。
  • Tomcat - 内置的 Tomcat 服务器可以运行作为 WAR 包部署的应用。
  • JBoss EAP - 仅支持“免费”、“高级 v3”和“独立 v2”定价层中的 Linux 应用。 内置的 JBoss EAP 服务器可以运行作为 WAR 或 EAR 包部署的应用。

注意

对于 Spring 应用程序,我们建议使用 Azure Spring Apps。 但是,你仍然可以使用 Azure 应用服务作为目标。 请参阅 Java 工作负荷目标指南以获取建议。

显示 Java 版本

要显示当前的 Java 版本,请在 Cloud Shell 中运行以下命令:

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

要显示所有受支持的 Java 版本,请在 Cloud Shell 中运行以下命令:

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

有关版本支持的详细信息,请参阅应用服务语言运行时支持策略

部署应用

生成工具

Maven

使用适用于 Azure Web 应用的 Maven 插件,可以在项目根中使用一个命令来轻松为 Azure Web 应用准备 Maven Java 项目:

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

此命令会提示你选择现有的或创建新的 Azure Web 应用,通过这种方式来添加 azure-webapp-maven-plugin 插件和相关配置。 在配置期间,它会尝试检测是否应将应用程序部署到 Java SE、Tomcat 或(仅限 Linux)JBoss EAP。 然后可以使用以下命令将 Java 应用部署到 Azure:

mvn package azure-webapp:deploy

下面是 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. 通过将适用于 Azure Web 应用的 Gradle 插件添加到 build.gradle 来设置该插件:

    plugins {
      id "com.microsoft.azure.azurewebapp" version "1.10.0"
    }
    
  2. 配置 Web 应用详细信息。 如果相应的 Azure 资源不存在,则会创建它们。 下面是示例配置。有关详细信息,请查看此文档

    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. 使用一个命令进行部署。

    gradle azureWebAppDeploy
    

IDE

Azure 在常用 Java IDE 中提供了无缝的 Java 应用服务开发体验,这些 IDE 包括:

Kudu API

若要将 .jar 文件部署到 Java SE,请使用 Kudu 站点的 /api/publish 终结点。 有关此 API 的详细信息,请参阅此文档

注意

必须将 .jar 应用程序命名为 app.jar,应用服务才能识别并运行该应用程序。 Maven 插件会在部署期间自动执行此操作。 如果不希望将 JAR 重命名为 app.jar,可使用命令上传 shell 脚本来运行 .jar 应用。 将此脚本的绝对路径粘贴到门户的“配置”部分的启动文件文本框中。 启动脚本不从放置它的目录运行。 因此,请始终使用绝对路径在启动脚本中引用文件(例如:java -jar /home/myapp/myapp.jar)。

若要将 .war 文件部署到 Tomcat,请使用 /api/wardeploy/ 终结点对存档文件执行 POST 操作。 有关此 API 的详细信息,请参阅此文档

若要将 .war 文件部署到 JBoss,请使用 /api/wardeploy/ 终结点对存档文件执行 POST 操作。 有关此 API 的详细信息,请参阅此文档

若要部署 .ear 文件,请使用 FTP。 .ear 应用程序会部署到应用程序配置中定义的上下文根。 例如,如果应用的上下文根是 <context-root>myapp</context-root>,则可以在 /myapp 路径中浏览该站点:http://my-app-name.azurewebsites.net/myapp。 如果希望在根路径中为 Web 应用提供服务,请确保应用将上下文根设置为根路径:<context-root>/</context-root>。 有关详细信息,请参阅设置 Web 应用程序的上下文根

不要使用 FTP 来部署 .war 或 .jar。 FTP 工具设计用来上传启动脚本、依赖项或其他运行时文件。 它不是用于部署 Web 应用的最佳选项。

重写或重定向 URL

若要重写或重定向 URL,请使用可用的 URL 重写程序之一,例如 UrlRewriteFilter

Tomcat 还提供重写阀

JBoss 还提供重写阀

日志记录和调试应用

可以通过 Azure 门户对每个应用使用性能报告、流量可视化和运行状况检查。 有关详细信息,请参阅 Azure 应用服务诊断概述

流式传输诊断日志

可以访问在容器中生成的控制台日志。

首先,请运行以下命令,以便启用容器日志记录功能:

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

<app-name><resource-group-name> 替换为适合 Web 应用的名称。

启用容器日志记录功能以后,请运行以下命令来查看日志流:

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

如果没有立即看到控制台日志,请在 30 秒后重新查看。

若要随时停止日志流式处理,可键入 CtrlC。

也可通过浏览器在 https://<app-name>.scm.azurewebsites.net/api/logs/docker 中检查日志文件。

有关详细信息,请参阅在 Cloud Shell 中流式传输日志

Linux 中的 SSH 控制台访问

若要通过容器打开直接的 SSH 会话,应用应该处于正在运行状态。

将以下 URL 粘贴到浏览器中,将 <app-name> 替换为应用名称:

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

如果尚未进行身份验证,则需通过要连接的 Azure 订阅进行身份验证。 完成身份验证以后,可以看到一个浏览器内 shell,可以在其中的容器中运行命令。

SSH 连接

注意

/home 目录之外进行的任何更改均存储在容器本身中,在应用重启后不保留。

若要从本地计算机打开远程 SSH 会话,请参阅从远程 shell 打开 SSH 会话

Linux 故障排除工具

内置的 Java 映像建立在 Alpine Linux 操作系统上。 使用 apk 包管理器安装任何故障排除工具或命令。

Java 探查器

Azure 应用服务上的所有 Java 运行时都附带 JDK 运行情况记录器,用于分析 Java 工作负载。 你可以使用它来记录 JVM、系统和应用程序事件,并排查应用程序中的问题。

若要了解有关 Java 探查器的详细信息,请访问 Azure Application Insights 文档

网络流量记录器

应用服务上的所有 Java 运行时都附带 Java Flight Recorder。 可以使用它来记录 JVM、系统和应用程序事件,并对 Java 应用程序中的问题进行故障排除。

使用 SSH 进入应用服务,运行 jcmd 命令以查看所有正在运行的 Java 进程的列表。 除了 jcmd 本身,你还会看到正在运行的 Java 应用程序以及进程 ID 号 (PID)。

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

执行以下命令以启动 JVM 的 30 秒录制。 它会分析 JVM 并在主目录创建一个名为“jfr_example.jfr”的 JFR 文件。 (将 116 替换为 Java 应用的 PID。)

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

在 30 秒的间隔内,可以通过运行 jcmd 116 JFR.check 来验证记录是否正在进行。 该命令会显示给定 Java 进程的所有录制。

连续记录

你可以使用 Java Flight Recorder 在对运行时的性能影响最小的情况下连续分析 Java 应用程序。 为此,请运行以下 Azure CLI 命令,通过必要的配置创建名为 JAVA_OPTS 的应用设置。 应用启动后,JAVA_OPTS 应用设置的内容会被传递到 java 命令。

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

开始记录后,你可以使用 JFR.dump 命令随时转储当前的记录数据。

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

分析 .jfr 文件

使用 FTPS 将 JFR 文件下载到本地计算机。 如果要分析 JFR 文件,请下载并安装 Java Mission Control。 有关 Java Mission Control 的说明,请参阅 JMC 文档安装说明

应用日志记录

通过 Azure 门户或 Azure CLI 启用应用程序日志记录,以将应用服务配置为向本地文件系统或 Azure Blob 存储写入应用程序的标准控制台输出和标准控制台错误流。 如果需要保留日志更长时间,请将应用程序配置为向 Blob 存储容器写入输出。

Java 和 Tomcat 应用日志位于 /home/LogFiles/Application/ 目录中。

只能使用 Azure Monitor 配置适用于基于 Linux 的应用的 Azure Blob 存储日志记录。

如果应用程序使用 LogbackLog4j 进行跟踪,则你可以遵照在 Application Insights 中浏览 Java 跟踪日志中的日志记录框架配置说明,将这些用于审查的跟踪写入到 Azure Application Insights。

注意

由于已知漏洞 CVE-2021-44228,请务必使用 Log4j 版本 2.16 或更高版本。

自定义和优化

Azure 应用服务原生支持通过 Azure 门户和 CLI 进行优化和自定义。 请查看以下文章了解非特定于 Java 的 Web 应用配置:

在本地复制应用内容

将应用设置 JAVA_COPY_ALL 设为 true,以将应用内容从共享文件系统复制到本地辅助角色。 此设置有助于解决文件锁定问题。

设置 Java 运行时选项

若要设置分配的内存或其他 JVM 运行时选项,请使用这些选项创建名为 JAVA_OPTS应用设置。 应用服务在启动时,会将此设置作为环境变量传递给 Java 运行时。

在 Azure 门户中 Web 应用的“应用程序设置”下,创建名为 JAVA_OPTS 且包含其他设置的新应用设置,例如 -Xms512m -Xmx1204m

在 Azure 门户中 Web 应用的“应用程序设置”下,创建名为 CATALINA_OPTS 且包含其他设置的新应用设置,例如 -Xms512m -Xmx1204m

若要通过 Maven 插件配置应用设置,请在 Azure 插件部分中添加设置/值标记。 以下示例设置特定的最小和最大 Java 堆大小:

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

注意

在 Windows 应用服务上使用 Tomcat 时,无需创建 web.config 文件。

在应用服务计划中运行包含一个部署槽位的单个应用程序的开发人员可以使用以下选项:

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

优化应用程序堆设置时,请查看应用服务计划详细信息,并考虑多个应用程序和部署槽位方面的需求,以得出最佳内存分配。

启用 Web 套接字

在 Azure 门户中应用程序的“应用程序设置”中启用 Web 套接字支持。 需要重启应用程序才能使设置生效。

在 Azure CLI 中使用以下命令启用 Web 套接字支持:

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

然后重启应用程序:

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

设置默认的字符编码

在 Azure 门户中 Web 应用的“应用程序设置”下,创建名为 JAVA_OPTS 且包含值 -Dfile.encoding=UTF-8 的新应用设置。

或者,可以使用应用服务 Maven 插件配置应用设置。 在插件配置中添加设置名称和值标记:

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

预编译 JSP 文件

要提高 Tomcat 应用程序的性能,可以先编译 JSP 文件,再部署到应用服务。 你可以使用由 Apache Sling 提供的 Maven 插件,也可以使用此 Ant 生成文件

日志中的 robots933456

你可能会在容器日志中看到以下消息:

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

可以放心忽略此消息。 /robots933456.txt 是一个虚拟 URL 路径,应用服务使用它来检查容器能否为请求提供服务。 404 响应只是指示该路径不存在,但它让应用服务知道容器处于正常状态并已准备就绪,可以响应请求。

选择 Java 运行时版本

应用服务允许用户选择 JVM 的主版本(例如 Java 8 或 Java 11)和补丁版本(例如 1.8.0_232 或 11.0.5)。 还可以选择在新的次要版本可用时自动更新补丁版本。 在大多数情况下,生产应用应使用 JVM 的固定补丁版本。 这可防止在补丁版本自动更新期间发生意外中断。 所有 Java Web 应用都使用 64 位 JVM,这是不可配置的。

如果使用 Tomcat,可以选择固定 Tomcat 的补丁版本。 在 Windows 上,可以固定 JVM 和 Tomcat 的补丁版本。 在 Linux 上,可以固定 Tomcat 的补丁版本;JVM 的补丁版本也会被固定,但不能单独配置。

如果选择固定次要版本,则需要定期更新应用上 JVM 的次要版本。 为了确保应用程序在较新的次要版本上运行,请创建一个过渡槽并在暂存站点上递增次要版本。 确认应用程序在新的次要版本上正常运行后,可以交换过渡槽和生产槽。

运行 JBoss CLI

在 JBoss 应用的 SSH 会话中,可以使用以下命令运行 JBoss CLI:

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

你可能无法进行连接,具体取决于 JBoss 在服务器生命周期中的位置。 请等候几分钟,然后重试。 此方法可用于快速检查当前的服务器状态(例如,查看数据源是否配置正确)。

此外,应用重启后,你在 SSH 会话中使用 JBoss CLI 对服务器所做的更改不会保留。 每次应用启动时,JBoss EAP 服务器都会以干净安装开始。 在启动生命周期期间,应用服务会进行必要的服务器配置并部署应用。 若要在 JBoss 服务器中进行任何持久更改,请使用自定义启动脚本或启动命令。 有关端到端示例,请参阅在 Azure 应用服务中为 Tomcat、JBoss 或 Java SE 应用配置数据源

也可手动配置应用服务,以在启动时运行任何文件。 例如:

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

有关可运行的 CLI 命令的详细信息,请参阅:

群集

应用服务支持 JBoss EAP 7.4.1 及更高版本的群集。 若要启用群集,Web 应用必须与虚拟网络集成。 当 Web 应用与虚拟网络集成时,它会重启,JBoss EAP 安装会以集群配置自动启动。 运行具有自动缩放功能的多个实例时,JBoss EAP 实例会通过虚拟网络集成中指定的子网相互通信。 可以通过创建名为 WEBSITE_DISABLE_CLUSTERING 的具有任何值的应用设置来禁用群集。

一个图,显示了横向扩展到三个实例的 VNet 集成式 JBoss 应用服务应用。

注意

如果要启用与 ARM 模板的虚拟网络集成,需要手动将属性 vnetPrivatePorts 设置为值 2。 如果从 CLI 或门户启用虚拟网络集成,则会自动为你设置此属性。

启用群集后,JBoss EAP 实例使用 FILE_PING JGroups 发现协议来发现新实例并保留群集信息,如群集成员、其标识符和 IP 地址。 在应用服务上,这些文件位于 /home/clusterinfo/ 下。 要启动的第一个 EAP 实例会获取对群集成员身份文件的读/写权限。 其他实例会读取文件,查找主节点,并与要包含在群集中并添加到文件中的节点进行协调。

注意

可以通过在应用启动期间清理过时的发现文件来避免 JBoss 群集超时。

可以选择在可用性区域间分布高级 V3 和独立 V2 应用服务计划类型,以提高业务关键型工作负载的复原能力和可靠性。 此体系结构也称为区域冗余。 JBoss EAP 群集功能与区域冗余功能兼容。

自动缩放规则

在配置用于水平缩放的自动缩放规则时,务必以递增方式(一次一个)删除实例,以确保每个被删除的实例可以将其活动(例如处理数据库事务)转移到群集的另一个成员。 在门户中配置用于纵向缩减的自动缩放规则时,请使用以下选项:

  • 操作:“计数递减”
  • 冷却:“5 分钟”或更长时间
  • 实例计数:1

不需要以递增方式添加实例(横向扩展),可以一次将多个实例添加到群集中。

应用服务计划

JBoss EAP 在以下定价层中可用:F1P0v3P1mv3P2mv3P3mv3P4mv3P5mv3

JBoss 服务器生命周期

应用服务中的 JBoss EAP 应用在实际启动服务器之前会经历五个不同的阶段。

有关详细信息以及自定义它的机会(例如通过应用设置来这样做),请参阅下面的相应部分。

1.环境设置阶段

  • 启动 SSH 服务以启用与容器的安全 SSH 会话
  • Java 运行时的密钥存储使用 Azure 门户中定义的任何公共和专用证书进行更新。
    • 公共证书由平台在 /var/ssl/certs 目录中提供,会加载到 $JRE_HOME/lib/security/cacerts
    • 专用证书由平台在 /var/ssl/private 目录中提供,会加载到 $JRE_HOME/lib/security/client.jks
  • 如果在此步骤中在 Java 密钥存储中加载了任何证书,则属性 javax.net.ssl.keyStorejavax.net.ssl.keyStorePasswordjavax.net.ssl.keyStoreType 将添加到 JAVA_TOOL_OPTIONS 环境变量中。
  • 确定了一些初始 JVM 配置,例如日志记录目录和 Java 内存堆参数:
    • 如果在应用设置 JAVA_OPTS 中为内存提供 –Xms–Xmx 标志,则这些值会替代平台提供的值。
    • 如果配置应用设置 WEBSITES_CONTAINER_STOP_TIME_LIMIT,则该值将传递给运行时属性 org.wildfly.sigterm.suspend.timeout,该属性控制停止 JBoss 时的最长关闭等待时间(以秒为单位)。
  • 如果应用与虚拟网络集成,则应用服务运行时会在环境变量 WEBSITE_PRIVATE_PORTS 中传递用于服务器间通信的端口列表,并使用 clustering 配置来启动 JBoss。 否则使用 standalone 配置。
    • 对于 clustering 配置,请使用服务器配置文件 standalone-azure-full-ha.xml
    • 对于 standalone 配置,请使用服务器配置文件 standalone-full.xml

2.服务器启动阶段

  • 如果在 clustering 配置中启动 JBoss:
    • 每个 JBoss 实例都会收到一个介于 0 到应用横向扩展到的实例数之间的内部标识符。
    • 如果在此服务器实例的事务存储路径中找到某些文件(通过使用其内部标识符来这样做),则意味着此服务器实例正在取代以前崩溃并留下未提交事务的相同服务实例。 服务器配置为继续在这些事务上进行的工作。
  • 无论 JBoss 是在 clustering 配置还是 standalone 配置中启动,如果服务器版本是 7.4 或更高版本,并且运行时使用 Java 17,则会对配置进行更新以启用 Elytron 子系统来确保安全。
  • 如果配置应用设置 WEBSITE_JBOSS_OPTS,该值将传递给 JBoss 启动器脚本。 此设置可用于提供属性文件的路径以及影响 JBoss 启动的更多标志。

3.服务器配置阶段

  • 在此阶段开始时,应用服务首先等待 JBoss 服务器和管理界面做好接收请求的准备,然后才继续操作。 如果启用了 Application Insights,这可能需要多花几秒钟的时间。
  • 当 JBoss 服务器和管理界面都准备就绪后,应用服务会执行以下操作:
    • 添加 JBoss 模块 azure.appservice,该模块提供用于日志记录以及与应用服务集成的实用工具类。
    • 更新控制台记录器以使用无色模式,使日志文件不会充满颜色转义序列。
    • 设置与 Azure Monitor 日志的集成。
    • 更新 WSDL 和管理接口的绑定 IP 地址。
    • 添加 JBoss 模块 azure.appservice.easyauth,以便与应用服务身份验证和 Microsoft Entra ID 集成。
    • 更新访问日志的日志记录配置以及主服务器日志文件的名称和轮换。
  • 除非定义了应用设置 WEBSITE_SKIP_AUTOCONFIGURE_DATABASE,否则应用服务会在应用服务应用设置中自动检测 JDBC URL。 如果存在有效的用于 PostgreSQL、MySQL、MariaDB、Oracle、SQL Server 或 Azure SQL 数据库的 JDBC URL,它会将相应的驱动程序添加到服务器并为每个 JDBC URL 添加一个数据源,同时将每个数据源的 JNDI 名称设置为 java:jboss/env/jdbc/<app-setting-name>_DS,其中 <app-setting-name> 是应用设置的名称。
  • 如果启用了 clustering 配置,则会检查要配置的控制台记录器。
  • 如果有 JAR 文件部署到 /home/site/libs 目录,则使用所有这些 JAR 文件创建一个新的全局模块。
  • 在该阶段结束时,应用服务会运行自定义启动脚本(如果存在)。 自定义启动脚本的搜索逻辑如下:
    • 如果已配置启动命令(使用 Azure 门户、Azure CLI 等方式),请运行该命令;否则,
    • 如果路径 /home/site/scripts/startup.sh 存在,请使用它;否则,
    • 如果路径 /home/startup.sh 存在,请使用它。

自定义启动命令或脚本以根用户身份运行(不需要 sudo),因此可以安装 Linux 包或启动 JBoss CLI 来执行更多 JBoss 安装/自定义命令(创建数据源、安装资源适配器)等。有关 Ubuntu 包管理命令的信息,请参阅 Ubuntu Server 文档。 有关 JBoss CLI 命令,请参阅 JBoss 管理 CLI 指南

4.应用部署阶段

启动脚本通过按优先顺序查找以下位置将应用部署到 JBoss:

  • 如果配置了应用设置 WEBSITE_JAVA_WAR_FILE_NAME,请部署其指定的文件。
  • 如果 /home/site/wwwroot/app.war 存在,请部署它。
  • 如果 /home/site/wwwroot 中存在任何其他的 EAR 文件和 WAR 文件,请部署它们。
  • 如果 /home/site/wwwroot/webapps 存在,请部署其中的文件和目录。 WAR 文件本身作为应用程序部署,而目录则作为“展开的”(未压缩的)Web 应用部署。
  • 如果 /home/site/wwwroot 中存在任何独立的 JSP 页面,请将其复制到 Web 服务器根目录并将其部署为一个 Web 应用。
  • 如果尚未找到可部署文件,则在根上下文中部署默认欢迎页(驻留页)。

5.服务器重新加载阶段

  • 部署步骤完成后,将重新加载 JBoss 服务器以应用任何需要服务器重新加载的更改。
  • 服务器重新加载后,部署到 JBoss EAP 服务器的应用程序应该就做好响应请求的准备了。
  • 服务器会一直运行,直到应用服务应用停止或重启。 可以手动停止或重启应用服务应用,也可以在部署文件或对应用服务应用进行配置更改时触发重启。
  • 如果 JBoss 服务器在 clustering 配置中异常退出,则会执行名为 emit_alert_tx_store_not_empty 的最终函数。 该函数会检查 JBoss 进程是否在磁盘中留下了非空的事务存储文件;如果留下了该类文件,则会在控制台中记录错误:Error: finishing server with non-empty store for node XXXX。 启动新的服务器实例时,它会寻找这些非空的事务存储文件来继续完成工作(请参阅 2.服务器启动阶段)。

Tomcat 基线配置

注意

本部分仅适用于 Linux。

如果 Java 开发人员了解 server.xml 文件和 Tomcat 的配置详细信息,他们就可以自信地自定义服务器设置、排查问题并将应用程序部署到 Tomcat。 可能的自定义包括:

  • 自定义 Tomcat 配置:通过了解 server.xml 文件和 Tomcat 的配置详细信息,可以微调服务器设置以满足其应用程序的需求。
  • 调试:在 Tomcat 服务器上部署应用程序时,开发人员需要了解服务器配置以调试可能出现的任何问题。 其中包括检查服务器日志、检查配置文件以及识别可能发生的任何错误。
  • 排查 Tomcat 问题:Java 开发人员不可避免地会遇到 Tomcat 服务器问题,例如性能问题或配置错误。 通过了解 server.xml 文件和 Tomcat 的配置详细信息,开发人员可以快速诊断和排查这些问题,从而节省时间和精力。
  • 将应用程序部署到 Tomcat:若要将 Java Web 应用程序部署到 Tomcat,开发人员需要了解如何配置 server.xml 文件和其他 Tomcat 设置。 了解这些详细信息对于成功部署应用程序并确保它们在服务器上顺利运行至关重要。

当你使用内置 Tomcat 创建应用来托管 Java 工作负载(WAR 文件或 JAR 文件)时,Tomcat 配置中有一些现成的设置。 有关详细信息,请参阅 Apache Tomcat 官方文档,其中包括 Tomcat Web 服务器的默认配置。

此外,在启动 Tomcat 发行版时,还会在 server.xml 之上进一步应用某些转换。 这些转换是连接器、主机和阀设置的转换。

Tomcat 的最新版本具有 server.xml(8.5.58 和 9.0.38 及更高版本)。 旧版本的 Tomcat 不使用转换,因此可能会有不同的行为。

连接器

<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 设置为 16384
  • URIEncoding 设置为 UTF-8
  • connectionTimeout 设置为 WEBSITE_TOMCAT_CONNECTION_TIMEOUT,默认为 240000
  • maxThreads 设置为 WEBSITE_CATALINA_MAXTHREADS,默认为 200
  • maxConnections 设置为 WEBSITE_CATALINA_MAXCONNECTIONS,默认为 10000

注意

可以使用应用设置优化 connectionTimeout、maxThreads 和 maxConnections 设置

以下是一条示例 CLI 命令,可用于更改 connectionTimeout、maxThreads 或 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
  • 连接器使用容器的地址,而不是 127.0.0.1

主机

<Host appBase="${site.appbase}" xmlBase="${site.xmlbase}" unpackWARs="${site.unpackwars}" workDir="${site.tempdir}" errorReportValveClass="com.microsoft.azure.appservice.AppServiceErrorReportValve" name="localhost" autoDeploy="true">
  • appBase 设置为 AZURE_SITE_APP_BASE,默认为本地 WebappsLocalPath
  • xmlBase 设置为 AZURE_SITE_HOME,默认为 /site/wwwroot
  • unpackWARs 设置为 AZURE_UNPACK_WARS,默认为 true
  • workDir 设置为 JAVA_TMP_DIR,默认为 TMP
  • errorReportValveClass 使用我们的自定义错误报告阀

<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 设置为 AZURE_LOGGING_DIR,默认为 home\logFiles
  • maxDaysWEBSITE_HTTPLOGGING_RETENTION_DAYS,默认为 0 [永久]

在 Linux 上,它具有所有相同的自定义项,以及:

  • 向阀添加一些错误和报告页:

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

后续步骤

请访问面向 Java 开发人员的 Azure 中心查找 Azure 快速入门、教程和 Java 参考文档。