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 Origin leverages Kubernetes by creating Docker-formatted containers from build
images and pushing them to a
container registry.
Build objects share common characteristics: inputs for a build, the need 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 Origin 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:
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:
-
continuous integration
-
continuous deployment
Docker Build
The Docker build strategy invokes the docker build command, and it therefore expects a repository with a Dockerfile and all required
artifacts in it to produce a runnable image.
Source-to-Image (S2I) Build
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 with the docker run command. S2I supports incremental
builds, which re-use previously downloaded dependencies, previously built
artifacts, etc.
The advantages of S2I include the following:
|
Image flexibility
|
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 tar to inject application
source, so the image needs to be able to process tarred content.
|
|
Speed
|
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.
|
|
Patchability
|
S2I allows you to rebuild the application consistently if an
underlying image needs a patch due to a security issue.
|
|
Operational efficiency
|
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.
|
|
Operational security
|
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.
|
|
User efficiency
|
S2I prevents developers from performing arbitrary yum
install type operations, which could slow down development iteration, during
their application build.
|
|
Ecosystem
|
S2I encourages a shared ecosystem of images where you can leverage
best practices for your applications.
|
|
Reproducibility
|
Produced images can include all inputs including specific versions
of build tools and dependencies. This ensures that the image can be reproduced
precisely.
|
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.
A Custom builder image is a plain Docker-formatted container image embedded with build process logic, for example for building RPMs or base images. The openshift/origin-custom-docker-builder image is available
on the
Docker Hub registry as an example implementation of a Custom builder image.
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
OpenShift Origin 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.
The first time a project defines a build configuration using a Pipeline
strategy, OpenShift Origin instantiates a Jenkins server to execute the
pipeline. Subsequent Pipeline build configurations in the project share this
Jenkins server.
For more details on how the Jenkins server is deployed and how to configure or
disable the autoprovisioning behavior, see
Configuring Pipeline Execution.
|
|
The Jenkins server is not automatically removed,
even if all Pipeline build configurations are deleted.
It must be manually deleted by the user.
|