Choose an OCI-compliant strategy

This page provides an overview of the Cloud Foundry build process you need to migrate from, and provides a description of the various ways you can migrate from that to a process that builds OCI-compliant containers.

Cloud Foundry build process overview

When an application is pushed to Cloud Foundry, it goes through a build stage where the source code is compiled by the Cloud Foundry v2 buildpacks.

The output of a Cloud Foundry build process creates a runnable archive known as a droplet. Droplets are not directly compatible with the Open Container Initiative (OCI) specification for running containers on Cloud Run.

When migrating applications from Cloud Foundry to Cloud Run you must change the application build process to generate industry standard OCI images (sometimes referred to as Docker images).

Diagram describing how Cloud Foundry Droplets are created

Strategies to achieve OCI-compliant images

There are three migration strategies you can choose from to build OCI-compliant containers:

Modifying a Cloud Foundry application (lift and shift)

The core components of the Cloud Foundry ecosystem (v2 Buildpacks, Stemcells, etc.) are open source. This means you can re-create the application containerization process by following our guide to "Dockerize" the core build components to create a new OCI-compliant image.

Pros:

  • It requires the least amount of application refactoring and customization.
  • The process is repeatable for all application instances.

Cons:

  • The pipeline for building application containers is self-managed.
  • Older Cloud Foundry components have diminished maintenance and support.
  • There are ongoing security maintenance costs, including:
    • Routinely re-building the build components to ensure you get security patches.
    • Routinely re-building the "dockerized" applications to take on the security updates from the rebuilt build components.

Using Cloud Native Buildpacks

The Cloud Native Buildpacks (CNB) specification was created to modernize and unify the buildpacks ecosystem. Builders compatible with the CNB specification follow open standards and create OCI-compliant images. Three common CNB providers are:

Pros:

  • Buildpack maintainers and platform providers are responsible for maintenance of the buildpack.
  • Buildpacks support rebasing containers on new images for fast security updates without rebuilding application containers.
  • Buildpacks generate portable OCI images.
  • The CNB project is incubating under the Cloud Native Computing Foundation (CNCF) and has an active community of maintainers and contributors.

Cons:

  • Functionality and configuration gaps between v2 and v3 buildpacks.
  • Frameworks and integrations installed on your behalf in the Java v2 buildpacks may not be available in the Java CNB buildpack.

Using self-managed Dockerfiles

You can author completely new Dockerfiles to containerize your application. Refer to building containers to learn about container images accepted by Cloud Run.

Pros:

  • Gives you the most flexibility in designing your applications.
  • Leverage your company's existing container tooling & build strategies.

Cons:

  • Dockerization and custom configuration must be performed for each application, leading to potentially time consuming debugging and rewrites.
  • Difficult to standardize implementations across multiple teams.
  • Patching images requires a full rebuild and redeploy.

Recommendations

Teams that are resource-constrained and looking to move as many applications as possible should first consider the Lift and Shift strategy to modify Cloud Foundry. Once the applications are modernized to towards being OCI-compliant images, we recommend that you consider using Cloud Native Buildpacks or self-managed Dockerfiles.

Teams that are ready to migrate immediately should try Cloud Native Buildpacks and then move to self managed Dockerfiles if they need a high level of control over their environment.

What's Next