Builds for Red Hat OpenShift is now generally available

We are excited to announce the general availability of Builds for Red Hat OpenShift. Builds enables application developers to build container images for their applications using popular tools in the Kubernete ecosystem. Builds for OpenShift is based on the open source Shipwright project (part of the CD Foundation) and provides a Kubernetes-native API for declaring and running image builds that run on-demand on the cluster and produce images that are then pushed to an image registry.

In the early days of Kubernetes, deploying applications necessitated developers to craft Dockerfiles and produce an image for their application outside of the cluster itself. Although Dockerfiles are powerful, this process imposed skillset challenges for developers, and at the same time, compliance and security challenges for IT ops due to complexities of enforcing control over the content of Dockerfiles.

A decade ago, OpenShift introduced BuildConfigs and Source-to-Image (S2I) to alleviate these challenges by enabling developers to build images for their applications on the cluster with an enhanced security posture, directly from source code and within the compliance boundaries of the organization. S2I is used today by thousands of OpenShift customers for building images on OpenShift.

Fast forward to today, the Kubernetes ecosystem has grown significantly, introducing new tools and methods for building images. Tools like Cloud-Native Buildpacks, Kaniko, ko, JIB, and more have emerged offering developers diverse options and flexibilities to choose from. Builds for OpenShift represents an evolution of the build capabilities that has been an integral part of OpenShift since the start. This evolution provides developers with the flexibility to select tools for building images that fit their skills and requirements while taking advantage of a more consistent API and user experience on the OpenShift platform.

Build images with Dockerfiles, S2I and Cloud-Native Buildpacks

Builds for OpenShift provides an extensible framework for defining container build tools for use on OpenShift clusters, while abstracting away the complexities of setting up and using these tools. A build strategy defines how a container image is built from a set of inputs such as the application source code. This process is described declaratively as a Kubernetes resource (BuildStrategy or ClusterBuildStrategy) with a series of steps executing in a set of containers in a pod which is scheduled to run on the cluster and produce the resulting image.

Builds for OpenShift provides and supports Buildah (Dockerfiles), Source-to-Image and Cloud-Native Buildpacks (as a Developer Preview) out of the box. In addition, admins and developers are able to install additional build strategies from the Shipwright community such as Kaniko, ko, and BuildKit at the cluster-level or within their namespaces (no admin rights needed).

Teams that need to customize Shipwright build strategies or create additional build strategies to enable use of other image tools, can do so through creating a BuildStrategy or ClusterBuildStrategy custom resources:

apiVersion: shipwright.io/v1beta1
kind: ClusterBuildStrategy
metadata:
name: buildpacks
spec:
volumes:
parameters:
steps:
  - name: prepare
    image: 
    script:
    volumeMounts:
  - name: analyze
    image: 
    script:
    volumeMounts:
  - name: build
    image: 
    script:
    volumeMounts:
  - name: push
    image: 
    script:
    volumeMounts:

The series of steps in the above example specify the images, the order that should be used to start a container for each step and the commands that should run within that container throughout the build process. The specification of each step is intentionally similar to the Container specification in Kubernetes in order to enable taking advantage of Kubernetes constructs and capabilities such as volumes, env vars, configmaps, secrets, etc within the builds. Builds uses service accounts in order to granularly control access to resources that a particular build is allowed to access on the cluster during the build process.

Change build tools without changing the build infrastructure

Builds for OpenShift empowers application developers to choose the best build tool that suits their application, team skills and organization requirements without having to learn and operate a local build environment or build infrastructure dedicated to the chosen tool. Build for OpenShift provides developers with a consistent API and user experience, through OpenShift Console and Shipwright CLI, for defining and executing image builds on-demand on the cluster.

The following Shipwright CLI creates a Build on OpenShift which uses the S2I build strategy to build a container image from the source code of a Node.js application on GitHub and pushes the resulting image to Red Hat Quay image registry: 

$ shp build create nodejs-app \
  --source-url="https://github.com/g/nodejs-app" \
  --strategy-name="source-to-image" \
  --builder-image="registry.redhat.io/rhel9/nodejs-20-minimal" \
  --output-image="quay.io/myorg/nodejs-app:latest"

Similarly, the Shipwright CLI could be used for creating a Build using any other build strategies such Buildah in the following example which uses the Dockerfile available in this provided Git repository to build the application image and push to :

$ shp build create go-app \
  --source-url="https://github.com/g/go-app" \
  --strategy-name="buildah" \
  --output-image="artifactory/reg/go-app:latest"

Once the Build is created for an application, the build can get executed using Shipwright CLI or OpenShift Web Console.

$ shp build run nodejs-app
$ shp build run go-app -env MODE=PROD

Integrates Builds into your CI/CD pipeline

Builds for OpenShift is designed to simplify building container images by running builds on-demand on the OpenShift clusters and removing the complexities of installing and configuring build tools locally on the CI/CD infrastructure. Using the Shipwright CLI, the build process would get started as a step within the CI pipeline of your choice to build an image on the cluster and within the same security, operational and compliance boundaries that the resulting application images will be deployed.

Get started

To try out Builds for OpenShift, install Builds for OpenShift operator from the OperatorHub on your cluster and then follow the docs to run your first build on OpenShift.

Cloud-Native Buildpacks build strategy is currently released as a Developer Preview. You can try out Buildspacks on OpenShift using the Buildpacks guide.

What’s next

While we are thrilled about reaching the GA milestone, it’s just the beginning. Red Hat continues to engage within the Shipwright and Buildpacks communities to evolve this project with additional build strategies such as multi-arch builds as well as capabilities around Git triggering, dependencies caching, SBOM generation and simplifying sharing of credentials and subscription entitlements across namespaces for consumption within builds.