During this scenario will need to build one or more container images.

It's helpful to have a container image registry during the build, push, and deploy phases. There is no need to shuttle private images over the internet. Instead, we 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 image registry:

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

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