本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
技術領域
本節概述容器化的主要技術領域。下圖顯示了傳統 Java EE 應用程式的架構。
下圖顯示了已容器化的 Java EE 應用程式的架構。
1. 工作階段狀態
在大多數情況下，Java EE 應用程式會存儲與使用者請求相關聯的工作階段資料，例如適用於 servlet 的 Cookie 和 Enterprise Java Beans (EJB) 狀態工作階段。建議您避免在 Java 虛擬機器 (JVM) 記憶體中儲存狀態資訊，因為容器必須保持無狀態。如需有關可處置性原則的詳細資訊，請參閱 Red Hat 文件中的基於容器的應用程式設計原則
記憶體複寫機制假設叢集中永遠存在一組特定的伺服器，或少數伺服器加入或離開叢集。這與容器環境不相容，因此建議您擺脫記憶體複寫機制。在容器環境中，應用程式伺服器會在建置新版本的容器映像時重新部署。也就是說，所有已複寫的記憶體資料也會被清除。
2. 代理程式
在單一實體或虛擬伺服器上執行多個代理程序，其通常會執行自動化和公用程式任務，例如：
-
監控 – 傳統的 Java EE 應用程式環境通常使用專用代理程式進行監控。這些代理程式負責監控伺服器 CPU、記憶體、磁碟使用率、JVM 內的記憶體使用情況、日誌訊息等。不過，無法在容器環境中直接執行監控代理程式。必須將監控代理程式取代為容器平台提供的監控機制，例如 Amazon CloudWatch 和 Amazon CloudWatch Logs。
-
工作 (排定的作業) – 在傳統的 Java EE 應用程式環境中，工作執行環境通常位於與應用程式伺服器相同的伺服器上，並負責除了使用者請求之外的長時間執行批次處理程序。例如，作業控制器控制的批次處理程序會存取資料庫以擷取資料並建立報告。由於多個工作負載無法在容器環境中共存，因此必須與容器環境分開來建置作業和批次處理執行環境。
-
檔案傳輸 – 檔案傳輸代理程式在 Java EE 應用程式環境中通常不常見，但其有時會作為獨立程序與 Java 應用程式在相同的作業系統上執行，以便與外部應用程式交換檔案。例如，其他應用程式使用的資料會每天傳輸到檔案，並反映在資料庫中。檔案傳輸代理程式無法在容器旁邊執行，但必須在另一部能夠存取資料庫和檔案的伺服器上執行。
3. 應用程式伺服器
容器化最重要的挑戰是變更應用程式伺服器。傳統的 Java EE 相容應用程式伺服器會採用靜態運算環境，因此其可能不適合在容器環境中執行。也就是說，實體或虛擬伺服器會被假設為 Java EE 應用程式運算環境的實體。例如，專屬的 Java EE 應用程式伺服器 (比如傳統的 IBM WebSphere Application Server (tWAS) 和 Oracle WebLogic Server) 都有自己的應用程式部署機制。
容器環境中的情況不同。在此環境中，容器包括應用程式伺服器和具有應用程式建置套件的執行期 (例如 .war 和 .jar 檔案)，並部署到容器平台，例如 Amazon ECS 或 Amazon EKS。建議您使用容器平台機制，將應用程式部署至環境。應用程式伺服器經常與容器一起部署，因此其大小必須較小 (小於 500 MB) 並且啟動速度快。若要符合此要求，可能需要變更傳統的應用程式伺服器，並遷移至更加容器友好的應用程式伺服器。這可能需要從 IBM WebSphere Application Server 遷移到 IBM WebSphere Liberty，或從 JBoss Enterprise Application Platform (EAP) 遷移到 WildFly。
建議您考量下列因變更應用程式伺服器而造成的影響：
-
透過環境變數注入組態 (與將組態存儲在檔案 (web.xml) 中的傳統 Java EE 應用程式不同)
-
與 Java EE 功能的相容性
-
JVM 版本
4. 檔案儲存
最常用於傳統 Java EE 應用程式的檔案儲存是本地檔案系統。最常見的使用案例包括應用程式日誌檔案、應用程式產生的檔案 (例如商業報告)，以及使用者上傳的內容。建議您避免將檔案儲存在容器內，因為容器是無狀態的，這表示檔案儲存必須外部化以進行容器化。
考量下列容器化選項：
-
Amazon Elastic File System (Amazon EFS) – Amazon EFS 是可從容器存取的受管 NFS 服務。Amazon EFS 與 Amazon ECS 和 Amazon EKS 整合。如果使用 Amazon EFS，則不需要撰寫自訂指令碼將 EFS 磁碟區掛接到容器。此選項的第一個步驟是列出應用程式中用於讀取或寫入的所有檔案系統路徑。識別要保留的檔案系統路徑之後，可以將檔案系統路徑映射至 EFS 檔案系統路徑。如需詳細資訊，請參閱 Amazon ECS 文件中的教學課程：搭配使用 Amazon EFS 檔案系統與 Amazon ECS。並非所有路徑都需要保留，尤其是應用程式日誌檔案。大多數企業應用程式會將日誌檔案寫入本機檔案系統。作為容器化程序的一部分，建議您考慮變更記錄目的地以使用「標準輸出」和「標準錯誤」。這可讓您擷取 CloudWatch Logs 的所有輸出，而無需管理日誌儲存大小和效能。如需 Amazon ECS 中日誌的詳細資訊，請參閱 Amazon ECS 文件中的使用 awslogs 日誌驅動程式。
-
Amazon Simple Storage Service (Amazon S3) – Amazon S3 比 Amazon EFS 便宜，而且支援的頻寬比 Amazon EFS 更寬，但 Amazon S3 需要比 Amazon EFS 更廣泛的應用程式代碼變更。這是因為 Amazon S3 不是檔案系統。
5. 建置和部署程序
容器化程序涉及變更和擴充應用程式交付程序。在傳統環境中，應用程式交付程序主要涉及 Java 構件 (例如 .war 和 .ear 檔案)。在容器環境中，容器映像是傳送單位。除了用於建置現有 Java 構件的程序之外，還必須建立用於建置和交付 Docker 容器的程序。如需管道程序的詳細資訊，請參閱 AWS 《 規範指引》文件中的使用 CI/CD 管道自動建置 Java 應用程式並將其部署至 Amazon EKS。
6. 資料庫存取
傳統應用程式容器化通常伴隨著資料庫遷移。為了降低遷移風險，建議您遵循關聯式資料庫的遷移策略 (AWS 方案指引）。容器化環境需要外部化組態，包括資料庫連線字串。您可以使用諸如 Spring Cloud Config
