共用方式為

在 Azure App Service 中部署及設定 Tomcat、JBoss 或 Java SE 應用程式

  • 發行項

本文說明 App Service 中 Java 應用程式最常見的部署和執行階段設定。 如果您從未使用過 Azure App Service，則請先閱讀 Java 快速入門。 App Service 常見問題集中回答了非 Java 開發特定的一般 App Service 使用問題。

Azure App Service 會以三種變體在完全受控的服務上執行 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 應用程式。 不過，您仍然可以使用 Azure App Service 作為目的地。 如需建議，請參閱 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"

如需版本支援的詳細資訊，請參閱 App Service 語言執行階段支援原則。

部署應用程式

建置工具

Maven

透過適用於 Azure Web Apps 的 Maven 外掛程式，您只要在專案根目錄中使用一個命令，就能輕鬆地讓 Maven Java 專案準備好使用 Azure Web Apps：

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. 將此外掛程式新增至 build.gradle，以設定適用於 Azure Web Apps 的 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 App Service 開發體驗，包括：

Kudu API

若要將 .jar 檔案部署到 Java SE，請使用 Kudu 網站的 /api/publish 端點。 如需有關此 API 的詳細資訊，請參閱這份文件。

注意

您的 .jar 應用程式必須命名為 app.jar，App Service 才能識別並執行您的應用程式。 Maven 外掛程式會在部署期間自動為您執行此動作。 如果您不想要將 JAR 重新命名為 app.jar，則可以使用命令上傳殼層指令碼來執行 .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 App Service 診斷概觀。

資料流診斷記錄

您可以存取從容器產生的主控台記錄。

請先執行下列命令來開啟容器記錄：

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

以適合您 Web 應用程式的名稱取代 <app-name> 和 <resource-group-name>。

開啟容器記錄後，請執行下列命令來查看記錄資料流：

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

如果您沒有立即看到主控台記錄，請在 30 秒後再查看。

若要隨時停止記錄資料流，請輸入 Ctrl+C。

您也可以在瀏覽器中的 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 訂用帳戶進行驗證才能連線。 驗證之後，您會看到瀏覽器中的殼層，您可以在其中執行您容器內的命令。

SSH 連線

注意

您在 /home 目錄以外進行的任何變更都會儲存在容器中，在應用程式重新啟動之後便不會保存。

若要從本機電腦開啟遠端 SSH 工作階段，請參閱從遠端殼層開啟 SSH 工作階段。

Linux 疑難排解工具

內建的 JAVA 映像是以 Alpine Linux 作業系統為基礎。 使用 apk 套件管理員來安裝疑難排解工具或命令。

Java Profiler

Azure App Service 上的所有 Java 執行階段都隨附 JDK 發行小眾測試版錄製器，可用來分析 Java 工作負載。 您可以使用此工具來記錄 JVM、系統和應用程式事件，並針對應用程式中的問題進行疑難排解。

若要深入了解 Java 分析工具，請瀏覽 Azure Application Insights 文件。

飛行記錄器

App Service 上的所有 Java 執行階段都會隨附 Java Flight Recorder。 您可以使用此工具來記錄 JVM、系統和應用程式事件，並針對 Java 應用程式中的問題進行疑難排解。

使用 SSH 連線到 App Service，並執行 jcmd 命令，以查看所有執行中的 Java 程序清單。 除了 jcmd 本身之外，您應該會看到 Java 應用程式以進程識別碼 （pid） 執行。

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

執行下列命令，以啟動 30 秒的 JVM 錄製。 其會分析 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 啟用應用程式記錄，設定 App Service 將應用程式的標準主控台輸出和標準主控台錯誤資料流寫入至本機檔案系統或 Azure Blob 儲存體。 如果您需要較長的保留期，則請設定應用程式將輸出寫入至 Blob 儲存體容器。

JAVA 和 Tomcat 應用程式記錄可以在 /home/LogFiles/Application/ 目錄中找到。

您只能使用 Azure 監視器來設定 Linux 型應用程式的 Azure Blob 儲存體記錄。

如果您的應用程式使用 Logback 或 Log4j 追蹤，則您可以使用在 Application Insights 中探索 Java 追蹤記錄中的記錄架構設定指示，將這些要檢閱的追蹤轉送至 Azure Application Insights。

注意

由於已知的弱點 CVE-2021-44228，請務必使用 Log4j 2.16 版或更新版本。

自訂和調整

Azure App Service 支援透過 Azure 入口網站和 CLI 的預設調整和自訂。 請檢閱下列非 Java 特定 Web 應用程式設定的文章：

在本機複製應用程式內容

將應用程式設定 JAVA_COPY_ALL 設為 true，以從共用檔案系統將應用程式內容複製到本機背景工作角色。 此設定有助於解決檔案鎖定問題。

設定 Java 執行階段選項

