Image Registry

When running Origin, Openshift or Atomic Platform as a Kubernetes cluster, the images in the inbuilt registry will be listed in the Cluster view.

You can also run just the registry view directly, for both project admins, and other users of the cluster.

Running the Registry interface

Running software on Openshift requires forethought, planning and configuration. In particular, in order to run the registry interface as a pod you need to first decide the host name that it will be accessible at. This is the host name part of its URL.

Next use the following commands to deploy the registry pod and service. You'll need to have admin access to the Openshift cluster, as an OAuth client needs to be created. Replace the XXX with the host name you want to make the registry accessible at. In addition replace YYY with the host name of the Openshift API server. Replace ZZZ with the host name of the Openshift registry itself.

$ curl -o openshift-cockpit.template https://raw.githubusercontent.com/cockpit-project/cockpit/master/containers/openshift-cockpit.template
$ oc process -f openshift-cockpit.template -v COCKPIT_KUBE_URL=https://XXX,OPENSHIFT_OAUTH_PROVIDER_URL=https://YYY:8443,REGISTRY_ONLY=true,REGISTRY_HOST=ZZZ | oc create -f -

You'll now need to setup a Route object to expose the pod at the URL you decided on above. You can access the registry interface on https port of the host name you chose.

Limitations

The registry implementation in an Openshift, Origin or Atomic Platform Kubernetes cluster and its API have several limitations. Since the UI just talks to the cluster, these issues need to be solved at the cluster level, rather thin in the user interface.

Deletion of images: Deleting an image doesn't actually remove its data from the registry storage. This will happen opportunistically later when the cluster decides the image is no longer in use.

Replacing an image: Replacing an image doesn't actually replace its data in the registry store. It is stored as history, and cleaned up opportunistically later when the cluster decides the image is no longer in use.

No image search: The API does not support searching for images. Images are categorized by project.

Cannot use normal credentials at docker login: One must paste a long docker login command from the interface into the command line before it used. One cannot simply type their usual Origin or Openshift credentials at the docker login prompts. Card

docker login expires after 24 hours: A login on the command-line (copied as described above) expires after 24 hours. It stops being valid even though it's cached by the docker client.

Doesn't scale: The API does not support paging or sorting. Therefore the interface loads all the images in the selected projects. If many images are present, then scaling issues will be present.

Projects not tracked properly: Unlike the rest of the interface, one will not see a new project immediately when adding a project from the command line or another tool that interacts with the API. Issue

Cannot see Docker Image layers as non-admin user: The interface displays the layers that make up an image. However due to API limitations one cannot see these layers as a non-admin user. Issue

Cluster admin cannot use docker command line: The token based API authentication used by docker login is not available to the Cluster system:admin account. Another account must be used.

Same image pushed twice shown multiple times: The same image tagged twice and then pushed into the registry twice will have different named identifiers in the API. The interface will show them separately. Issue

Cannot discover the name of the registry to access: The various command lines displayed in the interface will often not display the correct registry address to use. There's no way to discover this via the API for normal users.