將 Tomcat 應用程式遷移至 Azure App Service 上的 Tomcat

本指南說明當您想要移轉現有的Tomcat應用程式以使用Tomcat 9.0在 Azure App 服務上執行時,應該注意的事項。

移轉前

若要確保成功移轉,請先完成下列各節所述的評量和清查步驟。

如果您無法符合上述任何預先移轉需求,請參閱下列隨附移轉指南:

切換至支持的平臺

App Service 在特定 Java 版本上提供特定版本的 Tomcat。 若要確保相容性,請先將應用程式移轉至目前環境中其中一個支援的 Tomcat 和 Java 版本,再繼續進行其餘步驟。 請務必完整測試產生的組態。 在這類測試中使用Linux發行版的最新穩定版本。

注意

如果您的目前伺服器是在不支援的 JDK 上執行,此驗證特別重要(例如 Oracle JDK 或 IBM OpenJ9)。

若要取得目前的 Java 版本,請登入您的生產伺服器,然後執行下列命令:

java -version

在 Azure App 服務,Java 8 的二進位檔會從 Eclipse Temurin 提供。 針對 Java 11、17 和所有未來的 JAVA LTS 版本,App Service 會提供 Microsoft Build of OpenJDK。 這些二進位檔可在下列網站免費下載:

若要取得您目前的 Tomcat 版本,請登入您的生產伺服器,然後執行下列命令:

${CATALINA_HOME}/bin/version.sh

若要取得 Azure App 服務 所使用的目前版本,請下載 Tomcat 9,視您打算在 Azure App 服務 中使用的版本而定。

清查外部資源

外部資源,例如數據源、JMS 訊息代理程式,以及其他資源會透過 Java 命名和目錄介面 (JNDI) 插入。 某些這類資源可能需要移轉或重新設定。

在您的應用程式內

檢查 META-INF/context.xml 檔案。 尋找 <Resource> 元素內的 <Context> 元素。

在應用程式伺服器上

檢查 $CATALINA_BASE/conf/context.xml$CATALINA_BASE/conf/server.xml 檔案,以及 $CATALINA_BASE/conf/[engine-name]/[host-name] 目錄中找到的 .xml 檔案。

在context.xml檔案中,最上層<Context>元素內的元素將會描述 <Resource> JNDI資源。

在 server.xml 檔案中,JNDI 資源將由 元素內的<GlobalNamingResources>元素描述<Resource>

資料來源

資料來源是 JNDI 資源, type 屬性設定為 javax.sql.DataSource。 針對每個數據源,記載下列資訊:

  • 數據源名稱為何?
  • 什麼是聯機集區設定?
  • 哪裡可以找到 JDBC 驅動程式 JAR 檔案?

如需詳細資訊,請參閱 Tomcat檔中的JNDI資料源操作說明

所有其他外部資源

在本指南中記載每個可能的外部相依性並不可行。 您的小組有責任確認您可以在移轉後滿足應用程式的每個外部相依性。

清查秘密

密碼和安全字串

檢查生產伺服器上的所有屬性和組態檔,以取得任何秘密字串和密碼。 請務必在 $CATALINA_BASE/conf 中檢查 server.xmlcontext.xml 您也可以在應用程式內找到包含密碼或認證的組態檔。 這可能包括 META-INF/context.xml,以及 Spring Boot 應用程式、 application.propertiesapplication.yml 檔案。

清查憑證

記錄用於公用 SSL 端點或與後端資料庫和其他系統通訊的所有憑證。 您可以執行下列命令來檢視生產伺服器上的所有憑證:

keytool -list -v -keystore <path to keystore>

判斷文件系統是否使用和方式

應用程式伺服器上的檔案系統使用方式都需要重新設定,或在某些情況下,架構變更。 您可以識別下列部分或所有案例。

唯讀靜態內容

如果您的應用程式目前提供靜態內容,您將需要其替代位置。 您可能想要考慮將靜態內容移至 Azure Blob 儲存體,並新增 Azure CDN 以進行全球閃電快速下載。 如需詳細資訊,請參閱靜態網站裝載 Azure 儲存體快速入門:整合 Azure 儲存器帳戶與 Azure CDN。 您也可以直接將靜態內容部署到 Azure Spring Apps 企業版方案中的應用程式。 如需詳細資訊,請參閱 部署Web靜態檔案

動態發佈的靜態內容

如果您的應用程式允許應用程式上傳/產生的靜態內容,但在建立後是不可變的,您可以使用如上所述 Azure Blob 儲存體 和 Azure CDN,搭配 Azure 函式來處理上傳和 CDN 重新整理。 我們在使用 Azure Functions 上傳和 CDN 預先載入靜態內容時,提供了範例實作。 您也可以直接將靜態內容部署到 Azure Spring Apps 企業版方案中的應用程式。 如需詳細資訊,請參閱 部署Web靜態檔案

動態或內部內容

