Red Hat Summit Red Hat SummitSupportKonsoleEntwicklerDemo startenKontakt

Dieser Inhalt ist in der von Ihnen ausgewählten Sprache nicht verfügbar.

Chapter 9. Performing advanced builds

The following sections provide instructions for advanced build operations including setting build resources and maximum duration, assigning builds to nodes, chaining builds, build pruning, and build run policies.

9.1. Setting build resources
Link kopieren

By default, builds are completed by pods using unbound resources, such as memory and CPU. These resources can be limited.

Procedure

You can limit resource use in two ways:

  • Limit resource use by specifying resource limits in the default container limits of a project.

  • Limit resource use by specifying resource limits as part of the build configuration. ** In the following example, each of the 

    resources
    , 
    cpu
    , and 
    memory
    parameters are optional: 

    apiVersion: "v1"
kind: "BuildConfig"
metadata:
  name: "sample-build"
spec:
  resources:
    limits:
      cpu: "100m"
    1 
    
      memory: "256Mi"
    2
    1
    cpu is in CPU units: 100m represents 0.1 CPU units (100 * 1e-3).
    2
    memory is in bytes: 256Mi represents 268435456 bytes (256 * 2 ^ 20).

    However, if a quota has been defined for your project, one of the following two items is required:

    • A 

      resources
      section set with an explicit 
      requests
      : 

      resources:
  requests:
      1 
      
    cpu: "100m"
    memory: "256Mi"
      1
      The requests object contains the list of resources that correspond to the list of resources in the quota.

    • A limit range defined in your project, where the defaults from the 

      LimitRange
      object apply to pods created during the build process.

      Otherwise, build pod creation will fail, citing a failure to satisfy quota.

9.2. Setting maximum duration
Link kopieren

When defining a 

BuildConfig
object, you can define its maximum duration by setting the 
completionDeadlineSeconds
field. It is specified in seconds and is not set by default. When not set, there is no maximum duration enforced.

The maximum duration is counted from the time when a build pod gets scheduled in the system, and defines how long it can be active, including the time needed to pull the builder image. After reaching the specified timeout, the build is terminated by OpenShift Container Platform.

Procedure

  • To set maximum duration, specify 

    completionDeadlineSeconds
    in your 
    BuildConfig
    . The following example shows the part of a 
    BuildConfig
    specifying 
    completionDeadlineSeconds
    field for 30 minutes: 

    spec:
  completionDeadlineSeconds: 1800
Note

This setting is not supported with the Pipeline Strategy option.

9.3. Assigning builds to specific nodes
Link kopieren

Builds can be targeted to run on specific nodes by specifying labels in the 

nodeSelector
field of a build configuration. The 
nodeSelector
value is a set of key-value pairs that are matched to 
Node
labels when scheduling the build pod.

The 

nodeSelector
value can also be controlled by cluster-wide default and override values. Defaults will only be applied if the build configuration does not define any key-value pairs for the 
nodeSelector
and also does not define an explicitly empty map value of 
nodeSelector:{}
. Override values will replace values in the build configuration on a key by key basis.

Note

If the specified 

NodeSelector
cannot be matched to a node with those labels, the build still stay in the 
Pending
state indefinitely.

Procedure

  • Assign builds to run on specific nodes by assigning labels in the 

    nodeSelector
    field of the 
    BuildConfig
    , for example: 

    apiVersion: "v1"
kind: "BuildConfig"
metadata:
  name: "sample-build"
spec:
  nodeSelector:
    1 
    
    key1: value1
    key2: value2
    1
    Builds associated with this build configuration will run only on nodes with the key1=value2 and key2=value2 labels.

9.4. Chained builds
Link kopieren

For compiled languages such as Go, C, C++, and Java, including the dependencies necessary for compilation in the application image might increase the size of the image or introduce vulnerabilities that can be exploited.

To avoid these problems, two builds can be chained together. One build that produces the compiled artifact, and a second build that places that artifact in a separate image that runs the artifact.

In the following example, a source-to-image (S2I) build is combined with a docker build to compile an artifact that is then placed in a separate runtime image.

Note

Although this example chains a S2I build and a docker build, the first build can use any strategy that produces an image containing the desired artifacts, and the second build can use any strategy that can consume input content from an image.

The first build takes the application source and produces an image containing a 

WAR
file. The image is pushed to the 
artifact-image
image stream. The path of the output artifact depends on the 
assemble
script of the S2I builder used. In this case, it is output to 
/wildfly/standalone/deployments/ROOT.war
. 

