A build is the process of transforming input parameters into a resulting
object. Most often, the process is used to transform input parameters or source
code into a runnable image. A
BuildConfig object is the definition of the
entire build process.
OpenShift Container Platform uses Kubernetes by creating containers from build images and pushing them to a container image registry.
Build objects share common characteristics including inputs for a build, the requirement to complete a build process, logging the build process, publishing resources from successful builds, and publishing the final status of the build. Builds take advantage of resource restrictions, specifying limitations on resources such as CPU usage, memory usage, and build or pod execution time.
The OpenShift Container Platform build system provides extensible support for build strategies that are based on selectable types specified in the build API. There are three primary build strategies available:
Source-to-Image (S2I) build
By default, Docker builds and S2I builds are supported.
The resulting object of a build depends on the builder used to create it. For Docker and S2I builds, the resulting objects are runnable images. For Custom builds, the resulting objects are whatever the builder image author has specified.
Additionally, the Pipeline build strategy can be used to implement sophisticated workflows:
The Docker build strategy invokes the docker build command, and it expects a repository with a Dockerfile and all required artifacts in it to produce a runnable image.
Source-to-Image (S2I) is a tool for building reproducible, Docker-formatted
container images. It produces ready-to-run images by injecting application
source into a container image and assembling a new image. The new image
incorporates the base image (the builder) and built source and is ready to use
buildah run command. S2I supports incremental builds, which re-use
previously downloaded dependencies, previously built artifacts, etc.
The advantages of S2I include the following:
S2I scripts can be written to inject
application code into almost any existing Docker-formatted container image,
taking advantage of the existing ecosystem. Note that, currently, S2I relies on
With S2I, the assemble process can perform a large number of complex operations without creating a new layer at each step, resulting in a fast process. In addition, S2I scripts can be written to re-use artifacts stored in a previous version of the application image, rather than having to download or build them each time the build is run.
S2I allows you to rebuild the application consistently if an underlying image needs a patch due to a security issue.
By restricting build operations instead of allowing arbitrary actions, as a Dockerfile would allow, the PaaS operator can avoid accidental or intentional abuses of the build system.
Building an arbitrary Dockerfile exposes the host system to root privilege escalation. This can be exploited by a malicious user because the entire Docker build process is run as a user with Docker privileges. S2I restricts the operations performed as a root user and can run the scripts as a non-root user.
S2I prevents developers from performing arbitrary
S2I encourages a shared ecosystem of images where you can leverage best practices for your applications.
Produced images can include all inputs including specific versions of build tools and dependencies. This ensures that the image can be reproduced precisely.
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.
A Custom builder image is a plain Docker-formatted container image embedded with build process logic, for example for building RPMs or base images.
Custom builds run with a very high level of privilege and are not available to users by default. Only users who can be trusted with cluster administration permissions should be granted access to run custom builds.
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 OpenShift Container Platform in the same way as any other build type.
Pipeline workflows are defined in a Jenkinsfile, either embedded directly in the build configuration, or supplied in a Git repository and referenced by the build configuration.