$ docker pull registry.access.redhat.com/openshift3/jenkins-1-rhel7
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.
OpenShift Container Platform follows the LTS releases of Jenkins.
This image comes in two flavors, depending on your needs:
RHEL 7 Based Image
The RHEL 7 image is available through Red Hat’s subscription registry:
$ docker pull registry.access.redhat.com/openshift3/jenkins-1-rhel7
CentOS 7 Based Image
This image is available on DockerHub. To download it:
$ docker pull openshift/jenkins-1-centos7
To use these images, you can either access them directly from these registries or push them into your OpenShift Container Platform Docker registry. Additionally, you can create an ImageStream that points to the image, either in your Docker registry or at the external location. Your OpenShift Container Platform resources can then reference the ImageStream. You can find example ImageStream definitions for all the provided OpenShift Container Platform images.
The first time you start Jenkins, the configuration is created along with the administrator user and password.
The default login is
The default password can be configured by setting the
JENKINS_PASSWORD environment variable.
<<<<<<< HEAD The following command creates a new Jenkins pod with Jenkins running in a container:
OpenShift Container Platform OAuth authentication provided by the OpenShift Login plug-in.
Standard authentication provided by Jenkins
==== OpenShift Container Platform OAuth authentication
authentication is activated by configuring the
Configure Global Security
panel in the Jenkins UI, or by setting the
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 your identity provider.
For example, if
Allow All is the default identity provider, you can provide
any non-empty string for both the user name and password.
For non-browser access, the OpenShift Login plug-in also supports using the HTTP bearer token authorization header to supply valid credentials for accessing Jenkins. Ensure to use the token associated with the serviceaccount for the project in which Jenkins is running, which, if you started Jenkins using the jenkins-ephemeral or jenkins-persistent templates, are found by using:
$ oc describe serviceaccount jenkins $ oc describe secret <serviceaccount secret name>
Valid users are automatically added to the Jenkins authorization matrix at log
in, where OpenShift Container Platform
Roles dictate the specific Jenkins permissions the
user will have.
Users with the
admin role will have the traditional Jenkins administrative
user permissions. Users with the
view role will have progressively
less permissions. See the
Jenkins image source
repository README for the specifics on the OpenShift roles to Jenkins
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.
Ensure the the default image streams and templates are already installed.
Create a new Jenkins application using:
$ oc new-app jenkins-persistent
EmptyDir type volume (where configuration does not persist across pod restarts):
$ oc new-app jenkins-ephemeral
If you instantiate the template against releases prior to v3.4 of OpenShift Container Platform, standard Jenkins authentication is used, and the default 'admin' account will exist with password 'password'. See Jenkins Standard Authentication for details about changing this password.
==== Jenkins Standard Authentication
Jenkins authentication is used by default if the image is run outside of OpenShift Container Platform.
The first time Jenkins starts, the configuration is created along with the
administrator user and password. The default user credentials are
password. Configure the default password by setting the
environment variable when using (and only when using) standard Jenkins
To create a new Jenkins application using standard Jenkins authentication: >>>>>>> 7cdc862… More anchor fixes
$ oc new-app -e \ JENKINS_PASSWORD=<password> \ openshift/jenkins-1-centos7
=== Environment Variables
The Jenkins password can be configured with the following environment variable:
Password for the
=== 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.
== Creating a Jenkins Service from a Template
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 pod may 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 useful for development or testing only.
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.
Once selected, you must instantiate the template to be able to use Jenkins.
== Using Jenkins as a Source-To-Image builder
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:
This directory contains the Jenkins job definitions.
This file contains your custom Jenkins configuration.
The contents of the configuration/ directory will be 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
== Using the Jenkins Kubernetes Plug-in to Run Jobs
The official OpenShift Container Platform Jenkins image includes the pre-installed Kubernetes plug-in that allows Jenkins slaves to be dynamically provisioned on multiple container hosts using Kubernetes and OpenShift Container Platform.
To facilitate the using of the Kubernetes plug-in, OpenShift Container Platform provides three images suitable for use as Jenkins slaves..
<<<<<<< HEAD The first is a base image for Jenkins slaves. It pulls in both required tools (headless Java, the Jenkins JNLP client) and generally useful ones (including git, tar, zip, nss among others) as well as establishing the JNLP slave agent as the entrypoint. The image also includes the oc client tooling for invoking command line operations from within Jenkins jobs. And it provides Dockerfiles for both Centos and RHEL images.
It pulls in both the required tools (headless Java, the Jenkins JNLP client) and the useful ones (including git, tar, zip, nss among others).
It establishes the JNLP slave agent as the entrypoint.
It includes the oc client tooling for invoking command line operations from within Jenkins jobs, and
It provides Dockerfiles for both Centos and RHEL images. >>>>>>> 7cdc862… More anchor fixes
Two images which extend this base image are also provided:
Both the Maven and NodeJS slave images are configured as Kubernetes Pod Tempate images within the OpenShift Container Platform Jenkins image’s configuration for the Kubernetes plugin. That configuration includes labels for each which 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 will be done under an OpenShift Container Platform Pod running the respective slave image.
The Maven and NodeJS Jenkins slave images provide Dockerfiles for both Centos and RHEL that you can reference when building new slave images.
Also note the
contrib/bin subdirectories. They allow for the insertion of configuration files and executable
scripts for your image.
The Jenkins image also provides auto-discovery and auto-configuration <<<<<<< HEAD of slave images for the Kubernetes plug-ins by scanning the project Jenkins is deployed in for existing image streams with the label role set to jenkins-slave.
When an image stream with this label is found, corresponding Kubernetes plug-in configuration is generated so you can assign your Jenkins
of slave images for the
Kubernetes plug-in. The Jenkins image searches for these in the existing image streams within the project that it is running in. The search specifically looks for image streams that have the label
role set to
When it finds an image stream with this label, it generates the corresponding Kubernetes plug-in configuration so you can assign your Jenkins >>>>>>> 7cdc862… More anchor fixes jobs to run in a pod running the container image provided by the image stream.
Note: this scanning is only performed once, when the Jenkins master is starting. If you label additional imagestreams, the Jenkins master will need to be restarted to pick up the additional images.
To use a container image as an Jenkins slave, the image must run the slave agent as an entrypoint. For more details about this, refer to the official Jenkins documentation.
For more details on the sample job included in this image, see this tutorial.