第 5 章 Using build strategies
The following sections define the primary supported build strategies, and how to use them.
5.1. Docker build
OpenShift Container Platform uses Buildah to build a container image from a Dockerfile. For more information on building container images with Dockerfiles, see the Dockerfile reference documentation.
If you set Docker build arguments by using the buildArgs array, see Understand how ARG and FROM interact in the Dockerfile reference documentation.
5.1.1. Replacing Dockerfile FROM image
You can replace the FROM instruction of the Dockerfile with the from of the BuildConfig object. If the Dockerfile uses multi-stage builds, the image in the last FROM instruction will be replaced.
Procedure
To replace the FROM instruction of the Dockerfile with the from of the BuildConfig.
strategy:
dockerStrategy:
from:
kind: "ImageStreamTag"
name: "debian:latest"5.1.2. Using Dockerfile path
By default, docker builds use a Dockerfile located at the root of the context specified in the BuildConfig.spec.source.contextDir field.
The dockerfilePath field allows the build to use a different path to locate your Dockerfile, relative to the BuildConfig.spec.source.contextDir field. It can be a different file name than the default Dockerfile, such as MyDockerfile, or a path to a Dockerfile in a subdirectory, such as dockerfiles/app1/Dockerfile.
Procedure
To use the dockerfilePath field for the build to use a different path to locate your Dockerfile, set:
strategy:
dockerStrategy:
dockerfilePath: dockerfiles/app1/Dockerfile5.1.3. Using docker environment variables
To make environment variables available to the docker build process and resulting image, you can add environment variables to the dockerStrategy definition of the build configuration.
The environment variables defined there are inserted as a single ENV Dockerfile instruction right after the FROM instruction, so that it can be referenced later on within the Dockerfile.
Procedure
The variables are defined during build and stay in the output image, therefore they will be present in any container that runs that image as well.
For example, defining a custom HTTP proxy to be used during build and runtime:
dockerStrategy:
...
env:
- name: "HTTP_PROXY"
value: "http://myproxy.net:5187/"
You can also manage environment variables defined in the build configuration with the oc set env command.
5.1.4. Adding docker build arguments
You can set docker build arguments using the buildArgs array. The build arguments are passed to docker when a build is started.
See Understand how ARG and FROM interact in the Dockerfile reference documentation.
Procedure
To set docker build arguments, add entries to the buildArgs array, which is located in the dockerStrategy definition of the BuildConfig object. For example:
dockerStrategy:
...
buildArgs:
- name: "foo"
value: "bar"
Only the name and value fields are supported. Any settings on the valueFrom field are ignored.
5.1.5. Squash layers with docker builds
Docker builds normally create a layer representing each instruction in a Dockerfile. Setting the imageOptimizationPolicy to SkipLayers merges all instructions into a single layer on top of the base image.
Procedure
Set the
imageOptimizationPolicytoSkipLayers:strategy: dockerStrategy: imageOptimizationPolicy: SkipLayers
