Dieser Inhalt ist in der von Ihnen ausgewählten Sprache nicht verfügbar.
Chapter 5. Using build strategies
The following sections define the primary supported build strategies, and how to use them.
5.1. Docker build Link kopierenLink in die Zwischenablage kopiert!
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
5.1.1. Replacing Dockerfile FROM image Link kopierenLink in die Zwischenablage kopiert!
You can replace the
FROM
from
BuildConfig
FROM
Procedure
To replace the
FROM
from
BuildConfig
strategy:
dockerStrategy:
from:
kind: "ImageStreamTag"
name: "debian:latest"
5.1.2. Using Dockerfile path Link kopierenLink in die Zwischenablage kopiert!
By default, docker builds use a Dockerfile located at the root of the context specified in the
BuildConfig.spec.source.contextDir
The
dockerfilePath
BuildConfig.spec.source.contextDir
MyDockerfile
dockerfiles/app1/Dockerfile
Procedure
To use the
dockerfilePath
strategy:
dockerStrategy:
dockerfilePath: dockerfiles/app1/Dockerfile
5.1.3. Using docker environment variables Link kopierenLink in die Zwischenablage kopiert!
To make environment variables available to the docker build process and resulting image, you can add environment variables to the
dockerStrategy
The environment variables defined there are inserted as a single
ENV
FROM
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
5.1.4. Adding docker build arguments Link kopierenLink in die Zwischenablage kopiert!
You can set docker build arguments using the
buildArgs
See Understand how ARG and FROM interact in the Dockerfile reference documentation.
Procedure
To set docker build arguments, add entries to the
buildArgs
dockerStrategy
BuildConfig
dockerStrategy:
...
buildArgs:
- name: "foo"
value: "bar"
Only the
name
value
valueFrom
5.1.5. Squashing layers with docker builds Link kopierenLink in die Zwischenablage kopiert!
Docker builds normally create a layer representing each instruction in a Dockerfile. Setting the
imageOptimizationPolicy
SkipLayers
Procedure
Set the
toimageOptimizationPolicy:SkipLayersstrategy: dockerStrategy: imageOptimizationPolicy: SkipLayers
5.1.6. Using build volumes Link kopierenLink in die Zwischenablage kopiert!
You can mount build volumes to give running builds access to information that you don’t want to persist in the output container image.
Build volumes provide sensitive information, such as repository credentials, that the build environment or configuration only needs at build time. Build volumes are different from build inputs, whose data can persist in the output container image.
The mount points of build volumes, from which the running build reads data, are functionally similar to pod volume mounts.
Prerequisites
Procedure
In the
definition of thedockerStrategyobject, add any build volumes to theBuildConfigarray. For example:volumesspec: dockerStrategy: volumes: - name: secret-mvn1 mounts: - destinationPath: /opt/app-root/src/.ssh2 source: type: Secret3 secret: secretName: my-secret4 - name: settings-mvn5 mounts: - destinationPath: /opt/app-root/src/.m26 source: type: ConfigMap7 configMap: name: my-config8 - name: my-csi-volume9 mounts: - destinationPath: /opt/app-root/src/some_path10 source: type: CSI11 csi: driver: csi.sharedresource.openshift.io12 readOnly: true13 volumeAttributes:14 attribute: value- 1 5 9
- Required. A unique name.
- 2 6 10
- Required. The absolute path of the mount point. It must not contain
..or:and doesn’t collide with the destination path generated by the builder. The/opt/app-root/srcis the default home directory for many Red Hat S2I-enabled images. - 3 7 11
- Required. The type of source,
ConfigMap,Secret, orCSI. - 4 8
- Required. The name of the source.
- 12
- Required. The driver that provides the ephemeral CSI volume.
- 13
- Required. This value must be set to
true. Provides a read-only volume. - 14
- Optional. The volume attributes of the ephemeral CSI volume. Consult the CSI driver’s documentation for supported attribute keys and values.
The Shared Resource CSI Driver is supported as a Technology Preview feature.
5.2. Source-to-image build Link kopierenLink in die Zwischenablage kopiert!
Source-to-image (S2I) is a tool for building reproducible 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
buildah run
5.2.1. Performing source-to-image incremental builds Link kopierenLink in die Zwischenablage kopiert!
Source-to-image (S2I) can perform incremental builds, which means it reuses artifacts from previously-built images.
Procedure
To create an incremental build, create a with the following modification to the strategy definition:
strategy: sourceStrategy: from: kind: "ImageStreamTag" name: "incremental-image:latest"1 incremental: true2 - 1
- Specify an image that supports incremental builds. Consult the documentation of the builder image to determine if it supports this behavior.
- 2
- This flag controls whether an incremental build is attempted. If the builder image does not support incremental builds, the build will still succeed, but you will get a log message stating the incremental build was not successful because of a missing
save-artifactsscript.
5.2.2. Overriding source-to-image builder image scripts Link kopierenLink in die Zwischenablage kopiert!
You can override the
assemble
run
save-artifacts
Procedure
To override the
assemble
run
save-artifacts
-
Provide an ,
assemble, orrunscript in thesave-artifactsdirectory of your application source repository..s2i/bin Provide a URL of a directory containing the scripts as part of the strategy definition. For example:
strategy: sourceStrategy: from: kind: "ImageStreamTag" name: "builder-image:latest" scripts: "http://somehost.com/scripts_directory"1 - 1
- This path will have
run,assemble, andsave-artifactsappended to it. If any or all scripts are found they will be used in place of the same named scripts provided in the image.
Files located at the
scripts
.s2i/bin
5.2.3. Source-to-image environment variables Link kopierenLink in die Zwischenablage kopiert!
There are two ways to make environment variables available to the source build process and resulting image. Environment files and BuildConfig environment values. Variables provided will be present during the build process and in the output image.
5.2.3.1. Using source-to-image environment files Link kopierenLink in die Zwischenablage kopiert!
Source build enables you to set environment values, one per line, inside your application, by specifying them in a
.s2i/environment
If you provide a
.s2i/environment
assemble
Procedure
For example, to disable assets compilation for your Rails application during the build:
-
Add in the
DISABLE_ASSET_COMPILATION=truefile..s2i/environment
In addition to builds, the specified environment variables are also available in the running application itself. For example, to cause the Rails application to start in
development
production
-
Add to the
RAILS_ENV=developmentfile..s2i/environment
The complete list of supported environment variables is available in the using images section for each image.
5.2.3.2. Using source-to-image build configuration environment Link kopierenLink in die Zwischenablage kopiert!
You can add environment variables to the
sourceStrategy
assemble
run
Procedure
For example, to disable assets compilation for your Rails application:
sourceStrategy: ... env: - name: "DISABLE_ASSET_COMPILATION" value: "true"
5.2.4. Ignoring source-to-image source files Link kopierenLink in die Zwischenablage kopiert!
Source-to-image (S2I) supports a
.s2iignore
.s2iignore
assemble
5.2.5. Creating images from source code with source-to-image Link kopierenLink in die Zwischenablage kopiert!
Source-to-image (S2I) is a framework that makes it easy to write images that take application source code as an input and produce a new image that runs the assembled application as output.
The main advantage of using S2I for building reproducible container images is the ease of use for developers. As a builder image author, you must understand two basic concepts in order for your images to provide the best S2I performance, the build process and S2I scripts.
5.2.5.1. Understanding the source-to-image build process Link kopierenLink in die Zwischenablage kopiert!
The build process consists of the following three fundamental elements, which are combined into a final container image:
- Sources
- Source-to-image (S2I) scripts
- Builder image
S2I generates a Dockerfile with the builder image as the first
FROM
5.2.5.2. How to write source-to-image scripts Link kopierenLink in die Zwischenablage kopiert!
You can write source-to-image (S2I) scripts in any programming language, as long as the scripts are executable inside the builder image. S2I supports multiple options providing
assemble
run
save-artifacts
- A script specified in the build configuration.
-
A script found in the application source directory.
.s2i/bin -
A script found at the default image URL with the label.
io.openshift.s2i.scripts-url
Both the
io.openshift.s2i.scripts-url
-
: absolute path inside the image to a directory where the S2I scripts are located.
image:///path_to_scripts_dir -
: relative or absolute path to a directory on the host where the S2I scripts are located.
file:///path_to_scripts_dir -
: URL to a directory where the S2I scripts are located.
http(s)://path_to_scripts_dir
| Script | Description |
|---|---|
|
| The
|
|
| The
|
|
| The
These dependencies are gathered into a
|
|
| The
|
|
| The
Note The suggested location to put the test application built by your
|
Example S2I scripts
The following example S2I scripts are written in Bash. Each example assumes its
tar
/tmp/s2i
assemble script:
#!/bin/bash
# restore build artifacts
if [ "$(ls /tmp/s2i/artifacts/ 2>/dev/null)" ]; then
mv /tmp/s2i/artifacts/* $HOME/.
fi
# move the application source
mv /tmp/s2i/src $HOME/src
# build application artifacts
pushd ${HOME}
make all
# install the artifacts
make install
popd
run script:
#!/bin/bash
# run the application
/opt/application/run.sh
save-artifacts script:
#!/bin/bash
pushd ${HOME}
if [ -d deps ]; then
# all deps contents to tar stream
tar cf - deps
fi
popd
usage script:
#!/bin/bash
# inform the user how to use the image
cat <<EOF
This is a S2I sample builder image, to use it, install
https://github.com/openshift/source-to-image
EOF
5.2.6. Using build volumes Link kopierenLink in die Zwischenablage kopiert!
You can mount build volumes to give running builds access to information that you don’t want to persist in the output container image.
Build volumes provide sensitive information, such as repository credentials, that the build environment or configuration only needs at build time. Build volumes are different from build inputs, whose data can persist in the output container image.
The mount points of build volumes, from which the running build reads data, are functionally similar to pod volume mounts.
Prerequisites
Procedure
In the
definition of thesourceStrategyobject, add any build volumes to theBuildConfigarray. For example:volumesspec: sourceStrategy: volumes: - name: secret-mvn1 mounts: - destinationPath: /opt/app-root/src/.ssh2 source: type: Secret3 secret: secretName: my-secret4 - name: settings-mvn5 mounts: - destinationPath: /opt/app-root/src/.m26 source: type: ConfigMap7 configMap: name: my-config8 - name: my-csi-volume9 mounts: - destinationPath: /opt/app-root/src/some_path10 source: type: CSI11 csi: driver: csi.sharedresource.openshift.io12 readOnly: true13 volumeAttributes:14 attribute: value
- 1 5 9
- Required. A unique name.
- 2 6 10
- Required. The absolute path of the mount point. It must not contain
..or:and doesn’t collide with the destination path generated by the builder. The/opt/app-root/srcis the default home directory for many Red Hat S2I-enabled images. - 3 7 11
- Required. The type of source,
ConfigMap,Secret, orCSI. - 4 8
- Required. The name of the source.
- 12
- Required. The driver that provides the ephemeral CSI volume.
- 13
- Required. This value must be set to
true. Provides a read-only volume. - 14
- Optional. The volume attributes of the ephemeral CSI volume. Consult the CSI driver’s documentation for supported attribute keys and values.
The Shared Resource CSI Driver is supported as a Technology Preview feature.
5.3. Custom build Link kopierenLink in die Zwischenablage kopiert!
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 container image embedded with build process logic, for example for building RPMs or base images.
Custom builds run with a 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.
5.3.1. Using FROM image for custom builds Link kopierenLink in die Zwischenablage kopiert!
You can use the
customStrategy.from
Procedure
Set the
section:customStrategy.fromstrategy: customStrategy: from: kind: "DockerImage" name: "openshift/sti-image-builder"
5.3.2. Using secrets in custom builds Link kopierenLink in die Zwischenablage kopiert!
In addition to secrets for source and images that can be added to all build types, custom strategies allow adding an arbitrary list of secrets to the builder pod.
Procedure
To mount each secret at a specific location, edit the
andsecretSourcefields of themountPathYAML file:strategystrategy: customStrategy: secrets: - secretSource:1 name: "secret1" mountPath: "/tmp/secret1"2 - secretSource: name: "secret2" mountPath: "/tmp/secret2"
5.3.3. Using environment variables for custom builds Link kopierenLink in die Zwischenablage kopiert!
To make environment variables available to the custom build process, you can add environment variables to the
customStrategy
The environment variables defined there are passed to the pod that runs the custom build.
Procedure
Define a custom HTTP proxy to be used during build:
customStrategy: ... env: - name: "HTTP_PROXY" value: "http://myproxy.net:5187/"To manage environment variables defined in the build configuration, enter the following command:
$ oc set env <enter_variables>
5.3.4. Using custom builder images Link kopierenLink in die Zwischenablage kopiert!
OpenShift Container Platform’s custom build strategy enables you to define a specific builder image responsible for the entire build process. When you need a build to produce individual artifacts such as packages, JARs, WARs, installable ZIPs, or base images, use a custom builder image using the custom build strategy.
A custom builder image is a plain container image embedded with build process logic, which is used for building artifacts such as RPMs or base container images.
Additionally, the custom builder allows implementing any extended build process, such as a CI/CD flow that runs unit or integration tests.
5.3.4.1. Custom builder image Link kopierenLink in die Zwischenablage kopiert!
Upon invocation, a custom builder image receives the following environment variables with the information needed to proceed with the build:
| Variable Name | Description |
|---|---|
|
| The entire serialized JSON of the
|
|
| The URL of a Git repository with source to be built. |
|
| Uses the same value as
|
|
| Specifies the subdirectory of the Git repository to be used when building. Only present if defined. |
|
| The Git reference to be built. |
|
| The version of the OpenShift Container Platform master that created this build object. |
|
| The container image registry to push the image to. |
|
| The container image tag name for the image being built. |
|
| The path to the container registry credentials for running a
|
5.3.4.2. Custom builder workflow Link kopierenLink in die Zwischenablage kopiert!
Although custom builder image authors have flexibility in defining the build process, your builder image must adhere to the following required steps necessary for running a build inside of OpenShift Container Platform:
-
The object definition contains all the necessary information about input parameters for the build.
Build - Run the build process.
- If your build produces an image, push it to the output location of the build if it is defined. Other output locations can be passed with environment variables.
5.4. Pipeline build Link kopierenLink in die Zwischenablage kopiert!
The Pipeline build strategy is deprecated in OpenShift Container Platform 4. Equivalent and improved functionality is present in the OpenShift Container Platform Pipelines based on Tekton.
Jenkins images on OpenShift Container Platform are fully supported and users should follow Jenkins user documentation for defining their
jenkinsfile
The Pipeline build strategy allows developers to define a Jenkins pipeline for use 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
5.4.1. Understanding OpenShift Container Platform pipelines Link kopierenLink in die Zwischenablage kopiert!
The Pipeline build strategy is deprecated in OpenShift Container Platform 4. Equivalent and improved functionality is present in the OpenShift Container Platform Pipelines based on Tekton.
Jenkins images on OpenShift Container Platform are fully supported and users should follow Jenkins user documentation for defining their
jenkinsfile
Pipelines give you control over building, deploying, and promoting your applications on OpenShift Container Platform. Using a combination of the Jenkins Pipeline build strategy,
jenkinsfiles
OpenShift Container Platform Jenkins Sync Plugin
The OpenShift Container Platform Jenkins Sync Plugin keeps the build configuration and build objects in sync with Jenkins jobs and builds, and provides the following:
- Dynamic job and run creation in Jenkins.
- Dynamic creation of agent pod templates from image streams, image stream tags, or config maps.
- Injection of environment variables.
- Pipeline visualization in the OpenShift Container Platform web console.
- Integration with the Jenkins Git plugin, which passes commit information from OpenShift Container Platform builds to the Jenkins Git plugin.
- Synchronization of secrets into Jenkins credential entries.
OpenShift Container Platform Jenkins Client Plugin
The OpenShift Container Platform Jenkins Client Plugin is a Jenkins plugin which aims to provide a readable, concise, comprehensive, and fluent Jenkins Pipeline syntax for rich interactions with an OpenShift Container Platform API Server. The plugin uses the OpenShift Container Platform command-line tool,
oc
The Jenkins Client Plugin must be installed on your Jenkins master so the OpenShift Container Platform DSL will be available to use within the
jenkinsfile
For OpenShift Container Platform Pipelines within your project, you will must use the Jenkins Pipeline Build Strategy. This strategy defaults to using a
jenkinsfile
-
An inline field within your build configuration.
jenkinsfile -
A field within your build configuration that references the location of the
jenkinsfilePathto use relative to the sourcejenkinsfile.contextDir
The optional
jenkinsfilePath
contextDir
contextDir
jenkinsfilePath
jenkinsfile
5.4.2. Providing the Jenkins file for pipeline builds Link kopierenLink in die Zwischenablage kopiert!
The Pipeline build strategy is deprecated in OpenShift Container Platform 4. Equivalent and improved functionality is present in the OpenShift Container Platform Pipelines based on Tekton.
Jenkins images on OpenShift Container Platform are fully supported and users should follow Jenkins user documentation for defining their
jenkinsfile
The
jenkinsfile
You can supply the
jenkinsfile
- A file located within your source code repository.
-
Embedded as part of your build configuration using the field.
jenkinsfile
When using the first option, the
jenkinsfile
-
A file named at the root of your repository.
jenkinsfile -
A file named at the root of the source
jenkinsfileof your repository.contextDir -
A file name specified via the field of the
jenkinsfilePathsection of your BuildConfig, which is relative to the sourceJenkinsPipelineStrategyif supplied, otherwise it defaults to the root of the repository.contextDir
The
jenkinsfile
Procedure
To provide the Jenkins file, you can either:
- Embed the Jenkins file in the build configuration.
- Include in the build configuration a reference to the Git repository that contains the Jenkins file.
Embedded Definition
kind: "BuildConfig"
apiVersion: "v1"
metadata:
name: "sample-pipeline"
spec:
strategy:
jenkinsPipelineStrategy:
jenkinsfile: |-
node('agent') {
stage 'build'
openshiftBuild(buildConfig: 'ruby-sample-build', showBuildLogs: 'true')
stage 'deploy'
openshiftDeploy(deploymentConfig: 'frontend')
}
Reference to Git Repository
kind: "BuildConfig"
apiVersion: "v1"
metadata:
name: "sample-pipeline"
spec:
source:
git:
uri: "https://github.com/openshift/ruby-hello-world"
strategy:
jenkinsPipelineStrategy:
jenkinsfilePath: some/repo/dir/filename
- 1
- The optional
jenkinsfilePathfield specifies the name of the file to use, relative to the sourcecontextDir. IfcontextDiris omitted, it defaults to the root of the repository. IfjenkinsfilePathis omitted, it defaults tojenkinsfile.
5.4.3. Using environment variables for pipeline builds Link kopierenLink in die Zwischenablage kopiert!
The Pipeline build strategy is deprecated in OpenShift Container Platform 4. Equivalent and improved functionality is present in the OpenShift Container Platform Pipelines based on Tekton.
Jenkins images on OpenShift Container Platform are fully supported and users should follow Jenkins user documentation for defining their
jenkinsfile
To make environment variables available to the Pipeline build process, you can add environment variables to the
jenkinsPipelineStrategy
Once defined, the environment variables will be set as parameters for any Jenkins job associated with the build configuration.
Procedure
To define environment variables to be used during build, edit the YAML file:
jenkinsPipelineStrategy: ... env: - name: "FOO" value: "BAR"
You can also manage environment variables defined in the build configuration with the
oc set env
5.4.3.1. Mapping between BuildConfig environment variables and Jenkins job parameters Link kopierenLink in die Zwischenablage kopiert!
When a Jenkins job is created or updated based on changes to a Pipeline strategy build configuration, any environment variables in the build configuration are mapped to Jenkins job parameters definitions, where the default values for the Jenkins job parameters definitions are the current values of the associated environment variables.
After the Jenkins job’s initial creation, you can still add additional parameters to the job from the Jenkins console. The parameter names differ from the names of the environment variables in the build configuration. The parameters are honored when builds are started for those Jenkins jobs.
How you start builds for the Jenkins job dictates how the parameters are set.
-
If you start with , the values of the environment variables in the build configuration are the parameters set for the corresponding job instance. Any changes you make to the parameters' default values from the Jenkins console are ignored. The build configuration values take precedence.
oc start-build If you start with
, the values for the environment variables specified in theoc start-build -eoption take precedence.-e- If you specify an environment variable not listed in the build configuration, they will be added as a Jenkins job parameter definitions.
-
Any changes you make from the Jenkins console to the parameters corresponding to the environment variables are ignored. The build configuration and what you specify with takes precedence.
oc start-build -e
- If you start the Jenkins job with the Jenkins console, then you can control the setting of the parameters with the Jenkins console as part of starting a build for the job.
It is recommended that you specify in the build configuration all possible environment variables to be associated with job parameters. Doing so reduces disk I/O and improves performance during Jenkins processing.
5.4.4. Pipeline build tutorial Link kopierenLink in die Zwischenablage kopiert!
The Pipeline build strategy is deprecated in OpenShift Container Platform 4. Equivalent and improved functionality is present in the OpenShift Container Platform Pipelines based on Tekton.
Jenkins images on OpenShift Container Platform are fully supported and users should follow Jenkins user documentation for defining their
jenkinsfile
This example demonstrates how to create an OpenShift Container Platform Pipeline that will build, deploy, and verify a
Node.js/MongoDB
nodejs-mongodb.json
Procedure
Create the Jenkins master:
$ oc project <project_name>Select the project that you want to use or create a new project with
.oc new-project <project_name>$ oc new-app jenkins-ephemeral1 If you want to use persistent storage, use
instead.jenkins-persistentCreate a file named
with the following content:nodejs-sample-pipeline.yamlNoteThis creates a
object that employs the Jenkins pipeline strategy to build, deploy, and scale theBuildConfigexample application.Node.js/MongoDBkind: "BuildConfig" apiVersion: "v1" metadata: name: "nodejs-sample-pipeline" spec: strategy: jenkinsPipelineStrategy: jenkinsfile: <pipeline content from below> type: JenkinsPipelineAfter you create a
object with aBuildConfig, tell the pipeline what to do by using an inlinejenkinsPipelineStrategy:jenkinsfileNoteThis example does not set up a Git repository for the application.
The following
content is written in Groovy using the OpenShift Container Platform DSL. For this example, include inline content in thejenkinsfileobject using the YAML Literal Style, though including aBuildConfigin your source repository is the preferred method.jenkinsfiledef templatePath = 'https://raw.githubusercontent.com/openshift/nodejs-ex/master/openshift/templates/nodejs-mongodb.json'1 def templateName = 'nodejs-mongodb-example'2 pipeline { agent { node { label 'nodejs'3 } } options { timeout(time: 20, unit: 'MINUTES')4 } stages { stage('preamble') { steps { script { openshift.withCluster() { openshift.withProject() { echo "Using project: ${openshift.project()}" } } } } } stage('cleanup') { steps { script { openshift.withCluster() { openshift.withProject() { openshift.selector("all", [ template : templateName ]).delete()5 if (openshift.selector("secrets", templateName).exists()) {6 openshift.selector("secrets", templateName).delete() } } } } } } stage('create') { steps { script { openshift.withCluster() { openshift.withProject() { openshift.newApp(templatePath)7 } } } } } stage('build') { steps { script { openshift.withCluster() { openshift.withProject() { def builds = openshift.selector("bc", templateName).related('builds') timeout(5) {8 builds.untilEach(1) { return (it.object().status.phase == "Complete") } } } } } } } stage('deploy') { steps { script { openshift.withCluster() { openshift.withProject() { def rm = openshift.selector("dc", templateName).rollout() timeout(5) {9 openshift.selector("dc", templateName).related('pods').untilEach(1) { return (it.object().status.phase == "Running") } } } } } } } stage('tag') { steps { script { openshift.withCluster() { openshift.withProject() { openshift.tag("${templateName}:latest", "${templateName}-staging:latest")10 } } } } } } }- 1
- Path of the template to use.
- 1 2
- Name of the template that will be created.
- 3
- Spin up a
node.jsagent pod on which to run this build. - 4
- Set a timeout of 20 minutes for this pipeline.
- 5
- Delete everything with this template label.
- 6
- Delete any secrets with this template label.
- 7
- Create a new application from the
templatePath. - 8
- Wait up to five minutes for the build to complete.
- 9
- Wait up to five minutes for the deployment to complete.
- 10
- If everything else succeeded, tag the
$ {templateName}:latestimage as$ {templateName}-staging:latest. A pipeline build configuration for the staging environment can watch for the$ {templateName}-staging:latestimage to change and then deploy it to the staging environment.
NoteThe previous example was written using the declarative pipeline style, but the older scripted pipeline style is also supported.
Create the Pipeline
in your OpenShift Container Platform cluster:BuildConfig$ oc create -f nodejs-sample-pipeline.yamlIf you do not want to create your own file, you can use the sample from the Origin repository by running:
$ oc create -f https://raw.githubusercontent.com/openshift/origin/master/examples/jenkins/pipeline/nodejs-sample-pipeline.yaml
Start the Pipeline:
$ oc start-build nodejs-sample-pipelineNoteAlternatively, you can start your pipeline with the OpenShift Container Platform web console by navigating to the Builds
Pipeline section and clicking Start Pipeline, or by visiting the Jenkins Console, navigating to the Pipeline that you created, and clicking Build Now. Once the pipeline is started, you should see the following actions performed within your project:
- A job instance is created on the Jenkins server.
- An agent pod is launched, if your pipeline requires one.
The pipeline runs on the agent pod, or the master if no agent is required.
-
Any previously created resources with the label will be deleted.
template=nodejs-mongodb-example -
A new application, and all of its associated resources, will be created from the template.
nodejs-mongodb-example A build will be started using the
nodejs-mongodb-example.BuildConfig- The pipeline will wait until the build has completed to trigger the next stage.
A deployment will be started using the
deployment configuration.nodejs-mongodb-example- The pipeline will wait until the deployment has completed to trigger the next stage.
-
If the build and deploy are successful, the image will be tagged as
nodejs-mongodb-example:latest.nodejs-mongodb-example:stage
-
Any previously created resources with the
The agent pod is deleted, if one was required for the pipeline.
NoteThe best way to visualize the pipeline execution is by viewing it in the OpenShift Container Platform web console. You can view your pipelines by logging in to the web console and navigating to Builds
Pipelines.
5.5. Adding secrets with web console Link kopierenLink in die Zwischenablage kopiert!
You can add a secret to your build configuration so that it can access a private repository.
Procedure
To add a secret to your build configuration so that it can access a private repository from the OpenShift Container Platform web console:
- Create a new OpenShift Container Platform project.
- Create a secret that contains credentials for accessing a private source code repository.
- Create a build configuration.
-
On the build configuration editor page or in the page of the web console, set the Source Secret.
create app from builder image - Click Save.
5.6. Enabling pulling and pushing Link kopierenLink in die Zwischenablage kopiert!
You can enable pulling to a private registry by setting the pull secret and pushing by setting the push secret in the build configuration.
Procedure
To enable pulling to a private registry:
- Set the pull secret in the build configuration.
To enable pushing:
- Set the push secret in the build configuration.