How to migrate from Cloud Foundry to Code Engine and set up continuous integration and continuous delivery (CI/CD).

Recently, IBM announced the deprecation of Cloud Foundry. There are a few migration options and IBM Cloud Code Engine is one of them. It is a fully managed, serverless platform that runs your containerized workloads, including web apps, microservices, event-driven functions or batch jobs. 

In this post, I am going to show how to migrate from Cloud Foundry to Code Engine and set up continuous integration and continuous delivery (CI/CD). 

The goal here is to migrate a Node.js app on Cloud Foundry to Code Engine, along with continuous integration and deployment. In this example, I used a blank Cloud Foundry Node.js template with toolchain enabled, so the source code exists in a private repository in https://REGION.git.cloud.ibm.com. Similarly, I will create another toolchain and a Tekton pipeline and point to the repository to automate build and deployment:

Note: The toolchain template is for the simple Hello World app and it is expecting a Dockerfile, so it may not work with your code. It might be a good start to directly pull source code.

Prerequisites

• IBM Cloud account
• An API key with access to Continuous Delivery, Code Engine and Container Registry
• A project in Code Engine
• A basic understanding of Code Engine and how to write a Dockerfile

In this tutorial, I am going to use a blank Node.js application deployed on Cloud Foundry. The toolchain (CI/CD) is already enabled:

Step 1: Prepare a Dockerfile

Your apps on Code Engine will be running as containers, and a Dockerfile is required for this tutorial. Cloud Foundry uses `Buildpacks` to build a container from your source code, so the Dockerfile does not exist by default.

In this tutorial, I referred to the official nodejs.org document to create one. I ended up having the snippet below for my simple app, and it is stored in the root directory of the code repository. Your Dockerfile would be different from mine and might be more complicated, so I strongly encourage you to test it on your local environment:

FROM node:12
WORKDIR /usr/src/app
COPY . .
RUN npm install
EXPOSE 8000
CMD [ "node", "app.js" ]

It is entirely up to you to decide which base image to use, commands to execute and library to import. Please refer to this document to learn more about Dockerfile and the best practice.

Step 2: Create a toolchain

Now we are going to create a toolchain which automates building a container image and deploy onto Code Engine. 

Step 2.1: Create a template

Open the Toolchain page and click Create toolchain. 

Select Develop a Code Engine application from the list:

Step 2.2: Specify the Git repository

Specify the Git repository in the Application section. Since I am using the existing repository, I selected Bring your own application and set the link:

Step 2.3: Secrets setting

This time, I disabled Secret Manager because I am not going to use it. However, I recommend you to enable it for production use.

Step 2.4: Deployment target

Define your app name, specify an API key with required access and select where to store a container image and deploy your app:

Finally, click Create toolchain.

Results

Now I’ve created a new toolchain:

I also have a new application in my Code Engine project that is accessible:

Additional considerations

Everything went so quickly, and it seemed too easy, right? Below, I’ll list a few things worth mentioning and explain what they are.

Code Engine uses a different pipeline

The Cloud Foundry pipeline typically uses a Classic pipeline. The Code Engine template, on the other hand uses Tekton pipeline, which is an open-source project that you can use to configure and run continuous integration and continuous delivery pipelines. The way each pipeline handles build and deploy is different.

About Tekton pipeline

When you open the toolchain, you will see two pipelines: ci-pipeline and pr-pipeline. They are both Tekton pipelines, which is comprised of a set of tasks to build and deploy your application:

• ci-pipeline: Runs every time a code change is committed. 
• pr-pipeline: Runs when a pull request is made.

All tasks are defined in .yaml files and they are stored in two additional repositories created in your Git workspace:

The repositories contain many examples of tasks that represent each action in a pipeline, such as pulling source code, building a container image and testing. You can modify these tasks and add them to the definition of the pipeline. Each task specified in the Definition section runs according to Pipeline Definition, so if you have a custom pipeline, you need to modify the definition and validate:

Check pipeline logs

You can check how each tasks went from PipelineRuns:

Check application logs

You can easily check your app logs by integrating with logDNA, or you can use the ibmcloud cli to obtain the log.

Please refer to this document for more details:

Scale your application

Did it take some time to start your app? It’s probably because your app is set to scale down to zero by default so Code Engine was starting up your app when you accessed it. You can modify the configuration and set it to have a minimum of one application running at all times for a quicker response:

Modify your code

Many existing Cloud Foundry apps use Service binding to access other services, such as database and cognitive services. Service binding is a quick way to create service credentials for an IBM Cloud service, and if your Cloud Foundry app is using service bindings, you need to create new bindings for your Code Engine app and update your source code.

To be specific, service binding information for your Cloud Foundry apps is stored in the VCAP_SERVICES environment variable. However, for your Code Engine apps, it will be stored in CE_SERVICES.

What’s next?

It’s quire difficult to have suitable tasks and set up an efficient pipeline for your application, simply because it is about configuring an ecosystem and is completely different to app development. IBM Cloud Code Engine is more suitable for running microservices, and it is important to review the CI/CD cycle of your app with your team. For enterprise-level application that requires higher security, Kubernetes might be a better option than Code Engine.