將 WebSphere 應用程式遷移至 Azure Red Hat OpenShift

  • 發行項

本指南說明當您想要將現有的 WebSphere 應用程式伺服器 （WAS） 工作負載移轉至在 Azure Red Hat OpenShift 上執行的 IBM WebSphere Liberty 或 Open Liberty 時，應該注意的事項。

移轉前

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

確定目標是移轉工作的適當目標

成功將 WAS 應用程式移轉至 Azure 的第一個步驟是選取最適當的移轉目標。

WAS 傳統在 Azure 虛擬機器 上運作良好。 虛擬機 （VM） 目標是最容易的選擇，因為它最類似於內部部署部署。 虛擬機器的系統管理與部署體驗類似於您內部部署的內容。

另一個選項是將WAS傳統工作負載轉換為應用程式容器，以遷移至容器。 您可以在 Azure Kubernetes Service （AKS） 和 Azure Red Hat OpenShift 上執行容器目標。 這種緩解的取捨是經濟成本。

一般而言，相較於容器，VM 型解決方案的每分鐘成本較高。 雖然容器型解決方案的執行成本較低，但您必須限制應用程式以符合容器協調流程平臺的需求。

如果最小化變更是移轉工作最重要的因素，請考慮以 VM 為基礎的移轉。 在此情況下，請參閱將 WebSphere 應用程式遷移至 Azure 虛擬機器。

如果您可以容許將應用程式轉換為在容器內執行，以降低運行時間成本，請考慮以 AKS 為基礎的或 Azure Red Hat OpenShift 型移轉。

針對 AKS 型移轉，您可以開始使用免費層。 取得免費叢集管理，並只支付取用的虛擬機、相關聯的記憶體和網路資源的費用。 在此情況下，請參閱 將 WebSphere 應用程式遷移至 Azure Kubernetes Service。

針對以 Azure Red Hat OpenShift 為基礎的移轉，除了計算和基礎結構成本之外，應用程式節點還有另一個 OpenShift 授權元件的成本。 此成本是根據應用程式節點數目和實例類型計費。 使用隨選定價或保留實例，無論哪一個最符合您的工作負載和商務需求。 在此情況下，請參閱 將 WebSphere 應用程式遷移至 Azure Red Hat OpenShift。

Azure Red Hat OpenShift 檔中的作法指南涵蓋與移轉相關的一些層面。 如需操作說明指南的完整清單，請參閱 Azure Red Hat OpenShift 檔。

判斷預先建置的 Azure Marketplace 供應專案是否為良好的起點

決定 Azure Red Hat OpenShift 是適當的部署目標之後，您必須接受 IBM WebSphere Liberty 操作員或 Open Liberty 操作員（操作員）是在 Kubernetes 上執行 Liberty 的唯一方法。 接受此事實之後，您必須決定預先建置 的 Azure Marketplace 供應 專案是否為良好的起點。 以下是關於預先建置 Azure Marketplace 供應專案的一些考慮事項：

  • IBM 和 Microsoft 建立了此供應專案，可讓您在 Azure Red Hat OpenShift 上快速布建 Liberty。 在下列內容中會更詳細地說明這個概念。
  • 概括而言，供應專案會為您自動化下列步驟。
    • 如有需要，請取得現有的應用程式映像。
    • 如有需要，請布建 Azure Red Hat OpenShift 叢集。
    • 在 Azure Red Hat OpenShift 上安裝並設定 IBM WebSphere Liberty 操作員或 Open Liberty 操作員。
    • 使用運算符來執行整個專案。 操作員會在 Azure Red Hat OpenShift 中部署和管理容器化 Liberty 應用程式。 您可以在 IBM WebSphere Liberty 操作員和 Open Liberty 操作員中找到參考檔。

如果您未使用預先建置的 Azure Marketplace 供應專案，您必須瞭解如何直接使用 操作員。 掌握運算元超出本文的範圍。 操作員的完整文件位於 IBM WebSphere Liberty 操作員和 Open Liberty 操作員。

