$ oc new-app -e \
JENKINS_PASSWORD=<password> \
openshift/jenkins-2-centos7
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.
This image also includes a sample Jenkins job, which triggers a new build of a
BuildConfig defined in OpenShift Container Platform, tests the output of that build, and
then on successful build, retags the output to indicate the build is ready for
production. For more details, see the
README.
OpenShift Container Platform follows the LTS release of Jenkins. OpenShift Container Platform provides an image containing Jenkins 2.x. A separate image with Jenkins 1.x was previously made available but is now no longer maintained.
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
OAuth
authentication is activated by configuring the Configure Global Security
panel in the Jenkins UI, or by setting the OPENSHIFT_ENABLE_OAUTH
environment variable on the Jenkins Deployment Config to anything other than
false. This activates the OpenShift 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.
Users with the admin role have the traditional Jenkins administrative
user permissions. Users with the edit or view role have progressively
fewer permissions. See the
Jenkins image source
repository README for the specifics on the OpenShift roles to Jenkins
permissions mappings.
|
The |
Jenkins' users permissions 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 as described below.
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.
To create a new Jenkins application using standard Jenkins authentication:
$ oc new-app -e \
JENKINS_PASSWORD=<password> \
openshift/jenkins-2-centos7
The Jenkins server can be configured with the following environment variables:
OPENSHIFT_ENABLE_OAUTH (default: false)
Determines whether the OpenShift Login plug-in manages authentication when
logging into Jenkins. To enable, set to true.
JENKINS_PASSWORD (default: password)
The password for the admin user when using standard Jenkins authentication.
Not applicable when OPENSHIFT_ENABLE_OAUTH is set to true.
OPENSHIFT_JENKINS_JVM_ARCH
Set to x86_64 or i386 to override the JVM used to host Jenkins. For memory
efficiency, by default the Jenkins image dynamically uses a 32-bit JVM if
running in a container with a memory limit under 2GiB.
JAVA_MAX_HEAP_PARAM
CONTAINER_HEAP_PERCENT (default: 0.5, or 50%)
JENKINS_MAX_HEAP_UPPER_BOUND_MB
These values control the maximum heap size of the Jenkins JVM. If
JAVA_MAX_HEAP_PARAM is set (example setting: -Xmx512m), its value takes
precedence. Otherwise, the maximum heap size is dynamically calculated as
CONTAINER_HEAP_PERCENT% (example setting: 0.5, or 50%) of the container
memory limit, optionally capped at JENKINS_MAX_HEAP_UPPER_BOUND_MB MiB
(example setting: 512).
By default, the maximum heap size of the Jenkins JVM is set to 50% of the container memory limit with no cap.
JAVA_INITIAL_HEAP_PARAM
CONTAINER_INITIAL_PERCENT
These values control the initial heap size of the Jenkins JVM. If
JAVA_INITIAL_HEAP_PARAM is set (example setting: -Xms32m), its value takes
precedence. Otherwise, the initial heap size may be dynamically calculated as
CONTAINER_INITIAL_PERCENT% (example setting: 0.1, or 10%) of the
dynamically calculated maximum heap size.
By default, the initial heap sizing is left to the JVM.
CONTAINER_CORE_LIMIT
If set, specifies an integer number of cores used for sizing numbers of internal
JVM threads. Example setting: 2.
JAVA_TOOL_OPTIONS (default: -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap -Dsun.zip.disableMemoryMapping=true)
Specifies options to be heeded by all JVMs running in this container. It is not recommended to override this.
JAVA_GC_OPTS (default: -XX:+UseParallelGC -XX:MinHeapFreeRatio=5 -XX:MaxHeapFreeRatio=10 -XX:GCTimeRatio=4 -XX:AdaptiveSizePolicyWeight=90)
Specifies Jenkins JVM garbage collection parameters. It is not recommended to override this.
JENKINS_JAVA_OVERRIDES
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: -Dfoo -Dbar; -Dfoo=first\ value -Dbar=second\ value.
JENKINS_OPTS
Specifies arguments to Jenkins.
INSTALL_PLUGINS
Specifies additional Jenkins plug-ins to install when the container is first run
or when OVERRIDE_PV_PLUGINS_WITH_IMAGE_PLUGINS is set to true (see below).
Plug-ins are specified as a comma-delimited list of name:version pairs. Example
setting: git:3.7.0,subversion:2.10.2.
OPENSHIFT_PERMISSIONS_POLL_INTERVAL (default: 300000 - 5 minutes)
Specifies in milliseconds how often the OpenShift Login plug-in polls OpenShift Container Platform for the permissions associated with each user defined in Jenkins.
OVERRIDE_PV_CONFIG_WITH_IMAGE_CONFIG (default: false)
When running this image with an OpenShift Container Platform persistent volume for the Jenkins
config directory, the transfer of configuration from the image to the persistent
volume is only done the first startup of the image as the persistent volume is
assigned by the persistent volume claim creation. If you create a custom image
that extends this image and updates configuration in the custom image after
the initial startup, by default it is not copied over, unless you set this
environment variable to true.
OVERRIDE_PV_PLUGINS_WITH_IMAGE_PLUGINS (default: false)
When running this image with an OpenShift Container Platform persistent volume for the Jenkins
config directory, the transfer of plugins from the image to the persistent
volume is only done the first startup of the image as the persistent volume is
assigned by the persistent volume claim creation. If you create a custom image
that extends this image and updates plugins in the custom image after
the initial startup, by default they are not copied over, unless you set this
environment variable to true.
If you are going to run Jenkins somewhere other than as a deployment within your same project, you need to provide an access token to Jenkins to access your project.
Identify the secret for the service account that has appropriate permissions to access the project Jenkins needs to access:
$ oc describe serviceaccount default
Name: default
Labels: <none>
Secrets: { default-token-uyswp }
{ default-dockercfg-xcr3d }
Tokens: default-token-izv1u
default-token-uyswp
In this case the secret is named default-token-uyswp
Retrieve the token from the secret:
$ oc describe secret <secret name from above> # for example, default-token-izv1u Name: default-token-izv1u Labels: <none> Annotations: kubernetes.io/service-account.name=default,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 field contains the token value Jenkins needs to access the project.
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.
To customize the official OpenShift Container Platform Jenkins image, you have two options:
Use Docker layering.
Use the image as a Source-To-Image builder, described here.
You can use S2I to copy your custom Jenkins Jobs definitions, additional plug-ins or replace the provided config.xml file with your own, custom, configuration.
In order to include your modifications in the Jenkins image, you need to have a Git repository with the following directory structure:
This directory contains those binary Jenkins plug-ins you want to copy into Jenkins.
This file lists the plug-ins you want to install:
pluginId:pluginVersion
This directory contains the Jenkins job definitions.
This file contains your custom Jenkins configuration.
The contents of the configuration/ directory is copied into the /var/lib/jenkins/ directory, so you can also include additional files, such as credentials.xml, there.
The following is an example build configuration that 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:latest
namespace: openshift
type: Source
output: (3)
to:
kind: ImageStreamTag
name: custom-jenkins:latest| 1 | The source field defines the source Git repository
with the layout described above. |
| 2 | The strategy field defines the original Jenkins image to use
as a source image for the build. |
| 3 | The output field defines the resulting, customized Jenkins image
you can use in deployment configuration instead of the official Jenkins image. |
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 five images suitable for use as Jenkins agents: the Base, Maven, and Node.js images. See Jenkins Agents for more information.
|
The jenkins-slave-maven-* and jenkins-slave-nodejs-* images are being marked as deprecated during the v3.10 release cycle. The images still exist in the interim so users can migrate their applications to the newer jenkins-agent-maven-* and jenkins-agent-nodejs-* 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, execution of the given job is done 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 Sync plug-in, the Jenkins image on Jenkins start-up searches within the project that it is running, or the projects specifically listed in the plug-in’s configuration for the following:
Image streams that have the label role set to jenkins-slave.
Image stream tags that have the annotation role set to jenkins-slave.
ConfigMaps that have the label role set to jenkins-slave.
When it finds an image stream with the appropriate label, or image stream tag with the appropriate annotation, it generates the corresponding Kubernetes plug-in configuration so you can assign your Jenkins jobs to run in a pod running the container image provided by the image stream.
The name and image references of the image stream or image stream tag 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 image stream or image stream tag object with the key
slave-label. Otherwise, the name is used as the label.
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 consistent with the config format for Jenkins and the Kubernetes plug-in pod templates. A key differentiator to note when using ConfigMaps, instead of image streams or image stream tags, is that you can control all the various fields of the Kubernetes plug-in pod template.
The following is an example ConfigMap:
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>After startup, 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.
In particular, the following rules apply:
Removal of the label or annotation from the ConfigMap, ImageStream, or
ImageStreamTag result in the deletion of any existing PodTemplate from
the configuration of the Kubernetes plug-in.
Similarly, if those objects are removed, the corresponding configuration is removed from the Kubernetes plug-in.
Conversely, either the creation of appropriately labeled or annotated ConfigMap,
ImageStream, or ImageStreamTag objects, or the adding of labels after their
initial creation, leads to the creation of a PodTemplate in the Kubernetes-plugin
configuration.
In the case of the PodTemplate via ConfigMap form, changes to the ConfigMap
data for the PodTemplate is applied to the PodTemplate settings in the
Kubernetes plug-in configuration, and overrides any changes made to the
PodTemplate through the Jenkins UI in the interim between changes to the ConfigMap.
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.
Templates provide parameter fields to define all the environment variables (password) with predefined defaults. OpenShift Container Platform provides templates to make creating a new Jenkins service easy. The Jenkins templates should have been registered in the default openshift project by your cluster administrator during the initial cluster setup. See Loading the Default Image Streams and Templates for more details, if required.
a deployment configuration and a service.
|
A pod may be restarted when it is moved to another node, or when an update of the deployment configuration triggers a redeployment. |
jenkins-persistent uses a persistent volume store. Data survives a pod
restart.
must instantiate the template to be able to use Jenkins:
In the below sample, the openshift-jee-sample BuildConfig causes a Jenkins maven agent Pod to be dynamically provisioned. The Pod clones some Java source, builds a WAR file, then causes a second BuildConfig (openshift-jee-sample-docker) to run to layer the newly created WAR file into a Docker image.
A fuller sample which achieves a similar goal is available here.
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: ConfigChangeIt is also possible to override the specification of the dynamically created Jenkins agent Pod. The following is a modification to the above example which overrides the container memory and specifies an 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 on-the-fly. The new Pod template name is referenced in the node stanza below. |
| 2 | The "cloud" value must be set to "openshift". |
| 3 | The new Pod template can inherit its configuration from an existing Pod template. In this case, we inherit from the "maven" Pod template which is pre-defined by OpenShift Container Platform. |
| 4 | We are overriding values in the pre-existing Container, therefore we must specify it by name. All Jenkins agent images shipped with OpenShift Container Platform use the Container name "jnlp". |
| 5 | The Container image must be re-specified. This is a known issue. |
| 6 | A memory request of 512Mi is specified. |
| 7 | A memory limit of 512Mi is specified. |
| 8 | An environment variable CONTAINER_HEAP_PERCENT, with value "0.25", is specified. |
| 9 | The node stanza references the name of the Pod template newly defined above. |
For more information on Kubernetes plug-in configuration, see the Kubernetes plug-in documentation.
When deployed by the provided Jenkins Ephemeral or Jenkins Persistent templates, the default memory limit is 512MiB.
See Sizing OpenJDK on OpenShift Container Platform for background information on tuning the JVM used by Jenkins.
For memory efficiency, by default the Jenkins image dynamically uses a 32-bit
JVM if running in a container with a memory limit under 2GiB. This behavior can
be overridden by the OPENSHIFT_JENKINS_JVM_ARCH environment variable.
By default the Jenkins 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. See
Environment Variables for more details.
Consider that by default all other processes executed in the Jenkins
container, such as shell scripts or oc commands run locally from pipelines, are
not likely to be able to use more than the remaining 256MiB memory combined
without provoking an OOM kill. It is therefore highly recommended that
pipelines run external commands in a agent container wherever possible.
It is recommended to specify memory request and limit values on agent containers created by the Jenkins Kubernetes Plug-in. As admin, defaults can be set on a per-agent image basis through the Jenkins configuration. The memory request and limit can also be overridden on a per-container basis as documented above.
You can increase the amount of memory available to Jenkins by overriding the MEMORY_LIMIT paramenter when instantiating the Jenkins Ephemeral or Jenkins Persistent template.
The following plug-ins are provided to integrate Jenkins with OpenShift Container Platform. They are available by default in the Jenkins image.
The OpenShift Container Platform Client Plug-in aims to provide a readable, concise,
comprehensive, and fluent Jenkins Pipeline syntax for rich interactions with
OpenShift Container Platform. The plug-in leverages the oc binary, which must be available
on the nodes executing the script.
This plug-in is fully supported and is included in the Jenkins image. It provides:
A Fluent-style syntax for use in Jenkins Pipelines.
Use of and exposure to any option available with oc.
Integration with Jenkins credentials and clusters.
Continued support for classic Jenkins Freestyle jobs.
See the OpenShift Pipeline Builds tutorial and the plug-in’s README for more information.
The OpenShift Container Platform Pipeline Plug-in is a prior integration between Jenkins and OpenShift Container Platform which provides less functionality than the OpenShift Container Platform Client Plug-in. It remains available and supported.
See the plug-in’s README for more information.
To facilitate OpenShift Container Platform
Pipeline
build strategy for integration between Jenkins and OpenShift Container Platform, the
OpenShift Sync Plug-in
monitors the API server of OpenShift Container Platform for updates to BuildConfigs and
Builds that employ the Pipeline strategy and either creates Jenkins Pipeline
projects (when a BuildConfig is created) or starts jobs in the resulting
projects (when a Build is started).
As noted in Configuring the
Jenkins Kubernetes Plug-in, this plug-in can create PodTemplate
configurations for the Kubernetes plug-in based on specifically cited
ImageStream, ImageStreamTag, or ConfigMap objects defined in
OpenShift Container Platform.
This plug-in can now take Secret objects with a label key of
credential.sync.jenkins.openshift.io and label value of true and construct
Jenkins credentials which are placed in the default global domain within
the Jenkins credentials hierarchy. The ID of the credential is composed
of the namespace the Secret is defined in, a hyphen (-), followed by the
name of the Secret.
Similar to the handling of ConfigMaps for PodTemplates, the Secret object
defined in OpenShift Container Platform is considered the master configuration. Any subsequent
updates to the object in OpenShift Container Platform are applied to the Jenkins credential
(overwriting any changes to the credential made in the interim).
Removal of the credential.sync.jenkins.openshift.io property, setting of that
property to something other than true, or deletion of the Secret in
OpenShift Container Platform results in deletion of the associated credential in Jenkins.
The type of secret is mapped to the jenkins credential type as follows:
With Opaque type Secret objects the plug-in looks for username and
password in the data section and constructs a Jenkins
UsernamePasswordCredentials credential. Remember, in OpenShift Container Platform the
password field can be either an actual password or the user’s unique token.
If those are not present, it looks for the ssh-privatekey field and create
a Jenkins BasicSSHUserPrivateKey credential.
With kubernetes.io/basic-auth type `Secret`objects the plug-in creates a
Jenkins UsernamePasswordCredentials credential.
With kubernetes.io/ssh-auth type Secret objects the plug-in creates a
Jenkins BasicSSHUserPrivateKey credential.
The Kubernetes plug-in is used to run Jenkins agents as pods on your cluster. The auto-configuration of the Kubernetes plug-in is described in Using the Jenkins Kubernetes Plug-in.