若要設定配置的記憶體或其他 JVM 執行階段選項，請使用選項建立名為 JAVA_OPTS 的應用程式設定。 App Service 會在啟動時將此設定當成環境變數傳遞至 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 App Service 上使用 Tomcat 時，您不需要建立 web.config 檔案。

執行具有其 App Service 方案中某個部署位置的單一應用程式開發人員，可以使用下列選項：

  • 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

調整應用程式堆積設定時，請檢閱 App Service 方案詳細資料，並考慮多個應用程式和部署位置需求以尋找最佳的記憶體配置。

開啟 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 的新應用程式設定。

或者，您可以使用 App Service Maven 外掛程式來設定應用程式設定。 在外掛程式設定中新增設定名稱和值標籤：

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

預先編譯 JSP 檔案

若要改善 Tomcat 應用程式的效能，您可以先編譯 JSP 檔案，再部署至 App Service。 您可以使用 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 路徑，App Service 會使用該路徑來檢查容器是否可以處理要求。 404 回應只是指出路徑不存在，但其可讓 App Service 知道容器狀況良好，並已準備好回應要求。

選擇 Java 執行階段版本

App Service 可讓使用者選擇 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 伺服器都會從全新安裝開始。 在 啟動生命周期期間，App Service 會進行必要的伺服器設定並部署應用程式。 若要在 JBoss 伺服器中進行任何持續性變更，請使用 自訂啟動腳本或啟動命令。 如需端對端範例，請參閱在 Azure App 服務 中設定 Tomcat、JBoss 或 Java SE 應用程式的數據源。

或者，您可以手動設定 App Service 在啟動時執行任何檔案。 例如：

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

如需您可以執行之 CLI 命令的詳細資訊，請參閱：

叢集

App Service 可針對 JBoss EAP 7.4.1 版和更新版本來支援叢集功能。 若要啟用叢集功能，您的 Web 應用程式必須與虛擬網路整合。 Web 應用程式在與虛擬網路整合時會重新啟動，而且 JBoss EAP 安裝會自動以叢集設定來啟動。 當您 使用自動調整執行多個實例時，JBoss EAP 實例會透過虛擬網路整合中指定的子網彼此通訊。 您可以使用任何值建立名為 WEBSITE_DISABLE_CLUSTERING 的應用程式設定，以停用叢集功能。

此圖顯示 vnet 整合的 JBoss App Service 應用程式，已相應放大為三個實例。

注意

如果您要使用 ARM 範本來啟用虛擬網路整合，則必須以手動方式將 vnetPrivatePorts 屬性設定為 2 這個值。 如果您從 CLI 或入口網站啟用虛擬網路整合，則系統會自動為您設定此屬性。

啟用叢集功能時，JBoss EAP 執行個體會使用 FILE_PING JGroups 探索通訊協定來探索新的執行個體，並保存叢集資訊，例如叢集成員、其識別碼及其 IP 位址。 在 App Service 上，這些檔案位於 /home/clusterinfo/ 底下。 要啟動的第一個 EAP 執行個體會取得叢集成員資格檔案上的讀取/寫入權限。 其他執行個體則會讀取檔案、尋找主要節點，並與要納入叢集中並新增至檔案的該節點協調。

注意

您可以在應用程式啟動期間清除過時的探索檔案，以避免 JBoss 叢集逾時。

進階 V3 和隔離 V2 App Service 方案類型可以選擇性地分散到可用性區域，以改善業務關鍵工作負載的復原能力和可靠性。 此架構也稱為區域備援。 JBoss EAP 叢集功能可與區域備援功能相容。

自動調整規則

設定水平調整的自動調整規則時，請務必以累加的方式移除執行個體 (一次移除一個執行個體)，以確保每個移除的執行個體都可以將其活動 (例如處理資料庫交易) 傳送給叢集的另一個成員。 在入口網站中設定自動調整規則以調降規模時，請使用下列選項：

  • 作業：「將計數減少」
  • 冷卻時間：「5 分鐘」或更久
  • 執行個體計數：1

您不需要以累加的方式新增執行個體 (擴增)，您可以一次將多個執行個體新增至叢集。

App Service 方案

JBoss EAP 適用於下列定價層：F1、P0v3、P1mv3、P2mv3、P3mv3、P4mv3 和 P5mv3。

JBoss 伺服器生命週期