既然您已瞭解在 Azure Red Hat OpenShift 上處理 Liberty 的各種方式，您最好選擇要使用預先建置的 Azure Marketplace 供應專案，或直接使用操作員自行執行。

判斷 Liberty 版本是否相容

您需要 Open Liberty 操作員或 WebSphere Liberty 操作員，才能在 Kubernetes 型叢集上部署和管理應用程式。 請確定您現有的 Liberty 版本是操作員支援的其中一個版本。 Open Liberty 的版本會保留在 GitHub OpenLiberty/open-liberty 中。 IBM 維護 IBM WebSphere 應用程式伺服器 Liberty 的版本。 如需詳細資訊，請參閱 WebSphere 應用程式伺服器自由。

預先建置的 Azure Marketplace 供應專案可讓您從公用登錄中選取應用程式映射，因此隱含支援所有版本。

判斷是否需要授權

針對IBM WebSphere Liberty，您必須接受與應用程式容器中 IBM 計劃版本對應的許可協議條款。 如需適用於此 IBM 計劃的許可協定，請參閱 檢視 WebSphere Liberty 操作員的授權資訊。 如需詳細資訊，請參閱 在 Microsoft Azure 上執行 WebSphere Liberty。

如果您的產品版本不是預設IBM WebSphere 應用程式伺服器 （base），則必須 .spec.license.edition value 指定您的產品版本。 其他可用的值為 IBM WebSphere Application Server Liberty Core 和 IBM WebSphere Application Server Network Deployment。 預先建置的 Azure Marketplace 供應專案可讓您選取支援的產品版本。

使用IBM移轉工具的清查差異

若要將應用程式移至 WebSphere Application Server Liberty 或 Open Liberty，您需要規劃移轉、分析應用程式，以及更新原始程式碼。 IBM 提供移轉工具，協助您識別您目前環境與新自由環境中技術之間的任何差異，例如 Java EE 7 或 Java EE 8，以及 Java SE 8 或 Java SE 11。 如需詳細資訊，請參閱 將應用程式移轉至 Liberty。

清查伺服器容量

記錄目前生產伺服器的硬體（記憶體、CPU、磁碟），以及平均和尖峰要求計數和資源使用率。 不論您選擇的移轉路徑為何，您都需要此資訊。 例如，此資訊有助於引導您節點中 VM 大小的選取、容器要使用的記憶體數量，以及容器需要多少 CPU 共用。

若要節省大量成本來利用未使用的容量，可以在 Azure Red Hat OpenShift 中使用 Azure Spot 虛擬機器。 若要瞭解如何，請參閱在 Azure Red Hat OpenShift 叢集中使用 Azure Spot 虛擬機器。

清查所有秘密

在 Azure 金鑰保存庫 等「設定即服務」技術出現之前，沒有定義完善的「秘密」概念。 相反地，您有一組不同的組態設定，實際上可作為我們現在所謂的「秘密」功能。 使用 WAS 之類的應用程式伺服器時，這些秘密位於許多不同的組態檔和組態存放區中。 檢查生產伺服器上的所有屬性和組態檔是否有任何秘密和密碼。 您也可以在應用程式內找到包含密碼或認證的組態檔。 WAS 會將組態數據儲存在目錄的級聯階層中的數份檔中。 大部分的組態檔都有 XML 內容。 如需詳細資訊，請參閱設定檔和Azure 金鑰保存庫 基本概念。

在您有穩固的秘密清查之後，請參閱有關秘密的操作員檔。 如需詳細資訊，請參閱下列文章：

清查所有憑證

記錄用於公用 SSL 端點的所有憑證。 您可以執行下列命令來檢視生產伺服器上的所有憑證：

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

在您有穩固的憑證清查之後，請使用下列文章加以設定：

驗證支援的 Java 版本是否正常運作

使用 Liberty 需要特定版本的 Java，因此您必須確認應用程式使用該支援的版本正確執行。

WebSphere 應用程式伺服器自由運行時間對於 Java 執行時間環境 （JRE） 的最低層級有特定需求。 如需詳細資訊，請參閱 功能的 Java 版本相依性。

