Chapter 10. Using images
10.1. Using images overview
Use the following topics to discover the different Source-to-Image (S2I), database, and other container images that are available for OpenShift Container Platform users.
Red Hat’s official container images are provided in the Red Hat Registry at registry.redhat.io. OpenShift Container Platform’s supported S2I, database, and Jenkins images are provided in the openshift4
repository in the Red Hat Quay Registry. For example, quay.io/openshift-release-dev/ocp-v4.0-<address>
is the name of the OpenShift Application Platform image.
The xPaaS middleware images are provided in their respective product repositories on the Red Hat Registry but suffixed with a -openshift
. For example, registry.redhat.io/jboss-eap-6/eap64-openshift
is the name of the JBoss EAP image.
All Red Hat supported images covered in this section are described in the Red Hat Container Catalog. For every version of each image, you can find details on its contents and usage. Browse or search for the image that interests you.
The newer versions of container images are not compatible with earlier versions of OpenShift Container Platform. Verify and use the correct version of container images, based on your version of OpenShift Container Platform.
10.2. Configuring Jenkins images
OpenShift Container Platform provides a container image for running Jenkins. This image provides a Jenkins server instance, which can be used to set up a basic flow for continuous testing, integration, and delivery.
The image is based on the Red Hat Universal Base Images (UBI).
OpenShift Container Platform follows the LTS release of Jenkins. OpenShift Container Platform provides an image that contains Jenkins 2.x.
The OpenShift Container Platform Jenkins images are available on quay.io
or registry.redhat.io
.
For example:
$ docker pull registry.redhat.io/openshift4/ose-jenkins:<v4.3.0>
To use these images, you can either access them directly from these registries or push them into your OpenShift Container Platform container image registry. Additionally, you can create an ImageStream that points to the image, either in your container image registry or at the external location. Your OpenShift Container Platform resources can then reference the ImageStream.
But for convenience, OpenShift Container Platform provides ImageStreams in the openshift
namespace for the core Jenkins image as well as the example Agent images provided for OpenShift Container Platform integration with Jenkins.
10.2.1. Configuration and customization
You can manage Jenkins authentication in two ways:
- OpenShift Container Platform OAuth authentication provided by the OpenShift Login plug-in.
- Standard authentication provided by Jenkins.
10.2.1.1. OpenShift Container Platform OAuth authentication
OAuth authentication is activated by configuring options on the Configure Global Security panel in the Jenkins UI, or by setting the OPENSHIFT_ENABLE_OAUTH
environment variable on the Jenkins Deployment configuration to anything other than false
. This activates the OpenShift Container Platform Login plug-in, which retrieves the configuration information from Pod data or by interacting with the OpenShift Container Platform API server.
Valid credentials are controlled by the OpenShift Container Platform identity provider.
Jenkins supports both browser and non-browser access.
Valid users are automatically added to the Jenkins authorization matrix at log in, where OpenShift Container Platform Roles
dictate the specific Jenkins permissions the users have. The Roles
used by default are the predefined admin
, edit
, and view
. The login plug-in executes self-SAR requests against those Roles
in the Project
or namespace that Jenkins is running in.
Users with the admin
role have the traditional Jenkins administrative user permissions. Users with the edit
or view
role have progressively fewer permissions.
The default OpenShift Container Platform admin
, edit
, and view
Roles
and the Jenkins permissions those Roles
are assigned in the Jenkins instance are configurable.
When running Jenkins in an OpenShift Container Platform Pod
, the login plug-in looks for a ConfigMap
named openshift-jenkins-login-plugin-config
in the namespace that Jenkins is running in.
If this plugin finds and can read in that ConfigMap
, you can define the Role
to Jenkins Permission mappings. Specifically:
-
The login plug-in treats the key and value pairs in the
ConfigMap
as Jenkins permission to OpenShift Role mappings. - The key is the Jenkins permission group short ID and the Jenkins permission short ID, with those two separated by a hyphen character.
-
If you want to add the
Overall Jenkins Administer
permission to an OpenShift Container PlatformRole
, the key should beOverall-Administer
. - To get a sense of which permission groups and permissions IDs are available, go to the matrix authorization page in the Jenkins console and IDs for the groups and individual permissions in the table they provide.
-
The value of the key and value pair is the list of OpenShift Container Platform
Roles
the permission should apply to, with each role separated by a comma. -
If you want to add the
Overall Jenkins Administer
permission to both the defaultadmin
andedit
Roles
, as well as a new jenkins role you have created, the value for the keyOverall-Administer
would beadmin,edit,jenkins
.
The admin
user that is pre-populated in the OpenShift Container Platform Jenkins image with administrative privileges is not given those privileges when OpenShift Container Platform OAuth is used. To grant these permissions the OpenShift Container Platform cluster administrator must explicitly define that user in the OpenShift Container Platform identity provider and assigs the admin
role to the user.
Jenkins users' permissions that are stored can be changed after the users are initially established. The OpenShift Login plug-in polls the OpenShift Container Platform API server for permissions and updates the permissions stored in Jenkins for each user with the permissions retrieved from OpenShift Container Platform. If the Jenkins UI is used to update permissions for a Jenkins user, the permission changes are overwritten the next time the plug-in polls OpenShift Container Platform.
You can control how often the polling occurs with the OPENSHIFT_PERMISSIONS_POLL_INTERVAL
environment variable. The default polling interval is five minutes.
The easiest way to create a new Jenkins service using OAuth authentication is to use a template.
10.2.1.2. Jenkins authentication
Jenkins authentication is used by default if the image is run directly, without using a template.
The first time Jenkins starts, the configuration is created along with the administrator user and password. The default user credentials are admin
and password
. Configure the default password by setting the JENKINS_PASSWORD
environment variable when using, and only when using, standard Jenkins authentication.
Procedure
Create a Jenkins application that uses standard Jenkins authentication:
$ oc new-app -e \ JENKINS_PASSWORD=<password> \ openshift4/ose-jenkins
10.2.2. Jenkins environment variables
The Jenkins server can be configured with the following environment variables:
Variable | Definition | Example values and settings |
---|---|---|
|
Determines whether the OpenShift Login plug-in manages authentication when logging in to Jenkins. To enable, set to |
Default: |
|
The password for the |
Default: |
|
These values control the maximum heap size of the Jenkins JVM. If By default, the maximum heap size of the Jenkins JVM is set to 50% of the container memory limit with no cap. |
|
|
These values control the initial heap size of the Jenkins JVM. If By default, the JVM sets the initial heap size. |
|
| If set, specifies an integer number of cores used for sizing numbers of internal JVM threads. |
Example setting: |
| Specifies options to apply to all JVMs running in this container. It is not recommended to override this value. |
Default: |
| Specifies Jenkins JVM garbage collection parameters. It is not recommended to override this value. |
Default: |
| Specifies additional options for the Jenkins JVM. These options are appended to all other options, including the Java options above, and may be used to override any of them if necessary. Separate each additional option with a space; if any option contains space characters, escape them with a backslash. |
Example settings: |
| Specifies arguments to Jenkins. | |
|
Specifies additional Jenkins plug-ins to install when the container is first run or when |
Example setting: |
| Specifies the interval in milliseconds that the OpenShift Login plug-in polls OpenShift Container Platform for the permissions that are associated with each user that is defined in Jenkins. |
Default: |
|
When running this image with an OpenShift Container Platform persistent volume for the Jenkins configuration directory, the transfer of configuration from the image to the Persistent Volume is performed only the first time the image starts because the Persistent Volume is assigned when the Persistent Volume Claim is created. If you create a custom image that extends this image and updates configuration in the custom image after the initial startup, the configuration is not copied over unless you set this environment variable to |
Default: |
|
When running this image with an OpenShift Container Platform persistent volume for the Jenkins configuration directory, the transfer of plugins from the image to the Persistent Volume is performed only the first time the image starts because the Persistent Volume is assigned when the Persistent Volume Claim is created. If you create a custom image that extends this image and updates plug-ins in the custom image after the initial startup, the plug-ins are not copied over unless you set this environment variable to |
Default: |
|
When running this image with an OpenShift Container Platform Persistent Volume Claim for the Jenkins configuration directory, this environment variable allows the fatal error log file to persist when a fatal error occurs. The fatal error file is saved at |
Default: |
|
Setting this value overrides the image that is used for the default NodeJS agent Pod configuration. A related imagestreamtag named |
Default NodeJS agent image in Jenkins server: |
|
Setting this value overrides the image used for the default maven agent Pod configuration. A related imagestreamtag named |
Default Maven agent image in Jenkins server: |
10.2.3. Providing Jenkins cross project access
If you are going to run Jenkins somewhere other than your same project, you must provide an access token to Jenkins to access your project.
Procedure
Identify the secret for the service account that has appropriate permissions to access the project Jenkins must access:
$ oc describe serviceaccount jenkins Name: default Labels: <none> Secrets: { jenkins-token-uyswp } { jenkins-dockercfg-xcr3d } Tokens: jenkins-token-izv1u jenkins-token-uyswp
In this case the secret is named
jenkins-token-uyswp
.Retrieve the token from the secret:
$ oc describe secret <secret name from above> Name: jenkins-token-uyswp Labels: <none> Annotations: kubernetes.io/service-account.name=jenkins,kubernetes.io/service-account.uid=32f5b661-2a8f-11e5-9528-3c970e3bf0b7 Type: kubernetes.io/service-account-token Data ==== ca.crt: 1066 bytes token: eyJhbGc..<content cut>....wRA
The token parameter contains the token value Jenkins requires to access the project.
10.2.4. Jenkins cross volume mount points
The Jenkins image can be run with mounted volumes to enable persistent storage for the configuration:
-
/var/lib/jenkins
- This is the data directory where Jenkins stores configuration files, including job definitions.
10.2.5. Customizing the Jenkins image through Source-To-Image
To customize the official OpenShift Container Platform Jenkins image, you can use the image as a Source-To-Image (S2I) builder.
You can use S2I to copy your custom Jenkins Jobs definitions, add additional plug-ins, or replace the provided config.xml
file with your own, custom, configuration.
To include your modifications in the Jenkins image, you must have a Git repository with the following directory structure:
plugins
- This directory contains those binary Jenkins plug-ins you want to copy into Jenkins.
plugins.txt
- This file lists the plug-ins you want to install using the following syntax:
pluginId:pluginVersion
configuration/jobs
- This directory contains the Jenkins job definitions.
configuration/config.xml
- This file contains your custom Jenkins configuration.
The contents of the configuration/
directory is copied to the /var/lib/jenkins/
directory, so you can also include additional files, such as credentials.xml
, there.
The following example build configuration customizes the Jenkins image in OpenShift Container Platform:
apiVersion: v1 kind: BuildConfig metadata: name: custom-jenkins-build spec: source: 1 git: uri: https://github.com/custom/repository type: Git strategy: 2 sourceStrategy: from: kind: ImageStreamTag name: jenkins:2 namespace: openshift type: Source output: 3 to: kind: ImageStreamTag name: custom-jenkins:latest
- 1
- The
source
parameter defines the source Git repository with the layout described above. - 2
- The
strategy
parameter defines the original Jenkins image to use as a source image for the build. - 3
- The
output
parameter defines the resulting, customized Jenkins image that you can use in deployment configurations instead of the official Jenkins image.
10.2.6. Configuring the Jenkins Kubernetes plug-in
The OpenShift Container Platform Jenkins image includes the pre-installed Kubernetes plug-in that allows Jenkins agents to be dynamically provisioned on multiple container hosts using Kubernetes and OpenShift Container Platform.
To use the Kubernetes plug-in, OpenShift Container Platform provides images that are suitable for use as Jenkins agents: the Base
, Maven
, and Node.js
images.
Both the Maven and Node.js agent images are automatically configured as Kubernetes Pod Template images within the OpenShift Container Platform Jenkins image’s configuration for the Kubernetes plug-in. That configuration includes labels for each of the images that can be applied to any of your Jenkins jobs under their Restrict where this project can be run
setting. If the label is applied, jobs run under an OpenShift Container Platform Pod running the respective agent image.
The Jenkins image also provides auto-discovery and auto-configuration of additional agent images for the Kubernetes plug-in.
With the OpenShift Container Platform Sync plug-in, the Jenkins image on Jenkins start-up searches for the following within the project that it is running or the projects specifically listed in the plug-in’s configuration:
-
Imagestreams that have the label
role
set tojenkins-slave
. -
Imagestreamtags that have the annotation
role
set tojenkins-slave
. -
ConfigMaps that have the label
role
set tojenkins-slave
.
When it finds an imagestream with the appropriate label, or imagestreamtag with the appropriate annotation, it generates the corresponding Kubernetes plug-in configuration so you can assign your Jenkins jobs to run in a Pod that runs the container image that is provided by the imagestream.
The name and image references of the imagestream or imagestreamtag are mapped to the name and image fields in the Kubernetes plug-in Pod template. You can control the label field of the Kubernetes plug-in Pod template by setting an annotation on the imagestream or imagestreamtag object with the key slave-label
. Otherwise, the name is used as the label.
Do not log in to the Jenkins console and modify the Pod Template configuration. If you do so after the Pod Template is created, and the OpenShift Sync plug-in detects that the image associated with the ImageStream or ImageStreamTag has changed, it replaces the Pod Template and overwrites those configuration changes. You cannot merge a new configuration with the existing configuration.
Consider the ConfigMap approach if you have more complex configuration needs.
When it finds a ConfigMap with the appropriate label, it assumes that any values in the key-value data payload of the ConfigMap contains XML that is consistent with the configuration format for Jenkins and the Kubernetes plug-in Pod templates. A key differentiator to note when using ConfigMaps, instead of imagestreams or imagestreamtags, is that you can control all the parameters of the Kubernetes plug-in Pod template.
Example ConfigMap for jenkins-agent
:
kind: ConfigMap apiVersion: v1 metadata: name: jenkins-agent labels: role: jenkins-slave data: template1: |- <org.csanchez.jenkins.plugins.kubernetes.PodTemplate> <inheritFrom></inheritFrom> <name>template1</name> <instanceCap>2147483647</instanceCap> <idleMinutes>0</idleMinutes> <label>template1</label> <serviceAccount>jenkins</serviceAccount> <nodeSelector></nodeSelector> <volumes/> <containers> <org.csanchez.jenkins.plugins.kubernetes.ContainerTemplate> <name>jnlp</name> <image>openshift/jenkins-agent-maven-35-centos7:v3.10</image> <privileged>false</privileged> <alwaysPullImage>true</alwaysPullImage> <workingDir>/tmp</workingDir> <command></command> <args>${computer.jnlpmac} ${computer.name}</args> <ttyEnabled>false</ttyEnabled> <resourceRequestCpu></resourceRequestCpu> <resourceRequestMemory></resourceRequestMemory> <resourceLimitCpu></resourceLimitCpu> <resourceLimitMemory></resourceLimitMemory> <envVars/> </org.csanchez.jenkins.plugins.kubernetes.ContainerTemplate> </containers> <envVars/> <annotations/> <imagePullSecrets/> <nodeProperties/> </org.csanchez.jenkins.plugins.kubernetes.PodTemplate>
If you log in to the Jenkins console and make further changes to the Pod Template configuration after the Pod Template is created, and the OpenShift Sync plug-in detects that the ConfigMap has changed, it will replace the Pod Template and overwrite those configuration changes. You cannot merge a new configuration with the existing configuration.
Do not log in to the Jenkins console and modify the Pod Template configuration. If you do so after the Pod Template is created, and the OpenShift Sync plug-in detects that the image associated with the ImageStream or ImageStreamTag has changed, it replaces the Pod Template and overwrites those configuration changes. You cannot merge a new configuration with the existing configuration.
Consider the ConfigMap approach if you have more complex configuration needs.
After it is installed, the OpenShift Sync plug-in monitors the API server of OpenShift Container Platform for updates to ImageStreams
, ImageStreamTags
, and ConfigMaps
and adjusts the configuration of the Kubernetes plug-in.
The following rules apply:
-
Removing the label or annotation from the
ConfigMap
,ImageStream
, orImageStreamTag
results in the deletion of any existingPodTemplate
from the configuration of the Kubernetes plug-in. - If those objects are removed, the corresponding configuration is removed from the Kubernetes plug-in.
-
Either creating appropriately labeled or annotated
ConfigMap
,ImageStream
, orImageStreamTag
objects, or the adding of labels after their initial creation, leads to creating of aPodTemplate
in the Kubernetes-plugin configuration. -
In the case of the
PodTemplate
byConfigMap
form, changes to theConfigMap
data for thePodTemplate
are applied to thePodTemplate
settings in the Kubernetes plug-in configuration and overrides any changes that were made to thePodTemplate
through the Jenkins UI between changes to theConfigMap
.
To use a container image as a Jenkins agent, the image must run the slave agent as an entrypoint. For more details about this, refer to the official Jenkins documentation.
10.2.7. Jenkins permissions
If in the ConfigMap the <serviceAccount>
element of the Pod Template XML is the OpenShift Container Platform Service Account used for the resulting Pod, the service account credentials are mounted into the Pod. The permissions are associated with the service account and control which operations against the OpenShift Container Platform master are allowed from the Pod.
Consider the following scenario with service accounts used for the Pod, which is launched by the Kubernetes Plug-in that runs in the OpenShift Container Platform Jenkins image:
If you use the example template for Jenkins that is provided by OpenShift Container Platform, the jenkins
service account is defined with the edit
role for the project Jenkins runs in, and the master Jenkins Pod has that service account mounted.
The two default Maven and NodeJS Pod Templates that are injected into the Jenkins configuration are also set to use the same service account as the Jenkins master.
- Any Pod templates that are automatically discovered by the OpenShift Sync plug-in because their imagestreams or imagestreamtags have the required label or annotations are configured to use the Jenkins master’s service account as their service account.
-
For the other ways you can provide a Pod Template definition into Jenkins and the Kubernetes plug-in, you have to explicitly specify the service account to use. Those other ways include the Jenkins console, the
podTemplate
pipeline DSL that is provided by the Kubernetes plug-in, or labeling a ConfigMap whose data is the XML configuration for a Pod Template. -
If you do not specify a value for the service account, the
default
service account is used. - Ensure that whatever service account is used has the necessary permissions, roles, and so on defined within OpenShift Container Platform to manipulate whatever projects you choose to manipulate from the within the Pod.
10.2.8. Creating a Jenkins service from a template
Templates provide parameter fields to define all the environment variables with predefined default values. OpenShift Container Platform provides templates to make creating a new Jenkins service easy. The Jenkins templates should be registered in the default openshift
project by your cluster administrator during the initial cluster setup.
The two available templates both define deployment configuration and a service. The templates differ in their storage strategy, which affects whether or not the Jenkins content persists across a Pod restart.
A Pod might be restarted when it is moved to another node or when an update of the deployment configuration triggers a redeployment.
-
jenkins-ephemeral
uses ephemeral storage. On Pod restart, all data is lost. This template is only useful for development or testing. -
jenkins-persistent
uses a Persistent Volume store. Data survives a Pod restart.
To use a Persistent Volume store, the cluster administrator must define a Persistent Volume pool in the OpenShift Container Platform deployment.
After you select which template you want, you must instantiate the template to be able to use Jenkins.
Procedure
Create a new Jenkins application using one of the following methods:
A Persistent Volume:
$ oc new-app jenkins-persistent
Or an
emptyDir
type volume where configuration does not persist across Pod restarts:$ oc new-app jenkins-ephemeral
10.2.9. Using the Jenkins Kubernetes plug-in
In the following example, the openshift-jee-sample
BuildConfig causes a Jenkins Maven agent Pod to be dynamically provisioned. The Pod clones some Java source code, builds a WAR file, and causes a second BuildConfig, openshift-jee-sample-docker
to run. The second BuildConfig layers the new WAR file into a container image.
The following example is a BuildConfig that uses the Jenkins Kubernetes plug-in.
kind: List apiVersion: v1 items: - kind: ImageStream apiVersion: v1 metadata: name: openshift-jee-sample - kind: BuildConfig apiVersion: v1 metadata: name: openshift-jee-sample-docker spec: strategy: type: Docker source: type: Docker dockerfile: |- FROM openshift/wildfly-101-centos7:latest COPY ROOT.war /wildfly/standalone/deployments/ROOT.war CMD $STI_SCRIPTS_PATH/run binary: asFile: ROOT.war output: to: kind: ImageStreamTag name: openshift-jee-sample:latest - kind: BuildConfig apiVersion: v1 metadata: name: openshift-jee-sample spec: strategy: type: JenkinsPipeline jenkinsPipelineStrategy: jenkinsfile: |- node("maven") { sh "git clone https://github.com/openshift/openshift-jee-sample.git ." sh "mvn -B -Popenshift package" sh "oc start-build -F openshift-jee-sample-docker --from-file=target/ROOT.war" } triggers: - type: ConfigChange
It is also possible to override the specification of the dynamically created Jenkins agent Pod. The following is a modification to the previous example, which overrides the container memory and specifies an environment variable:
The following example is a BuildConfig that the Jenkins Kubernetes Plug-in, specifying memory limit and environment variable.
kind: BuildConfig apiVersion: v1 metadata: name: openshift-jee-sample spec: strategy: type: JenkinsPipeline jenkinsPipelineStrategy: jenkinsfile: |- podTemplate(label: "mypod", 1 cloud: "openshift", 2 inheritFrom: "maven", 3 containers: [ containerTemplate(name: "jnlp", 4 image: "openshift/jenkins-agent-maven-35-centos7:v3.10", 5 resourceRequestMemory: "512Mi", 6 resourceLimitMemory: "512Mi", 7 envVars: [ envVar(key: "CONTAINER_HEAP_PERCENT", value: "0.25") 8 ]) ]) { node("mypod") { 9 sh "git clone https://github.com/openshift/openshift-jee-sample.git ." sh "mvn -B -Popenshift package" sh "oc start-build -F openshift-jee-sample-docker --from-file=target/ROOT.war" } } triggers: - type: ConfigChange
- 1
- A new Pod template called
mypod
is defined dynamically. The new Pod template name is referenced in the node stanza. - 2
- The
cloud
value must be set toopenshift
. - 3
- The new Pod template can inherit its configuration from an existing Pod template. In this case, inherited from the Maven Pod template that is pre-defined by OpenShift Container Platform.
- 4
- This example overrides values in the pre-existing Container, and must be specified by name. All Jenkins agent images shipped with OpenShift Container Platform use the Container name
jnlp
. - 5
- Specify the Container image name again. This is a known issue.
- 6
- A memory request of
512 Mi
is specified. - 7
- A memory limit of
512 Mi
is specified. - 8
- An environment variable
CONTAINER_HEAP_PERCENT
, with value0.25
, is specified. - 9
- The node stanza references the name of the defined Pod template.
By default, the pod is deleted when the build completes. This behavior can be modified with the plug-in or within a pipeline Jenkinsfile.
10.2.10. Jenkins memory requirements
When deployed by the provided Jenkins Ephemeral or Jenkins Persistent templates, the default memory limit is 1 Gi
.
By default, all other process that run in the Jenkins container cannot use more than a total of 512 MiB
of memory. If they require more memory, the container halts. It is therefore highly recommended that pipelines run external commands in an agent container wherever possible.
And if Project
quotas allow for it, see recommendations from the Jenkins documentation on what a Jenkins master should have from a memory perspective. Those recommendations proscribe to allocate even more memory for the Jenkins master.
It is recommended to specify memory request and limit values on agent containers created by the Jenkins Kubernetes Plug-in. Admin users can set default values on a per-agent image basis through the Jenkins configuration. The memory request and limit parameters can also be overridden on a per-container basis.
You can increase the amount of memory available to Jenkins by overriding the MEMORY_LIMIT
parameter when instantiating the Jenkins Ephemeral or Jenkins Persistent template.
10.2.11. Additional Resources
- See Base image options for more information on the Red Hat Universal Base Images (UBI).
10.3. Jenkins agent
OpenShift Container Platform provides three images that are suitable for use as Jenkins agents: the Base, Maven, and Node.js images.
The first is a base image for Jenkins agents:
-
It pulls in both the required tools, headless Java, the Jenkins JNLP client, and the useful ones including
git
,tar
,zip
, andnss
among others. - It establishes the JNLP agent as the entrypoint.
-
It includes the
oc
client tooling for invoking command line operations from within Jenkins jobs. -
It provides Dockerfiles for both Red Hat Enterprise Linux (RHEL) and
localdev
images.
Two more images that extend the base image are also provided:
- Maven v3.5 image
- Node.js v10 image and Node.js v12 image
The Maven and Node.js Jenkins agent images provide Dockerfiles for the Universal Base Image (UBI) that you can reference when building new agent images. Also note the contrib
and contrib/bin
subdirectories. They allow for the insertion of configuration files and executable scripts for your image.
Use and extend an appropriate agent image version for the your of OpenShift Container Platform. If the oc
client version that is embedded in the agent image is not compatible with the OpenShift Container Platform version, unexpected behavior can result.
10.3.1. Jenkins agent images
The OpenShift Container Platform Jenkins agent images are available on quay.io
or registry.redhat.io
.
Jenkins images are available through the Red Hat Registry:
$ docker pull registry.redhat.io/openshift4/ose-jenkins:<v4.3.0> $ docker pull registry.redhat.io/openshift4/jenkins-agent-nodejs-10-rhel7:<v4.3.0> $ docker pull registry.redhat.io/openshift4/jenkins-agent-nodejs-12-rhel7:<v4.3.0> $ docker pull registry.redhat.io/openshift4/ose-jenkins-agent-maven:<v4.3.0> $ docker pull registry.redhat.io/openshift4/ose-jenkins-agent-base:<v4.3.0>
To use these images, you can either access them directly from quay.io
or registry.redhat.io
or push them into your OpenShift Container Platform container image registry.
10.3.2. Jenkins agent environment variables
Each Jenkins agent container can be configured with the following environment variables.
Variable | Definition | Example values and settings |
---|---|---|
|
These values control the maximum heap size of the Jenkins JVM. If By default, the maximum heap size of the Jenkins JVM is set to 50% of the container memory limit with no cap. |
|
|
These values control the initial heap size of the Jenkins JVM. If By default, the JVM sets the initial heap size. |
|
| If set, specifies an integer number of cores used for sizing numbers of internal JVM threads. |
Example setting: |
| Specifies options to apply to all JVMs running in this container. It is not recommended to override this value. |
Default: |
| Specifies Jenkins JVM garbage collection parameters. It is not recommended to override this value. |
Default: |
| Specifies additional options for the Jenkins JVM. These options are appended to all other options, including the Java options above, and can be used to override any of them, if necessary. Separate each additional option with a space; if any option contains space characters, escape them with a backslash. |
Example settings: |
10.3.3. Jenkins agent memory requirements
A JVM is used in all Jenkins agents to host the Jenkins JNLP agent as well as to run any Java applications such as javac
, Maven, or Gradle.
By default, the Jenkins JNLP agent JVM uses 50% of the container memory limit for its heap. This value can be modified by the CONTAINER_HEAP_PERCENT
environment variable. It can also be capped at an upper limit or overridden entirely.
By default any other processes run in the Jenkins agent container, such as shell scripts or oc
commands run from pipelines, cannot use more than the remaining 50% memory limit without provoking an OOM kill.
By default, each further JVM process that runs in a Jenkins agent container uses up to 25% of the container memory limit for it’s heap. It might be necessary to tune this limit for many build workloads.
10.3.4. Jenkins agent Gradle builds
Hosting Gradle builds in the Jenkins agent on OpenShift Container Platform presents additional complications because in addition to the Jenkins JNLP agent and Gradle JVMs, Gradle spawns a third JVM to run tests if they are specified.
The following settings are suggested as a starting point for running Gradle builds in a memory constrained Jenkins agent on OpenShift Container Platform. You can modify these settings as required.
-
Ensure the long-lived Gradle daemon is disabled by adding
org.gradle.daemon=false
to thegradle.properties
file. -
Disable parallel build execution by ensuring
org.gradle.parallel=true
is not set in thegradle.properties
file and that--parallel
is not set as a command line argument. -
To prevent Java compilations running out-of-process, set
java { options.fork = false }
in thebuild.gradle
file . -
Disable multiple additional test processes by ensuring
test { maxParallelForks = 1 }
is set in thebuild.gradle
file. -
Override the Gradle JVM memory parameters by the
GRADLE_OPTS
,JAVA_OPTS
orJAVA_TOOL_OPTIONS
environment. variables. -
Set the maximum heap size and JVM arguments for any Gradle test JVM by defining the
maxHeapSize
andjvmArgs
settings inbuild.gradle
, or though the-Dorg.gradle.jvmargs
command line argument.
10.3.5. Jenkins agent pod retention
Jenkins agent pods, also known as slave pods, are deleted by default after the build completes or is stopped. This behavior can be changed by the Kubernetes plug-in Pod Retention setting. Pod retention can be set for all Jenkins builds, with overrides for each pod template. The following behaviors are supported:
-
Always
keeps the build pod regardless of build result. -
Default
uses the plug-in value (pod template only). -
Never
always deletes the pod. -
On Failure
keeps the pod if it fails during the build.
You can override pod retention in the pipeline Jenkinsfile:
podTemplate(label: "mypod",
cloud: "openshift",
inheritFrom: "maven",
podRetention: onFailure(), 1
containers: [
...
]) {
node("mypod") {
...
}
}
- 1
- Allowed values for
podRetention
arenever()
,onFailure()
,always()
, anddefault()
.
Pods that are kept might continue to run and count against resource quotas.