本页面简要介绍需要迁移的 Cloud Foundry 构建流程，以及从该流程迁移到构建符合 OCI 规范的容器的流程的各种方法。
Cloud Foundry 构建流程概览
应用推送到 Cloud Foundry 后会经历一个构建阶段，在此阶段中，源代码由 Cloud Foundry v2 Buildpack 编译。
Cloud Foundry 构建流程的输出会创建一个可运行的归档，称为 Droplet。Droplet 与在 Cloud Run 上运行容器的 Open Container Initiative (OCI) 规范不直接兼容。
将应用从 Cloud Foundry 迁移到 Cloud Run 时，您必须更改应用构建流程以生成行业标准 OCI 映像（有时称为 Docker 映像）。
获得 OCI 合规映像的策略
如需构建符合 OCI 规范的容器，有三种迁移策略可供选择：
- 修改现有 Cloud Foundry 应用（有时称为“直接原样迁移”）。
- 使用云原生 Buildpack
- 使用自行管理的 Dockerfile
修改 Cloud Foundry 应用（直接原样迁移）
Cloud Foundry 生态系统的核心组件（v2 Buildpack、Stemcells 等）是开源的。这意味着，您可以按照我们的指南将核心构建组件“通过 Docker 进行虚拟化”来创建新的 OCI 合规映像，从而重新创建应用容器化流程。
优点：
- 它需要的应用重构和自定义最少。
- 流程对所有应用实例都是可重复的。
缺点：
- 构建应用容器的流水线是自行管理的。
- 旧版 Cloud Foundry 组件的维护和支持减少。
- 有持续的安全维护费用，包括：
- 定期重新构建构建组件，以确保您获得安全补丁程序。
- 定期重新构建“已通过 Docker 进行虚拟化”的应用，以接受重新构建的构建组件中的安全更新。
使用 Cloud Native Buildpack
Cloud Native Buildpacks (CNB) 规范的目的是现代化改造和统一 Buildpack 生态系统。与 CNB 规范兼容的构建器遵循开放标准并创建符合 OCI 规范的映像。三个常见的 CNB 提供方是：
优点：
- Buildpack 维护者和平台提供方负责维护 Buildpack。
- Buildpack 支持在新的映像上将容器变基 (rebase)，以快速获取安全更新，而无需重新构建应用容器。
- Buildpack 会生成可移植的 OCI 映像。
- CNB 项目在 Cloud Native Computing Foundation (CNCF) 下孵化，它拥有一个活跃的维护者和贡献者社区。
缺点：
- v2 和 v3 Buildpack 之间存在功能与配置差异。
- 代表您在 Java v2 Buildpack 中安装的框架和集成在 Java CNB Buildpack 中可能不可用。
使用自行管理的 Dockerfile
您可以编写全新的 Dockerfile 来对应用进行容器化。请参阅构建容器以了解 Cloud Run 接受的容器映像。
优点：
- 提供最大的应用设计灵活性。
- 利用公司现有的容器工具和构建策略。
缺点：
- 必须为每个应用执行通过 Docker 虚拟化和自定义配置，从而导致可能非常耗时的调试和重写。
- 难以跨多个团队对实现进行标准化。
- 修补映像需要完全重新构建并重新部署。
建议
资源受限且希望迁移尽可能多的应用的团队应首先考虑使用直接原样迁移策略来修改 Cloud Foundry。将应用改造为符合 OCI 规范的映像后，我们建议您考虑使用 Cloud Native Buildpack 或自行管理的 Dockerfile。
已准备好立即迁移的团队应尝试 Cloud Native Buildpack，并在需要高度控制环境时迁移到自行管理的 Dockerfile。
后续步骤
- 完成使用直接原样迁移策略的 Spring Music 示例迁移。
- 迁移到 OCI 容器