Open Liberty 需要 Java SE 運行時間。 它可以使用 Java Runtime Environment （JRE） 或 Java SE 開發工具包 （JDK） 散發套件來執行。 如需詳細資訊，請參閱 支援的 Java SE 版本。

清查 JNDI 資源

清查所有 JNDI 資源。 例如，資料庫之類的數據源可能會有相關聯的 JNDI 名稱，可讓 JPA 正確地將 的 EntityManager 實例系結至特定資料庫。 如需 JNDI 資源和資料庫的詳細資訊，請參閱 IBM 檔中的 WebSphere 數據源 。 其他 JNDI 相關資源，例如 JMS 訊息代理程式，可能需要移轉或重新設定。 如需 JMS 設定的詳細資訊，請參閱 使用 JMS 資源。

如果您使用預先建置的 Azure Marketplace 供應專案，您可以在部署期間自定義的一組 JNDI 資源僅限於供應專案所支援的內容。 針對 AKS 上的 WebSphere Liberty，您可以在預設的 Java 命名和目錄介面 （JNDI） 命名空間中提供物件。 如需詳細資訊，請參閱 在 Liberty 功能中使用 JNDI 預設命名空間進行開發。 如需 Open Liberty，請參閱 Java 命名和目錄介面。

檢查您的配置檔組態

WAS 中的主要組態單位是配置檔。 因此， resources.xml 檔案包含大量組態，您必須仔細考慮進行移轉。 檔案包含儲存在子目錄中之其他 XML 檔案的參考。 如需詳細資訊，請參閱 管理分散式和IBM i操作系統上的配置檔。

在您的應用程式內

檢查 deployment.xml 檔案和/或 WEB-INF/web.xml 檔案。

您必須在 Azure Red Hat OpenShift 執行的容器映射中擷取這些自定義。 當您使用預先建置的 Azure Marketplace 供應專案時，建立自定義容器映像並將其提供給公用登錄，然後在部署時指向該登錄，以最佳方式處理這類自定義。

如果您使用 WebSphere 應用程式伺服器網路部署數據格，則每個叢集成員都會在傳統 WAS 的安裝中執行。 Liberty 是 WebSphere 應用程式伺服器的輕量型配置檔。 這是 WAS 的彈性動態配置檔，可讓 WAS 伺服器只部署必要的自定義功能，而不是部署一組大型可用的 JEE 元件。

判斷是否使用會話複寫

如果您的應用程式依賴會話複寫，您有下列選項：

  • 針對 HTTP 工作階段，根據工作階段管理層級，您可以使用快取或資料庫來收集工作階段數據。
  • 針對 分散式會話，您可以使用資料庫會話持續性，將會話儲存在資料庫中。
  • 針對 動態快取，您可以管理快取或資料庫中的會話數據。
  • 您可以重構應用程式以使用資料庫進行工作階段管理。
  • 您可以重構應用程式，將會話外部化至 Azure Redis 服務。 如需詳細資訊，請參閱 Azure Cache for Redis。

對於所有這些選項，最好掌握 Liberty 如何執行 HTTP 工作階段狀態複寫。 下列文件可協助您瞭解如何在 Liberty 中管理 HTTP 工作階段：

檔數據源

如果您的應用程式使用任何資料庫，您需要擷取下列資訊：

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

如需 WAS 中 JDBC 驅動程式的詳細資訊，請參閱 搭配 WebSphere 應用程式伺服器使用 JDBC 驅動程式。

JDBC 組態是 Liberty 中的核心伺服器組態。 如需詳細資訊，請參閱 JDBC Driver。

預先建置的 Azure Marketplace 供應專案對資料庫的支援有限。 您可以在應用程式映像中處理組態，並在部署供應專案時使用映像。

判斷 WAS 是否已自定義

判斷已進行下列哪一項自定義，並擷取已完成的工作。

  • 啟動文稿是否已變更？ 這類腳本包括 wsadmin、管理員 Control、管理員 Config、管理員 App 和 管理員 Task。
  • 是否有任何特定參數傳遞至 JVM？
  • 是否有 JAR 新增至伺服器類別路徑？
  • 這類 systemd 操作系統層級的設施是否已用來在伺服器重新啟動後自動啟動WAS元件？

