What's new in OpenShift 3.6 - Developer Experience

What’s new in OpenShift 3.6 - Developer Experience

With OpenShift 3.6 having just shipped, I’d like to take a moment to highlight some of the key new features delivered by the Developer Experience team. For 3.6, the Developer Experience team had two main areas of focus: Service Catalog/Broker support and build pipeline (Jenkins) improvements, but in addition we also made a number of improvements to various build capabilities.

Service Catalog Support

Technology Preview Feature

If you haven’t heard about the Service Catalog effort being driven in the upstream Kubernetes community, you can learn more about it by checking out this OpenShift Commons Briefing. Though the service catalog is a technology preview feature for 3.6, we’ve made it extremely easy to get started with it today. By running oc cluster up --service-catalog, in just a few minutes you can get an OpenShift cluster up and running, including the service catalog and the brand new catalog-oriented web console. The --service-catalog option to oc cluster up deploys the service catalog in a pod within your cluster as well as configuring the rest of the cluster to use it.

Template Service Broker

Technology Preview Feature

As part of our focus on the Service Catalog, we implemented a service broker conformant to the Open Service Broker API specification. This broker presents OpenShift templates as Service Catalog services, allowing you to “provision” an OpenShift template as a service catalog service, as well as “bind” to it. For example, this means you can now provision a database from a template and then bind your application to it. Your application will get database credentials automatically injected as part of the binding. Learn more in the OpenShift Developer's Guide Templates section on this topic. Again this feature is in tech preview along with the rest of the Service Catalog, but you can explore it using oc cluster up --service-catalog. You will need to run a few additional commands to enable the template broker within your cluster because the broker currently runs in an insecure mode. When you run oc cluster up you’ll see all the instructions you need to enable it:

In order to enable access to the Template Service Broker for use with the Service Catalog, you must first grant unauthenticated access to the template service broker api.

WARNING: Enabling this access allows anyone who can see your cluster API server to provision templates within your cluster, impersonating any user in the cluster (including administrators). This can be used to gain full administrative access to your cluster. Do not allow this access unless you fully understand the implications. To enable unauthenticated access to the template service broker api, run the following command as cluster admin:

oc adm policy add-cluster-role-to-group system:openshift:templateservicebroker-client system:unauthenticated system:authenticated

WARNING: Running the above command allows unauthenticated users to access and potentially exploit your cluster.

Obviously those warnings sound pretty dire, and if it’s an environment you care about, they are! So please do make sure you understand the implications of enabling unauthenticated access to your cluster before doing so. The requirement to run the broker with security disabled is planned to be resolved in next release of OpenShift, at which point it will use standard OpenShift token-based authentication.

Automatic Build Pruning

You can now indicate how many historical builds you want to retain for a given build configuration and OpenShift will remove surplus builds automatically (without the cluster administration having to run oadm prune). The number of failed and successful builds to retain can be set independently. This will help you reduce clutter and resource usage on your cluster. To learn more about how to configure this feature, see OpenShift documentation section on advanced build operations for pruning.

Notification Events for Builds

Builds now emit events when they enter various lifecycle phases. When a build begins running, is cancelled, completes successfully, or fails, an event will be generated which can be seen in the web console.

New Webhook Support

We’ve added first class support for GitLab and BitBucket webhooks. This allows pushes to repositories hosted on those platforms to trigger OpenShift builds. Previously only GitHub had first class support and other repositories were forced to use a bridge to the generic webhook mechanism. With the first class mechanism the build platform can distinguish events for pushes to branches that are unrelated to the build configuration and ignore them.

Support for Dockerfile Arguments (ARGs)

When performing a Docker strategy build, you can now provide values for ARGs referenced within your Dockerfile.

Environment Variables in Pipeline Builds

