Build an image on a managed serverless platform

This article is part of the Introduction to IBM Cloud Code Engine series.

What is the build container images feature in IBM Cloud Code Engine

IBM Cloud Code Engine runs containerized workloads. If you choose to point to an existing container image, you can then ask IBM Cloud Code Engine to run it for you. But it means you have to take care of the build process to generate the container image. If you want to only focus on writing your source code and do not want to take care of the image build process, then you can use the build container images feature. You provide source code directly (via a Git repo) and IBM Cloud Code Engine builds and manages the container image for you. Those familiar with Cloud Foundry should recognize the similarities.

IBM Cloud Code Engine supports two build strategies. One is Dockerfile build, which uses the Kaniko builder tool. The other is Cloud Native Buildpack, which uses the Paketo builder tool.

Dockerfile build provides more flexibility, but you must understand the Dockerfile commands and take responsibility for the base image and vulnerability issues. So, if you already have Dockerfile in your Git repo, you can use Dockerfile build.

If you are developing a new microservice, you do not need to write a Dockerfile, and should use Cloud Native Buildpack instead because it is a more user-friendly option with nothing new to learn. You do not need to worry about the base image and vulnerability issues. It will inspect your source repository and detect which runtime environment that your code is based on and how a container image is built from your source. If you are a Cloud Foundry user, your application source code could be built by Cloud Native Buildpack and run as an application on IBM Cloud Code Engine with a similar experience as Cloud Foundry. However, IBM Cloud Code Engine gives you more power features, such as the ability to scale to zero.

The documentation for building container images can help you get started.

Reasons to build container images in IBM Cloud Code Engine

You may think building container images is simple and you can run it on your laptop. But this will probably not be viable if you work for an enterprise with hundreds of applications and ensuring security compliance is a priority. For enterprises, developers should consider how to:

  • Maintain a build environment that is always secure.
  • Write Dockerfile files and maintain a proper base image.
  • Take care of image vulnerability issue and remediate it.

You will not have to worry about those considerations by building container images in IBM Cloud Code Engine (we’ll refer to this as the Build service going forward), especially with Cloud Native Buildpack or Dockerfile support. As a developer, you will only focus on writing your source code. Then the click of a button will start a build in IBM Cloud Code Engine. It will maintain your base image without vulnerability issues, inspect your source repository, detect the program language, build your image, and upload to your container registry. In the future, IBM Cloud Code Engine will also support auto trigger build when there is a Git repo change and base image update.

Build service introduction

From a user interface (UI) perspective, you need an easy way to start a build. The Build service provides the concepts of Build, BuildRun and BuildStrategy within the front-end UI. From the back-end perspective, it leverages Tekton as the engine to run an actual build. The Build service is based on the Shipwright build open source framework for building container images on Kubernetes. It includes 3 concepts:

  • The BuildStrategy is used to define the process to used to execute the builder tool.
  • The Build is used to define a build configuration.
  • The BuildRun is used to start the actual image build using a registered strategy.

Shipwright build, Tekton, and BuildStrategy are key components of the Build service to orchestrate a build. As the following diagram illustrates, you provide a Git repo (both public and private Git repos are supported) that contains source code and select the BuildStrategy and Build Spec (CPU and memory) to kick off the build. As a result, a container image is generated and pushed to your container registry (both public and private registries are supported).

Diagram of how the Build service works

How to use the Build service on IBM Cloud Code Engine

IBM Cloud Code Engine provides simplified UI and CLI experiences by abstracting high level concepts from the developer point of view. In fact, you do not need to understand any back-end concepts. Generally, there are two steps to start a build.

1. Define your Build

  1. Create a project in IBM Cloud Code Engine to contain all of your resource and actions. You must build inside a project.
  2. Provide information to create a build, including the name of the build, URL of the source code Git repo, and the branch of the Git repo.
  3. Select your BuildStrategy. As mentioned before, IBM Cloud Code Engine currently supports the two build strategies of Dockerfile and Cloud Native Buildpack.
  4. Select how many CPU and memory requests you have. Since IBM Cloud Code Engine has a pay-as-you-go model, you’ll only pay for the infrastructure resources that you use.
  5. Provide the container registry location where you want to push your image as output, including the container registry and image tag.

2. Kick off your Build

You can kick off your Build multiple times. A BuildRun is created each time as a record where you can see all general information, the Build log, and BuildRun status.

Following are some examples of using the IBM Cloud Code Engine CLI to start a Build. There are only 5 steps to complete an end-to-end build process:

  1. Create a secret to allow the IBM Cloud Code Engine Build service to access your container registry:

     ibmcloud code-engine registry create --name <CONTAINER_REGISTRY_SECRET_NAME> --server <REGISTRY> --username <USERNAME> --password <PASSWORD>
  2. Create a Build:

     ibmcloud code-engine build create --name helloworld-build --source --context-dir /helloworld --strategy kaniko --size medium --image --registry-secret icr-mynamespace
  3. Kick off a BuildRun:

     ibmcloud code-engine buildrun submit --name helloworld-build-run --build helloworld-build
  4. Check status of the BuildRun:

     ibmcloud code-engine buildrun get --name helloworld-build-run
  5. View the BuildRun:

     ibmcloud code-engine buildrun logs -i <BUILDRUN_INSTANCE_NAME>

For more details, visit the Build service documentation and try it yourself by registering for an IBM Cloud Code Engine trial.


Building a container image from source code is an important developer capability. However, it does not cover other things such as how to build, what is a base image, how to trigger a build, or how to handle vulnerability issues. To create 12-factor applications, functions and event batch jobs more easily, you can just provide source code for the IBM Cloud Code Engine Build service to generate an image, and create the application and batch job from the image for you.