您必須考慮移轉考慮，視這些問題的解答而定。

您必須在 Azure Red Hat OpenShift 執行的容器映射中擷取這些自定義。 當您使用預先建置的 Azure Marketplace 供應專案時，建立自定義容器映像並將其提供給公用登錄，然後在部署時指向該登錄，以最佳方式處理這類自定義。

判斷是否需要連線至內部部署

如果您的應用程式需要存取任何內部部署服務，您必須布建其中一個 Azure 的連線服務。 如需詳細資訊，請參閱 選擇將內部部署網路連線至 Azure 的解決方案。 或者，您必須重構應用程式，才能使用內部部署資源公開的公開可用 API。

判斷 Java 訊息服務 （JMS） 佇列或主題是否正在使用中

如果您的應用程式使用 JMS 佇列或主題，您必須將它們移轉至外部裝載的 JMS 伺服器。 使用 JMS 的其中一個策略是使用 Azure 服務匯流排 和進階消息佇列通訊協定。 如需詳細資訊，請參閱搭配 Azure 服務匯流排 和AMQP 1.0使用 JMS。

如果您已設定 JMS 永續性存放區，則必須擷取其設定，並在移轉之後套用。

如果您使用 IBM MQ，您可以將此軟體移轉至 Azure 虛擬機器，並依目前使用。

Microsoft 有整合 IBM MQ 與 Logic Apps 的解決方案。 如需詳細資訊，請參閱從 Azure Logic Apps 中的工作流程 連線 IBM MQ 伺服器。

判斷您是否使用自己的自定義建立共用Java EE 連結庫

如果您使用共用 Java EE 連結函式庫功能，您有兩個選項：

  • 重構應用程式程式代碼以移除連結庫上的所有相依性，並改為將功能直接併入您的應用程式。
  • 將連結庫新增至伺服器類別路徑。

您可以使用從 Java EE 應用程式存取第三方 API 中所述的相同技術來處理這些連結庫。

判斷是否使用OSGi套件組合

如果您使用新增至 WAS 的 OSGi 套件組合，則必須將相等的 JAR 檔案直接新增至 Web 應用程式。

您可以將套件組合包含在提供給預先建置 Azure Marketplace 供應專案的映射中。 如需詳細資訊，請參閱 設定OSGi應用程式的連結庫。

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

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

Azure Red Hat OpenShift 上的 Liberty 會在 Linux x86_64上執行。 任何 OS 特定程式代碼都必須與 Linux 相容。 若要瞭解如何探索特定的OS資訊，請遵循判斷自由版本是否相容一節中的步驟。

判斷IBM Integration Bus 是否正在使用中

如果您的應用程式使用 IBM 整合總線，您必須擷取 IBM Integration Bus 的設定方式。 如需詳細資訊，請參閱 IBM 整合總線檔。

預先建置的 Azure Marketplace 供應專案不支援 IBM 整合總線。 若要啟用此功能，請遵循在 Liberty 上啟用 JMS 應用程式以 連線到 IBM 檔中的服務整合匯流中的 指示。

判斷您的應用程式是否由多個 WAR 組成

如果您的應用程式是由多個 WAR 所組成，您應該將每個 WAR 視為個別的應用程式，並針對每個 WAR 進行本指南。

判斷您的應用程式是否封裝為 EAR

如果您的應用程式封裝為 EAR 檔案，請務必檢查 application.xml、ibm-application-bnd.xmi 和 ibm-application-ext.xmi 檔案，並擷取其組態。 如需詳細資訊，請參閱 在 WebSphere 上建置企業封存 （EAR） 套件。

預先建置的 Azure Marketplace 供應專案可讓您使用現有的容器映像。 您可以根據您的商務需求準備應用程式。

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

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

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

Kubernetes 會處理具有永續性磁碟區的文件系統（PV）。 預先建置的 Azure Marketplace 供應專案不支援掛接永續性磁碟區。 若要建立 Azure 檔案儲存體 儲存體 Class，請遵循在 Azure Red Hat OpenShift 4 上建立 Azure 檔案儲存體 儲存體 Class 中的指示。