對於應用程式經常寫入和讀取的檔案(例如暫存數據檔),或只有應用程式可見的靜態檔案,您可以將 Azure 儲存體 掛接至 App Service 檔案系統。 如需詳細資訊,請參閱在 Linux 上的 App Service 中提供來自 Azure 儲存體 的內容。

識別會話持續性機制

若要識別正在使用中的會話持續性管理員,請檢查 應用程式和 Tomcat 組態中的 context.xml 檔案。 尋找 <Manager> 項目,然後記下 屬性的值 className

Tomcat 的內建 PersistentManager 實作,例如 StandardManagerFileStore,並非專為搭配分散式、縮放平臺使用而設計,例如 App Service。 由於 App Service 可能會在數個實例之間進行負載平衡,且隨時透明地重新啟動任何實例,因此不建議將可變狀態保存到文件系統。

如果需要會話持續性,您必須使用替代 PersistentManager 實作來寫入外部數據存放區,例如具有 Redis 快取的 VMware Tanzu 會話管理員。 如需詳細資訊,請參閱 搭配 Tomcat 使用 Redis 作為會話快取。

識別在生產伺服器上執行的所有外部進程和精靈

如果您有在應用程式伺服器外部執行的任何進程,例如監視精靈,您必須將其消除或移轉至別處。

特殊情況

某些生產案例可能需要額外的變更,或施加額外的限制。 雖然這類案例可能不常發生,但請務必確保它們無法套用至您的應用程式或正確解決。

判斷應用程式是否依賴排程的作業

無法搭配 App Service 使用排程器工作或 cron 作業等排程工作。 App Service 不會防止您在內部部署包含排程工作的應用程式。 不過,如果您的應用程式相應放大,則每個排程期間,相同的排程工作可能會執行多次。 這種情況可能會導致非預期的後果。

清查應用程式伺服器內部或外部的任何排程工作。

判斷您的應用程式是否包含 OS 特定程式代碼

如果您的應用程式包含主機 OS 上具有相依性的任何程式代碼,則必須重構它以移除這些相依性。 例如,您可能需要以 或 \ 取代檔案系統路徑File.Separator中的任何 使用 /Paths.get

判斷是否使用 Tomcat 叢集

Azure App 服務 不支援Tomcat叢集。 相反地,您可以透過 Azure App 服務 設定及管理調整與負載平衡,而不需要Tomcat特定的功能。 您可以將會話狀態保存到替代位置,使其可在複本之間使用。 如需詳細資訊,請參閱 識別會話持續性機制

若要判斷您的應用程式是否使用叢集,請在 server.xml 檔案中<Host>尋找 <Cluster><Engine> 元素內的 專案。

判斷是否使用非 HTTP 連接器

App Service 僅支援單一 HTTP 連接器。 如果您的應用程式需要其他連接器,例如 AJP 連接器,請勿使用 App Service。

若要識別應用程式所使用的 HTTP 連接器,請在 Tomcat 組態中的 server.xml 檔案內尋找<Connector>元素。

判斷是否使用MemoryRealm

MemoryRealm 需要保存的 XML 檔案。 在 Azure AppService 上,您必須將此檔案上傳至 /home 目錄或其其中一個子目錄,或掛接的記憶體。 接著,您必須據以修改 pathName 參數。

若要判斷目前是否 MemoryRealm 使用,請檢查您的 server.xmlcontext.xml 檔案,並搜尋 <Realm>className 屬性設定為 org.apache.catalina.realm.MemoryRealm的專案。

判斷是否使用 SSL 工作階段追蹤

App Service 會在 Tomcat 運行時間之外執行會話卸除,因此您無法使用 SSL 會話追蹤。 請改用不同的會話追蹤模式 (COOKIEURL)。 如果您需要 SSL 會話追蹤,請勿使用 App Service。

判斷是否使用 AccessLogValve

如果您使用 AccessLogValve,您應該將 參數設定 directory/home/LogFiles 或其其中一個子目錄。

遷移

參數化組態

在移轉前步驟中,您可能會在 server.xml 和 context.xml 檔案中識別某些秘密和外部相依性,例如數據源。 針對您識別的每個專案,將任何使用者名稱、密碼、連接字串 或URL取代為環境變數。

例如,假設 context.xml 檔案包含下列元素:

<Resource
    name="jdbc/dbconnection"
    type="javax.sql.DataSource"
    url="jdbc:postgresql://postgresdb.contoso.com/wickedsecret?ssl=true"
    driverClassName="org.postgresql.Driver"
    username="postgres"
    password="t00secure2gue$$"
/>

在此情況下,您可以變更它,如下列範例所示:

<Resource
    name="jdbc/dbconnection"
    type="javax.sql.DataSource"
    url="${postgresdb.connectionString}"
    driverClassName="org.postgresql.Driver"
    username="${postgresdb.username}"
    password="${postgresdb.password}"
/>

