選擇符合 OCI 的策略

本頁面提供您需要遷移的 Cloud Foundry 建構程序總覽，並說明從該程序遷移至建構 OCI 相容容器程序的各種方式。

Cloud Foundry 建構程序總覽

應用程式推送至 Cloud Foundry 時，會經過建構階段，由 Cloud Foundry v2 Buildpacks 編譯原始碼。

Cloud Foundry 建構程序會產生可執行的封存檔，也就是「滴答」。如要在 Cloud Run 上執行容器，必須使用 Open Container Initiative (OCI) 規格，但 Droplet 無法直接與該規格相容。

將應用程式從 Cloud Foundry 遷移至 Cloud Run 時，您必須變更應用程式建構程序，以產生業界標準的 OCI 映像檔 (有時稱為 Docker 映像檔)。

說明如何建立 Cloud Foundry Droplet 的圖表

如何製作符合 OCI 規範的圖片

您可以選擇下列三種遷移策略，建構符合 OCI 規範的容器：

修改 Cloud Foundry 應用程式 (隨即轉移)

Cloud Foundry 生態系統的核心元件 (v2 Buildpack、Stemcell 等) 都是開放原始碼。也就是說，您可以按照我們的「Dockerize」核心建構元件指南，重新建立應用程式容器化程序，以建立符合 OCI 標準的新映像檔。

優點：

  • 需要的應用程式重構和自訂作業最少。
  • 所有應用程式執行個體都可以重複這個程序。

缺點：

  • 建構應用程式容器的管道為自行管理。
  • 舊版 Cloud Foundry 元件的維護和支援服務已減少。
  • 持續進行安全維護需要費用，包括：
    • 定期重新建構建構元件，確保您取得安全性修補程式。
    • 定期重新建構「Docker 化」應用程式，從重新建構的建構元件中取得安全性更新。

使用 Cloud Native Buildpacks

Cloud Native Buildpacks (CNB) 規格的建立，是為了讓建構包生態系統現代化並統一。與 CNB 規格相容的建構工具遵循開放標準，並建立符合 OCI 規範的映像檔。常見的 CNB 供應商有三家：

優點：

  • 建構包維護人員和平台供應商負責維護建構包。
  • 建構包支援以新映像檔為容器重新設定基準，以便快速進行安全性更新，不必重新建構應用程式容器。
  • 建構包會產生可攜式 OCI 映像檔。
  • CNB 專案正在 Cloud Native Computing Foundation (CNCF) 旗下孵化，並擁有活躍的維護人員和貢獻者社群。

缺點：

  • v2 和 v3 buildpack 之間的功能和設定差異。
  • 在 Java v2 建構套件中為您安裝的架構和整合功能，可能無法在 Java CNB 建構套件中使用。

使用自行管理的 Dockerfile

您可以編寫全新的 Dockerfile，將應用程式容器化。請參閱建構容器，瞭解 Cloud Run 接受的容器映像檔。

優點：

  • 在設計應用程式時享有最大的彈性。
  • 運用貴公司現有的容器工具和建構策略。

缺點：

  • 您必須為每個應用程式執行 Docker 化和自訂設定，這可能會導致耗時的偵錯和重寫作業。
  • 難以在多個團隊之間標準化實作項目。
  • 修補映像檔需要完整重建並重新部署。

建議

如果團隊資源有限，且希望盡可能遷移多個應用程式，應優先考慮採用「隨即轉移」策略來修改 Cloud Foundry。應用程式完成現代化，可產生符合 OCI 規範的映像檔後，建議您考慮使用 Cloud Native Buildpacks 或自行管理的 Dockerfile。

如果團隊已準備好立即遷移，建議先試用 Cloud Native Buildpacks，然後視環境控管需求，改用自行管理的 Dockerfile。

後續步驟