Soon, all Red Hat OpenShift documentation will only be available on docs.redhat.com, the official location of all Red Hat product documentation. Get familiar with the updated experience today!
  1. Documentation
    2. history
×

Jenkins

Overview

OpenShift Enterprise 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 Enterprise, tests the output of that build, and then on successful build, retags the output to indicate the build is ready for production.

Versions

OpenShift Enterprise follows the LTS releases of Jenkins. Currently, OpenShift Enterprise provides versions 1.x and 2.x.

Images

These images come in two flavors, depending on your needs:

  • RHEL 7

  • CentOS 7

RHEL 7 Based Images

The RHEL 7 images are available through the Red Hat Registry:

$ docker pull registry.access.redhat.com/openshift3/jenkins-1-rhel7
$ docker pull registry.access.redhat.com/openshift3/jenkins-2-rhel7

CentOS 7 Based Images

This image is available on Docker Hub:

$ docker pull openshift/jenkins-1-centos7
$ docker pull openshift/jenkins-2-centos7

To use these images, you can either access them directly from these registries or push them into your OpenShift Enterprise 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 Enterprise resources can then reference the ImageStream. You can find example ImageStream definitions for all the provided OpenShift Enterprise images.

Configuration and Usage

Initializing Jenkins

The first time you start Jenkins, the configuration is created along with the administrator user and password. The default login is admin/password. The default password can be configured by setting the JENKINS_PASSWORD environment variable.

  • OpenShift Enterprise OAuth authentication provided by the OpenShift Login plug-in.

  • Standard authentication provided by Jenkins

OpenShift Enterprise OAuth authentication

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 Enterprise API server.

Valid credentials are controlled by the OpenShift Enterprise 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 template or jenkins-persistent template (see below), 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 Enterprise 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 edit or view role will have progressively less permissions. See the Jenkins image source repository README for the specifics on the OpenShift roles to Jenkins permissions mappings.

The admin user that is pre-populated in the OpenShift Enterprise Jenkins image with administrative privileges will not be given those privileges when OpenShift Enterprise OAuth is used, unless the OpenShift Enterprise cluster administrator explicitly defines that user in the OpenShift Enterprise identity provider and assigns the admin role to the user.

Jenkins' users permissions can be changed after the users are initially established. The OpenShift Login plug-in polls the OpenShift Enterprise API server for permissions and updates the permissions stored in Jenkins for each user with the permissions retrieved from OpenShift Enterprise. 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 Enterprise.

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 Standard 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.

To create a new Jenkins application using standard Jenkins authentication:

$ oc new-app -e \
    JENKINS_PASSWORD=<password> \
    openshift/jenkins-1-centos7

Environment Variables

The Jenkins password can be configured with the following environment variable:

Table 1. Jenkins Environment Variables
Variable name Description

JENKINS_PASSWORD

Password for the admin user.

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 Enterprise 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.

The two available templates both define a 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 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 Enterprise deployment.