Understand Openshift Buildconfig Configurations

Introduction

Red Hat Openshift is an on-premises platform as a service built to Docker containers orchestrate and manage. Openshift is build top on Kubernetes. Upon standers Kubernetes resources, Openshift has introduced new resources to docker container orchestration. Among them one resource is BuildConfig in addition, to support Build Config Openshift developed a new technology called Source-to-Image (S2I) to build pods. Source-to-Image technology can be used with Openshift out of the box. S2I provides Openshift capabilities equivalent to Jenkins. A build is a process transform input parameters or source code into a runnable image. Openshif Buildconfig configuration is the definition of input source, build process, and the output of the build. This article will help you to Understand Openshift Buildconfig Configurations.

Understand Openshift Buildconfig Configurations

In a Buildconfig definition, there a list of directives to be fill. A sample Buildconfig definition looks like below,

apiVersion: build.openshift.io/v1
kind: BuildConfig
metadata:
  name: maven-webapp-build
spec:
  runPolicy: <... list the run policy ...>
  triggers:
    <... list of triggers ...> 
  source:
    <... input parameters or source ...>
  strategy:
    <... build strategy to use ...>
  output:
    <... repository details ...>
  postCommit:
    <... optinal build hooks ...>

Under the spec section source, strategy and output must be filled in order to run the build config. triggers and postcommit directives are optional.

• triggers - can be used to define the way in which this build can be triggered. Webhooks like GitHub/GitLab webhooks can be used to trigger this build. Those configurations are defined here.
• source - under this section input parameters and source code repository is define.
• strategy - define the way which Openshift should build the image
• output - This directive is used to set an image output repository. This can be either Openshift build in a private repository, private image repository hosted on-prem, or the docker hub.

Build Strategies

There are three primary build strategies available to use. Additionally, there is the Pipeline strategy. The Pipeline build strategy can be used to implement sophisticated workflows, continuous integration, and continuous deployment. Primary build strategies are,

• Docker Build
• Source-to-Image
• Custom Build

Docker Build

The Docker build strategy invokes the docker build command, and it therefore expects a repository with a Dockerfile along with all required artifacts to produce a runnable image or an inline Dockerfile define in the build config with all required artifacts to produce a runnable image in the source repository.

Source-to-Image (S2I) Build

Red Hat introduced Source-to-Image technology in order to reduce workload from developers and allow them to focus on the code. Openshift provides a list of pre-built language images based on centos/s2i-base-centos7 and also they provide a Redhat flavored based image. Those images are built with S2I binary, all the essential libraries, and tools needed for the development environment. List of OpenShift language images,

• s2i-python
• s2i-ruby
• s2i-nodejs
• s2i-perl
• s2i-php

S2I will inject your code into one of the base language images listed above. S2I supports incremental builds, which re-use previously downloaded dependencies, previously built artifacts.

Custom Build

The Custom build strategy allows developers to define a specific builder image responsible for the entire build process. Using your own builder image allows you to customize your build process.

Pipeline Build

The Pipeline build strategy allows developers to define a Jenkins pipeline for execution by the Jenkins pipeline plugin. The build can be started, monitored, and managed by the OpenShift Container Platform in the same way as any other build type.

Build Inputs — (Source)

Under the source directive, we can define input parameters and source code. There are a few methods that we can use to input parameters and source codes.

1. Inline Dockerfile definitions
2. Content extracted from existing images
3. Git repositories
4. Binary (Local) inputs
5. Input secrets
6. External artifacts

You can combine multiple inputs in a single build. However, the Inline Dockerfile definition has the highest priority. it will overwrite any other file named Dockerfile provided by another input. You can’t use Binary (local) input and Git repositories in the same build config.

Openshift BuildConfig Configuration Example — 1

Now, its time to do some cording. In the first example, I will explain a BuildConfig which use Docker Build Strategy and use of Inline Dockerfile definition as the build input source.

In the first two lines in the file, we are telling Openshit to use build.openshift.io/v1 API version and BuildConfig kind. Under the metadata section, I only used one directive, name to give a name to the BuildConfig.

As I mentioned earlier, we are using the inline Dockerfile definition as the input source. To tell the Openshit to use the Dockerfile in the build config definition, we set the source type to docker. Then it's time to write the Dockerfile.

FROM tomcat
RUN wget https://github.com/Chathuru/maven-web-project/releases/download/v1.0/maven-webapp.war -O /usr/local/tomcat/webapps/maven-webapp.war
CMD ["catalina.sh", "run"]

I used the simple Dockerfile above. I am using tomcat as the base image. Then, it will download and save the maven-webapp.war in tomcat's webapps directory. Finally, I am stating the tomcat server in the image.

As we are trying to build a docker image from the inline docker file we need to use the docker build strategy. Inline 13, under the strategy, I set to use the docker strategy.

Finally, we have to provide a repository to upload the build image. To that in this example, I am using Openshitf’s local repository. This configuration is set under the output under to directive. To use Openshitf's local repository, set the kind as ImageStreamTag. You can also push the image to docker hub after a successful build by setting kind as the DockerImage. Give a name and aversion to the final image. Keep in mind if you are using the Openshitf's local repository, you need to create the ImageStream object.

You can find all Openshift resources in the GitHub repository directory. In the repository, you can find the DeploymentConfig.yaml, Service.yaml and Router.yaml as well. By deploying this resource on the Openshift, you can use the image you build with the build config.

Openshift BuildConfig Configuration Example — 2

In the example — 1, I explained to you, how to use Docker Build Strategy and Inline Dockerfile definition. In this example, I will explain how to use Docker Build Strategy and Git repositories. In this, I hosted all resources on the Github repository.

As I am using the same Docker Build Strategy as an example - 1, there is no difference in the strategy section. If you save the Dockerfile in a subdirectory inside the Git repository you can set the subdirectory path under the strategy section with the dockerStrategy directive. However, you can change to the subdirectory with git input as well.

You can find another example which uses Docker Build Strategy and Git repositories in this Github repository.

Source-to-Image (S2I) Build Strategy

In this example, I am using the Git repositories as the source input method. But for the build strategy, I am using the source strategy. Here, I use centos/python-36-centos7 as the OpenShift language images.

I will write a separate article to explain more about S2I and Openshit Custom build strategy.