App Service 中的 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.keyStore和 javax.net.ssl.keyStorePassword javax.net.ssl.keyStoreType 會新增至 JAVA_TOOL_OPTIONS 環境變數。
  • 某些初始 JVM 設定會決定，例如記錄目錄和 Java 記憶體堆積參數：
    • 如果您在應用程式設定JAVA_OPTS中提供記憶體的 –Xms 或 –Xmx 旗標，這些值會覆寫平臺所提供的值。
    • 如果您設定應用程式設定 WEBSITES_CONTAINER_STOP_TIME_LIMIT，則會將值傳遞至運行時間屬性 org.wildfly.sigterm.suspend.timeout，以控制 JBoss 停止時的最大關機等候時間（以秒為單位）。
  • 如果應用程式與虛擬網路整合，App Service 運行時間會傳遞埠清單，以用於環境變數 WEBSITE_PRIVATE_PORTS 中的伺服器間通訊，並使用組態啟動 JBoss clustering 。 否則會使用組 standalone 態。
    • 針對組 clustering 態，會使用伺服器組態檔 standalone-azure-full-ha.xml 。
    • 針對組 standalone 態，會使用伺服器組態檔 standalone-full.xml 。

2.伺服器啟動階段

  • 如果在組態中 clustering 啟動 JBoss：
    • 每個 JBoss 實例都會收到介於 0 與應用程式相應放大的實例數目之間的內部識別碼。
    • 如果在此伺服器實例的交易存放區路徑中找到某些檔案（使用其內部標識符），表示此伺服器實例會取代先前當機的相同服務實例，並將未認可的交易拋在後面。 伺服器已設定為繼續這些交易的工作。
  • 無論 JBoss 從 或 standalone 組態開始clustering，如果伺服器版本是 7.4 或更新版本，且運行時間使用 Java 17，則會更新組態以啟用 Elytron 子系統的安全性。
  • 如果您設定應用程式設定 WEBSITE_JBOSS_OPTS，該值會傳遞至 JBoss 啟動器文稿。 此設定可用來提供屬性檔案的路徑，以及影響 JBoss 啟動的更多旗標。

3.伺服器設定階段

  • 在此階段開始時，App Service 會先等候 JBoss 伺服器和系統管理介面準備好接收要求，然後再繼續。 如果已啟用 Application Insights，這可能需要幾秒鐘的時間。
  • 當 JBoss Server 和系統管理介面都就緒時，App Service 會執行下列動作：
    • 新增 JBoss 模組 azure.appservice，其提供公用程式類別來記錄和與 App Service 整合。
    • 更新主控台記錄器以使用無色模式，讓記錄檔不會滿是色彩逸出序列。
    • 設定與 Azure 監視器記錄的整合。
    • 更新 WSDL 和管理介面的系結 IP 位址。
    • 新增 JBoss 模組 azure.appservice.easyauth ，以便與 App Service 驗證 整合，並Microsoft Entra ID。
    • 更新存取記錄的記錄組態，以及主伺服器記錄檔的名稱和輪替。
  • 除非定義應用程式設定 WEBSITE_SKIP_AUTOCONFIGURE_DATABASE ，否則 App Service 會在 App Service 應用程式設定中自動偵測 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 檔案來建立新的全域模組。
  • 在階段結束時，如果存在，App Service 就會執行自定義啟動腳本。 自訂啟動文稿的搜尋邏輯如下所示：
    • 如果您已設定啟動命令（在 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 應用程式。
  • 如果尚未找到可部署的檔案，請在根內容中部署默認歡迎頁面（停車頁面）。

5.伺服器重載階段

  • 部署步驟完成後，JBoss 伺服器會重載以套用任何需要伺服器重載的變更。
  • 在伺服器重載之後，部署至 JBoss EAP 伺服器的應用程式應該已準備好回應要求。
  • 伺服器會執行，直到 App Service 應用程式停止或重新啟動為止。 您可以手動停止或重新啟動App Service應用程式，或在部署檔案或變更App Service 應用程式時觸發重新啟動。
  • 如果 JBoss 伺服器在設定中 clustering 異常結束，則會執行名為 emit_alert_tx_store_not_empty 的最終函式。 函式會檢查 JBoss 進程是否在磁碟留下無空交易存放區檔案;如果是，則會在控制台中記錄錯誤： Error: finishing server with non-empty store for node XXXX。 啟動新的伺服器實例時，它會尋找這些無空交易存放區檔案以繼續工作（請參閱 2。伺服器啟動階段）。

Tomcat 基準設定

注意

本節僅適用於 Linux。

如果 Java 開發人員知道 Tomcat 的 server.xml 檔案和設定詳細資料，便可以放心地自訂伺服器設定、針對問題進行疑難排解，以及將應用程式部署至 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 網頁伺服器預設設定在內的詳細資訊。

此外，某些轉換會在啟動時進一步套用至 server.xml 上以便進行 Tomcat 散發。 這些是連接器、主機和閥門設定的轉換。

最新版的 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 設定可以使用應用程式設定來微調

以下是可用來改變 connectionTimeout、maxThreads 或 maxConnections 值的範例 CLI 命令：

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

<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
  • maxDays 是 ， WEBSITE_HTTPLOGGING_RETENTION_DAYS預設為 7。 這會與應用程式記錄平台預設值一致

在 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 參考文件。