IBM Cloud Foundry Migration Runtime provides a KubeCF-based platform on Red Hat OpenShift as a pragmatic Kubernetes approach to workload migration.
As cloud technologies advanced, many organizations adopted Cloud Foundry, made significant investments in the platform, and rewrote applications to take advantage of it. Over time, containers and Kubernetes have created significant disruption in application development strategies, with organizations now facing new considerations as they modernize their existing and future investments to leverage the strategic value that Kubernetes offers.
IBM Cloud Foundry Migration Runtime, coupled with a Red Hat OpenShift platform, delivers a new intuitive toolset that can accelerate movement towards running one platform while protecting migration timelines and goals from technical and operational risks.
IBM Cloud Foundry Migration Runtime builds on several of open-source projects including Cloud Foundry itself.
The first is cf-operator is a Kubernetes Operator from the Quarks project that takes a Cloud Foundry BOSH release and converts it into Kubernetes resources.
The next is KubeCF , a distribution that deploys Cloud Foundry using the cf-operator.
IBM Cloud Foundry Migration Runtime builds on KubeCF to deploy an opinionated install that works effectively with OpenShift. This makes use of Project Eirini to use the OpenShift Kubernetes scheduler directly for running user applications rather than the traditional Cloud Foundry Diego/Garden scheduler.
Developers interact with IBM Cloud Foundry Migration Runtime through a standard cf CLI used with all Cloud Foundry distributions. This provides the cf command.
The platform also provides a Stratos -based Web Interface.
Administrators interact using the same tools as developers but in addition are also likely to interact through the OpenShift console an oc CLI tool.
The platform also provides OpenShift routes to manage traffic into the both Cloud Foundry components and the Stratos-based UI.
There are two type of components in IBM Cloud Foundry Migration Runtime.
The first are long-running components that provide Cloud Foundry APIs, authentication and services. The second are transient components that start in order to build and deploy user application and then terminate.
In addition to the Cloud Foundry Platform components IBM Cloud Foundry Migration Runtime provides a a separate ingress and UI.
These containerised components can be grouped by function as follows:
|adapter||Manages connections to the syslog drains of user applications as part of the logging system.|
|cloud controller (api)||The IBM Cloud Foundry Migration Runtime Cloud Controller, which implements the CF API.|
|bits||Serves OCI images for droplets of user applications.|
|cc-worker||Worker to process background tasks for the Cloud Controller.|
|credhub||Credential management and secure storage component.|
|database||A PXC database to store persistent data for components such as the cloud controller and UAA.|
|diego-api||API for the Diego scheduler.|
|doppler||Routes log messages from applications and components.|
|eirini||An alternative to the Diego scheduler that allows scheduling on the OpenShift Kubernetes scheduler directly.|
|log-api||Exposes log streams to users using web sockets and proxies user application log messages to syslog drains. Exposed using the router.|
|nats||A pub-sub messaging queue for the routing system.|
|router||Routes application and API traffic.|
|routing-api||API for the routing system.|
|scheduler||Service used to create, schedule and interact with jobs that execute on Cloud Foundry.|
|singleton-blobstore||A WebDAV blobstore for storing application bits, buildpacks, and stacks.|
|uaa||User account and authentication.|
This is a diagram of how IBM Cloud Foundry Migration Runtime interact. Each component is exposed as Kubernetes service.
All user traffic is through an OpenShift routes. This directs traffic to only the router component and the cfmr UI component via an TLS-secured HTTPS connection. A user cannot access any other component directly.
Within the OpenShift project components communicate between using secure and insecure connections.
There are three types of user to illustrate:
A platform developer will deploy an application using the CF CLI with the
cf push command.
cf pushcommand in the CF CLI.