There are many new features in OpenShift 3.3 that improve functionality and the user experience, including a few that lie at the heart of the OpenShift ecosystem: the registry.  Here are a few highlights of those improvements.

registry-central-to-openshift

The Registry User Interface

The Red Hat OpenShift Container Platform provides a registry to manage container images. The most noticeable improvements to the registry in OpenShift 3.3 are in the user interface and its deployment options. The registry can be deployed one of two ways: as an integrated registry in the OpenShift web console or as a stand-alone version.

The OpenShift Integrated Registry User Interface

The updated OpenShift integrated registry provides details about the container images it manages and their tagged versions from within the OpenShift web console.  Each tag of an image stream, from the Builds → Images view, is now a hyperlink that leads to a multi-tabbed page with more information about the selected image.

screenshot-from-2016-08-26-00-44-08

The Details tab shows the image author, built-on date, digest hash ID, labels, annotations, and docker version for compatibility comparisons.   The Config tab shows how the container image was built and its set of defined metadata labels.  The Layers tab shows the size and digest ID for each layer of the image.

screenshot-from-2016-08-26-00-44-17

The Stand-Alone Registry User Interface

The OpenShift registry can alternatively be installed as a stand-alone container image registry to run on-premise or in the cloud, deployed as either an all-in-one cluster (running the master, node, etcd and registry components) or in a Highly Available configuration (three hosts running all components on each, with the masters configured for native high-availability).

The web console of the stand-alone version of the registry is based on the Cockpit project, with full API and CLI access.  Traffic to/from the stand-alone registry is secured by default with TLS.

overview

imagemetadata

This container image registry viewer provides a more “hub-like” direct access experience with registry images, and allows users to manage Role-Based Access Control (RBAC) to authorize image delivery on a per user and per project basis for 'oc policy' and 'oc projects' functionality right from within the user interface.

projectrbac

It has its own built-in OAuth server for a Single Sign-On (SSO) user experience and is easily integrated with common enterprise and cloud identity providers.  The standalone registry management interface also has flexible options for persistent storage of the images it manages and their metadata.

Unauthenticated Image Pull (Anonymous Access)

This new feature provides the ability to pull images from the OpenShift integrated registry without a docker login, to facilitate automation and users who want the ability to "just pull an image like I do with docker hub.”

To enable, the project admin (a user with registry-admin role) simply assigns the registry-viewer role with the one-liner:

$ oc policy add-role-to-group registry-viewer system:unauthenticated

Google Cloud Storage as the Storage Back-End for the Registry

OpenShift 3.3 adds a Google Cloud Storage (GCS) driver to enable its use as the storage back-end for the registry’s container images. Prior to GCS driver initialization, the OpenShift admin must set a bucket parameter to define the name of the GCS bucket to store objects in.

Support for docker distribution 2.4

The OpenShift 3.3 registry will provide support for docker distribution registry 2.4, and the features will be backported to OpenShift 3.2.  Version 2.4 includes a variety of performance and usability enhancements, notably:

Cross-repo Mounting When Pushing Images That Already Exist in the OpenShift Registry

When a client wishes to push a blob to a target repo from a primary source, and knows that the blob already exists in a secondary source repo on the same server as the target, this feature gives the user the ability to optimize the push by requesting the server cross-mount the blob from the secondary source repo, speeding up push time.

Of course, the client must have proper authorizations (pull/push on the target repo, pull on the secondary source repo). If the client is not authorized to pull from the secondary source repo, the blob push will proceed, unoptimized, and the client will push the entire blob to the target repo from the primary source repo without assistance from the secondary source repo.

Support for the New schema2 Storage Format for Images

The image manifest version 2, schema 2 (aka, schema2), allows multi-architecture images via a manifest list which references image manifests for one or more platform-specific versions of an image (e.g. amd64 versus ppc64le).  Schema2 also supports the ability to hash an image’s configuration, to create an ID for the image and provide docker content-addressable information about the image.

To preserve compatibility with older docker versions, support for schema2 must be manually enabled:

$ oc login -u system:admin
$ oc set env dc/docker-registry -n default REGISTRY_MIDDLEWARE_REPOSITORY_OPENSHIFT_ACCEPTSCHEMA2=true

Allow images from a remote registry to be “pulled-through” the OpenShift registry

The OpenShift integrated registry allows remote public and private images to be tagged into an image stream and “pulled-through” it, as if the image were already pushed to the OpenShift registry.  Authentication credentials required for private images to create the image stream are re-used by the integrated registry for subsequent pull-through requests to the remote registry.

The content-offload optimization configuration is still honored by pull-through requests. If the pull-through request points to a remote registry configured with both a storage backend (for example, GCS, S3 or Swift storage) and content-offload enabled, a redirect URL that points directly to the blobs on the remote backend storage will be passed through the local registry to the local docker daemon, creating a direct connection to the remote storage for the blobs.

To optimize image and blob lookups for pull-through requests, a small cache is kept in the registry to track which image streams have the manifest for the requested blobs, avoiding a potentially costly multi-server search.

Conclusion

The OpenShift 3.3 registry continues to add functionality to an intuitive interface with the goal of improving container image management. We hope you will try and integrate some of these new registry features into your environment to improve how it is that you develop.

 

Related Posts

If you want to learn more about the new features of OpenShift 3.3 Don't miss the following blog posts from our engineering team:

What’s New in OpenShift 3.3 – Developer Experience

What’s New in OpenShift 3.3 – Cluster Management

What’s New in OpenShift 3.3 – Web Console