This is a cache of https://docs.openshift.com/enterprise/3.1/using_images/other_images/jenkins.html. It is a snapshot of the page at 2024-11-24T04:33:53.345+0000.
Jenkins - Other Images | Using Images | OpenShift Enterprise 3.1
    OpenShift docs are moving and will soon only be available at docs.redhat.com, the home of all Red Hat product documentation. Explore the new docs experience today.
  1. Documentation
    2. history
×

Jenkins

Overview

OpenShift Enterprise provides a Docker 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.

Images

This image comes in two flavors, depending on your needs:

  • RHEL 7

  • CentOS 7

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

The following command creates a new Jenkins pod with Jenkins running in a container:

$ 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, but 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.

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 Enterprise 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 plugins 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:

plugins

This directory contains those binary Jenkins plugins you want to copy into Jenkins.

plugins.txt

This file lists the plugins you want to install (see the section above).

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

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.

Using the Jenkins Kubernetes Plug-in to Run Jobs

The official OpenShift Enterprise Jenkins image includes the pre-installed Kubernetes plug-in that allows Jenkins slaves to be dynamically provisioned on multiple Docker hosts using Kubernetes and OpenShift Enterprise.

The Jenkins image entrypoint also provides auto-discovery and auto-configuration of 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, the entrypoint generates the corresponding Kubernetes plug-in configuration so you can assign your Jenkins jobs to run in a pod running the Docker image provided by the image stream.

To use a Docker 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.

Alternatively, you can use a provided OpenShift Enterprise template to convert an existing image stream to a Jenkins slave.

Tutorial

For more details on the sample job included in this image, see this tutorial.