選擇符合 OCI 的策略

本頁面將概略說明您需要從中遷移的 Cloud Foundry 建構程序，並說明如何從該程序遷移至建構符合 OCI 標準的容器程序。

Cloud Foundry 建構程序總覽

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

Cloud Foundry 建構程序的輸出內容會建立可執行的封存檔，稱為「droplet」。Droplet 與 Open Container Initiative (OCI) 規格不相容，無法在 Cloud Run 上執行容器。

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

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

符合 OCI 規範的圖片策略

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

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

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

優點：

  • 這項方法需要的應用程式重構和自訂作業量最少。
  • 此程序可重複套用至所有應用程式執行個體。

缺點：

  • 應用程式容器建構管道為自管。
  • 較舊的 Cloud Foundry 元件維護和支援服務已減少。
  • 持續性的安全性維護費用包括：
    • 定期重新建構建構元件，確保您能取得安全性修補程式。
    • 定期重新建構「dockerized」應用程式，以便採用重新建構的建構元件中的安全性更新。

使用 Cloud Native Buildpacks

雲端原生 Buildpack (CNB) 規格旨在將 Buildpack 生態系統現代化並統一。與 CNB 規格相容的建構工具會遵循開放標準，並建立符合 OCI 的映像檔。以下是三種常見的 CNB 供應商：

優點：

  • 建構包維護者和平台供應商負責維護建構包。
  • Buildpack 可支援在新映像檔上重新命名容器，以便快速更新安全性，而無需重新建構應用程式容器。
  • Buildpacks 會產生可攜式 OCI 映像檔。
  • CNB 專案在 Cloud Native Computing Foundation (CNCF) 的孵化計畫下進行，並擁有活躍的維護者和貢獻者社群。

缺點：

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

使用自行管理的 Dockerfile

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

優點：

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

缺點：

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

建議

資源有限且希望盡可能遷移更多應用程式的團隊，應先考慮採用升遷與轉移策略來修改 Cloud Foundry。應用程式完成現代化後，如果符合 OCI 規範的映像檔，建議您考慮使用雲端原生 Buildpack 或自行管理的 Dockerfile。

如果團隊已準備好立即遷移，建議先試用 Cloud Native Buildpacks，然後再轉移至自行管理的 Dockerfile，以便對環境進行高度控管。

後續步驟