若要確保已部署之 .war 檔案內 META-INF 資料夾中的任何 context.xml 檔案發生參數替代,請務必設定CATALINA_OPTS環境變數,如下列範例所示:

export CATALINA_OPTS="-Dorg.apache.tomcat.util.digester.PROPERTY_SOURCE=org.apache.tomcat.util.digester.EnvironmentPropertySource"

佈建 App Service 方案

從 App Service 定價的可用服務方案清單中,選取其規格符合或超過目前生產硬體的方案。

注意

如果您打算執行預備/Canary 部署或使用部署位置,App Service 方案必須包含該額外的容量。 我們建議針對 Java 應用程式使用 進階版 或更高的方案。 如需詳細資訊,請參閱在 Azure App 服務 中設定預備環境。

然後,建立 App Service 方案。 如需詳細資訊,請參閱 在 Azure 中管理 App Service 方案。

建立及部署 Web 應用程式(s)

針對部署至 Tomcat 伺服器的每個 WAR 檔案,您必須在 App Service 方案上建立 Web 應用程式(選擇 Tomcat 版本作為運行時間堆棧)。

注意

雖然可以將多個 WAR 檔案部署到單一 Web 應用程式,但這是極不想要的。 將多個 WAR 檔案部署到單一 Web 應用程式,可防止每個應用程式根據自己的使用量需求進行調整。 它也會增加後續部署管線的複雜性。 如果需要在單一 URL 上使用多個應用程式,請考慮使用路由解決方案,例如 Azure 應用程式閘道

Maven 應用程式

如果您的應用程式是從 Maven POM 檔案建置的, 請使用適用於 Maven 的 Webapp 外掛程式來建立 Web 應用程式並部署您的應用程式。

非 Maven 應用程式

如果您無法使用 Maven 外掛程式,則必須透過其他機制布建 Web 應用程式,例如:

建立 Web 應用程式之後,請使用其中一個 可用的部署機制 來部署您的應用程式。

移轉 JVM 執行時間選項

如果您的應用程式需要特定的運行時間選項, 請使用最適當的機制來指定它們

填入秘密

使用應用程式 設定 來儲存應用程式特有的任何秘密。 如果您想要在多個應用程式之間使用相同的秘密,或需要精細的存取原則和稽核功能,請改用 Azure 金鑰保存庫

設定自訂網域和 SSL

如果您的應用程式將在自定義網域上顯示,您必須將 Web 應用程式對應至它。 如需詳細資訊,請參閱教學課程:將現有的自定義 DNS 名稱對應至 Azure App 服務

然後,您必須將該網域的 SSL 憑證系結至 App Service Web 應用程式。 如需詳細資訊,請參閱在 Azure App 服務 中使用SSL系結保護自定義 DNS 名稱。

匯入後端憑證

所有與後端系統通訊的憑證,例如資料庫,都必須提供給 App Service 使用。 如需詳細資訊,請參閱 在App Service中新增SSL憑證。

移轉數據源、連結庫和 JNDI 資源

如需數據源設定步驟,請參閱為 Azure App 服務 設定 Linux Java 應用程式的數據源一節。

如需其他數據源指示,請參閱Tomcat檔中 JNDI 資料源操作說明的下列各節

遵循 與數據源 JAR 檔案相同的步驟,移轉任何其他伺服器層級的 Classpath 相依性。

移轉任何其他 共用伺服器層級 JDNI 資源

注意

如果您遵循每個 Webapp 一個 WAR 的建議架構,請考慮將伺服器層級的 Classpath 連結庫和 JNDI 資源移轉至您的應用程式。 這可大幅簡化元件控管和變更管理。

移轉其餘組態

完成上一節之後,您應該在 /home/tomcat/conf設定可自定義的伺服器組態。

複製任何其他設定來完成移轉(例如 領域JASPIC

移轉排程的工作

若要在 Azure 上執行排程的工作,請考慮使用 Azure Functions 的定時器觸發程式。 您不需要將作業程式代碼本身移轉至函式。 函式可以直接叫用應用程式中的URL來觸發作業。 如果這類作業執行必須動態叫用和/或集中追蹤,請考慮使用 Spring Batch

或者,您可以使用循環觸發程式建立邏輯應用程式來叫用 URL,而不需在應用程式外部撰寫任何程式代碼。 如需詳細資訊,請參閱 概觀 - 什麼是 Azure Logic Apps?使用 Azure Logic Apps 中的週期性觸發程式建立、排程和執行週期性工作和工作流程。

注意

若要防止惡意使用,您可能需要確保作業調用端點需要認證。 在此情況下,觸發程式函式必須提供認證。

重新啟動和抽煙測試

最後,您必須重新啟動 Web 應用程式,以套用所有設定變更。 重新啟動完成後,請確認您的應用程式正在正確執行。

移轉後

既然您的應用程式已移轉至 Azure App 服務 您應該確認它如預期般運作。 完成之後,我們有一些建議可讓您的應用程式更原生雲端。

建議