Builds using the pipeline strategy now support environment variables; these can be supplied and overridden at the time a build request is submitted. The environment variables are made available to the pipeline at execution time, allowing highly customized pipelines to be parameterized, for example, with version numbers, commit IDs, names of branches to test, or tag names to use when promoting images. See the OpenShift Documentation for additional details.

Credentials for the OpenShift Jenkins Sync Plugin

The sync plugin synchronizes state between the OpenShift cluster and Jenkins, enabling pipelines to be triggered from either side and reflecting current execution progress. Running this plugin within a Jenkins server running in a pod on your OpenShift cluster has always been straightforward, but configuring it for use from an external Jenkins server was not so straightforward previously. We’ve improved the plugin so it can pick up OpenShift credentials from a Jenkins credential object, making it simple to use the sync plugin with an external Jenkins server.

Easier Custom Slave Configuration for Jenkins

Our Jenkins image ships with two pre-configured slave images (one for Node.JS and another for Maven). Previously, addition of custom slave images required adding a special label to an ImageStream, manual configuration via the Jenkins console, or writing a custom configuration that defined the slave configuration along with the rest of the Jenkins configuration. The newest version of the OpenShift Jenkins Sync plugin continues to automatically define slaves based on ImageStreams with an appropriate label, but can now also define slaves based on specific ImageStream tags.  In addition, pod templates for  slave pods can be provided in a ConfigMap with an appropriate annotation. The sync plugin watches for these ConfigMaps and converts any slave pod template definitions, provided in the Jenkins XML config format, into available slave definitions. These slave definitions can then be used to execute your pipeline in a temporary pod that is running your custom image. A pod running your slave image and defined based on your pod template will be spun up and torn down on demand when Jenkins jobs referencing the slave are submitted for execution. See OpenShift Documentation for additional details.

ValueFrom Support in Build Environment Variables

With the exception of pipeline builds, it is now possible to use Kubernetes’ standard ValueFrom API mechanism for defining environment variables in terms of other resources or fields. This means you can now define an environment variable to be the memory limit that is set on the build, define one variable in terms of another, or define an environment variable based on a ConfigMap or Secret key.

Detailed Build Timing Information

Builds now record timing information based on more granular steps. Information such as how long it took to pull the base image, clone the source, build the source, and push the image can be seen when looking at a build object:

$ oc describe build nodejs-ex-1

Name:       nodejs-ex-1

Namespace:  myproject

Created:    2 minutes ago

Labels:     app=nodejs-ex

            buildconfig=nodejs-ex

            openshift.io/build-config.name=nodejs-ex

            openshift.io/build.start-policy=Serial

Annotations: openshift.io/build-config.name=nodejs-ex

            openshift.io/build.number=1

            openshift.io/build.pod-name=nodejs-ex-1-build

Status: Complete
Started: Fri, 07 Jul 2017 17:49:37 EDT
Duration: 2m23s
FetchInputs: 2s
CommitContainer: 6s
Assemble: 36s
PostCommit: 0s
PushImage: 1m0s

HTTPD Image for Static Content

We’ve made a new image available for serving static content. This is a Source to Image (S2I) enabled httpd image. You can provide your static content in a git repo and then use a normal S2I build to build a custom image that will service your content.  The image is based on Apache Server v2.4. New ImageStreams have been defined for both Centos and RHEL. We’ve also created an example repository you can use to try it out.

Deprecation of Jenkins v1 Image

Finally, although this isn’t exactly a new feature, I want to announce that OpenShift 3.6 will be the last release to ship an updated Jenkins v1 image (docker.io/openshift/jenkins-1-centos7 and registry.access.redhat.com/openshift3/jenkins-1-rhel7). With the Jenkins community moving more towards pipelines and the new blue ocean UI, we are focusing our efforts on the v2 image (docker.io/openshift/jenkins-2-centos7 and registry.access.redhat.com/openshift3/jenkins-2-rhel7) which has now been available for several releases. Users of the v1 image are strongly advised to move to the v2 image which should be fully compatible with existing jobs.