Chapter 5. Other Images
This topic group includes information on other container images available for OpenShift Enterprise users.
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.
OpenShift Enterprise follows the LTS releases of Jenkins. Currently, OpenShift Enterprise 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 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.
5.2.4. Configuration and Usage
220.127.116.11. 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
18.104.22.168.1. 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
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.
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.
22.214.171.124.2. 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
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
126.96.36.199. Environment Variables
The Jenkins password can be configured with the following environment variable:
Table 5.1. Jenkins Environment Variables
| || |
Password for the
188.8.131.52. 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.
5.2.5. 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-ephemeraluses ephemeral storage. On pod restart, all data is lost. This template is useful for development or testing only.
jenkins-persistentuses 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.