OpenShift Build Process

In this article, we will explore the various ways to build and customize images in Red Hat OpenShift.

The Build Process:

Redhat Openshift includes tooling for building your applications. A build process uses input parameters and source code or application binaries to create container images. The BuildConfig resource contains the definition for the build process, which includes:

• A build trigger that starts the build process.
• A build strategy that defines how the build process works.
• One or more input sources, such as git, binary, or inline definitions.
• The build process output, which most often is a runnable container image.

On every build execution, OpenShift creates a Build object for that particular run. The Build object contains metadata and the build execution logs.

Build Strategies:

The following are the available build strategies in OpenShift:
• Source-to-Image (S2I) build
• Docker build
• Custom build
The resulting build object is a runnable image in the case of S2I or Docker strategies. Custom builds can have any type of output, such as RPMs or base images.

Source-to-Image (S2I) Build:

This allow us to build the container images without manually creating a Containerfile. S2I creates a new container image by using an application source code.

Docker Build:

The docker build strategy uses the buildah CLI to build a new container image by running the instructions from an existing Containerfile. The docker strategy can retrieve the Containerfile and the artifacts to build the container image from a Git repository, or can use a Containerfile provided inline in the build configuration as a build input source.

** Developers do not need to set up the container tooling on their workstation because the build runs as a pod inside the OpenShift cluster.

Custom Build:

The custom build strategy specifies a builder image responsible for the build, which enables developers to define the build process. Custom builds require a high level of cluster privileges to run.

BuildConfig Resource:

OpenShift generates a BuildConfig when we create an application by either running the oc new-app or oc new-build commands, or by using the web console. We can also edit the BuildConfig definition to customize it to your needs.
The following example builds a sample php application by using the source strategy and a git input source:

sample Buildconfig

• The runPolicy attribute defines whether several builds can run simultaneously. The Serial value represents that only one build can run at a time.
• The ImageChange trigger that creates a new build when the ruby-20-centos7:latest image stream changes.
• The Git source attribute responsible for defining the input source of the build. A BuildConfig can have multiple inputs.
• Defines the Source build strategy, which uses the S2I technology to build the container image.
• The output attribute defines where to push the new container image after a successful build.
• Output image kind set to ImageStreamTag, which targets the image creation to the image registry integrated in OpenShift. To specify any image registry, use the DockerImage kind, which allows fully qualified image names.

Build Input:

Build inputs provide source content for builds. Openshift supports the following types of input sources, listed in order of precedence.

• Inline Dockerfile: Specifies the Containerfile instructions to build an image.
• Image: Enables injecting sources from container images. The image source can be a container image or an image stream.
• Git: Openshift clones the input application source code from a Git repository. The source code location inside the repository is configurable.
• Binary: Enables uploading binary content from local file system to the builder.
• Input secrets: We can use input secrets to enable creating credentials for the build that are not available in the final application image.
• External artifacts: Allow copying binary files to the build process.

We can combine multiple inputs in a single build. However, as the inline Containerfile takes precedence, it overrides any other Containerfile provided by another input. Additionally, binary input and Git repositories are mutually exclusive inputs.