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.

Categories

More from Cloud

Kubernetes version 1.28 now available in IBM Cloud Kubernetes Service

2 min read - We are excited to announce the availability of Kubernetes version 1.28 for your clusters that are running in IBM Cloud Kubernetes Service. This is our 23rd release of Kubernetes. With our Kubernetes service, you can easily upgrade your clusters without the need for deep Kubernetes knowledge. When you deploy new clusters, the default Kubernetes version remains 1.27 (soon to be 1.28); you can also choose to immediately deploy version 1.28. Learn more about deploying clusters here. Kubernetes version 1.28 In…

Temenos brings innovative payments capabilities to IBM Cloud to help banks transform

3 min read - The payments ecosystem is at an inflection point for transformation, and we believe now is the time for change. As banks look to modernize their payments journeys, Temenos Payments Hub has become the first dedicated payments solution to deliver innovative payments capabilities on the IBM Cloud for Financial Services®—an industry-specific platform designed to accelerate financial institutions' digital transformations with security at the forefront. This is the latest initiative in our long history together helping clients transform. With the Temenos Payments…

Foundational models at the edge

7 min read - Foundational models (FMs) are marking the beginning of a new era in machine learning (ML) and artificial intelligence (AI), which is leading to faster development of AI that can be adapted to a wide range of downstream tasks and fine-tuned for an array of applications.  With the increasing importance of processing data where work is being performed, serving AI models at the enterprise edge enables near-real-time predictions, while abiding by data sovereignty and privacy requirements. By combining the IBM watsonx data…

The next wave of payments modernization: Minimizing complexity to elevate customer experience

3 min read - The payments ecosystem is at an inflection point for transformation, especially as we see the rise of disruptive digital entrants who are introducing new payment methods, such as cryptocurrency and central bank digital currencies (CDBC). With more choices for customers, capturing share of wallet is becoming more competitive for traditional banks. This is just one of many examples that show how the payments space has evolved. At the same time, we are increasingly seeing regulators more closely monitor the industry’s…