$ docker pull registry.access.redhat.com/openshift3/jenkins-1-rhel7 $ docker pull registry.access.redhat.com/openshift3/jenkins-2-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. Currently, OpenShift Container Platform provides versions 1.x and 2.x.
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 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 admin/password
.
The default password can be configured by setting the JeNKINS_PASSWORD
environment variable.
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.
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 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 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 |
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-1-centos7
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.
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 Container Platform deployment.