apiVersion: build.openshift.io/v1
kind: BuildConfig
metadata:
  name: artifact-build
spec:
  output:
    to:
      kind: ImageStreamTag
      name: artifact-image:latest
  source:
    git:
      uri: https://github.com/openshift/openshift-jee-sample.git
      ref: "master"
  strategy:
    sourceStrategy:
      from:
        kind: ImageStreamTag
        name: wildfly:10.1
        namespace: openshift

The second build uses image source with a path to the WAR file inside the output image from the first build. An inline 

dockerfile
copies that 
WAR
file into a runtime image. 

apiVersion: build.openshift.io/v1
kind: BuildConfig
metadata:
  name: image-build
spec:
  output:
    to:
      kind: ImageStreamTag
      name: image-build:latest
  source:
    dockerfile: |-
      FROM jee-runtime:latest
      COPY ROOT.war /deployments/ROOT.war
    images:
    - from:
1 

        kind: ImageStreamTag
        name: artifact-image:latest
      paths:
2 

      - sourcePath: /wildfly/standalone/deployments/ROOT.war
        destinationDir: "."
  strategy:
    dockerStrategy:
      from:
3 

        kind: ImageStreamTag
        name: jee-runtime:latest
  triggers:
  - imageChange: {}
    type: ImageChange
1
from specifies that the docker build should include the output of the image from the artifact-image image stream, which was the target of the previous build.
2
paths specifies which paths from the target image to include in the current docker build.
3
The runtime image is used as the source image for the docker build.

The result of this setup is that the output image of the second build does not have to contain any of the build tools that are needed to create the 

WAR
file. Also, because the second build contains an image change trigger, whenever the first build is run and produces a new image with the binary artifact, the second build is automatically triggered to produce a runtime image that contains that artifact. Therefore, both builds behave as a single build with two stages.

9.5. Pruning builds
Link kopieren

By default, builds that have completed their lifecycle are persisted indefinitely. You can limit the number of previous builds that are retained.

Procedure

  1. Limit the number of previous builds that are retained by supplying a positive integer value for 

    successfulBuildsHistoryLimit
    or 
    failedBuildsHistoryLimit
    in your 
    BuildConfig
    , for example: 

    apiVersion: "v1"
kind: "BuildConfig"
metadata:
  name: "sample-build"
spec:
  successfulBuildsHistoryLimit: 2
    1 
    
  failedBuildsHistoryLimit: 2
    2
    1
    successfulBuildsHistoryLimit will retain up to two builds with a status of completed.
    2
    failedBuildsHistoryLimit will retain up to two builds with a status of failed, canceled, or error.

  2. Trigger build pruning by one of the following actions:

    • Updating a build configuration.
    • Waiting for a build to complete its lifecycle.

Builds are sorted by their creation timestamp with the oldest builds being pruned first.

Note

Administrators can manually prune builds using the 'oc adm' object pruning command.

9.6. Build run policy
Link kopieren

The build run policy describes the order in which the builds created from the build configuration should run. This can be done by changing the value of the 

runPolicy
field in the 
spec
section of the 
Build
specification.

It is also possible to change the 

runPolicy
value for existing build configurations, by:

  • Changing 
    Parallel
    to 
    Serial
    or 
    SerialLatestOnly
    and triggering a new build from this configuration causes the new build to wait until all parallel builds complete as the serial build can only run alone.
  • Changing 
    Serial
    to 
    SerialLatestOnly
    and triggering a new build causes cancellation of all existing builds in queue, except the currently running build and the most recently created build. The newest build runs next.
Red Hat logoGithubredditYoutubeTwitter

Lernen

Testen, kaufen und verkaufen

Communitys

Über Red Hat Dokumentation

Wir helfen Red Hat Benutzern, mit unseren Produkten und Diensten innovativ zu sein und ihre Ziele zu erreichen – mit Inhalten, denen sie vertrauen können. Entdecken Sie unsere neuesten Updates.

Mehr Inklusion in Open Source

Red Hat hat sich verpflichtet, problematische Sprache in unserem Code, unserer Dokumentation und unseren Web-Eigenschaften zu ersetzen. Weitere Einzelheiten finden Sie in Red Hat Blog.

Über Red Hat

Wir liefern gehärtete Lösungen, die es Unternehmen leichter machen, plattform- und umgebungsübergreifend zu arbeiten, vom zentralen Rechenzentrum bis zum Netzwerkrand.

Theme

© 2026 Red HatNach oben