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 can 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 Docker Registry Helm Chart.

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

helm repo add twuni https://helm.twun.io

Install the chart for a private container registry:

helm install registry twuni/docker-registry \
  --version 1.11.0 \
  --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

Assign an environment variable to the common registry location:

export REGISTRY=[[HOST_SUBDOMAIN]]-31500-[[KATACODA_HOST]].environments.katacoda.com

It will be a few moments before the registry deployment reports it's Available:

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 -c

and you will see this registry response with the expected empty array:

{"repositories":[]}

If you do not see this response, wait a few moments, and try again. If you have waited and continue to receive an error message, then return to step one and re-verify the health of the cluster.

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.

The container registry you previously deployed is exposed with a Service of the type NodePort. With the Katacoda URL, you have pushed and pulled containers from a public address for the registry's service. However, Katacoda caps a limit on how much data you can post to the URL. This size limit didn't matter for the small image you just pushed in the previous step. With larger images, a push will fail with the status code 413 Request Entity Too Large. In the upcoming step, you will push a larger image that exceeds the Katacoda upload limit.

To workaround this capping issue and learn more about registries we can install a different registry called Trow. We will install and access the new registry locally to avoid the push limit. More about Trow is found in the Container Solutions trow open-source repo. To install Trow follow their recommended quick install steps.

Clone the Trow repo:

git clone https://github.com/ContainerSolutions/trow.git && cd trow/quick-install

Deploy Trow and setup local access:

./install.sh

As it runs, answer 'y'es to all three installation questions. The install script added a host to /etc/hosts and we'll use that as the new container image registry location:

export REGISTRY=trow.kube-public:31000

Return to the home directory:

cd ~

Trow lacks a user interface or easy curl/REST calls, but it does follow the common OCI container registry API so tools like docker-ls can be used to list the contents of the registry. For now, we'll trust it's running and the proof will be to push and pull with the registry in the next step.

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 takes 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 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.

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