There are many workflows around Kubernetes that need access to one more container registries. While public registries are commonly referenced there is privacy concerns and no need to shuttle private images over public networks. Instead, private registries keep all this pushing and pulling in a local registry.

There are many options for standing up a container registry. We prefer a pure Kubernetes solution and install a registry through the stable Helm chart.

Add the chart repository for the Helm chart to be installed.

helm repo add stable https://kubernetes-charts.storage.googleapis.com

Install the chart for a private container registry.

helm install registry stable/docker-registry \
  --version 1.9.4 \
  --namespace kube-system \
  --set service.type=NodePort \
  --set service.nodePort=31500

The registry is now available as a service. It can be listed.

kubectl get service --namespace kube-system

The Docker tag, push and pull commands must all have the same host name for the image. Docker also requires SSL access, so it's necessary to consistently refer to the registry from the command-line and from within the cluster. In this scenario case we can simply use 127.0.0.0. Use port-forward to expose the registry.

kubectl port-forward --namespace kube-system \
$(kubectl get po -n kube-system | grep registry-docker-registry | \
awk '{print $1;}') 5000:5000 &

Assign an environment variable to the common registry location.

export REGISTRY=127.0.0.1:31500

It will be a few moments before the registry deployment reports it's Available with a 1.

kubectl get deployments registry-docker-registry --namespace kube-system

Once the registry is serving, inspect the contents of the empty registry.

curl $REGISTRY/v2/_catalog | jq

When it's running and healthy, you will see an empty list.

{"repositories":[]}

With the new registry running, let's push a container to it. Grab an existing container.

docker pull replicated/dockerfilelint

Verify the image is now cached locally.

docker images | grep lint

Add a new tag to the new container.

docker tag replicated/dockerfilelint $REGISTRY/dockerfilelint

With the image pulled and with a new tag, it now can be deployed to the new registry.

docker push $REGISTRY/dockerfilelint

Inspect the contents of the private registry and verify the container has been pushed.

curl $REGISTRY/v2/_catalog | jq

In the last step you saw how you can interact with the registry with REST calls. However, it's always helpful to have a decent web interface in front of your registry. There are a few open solutions out there that all run as containers.

This particular one joxit/docker-registry-ui is solid and provides a clean interface. Merci beaucoup, Jones Magloire.

kubectl apply -f registry-ui.yaml

In a moment the new web interface will be available. Open the registry web interface and observe it hosts the single dockerfilelint container image.

As an example, you will take a real application and use the registry to build the container, publish it to your local registry, and run the application on Kubernetes. This example could have used a simple and fast hello world, but this example is a bit richer. This take longer to build, but the hope it to expose you to new types of application possibilities on Kubernetes.

We are taking a clever application from IBM that uses Tensorflow to detect whether a mitosis exists in an image of breast cancer tumor cells.

This repository contains code to instantiate and deploy the mitosis detection model mentioned above. This model takes a 64 x 64 PNG image file extracted from the whole slide image as input, and outputs the predicted probability of the image containing mitosis. For more information and additional features, check out the deep-histopath repository on GitHub. Clone this repository locally:

git clone https://github.com/IBM/MAX-Breast-Cancer-Mitosis-Detector.git && cd MAX-Breast-Cancer-Mitosis-Detector

Build the container image locally.

docker build -t $REGISTRY/max-breast-cancer-mitosis-detector .

There will be some warnings in red text, but you can safely ignore them. This build will take at about 2-3 minutes.

Push the newly built, local image to your private registry.

docker push $REGISTRY/max-breast-cancer-mitosis-detector

The image size is close to 1.5GB so it will take about 1-2 minutes to push. Once the push is complete, verify the new container is listed in the registry web interface.

Deploy the application on Kubernetes using the container image built and pushed in the previous step. The Kubernetes manifest YAML file has a $REGISTRY variable inside of it that needs to be replaced with the actual location of the private registry. Use the envsubst command to replace the environment variable.

cd ~ && envsubst < max-breast-cancer-mitosis-detector.yaml > max-breast-cancer-mitosis-detector-modified.yaml

With the corrected location to the private registry, deploy the application.

kubectl apply -f max-breast-cancer-mitosis-detector-modified.yaml

In a moment the application will be available.

kubectl get deployments,pods,services

Now that the application is running navigate to the application's interactive Swagger documentation page.

Obtain the service location of the application. Be sure access is via HTTP, not HTTPS.

export APP=http://127.0.0.1:32500/

You can exercise the application from the command line.

cd ~/MAX-Breast-Cancer-Mitosis-Detector

See the model prediction, in JSON form, with an image containing a known breast cancer mitosis.

curl -F [email protected]/true.png -XPOST "${APP}model/predict"

See the model prediction with an image without a known breast cancer mitosis.

curl -F [email protected]/false.png -XPOST "${APP}model/predict"

If this IBM app piques your interest you can explore the details of this application here. IBM governs many other MAX applications in the same GitHub account.

Early Detection Saves Lives