唯讀靜態內容

如果您的應用程式目前提供靜態內容，您將需要其替代位置。 您可能想要考慮將靜態內容移至 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 Marketplace 供應專案是移轉的起點。 如果供應專案未涵蓋您需要移轉的架構層面，則需要擷取現有部署的網路拓撲。 然後，您必須在 Azure 中重現該拓撲，即使使用其中一個解決方案範本來建立基本供應專案也一樣。

網路拓撲是一個廣泛的主題，但下列參考可以為您的移轉工作提供一些方向：

用於 JCA 配接器和資源配接器的帳戶

如果您現有的應用程式使用 JCA 配接器或資源配接器連線到其他企業系統，請確定您將這些成品的設定套用至 AKS 上執行的 Liberty 伺服器。 如需詳細資訊，請參閱 JCA 組態專案和 Java 連線 or 架構概觀。

判斷是否使用叢集

操作員會處理在 Azure Red Hat OpenShift 上執行 WAS 工作負載的所有可能方式的叢集。

檢查EJB叢集

如果您的應用程式使用本機企業 Java Beans （EJB），您可能需要將其移轉至叢集 EJB。 如需詳細資訊，請參閱 在 Liberty 上開發 EJB 應用程式。

考慮負載平衡需求

預先建置的 Azure Marketplace 供應專案會使用 OpenShift 內建路由，以公用 URL 和帳戶裝載應用程式以進行負載平衡。 如需詳細資訊，請參閱 OpenShift Route 設定。

遷移

本節中的步驟假設您的分析已引導您決定使用預先建置的 Azure Marketplace 供應專案。

布建供應專案

若要在 Azure 入口網站 中開啟供應專案，請參閱 AZURE Red Hat OpenShift 上的 IBM WebSphere Liberty 和 Open Liberty。 選取 [建立]，然後使用您在上述步驟中收集的信息，協助填寫供應專案字段。

KeyStores 的帳戶

您必須考慮移轉應用程式所使用的任何 SSL/TLS KeyStore。 如需詳細資訊，請參閱 設定金鑰存放區。

連線 JMS 來源

連接資料庫之後，您可以遵循 IBM 檔中 JCA 組態元素概觀中的指示來設定 JMS。

用於記錄的帳戶

您無法在沒有掌握記錄的情況下執行雲端作業。 運算元提供監視的不同方法。 如需詳細資訊，請參閱 監視 Liberty 伺服器運行時間環境。 這有助於在 Red Hat OpenShift 中主要記錄和監視系統。 如需詳細資訊，請參閱瞭解 Red Hat OpenShift 和關於 OpenShift 容器平臺監視的記錄子系統。 您可以設定 Azure Red Hat OpenShift 的 Azure 監視器容器深入解析。 如需詳細資訊，請參閱 設定 Azure Red Hat OpenShift 的 Azure 監視器容器深入解析。 如果您偏好使用彈性堆疊，Azure 會為 Elastic 提供絕佳的支援。 如需完整詳細數據，請參閱 什麼是彈性與 Azure 整合？ 您可以結合這些資源中的知識，以達到 Azure Red Hat OpenShift 上 Liberty 的 Azure 優化記錄解決方案。

移轉您的應用程式

無論您是否選擇在部署時間提供應用程式映像，都需要透過 CI/CD 更新應用程式。 OpenShift 檔包含示範如何執行此更新的範例。 如需詳細資訊，請參閱 OpenShift 容器平臺 CI/CD 概觀。

設定測試

您必須針對應用程式設定任何容器內測試，才能存取在 Azure 內執行的新伺服器。 如同 CI/CD 考慮，您必須確定必要的網路安全性規則可讓您的測試存取部署至 Azure 的應用程式。 如需詳細資訊，請參閱 網路安全組。

移轉後

在您達到您在移轉前步驟中 定義的移 轉目標之後，請執行一些端對端驗收測試，以確認一切如預期般運作。 下列文章提供移轉后增強功能的相關信息：